Доброто познаване на правилата в Scrum е необходимо, но съвсем не достатъчно условие за добрия ProductOwner (PO).  Тази роля е от изключителна важност за проекта и продукта като цяло, тъй като добре свършената работа може да направи вашата компания лидер в областта си, докато в обратния случай ви изпрати след всички конкуренти. Това налага много допълнителни изисквания към PO – като начало, добро разбиране за бизнес сферата, към която е ориентиран продуктът, умения за работа с клиенти от една страна, и с екипа от друга, и т.н.  И всеки проект и продукт имат своя специфика, затова е трудно да се дават готови рецепти за „добър PO“.

Въпреки това има въпроси, които винаги изникват по време на обученията или впоследствие, когато започнат първите спринтове. В този блог ще се опитам да дам насоки, в които да търсите решенията на тези въпроси, когато се сблъскате с тях.

В: Колко детайлни трябва да са описаниятa на елементите от продуктовия списък?

О: Едно от предизвикателствата за PO е да се научи да казва на екипа „какво“, а не „как“ трябва да се направи, особено когато той/тя е запознат със технологичните специфики на продукта. Ето защо писането на много детайлни описания на елементите в списъка може да се превърне в създаване на дизайн или подробна спецификация, която не оставя твърде много свобода на екипа да реши как да свърши поставената задача. Дори и да сте убедени, че с вашия голям опит давате най-доброто решение, при описанието на продуктовия списък се ограничете до това да дефинирате проблема и оставете екипът да търси отговора – така решението може да се окаже по-иновативно и ефективно от всичко, правено досега.

В същото време обаче, не бива да оставяте вашия продуктов списък твърде абстрактен и неконкретен. Виждала съм това да се случва, когато се използват потребителски истории (user stories) като инструмент. Те наистина предполагат кратка формулировка и много допълнителна комуникация междy PO и екипа, но много важен и често забравян елемент от тях е дефиницията за завършеност (или acceptance criteria/test). Чрез дефинирането на тестовете, с които искате да проверите дали продуктът се държи според изискванията, вие всъщност дефинирате какъв резултат очаквате за дадената история и давате на екипа насоките на проблема, който те трябва да решат.

По отношение на екипа, факторите, които също определят необходимостта от по-детайлно описание, е зрелостта на екипа (времето, което членовете му са работили заедно като екип) и степента на сработеност с PO. Когато работите с по-млади или непознати за вас екипи, е добра идея да вложите повече детайли в описанието на продуктовия списък, докато намерите оптималния вариант за комуникация и уточняване на изискванията.

В: Как PO приоритизира?

О: Приоритизирането започва още при началното дефиниране на продуктовия списък. След определянето на елементите и преди началната им оценка с екипа, е добре да разделите изискванията в следните групи:

1. Елементи, без които продуктът не може (must-haves)
2. Елементи, които продуктът би трябвало да има (should-haves)
3. Елементи, които продуктът е добре да има и биха се превърнали в негово предимство на пазара (nice-to-haves или exciter features, както ги нарича Майк Коон)
4. Елементи, които са интересни, но не и важни (за текущата версия на продукта) и могат да изчакат

Ясно е, че на първо място екипът ще се фокусира върху първите 3 групи в този ред. С това вие вече сте определили приоритетите на най-общо ниво. Следващата стъпка е оценката от екипа. Когато вече знаете колко би струвало да се направи всеки един от елементите, бихте могли да махнете някои от нещата във групите на should- и nice-to-haves, ако те са прекалено скъпи и не донасят голяма допълнителна стойност на продукта. Ако се налага, може да зададете и по-детайлни приоритети вътре в самите групи (обикновено е наложително за should- и nice-to-have, но понякога и за задължителните функционалности – например, ако планирате да издадете алфа- или бета-версия на продукта и искате тя да съдържа определени функционалности). Интересен инструмент, който може да ви помогне в това упражнение, можете да намерите на http://www.mountaingoatsoftware.com/tools/relative-weighting.

В: Какво да прави PO, ако няколко неща са спешни?

