RSS Feed LinkedIn Google Plus

Scrum in Action

2013. július 8. hétfő

Andrew Phan és Phoung-Van Pham könyve gyakorlati áttekintést igyekszik nyújtani a Scrumról, külön pozitív, hogy egy fejezetet szánnak a pénzügyi tervezhetőségnek is, kiemelve, hogy a felső vezetésnek ne azt próbáljuk elmondani, hogy a Scrum modern, hatékony, rugalmas, hanem törekedjünk az objektív, pénzügyi nyelvezet használatára. Gyakorlatias jellegű könyv, a  teljesen kezdők számára talán kevés a magyarázat a miértekről. Pozitív, hogy a Scrumnak az enterprise méretű vetületeivel is foglalkozik, de nagyon részletes magyarázatot nem ad. Dicséretes, hogy külön fejezet foglalkozik azzal, hogy hogyan kell beszélni a külső kapcsolatokkal a főigazgatótól kezdve a közvetlen felettesen át a QA csapatig. Az alábbiakban pár dolgot kiemelnék belőle.

Time boxing

Minden megbeszélésnek legyen fix időkerete. Máshol olvastam, hogy ahhoz, hogy eredményeket érjünk el, két dolog kell: világos célok és a szükségesnél kicsit kevesebb idő.

Célok kitűzése

Mielőtt nekiállnánk apróbb feladatokra bontani a folyamatot, fontos, hogy jól tűzzük ki az elérendő céljainkat, ebben segít a SMART lista, a cél legyen

  • Specific: mindenki ugyanazt értse alatta
  • Measurable: objektívan meg tudjuk állapítani, hogy a célunkat elértük-e
  • Achievable: az érdekelt személyek egyezzenek meg abban, hogy mi a cél
  • Realistic: a rendelkezésre álló erőforrásokkal elérhető legyen
  • Time-Based: legyen elég időnk ahhoz, hogy elérjük

Követelmények megfogalmazása

Ahhoz, hogy a fejlesztésünk sikeres legyen, fontos, hogy világosan, pontosan és írásban megfogalmazott követelményeink legyenek, ez alól az agilis módszertanok sem adnak kivételt. A User Story-k ellenőrzéséhez az alábbi lista nyújt segédletet, miszerint a követelmények legyenek

  • konzisztensek, ne ütközzenek más feladatok követelményeivel
  • egyértelműek, bárki, aki átnézi a követelményt csak egy megvalósítást tudjon felrajzolni, függetlenül a szerepétől
  • tesztelhetőek: tudjunk teszt eseteket gyártani hozzá, ha ez nincs meg, az, hogy korrektül leimplementáltuk-e az igényeket, csupán személyes vélemény lesz
  • megvalósíthatóak: minden követelmény implementálható kell hogy legyen a rendelkezésre álló eszközeinkkel figyelembe véve a korlátainkat is
  • függetlenek: egy User Story sem függhet egy másiktól
  • kinyomozható: minden User Story-t hozzá kell tudnunk kötni egy felhasználóhoz és az ő céljaihoz

A függetlenséggel nem értek teljes mértékben egyet, vannak olyan szituációk, hogy ki kell kutatni valamit ahhoz, hogy bölcs alapot tudjunk vetni a projektnek, ilyenkor addig nem építhetjük fel a falakat, vagy tervezhetjük meg a konyhabútort, amíg nem tudjuk, az adott területen mekkora alapterületű és milyen formájú házra fogunk tudni majd engedélyt kapni. De kétség kívül törekedni kell a függetlenségre.

Architektúra ismerete

Bár az agilis fejlesztési módszertanoknál nem specifikálunk le mindent jó előre, nagyon fontos, hogy a fejlesztők képben legyenek a pontos architektúrával, hiszen így tudják a User Story-kat a megfelelő helyen implementálni. Ennek hiányában a feladatok első körben általában rossz helyen (tipikusan az Application Layer-ben) készülnek el, s majd idővel kezdenek el a saját helyük felé vándorolni. Ezen kívül a technológia és az architektúra nem ismerete rapszódikussá teszi az egyes sprintek alatt elvégzett story point-ok számát.

