HTML

Agilitás Blog - az agilitas.hu blogja

Agilis módszertani cikkek, újdonságok, vélemények, intejúk, szoftverek, eszközök és technikák - a gondolkodó, tapasztalt tanácsadók szemével.

Friss topikok

  • kulcsár bence: @Borbándy László: kezdem sejteni, van vagy 4 borbandy laszlo es vagy 6 kulcsar bence a facebookon.... (2013.03.11. 22:51) A UserStory feldarabolás 10 stratégiája
  • Janovszki Zsolt: időnként jó ezt újra meg újra végiggondolni, most pont egy prezentációhoz kellett, gondoltam gondo... (2013.03.04. 23:14) Agile Principles - magyarul
  • kulcsár bence: A cikk célja az volt, hogy a lehető legszélesebb áttekintését adja az agilis szerződéseknek. Jó öt... (2011.02.15. 11:08) Agilis szerződések
  • kulcsár bence: A kérdés jó. Először is tisztázni kell, hogy a csapat agilis csapat-e. A mi esetünkben igen, ami r... (2011.02.08. 23:26) Az önszervező csapat sikerfaktorai
  • Janovszki Zsolt: @sipos_zoli: ott a két pont. Kérlek járuljatok hozzá az átadás dokumentálásához, amire a mai napon... (2010.12.08. 13:01) Szerintem félreértelmezi

Linkblog

Scrum Master reference card series_sustainable pace

2014.02.17. 14:50  T. Balázs

  • General qualities

    • Sustainable pace is the tool and time where the team concentrates on its self improvement. It is an investment that brings its returns in higher business value delivered per sprint. Without sustainable pace a growing velocity is a vanity metric.

    • It is not for covering up the slips on the estimated times

    • Its amount should be constant enough to be able to introduce metrics on it

    • Team has improvement backlog

    • Team has impediment backlog

    • Team has tech debt backlog

    • These issues have to be treated as user stories, and planned. Preferably during the sprint planning meeting. A short time-box should be enough for it. Only real life practice will tell what “short” is.

  • In sprint planning

    • PO agrees to what the team commits to deliver by end of sprint:

      • improvement introduced. Team knows

        • what steps will be made > action plan

        • how the success will be measured

        • when will we be there > done criteria

        • owner of improvement volunteered

      • impediment cleaned away. Team knows

        • what steps will be made > action plan

        • how the success will be measured

        • when will we be there > done criteria

        • owner of impediment volunteered

      • Tech Debt cleared and presented

    • Tech Debt

      • prioritized backlog (high, medium, low)

      • High, medium and low items all must get their share of being cleared!

      • Team has a fix day every week when they give presentation.

      • The presentation begins not earlier than 17:00

      • Every presentation day gives place to two or three presentations (each not longer than 15 minutes)

      • preparing for the tech dept presentation is part of the sustainable pace

      • every team member must present and be present

      • in the sprint planning meeting

        • the tech dept topics are chosen

        • presenter volunteers

        • preparation resources are decided upon

        • topic is publicised within the organization

      • scrum master prepares QA page for the attending crowd

      • best practices are learned and applied for ever better presentations

      • scrum master has various statistics on the subject

author: Balázs Tornai

please comment to: Twitter @Bal_A_gile or balazs.tornai@agilitas.hu

Szólj hozzá!

Címkék: team fenntartható fejlődés agile scrum openagile agile principles agilis szemlélet agile tools agile team scrum mastery scrum master-ség önfejlesztő csapat self improvement of team

Agile Principles - magyarul

2013.03.04. 23:11  Janovszki Zsolt

Számunkra a legfontosabb az elégedett ügyfél, amit az értéket képviselő szoftver korai fázisban történő átadásával, majd az értéknövelő fejlesztések folyamatos szállításával érünk el

A követelmények változását a fejlesztés késői fázisában is elfogadjuk. Az agilis folyamatok a megrendelői versenyelőny növelésének eszközeként fogják fel a változást

Működő szoftvert szállítunk néhány héttől néhány hónapig terjedő gyakorisággal. Ezen belül preferáljuk a rövidebb szállítási gyakoriságot

Az üzletnek és a fejlesztésnek napi szinten, az elejétől a végéig együtt kell dolgozniuk a projekten

Motivált egyénekre építsd a projektet! Nyújts megfelelő környezetet, támogasd őket, és bízz bennük, hogy megcsinálják, amit meg kell csinálniuk

A leghatékonyabb módja a fejlesztő csapat részére történő információ átadásának, illetve az információ áramlásnak a csapaton belül a személyes megbeszélés

Az előrelépés elsődleges mértékegysége a működő szoftver

Az agilis folyamatok a fenntartható fejlesztést támogatják. A szponzoroknak, a fejlesztőknek és a felhasználóknak képesnek kell lenniük előre nem meghatározott ideig fenntartani az állandó ütemben történő haladást

A technikai kiválóságra törekvés és a jó tervezés erősíti az agilitást

Simplicity- a nem elvégzett munka maximalizálásának művészete - esszenciális

A legjobb architektúrákat, specifikációkat és terveket az önszerveződő csapatok képesek letenni az asztalra

Előre meghatározott időszakonként a csapat elgondolkozik azon, hogy miként lehetnének még hatékonyabbak, és ezután a megbeszélés eredményének megfelelően formálják át a viselkedésüket, hozzáállásukat

1 komment

Címkék: manifesto agile agile principles működő szoftver agilis szemlélet

Agilis coach az agilis szervezetben

2012.11.28. 12:00  kulcsár bence

Alan Atlas, CST, CSC, Agile Coach, Rally Software and Mark Kilby, CSM, Agile Coach, Rally Software

A coaching és a tréning elengedhetetlen elemei az agilis módszertan bevezetésének. Ezt nehéz lehet elfogadni bizonyos esetekben mivel az agilis kereteket könnyű átlátni, mégis rengeteg apró részletre kell odafigyelni, hogy kezelhessük az agilis átalakulás összetett folyamatát. Tagadhatatlan, hogy hasznosak az elérhető külső források pl.: könyvek, weboldalak, kurzusok és tanácsadók. A szervezetek többségének mégis szüksége van egy olyan személyre, aki érti az agilis átalakítás finomságait, és azt el tudja helyezni egy adott szervezeti kontextusban. Így biztosítva, hogy az átalakítás olyan sikeres legyen, amennyire csak lehetséges. Mi úgy hivatkozunk erre a szerepre: „a beépített agilis coach”. Ha csak lehet, kifejezetten bátorítjuk megbízóinkat, hogy azonosítsák ezeket a személyeket a szervezeten belül, ahogy egyre nő az igény a mind mélyebb agilis tudás elsajátítására és alkalmazására.

Agilis coachként számtalan emberi tulajdonság, tudás és tapasztalat kap központi szerepet, az ezek közüli választás pedig egy nagyon kényes folyamat. Ebben a cikkben tisztázzuk, hogy mikor kell egy agilis coach, mit is csinál tulajdonképpen, és adunk egy pár hasznos tippet, illetve miként hozható létre a saját belső „agilis coach”.

1. Mikor kell egy agile coach?

1.1. A coaching szükségességének tünetei

Sok cég egyedül indul el az agilis úton. Néhányan kitartanak a DIY (csináld magad) módszer mellett, de vannak akik amellett teszik le a voksukat, hogy egy külső professzionális agilis coach/tanácsadó segítségével járják azt végig.

Amint az agilis módszertan gyökeret ver a szervezetben, többnyire önmagától nyilvánvalóvá válik (vagy az agilis tanácsadó javasolja így), hogy a vállalkozásnak ideje létre hozni egy belsős coach pozíciót. Ez minden esetben jobban szolgálja az agilis irányba fejlődő szervezet érdekeit.

Azonban néha ez a szükségszerűség nem is olyan nyilvánvaló. Különösen a „csináld magad” szervezeteknek tart sokáig, hogy felismerjék: agilis tudás mindentől függetlenül is létezik, és az ő esetükben nincs belőle elég a szervezeten belül. Emellett az egy ösztönös vagy jobb esetben tervezett döntés, hogy egy szervezet mihez kezd a felgyűlt belső agilis tapasztalatokkal.

Íme néhány negatív jelenség ami egy szervezet elengedhetetlen szükségét jelzi egy jól finanszírozott, központilag támogatott, biztos lábakon álló és állhatatos agilis tanácsadó jelenlétének:

  • Nem lehet egyértelműen megállapítani, hogy a meglévő agilis csapatok valóban sikeresen működnek-e
  • A csapatok teljesítménye széles skálán mozog
  • A csapatok nem kielégítően alkalmazzák az agilis eszközöket, nincs meg a várt áttörés, illetve nem látszanak az elvárt előnyök a korábbi működéshez képest
  • A külsős tanácsadó válik a strukturális változtatások kerékkötőjévé
      • Pénzügyi okból – egyszerűen túl sokba kerül
      • Nem képes teljesíteni az elvárásokat
      • Nem elég tapasztalt
  • Az agilis módszertanok alkalmazása csapatok helyett programokban/projektekben jelentkezik
  • A cégen belül egyes szervezetek azon kapják magukat, hogy nincsenek szinkronban a már agilis szervezeti egységekkel

 Az első három pont az agilis csapatok teljesítményét nézi. Azaz: ha már nyakig van a cég az agilis átalakításban, de nem tudja megmondani, hogy hol tartanak az egyes csapatok, vagy ha a csapatok gyengén szerepelnek, jobb ha a saját kezébe veszi a kezdeményezést. A PMO világában ilyenkor még több szabály és új felügyeleti eszközök alkalmazásával kezelnék a helyzetet. Az agilis világban ellenben támogatással, tréningekkel, képzéssel kell segíteni, hogy a csapatok minél sikeresebben vegyék az agilis átalakítás akadályait. Ez a segítség biztosítja, hogy a lehető legtöbbet profitáljanak az új módszertanok alkalmazásából. Javasolt, hogy az agilis módszertan bevezetésében felgyülemlett tapasztalatokat, és a szervezetre jellemző speciális eseteket rendszerezzék. Ezzel nagyban segíthető a belső tréning és coaching eredményessége.

Ennek legjobb módja egy olyan személy alkalmazása, aki mélyen ismeri és érti az agilis módszertanokat, egyben fel tudja mérni, mikor ér el egy bizonyos fejlettségi szintet az agilis bevezetés, és ezután mint coach tudja támogatni a teameket (lásd alant).

A következő szimptóma azt a helyzetet írja le, amikor a szervezet túlnő a külsős agilis tapasztalat forrásán. Ez esetben önjáróvá kell válni, és a további agilis fejlődés motorja a belső indíttatás lesz. Ennek a pontnak a lényege akkor érezhető, ha már túljutottunk a kívülről indukált agilis bevezetés tréningjein.

Az utolsó két szimptóma természetes következménye az agilis adaptáció sikeres voltának. Végül minden bevezetés eredményeként megjelenik az az igény, hogy az agilis alapelveket a nagyobb projektekben is alkalmazzák. Az is fel fog tűnni, hogy amikor az agilis módszerek meggyökeresednek, a fejlesztői csapatokon kívüli más szervezetek is tréningeket kérnek a témában, hogy alkalmazkodni tudjanak az agilis csapatok által diktált új ritmushoz és stílushoz, kultúrához.

A figyelmes olvasó bizonyára észrevette, hogy hangsúlyozzuk a belső coach szükségességét amennyiben az agilis átalakítás döcögve halad és akkor is, ha épp kifejezetten sikeres. Más szóval, mindenképp helye van az agilis coachingnak minden szervezetben, ha az agilis módszertanok bevezetése útjára léptek vagy lépni fognak.

2.  Mit csinál egy coach?

2.1. Tréning azoknak, akik még nem ismerik az agilis módszertanokat

Az agilis coach egyik fő feladata a tréning. Újonnan létrejött csapatoknak, alkalmazottaknak, menedzsereknek és felső vezetőknek mind szükségük van tréningre az agilis bevezetés kezdeti lépéseiben. A képzésekre azonban még azután is folyamatosan szükség van, hogy a teljes szervezet profin elsajátította az agilis technikákat (pl.: az új kollégáknak is meg kell tanítani, hogyan illeszkedhetnek be a helyi agilis környezetbe).

2.2.  Coaching


2.2.1.   Új csapatok indítása

 A coaching folyamata a tanácsadásból, hibák javításából, javaslatok tételéből és bármi más segítség megadásából áll, hogy a csapatok javíthassanak az agilis bevezetés hatékonyságán. Miközben az olyan keretek, mint a SCRUM relatív egyszerűek, rengeteg a hibalehetőség és a finomhangolás/optimalizálás helye és igénye, amikor egy csapat először próbálja bevezetni. A coach-tól elvárt, hogy bevesse minden tapasztalatát a csapatok terelgetésében, ahogy azok először próbálkoznak az agilis alapelvek értelmezésével és alkalmazásával.

2.2.2.   Team értékelés és finomhangolás

Ez egy igen érzékeny folyamat, ahol a coach általában megfigyel egy csapatot, majd ezen tapasztalatok alapján javasol problémamegoldó lépéseket. Ezek lehetnek tréningek, coaching egyes kiemelt agilis területeken, vagy személyreszabott tanács, hogy miként helyezzék el az adott csapatot az agilis szervezeten belül.

Sokan félreértik ezeket az értékeléseket és úgy tekintenek rájuk mint egy „standard agilis folyamatnak” történő megfelelési mutatót. A helyes szemlélet az, ha olyan eszközként tekintünk rájuk melyek segítenek feltárni a hatékonyabb agilis bevezetési módokat és megmutatják, miként érhető el a lehető legteljesebb üzleti érték.

Amikor van már egy bejáratott alap keretrendszer mint mondjuk a SCRUM vagy az XP, megtalálni ezek legoptimálisabb bevezetési módjait talán a legegyszerűbb kihívás, de semmiképp sem az egyetlen.

Figyelem: Ha az értékelés eredményére mint „megfelelősségi fok”-ra tekintünk, akkor a coach-ot óhatatlanul is egy újabb „folyamat felügyelő”-nek fogják látni, és hitelét veszti, mint a csapat bizalmát bíró team-tag.

2.2.3.   Folyamatos Oktatás

 Gyakran a tréningek bőségében dúskálnak a fejlesztő csapatok az agilis bevezetés elején, de mások, mint például a menedzsment, üzleti fejlesztés, értékesítés, marketing, PMO (projekt menedzsment iroda) és más szervezetek, nem kapják meg ugyanazt a szintű oktatást. Ezeket a szervezeteket az agilis módszertanokba bevezetni csak az első lépés ahhoz, hogy megőrizhessék hatékonyságukat mint az üzleti élet egyik résztvevői.

A coach ilyen folyamatos képzési és oktatási tevékenysége kevésbé intenzív és aprólékos, mint egy célzott agilis team képzés. Ugyanakkor a legtöbb esetben ez a helyes szintű információmennyiség ami hatékonyan adható át egy szervezetnek az agilis bevezetés korai fázisában.