О: В зависимост от проекта и мащабите му имате различни варианти за реакция. Ако работите с няколко екипа, бихте могли да вложите целия им капацитет, като включите всички високоприоритетни елементи в списъците на екипите за спринта. Ако нямате такава опция, можете да се опитате да предефинирате тези изисквания, така че те да обхващат по-малко функционалност (например, ако цялото изискване е възможност да се съхраняват и променят лични данни, бихте могли на първо време да ограничите изискването до това те да могат да се запазват, а като втора стъпка – да се променят). Така ще можете да покажете работещ продуктов инкремент и да получите обратна връзка от клиентите в края на итерацията, въпреки че цялостната визия все още не е осъществена.

Ако нито едно от по-горните неща не са възможни, алтернативата е да поговорите с клиентите си и да обсъдите приоритетите отново. Разкажете им какви са плановете и защо не достига капацитета на екипа, покажете им защо функционалностите, които планирате, ще са им полезни.

В: Как PO да изисква високо качество от екипа?

О: В Scrum осигуряването на високо качество на продукта е приоритет на екипа. Въпреки това, PO би могъл да помогне на екипа да постигне добро качество чрез дефинирането на добри функционални тестове (по-горе стана дума за т.нар. acceptance tests). Освен това той/тя трябва да бъде на разположение на екипа за въпроси, демота и обратна връзка по време на целия спринт, за да не се налага преработка впоследствие.

В: Какво да прави PO, ако нещо не се свърши навреме?

О: Понякога това, което все още трябва да се направи, не носи много допълнителна стойност за продукта – например,  да се премести елемент от ляво или от дясно на уеб страничката или да се смени текста на бутон от приложението. По ваша преценка, такъв елемент би могъл да бъде приет за завършен. Когато обаче не са довършени по-критични за продукта неща и особено такива, които са отразени в критериите за завършеност, елементът трябва да бъде върнат в списъка с изисквания, да бъде приоритизиран и планиран за следващия спринт. Всяко забавяне трябва да бъде комуникирано и с клиентите и другите заинтересовани лица, тъй като би могло да има отражение и върху техния график.

В: Как PO може да помогне на екипа?

О: PO трябва да помогне на екипа да разберат в детайли какво се изисква от тях, за да могат да предоставят добро решение. За да постигне това, PO трябва да разполага с достатъчно време за екипа, така че участниците в него да могат да го открият за дискусия или предварително демо.  Освен това, като PO вие бихте могли да отделяте от времето за проверка на вече завършените елементи и да предоствяте бърза обратна връзка на екипа, така че те да могат да го имплементират в рамките на същата итерация.

Leanify стана една от първите фирми в света – и първата в Източна Европа, регистрирани като Scrum Alliance Registered Education Provider (REP). Програмата е нова за Scrum Alliance и е свързана с нов тип сертификат – Certified Scrum Developer (CSD). Курсът на Leanify „Scrum за екипи“ беше оценен от представители на Алианса и беше одобрен да се включи в програмата. Участниците в курса ще получат кредити по първата цел, необходима за сертификата CSD.

За повече информация относно REP и CSD, вижте http://scrumalliance.org/rep.

В: Кой е подходящ за Scrum master (SM)?

О: Всеки, който има широк поглед върху компанията, инфраструктурата в нея, познава много от служителите и хората му имат доверие. Не е необходимо това да е най-добрият програмист, защото той ще е по-необходим в екипа. Хубаво е SM да е и неформален лидер, за да може да обединява екипа и да го мотивира, както и да може да оказва влияние за спазване на правилата. Но най-важното качество е комуникативността – да може да комуникира с всички – ProductOwner, мениджмънт, екип, хора, които да помагат за преодоляване на пречките. Възможно е екипът сам да си избере SM, както и да изисква от SM да е напълно отдаден на екипа.

В: SM участва ли в планирането?

О: Не. Честа грешка е SM да участва в планирането, да раздава задачи и да дава оценка за времето на изпълнение. Ролята на SM се изчерпва до осигуряването на необходимите условия за провеждането на срещата и постоянната готовност да окаже помощ при нужда.

В: SM участва ли в самата разработка?

