В моята предишна статия започнах дискусията около лошо развитите навици в scrum екип, които в крайна сметка ще доведат (рано или късно) до провал в доставката. В тази статия бих искал да разширя тази тема още веднъж и сега да се съсредоточа върху функционалните процеси в екипа.
Те са също толкова важни, колкото и техническото съвършенство на отбора. Дори ако хората вътре са суперквалифицирани за работата, която ще изпълняват, все още има области, които могат да съсипят усилията им за съвършенство. И това няма да е толкова тяхна вина, колкото ще бъде пряка отговорност за решенията за управление на проекта и тяхната способност да обслужват екипа с подходящи за целта процеси, за да подкрепят екипа с ясно намерение и предвидими дейности.
Съдържание
Силно сегрегиран екип с различни умения
Представете си, че екипът разполага с квалифицирани разработчици, съвършено независими и способни да спазват обещанията си и да предоставят договореното съдържание за спринта точно навреме преди края на спринта. Дори при такъв перфектен сценарий (който така или иначе е много малко вероятно да се случи), екипът ще има проблеми да се справи с (постоянно нарастващите) функции за изоставане, ако уменията са строго разделени между членовете на екипа.
Няколко примера
- Екипът разполага с 1 или 2 DevOps инженери, способни да направят всякакви промени в автоматизираните тръбопроводи или да се грижат за услугите вътре в платформата, но останалата част от екипа няма представа за подобни неща. След това обсъждането на тези истории на церемонии за схватка, като усъвършенстване, ще доведе до загуба на време за по-голямата част от екипа, като остане на срещата без никакво участие и обратното – разработчикът на DevOps няма да има интерес към останалите истории, ориентирани към функционалността, и времето за срещата също ще бъде най-вече загубено.
- Има един експерт по база данни за целия екип. В зависимост от сложността и използването на решенията за данни в системата, която екипът разработва, този човек може да бъде постоянно претоварен с истории, които няма шанс да завърши достатъчно скоро, особено когато се вземат предвид техните приоритети. Дори по-лошо, други истории също ще трябва да почакат, тъй като те зависят от източника на данни, предоставен от историите на базата данни.
- Когато конкретен продукт е ориентиран предимно към бекенд разработка, единственият фронтенд разработчик е там за всеки случай (защото от време на време е необходима малка промяна дори в UI приложението). В този случай, отново, повечето от скръм церемониите са загуба на време за този член на екипа, тъй като техните знания са ограничени само до предния край и нищо друго няма значение.
Където завършва
Във всеки от горните случаи резултатът е, че хората или губят времето си, или, алтернативно, не са в състояние да наваксат изоставането в търсенето. Те блокират останалата част от екипа да започне работа по следващите истории или ефективно намаляват цялостната ефективност на екипа за схватка, защото има твърде много време, което не се използва в рамките на спринта.
Екипът обаче все още има този брой разработчици. Отвън не се вижда (дори не иска да се излага), че хората в екипа не могат да поемат някои истории, само защото са твърде ориентирани към някакъв специфичен набор от умения. Така че те не могат да помогнат на другите членове на екипа с историите, дори ако капацитетът им би позволил това, а приоритетите за истории също биха го облагодетелствали.
Дори е трудно за собственика на продукта да състави някакво смислено съдържание за спринта за екипа, тъй като собственикът на продукта винаги трябва да има предвид колко хора могат да работят върху всяка отделна история и дали повече подобни истории се включват в спринта едновременно , в крайна сметка капацитетът на екипа е препълнен, дори ако в действителност има хора, които биха могли да работят по тези истории, но те нямат набор от умения да започнат с тях.
Разрешаване на дилемата
Това е дилема, която трябва да бъде разрешена, а ръководителите на проекти трябва да са наясно какъв маршрут да изберат. По-конкретно, избор между:
- Наличие на много разработчици с пълен стек, способни да работят върху по-широко съдържание, но не и експерти по много теми. Така че те могат да отидат широко, но не и дълбоко. Тогава доставката може да напредне бързо, но качеството може да пострада.
- Наличие на специализирани експерти за всяка технология, но след това приемане на ограничението и работа по-усърдно върху по-добре напаснато печатно съдържание. Тогава хората могат да се задълбочат и да създадат страхотни истории, но към историите ще трябва да се подхожда последователно, като по този начин ще отнеме повече време за предоставяне.
Слаб собственик на продукта
Това не е непременно „проблем на процеса“ по дефиниция, но аз го третирам така, само защото създаването на солидни истории може да се разбира като процес, който екипът трябва да иска да бъде стабилен и съвместим с екипа за разработка.
Това, което имам предвид под слаб, не трябва да се отнася до свойството знания на дадено лице, а по-скоро до способността на собственика на продукта да обслужва екипа с истории, които разработчиците могат да разберат и които имат някакъв ясен смисъл от гледна точка на пътната карта на продукта. И двете са много важни за успешен скръм екип.
Ако в историите липсват подробности за разработчиците, за да могат ясно да разберат целта, функционалната стойност или техническите очаквания, тогава могат да се случат основно два сценария:
- Разработчиците ще създадат нещо различно от това, което собственикът на продукта всъщност е искал. Дори е трудно да се улови по време на самия спринт, защото най-вече собственикът на продукта не е имал възможността да проследи напредъка на историите на толкова подробно ниво и най-вече PO просто ще очаква нещото да се случи (магически).
- Разработчиците ще отделят твърде много време за изясняване на историите и обсъждането им отново и отново, вместо да започнат да ги изграждат. Това включва много допълнителни обаждания, повтарящи се споразумения и отлагане на работата до късната фаза на спринта. Достига точка, в която първоначалните оценки за историите вече не могат да се считат за точни и историите не е възможно да се затворят в рамките на спринта и се пренасят в следващите спринтове. В най-лошия случай ситуацията се повтаря в следващите спринтове.
Време за саморефлексия
Обикновено е трудно да се признае, но собственикът на продукта трябва да намери време да разсъждава, да разгледа създадените неизпълнени истории и евентуално да го сравни с визията на продуктовата пътна карта, ако все още има някаква разумна връзка между тези две – ако има някаква пътна карта изобщо. Ако не, това е първото нещо, което трябва да се реши. Понякога решението е да признаете, че собственикът на продукта е твърде далеч от екипа и твърде далеч от собствената цел.
В такъв случай частта от екипа, собственик на продукта, трябва да бъде решена. Ако не друго, включването в екипа на солиден бизнес анализатор, ориентиран повече към съдържанието на екипа, отколкото към бизнес съдържанието (за това вече имаме собственик на продукта в този случай), може да бъде валидна опция, към която да отидете, дори на цената на увеличени общи разходи на екипа.
Процеси на тестване без фиксирана времева линия
Какво ще стане, ако дейностите по тестване не са в съответствие с конкретен график в рамките на scrum спринт?
На пръв поглед това може да изглежда като нещо добро, което искаме за agile/scrum екип. Гъвкавостта винаги е добре дошла и звучи добре, когато се представя навън.
Моят опит показва, че резултатът от тази свобода е повече хаос, отколкото гъвкавост. Това не означава, че решението за това трябва да бъде създаването на „водопади в спринта“ със специални фази на тестване, последвани веднага след приключване на разработката. Това в никакъв случай не е правилният подход в случая. Можете да прочетете повече за това в моите публикации относно стратегията за тестване на скръм и жизнения цикъл на гъвкавото тестване.
Все още можем да позволим известна гъвкавост и да изберем графика за тестване, тъй като изглежда най-подходящ за текущия екип за разработка и дадените свойства на продукта, който екипът доставя. Има обаче две основни цели, които трябва да бъдат постигнати с този избор:
Ако тези условия бъдат изпълнени, екипът естествено ще се адаптира към процеса на монтаж и графикът за доставка няма да бъде повлиян от непланирани продължителни дейности по тестване.
В крайна сметка това, което има най-голямо значение, е надеждното и предвидимо освобождаване на спринта, което ме води до последната точка на този блог.
Недефиниран процес на освобождаване
Сега, това е толкова очевидно нещо за всеки scrum екип. И все пак, достатъчно любопитно, това обикновено е и един от най-подценяваните процеси.
Много често един scrum екип просто казва, че освобождаването ще бъде след всеки спринт, но това не е подкрепено от солиден процес. Това, което се случва тогава, в действителност е много хаотични, непредвидими дейности, които ще възникнат по време на освобождаването. Изведнъж всички хора са заети със „задачи за освобождаване“ и никой не е в състояние да се съсредоточи върху продължаването на разработването на нови истории за спринт. Показателите за спринт са изключени и освобождаването изглежда като произволна, непредвидима дейност от гледната точка на 3-то лице (обикновено клиента).
Хората са толкова съсредоточени върху изоставането, съдържанието на спринта, разработването, тестването и накрая демонстрирането на резултатите, че забравят, че след като приключат с всичко това, следващият спринт вече е в ход и те вече губят време.
Търся добър момент за освобождаване
И така, кога точно екипът трябва да направи действителното пускане в производство? Единственото важно нещо, което има значение в крайна сметка.
Отговорът на този въпрос е в процеса, ако приемем, че имате такъв. В зависимост от:
- сложността на съдържанието, което екипът създава в спринтовете,
- продължителност на спринта,
- брой на засегнатите компоненти в системата
- броя на хората, които използват и искат промените,
трябва да се установи процес на повторно освобождаване и да се следва занапред. Точните правила на процеса могат отново да бъдат гъвкави при дефиниране. Но както е с дейностите по тестване, превръщането му в стабилен навик, който е предвидим и планиран за конкретни дни в бъдещето, го прави нещо, на което да разчитате и да се позовавате.
Избор за избор
Възможните форми на такъв процес могат да бъдат някои от следните или други:
- Завършете тестването на функциите от текущия спринт по време на следващия спринт и освободете съдържанието в края на този спринт (след като тестването приключи). Това означава, че всяко издание няма да има съдържание от последния спринт, но ще съдържа истории от 2-та спринта преди това.
- Последният спринт преди пускането винаги е посветен на тестване на съдържанието от предишните два спринта.
- Това не означава, че развитието по време на „тестовия спринт“ ще бъде спряно; той само казва, че съдържанието, разработено в този тестов спринт, все още няма да бъде включено в следващото издание.
- Ако вече има достатъчно автоматизирани тестови дейности, стремете се да правите пускането след края на всеки спринт. Тогава това трябва да е много строг процес с посветени хора, фокусирани върху тези няколко дни на 100%. Все още не трябва да засяга останалата част от екипа за разработка по никакъв начин.
- Можете също така да изберете да пускате веднъж на месец или веднъж на N месеца, главно ако това е добре от гледна точка на крайните потребители. Това ще увеличи усилията от страна на тестването за всеки спринт (тъй като съдържанието ще бъде по-голямо за всяко издание). Но от друга страна, това ще означава по-малко количество повтарящи се дейности във времето, което в този случай може да има ползи за екипа. В резултат на това може да позволи на екипа да изгради повече нови функции между изданията, въпреки факта, че функциите действително ще бъдат пуснати в производство с по-бавен каданс.
Но както вече беше посочено няколко пъти преди, не е толкова важно кой от тези процеси ще бъде избран. Много по-важно е колко добре екипът след това ще се придържа към този процес и ще го превърне в труден навик.
Можете също да прочетете това ръководство за процеса и практиките за управление на изданията.