2.2.4.   Támogatás és vezetés

Csakúgy, mint ahogy a PMO módszerben van központosított folyamatirányítás, megvan az igény, hogy folyamatosan átlássák az agilis bevezetés éppen aktuális helyzetét a cégen belül. Ez lehet olyan triviális módszer, minthogy valaki egyenként végigmegy az agilis csapatokon és közvetlenül tájékozódik, vagy olyan komplex, mint tervezni egy irányítási rendszert, ami agilis metrikák sokaságát dolgozza fel, hogy ezáltal segítse az agilis bevezetést az egész cégen belül.

2.2.5.   Tanácsadás

Az agilis keretrendszerek nem részletezik az agilis bevezetés minden aspektusát, különösen nem nagy szervezetekben és nagy projektekben. Egyáltalán nem magától értetődő, hogy miként kell az agilis módszertanokat bevezetni egy 500+ főt felölelő projektben, és elérni az integráció és hatékonyság azon fokát, mint egy jelentősen kisebb projektben, vagy csapatban. Egy agilis coachtól elvárt, hogy naprakész legyen az adott iparág sajátosságaiból, különösen ami az agilis módszertanok adott területen belüli alkalmazását illeti. Ez igaz kis és nagy projektekre egyaránt. Az egyes csapatok szintjén pedig képesnek kell lennie, hogy elősegítse a fejlődést, és támogassa a programokat az adott tudás sikeres alkalmazására.

2.2.6.   Közösség Formálás és Vezetés

Kiemelt szolgáltatása a belső agilis coachnak, hogy elősegíti és kineveli a szervezeten belül az agilis módszertanok alkalmazóinak közösségét. Ez a közösség lesz a platform, hogy az emberek kicseréljék tapasztalataikat, megoldjanak helyi kihívásokat, problémákat. Ezeket a közösségeket a szervezet agilis átalakításának korai folyamatában létre kell hozni. A kezdetekben, mint egy speciális érdeklődésű kis csoport, ez a közösség jó hangulatú platformja lesz az agilis fejlődésnek és a tanulásnak. Különösen igaz ez, ha az agilis coach rendszeresen bedob hasznos és aktuális témákat a szélesebb értelemben vett agilis közösségből (akár az iparágon kívülről is), hogy azokat a csoport feldolgozza, alkalmazásuk területeit megkeresse.

A jó coach kinevel egy közösséget, ami csomópontként funkcionálva forrása az egyes csapatok, csoportok és szervezetek közötti új ötletek, elképzelések és probléma megoldási módszerek születésének. Ezen a csomóponton a coach gyengéden irányíthatja a beszélgetéseket, és beolthatja a résztvevőket egy kifinomult gondolkodásmóddal. Fontos, hogy ezt anélkül tegye, hogy túl irányító, vagy adott esetben elutasító lenne egyes egyénekkel szemben. Az ilyen közösségek agilis bevezetés lezárulta után is forrásai lesznek az új ötleteknek, módszereknek.

2.3. Példamutatás az agilis működésben

A legkritikusabb dolog amit egy agilis coachnak tennie kell egy szervezeten belül, az a folyamatos személyes példamutatás az agilis működésben, amit ő maga is képvisel, bevezetni igyekszik. Ennek megnyilvánulásai például: hatékonyságnövelő megbeszélések és tervezések elősegítése, konstruktív konfliktusmegoldások, a hibák mihamarabbi feltárása és ezek minél láthatóbb és transzparensebb megoldásának segítése. Lásd Davies és Sedky könyvét: „Agile coaching” valamint Tabaka könyvét, utóbbi témája a részletek feltárásáért történő együttműködés. Adkins könyve az agilis csapatokról, ezen példamutató megnyilvánulások széles skáláját vonultatja fel pl.: “…és ide kerül a Te kedvenced…” – ami arra utal, hogy egy coachnak mindig késznek kell lennie arra, hogy alkalmazkodjon a felmerülő legkülönbözőbb helyzetekhez. A folyamatosan előremutató és fejlődést elősegítő viselkedésekben történő példamutatás kulcskérdés egy agilis coach életében.

3.   A saját coach kinevelése, avagy mi kell egy agilis coach-hoz

3.1. Értékek

Amíg az Agilis Kiáltvány lefektette egy hatékonyabb munkavégzés kereteit, mi ajánlunk egy értékrendszert ami elvárt egy agilis coachtól:

3.1.1.   Tettek a puszta beszéddel szemben

Az agilis filozófia az emberek együttműködését tartja legértékesebbnek. Ezért egy jó agilis coach előszeretettel használja az interaktív tanítási technikákat. Röviden átbeszéli az új koncepciókat az érdekeltekkel, és bevonja a hallgatóságát a megbeszélésekbe, tevékenységekbe és önszervező kísérletekbe. Ezzel bátorítja az embereket, hogy a gyakorlatban megvalósítsák a tanultakat. Ez a fajta coaching tudás az irányítatlan egyéni stílustól az évek során finomított és tökéletesített professzionális tréning tudásig terjedhet.

3.1.2.   Minden részletre kiterjedő megfigyelés (Szokrateszi kérdezési módszer) az elszámoltató kikérdezéssel szemben

Bár az agilis coach szélesebb tudással rendelkezik az agilis módszertanokról, mint bárki a szervezetben, tudniuk kell, hogy nem mindig van kéznél náluk sem a helyes válasz. Épp ezért egy agilis coach nem úgy fog kérdezni, hogy „És akkor miért nem próbáljátok meg a pair-programming módszert?” de helyette rávezeti a csapatokat, hogy maguknak fedezzék fel és döntsék el, hogy mi lesz nekik a leghatékonyabb megoldás. Hogy elérje ezt, a coach olyan kérdéseket tehet fel mint: “Milyen problémáitok vannak a minőséggel? Hogy látjátok, mi működik és mi nem, a jelenlegi felállásban? Van alternatív megoldás, amit kipróbálhatunk a jobb eredmény reményében? Érdemes fontolóra venni ezek alapján a pair-programming alkalmazását?” Az ilyen jellegű kérdéssor segíti a csapatokat, hogy maguknak válogassák össze azokat a gyakorlatokat, melyek a legmegfelelőbbek a rájuk jellemző környezetben A jó agilis coach kerüli, hogy a csapatra felülről erőltessenek egy új módszertant.

3.1.3.   Tárgyalásvezetés a parancsoló vezetéssel szemben

Az agilis coach biztosítja, hogy mindenki megoszthassa a többiekkel amit gondol, és nem egy felülről diktált menetrendet erőltet. Miközben eléri a kiegyensúlyozott inputot a megbeszélés levezetésével, az agilis coach egyben segíti a csapatot, hogy konszenzus alapján döntsenek, és nem ő dönt a csapat helyett. Az agilis coachnak ezt a fajta tárgyalásvezetői feladatot a szervezet minden szintjén meg kell tudnia valósítani a kisegítő személyzettől a felső vezetésig. Így minden szinten profitálnak az együttműködésen alapuló önmenedzselésből.

3.1.4.   Közösségorientált a hierarchikus berendezkedéssel szemben

Az agilis coach úgy tekint egy szervezetre, mintha az egy önálló ökoszisztéma volna, és tisztában van azzal, hogy a legapróbb változtatás is alapjaiban és megjósolhatatlan módon befolyásolhatja a szervezetet. Minden változtatás gyakorlatilag egy kísérlet, ami számos tervezés-megvalósítás-ellenőrzés-akció ciklusból áll. Ezek a ciklusok segítenek felderíteni, hogy a kérdéses változtatás hatékonyságnövelő volt, vagy adott esetben kártékony a csapat és a szervezet szempontjából. Ez a szemléletmód jelentősen eltér a klasszikus szervezeti felépítésekhez képest, ahol megkíséreljük beskatulyázni a munkaterületeket, és hierarchiát tükröző címekkel ruházzuk fel az embereket. Ezzel szemben az emberek a legritkább esetben illenek bele ezekbe a skatulyákba. Ehelyett keresztül kasul vándorolnak a szervezet egyes részein belül. Nagyjából úgy, ahogy a borostyán kúszik át a drótkerítésen. Az agilis coach azt figyeli, hogy ezek a „borostyánok” hol támasztják és hol fojtják meg a szervezet agilis átalakítását, és a megteszi kellő lépéseket, hogy új változtatásokkal a helyes irányba terelje a folyamatot.

3.2. Emberi tulajdonságok

A fent leírt tulajdonságokon túl, a következőkkel sem árt tisztában lenni egy agilis coach esetében:

3.2.1.   Aktív és mély figyelem

„Ez több mint aktív odafigyelés.” Ahogy Adkins írja a könyvében: több szintű figyelem létezik, és egy jó coach tudja, hogy nem csak meghallania kell a szavakat, hanem érteni és érezni is kell a szavak mögötti kontextust.

3.2.2.   Szenvedéllyel Tanítani

Egy coach nem feltétlenül szenvedélyes minden területen, de szükséges hogy szenvedélyt mutasson egyes témák iránt. Ez dönti el, hogy miként tanít többeket egy osztályteremben, vagy klasszikus szemtől-szemben tréneri körülmények között. Az ilyen coach a többiek szemében, energikus, motiváló személyként jelenik meg.

3.2.3.   Az örök tanuló

Az agilis módszertanok folyamatos változásban vannak, ahogy az azokat használók közössége növekszik és a módszertanok a munkájukon keresztül megmérettetnek és tapasztalatokat cserélnek. Egy agilis coachnak szemmel kell tartania ezeket a trendeket, hogy ha kell bevezethesse őket a szervezetben.

3.2.4.   Örökre Szolgál

A legjobb coach-ok mindig szolgálják a csapatukat, a közösségüket és a szervezetüket. Ez nem azt jelenti, hogy elnyomják a saját céljaikat, ambícióikat. A „Rally”-nél az egyik fő értékünk a „saját valóság megteremtése”. Ennek az értéknek lényegi eleme, hogy mindannyian folyamatosan próbáljuk meg felismerni és fellelni a legbelsőbb mozgatórugóinkat és azokat összeegyeztetni a szervezeti célokkal Így tudjuk hatékonyan szolgálni saját magunk és a szervezetet. A jó agilis coach példát állít ennek a viselkedésnek és tanítja a többieket, hogyan tehetik ők is ezt.

Hogy átgondoljunk további karakterisztikákat az agilis coachokról, javasoljuk, hogy nézd át Rising and Mann könyvében kifejtett a mintákat a „Fearless Change” témában, vagy megfontolás tárgyává tenni Roger Brown listáját az ő 2009-es blog post-jából. 

3.3. Felvenni vagy Belülről Választani?


3.3.1.    Építsd Magad, vagy Vedd Meg

Vannak jó érvek amellett, hogy a cégen belül keressük meg az agilis coach-ot. Az agilis átalakítás kultúrára történő hatása, mély ismerete a belső politikai viszonyoknak, történelmi kontextus, üzleti környezet és más cég-specifikus faktorok komoly fegyvertény lehet egy coach eszköztárában. Ha a hatékony coach munkát nézzük, ezek legalább olyan fontosak, mint bármely más coach tulajdonság és minőség melyeket feljebb már említettünk.

A másik fontos dolog egy céges coach esetében az elhivatottság és pozitív hozzáállás. Valaki, aki hisz az agilis módszertanok erejében és előnyeiben, sokkal valószínűbb, hogy helyesen fogja azokat alkalmazni. Véleményünk szerint az energikus odaadás sokkal értékesebb mint az érzelemmentes tudás.

A harmadik fontos előny, ami miatt érdemes az agilis coachot a cégen belül keresni, az az illető garantált ismertsége a szervezeten belül, főleg ha pozitív, motivált és hozzáértő személyként ismerik. A szakmai hitel kulcsfontosságú egy coach életében. Ha valaki már felépítette ezt a hitelességet, legtöbbször sok év kitartó munkájával, az döntő fontosságú lehet az illető kiválasztásában. Mindez elengedhetetlen ahhoz, hogy legyőzzük a cégekben általánosan meggyökerezett szemléletet, miszerint „nálunk minden más”. Az a személy, aki már sikereket tud felmutatni az agilis módszertanok használatában a helyi céges viszonyokon belül, sokkal hitelesebb lesz a többiek szemében, mint bármely külsős. 

3.4.  Pár Jótanács Coach Felvételhez

Ha úgy döntünk, hogy a cégen kívülről keresünk embert, abban a rendhagyó felvételi helyzetben találhatjuk magunkat, hogy nem tudjuk megítélni a jelölteket, mivel nincs meg a megfelelő belső tudás a szakterületen. Hogy ezt leküzdhessük, alkalmazzunk erre az időszakra egy külsős agilis coach-ot, aki segít végigvinni a kiválasztás folyamatát.

Ne csak kérdésekkel bombázzuk a jelölteket egy interjú szobában. Rengeteg jó forrás van a területről, de az agilis alapelvek tőlük függetlenül azt követelnék meg, hogy „együttműködjenek” és ezáltal „eredményeket mutassanak fel”.

Egy pár kérdés ízelítőképp:

  • A jelölt coach vezessen le egy megbeszélést a szervezeten belüli valamely csapattal. A csapatnak szenvedéllyel kell viseltetnie a téma iránt. Ez lehet egy dizájn, vagy stratégiai kérdést taglaló megbeszélés. Legyenek egymással ütköző álláspontok. Figyeljük meg, hogy a jelölt miként segíti a csapatot, hogy az önálló döntésre jusson a témában. Természetesen egy titoktartási szerződés ajánlott egy ilyen interjú szituációban.
  • Tegyük párba a jelöltet valakivel a szervezetből, hogy együtt dolgozzanak ki egy tréning anyagot vagy kódrészletet.
  • A jelölt tanítson egy adott témáról a legkülönbözőbb kollégák csoportjának a szervezeten belül. Az ebédelj-és-tanulj alkalmak tipikusan jók erre.
  • Figyeld meg miként reagál a coach egy váratlan eseményre. Próbálkozz például a Powerpoint Karaoke módszerrel. Lényege, hogy az előadónak olyan slideokból kell prezentálnia, melyeket korábban még nem látott. A slideokat automatikus váltásra állítsuk, mondjuk 20 másodpercre. A játék lényege, hogy a lehető legkoherensebb előadást rögtönözze belőle a jelölt.

4.   Összefoglalás

A coaching és tréning elengedhetetlenek az agilis átalakítás folyamatában. A legtöbb jelentősebb méretű cégnek, nagy értéket képvisel egy stabil, megbízható, belső agilis tudásforrás létrehozása és fenntartása (gyakran úgy hivatkoznak rá, mint „belső agilis coach”). Vannak felmerülő és érzékelhető szimptómák egy vállalkozásban, amik azt mutatják, hogy egy belső agilis coach igen hasznos extra lehet az agilis tevékenységekhez.