О: За предпочитане е SМ да не е част от екипа, защото така времето му се разпокъсва и понякога трябва да прави избор между разрешаването на пречка и изпълнението на собствената си задача. Ако има няколко паралелни Scrum екипа по един проект, по-добре е SM да е такъв на няколко от тях, отколкото няколко човека да са и SM, и членове на екипа едновременно.

В: SM трябва ли да дава отчет на мениджмънта?

О: SM е връзката между мениджмънта и екипа по време на спринта. Ако е необходимо, напомня къде се намират и показва стандартните показатели на проекта – под формата на графика на оставащата работа. Най-добре е SM да обясни на мениджмънта, че демото по време на ревюто ще даде най-точна представа за постигнатото до момента и те непременно трябва да присъстват. 

В: SM ли е отговорен за крайния резултат?

O: Не. Екипът е отговорен за резултата. Ролята на SM е да помага за постигането на резултата и да премахва всички препятствия пред тях. SM е отдаден на екипа.

В: Какво може да направи SM, ако вижда, че нещо не е наред в процеса?

О: Може да направи сверяване на часовника под формата на анкета, да направи допълнително обучение на хората или да се потърси външен човек за анализ и преценка на ситуацията. Но при всички случаи – трябва да направи всичко възможно, за да подсигури правилното изпълнение на процеса в екипа.

В: Какво може да направи SM, ако вижда, че екипа изостава в спринта?

О: Първо трябва да насочи екипа да анализира, защо се е стигнало до тази ситуация. След това да им помогне да потърсят заедно решение. Ако екипът все пак потвърди, че не вижда проблеми за постигане на Целта на Спринта, отговорността е тяхна и той трябва да приеме решението им.

Колкото и добър да е даден процес или методология, резултатите не са впечатляващи, когато не се прилага правилно. Това напълно важи и за Scrum.

В моята практика, като Scrum Master, общувам с различни Scrum Master-и и екипи, където се прилага Scrum. Някои от тях са ми споделяли, че резултатите не са такива, каквито са очаквали и дори не виждат полза. След по-задълбочен разговор обаче, се оказваше, че това, което на практика са правели, е далече от истинските Scrum принципи и идеи. От тези разговори осъзнах колко важно е Scrum Master-ът да е добре запознат с процеса, да има силата да го отстоява и да служи за пример, да помага на екипа за постигане на целите в спринта.

За правилното прилагане на Scrum е нужна промяна в мисленето и поведението на хората. Екипът трябва да се научи да поема отговорност, а мениджърите да не се намесват в работата на екипа.

Ето някои от често срещаните грешки при прилагането на Scrum и съответните идеи, които Scrum Master-ът би могъл да използва, за да насочи нещата в правилната посока. Тези грешки обикновено се срещат в началото при повечето екипи и ако Scrum Master-ът не ги изкорени още тогава, те ще продължат да се правят, процесът ще се изроди и няма да донесе очакваната полза.

• Когато в началото някоя организация започне да прилага Scrum, обикновено мениджърите все още не са си променили мисленето и продължават с предишния си подход да дават задачи на хора от екипа. Това обаче е много погрешно в Scrum, понеже екипът сам трябва да разпределя задачите си, които от своя страна са били определени по време на планирането на спринта въз основа на продуктовия списък, изработен от Product Owner-а. Scrum Master-ът трябва да следи за такива опити за вмешателство и да предпазва екипа от външно влияние (в конкретния случай от мениджъра). В случая Scrum Master-ът може да разговаря с екипа, като обясни, че според Scrum, само екипът е отговорен за планирането на работата и за изпълнението на задачите по спринта и не трябва да приема намесата на мениджъра. От друга страна, Scrum Master-ът задължително трябва да разговаря с мениджъра, да му обясни Scrum правилата и да настоява мениджъра да не се намесва в работата на екипа. Освен това, може да препрати мениджъра и към Product Owner-а за дискусия, ако задачата е свързана с евентуална промяна в продуктовия списък.