A product owner követelményei

Az agilis projekt nem lehet sikeres egy jó product owner nélkül, aki az eredeti vízió és célok őrangyalaként gondoskodik arról, hogy valóban értéket tudjunk leszállítani. A jó product owner hét fő ismérve:

  • tudja, hogyan kell sikeresen kezelni az érintett emberek elvárásait és nem ritkán konfliktust okozó prioritásait
  • tiszta képe és ismerete van a termékről
  • tudja, hogyan gyűjtse össze az igényeket annak érdekében, hogy a projekt vízióból jó product backlog-ot tudjon készíteni
  • folyamatosan és aktívan elérhető a csapat számára, nem csak a sprint során, de a release és sprint planning közben is
  • jó szervező, aki gyorsan tud különböző feladatok között váltani, miközben szemét a célon tudja tartani
  • tudja, hogyan kommunikálja a termék vízióját, nem csak a csapat, de az üzleti részleg felé is
  • jó vezető, aki alkalmas tanítani, segíteni és támogatni a csapattagokat

Hogyan adoptáljuk a Scrum-ot?

Sok esetben nem lehet mindent teljes mértékben bevezetni, a fejezetben különböző gyakorlati életben előforduló szituációk megoldására kapunk javaslatokat:

  • Mit tegyünk, ha elvárnak különféle jelentéseket a Burndown chart-on kívül…
  • Ha a menedzsment szeretné látni, mennyi pénz megy el a Scrum projektre…
  • Ha a cég mindenképpen akar Projekt Menedzsert…
  • Ha nincs lehetőség ScrumMaster alkalmazására…
  • Ha egy hivatalos vezetőt akarnak kinevezni ScrumMasternek…
  • Ha nem megoldható a fizikai jelenlét a Daily Standup-okon…
  • Ha egy nagy csapatot kapsz meg (több, mint 9-10 fő), hogy dolgozzanak Scrum-ban…
  • Ha nincs meg még az infrastruktúra a teszteléshez…
  • Ha a fejlesztési csapat nem akar TDD-ben dolgozni…
  • Ha a tesztelési csapat senkit nem tud delegálni az új Scrum projekthez…
  • Ha mindenkinek új a Scrum és nincs ScrumMaster…
  • Ha a cégvezetés a büdzsé miatt a product ownert és a ScrumMastert szeretné egy személybe olvasztani…
  • Ha a csapat nem határozza meg, mit ért a “KÉSZ” alatt…
  • Ha a vezetőség egyéb fázisokat akar bevezetni a sprinten kívül…
  • Ha valaki szeretné, hogy a sprint 30 napnál hosszabb legyen…
  • Ha a cég azt akarja, hogy az igények legyenek előre összegyűjtve, amennyire csak lehet, mielőtt elkezdődik a projekt…
  • Ha infrastrukturális szempontból nincs lehetőség napi buildre és a continuous integration bevezetésére…
  • Ha nincs senki, aki product owner lehetne…

A jó ScrumMaster tulajdonságai

  • a Scrum alapos elméleti és gyakorlati szintű ismerete
  • jó alázatos vezető képességek
  • erős szervezési képességek
  • jó kommunikációs képességek
  • nagyszerű előadói képességek
  • konfliktuskezelő képesség
  • jó emberismerő

Öszegzés

Alapvetően tetszett a könyv, gyakorlatias jellegű, de helyenként több időt szentelt egy speciális gyakorlat bemutatására, mint az alapok ismertetésére, ezért teljesen kezdőknek nem ezt ajánlanám, a 10-es skálán 7-es. A könyvet a Virtual Call Center Kft-től kaptam kölcsön, melyet ezúton is köszönök.


Nincs hozzászólás

Vélemény?

Bocsánat, de a bejegyzéshez egyelőre nem engedélyezett a hozzászólás.