A belső agilis coach feladatai különbözőek: van benne klasszikus tréning, coaching és még sok egyéb. Agilis coach-nak lenni elvárást is támaszt számos emberi tulajdonsággal szemben, valamint különböző késségeket és képességeket igényel. Ezekből, mint megbízó, kiválasztani a legmegfelelőbbet óvatosságot és körültekintést igényel.

5.   Ajánlott irodalom

“Agile Coaching”, Rachel Davies and Liz Sedley, 2009.

“Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition”, Lyssa Adkins, Addison-Wesley, 2010.

“Collaboration Explained: Facilitation Skills for Software Project Leaders”, Jean Tabaka, Addison-Wesley, 2006.

“Fearless Change: Patterns for Introducing New Ideas”, Mary Lynn Manns, Ph.d., and Linda Rising, Ph.d., Addison-Wesley, 2004.

http://www.Agilecoach.net/

“The Value of an Agile Coach”, Roger Brown, http://www.Agilecoachjournal.com/index.php/2009-10-15/scrum/the-value-of-an-

Forrás  fordította Tornai Balázs, válogatta Kulcsár Bence

Szólj hozzá!

Az agilis coach 7 buktatója

2012.02.17. 14:15  kulcsár bence

Lyssa Adkins, CST, Agile Coach

Az agilis coach-oknak komoly munkájuk van és kemény kihívásoknak kell megfelelniük:


"Támogassák a csapatot, de se túl sokat, se túl keveset. "
"Legyenek elérhetőek, de ne legyenek levakarhatatlanok. "
"Adjanak ötleteket, de ne legyenek túl mélyen belevonva."
"Coachok legyenek, ne menedzserek."

 

Ezek a tanácsok zavarosak sőt, ellentmondásosak is. Nem csoda, ha az agilis coach-ok szerencsétlen viselkedési csapdákba esnek miközben újabb és újabb módokon próbálnak segíteni a csapatoknak. A probléma az, hogy ezek a viselkedési jelenségek alaposan alá tudják ásni egy csapat önszervező képességét és a fejlődését, hogy magasabb teljesítményt érjen el. Ezért hívjuk ezeket bukás-formuláknak.

Pár év coaching, agilis coach-ok segítése, és sok más coach munka közbeni megfigyelése után, feljegyeztem egy csokorra való buktatót. Egyes coach-ok ideiglenesen felvehetnek egy vagy akár több buktatót is, amikor stresszhatásnak vannak kitéve. Mások folytonosan mutatják ezen buktatók jeleit, olyannyira, hogy a coach maga sincs is tisztában vele, vagy azok hatásával a csapatra.

Ebben a cikkben az agilis coach kifejezést egyben a „scrum master” kifejezéssel tesszük egyenlővé. A nagy teljesítményű csapatok létrehozásáért, a scrum mastereknek és az agilis coachoknak mélyre kell merülniük a „scrum”-ban. Túl a konkrét technikákon egyenesen a munka coach aspektusaiba is, ezért a cikk csak az agilis coach kifejezést fogja használni. Fontos: a cikkben leírt buktatók, és az azok kikerülésének módjai mind az agilis coach-okra, mind a scrum master-ekre egyarán érvényesek.

Mik is ezek a buktatók?

A bukás-formulák, részletesen

Ím a hét buktató megszemélyesítve. Mindegyik esetében kifejtve a legfőbb jellemvonással.

A Kém

A kém épp csak annyi időt tölt a csapat megfigyelésével, amivel fel tudja majd tölteni a következő retrospektívet.

A Sirály

A sirály lecsap a standupok idején, összepiszkítja a csapatot (jószándékú megjegyzésekkel és tanácsokkal) majd tovább repül.

A Véleménygyilkos

A véleménygyilkos véleményt nyilvánít a csapatmegbeszéléseken, de oly módon, hogy úgy ragaszkodik a saját véleményéhez (vagy egy kiemelt személy véleményéhez), hogy azzal megöli a lehetőségét, hogy a csapat hatékony és magasan eredményes megbeszélést tarthasson.

Az Admin

Az admin azzal ássa alá a csapat önvezérlését, hogy felesleges közvetítővé (és más, adminisztrátor jellegű feladatokat ellátó személlyé) válik a megbeszélések szervezésében, a csapat-kérések teljesítésében.

A Hub

A hub (csomópont) úgy viselkedik, mintha ő lenne az univerzum közepe, már legalábbis ami a csapattagok közti kommunikációt és a közvetlen feladatszintű koordinációt illeti.

A Pillangó

A pillangó csapatról csapatra száll, épp csak addig telepszik meg, amíg elejt egy bölcsességet, vagy feltesz egy filozófiai kérdést.

A Profi

A profi olyannyira bevonja magát a csapat munkájába, hogy csak a fákat látja. „Hogy mi? Hogy egy erdőben lennénk? Ez azt jelenti, hogy innen ki is tudnánk keveredni?”


Az összes bukás-módnak ugyanaz az eredménye a csapat szempontjából. Elszívja a csapat képességét, hogy valóban magasan teljesítővé váljanak, mert mind az agilis coach-ot nézik, ő van a reflektorfényben. Amikor a bukás-mód valamelyike bekapcsol, valahogy a coach kerül a csapat munkájának fókuszába. Talán a coach túl lerohanós, mint például a „hub”. Pont ennyire romboló hatású, ha a coach túlzottan visszahúzódó, mint a „pillangó”. Mindegyik esetben a coach kerül a középpontba, és az a legrosszabb hely, ahol a coach lehet.

Mi a forrásuk?

Az egó, vagy a folytonosan megosztott figyelem, vagy mindkettő együtt. Bármilyen kombináció lehetséges, amikor egy coach a bukás-mód szorításában vergődik.

Az egó normális dolog, nem?
Természetesen az. Az egó az, ahol az értékítélet, intellektus, tervezés, érzékelés és valóságfelfogás mind összefut. Az tesz alkalmassá, hogy a kockázatokat vállalva megoszd mindenkivel az elképzeléseidet. Teljesen normális és szükséges dolog. Ugyanakkor az egó „én” centrikus. ÉN mit gondolok? NEKEM milyen ötleteim vannak amik segítenek? Mit fognak az emberek gondolni RÓLAM? Ez az „én” gondolkodás azonban könnyen túlzásokba eshet, egy csapat coach-olása folyamán. Miért nem értik amit ÉN értek? Mit fogok ÉN csinálni, ha nem jól csinálják, amit kellene? Mit fognak az emberek gondolni az ÉN csapatomról? Mit fognak az emberek mondani RÓLAM, mint az ő coach-ukról?

Ami e mögött az „én” gondolkodás mögött van, az a félelem. Félelem attól, hogy a csapat nem fogja tudni a helyes utat, amin elinduljon. Félelem attól, hogy nem lesznek elég jók, abban amit csinálnak, és ez rossz fényt fog vetni a coach-ra. A probléma ezzel a körrel az, hogy a félelem félelmet szül egy olyan öngerjesztő folyamatban, aminek eredményeként a coach nem hagy elég teret a csapatnak, hogy maga tapasztalja meg, mi fog történni, mit tudnának magukból kihozni, és milyen szintre is tudnának fejlődni igazán. A „hub”, az „admin”, a „vélemyénygyilkos”, és a „profi” itt lép be a képbe. Ezek a bukás-módok annak eszközei, amikor a coach úgy akar belefolyni a folyamatokba, hogy biztosítani akarja, hogy a csapat nem tér le a kijelölt ösvényről. A probléma ezzel az, hogy ez egyben annak lehetőségét is kizárja, hogy a csapat valami egészen rendkívülivel rukkolhasson elő.

A multitasking rendben van, ugye?
Nos, nem igazán. A multitasking, és annak közeli rokona, a megosztott figyelem, alapjában véve új dolgok, és az emberi idegrendszer nem igazán erre van építve. Valószínűleg mindannyiunk jól ismerjük a multitasking intézményét – több dolgot csinál az ember egyszerre, melyből általában az egyik olyan egyszerű, hogy szimplán auto-pilot módban elkészül. A folyamatos részleges figyelem egy elég új fogalom ebben a témában, de több mint valószínű, hogy az sem új számunkra. Ilyen: „gyorsan válaszolok erre az e-mailre, amíg elmondod nekem a problémádat, és közben megnézem a Blackberry-met, mert épp rámciripelt. Most ismételd el kérlek még egyszer, hogy miről is akartál velem beszélni?” Olyan mint a multitasking, de van benne egy csavar – az az érzés, hogy az ember bekapcsolva lehet 24/7-ben, folyamatosan azt figyelve, hogy ki, vagy mi követeli leghamarabb ismét a figyelmet.

A folyamatosan osztott figyelem akkor jelentkezik, amikor a coach egyszerre több csapattal foglalkozik, ami egy elég hétköznapi jelenség. Ez könnyen a „pillangó”, a „kém”, vagy a „sirály” bukás-módok bekapcsolásához vezet. Ezek annak a megoldásnak a különböző megjelenései, amikor valaki jelenléte épp arra elég, hogy azt éreztesse, mintha coach-olna, miközben valójában alig van ott.

A helyzet a  valóságban az, hogy a coachok az idejük egy jelentős részét várakozással töltik. A csapattal kell lenni, figyelni kell a történéseket, és várni kell. De mire? Értékes, tanításra használható pillanatokra.

Tanításra használható pillanatok: „azok a kiemelhető átalakítási események, állapotok, amikor maximális a fogadóképesség arra, hogy a csapat új ismereteket sajátítson el." Ezek azok a pillanatok melyekben kikristályosodik egy-egy agilis alapelv, melyet készpénzre lehet váltani. Képes a csapatot egy olyan újabb szintre emelni az agilis módszertan megértésében és alkalmazásában, mely egy kiemelkedő termék elkészültéhez vezet. Ezek az úgynevezett "aha!" pillanatok, mindent egyesítenek és megalapozzák egy magasan teljesítő csapat kialakulását.

Habár a tanításra legalkalmasabb pillanatok általában egyes tipikus átalakulási ponton megjelennek az egyének szintjén is, -mint pl. elhelyezkedés egy új munkahelyen- minden bizonytalan abban a pillanatban, hogy csapatokkal foglalkozunk. Egy agilis csapat kontextusában, a tanításra alkalmas pillanatok rendszertelenül és váratlanul jelentkeznek. Ezeket nem lehet kikényszeríteni és nem tudható, hogy mikor jönnek velünk szembe. A várakozás improduktívnak tűnhet, de ha nem áll a coach rendelkezésére elegendő idő ahhoz, hogy „csak legyen” a csapattal, ezen pillanatok könnyen észrevétlenek maradnak, vele együtt a lehetőség a kiemelt tanításra. Ha ezek a tanításra kiemelt pillanatok elvesznek, annak eredménye az, hogy a csapat útja egy kimagaslóan teljesítő team felé jelentősen meghosszabbodik.

Mit tehet az agilis coach?
Van egy „visszaállító-mód” – egy mód, hogy elkerüljük vagy legalábbis kikeveredjünk a bukás-módból. A visszaállító-mód lényege, hogy a félelmeket bizalommal kell helyettesíteni. Fontos, hogy itt ismét kiemeljük: a félelmeket bizalomra kell cserélni. Bízni kell abban, hogy a csapat tényleg tudja a megfelelő tennivalókat, még akkor is, ha különbözik attól, amit te csináltatnál velük. Bízni kell abban, hogy visszapattannak a zsákutcákból, vagy olyan megközelítésekből, melyek sehova sem vezetnek, úgyhogy nem neked kell őket megkímélni ezektől az esetleges csalódásoktól. Bízni kell abban, hogy kihozzák magukból a legjobbat, hogy örömet okozzanak a vevőiknek, és természetesen nekünk. Végül bízni kell abban, hogy ha elbuknak, abból tanulnak és ez által csak még jobbak lesznek.

Nem kis diadal kivívni ezt a bizalmat. Ez egy hatalmas munka, de legalább annyira hatalmas a jutalom is. Egy elegáns mellékhatása ennek a fajta bizalomnak a következő: ahhoz, hogy a bizalom működjön, a teljes figyelmünket fel kell ajánlanunk. Hogy helyet adjunk a bizalomnak, pontosan figyelnünk kell, hogy mi folyik a csapatban és hogy mi „akar folyni”.


bizalom + figyelem = Jó Coaching  (de legalábbis az alapja annak, ami lehetővé teszi a jó coachingot).

 

Bár nincs egy kiemelt helyes út, hogy elérjük a fent leírt bizalmat, álljon itt pár tipp, amivel érdemes megpróbálkoznunk: legyünk figyelmesek és gondosak, legyünk kíváncsiak, könnyedek és érzékenyek a másik felé. Ezek jól összedolgoznak, de önmagukban is megállják a helyüket.


Figyelmes és gondos
Bármi, amit azért teszünk, hogy figyelmesek és gondosak legyünk egyből segít elkerülni a bukás-módokat. Miközben így teszünk, megtanulhatjuk hogyan legyünk folyamatosan elérhető a csapatnak, és ez növelni fogja az öntudatosságunkat is. A jelenlét és az öntudatosság két hatékony eszköz, hogy tudjuk, mikor érkezik meg egy bukás-mód, és hogy korrigáljuk az eddigi munkát és kikerüljük azt. Bármely könyv John Kabat-Zinn-től jó a figyelmesség és gondosság megtanulásának elkezdéséhez.

A figyelmesség és a gondosság a fejben szóló zajok elhallgattatásával egyenlő. A zaj lehet például az aggodalom, hogy vajon mi lesz a következő dolog, amit a csapat tenni fog; ítélet arról, hogy a PO túlzottan irányító; bosszankodás, hogy egy csapattag nem igazán vesz részt; lelkesedés, hogy a csapat épp most fejezett be egy új terméket; és rengeteg más hasonló gondolat. Ezek a gondolatok mind ott vannak, és folyamatosan megpróbálják átkönyökölni magukat a belső védelmi vonalakon, hogy a figyelem középpontjába kerüljenek. Ezek ráadásul hangosak és elterelik a figyelmemet arról, amit coachként kéne tenni: ráhangolódni, hogy mi is van a csapattal éppen most. Nem arra, hogy mi történt a múltban, nem azon aggodalmaimra, hogy mi fog történni a jövőben, hanem arra, mi is történik a jelen pillanatban. Épp ezért azonosítják sokszor a figyelmességet és gondosságot a „jelenléttel”. Amikor jelen vagyunk, képesek vagyunk érzékelni, hogy mi is történik a csapattal, és tudunk segíteni nekik a következő lépésben, hogy konstruktívan a pozitív irányba fejlődjenek. Visszatekintve gyakran azt látom, hogy az ösvény, amin elindult a team tökéletes volt, és egyben teljesen más is, mint amit én javasoltam volna, ha az aggodalom, ítélet, bosszankodás, lelkesedés vezéreltek volna.