• Пак в началото на прилагането на Scrum, хората от екипа обикновено не са свикнали сами да поемат отговорност за изпълнението на задачите, да решават кой коя задача ще вземе и как ще я реализира. В тези случаи обикновено част от хората са свикнали някой друг да им дава задачите и да решава вместо тях кое и/или как трябва да се направи. В тази ситуация Scrum Master-ът трябва да обясни на хората от екипа, че е тяхна отговорност сами да решат коя задача от кой ще бъде изпълнена и по какъв начин. Ако няма резултат само от разговора, Scrum Master-ът трябва да осуети опитите за външно вмешателство на мениджъри, които с охота ще се опитат да “помогнат” , като разпределят задачите и кажат как да се изпълнят. Ако екипът бъде оставен достатъчно време без външна намеса, ще се научи да се самоорганизира и да поема отговорност.

• Друга грешка, която се прави, е закъснението за ежедневните Scrum срещи. В повечето случаи само няколко човека закъсняват, но това е лошо, понеже губят времето на останалите, които са дошли на време. В тези ситуации най-удачното разрешение идва от личния пример на Scrum Master-а. Ако той не закъснява и показва на екипа, че държи срещата да започва на време с всичките участници, то тогава ще има резултат и хората ще започнат да се стараят да идват на време.

Това е само една малка част от грешките, които се допускат и за които Scrum Master-ът е длъжен да следи и да поправя. При всички случаи, обаче, е много важен личният пример на Scrum Master-а. Важно е да познава добре, твърдо да отстоява и да следи за правилното изпълнение на Scrum принципите. Едва тогава резултатите ще бъдат впечатляващи – хората от екипа ще бъдат мотивирани и ще изпитват удоволствие от работата. Клиентите също ще бъдат доволни от това, което получават, и съответно компанията ще увеличи печалбата си.

Когато започнах работа като ProductOwner, не си давах изцяло сметка за важността на тази роля в един Scrum проект. Смятах, че добрият продукт се определя най-вече от техническите качества на екипа. С течение на времето обаче осъзнах в колко голяма степен един ProductOwner може да повлияе за успеха (и респективно неуспеха) на проекта в много различни аспекти.

По време на имплементацията екипът навлиза в много детайли и всеки от членовете му работи върху конкретни аспекти на продукта. Понякога за тях е трудно да запазят общата картина и да не се отклоняват или пък да взимат най-добрите за цялостния продукт решения. ProductOwner-ът е този, който през цялото време поддържа продуктовата визия и държи екипа фокусиран върху постигането й. Това е особено важно, когато има много заинтересовани лица (stakeholders) с различни, дори противоречиви изисквания. Без ясна визия, решението за това какво трябва и какво не трябва да се имплементира в продукта, би било много трудно, почти невъзможно. Но когато за ProductOwner-а е ясно какви сценарии трябва да поддържа продуктът, приоритизацията на изискванията става значително по-лесно.

За да бъде успешен проектът, екипът трябва да е истински отдаден и обещанието (commitment) да изпълни дадена част от продуктовия списък в спринта да не е само формално. Екипът трябва да се стреми към максимален резултат и да е мотивиран да увеличава скоростта си с всяка итерация. Разбира се, за добрата мотивация има редица фактори, но сред тях стои и отдадеността на самия ProductOwner. Съгласете се, че ако той/тя не идва на демотата в края на спринта например, или по време на итерацията не проявява никакъв интерес какво се случва, то и самият екип не би се чувствал така силно мотивиран да даде най-доброто от себе си и да предостави на ProductOwner-а това, което е поискал. ProductOwner-ът е част от Scrum екипа и като такъв трябва да е ангажиран и отдаден на проекта дори повече от останалите, тъй като той/тя е лицето на екипа пред клиентите.

Като част от Scrum екипа, ProductOwner-ът може да използва капацитета и знанията в него за детайлизирането и прецизирането на елементите от продуктовия списък. В моя опит много добре сработва съвместната работа особено с по-опитните членове от екипа, когато трябва да се уточнят архитектурни детайли. Като ProductOwner аз се фокусирам изцяло върху описанието на потребителските истории, а за техническите аспекти използвам „мозъчен тръст“ от архитекти и старши програмисти, от една страна, за да мога да приоритизирам изискванията правилно, а от друга – за да дам възможност на екипа да помисли предварително върху исканата функционалност и да може да планира по-адекватно за следващия спринт.

