У претходном тексту сам покренуо причу о лошим навикама у Скрам тимовима, које на крају неизбежно доводе до неуспеха у испоруци. Сада бих желео да продубим ову тему, фокусирајући се на функционалне процесе у тиму.
Ови процеси су једнако важни као и техничка експертиза тима. Чак и ако су чланови тима врхунски стручњаци у својим областима, постоје аспекти који могу угрозити њихов рад. Ово неће нужно бити њихова грешка, већ директна последица одлука о управљању пројектом и способности да се тиму обезбеде процеси који су прикладни и подржавају тим са јасним циљевима и предвидљивим активностима.
Тим са оштро подељеним вештинама
Замислимо тим пун вештих програмера који самостално и тачно испоручују договорени садржај спринта у задатом року. Чак и у таквом идеалном случају (који је, реално гледано, мало вероватан), тим ће имати потешкоћа да прати све већи број функција ако су вештине чланова тима строго раздвојене.
Неколико примера
- Тим има једног или двојицу DevOps инжењера који су задужени за све измене аутоматизованих токова и одржавање сервиса на платформи, док остатак тима нема основно знање о тим процесима. Током Скрам састанака, дискусије о таквим темама постају губљење времена за већину тима, јер не могу да учествују. Са друге стране, DevOps инжењерима неће бити занимљиве остале теме које се односе на функционалности, па и за њих време на састанцима постаје бескорисно.
- Постоји само један специјалиста за базе података у целом тиму. У зависности од сложености система који тим развија, овај члан може бити константно преоптерећен захтевима који се не могу завршити довољно брзо. Што је још горе, остали задаци ће морати да чекају јер зависе од извора података које овај специјалиста обезбеђује.
- Када је пројекат углавном усмерен на развој позадинских процеса, један једини програмер за развој корисничког интерфејса је ту „за сваки случај“ (јер је, ипак, с времена на време потребна нека мања измена). У таквом случају, већина Скрам састанака представља губљење времена за овог члана тима, јер је његово знање ограничено само на кориснички интерфејс, и ништа друго му није битно.
Коначан исход
У свим наведеним ситуацијама, људи или губе време, или нису у стању да испуне све захтеве. Они блокирају остатак тима да започне са радом на следећим задацима, или се укупна ефикасност Скрам тима смањује због превише неискоришћеног времена током спринта.
Ипак, тим и даље има одређен број програмера. На први поглед се не види да неки чланови тима нису у могућности да преузму неке задатке јер су превише специјализовани. Дакле, не могу да помогну осталим члановима, чак и ако би имали капацитет за то, и ако би приоритети то дозвољавали.
Чак је и руководиоцу пројекта тешко да осмисли смислен садржај спринта за тим, јер увек мора да води рачуна о томе колико чланова може да ради на сваком појединачном задатку. Ако се више сличних задатака убаци у спринт у исто време, капацитет тима се прекорачује, чак и ако постоје људи који би могли да раде на тим задацима, али немају потребне вештине.
Решавање дилеме
Ово је дилема коју треба решити, а менаџери пројекта морају бити свесни могућих приступа. Конкретно, треба размотрити:
- Имати велики број програмера који могу радити на различитим задацима, али нису стручњаци за све области. Овај приступ омогућава брз напредак, али квалитет може бити угрожен.
- Имати специјалисте за сваку технологију, али прихватити ограничења и радити на прилагођенијим задацима. Овај приступ омогућава детаљан рад и квалитетне резултате, али захтева последовано обрађивање задатака, што продужава време испоруке.
Слаб руководилац производа
Ово можда није „процесно питање“ у правом смислу, али га тако третирамо јер се креирање јасних и чврстих задатака може сматрати процесом који тим треба да жели да усвоји.
Када говоримо о слабом руководиоцу производа, не мислимо на његово знање, већ на способност да тиму обезбеди задатке које програмери могу да разумеју и који имају јасан смисао у контексту мапе пута производа. Оба аспекта су веома битна за успешан Скрам тим.
Ако задацима недостају детаљи како би програмери разумели њихову сврху, функционалну вредност или техничка очекивања, могу се десити два сценарија:
- Програмери ће направити нешто друго од онога што је руководилац производа желео. Ово је тешко приметити током самог спринта, јер руководилац производа обично нема детаљан увид у напредак задатака и очекује да се све одвија „магично“.
- Програмери ће провести превише времена разјашњавајући задатке и дискутујући о њима уместо да почну са радом. Ово укључује додатне састанке, поновљене договоре и одлагање посла за каснију фазу спринта. Тада се првобитне процене за задатке више не могу сматрати тачним, и задаци се не могу завршити у спринту, па се преносе у наредне спринтове. У најгорем случају, ситуација се понавља у наредним спринтовима.
Време за саморефлексију
Иако је то често тешко признати, руководилац производа треба да одвоји време да размисли, прегледа задатке у заостатку и упореди их са визијом мапе пута производа. Ако не постоји веза између њих, то је прво што треба поправити. Понекад је решење признати да је руководилац производа превише удаљен од тима и својих циљева.
У том случају, треба размотрити промене у тиму руководиоца производа. Ангажовање пословног аналитичара који је више фокусиран на садржај тима (а не на пословни садржај, за шта је већ задужен руководилац производа) може бити добро решење, иако то може повећати укупне трошкове тима.
Процеси тестирања без фиксног распореда
Шта ако активности тестирања немају јасан распоред у Скрам спринту?
На први поглед, ово може изгледати као добра ствар за агилни/Скрам тим. Флексибилност је увек пожељна и добро звучи споља.
Међутим, моје искуство показује да ова слобода често доводи до хаоса, а не до флексибилности. То не значи да треба увести „водопадни приступ унутар спринта“, са посебним фазама тестирања одмах након завршетка развоја. То није прави приступ. Више о томе можете прочитати у мојим текстовима о стратегији Скрам тестирања и животном циклусу агилног тестирања.
Треба задржати одређену флексибилност и изабрати распоред тестирања који је најприкладнији за тим и карактеристике производа. Ипак, постоје два главна циља која треба постићи:
- Минимизирати прекиде у развојним активностима током тестирања.
- Обезбедити да тестирање буде чврста (са становишта садржаја), поуздана и предвидљива активност.
Ако се ови услови испуне, тим ће се природно прилагодити процесу, и распоред испоруке неће бити угрожен непланираним продуженим тестирањем.
На крају, најважнији је поуздан и предвидив спринт, што нас доводи до последње теме.
Недефинисан процес издавања
Ово је очигледно битна ствар за сваки Скрам тим, али је често потцењена.
Често Скрам тимови кажу да ће издавање бити на крају сваког спринта, али то није поткрепљено јасним процесом. У пракси се тада дешавају хаотичне и непредвидиве активности током издавања. Одједном су сви преокупирани „задацима издавања“, и нико није у могућности да се фокусира на развој нових задатака. Метрике спринта су нарушене, а издавање изгледа као насумична и непредвидива активност споља (најчешће клијентима).
Тим је толико фокусиран на заостатак, садржај спринта, развој, тестирање и презентовање резултата, да заборављају да након свега тога, следећи спринт већ почиње, и они губе време.
Тражење правог времена за издавање
Дакле, када тачно тим треба да изврши издавање у продукцију? То је на крају једино што је заиста важно.
Одговор на то питање лежи у процесу, под претпоставком да постоји. Зависи од:
- сложености садржаја који тим производи током спринтова,
- трајања спринта,
- броја укључених компоненти у систему,
- броја корисника који користе систем и траже измене.
Потребно је успоставити поновљиви процес издавања и пратити га у будућности. Правила процеса могу бити флексибилна, али је важно да се тим придржава процеса и да он постане дуготрајна навика.
Избори за одабир
Могући облици таквог процеса су:
- Завршити тестирање функција из текућег спринта током наредног спринта, и објавити садржај на крају тог наредног спринта (када се тестирање заврши). То значи да свако издање неће садржати нови садржај из последњег спринта, већ садржај из претходна два спринта.
- Последњи спринт пре издавања је увек посвећен тестирању садржаја из претходна два спринта.
- То не значи да ће развој током „тестног спринта“ бити заустављен, већ само да садржај развијен током тог спринта неће бити укључен у следеће издање.
- Ако већ постоје аутоматизовани процеси тестирања, онда извршити издавање на крају сваког спринта. Ово мора бити строг процес са посвећеним члановима тима који се 100% фокусирају на те процесе током неколико дана. И даље не би требало да утиче на остатак развојног тима.
- Такође је могуће издавати једном месечно, или једном у неколико месеци, ако то одговара крајњим корисницима. Ово ће повећати напор тестирања за сваки спринт (јер ће бити више садржаја за свако издање), али ће смањити број понављања активности, што може бити корисно за тим. То може омогућити тиму да развије више нових функција између издавања, иако ће функције бити објављене у продукцију споријим ритмом.
Као што је већ неколико пута поменуто, није толико важно који ће се процес изабрати, већ колико ће се тим добро придржавати изабраног процеса, и да он постане дугорочна навика.
Такође можете прочитати овај водич о процесима и праксама управљања издавањима.