Légy kíváncsi
Amikor megfigyelünk egy csapatot munka közben, legyünk mindig érdeklődők, hogy mi is történik valójában. Olyan kérdéseket tegyünk fel magunknak mint pl.: Mi akar itt történni? Hova akarnak eljutni ezzel? Mi lehetne nekik hasznos ebben? Ezután figyeljük tovább a történéseket. Adjunk magunknak időt, hogy átlássuk mi is folyik ott valójában és tiszta képet kapjunk a csapatról – egy olyan képet, amit nem befolyásolnak az ítéleteink és feltevéseink. Ezután vegyük szemügyre, hogy velünk mi történik. Milyen bukás-mód vár ránk a sarkon? Mit érzünk? A félelem motivál esetleg? Hol tart a bizalom? Hol jár a figyelmünk? És ekkor, amikor tisztán látjuk a csapatot, pontosan értjük, hogy mi zajlik bennünk, elkezdhetünk gondolkodni azon, miként coach-oljuk őket.

Csak könnyedén
Lehet, hogy annak felismerése, hogy épp valamilyen bukás-módban vagyunk elegendő lehet számunkra az adott pillanatban.
Elképzelhető, hogy az, ha tudomásunkra jut amikor bukás-módba kapcsolunk már egy nagy előrelépés lehet. Haladjunk ebbe az irányba, és legyünk tisztában ezzel. Természetesen támaszkodhatunk az idő által csiszolt relexeinkre is ha stresszhelyzetbe kerülünk. A trükk az, hogy legyünk tisztában azzal, hogy a stressz alatti működés nem kell, hogy a mindennapi rendes működéssé váljon. És ekkor, még ha stressz alatt is vagyunk, képesek leszünk elkerülni a bukás-módokat.


Párban
Párban dolgozni a coach-oknak is hasznos. Talán éppenséggel alapvető is. Neveljünk ki egy csoportnyi kollégát, akikhez fordulhatunk, ha úgy érzzük, hogy bukás-mód fenyeget. Ezek az emberek együtt éreznek velünk, és emlékeztetnek: a te célod egy kimagasló teljesítményt, önellenőrzést és önszabályozást alkalmazó csapat létrehozása. Ezzel a felfrissített céllal ellenőrzés alá vonhatjuk az egót, összpontosíthatjuk a figyelmet, és felkészülhetünk, hogy a bizalom pozíciójából coach-olhassunk.

Forrás  fordította Tornai Balázs, válogatta Kulcsár Bence

Szólj hozzá!

Az agilis szervezetek jellemzői

2011.12.17. 12:18  kulcsár bence

Jim Collins a csapata 5 éves kutatási eredményeit elemzi híres könyvében -„Good to Great”-, melynek témája: miként alakítsunk egy már jó céget kimagasló céggé. Vajon az agilis módszertanok segítenek ebben?

Jean Tabaka előállt egy 10-es listával az agilis szervezetek legfőbb jellemzőiről. Ez a lista rávilágít, hogy mi kell bármely cégnek a fent leírt minőségi ugráshoz.

  • Munka / Magánélet egyensúlya és folyamatos teljesítmény – Bátorítsd és támogasd azokat a csapatokat, melyek egyszerre propagálják a személyes és szervezeti célokat. Alkalmazz rövidebb szállítási periódusokat.
  • A szolgáló vezető – A teljes menedzsmentnek el kell sajátítania miként tud szolgálva vezetni és miként fog a vezetés szolgálni. Ahelyett, hogy felülről erőltetnénk döntéseket a csapatra, a vezetőknek támogatást kell nyújtaniuk a teamek felé, hogy végigvihessék a saját maguk által vállaltakat.
  • Fenntartható és sikeres teljesítmény – Át kell állni egy stabilan tartható tempóra. A teljes szervezetnek egy fő fókusza kell legyen: a vevői érték (amiért örömmel és megelégedéssel fizet).
  • A közösséghez való hozzájárulás, és egy profitabilis cég fenntartása – A profitabilitáson és a fő tevékenyégen túl a közvetlen közösségre gyakorolt jó benyomás is a figyelmünk középpontjában kell legyen.
  • Egymással együttműködő okos alkalmazottak – intelligens embereket alkalmazz és támogasd az együttműködést. Ez elősegíti mindenki egyéni fejlődését.
  • Bottom-up és top-down döntési modellek – el kell érni, hogy a vezetőket az információ közvetlen birtokosai tájékoztassák és fordítva. A tacit tudás segíti az explicit tudás kialakulását.
  • Személyes rugalmasság és ritmus – hozd létre a folyamatos értékszállítás körforgását.
  • Minőség és sebesség – a teljes szervezet az értékek létrehozására és a gyors visszajelzések fogadására-feldolgozására kell koncentráljon.
  • Saját valóság és vízió – ahelyett, hogy egy szervezetet kőbe vésett szabályok mentén terelnénk a vízió megvalósítása irányába, mint agilis szervezet, olyan egyéneket alkalmazzunk, akik a személyes kisugárzásuk révén mutatnak irányt a vízió alakításához és eléréséhez.
  • Elkötelezettség, hogy végigmész a naggyá válás útján – fegyelmezett kultúra és mérőszámok alkalmazása – pl.: munka / magánélet egyensúly, bottom-up és top-down döntéshozás, a szolgáló vezetés megvalósításának fogásai, újítások alkalmazása, a technikai hiányosságok követése és ledolgozása. Mindezek segítenek annak feltárásában, hogy a cég vajon a jó úton jár-e, hogy elérje: a jóból nagyszerű legyen.


Hasonlóképp, Mike Beedle a következő karakterisztikákat emelte ki:

  • Megfordított menedzsment piramis
  • Nagyfokú szabadság biztosítása, hogy az egyén saját hatáskörben megoldhassa az előtte álló feladatot
  • Folyamatos tanulás, tudás létrehozása és megosztása
  • Emberibb és szórakoztatóbb munkakörülmények
  • Hiperproduktív, együttműködésen alapuló munkavégzés
  • Dinamizált tervezés, architektúra és követelmények
  • Olyan új értékek meghonosítása, melyek együttműködő(bb) szervezetté kovácsolják a jelenlegit
  • Életminőség


Mike Cottmeyer eredménye az alábbi lista mely több szervezet mintáinak közös metszete. Ezek a minták elengedhetetlenek a sikeres agilis működéshez.

„Vannak bizonyos minták, melyekkel újra és újra találkozok. Ezek a minták megalapozzák az agilis működés sikeres bevezetését, vagy egy nagyszabású szervezeti átalakítást az agilis módszertan jegyében. Íme kigyűjtve a legfontosabbak és velük együtt az, hogy miért is azok.”

  • Keresztkompetenciákkal rendelkező csapat
  • Felhatalmazott csapattagok – a lényeg az üzleti eredmény. Ezen felül minden csapat a maga hatáskörében dönt, azt miként éri el. 
  • Az üzlet korlátozott beleszólása - Az üzletnek kell meghatároznia a prioritásokat és megjelölnie a létrehozandó értékeket a teljes fejlesztői csapatnak. (ezután a többi már a csapat kizárólagos hatásköre)
  • Megosztott felelősség – mindenki felelős az elért üzleti eredmény rá eső részéért.
  • Szolgáló típusú vezetés
  • Folyamatos értékteremtés – biztosítani, hogy a szervezet kiszámítható ütemben szállítson üzleti értéket.
  • Érték a tevékenység felett – minden egyes lépésnek további hozzáadott érték létrehozását kell eredményeznie.
  • Törekvés a technikai tökéletességre – folyamatosan figyelni és csökkenteni kell az felhalmozódó technikai hiányosságokat. Már az első pillanattól be kell építeni a minőség, megbízhatóság és skálázhatóság elveit minden tevékenységbe.
  • Korai visszajelzés és alkalmazkodás
  • Totális nyíltság és átláthatóság – egy valóban agilis szervezetben semmi sem maradhat rejtve. Az ember nem tud elbújni. Az haladást nem lehet elrejteni. A mérőszámokat nem lehet eldugni. Rossz minőséget nem lehet a szőnyeg alá söpörni. A kockázatokat nem lehet figyelmen kívül hagyni. Az akadályokat nem lehet nem észrevenni.
  • Bizalom – olyan környezet és kultúra megteremtése, ahol az emberek megbíznak egymásban.


A fentiek alapján könnyen belátható, hogy a leghangsúlyosabb elemek: támogatás, kommunikáció és együttműködés. Mindennek kulcsa a bizalmon alapuló légkör, a folyamatos tudásfejlesztés és fenntartható tempójú értékteremtés.

Forrás  fordította Tornai Balázs, válogatta Kulcsár Bence

Szólj hozzá!

Scrum Master ellenőrzőlista

2011.12.06. 11:41  kulcsár bence

Oka van annak, hogy amikor két pilóta elfoglalja a helyét a repülőn, minden alkalommal lépésről lépésre végigmennek egy ellenőrzőlistán. Ez az ok, pedig az, hogy az Ellenőrzőlisták Működnek. Az ellenőrzőlista pedig még egy olyan tökéletes ScrumMaster számára is hasznos lehet, aki az összes scrum master tesztinterjú kérdésre tudja a választ.

Minden nap

  • Látható a feladat-tábla (information radiator)?
  • Teljes user story-k és hozzájuk tartozó feladatok vannak rajta?
  • Tudja a megbízó, ha a táblára néz, hogy mit vállalt a csapat?
  • Tegnap óta lett frissítve?
  • Van rajta „ön itt áll” státuszjelzés?
  • Láthatóak rajta a user story-k, melyek a végső elfogadásra várnak?
  • Fent van a burndown chart?
  • Az frissítve lett tegnap óta?
  • Az optimális sávban van?
  • Fent van a release-plan?
  • Ha ránézel a táblára, tudod, hogy mi várható a következő iterációban?
  • Akadálytalanítva lett a lehető tegtöbb user story a következő iterációból?
  • Volt napi stand-up?
  • Látható a következő demó dátuma? Biztos, hogy mindenki részt vesz rajta, akinek kell?
  • Fent vannak a PO elérhetőségei és neve?
  • Bízik a csapat abban, amit készít? Miért?

Minden sprintben

  • Vannak előre látható buktatók, a normális szintet többszörösen meghaladó kockázati tényezők a release tervben?
  • A teljes megbízói csapat látta (és elfogadta) a release tervet? Van úgynevezett csendes megbízó (aki vagy távolmaradásával, vagy a hallottak, látottak feltétlen elfogadásával jelent kockázatot)?
  • Az összes megbízó képviselője tisztában van a velocity-vel? És Te?
  • Kifizették ezt az iterációt?
  • Készült egy e-mail, ami tartalmazza listaszerűen a teljestett iteráció leírását, az elkészült és elfogadott user story-kat, a velocity-t, a kockázatokat és a projekt scope-ot?


Forrás  fordította Tornai Balázs, válogatta Kulcsár Bence

Szólj hozzá!

ScrumMaster 10 perc alatt

2011.11.29. 13:45  kulcsár bence

Talan egy kissé túloz a cím, de Hamid Shoajee videója tényleg 10 perc alatt foglalja össze miről is szól a scrum. Kezdőknek és érdeklődőknek ideális bevezető, gondolatébresztő.

Szólj hozzá!

Ki alkalmas UserStory írásra?

2011.11.28. 12:59  kulcsár bence

Az, aki a megfelelő üzleti értéssel, tudással rendelkezik, alkalmas arra, hogy UserStory-t írjon. Ez a személy többnyire olyan valaki, aki elég közel van az üzlethez.

Feltételezhető, hogy minden scrum team tag tudja, hogyan kell UserStory-t írni.

Ron Jefferies’s Circle of Life, cikkére reflektálva egy UserStory készítésnek 3 kulcseleme van: Kártya, Párbeszéd és Megerősítés. (3C, Card, Conversation, Confirmation)


Párbeszéd kulcselem.

Így zajlik egy tipikus „UserStory író” párbeszéd:

  1. A Product Owner(PO) vagy a Business Analyst leírja a UserStory-t egy kártyalapra.
  2. A kártyát az asztalon hagyják, és behívják az érdekelt csapatot (fejlesztők, tesztelők stb.) a Párbeszédre.
  3. A csapat kérdéseket tesz fel, hogy megértsék a UserStory-t. Ezek alapján a BA és a PO feljegyzi a módosításokat. Ettől függetlenül bármely jelenlévő felveheti a kártyát és rávezetheti a szükségesnek ítélt változtatásokat.
  4. Amennyiben a párbeszéd technikai UserStory-k miatt megakad, bevonják az érintett technikai probléma szakembereit (DB admin, architect stb.) is.
  5. A Product Owner dönt végül a UserStory-ról.


A projekt méretétől függően dedikált emberek (tipikusan BA-k) felelőssége a UserStory-k megírása. Kisebb projektek esetén közvetlenül a Product Owner is írhatja a UserStory-t.

Forrás  fordította Tornai Balázs, válogatta Kulcsár Bence

Szólj hozzá!

Top 100 Agile Books '11

2011.08.25. 13:27  kulcsár bence

Jurgen Appelo idén is előállította az Amazon eladási statisztikái alapján a legjobban fogyott agilis szakirodalmak listáját. Külön jó érzés, hogy e lista alakításában én is aktívan részt vettem -már ami vásárlás oldalát illeti. Érdekesség, hogy maga a szerző az idei év egyik legígéretesebb könyvét dobta piacra, Management 3.0 címmel. 45. pozíciója remekül indikálja, hogy a zseniális gondolkodók radikalitásuk miatt nem válhatnak best seller-ré. Külön respekt Mike Cohn-nak, aki az első 11-ben rögtön 3 könyvet tudhat magáénak.

TY: This Year, LY: Last Year.