Естествено, в работата на ProductOwner-а съществено място заема работата с клиенти.  Всеки клиент иска да му бъде обърнато внимание, да сподели проблемите си, да бъде разбран от своя софтуерен доставчик и необходимият му софтуер да му бъде предоставен. В реални условия обаче е почти невъзможно да бъдат задоволени всички изисквания в необходимите срокове, защото обикновено проектите имат ограничен бюджет и ресурси, клиентите са поне няколко, а изискванията растат непрестанно. Ето защо ProductOwner-ът трябва да е в непрекъснат диалог с клиентите на продукта и да приоритизира правилно най-важните за тях функционалности в съответния момент, така че те да им бъдат доставени навреме. Същевременно, ако има неща, които клиентът би се радвал да  види в продукта, но определено не смята за твърде съществени, а няма достатъчно ресурси те да бъдат направени, ProductOwner-ът трябва да е в състояние ефективно да управлява очакванията и да подготви клиента за това. Прозрачният статус в края на всяка итерация заедно с по-дългосрочна визия от страна на ProductOwner-a дава сигурност на клиентите и намалява натиска от тях към екипа или компанията. При наличието на такъв открит диалог, ProductOwner-ът има известна доза влияние върху клиентите и може да позиционира успешно функционалност, която не е директно поискана от дадения клиент, но може да бъде добре приложена в неговите сценарии.

И така, ролята на ProductOwner е свързана с голяма отговорност – ако той/тя не си свърши работата добре, дори и силният екип не може да спаси проекта от провал. Същевременно тази отговорност носи голямо влияние върху проекта, екипа и дори клиентите. Правилното използване на това влияние би могло да гарантира голям успех на екипа и на продукта като цяло.

Все още си спомням ясно, когато преди 4 години в екипа, в който работех по това време, започна да се говори за Scrum. След еднодневен курс, в който ни запознаха с основите и правилата в този нов за нас, програмистите, процес, изпитвах любопитство и известна доза нетърпение да разбера дали теорията, която звучеше доста убедително, наистина може да се приложи на практика. Изглеждаше ми перфектно – когато имам проблем извън програмирането, като например с инфраструктурата или невъзможност да намеря правилния контакт с необходимите знания, се намесва „нинджа“, който да се справи с всичките ми проблеми и аз да мога да се отдам напълно на любимото си занимание – да програмирам. Щеше да има яснота какво правим, защо го правим, а на всичкото отгоре ние самите щяхме да решаваме как да го правим. Какво повече от това можех да искам от текущата си работа.

Разбира се, началото не беше много лесно. Имаше доста лутане между това какво е правилно и какво не, какво трябва да докладвам като пречка на сутрешните срещи, какво трябва сама да свърша; как да планираме нещо, за което нямаме представа какво ще представлява, и да се подпишем, че ще го свършим навреме. В началото не беше лесно да се отърсим от това, че ни трябва някой, който да ни каже какви за ни задачките и за колко време сме длъжни да го направим. Свободата понякога е тежко бреме…

Най-хубавото дойде на ревюто, когато се представихме като горди собственици на нова функционалност – не мениджъра, НИЕ бяхме презентаторите, ние обирахме лаврите. Е, разбира се, не всички ревюта минаваха гладко, случваше се и да се изчервим заради несвършена работа, но беше хубаво сами да отговаряме за постиженията си или неуспехите.

Когато минах към нов проект, с радост разбрах че ще работим по Scrum. Макар че леко ме притесняваше факта, че всички сме нови по темата, половината даже нови за фирмата. Как ли щяхме да се справим… Още на първото ревю изненадахме себе си, а и всички заинтересовани страни- мениджъри, колегите от чужбина, които работеха директно с клиенти. В един момент проектът се превърна в невероятен успех, който ни даваше все повече сили и гордост , за да продължим да творим и да се опияняваме от постиженията си. И до момента това е любимия ми проект, който ме караше да се чуствам горда, че създавам нещо смислено и разбираемо за мен, оценено от останалите и по начин, който на мен ми харесваше. Екипът беше много сплотен и много силен заедно. Огромно влияние имаха Product Owner-а, който винаги знаеше какво иска и защо го иска, можеше да обясни гледната точка на клиента по един много убедителен начин, и Scrum Master-a, който беше силното рамо, на което можеше да се подпрем при проблем, както и беше човека, който ни насочваше деликатно по правилния път към перфектното „скръмиране“.

