Усі, хто читав книжки по Scrum'у, знають про правило непорушності обсягу спринта: Усе, що включили до спринт-беклогу на плануванні, має робитись; і не можна допускати жодних змін під час самого спринта!
У той же час усі, хто працював чи намагався працювати по Scrum'у, відчули, що виконання цього правила іноді коштує дуже багато зусиль, а бува - і добрих стосунків із ПО. Особливо важко буває коли треба і підтримувати вже випущений продукт, і одночасно робити нову функціональність.
Повз мене пройшли сотні "Великих Битв за Спринт", де енергійний, щойно просвітлений еджайлом скрам-майстер, зіштовхувався з не дуже начитаним, але дуже переконливим ПО. Часом перемагав скрам-майстер. Він (чи вона) тоді виглядав героєм: тепер команда може працювати без страху, що зараз таски втратять усю бізнесову цінність.
Але коли перемагав ПО, годі було шукати людину більш розгублену, ніж щойно впевнений у майбутньому скрам-майстер. У цьому випадку або треба було скасовувати весь спринт та влаштовувати нове планування, або продовжувати старий "зіпсований" спринт. І тоді лише горбочок на burn-down chart'і щодня нагадував про програний бій.
Після кількох таких боїв ПО і скрам-майстер, не бачачи іншого виходу, і задля чіткого планування домовляються, що не будуть змішувати в один спринт задачі з розробки нового та підтримку старого. І тоді народжується нове означення: Support Sprint. І його одразу ніхто не любить. ПО - тому, що доводиться відкладати термінові для бізнесу зміни аж туди. Команда - тому, що зазвичай все одно приходиться відкладати розробку чогось нового і цікавого на цілих 2 тижні і колупатися із старими багами. А коли раптом виявляється, що якусь задачу команда вже не встигне зробити у цьому спринті, і її заявнику доведеться чекати наступного суппорт-спринта, то страждають знову всі, і у першу чергу - бізнес.
То як можна було б позбавити страждань увесь цей гурт людей, і при цьому залишити за своєю методологією розробки величне ім'я "Scrum"? А найголовніше питання - як при цьому виконати основну ідею Agile: реагувати на зміни так, щоб і замовник, і команда залишалися щасливими?
Завдяки одній зміні у плануванні і одному додатковому полю до кожного тікета:
* При плануванні спринта закладіть буфер для вирішення термінових задач з підтримки, що мають бути зроблені негайно, та що їх не можна було передбачити та запланувати.
* До всіх задач, або принаймні до задач із підтримки, додайте поле "Class of Service" із наступними значеннями:
Ідея поля "Class of Service" чи "класів обслуговування" прийшла від організації роботи інженерів підтримки. Самі вони працюють згідно Канбану (Kanban). І ми, власне, оцим буфером просто вставляємо невеличкий потічок Канбану у наш зовні дуже ортодоксальний Скрам.
(На моєму проекті моєму бізнесу було зручно назвати це поле "Severity", але це не узгоджується із визначенням, яке дає для "Severity" ISTQB, то ж вирішуйте самі.)
Це, звичайно, не срібна куля, й усі проблеми навряд чи вирішить, але спробувати варто, а особливо з молодими норовливими скрам-майстрами, що дуже люблять книжки і методички.
Щодо вузьких місць цього підходу, одразу може здатися, що нахабні бізнес-піпли понаставлять ASAP на усі таски. Але із свого досвіду зауважу, що зі мною так не сталося. Почасти тому, що я зробив значенням за замовченням у цьому полі "Standard". І ще раджу зробити це значення видимим і на дошці спринта, і в беклозі, аби нічого не проґавити.
Прошу коментувати! Якщо вас цікавлять якісь деталі, чи "як це зробити у JIRA?" - дайте знати, допишу.
У той же час усі, хто працював чи намагався працювати по Scrum'у, відчули, що виконання цього правила іноді коштує дуже багато зусиль, а бува - і добрих стосунків із ПО. Особливо важко буває коли треба і підтримувати вже випущений продукт, і одночасно робити нову функціональність.
Повз мене пройшли сотні "Великих Битв за Спринт", де енергійний, щойно просвітлений еджайлом скрам-майстер, зіштовхувався з не дуже начитаним, але дуже переконливим ПО. Часом перемагав скрам-майстер. Він (чи вона) тоді виглядав героєм: тепер команда може працювати без страху, що зараз таски втратять усю бізнесову цінність.
Але коли перемагав ПО, годі було шукати людину більш розгублену, ніж щойно впевнений у майбутньому скрам-майстер. У цьому випадку або треба було скасовувати весь спринт та влаштовувати нове планування, або продовжувати старий "зіпсований" спринт. І тоді лише горбочок на burn-down chart'і щодня нагадував про програний бій.
Після кількох таких боїв ПО і скрам-майстер, не бачачи іншого виходу, і задля чіткого планування домовляються, що не будуть змішувати в один спринт задачі з розробки нового та підтримку старого. І тоді народжується нове означення: Support Sprint. І його одразу ніхто не любить. ПО - тому, що доводиться відкладати термінові для бізнесу зміни аж туди. Команда - тому, що зазвичай все одно приходиться відкладати розробку чогось нового і цікавого на цілих 2 тижні і колупатися із старими багами. А коли раптом виявляється, що якусь задачу команда вже не встигне зробити у цьому спринті, і її заявнику доведеться чекати наступного суппорт-спринта, то страждають знову всі, і у першу чергу - бізнес.
То як можна було б позбавити страждань увесь цей гурт людей, і при цьому залишити за своєю методологією розробки величне ім'я "Scrum"? А найголовніше питання - як при цьому виконати основну ідею Agile: реагувати на зміни так, щоб і замовник, і команда залишалися щасливими?
Завдяки одній зміні у плануванні і одному додатковому полю до кожного тікета:
* При плануванні спринта закладіть буфер для вирішення термінових задач з підтримки, що мають бути зроблені негайно, та що їх не можна було передбачити та запланувати.
* До всіх задач, або принаймні до задач із підтримки, додайте поле "Class of Service" із наступними значеннями:
- ASAP - тобто задача потребує негайного вирішення, "немає часу на весь ваш 'скрум', чи як його там!" Саме для таких задач варто залишити буфер.
- Fixed date (сама дата, звичайно, має бути записана десь у іншому полі) - ці задачі можна запланувати, але не можна відтермінувати; вони потрібні саме тоді, коли сказано, і ніяк не пізніше. Той випадок, коли можна було б синхронізувати бізнес та Support Sprint, але немає сенсу, бо бізнес такий нерішуче-мінливий у своїх бажаннях.
- Standard - це звичайні задачі; вони приходять з беклогу продукта, плануються і робляться у спринті.
Ідея поля "Class of Service" чи "класів обслуговування" прийшла від організації роботи інженерів підтримки. Самі вони працюють згідно Канбану (Kanban). І ми, власне, оцим буфером просто вставляємо невеличкий потічок Канбану у наш зовні дуже ортодоксальний Скрам.
(На моєму проекті моєму бізнесу було зручно назвати це поле "Severity", але це не узгоджується із визначенням, яке дає для "Severity" ISTQB, то ж вирішуйте самі.)
Це, звичайно, не срібна куля, й усі проблеми навряд чи вирішить, але спробувати варто, а особливо з молодими норовливими скрам-майстрами, що дуже люблять книжки і методички.
Щодо вузьких місць цього підходу, одразу може здатися, що нахабні бізнес-піпли понаставлять ASAP на усі таски. Але із свого досвіду зауважу, що зі мною так не сталося. Почасти тому, що я зробив значенням за замовченням у цьому полі "Standard". І ще раджу зробити це значення видимим і на дошці спринта, і в беклозі, аби нічого не проґавити.
Прошу коментувати! Якщо вас цікавлять якісь деталі, чи "як це зробити у JIRA?" - дайте знати, допишу.
Немає коментарів:
Дописати коментар