TY LY Title Author(s) Year
1 5 The Art of Unit Testing: With Examples in .Net Roy Osherove 2009
2 1 Agile Estimating and Planning Mike Cohn 2005
3 3 Working Effectively with Legacy Code Michael Feathers 2004
4 8 Kanban: Successful Evolutionary Change for Your Technology Business David J. Anderson 2010
5 9 Succeeding with Agile: Software Development Using Scrum Mike Cohn 2009
6 2 Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin 2008
7 6 Agile Software Development, Principles, Patterns, and Practices Robert C. Martin 2002
8 4 Refactoring: Improving the Design of Existing Code Martin Fowler, et al. 1999
9 - The Agile Samurai: How Agile Masters Deliver Great Software Jonathan Rasmusson 2010
10 7 The Pragmatic Programmer: From Journeyman to Master Andrew Hunt, David Thomas 1999
11 11 User Stories Applied: For Agile Software Development Mike Cohn 2004
12 10 Growing Object-Oriented Software, Guided by Tests Steve Freeman, Nat Pryce 2009
13 32 The Principles of Product Development Flow: Second Generation Lean Product Development Donald G. Reinertsen 2009
14 14 The Art of Agile Development James Shore, Shane Warden 2007
15 23 Scrum and XP from the Trenches Henrik Kniberg 2007
16 12 Lean Software Development: An Agile Toolkit Mary Poppendieck, Tom Poppendieck 2003
17 13 Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans 2003
18 16 Agile Principles, Patterns, and Practices in C# Robert C. Martin, Micah Martin 2006
19 17 Agile Testing: A Practical Guide for Testers and Agile Teams Lisa Crispin, Janet Gregory 2009
20 24 Implementing Lean Software Development: From Concept to Cash Mary Poppendieck, Tom Poppendieck 2006
21 18 Practices of an Agile Developer: Working in the Real World Venkat Subramaniam, Andy Hunt 2005
22 15 Making Things Happen: Mastering Project Management Scott Berkun 2008
23 57 Beautiful Testing: Leading Professionals Reveal How They Improve Software Adam Goucher, Tim Riley 2009
24 19 Behind Closed Doors: Secrets of Great Management Johanna Rothman, Esther Derby 2005
25 34 Crystal Clear: A Human-Powered Methodology for Small Teams Alistair Cockburn 2004
26 28 Agile Coaching Rachel Davies, Liz Sedley 2009
27 20 Applied Software Project Management Andrew Stellman, Jennifer Greene 2005
28 21 Agile Project Management: Creating Innovative Products (2nd Edition) Jim Highsmith 2009
29 22 xUnit Test Patterns: Refactoring Test Code Gerard Meszaros 2007
30 31 Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects Johanna Rothman 2009
31 26 Writing Effective Use Cases Alistair Cockburn 2000
32 - Specification by Example: How Successful Teams Deliver the Right Software Gojko Adzic 2011
33 41 Managing the Design Factory Donald G. Reinertsen 1997
34 - The Clean Coder Robert C. Martin 2011
35 29 Agile Retrospectives: Making Good Teams Great Esther Derby, Diana Larsen 2006
36 39 Agile Project Management with Scrum Ken Schwaber 2004
37 30 Agile Adoption Patterns: A Roadmap to Organizational Succes Amr Elssamadisy 2008
38 27 Refactoring to Patterns Joshua Kerievsky 2004
39 40 Extreme Programming Explained: Embrace Change (1st+2nd Edition) Kent Beck, Cynthia Andres 1999
40 37 The Productive Programmer Neal Ford 2008
41 60 Agile Product Management with Scrum: Creating Products that Customers Love Roman Pichler 2010
42 25 Agile and Iterative Development: A Manager's Guide Craig Larman 2003
43 68 Stand Back and Deliver: Accelerating Business Agility Pollyanna Pixton, Niel Nickolaisen, Todd Little, Kent McDonald 2009
44 - The Elements of Scrum Chris Sims, Hillary Louise Johnson 2011
45 - Management 3.0: Leading Agile Developers, Developing Agile Leaders Jurgen Appelo 2011
46 47 Test Driven Development: By Example Kent Beck 2002
47 36 Agile Software Development with Scrum Ken Schwaber, Mike Beedle 2001
48 - The Concise Executive Guide to Agile Israel Gat 2010
49 48 Continuous Integration: Improving Software Quality and Reducing Risk Paul M. Duvall, Steve Matyas, Andrew Glover 2007
50 - Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Jez Humble, David Farley 2010
51 35 Requirements by Collaboration Ellen Gottesdiener 2002
52 42 Manage It!: Your Guide to Modern, Pragmatic Project Management Johanna Rothman 2007
53 45 Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum Craig Larman, Bas Vodde 2008
54 38 Organizational Patterns of Agile Software Development James O. Coplien, Neil B. Harrison 2004
55 43 Leading Lean Software Development: Results Are not the Point Mary Poppendieck, Tom Poppendieck 2009
56 51 Ship it! A Practical Guide to Successful Software Projects Jared Richardson, William A. Gwaltney 2005
57 86 Kanban and Scrum - Making the Most of Both Henrik Kniberg, Mattias Skarin 2010
58 71 Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition Lyssa Adkins 2010
59 49 Collaboration Explained: Facilitation Skills for Software Project Leaders Jean Tabaka 2006
60 55 Beyond Software Architecture: Creating and Sustaining Winning Solutions Luke Hohmann 2003
61 50 Changing Software Development: Learning to Become Agile Allan Kelly 2008
62 80 Innovation Games: Creating Breakthrough Products Through Collaborative Play Luke Hohmann 2006
63 70 Just Enough Requirements Management: Where Software Development Meets Marketing Alan Mark Davis 2005
64 52 Agility and Discipline Made Easy: Practices from OpenUP and RUP Per Kroll, Bruce MacIsaac 2006
65 61 Implementation Patterns Kent Beck 2006
66 62 Extreme Programming Installed Ron Jeffries, Ann Anderson, Chet Hendrickson 2000
67 56 Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders Andrew Stellman, Jennifer Greene 2009
68 53 Refactoring Databases: Evolutionary Database Design Scott W. Ambler, Pramodkumar J. Sadalage 2006
69 88 Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing Gojko Adzic 2009
70 58 Managing Agile Projects Sanjiv Augustine 2005
71 46 Agile Software Development: The Cooperative Game (2nd Edition) Alistair Cockburn 2006
72 81 Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results David J. Anderson 2003
73 73 Becoming Agile: ...in an Imperfect World Greg Smith, Ahmed Sidky 2008
74 66 Emergent Design: The Evolutionary Nature of Professional Software Development Scott L. Bain 2008
75 75 Test Driven: TDD and Acceptance TDD for Java Developers Lasse Koskela 2007
76 83 The Software Project Manager's Bridge to Agility Michele Sliger, Stacia Broderick 2008
77 - Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration Ken Pugh 2011
78 63 Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams Greg Cohen 2010
79 54 Managing Agile Projects Kevin J. Aguanno 2005
80 69 A Tale of Two Systems: Lean and Agile Software Development for Business Leaders Michael K. Levine 2009
81 67 Fearless Change: Patterns for Introducing New Ideas Mary Lynn Manns, Linda Rising 2004
82 64 Balancing Agility and Discipline: A Guide for the Perplexed Barry Boehm, Richard Turner 2003
83 79 Patterns of Agile Practice Adoption Amr Elssamadisy 2007
84 - Lean Architecture: for Agile Software Development James O. Coplien, Gertrud Bjørnvig 2010
85 59 Lean-Agile Software Development: Achieving Enterprise Agility Alan Shalloway, Guy Beaver, James R. Trott 2009
86 84 Business Agility: Sustainable Prosperity in a Relentlessly Competitive World Michael H. Hugos 2009
87 - Just Enough Software Architecture: A Risk-Driven Approach George H. Fairbanks 2010
88 78 Principles of Software Development Leadership: Applying Project Management Principles to Agile Software Development Ken Whitaker 2009
89 77 A Practical Guide to Distributed Scrum Elizabeth Woodward, Steffan Surdek, Matthew Ganis 2010
90 76 The Business Value of Agile Software Methods: Maximizing Roi With Just-in-time Processes and Documentation David F. Rico, Hasan H. Sayani, Saya Sone 2009
91 - Personal Kanban: Mapping Work | Navigating Life Jim Benson, Tonianne DeMaria Barry 2011
92 74 Agile Game Development with Scrum Clinton Keith 2010
93 - Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise Dean Leffingwell 2010
94 85 The Enterprise Unified Process: Extending the Rational Unified Process Scott W. Ambler, John Nalbone, Michael J. Vizdos 2005
95 - Managing Software Debt: Building for Inevitable Change Chris Sterling 2010
96 82 Project Management the Agile Way: Making It Work in the Enterprise John C. Goodpasture 2009
97 - Agile Software Development with Distributed Teams Jutta Eckstein 2010
98 - SDLC 3.0: Beyond a Tacit Understanding of Agile Mark Kennaley 2010
99 33 Scaling Software Agility: Best Practices for Large Enterprises Dean Leffingwell 2007
100 95 Test-Driven Development: A Practical Guide David Astels 2003

 

Forrás

Szólj hozzá!

Value Engineering & Scrum

2011.08.01. 13:18  kulcsár bence

A következő kis videó remekül mutatja be miért is fontos az üzleti értékek mentén priorizálni  feladatainkat. Természetesen ez csak folyamatos erőfeszítés és magasfokú tudatosság mentén realizálható. Ennek eredményeképpen -mint az az animációból is kiderül, a veszteségek minimalizálását nyerhetjük, ezzel párhuzamosan pedig az egységnyi erőforrásból előállítható többlet üzleti értéket (más szemszögből pedig az egységnyi üzleti érték előállításának költség-optimalizációját). Az egyébként szórakoztató kisfilmet Leo Lamarca készítette.

Szólj hozzá!

Visual Builds Board

2011.07.19. 11:02  kulcsár bence

Builds Board TV

 

A TargetProcess-nél egy speciális digitális táblát fejlesztettek amelyet "Visual Builds Board"-nak kereszteltek el. Mivel a fejlesztéseiket agilis szempontból a végfelhasználók számára önálló értéket hordozó funkcionalitások mentén valósítják meg, náluk minden egyes UserStory illetve Bug önálló branch-ként értelmezett. Ez azt jelenti, hogy számos build-et kell elkészíteniük, hiszen minden branchet önállóan kell tesztelni. A Visual Builds Board segít átlátni az összes branch státuszát. Ennek alapját egy .NET applikáció nyújtja amely össze van kötve a TargetProcess illetve a Jenkins szoftverekkel.

Zöld: lefutott build-ek, Narancs: éppen futó build-ek, Piros: Hibával leállt buildek.

Builds Status

Builds Status 2

Builds Status In Progress

Builds Status History

Forrás

Szólj hozzá!

'Képtelenség gyorsabban menni, Kapitány!'

2011.06.14. 14:00  kulcsár bence

Sok Scrum team kerül olyan helyzetbe, amikor több nyilvánvaló akadály tűnik fel. Miután megoldották őket, stabilizálódik a helyzet. Ebben a fixált állapotban gyakran hangzik el, hogy elértük a maximális teljesítményt: képtelenség gyorsabban haladni!
 
Mi a gond ezzel szituációval? (a csapat szempontjából)
 
Vizsgáljunk meg néhányat:
 

1., Nem teljesen egyértelmű akadályok

A leggyakrabban számos nem teljesen egyértelmű akadály húzódhat meg a felszín alatt. Lehetnek olyan dolgok, amelyek szimplán elkerülték a figyelmet, vagy éppenséggel elefánt a konyhában típusú probléma is, mint mondjuk egy command&control típusú scrum master. Lehetséges probléma gócpontok:

  • Néhányan azt feltételezik, hogy az összes akadály technikai jellegű
  • Néhányan úgy gondolják, az összes akadályt a csapat számára mindössze a szükséges infrastruktúra felállítása jelenti
  • Néhányan úgy gondolják, az összes akadály a részleges szállításból következő folyamatos integrációból keletkezik
  • Néhányan úgy gondolják, az összes akadály a folyamatok és a fejlesztések egyszerűsítéséből fakad
  • Néhányan pedig úgy, hogy az összes akadályt a menedzserek megszakításai jelentik

 Bármelyik fent említett probléma mellett megjelenhet más aspektus is, akár technikai/architektúrális/kódolási. Pl. mikor éremes újrafejleszetni vagy mikor érdemes fenntartani a meglévő kódot.

2., Akadályok amelyek elmozdíthatatlannak tűnnek

A legtöbb esetben nem foglalkoznak a triviálisan mozdíthatatlannak tűnő akadályok feloldásával. Ilyen esetekben sokszor mégis könnyen feloldhatóvá válik az akadály, pl. egy megfelelő menedzserrel vagy szakértővel való megbeszélést követően.

Egy külső nézőpont és vélemény rengeteget segíthet a csapatnak és nagy mértékben növelheti a teljesítőképességet.

3., Tökéletesek vagyunk

A tökéletessé vagy jóvá - legjobbá válás igénye mélyen gyökerezik az emberi természetben.

A Lean-t alkalmazók azt mondják, ha elértük az előző definíciónkat a tökéletességről, akkor elég bölcssé váltunk ahhoz, hogy egy újabb és pontosabb definíciót alkothassunk a magunk számára amit követhetünk.

Ha megnyerte a csapat a világbajnokságot az előző Sprintben akkor kétségtelenül jobbá vált, így jogos lehet a kérdés: mi a legnagyobb akadály jelenleg?

 

Természetesen sok egyéb probléma is akadályozhatja a teljesítmény növekedését de érdemes ezzel a hárommal kezdeni a vizsgálódást.

Forrás

Szólj hozzá!

Címkék: agile

A UserStory feldarabolás 10 stratégiája

2011.05.10. 18:00  kulcsár bence

A UserStory egy lefejlesztendő rendszer-funkcionalitást, vagy felhasználói igényt jelent. A funkció meghatárazásakor a felhasználói szemléletű leírás (Szerepkör -> Cél) széleskörűen elterjedt az agilis projektekben. "Mint felhasználó, szeretnék egy vonatjegyet foglalni Párizsba"


A UserStory-k meghatározásakor gyakran használják a következő szabályokat:

3C
Card, Conversation, Confirmation


INVEST
Independent, Negotiable, Valuable, Estimable, Small enough, Testable


USERVOICE FORMAT
AS A <User Role>
I CAN <Goal>
SO THAT <Business Value>


Így a UserStory-k eredményorientáltak és felhasználócentrikusak.

Minden UserStory a csapat által kerül becslésre, valamint a ProductOwner által priorizálva, továbbá elég kicsinek kell lennie, hogy egy Sprint alatt szállítani lehessen (általában a legkisebb csapatok is minimum 3 UserStory-t szállítanak egy Sprint-ben). Ez szükségszerű ha vizsgálni szeretnénk az értékszállítás, a láthatóság, a rugalmasság, a visszajelzés  és a folyamatos javítás előnyeit.
Egy coach életében gyakran előfordul, hogy segítenie kell a ProductOwner-nek felosztani a UserStory-kat kisebb egységekre.
Itt olvasható 10 stratégia amely hatékonyan segít nagyon UserStory-k felosztásakor:

1. Egy folyamat lépései

A felhasználó egy jól definiált folyamat meghatározott lépéseit hajtja végre. A nagy UserStory ezen lépések - státuszok mentén van felosztva és lépésenként lefejlesztve. Minden lépésnek saját UserStory-ja lesz.

2. Forgatókönyv

Egy forgatókönyv mentén történik a feldarabolás. Az egyik UserStory lehet a sikeres bejárási út, a többi pedig az alternatív bejárások:
Ha x történik, akkor…
Ha .., akkor

3. Forgatókönyv szekvenciája

Sokkal precízebb, ha a UserStory-kat a forgatókönyv specifikus lépéseinek szekvenciája mellet osztjuk fel.

4. Műveletek