Една от най-полезните срещи, която провеждахме, беше ретроспективата – момента, в който си правехме равносметка, поздравявахме се за успеха и анализирахме пропуските и слабостите си с цел да ставаме все по-добри и по-добри.

В следващите години като Scrum Master често си припомнях опита си като член на Scrum екипа и мисля, че това ми помогна много да модерирам и други успешни проекти.

Scrum се оказа много полезен процес, който променя малко или много живота на човек, отношението му към ежедневието, към работата, която върши, и дори към модела му на поведение. Пожелавам на всеки, който реши да пробва Scrum, да има късмета да усвои процеса добре и да се наслади на резултатите, които ще постигне.

Може би сте чули тези понятия или някой вече ви е разказал за какво става въпрос, но искате да научите повече. Ето какво е важно да знаете и от къде да черпите информация.

Lean е философия, която разчита на силата, знанията и отдадеността на хората (empowered team) и на желанието за постоянно подобрение (kaizen/continuous improvement). Друг основен фокус в Lean е елиминирането на ненужни дейности (eliminate waste) и фокусирането върху дейности които правят продукта по-добър (value map stream). Има набор от методи, които се причисляват към Lean методологиите – Pull principle, JIT (Just in Time), Flow, Zero Defect, Stop the line.

Произлиза от Японското автомобилостроене, но в края на 90-те години е адаптирано и за софтуерното производство и намира все по-широко приложение. Като цяло се разчита, че хората от екипа, които произвеждат продукта, вършат най-важната работа и затова мениджърите по-скоро служат и помагат на екипа отколкото да казват как да се направи. Това разбира се изисква високо самосъзнание, отговорност, желание за постоянно самоусъвършенстване и работа в екип.

Полезни връзки свързани с Lean:

Wikipedia ; Scaling lean and agile – Craig Larman (amazon); Lean Primer; Implementing Lean Software Development: From Concept to Cash – Mary Poppendieck (amazon)

. . .

Scrum е една от Agile методологиите, които имат малко по-формални правила. Правилата са в 3 области:

• точно 3 дефинирани роли – Scrum master, Product owner и Екип;
• определени ритуали (срещи), които са ограничени по време – Daily Scrum, Planning, Review;
• определени артефакти – Product Backlog, Sprint Backlog, Burndown chart.

Тези правила са дефинирани по такъв начин, че от една страна да дават голяма свобода на екипа от друга го дисциплинират и фокусират.

Product owner отговаря за визията на продукта, дефинирането, работа с клиентите по изискванията и приемане на свършената работа.

Scrum master е пазителя на процеса, той защитава и помага на екипа, като премахва всички препятствия пред тях, за да свършат по-бързо работата.

Екипът е съставен от всички необходими хора със съответната експертиза, така че да може да завършва напълно дадена функционалност от продукта в края на всеки спринт.

Клиента присъства на всяко Review, което е в края на 2 до 4 седмичен спринт. Екипа планира в началото на спринта приоритизиран Product Backlog, който се застопорява и не се променя за тези 2 до 4 седмици и демонстрира накрая постигнатия резултат. Product owner и клиентите може да обсъдят резултата и да решат как да продължат. По този начин клиента редовно и на малки интервали получава нещо работещо и се избягват недоразуменията и скъпите поправки, както излишна функционалност.

Полезни връзки свързани със Scrum:

За начинаещи: Wikipedia; Scrum Alliance – what is Scrum; Scrum guide; Agile manifesto; Scrum startup reading; Agile Project Management with Scrum (Microsoft Professional) by Ken Schwaber;

За напреднали: Agile Estimating and Planning by Mike Cohn ; Succeeding with Agile: Software Development Using Scrum by Mike Cohn; User Stories Applied: For Agile Software Development by Mike Cohn; Agile Retrospectives: Making Good Teams Great by Esther Derby

Други полезни сайтове: InfoQ ; Rally ; MikeCohn

Инструменти: Agilo; VersionOne; Jira; Rally; Open Source Review