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