A UserStroy-k feldarabolásának egyik legkézenfekvőbb és leggyakoribb módja ha műveletek mentén osztják szét. A CRUD (Create, Retrieve, Update, Delete) funkcionális dekompozícionálás jó példa lehet. Természetesen ezekből csoportokat is lehet képezni (pl. két részre bontva) ha az megfelelőbb.

5. Az adatméret vagy adattípus

Szintén gyakori eset. A nagy UserStory a használt objektumok kezelése mentén lesz felbontva (pl. különböző account type, vagy language message)

6. Input, Output típus vagy Konfiguráció

Adat és adattípus variációk konfigurációk függvényében vagy akár UserInterface esetek konfigurációként értelmezve szintén segíthetnek nagyobb UserStory-k felosztásában.

7. Felhasználó típus vagy szerepkör

A UserStory felosztást a terméket használók személye vagy betöltött szerepköre mentén is elvégezhetjük. Ha a UserVoice formátumot használtuk a Story-k meghatározásánál akkor kézenfekvő és egyszerű lehet ez a fajta megközelítés. Másfelől segíthet a bonyolult UserStory-k vizualizálásában.

8. Ismeret szintje

A szétdarabolás elengedhetetlen feltétele a funkcionalitás mély ismerete. Szétbontható egy nagyobb UserStory jól ismert és ismeretlen részekre. A kevéssé ismert UserStoryk-ra értelemszerűen spike-okat lehet indítani, azaz olyan timebox-olt rövid iterációt, amelynek az outputja a vizsgált ismeretlen időbeli megbecslése.

9. Komplexitás szintje

Például egy UserStrory-t a legegyszerűbb legelemibb funkcióra bontjuk, a többi peddig ettől komplexebb vagy többrészlettel bíró darabba.

10. Minőségi szintek

Teljesítmény, biztonság, használhatóság ezek a nem funkcionális követelmények gyakran hangzanak el egy specifikus UserStory-val kapcsolatban. Ezek az elégedettség fokmérői de ugyanakkor segíthenek a UserStory felbontásban is (pl. 60 másodpercen belül jelenjen meg a képernyőn, kevesebb mint 30 másodpercen benül jelenjen meg a képrenyőn, valós időben jelenjen meg a képernyőn).
 

4 komment

Scrum pilot - hogyan?

2011.04.13. 14:51  kulcsár bence

"Melyik projekt a legalkalmasabb Scrum pilot-nak?" Sokszor hangzik el ez a kérdés különböző workshop-okon és tréningeken. Habár fontos, hogy a szervezeti körülményekkel összhangban tervezzünk meg egy specifikus bevezetést, a következő 6 kritérium további segítséget nyújthat a megfelelő agilis pilot projekt sikeres kiválasztásához:

1., Kis méret

A kiválasztott pilot projektnek kis méretűnek kívánatos lennie, maximum 2-3 csapatnyi emberrel. Nagyméretű agilis fejlesztések további kihívásokat rejtenek és futtatásuk extra gyakorlatot igényel. 

2., Fontosság

Bizonyosnak kell lenni, hogy a kiválasztott projekt fontos a szervezet számára. Másként a szekptikusok leértékelik a projektet és aláaknázhatják a scrum szevezeten belüli kiterjesztését. Ugyanakkor óvakodni kell a küldetés-kritikus pilot projektektől is, mert az agilis projekt bevezetésének erőforrásigénye súlyosan kihathat az egész szervezet üzleti teljesítményére. Az agilis szoftverfejlesztés sok szervezet számára bomlasztólag ható folyamat innovációt jelent: megkívánja a képességet a kísérletezésre, a hibázásra és az ezekből való tanulásra.

3., Függetlenség

Válasszunk olyan projektet amelynek csak néhány kapcsolódási pontja van más csapatokhoz. A több kapcsolódó csapattal vagy projekttel való koordináció megnöveli a komplexitás szintjét, továbbá nehézzé teszi az agilis vezérelvek követését. Különösen igaz ez, ha a kapcsolódó projektek eltérő szoftverfejlesztési folyamatot követnek. Ha csak nagy komplex projektek közül választhatunk, akkor valamilyen kevés függőséggel bíró részprojektet próbáljunk keresni az agiltás beveztéséhez.

4., Közös elhelyezés

Közös elhelyezésű (lokális) projektet érdemes agilis bevezetéshez választani és óvakodni az elosztottaktól. Utóbbiak a hatékony együttműködést sokkal nehezebbé teszik, valamint további tapasztalatokat és eszközöket igényelnek. Disztributált projektek esetében a közös felhasználói történet írás, a pair-programozás, és a hatékony sprint retrospective meeting-ek egyértelműen nagyobb kihívást jelentenek.

5., Kizárólag szofver

Az agilis bevezetést először korlátozzuk szoftver projektre. Ezzel csökkenthetjük azt az összetettséget amit a hardver vagy a gépipari terület adna hozzá a projekthez. Az agilis szoftverfejlesztési módszerek és praktikák könnyen és jól érthetőek, ami a hardver és a gépipari mérnöki folyamatokra csak kisebb mértékben igaz.

6., Új termék fejlesztése

Érdemes olyan projektet választani ahol nem meglévő hanem új terméket fejlesztenek. Ezzel lehetővé válik megtapasztalni, hogy miként válik egy ötlet árucikké az agilis folyamatok által. Segít eloszlatni a félelmeket a legacy code base, illetve a tesztelés felől. Továbbá, a scrum különösen alkalmas arra, hogy megbirkózzanak a bizonytalansági, az innovációs, és a kockázati tényezőkkel, amelyek fontos jellemzői az új termékek kifejlesztésének.

Mielőtt a pilot projekt kiválasztásra kerül érdemes megfontolni a következő kérdéseket:

Végig van-e gondolva miért lesz kipróbálva a scrum módszer és milyen elvárások állnak ezzel szemben?

Még akkor is, ha csak hype vezérelte kíváncsiságról beszélhetünk?

 

 Forrás

Szólj hozzá!

Az agilis csapat építése

2011.04.13. 10:00  kulcsár bence

Bevezetés

Egy agilis szoftverfejlesztő csapat felépítése nem olyan könnyű dolog mint amilyennek tűnik. Sok menedzser és csapatvezető felkér pár technikaliag képzett fejlesztőt, ad pár útmutatást az agilis folyamatokról és reménykedik benne, hogy minden olyan jól működik majd mint a szakirodalomban. Ez a felfogás nem csak irreális de hajlamos a bukásra is.

Egy sikeres agilis csapat összetevői

Egy sikeres agilis szoftverfejlesztő csapat tapasztalt fejlesztőkből áll, csapatértékeken alapszik, jó kommunikáció jellemzi és mindig a fejlődést tartja szem előtt. Bár a siker szempontjából nem minden egyes összetevő teljesen kritikus, az összes rendelkezésre állása esetén jelentősen lerövidül a sikerig vezető út.

Vezérelvek

Mindenkinek van elképzelése arról, hogy milyen kultúrát kíván megalapozni a csapatában. Ha csak a menedzser nem kér fel olyanokat akiket nagyon jól ismer, egy kultúrális víziót gyakorlattá fordítani nagyon nehéz feladat. Korán felismerhető, hogy azok a tulajdonságok amelyek nélkülözhetetlenül fontosak: a megbízó fejével gondolkodás, a hatékony együttműködési készség, a tényeken alapuló döntéshozatal és menedzsment, valamint a teljesítés orientáltság. Az a csapat amelyik megtestesíti az előző tulajdonságokat könyebben válhat sikeressé. Ezen csapat tagjai pedig számos előnyös viselkedésmintát mutathatnak fel: közvetlen kérdések a megrendelő felé, megrendelő fejével való gondolkozás, segítség kérés, segítség nyújtás, konkrét tényeken alapuló döntéshozatal személyes vélemény helyett, befejezett és teljes kód leszállítására való törekvés.     

Hatékony kommunikáció

A hatékony kommunikácó kritikus a siker szempontjából. Az egyik leghatékonyabb módja a kommunikációnak a szemtől-szembe helyzet. Azaz, sokkal könnyebb kidolgozni ötleteketet ha az emberek egy helyen tartózkodnak. A másik lényegesen fontos szempont a fókuszáltság. A megbeszélések nem tudnak produktívak lenni ha nem rendelkeznek jól meghatározott témával amelyhez a résztvevők ragaszkodnak. A harmadik esszenciális elem, hogy a párbeszéd tényekre és ötletekre fókuszáljon. Ha ez nem történik meg, a párbeszédek könnyen viaskodássá alakulhatnak amelyek személyes véleményekre alapulnak nem pedig tényekre és ötletekre.

Megfelelő emberek

A legfontosabb összetevő a sikeres csapat szempontjából, maga az ember. A szoftverfejlesző csapat tehetséges embereket igényel. Tapasztalt fejlesztők szükségesek komplex rendszerek fejlesztéséhez melyekhez új technológiákat használnak fel. Ilyen összetett rendszerek fejlesztését nem tudja egy vagy két jó ember elvégezni: egy csapat szükséges hozzá. Ugyanakkor a fejlesztők részéről szükség van csapatban végzett munkatapasztalatra is, természetesen.

Folyamatos tökéletesítés

Tudjuk, hogy nagyot bukhatunk ha egy új csapattal egy új rendszert fejlesztünk. A különbség a sikeres és a sikertelen csapat között az, hogy a sikeres képes tanulni a hibáiból. A haladás csak akkor érhető el, ha múlt hibái átvizsgálásra kerülnek és szükséges tökéletesítés végrehajtódik.

A csapat építése

 

Kommunikációs fókusz

A cég és a csapat szempontjából is fontos a kommunikáció központúság, ezért célszerű az irodát nyitott terekre tagolni. A fejlesztő csapat egy nagy nyitott szobában foglaljon helyet. Minden fejlesztő saját asztallal rendelkezzen de rendeződjenek csoportba, hogy megkönnyítsék a kommunikációt. Ez a nyitott környezet megkönnyíti a kommunikációt mivel az emberek nem rejtőzhetnek el a saját irodájukba és minden beszélgetés publikus. (Lényeges megemlíteni, hogy ha mindenki professzionálisan viselkedik a környezet nem válik zavaróvá és hangossá)

Alapelvek letétele

Csapatépítés során nyilvánvalóvá válik, hogy meg kell határozni azokat az elvárásokat, amelyeket a csapattagoknak meg kell testesíteniük. Kezdetileg a napról-napra történő interakciók sorozatával építhető ki a kívánt csapat-karakterisztika. Ezen jellemzők meggyökereztetésével és szocializációval érhető el, hogy az összes csapattag kellő figyelemmel tekintsen azokra az értékekre amelyek fontosak a siker eléréséhez. A gyakorlatban természetesen eltérő lehet az egyes csapatok jellemvonás kialakítása. Az egyes csapattagok tekintetében is jelentős lehet az eltérés, egyeseknél rövidebb másoknál több munkával érhető el az eredmény. Egyes csapattagok nagyon pozitívak és előfordulhat az is, hogy valaki kifejezetten negatívan viszonyul a folyamatokhoz. Bizonyos esetekben célszerű valakit eltávolítani a csapatból. Érdekes megemlíteni, hogy az interjúk során érdemes a technikai felkészültség mellett a kívánt csapat-értékekre is fókuszálni. Ha szimplán a legfelkészültebb technikai embereket válogatjuk össze, közel sem biztos, hogy a legmegfelelőbb csapatot kapjuk.

Interjúztatás

Olyan technikaliag felkészült embert találni aki tökéletesen beleillik egy működő csapatkultúrába nem éppen könnyű dolog. Egyfelől objektív mérési szempontok  segítségével könnyen előszűrhetjük a jelentkezőket. Másfelől ezek az objektív szempontok nem veszik figyelembe a jelentkező soft skill-jeit, melyek nélkülözhetetlenek a csapatban való működéshez. Létezik egy kipróbált gyakorlat ezen képességek hatékony kipróbálására. A felvételi modell ebben az esetben többlépcsős. Az első lépés egy telefonos interjú. Ennek során gyorsan bemutatható a cég a jelentkezőnek, illetve magas szinten lemérhető a jelölt is. A beszélgetés érint pár technikai területet, fejlesztési koncepciót, agilis módszertani ismereteket valamint önálló gondolatokat és tapasztalatokat. A beszélgetés végére elmondható, hogy a jelentkező képes lesz-e az új környezetben működni. Ha a jelölt nem esett ki a szűrőn egy személyes interjúra kap meghívást. Ez az interjú három részre osztódik: technikai, folyamat és személyes részekre. Minden szegmensen legalább két csapattag is részt vesz, mivel nagyon lényeges, hogy a csapat kommunikálhasson a jelölttel. A technikai rész értelemszerűen a nyers technikai tudásra és valós programozási feladatra koncentrál. A folyamat rész többek között teszt filozófiákra, probláma megoldásra és pair programming-ra fókuszál. A személyes rész pedig konfliktus kezelésre, motivációra és általános személyiség jegyekre. Ha mindhárom részen egyöntetűleg jól teljesített a jelölt jól fog teljesíteni a csapatban is.

Folyamatjavítás

A folyamatjavítás a kulcs a sikeres fejlesztőcsapatok építéséhez. Természetesen nem csak a technikai folyamatoké például a kódkészítésé hanem a munka priorizálásé vagy éppen az új ember felvételé is. Több ismert módszer is használható a javításhoz, például a 3x3 -nak nevezett. Ennek során a csapat összeül, minden csapattagnak meg kell neveznie néhány pozitív dolgot az elmúlt 3 hónapból, és néhány negatívat is. Minden csapattag kap 3 szavazati pontot a pozitív csoportra és 3-at a negatívra is. A szavazatok külön elemenként számolódnak. Ezután priorizálva válik láthatóvá mit gondol a csapat pozitívumnak és miket negatívumnak melyeken javítani kell. Ez a módszer segít a csapattagoknak igazodni a csapat karakterisztikához. A folyamatjavítás másik területe lehet például az interjúztatás, hiszen segítségével eleve nem csak technikailag felkészült csapattagot találhatunk, hanem eleve olyat aki jól fog illeszkedni a csapatba. A folyamatjavítás során meg kell találni az egyensúlyt az új folyamatindítás és a régiek módosítása között. Ha bizonyos problémák rendszeresen jelentkeznek meg kell találni az inkrementális változtatás lehetőségét. Ha bizonyos problémák nem rendszeresen jelentkeznek akkor jellemzően érdemes várakozni és többet megtudni mielőtt bármilyen változtatást vezetnénk be.

 Forrás

Szólj hozzá!

Nincs specifikáció

2011.03.23. 12:12  kulcsár bence

Szólj hozzá!

89 agile tools

2011.03.05. 22:25  kulcsár bence

Aki kapcsolatba kerül a scrum-mal vagy más agilis technikával előbb-utóbb szembesül azzal a kérdéssel, hogy milyen szoftverrel támogassa a folyamatait. Ez a lista megpróbál átfogó képet adni a piacon fellelhető szoftver megoldásokról. Vannak open source projektek, előfordulnak x felhasználóig ingyenesek és kizárólag előfizetésesek is. Véleményem szerint akkor is érdemes átbogarászni a listát, ha már regebben használunk egy megoldást, mert az agilitás terjedésével egyre szebb és használhatóbb alternatívák jelentek meg a közelmúltban.

