RSS Feed LinkedIn Google Plus

Kategória: Projekt menedzsment

  1. Hogyan motiváljuk az alkalmazottakat?

    2012. január 31. kedd

    Ilya Pozin így kezdi bejegyzését:

    The ability to motivate employees is one of the greatest skills an entrepreneur can possess. Two years ago, I realized I didn’t have this skill. So I hired a CEO who did.

    Majd a következőkben a kilenc, a két év során megtanult szempotot tár elénk magyarázatokkal ellátva:

    1. Légy bőkezű a dicsérettel
    2. Szabadulj meg a menedzserektől és vezérelvű irányítástól
    3. A saját ötleteid rákényszerítése helyett őket is vond be
    4. Kerüld a kioktatást és a kritizálást
    5. Tégy mindenkit vezetővé
    6. Hetente hívd meg egy alkalmazottadat ebédelni
    7. Adj elismerést és kisebb jutalmakat
    8. Céges partik helyett inkább pikniket rendezz
    9. Oszd meg a sikereket – és a fájdalmakat

    A pénz fontos szempont, önmagában kevés és nem boldogít. :) Érdemes elgondolkodni azon, amit írt.


  2. Scrum és Kanban: mindkettőből a legjobbat

    2011. május 20. péntek

    A napokban olvastam el a címben említett könyvet. Összességében tetszett, rövid, velős, amolyan metrón olvasós könyv.

    Mi most Scrum alapú módszerrel fejlesztünk, de még nem tökéletes. A könyv abból indul ki, hogy ismerjük és használjuk a Scrum-ot, és mellé teszi a Kanbant is, mint egy lehetőséget. (Többet van szó a Kanbanról.) Viszont a példája (példái) az üzemeltetési részlegről vannak. Oda jobban illik a Kanban, a fejlesztéshez talán annyira nem. Bár kétség kívül vannak olyan részei, amit hasznosíthatnánk, hasznosítunk.

    A Scrum-ban a csapat az etap planning-en megkapja, megbecsüli, elvállalja a feladatokat, amiket a sprint végéig elvileg kiadható formára hoz. Sprint alatt a táblához nem nyúlhat a Product Owner. Nálunk ezt még nem sikerült átvinni. Köztes megoldásként a bal szélső oszlopot (feladat/sprint backlog) módosíthatja a PO, korlátozott mértékben újabb feladatokat vehet fel. A Scrum Master pedig kiveheti az alacsonyabb prioritású feladatokat, hogy tudjuk tartani Burndown chart által mutatott optimális fejlesztési ütemet, és két hetente lehessen kiadás.

    Nem olyan könnyű bevezetni az agilis módszertant.


  3. Agilis? Nem agilis?

    2011. április 19. kedd

    Verhás Péter élesen fogalmaz az agilis módszertant alkalmazókkal szemben. El tudom hinni, hogy a tapasztalataira épít. Ha az agilis annyit jelent, hogy nem kell tervezni, nem kell tesztelni, akkor sokkal gyengébb minőségű kód lesz. A nagy projekteket, komolyabb függvénykönyvtárakat, keretrendszereket, publikus API-kat igenis meg kell tervezni, dobozokat kell rajzolni hozzá, és stabillá kell tenni. Azt írja:

    A tesztelés megint egy külön téma, de ott meg aztán végképp nagyon rossz a tapasztalatom. Akár waterfall, akár agilis: tesztelés az nem nagyon szokott lenni. De, ahogy a levélíró is érzékeli: waterfall fejlesztésnél azért inkább. Ahhoz a habitushoz közelebb áll a fegyelem, a teszteléshez pedig fegyelem kell.

    Érdekes, igaza van. Pedig éppen az agilis környezetben lenne szükség arra, hogy jól felépített és széles körű automatizált teszteket futtassunk.

    Nálunk mindenesetre határozottan jó lépés volt az agilis módszertanra való áttérés, így a dolgoknak menete lett, tervezés, tesztelés, fix határidők, stb. Sajnos néha jelentkezik a „írjunk kódot, gyorsan” hozzáállás, így még a dokumentáció is lemarad, nemhogy a tesztesetek írása.

    Összességében mégis azt tudom mondani, hogy jól megszervezett és koordinált módon az agilis módszertannal történő fejlesztés az ügyfél számára is jobb. Ehhez látni kell azt is, hogy ez a módszertan is eszköz, nem cél.