21 Scrum

Szólj hozzá!

Agilis szerződések

2011.02.14. 10:16  kulcsár bence

Az agilis projektek egyik kulcskérdése maga a szerződéses viszony. A következő cikkben Allistair Cockburn számos érdekes szerződéstípust felvonultatva ad áttekintést az agilis projektek szerződés modelljeiről.

Fix ár, fix feladatkör (esetleg fix határidő)

Ez egy régi típusú szerződés: igyekezz legjobb tudásod szerint (mindegy, milyen módszerrel) árajánlatot adni a projektre. Amint benne vagy a projektben, iktass ki mindent, ami fölösleges, használd a legjobb agilis technikákat (lásd még: Process: the 4th dimension), hogy a lehető legjobb eredményt produkálhasd. Tapasztalat szerint az agilis technikák nem befolyásolják egy projekttel kapcsolatos előzetes becsléseket. Leghőbb vágyunk ellenére a projektbecslés még mindig leginkább azon múlik, ki mennyire tapasztalt, milyen megérzései és tippjei vannak. A minden szempontból “fix” projektszerződéseknek akkor van értelme, ha az elvárások nagyon stabilak. Akkor is használnak ilyen szerződést, ha a két fél nem bízik egymásban, noha még egy ilyen megállapodásban is bőven vannak kiskapuk, amikkel bármelyik fél hátrányos helyzetbe hozhatja a másikat, ha éppen ez a célja.

Fix ár, fix feladatkör (esetleg fix határidő), de a megrendelővel együttműködve a feladatkörök átalakíthatók

Kockázatos megoldás, bár már többször láttam sikeresen működni: kétszer kereskedelmi projektekben, és egyszer egy állami projektben. Jeff Patton leírja, hogyan működött együtt a megrendelővel a projekt kezdetén, hogy beazonosítsák az igényeket, kívánságokat és prioritásokat. A projekt előrehaladtával Jeff gondoskodott róla, hogy mindig a legfontosabb elemeken dolgozzanak. Ahogy közeledett a határidő, és világossá vált, hogy néhány részletet még nem sikerült befejezni, Jeff biztosította, hogy kizárólag a legkevésbé fontos területeken maradjanak befejezetlen dolgok. Ez csupa olyasmi volt, ami fölött a megrendelő szemet hunyt, vagy egyszerűen beépítette egy következő szerződésbe.
A fentebb említett állami megrendelés is teljesen fix szerződéssel indult. A csapat szorosan együttműködött a rendszer felhasználóival, és hónapról hónapra képes volt működő, alaposan tesztelt és használható szoftvert szállítani és installálni. Minden szállítás után megbeszélték a felhasználókkal, hogy vajon továbbra is az írott szerződéshez tartsák-e magukat, vagy térjenek el tőle a felhasználók valódi igényeinek megfelelően. Szerintem ez a megbízott cég részéről nagy bátorságra vall, hiszen ha nem lettek volna ilyen jó viszonyban a megrendelővel, akár azt is kockáztathatták volna, hogy nem fogják őket kifizetni. Ebben az esetben azonban az ügyfél annyira elégedett volt a szállított termékkel, hogy minden elvégzett munkát kifizettek a megbízott cégnek. Ez jó példa arra, hogyan lehet egy fix áras, fix feladatkörös és fix határidős szerződést a munka valós idő- és munkaigényének megfelelően rugalmasan kezelni. Veszélyes, de remek stratégia, ha abban a helyzetben vagyunk, hogy kipróbálhassuk.

Fizetés óradíj és dologi költségek alapján

Ebben az esetben minden munkafázist akkor fizetnek ki, amikor elkészült. Nyilvánvalóan ilyen szerződést akkor érdemes használni, ha az elvárások folyamatosan változnak. Egy esetben – amit nem is neveznék projektnek  – az ügyfél szélsőséges módon változtatgatta az elvárásait, akár napokkal a szállítás előtt is. A megbízott cég mindig leszállította, amivel éppen elkészült, az ügyfél pedig teljes mértékben kontrollálni tudta, hogy mi legyen a prioritási lista tetején. Az évek múlásával mindez úgy működött, mint egy kiegyensúlyozott áramlás: a megrendelőhöz mindig eljutott a szükséges szoftver, a megbízott céghez pedig cserébe a pénz.
Ha az ügyfél megbízik a fejlesztő cégben, ez a legegyszerűbb szerződéstípus, amit használni érdemes. A nehézsége mindössze annyi, hogy valóban bizalomra van hozzá szükség. Néhány megbízott cég éppen ezért próbaidőt kér az ügyféltől, ami alatt igyekeznek különféle agilis technikákkal rövid határidő alatt működő szoftvert szállítani, és így elnyerni az ügyfél bizalmát és a későbbi megrendeléseket.

Fix ár és maximum ár

Ez a szerződés stabil elvárásokat feltételez. A “fix ár” a megbízott cég számára garantál egy bizonyos profitot a működési költségeiken és az alvállalkozóiknak kifizetett munkadíjon felül. Egyúttal biztos bevételt garantál a cégnek akkor is, ha a feladatok mennyisége lecsökken, vagy a munka a vártnál hamarabb befejeződik. A “maximum ár” pedig egyfajta költségvetési plafont jelent, amit a megbízott cég akkor sem léphet át, ha a munka lassabban halad a vártnál. Ez tehát a megrendelő számára jelent védelmet. Miután mindkét fél –  a megrendelő és a megbízott cég is  – védve van, nyugodtan törekedhetnek arra, hogy felgyorsítsák a munkát, illetve szükség esetén el tudják fogadni a váratlan nehézségeket.

Fix ár funkciópont- vagy storypoint-egységenként

Ha az ügyfél és a megbízott cég meg tud egyezni a szállítás egységeiben, mint például funkciópontok vagy sztoripontok, ezen egységek alapján is megállapíthatják az árat. Számos szerződés funkciópontokban méri a projektek nagyságát, a leszállított funkciópontokhoz rendeli az egységárat, majd egy hivatalos funkciópont-auditor bevonásával összesíti a projekt végéig leszállított összes funkciópont mennyiségét. A megrendelő így végül ezt a valós összeget fizeti ki, nem pedig az eredetileg becsült összeget. Ez nagyon kedvező szerződési forma, hiszen a megbízott céget arra ösztönzi, hogy minél több funkciópont szállításával növelje a bevételét, a megrendelőnek pedig lehetőséget ad arra, hogy a projekt közben módosítsa az elvárásait. Ugyanez a helyzet az XP-stílusú sztoripontokkal is, azzal az eltéréssel, hogy nem léteznek hivatalos sztoripont-vizsgálók, hogy hitelesítsék a végeredményt. 

Bob Martin ötlete

Bob Martin az Object Mentor-tól közzétett egy érdekes variációt: azt javasolja, a szerződő felek állapítsanak meg egy alapdíjat sztoripontonként, plusz egy átlagosnál alacsonyabb (közel önköltséges vagy az alatti) óradíjat. Ez a megbízott céget arra ösztönzi, hogy mielőbb szállítson, miközben bizonyos fokú védelmet ad arra az esetre, ha a munka a vártnál lassabban halad. Bob Martin így fogalmaz:
”Célszerű megegyezni abban, hogy a megrendelő a befejezett pontok alapján fizet egy meghatározott összeget, plusz egy bizonyos óradíjat minden munkaóra után. Vegyünk például egy projektet, amely 1000 pontból áll. Tételezzük fel, hogy ez a munkamennyiség egy négyfős csapat által heti 50 pontos sebességgel végezhető el. Mindezek alapján ez a projekt 80 ember/hét időtartamig fog tartani. Száz dolláros óradíjjal így tehát a projekt végösszege 320,000 dollár lenne. Most csökkentsük le az óradíjat 30 dollárra, és kérjünk a megrendelőtől 224 dollárt pontonként. Ennek az eredménye igen érdekes lehet: ha a munka valóban 80 ember/hét időtartamig tart, akkor ugyanannyiba fog kerülni. Ha 100 ember/hét időtartamig tart, akkor 344,000 dollárba kerül majd. Ha vizsont csak 70 ember/hétig tart, akkor a végső ára 308,000 dollár lesz. Érdemes megfigyelni, hogy mindez apró különbség ahhoz képest, hogy az időtartamok mennyire eltérőek. Továbbá azt is érdemes észrevenni, hogy a megbízott céget ez a konstrukció erőteljesen arra ösztönzi, hogy hamar befejezze a munkát, hiszen ez növeli a valós óradíjának az összegét.”
Én magam még nem láttam ezt a modellt működés közben, de többektől nagyon kedvező visszajelzéseket hallottam róla.  

Kockázati tőke-alapú finanszírozási modell

Ez bármelyik fentebb leírt szerződéshez felhasználható. Ebben a konstrukcióban a megrendelő egy bizonyos mennyiségű elvégzett munka alapján fizet, a megbízott cégnek pedig eredményeket kell produkálnia, ha több pénzt szeretne kapni. Az ügyfél így bármikor csökkentheti a veszteségeit, ha nem kapja meg a várt eredményeket. Továbbá, minden egyes munkaperiódus után lehetősége van arra, hogy változtasson a szerződés feltételein. A munkaperiódusok eredményének nem kell feltétlenül működő szoftvernek lennie, lehet akár egy írásos tanulmány vagy egy requirements document, vagy bármi, amit a megrendelő választ.  
A kockázati tőke-alapú finanszírozási modell jól működik agilis szolgáltatók esetében, hiszen ők hozzá vannak szokva, hogy működő és használható szoftvert szállítsanak, mégpedig hamar és rendszeresen.  
Személy szerint érthetetlennek tartom, hogy azok a kockázati tőke-finanszírozók, akiknek az induló (start up) projektjeit eddig láttam, nem használták ki a fent leírt modellt annyira, amennyire az agilis csapatok. A tőke-finanszírozók általában szemet hunynak afölött, ha az evaluation markerek időben túl távol esnek egymástól. Pedig, ha a kifizetést havonkénti szállításokhoz kötnék, az a fejlesztő csapatot (start-up team) arra ösztönözné, hogy átgondolja, mennyi munkát is tud hónapról hónapra elvégezni. A havonkénti fejlődés alapján pedig a finanszírozóknak világos képet adhatna arról, hogy milyen is a megbízott cég (start-up company) valós haladási üteme.

Inkrementális szállítás és -fizetés

Ez a “fix ár/feladatkör és határidő”, valamint a “fix ár/maximum ár” jellegű szerződésekben használható. A megrendelő ebben az esetben elvárja, hogy inkrementális módon megkapja az általa megrendelt, integrált és tesztelt rendszereket, amelyeket minden szállításkor szintén inkrementális módon saját maga is tesztel, és a megbízott céget abban az esetben fizeti ki, ha a tesztek sikeresen lezajlottak. Ezt a modellt használták egy repülőtér-építési projektben, vaalmint a  “Solystic’s French Post Office” szerződésben. Mindkét projekt vezetője arról számolt be, hogy ez a konstrukció csodálatosan motiválta a beszállító céget. Persze mindehhez nélkülözhetetlen, hogy a megrendelő tisztában legyen az inkrementális fejlesztés mibenlétével, és el tudja végezni az időről időre esedékes teszteket.

Jonathan House ötlete

Fix ár, plusz 5% bónusz, ha időben szállítanak, vagy fix ár és 5% levonás, ha csúszik a projekt.

Variáció az óradíj- és dologi költségek-alapú fizetésre

A kiszámlázható munkaórák itt egy fix tartományban változhatnak (pl. havonként 180-240 óra az egész csapatnak), hogy elejét vegyék a korlátlan költekezésnek. Némi lehetőség itt is van arra, hogy szükség esetén megnöveljék az óraszámot és ezzel az árat, illetve ne történjen túlszámlázás, ha kevesebb munkaórára volt szükség. 

Határozatlan munkamennyiség szállítása határozatlan időpontban

Ez önmagában is hatalmas témakör, amelyről a következő linken olvashatunk bővebben: Indefinite Delivery, Indefinite Quantity or IDIQ contracts

Norvég PS 2000 sztenderd szerződés

“Ennek a szoftverfejlesztési szerződésnek a lényege, hogy olyan mechanizmusokat bocsát az ügyfél és a fejlesztő cég rendelkezésére, amelyekkel közös egyetértésre juthatnak, valamint tartalmaz egy rugalmas iteratív modellt, amely alapján a fejlesztés során figyelembe lehet venni a felmerülő bizonytalanságokat és kockázatokat.”  
    •    Lépésről lépésre történő iteratív fejlesztési modell, amellyel fel lehet használni a követelményekről és a nehézségekről útközben megszerzett tudást és tapasztalatokat
    •    Szoros együttműködés a beszállító cég és az ügyfél között
    •    Beépített ösztönzők és szankciók, valamint target pricing
    •    Konfliktuskezelési módszerek egy szakértő mediátor bevonásával”
Ezt a szerződést meg kell rendelni (néhány ezer norvég koronába kerül).

Target-Cost szerződés

Idézet: http://www.sparkboxx.com/sparkboxx/types-of-contracts.html “Ebben a szerződésben kitűznek egy kezdeti funkcionális célt, majd konzultációk segítségével meghatározzák, mennyi forrást és időt lenne célszerű befektetni ahhoz, hogy megvalósuljanak a kezdeti specifikációk. A funkcionalitáshoz kapcsolódó cél alapján megállapítanak egy kezdeti árat, amelyre rászámolnak egy bizonyos összeget váratlan helyzetekre, valamint profitot. Ha az ügyfél a projekt során megváltoztatja a munka kiterjedését, vagy ha váratlan követelmények merülnek fel, a megnövekedett költségeket (additions) három csoportba oszthatjuk: (Horowitz 2005): hibajavítások, pontosítások és teljesítményfokozások (enhancements).
Az eredeti cikk a céláras szerződésről angolul itt olvasható:  http://cyrusinnovation.com/downloads/agile2005_cyrusinnovation_targetcostcontracts_paper.pdf
 

Forrás

2 komment

Címkék: agile contract

Az önszervező csapat sikerfaktorai

2011.01.19. 00:03  kulcsár bence

Az agilis csapat jellemzője az önszerveződés, mely nélkülözhetetlen az agilis gondolkodás kialakulásához. Sokan úgy gondolják azonban, hogy az önszerveződő csapatok nem praktikusak. Valóban, ennek kialakulása nagyban függ a csapattagoktól, a menedzsmenttől, a cég szervezeti függelmeitől és a végzendő munka természetétől is. Ha kizárólag szoftverfejlesztő csapatokra gondolunk, három sikerfaktorát azonosíthatjuk a hatékony önszerveződés kialakításának.

Tisztán definiált határok

A csapatok tisztán és jól definiált határok mellett szervezhetik és menedzselhetik magukat szabadon és hatékonyan. A határok deklarálása nélkül a csapatok bizonytalanok abban, hogy milyen messzire mehetnek, illetve mennyire próbálhatják meg menedzselni magukat. Ha a csapattagok bizonytalanok, folyton figyelmeztetni fogják őket, hogy tilosban járnak. Előbb utóbb pedig mindenre engedélyt fognak kérni a menedzsmenttől, ez pedig teljesen lenullázza az önszerveződésben rejlő lehetőségeket.

Hibatűrés és tanulásra szánt idő

Gyakran előfordul, hogy a menedzsment önszerveződőnek deklarál egy csapatot és az első adódó alkalommal amikor hibát vétenek átveszi az irányítást a szituáció felett. Ha ez bekövetkezik az önszerveződésre törekvő kísérlet véget is ér. Ezután nagyon sok idő és erőfeszítés szükséges, hogy a csapat elhiggye a menedzsmentnek az eltökéltségét az önszerveződés engedélyezését és támogatását illetően.

Kihívás, nem frusztrálás

A csapat adminisztratív vagy funkcionális menedzserének érzékenynek kell lennie a csapat korlátait illetően, és ennek megfelelően alakítani az elvárásokat illetve a határokat. Mindezt oly módon, hogy a csapattagok kihívásnak tekintsék az elvárásokat ne pedig frusztrálónak. Azaz nem többet kívánni tőlük mint a legtöbb munka, amit kezelni is tudnak. Ez az alapja egy önszerveződés végső soron pedig egy projekt illetve az organizáció érettségének is.
 

Forrás

2 komment

Címkék: team agile self organize

Védett a management-tel szemben?!

2010.12.27. 11:34  kulcsár bence

Szólj hozzá!

Mit jelent agilisnak lenni?

2010.12.20. 20:36  kulcsár bence

Laurie Williams, a North Carolina State University professzora egy felmérést végzett, amely azt vizsgálta, hogy az agilis csapatok a gyakorlatban milyen irányelveket és praktikákat használnak. Közel 300 csapat vett részt a felmérésben, a válaszok közül pedig azok sorolódtak előre amelyek a legtöbb "Very High" fontossági minősítést kapták.

  1. A legfontosabb agilis jellemző az értéket hordozó szoftver korai és folyamatos szállítása valamint az ezáltal elért ügyfél elégedettség   

  2. A fejlesztés előrehaladását elsődlegesen a működő szoftver méri

  3. Működő szoftver gyakori szállítása, a néhány hetestől a néhány hónapos iterációkig terjedő skálán -a minél rövidebbek preferálásával

  4. Építs projektet motivált egyéniségekre. Biztosítsd a környezeti feltételeket, támogasd őket amennyire csak igénylik. Bízz meg bennük, hogy el fogják végezni a munkát!

  5. Szabályos időközönként a csapat reflektál, hogy miként lehetne hatékonyabb, majd ennek megfelelően finomhangolja a folyamatait és módosítja a viselkedését.

A felmérés rákérdezett, mely gyakorlati elemek voltak esszenciálisak az agilis átállás megfontolásához. Az 5 legvonzóbb agilis szokás és praktika:

  1. Rövid iterációk (30 nap vagy kevesebb)

  2. Continuous integration (Folyamatos integráció)

  3. "Done" kritérium

  4. Automatikus teszt futtatás minden build-nél

  5. Automatizált unit teszt

Szólj hozzá!

Címkék: agile scrum

Nintendo Wii + scrum + taskboard

2010.12.16. 21:26  kulcsár bence

Figyelemre méltó kezdeményezés a Nintendo Wii segitsegevel összehozott interaktív scrum dashboard a TenForce jóvoltából. A lényeg, hogy egy beamerrel, egy Wii-vel és a pmScrum megoldással szabadkézzel válik irányíthatóvá egy projektorral kivetített virtuális dashboard.

Scrum TaskBoard from pmScrum on Vimeo.

Szólj hozzá!

Címkék: tool

Termékvízó készítés lépései

2010.12.12. 21:20  kulcsár bence

Szólj hozzá!

Címkék: product vision

Termékvízió

2010.12.12. 10:25  kulcsár bence

Merre van észak?

Dolgoztak már olyan Scrum projektben, amelynek a végső célja nem volt világos? Amelyben volt Product Backlog, de a fejlesztő munkatársak csak homályosan értették a Release célját? Ilyesmi sokkal gyakrabban előfordul, mint hinnénk, még több millió dolláros költségvetésű projektekben is! Sajnos a Scrum-nak azt az alapelvét, miszerint ”legfőbb cél a hatékony munkavégzés”, sokan úgy értelmezik, hogy kapkodva kell dolgozni, miközben nincs idő átgondolni, hogy merre is haladjon a projekt. Ne kövessük el ezt a hibát! Minden Scrum projekthez nélkülözhetetlen egy vízió arról, hogy “merre van észak”, vagyis merre haladjon a Scrum csapat. Ez a vízió nem más, mint az a közös cél, amellyel mindenkinek tisztában kell lennie: legyen bár az illető Product Owner, ScrumMaster, a fejlesztői csapat tagja, a menedzsment vagy a megrendelő képviselője, vagy más kulcsszereplő. Ken Schwaber szavait idézve: “Minden Scrum projekt elkezdéséhez két minimum-feltétel szükséges: egyrészt a vízió, másrészt a Product Backlog. E kettő közül a vízió tartalmazza, hogy miért valósul meg a projekt, és mi az elérendő végcél.” (Schwaber 2004, p. 68)

Öt fontos kérdés

Jonathan Swift angol író szerint “a vízió a láthatatlan dolgok meglátásának művészete”. A Scrum szerint pedig a termékről alkotott vízió nem más, mint a projekt jövőképe, amely leírja, hogy kik a megrendelők, mire van szükségük, és hogyan fognak teljesülni az elvárásaik. Emellett esszenciálisan összefoglalja a termék lényegét, vagyis mindazokat a döntő információkat, amelyekre szükségünk van ahhoz, hogy sikeres terméket fejlesszünk és indítsunk útjára. Ahhoz, hogy a termékvíziónk megfelelő legyen, célszerű alaposan körbejárni a következő öt kérdést:

1. Ki fogja megvásárolni a terméket, vagyis mi a célcsoportunk?

2. A megrendelő mely igényeit fogja kielégíteni a termék?

3. A terméknek mely tulajdonságai döntő fontosságúak ahhoz, hogy kielégíthessük a kiválasztott igényeket, és így sikeres legyen a termék?

4. A termék hogyan viszonyul más, már létező (saját vagy konkurrens) termékekhez? Mik a termék egyedi üzleti értékei az eladhatóság szempontjából?

5. Mi a kitűzött határidő és mekkora a tervezett költségvetés, amelyből megvalósul a termék?


Ha megválaszoljuk ezt az öt kérdést, a kapott információk alapján elkészíthetjük magát az üzleti tervet is, valamint eldönthetjük, hogy érdemes-e belevágni a projektbe, és ha igen, akkor hogyan.

A termékvízió létrehozása

Mivel a Product Owner felel a termék sikeréért és a befektetés megtérüléséért, célszerű, ha ő irányítja a termékvízió megalkotását, a csapattal szoros együttműködésben. (Pichler 2008). Innovatív projektek esetében a csapattagok között lehetnek üzleti és technikai szakértők, marketingesek, termék- és user interface designerek, illetve -fejlesztők. Minél innovatívabb és összetettebb a termék, annál fontosabb a vízió, illetve annál több erőfeszítést igényel a vízió megalkotása. Új termékek fejlesztése esetén, vagy ha egy létező terméket jelentős mértékben átalakítanak, általában végeznek piackutatást vagy prototyping tevékenységet. Mivel a releváns információk begyűjtése ilyenkor hetekig vagy hónapokig is tarthat, célszerű a szükséges munkát egy vagy több sprintre felosztva elvégezni. Ezzel összehasonlítva: egy kisebb product update vagy egy maintenance release esetében a vízió akár néhány óra vagy nap leforgása alatt megalkotható.

A termékvízió legfontosabb alkotóelemei

A termékvízió leglényegesebb elemei: a megrendelő legfontosabb igényeinek leírása, és azon terméktulajdonságok felsorolása, amelyek kielégítik majd ezeket az igényeket. A termékvízió megalkotása során először megnevezzük a megrendelői célcsoportot, majd a megrendelő releváns igényeit. Ezáltal azt is eldöntjük, hogy milyen piacot vagy piaci szegmenst veszünk célba. Ezek után meghatározzuk a termék attribútumait, vagyis azokat a kritikus és magas szintű elvárásokat, amelyeknek meg kell felelni ahhoz, hogy a termék kielégíthesse az ügyfél igényeit.

A termék-attribútumok általában funkcionális és nem-funkcionális tulajdonságokból állnak. Nem-funkcionális tulajdonság például az adott termék teljesítménye, robosztussága és használhatósága. A funkcionális tulajdonságok pedig a termék olyan, specifikus funkciói vagy jellegzetességei, mint például az automatikus telefonhívás vagy e-mail küldés. Végső soron a termék-attribútumok iránytűként szolgálnak a team számára, hiszen leszűkítik a lehetséges megoldásokat, illetve meghatározzák az összes lehetséges megoldást.

Ahhoz, hogy a termék-attribútumok részletezettsége éppen megfelelő legyen, a Product Owner és a team részéről szoros együttműködésre és arányérzékre van szükség. Ha ugyanis az attribútumok nem elég kidolgozottak, nem tudnak majd kellő iránymutatást adni a munkához. Ha pedig túlságosan specifikusak, az elhamarkodott döntésekhez vezethet és alááshatja a csapat kreativitását. Az attribútumok meghatározásához célszerű különböző felhasználói típusokat, szerepköröket, használati eseteket, és user story-kat felhasználnunk.

Milyen az ideális termékvízió?

A fontos célkitűzésekhez hasonlóan a jó vízió is egyszerre hat az értelmünkre és az érzelmeinkre.

Fontos, hogy motiválja és inspirálja az embereket. A termékvíziónak világosnak és szilárdnak, széles körűnek és magával ragadónak, valamint kellően rövidnek és tömörnek kell lennie.


Világos és szilárd

A termékvízió legyen világos és közérthető, hogy általa megszülessen az egyetértés és a közös cél, valamint, hogy elkerülhessük a félreértéseket és a zűrzavart. (Lynn&Reilly 2002, Pichler 2008). A vízió szó latin eredetű, jelentése “látás, kilátás, elgondolás, ötlet”. A termékvízió célja tehát, hogy általa láthassuk a leendő terméket, így nem szabad, hogy ködös vagy homályos legyen.

A vízió átalakítása zavarodottsághoz, a motiváció elvesztéséhez és a projekt bukásához vezethet, különösképpen, ha a változtatások érintik a megrendelői igényeket vagy a legfőbb attribútumokat. Kisebb módosítások általában elfogadhatók, de csak akkor, ha a terméket jellemző alapértékek érintetlenek maradnak.

Széles körű és magával ragadó

A termékvízió ideális esetben széles körű és mindenki számára szimpatikus célokat fogalmaz meg: olyanokat, amelyek mentén könnyen irányítható a fejlesztés, ám marad elég hely a kreativitásnak; továbbá, amelyek magukkal ragadják és inspirálják az embereket, elősegítik a kreativitást és elnyerik a résztvevők támogatását.

Rövid és tömör

A termékvízió legyen rövid és tömör (Pichler 2008). Olyan információkat tartalmazzon, amelyek nélkülözhetetlenek a termék sikeréhez. A Lynn&Reilly (2002) által elemzett,  kasszasikert hozó termékek víziójában például legfeljebb hat termék-attribútum szerepelt. A termékvízió nem egyenlő az összes tulajdonság listaszerű felsorolásával, és nem célja, hogy szükségtelen részleteket tartalmazzon.

A lift-teszt

A termékvízió értékelésének klasszikus módja, ha elvégezzük a lift-tesztet:

“El tudod mondani a terméked lényegét annyi idő alatt, amíg felérünk a lifttel?” (Moore 2006, p. 152). Ha a termékvízió átmegy ezen a teszten, akkor biztosak lehetünk benne, hogy kellően világos, magával ragadó és rövid (feltéve, hogy a lift egy megfelelő magasságú épületben halad velünk, és nem szorulunk be.)

Ne feledjük: a lift-teszt nem alkalmas arra, hogy megmutassa, vajon megfelelően választottuk-e ki a megrendelői igényeket vagy a termék-attribútumokat, hiszen erre csak a korai ügyfél-visszajelzések adhatnak választ.

Mindennapos, rutinszerű projektek

Még a rutinszerű projekteket is célszerű termékvízió alapján irányítani. Én például a saját marketing-tevékenységeimet is a Scrum segítségével végzem. A marketing backlogomat rendszeresen új elemekkel bővítem, akár nap mint nap. Fölösleges lenne ugyanis piackutatást vagy prototypingot végeznem, mielőtt eldönteném, mit is szeretnék csinálni. Ehelyett megalkotom a saját marketing-víziómat, amely alapján dolgozom és képes vagyok a lényegre fókuszálni. Ez kevésbé összetett, mint egy új termék fejlesztéséhez használatos vízió, de mégis fontos, hogy megalkossam és alkalmazzam.

Összegzés

A hatékony termékvízió képes arra, hogy vezesse a Scrum teamet és összhangba hozza a projekt kulcsszereplőit és a megrendelőket. A vízió megalkotására fordított idő és pénz nagyon kifizetődő befektetés. Robert G. Coopert idézve: 

“Túl sok fejlesztési projektben térnek rá a megvalósításra az első ötlet felbukkanása után, ahelyett, hogy elvégeznének bizonyos előzetes házifeladatokat. Ennek a ‘vigyázz, kész, tűz’ hozzáállásnak általában katasztrofális következményei vannak. Az alapos fejlesztés előtti felkészülés ezzel szemben jelentősen növeli a sikeres projektek arányát és közvetlenül befolyásolja az anyagi megtérülést.” (Cooper 2000, p. 3)

Mindez persze nem azt jelenti, hogy halogassuk a projekt elkezdését, vagy fordítva üljünk a lovon és gigantikus méretű termék-koncepciókat dolgozzunk ki, amelyek felérnek egy önálló projekttel. A titok nyitja, hogy a lehető legkevesebb időt fordítsuk rá, ám mégis pont annyit, amennyi szükséges. Használjuk a Scrumot a vízió megalkotására és gondoskodjunk róla, hogy a vízió létrehozásában részt vevő csapat lehető legtöbb tagja részt vegyen magának a terméknek a megalkotásában is.

Forrás

Szólj hozzá!

Címkék: product vision

Szerintem félreértelmezi

2010.12.06. 12:45  kulcsár bence

6 komment

Címkék: cartoon