Як команда Scrum враховує інфраструктурні завдання на нараді планування?

Як команда Scrum враховує завдання розробки / інфраструктури на зустрічі з планування?

На перший погляд, вони не здаються історіями користувачів, оскільки не доставляють цінність для кінцевого користувача.

Однак приєднання їх як завдань до певної історії користувача іноді також не має сенсу. Наприклад, скажіть, що завдання таке: "Налаштування бамбука". Це завдання не потрібно для завершення будь-якої історії користувача, оскільки команда може вручну створювати та розгортати. Тому приєднувати його до історії користувача немає сенсу, оскільки це завдання не потрібно для завершення історії користувача.

Отже, це говорить про те, що ці завдання стають історіями користувачів. Але, якщо командна історія вказує на них, то це змінює швидкість, яка є дивною, оскільки Власник продукту хоче знати швидкість проти його відставання, а не проти його відставання з купою технічних історій користувачів, що додаються до нього.

Вони насправді не користувацькі історії. Вони є історіями зацікавлених сторін. Якщо програмне забезпечення насправді не оплачується безпосередньо користувачами, рідко історія створюється повністю на їх користь.

Я наводжу вам кілька прикладів:

• статті з ключовими словами, які дозволяють рекламодавцям мати більш ефективні рекламні оголошення
• CAPTCHA, які є для того, щоб зупинити модераторів, які мають справу зі спамом вручну.

Більшість технічних історій насправді приносять користь бізнесу, але це рідко для користувачів. Фразування їх по-іншому може допомогти. Я звичайно використовую шаблон Кріса Матта "Feature Injection":

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Це чітко визнає всі види зацікавлених сторін, включаючи команду з розвитку. Тепер ви можете також сформулювати свої технічні історії, закликаючи вигоди для бізнесу:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

Про це я написав кілька публікацій у блозі: Вони не Історії користувачів , а Ін'єкції та керування технічними розповідями . Сподіваюся, вони допоможуть.

Швидкість - це міра здатності команди виконувати корисну роботу (на відміну від Drag). Завдання інфраструктури все ще приносять цінність кінцевому користувачеві, хоча і опосередковано, завдяки чому команда в довгостроковій перспективі стає більш ефективною. У мене немає проблем відстежувати ці речі як історії користувачів (у цьому випадку користувач - команда розробників) та визначати їх пріоритетним чином. Власник продукту, що має добру комунікацію із замовниками (клієнтами), повинен мати можливість зрозуміти, куди такі завдання можуть вміщуватися, не порушуючи результати роботи.

Робіть їх поступово.

Якщо жоден із зацікавлених сторін не хоче цього, не робіть це історією. Просто подбайте про це, трохи за раз. Наприклад, перший раз, коли ви розгортаєтесь вручну. Вдруге ви трохи автоматизуєте це. Втретє ви автоматизуєте трохи більше. Врешті-решт, ваша збірка не є найбільшою проблемою, тому ви зосереджуєтесь на чомусь іншому.

У вас буде більше цих завдань, орієнтованих на розробників, на початку, і це добре; ваша швидкість (виміряна історіями) буде просто нижчою. Це правильне уявлення про ситуацію. Але у вас завжди буде щось, тому команді важливо ввійти в звичку робити те, що необхідно для вдосконалення процесу.

ІМХО ідеальним підходом є розміщення зусиль інфраструктури як завдань під історією користувача, де вона вперше має значення; як ви вже згадували.

Беручи свій приклад; Ручне створення та розгортання означає, що це постійне зусилля і не має форми завершення. Він існує нескінченно.

Те саме можна сказати і для коду, який автоматизує будь-яку частину зусиль у типовому додатку, який раніше робився вручну. Визначення цього зусилля як завдання в історії користувача визначає завершеність; що за своєю суттю має значення для кінцевого споживача.

Ви, звичайно, можете створювати та розгортати додаток кожен спринт, але це стає частиною щоденних завдань, які формально не відслідковуються через відставання, і тоді все це стає суперечливим.

Історії користувачів визначають значення економічної орієнтації з точки зору користувача. Через це інфраструктурні завдання, як правило, розглядаються як "відходи". Це не означає, що вони не потрібні. Це означає, що виконання додаткових інфраструктурних завдань призведе до меншої вартості бізнесу. Зважаючи на це, інфраструктурні завдання не повинні розглядатися як користувацькі історії та не повинні додаватися до будь-яких історій користувача.

На плановій нараді команда повинна розглянути, які завдання інфраструктури будуть абсолютно необхідні під час наступного спринту. Зобов'язання буде виконано з урахуванням цих інфраструктурних завдань. Це вплине на швидкість команди, що є правильним результатом, оскільки швидкість вимірює, наскільки цінність бізнесу може надати команда.

Я ніколи не прирівнював розповіді користувачів до того, щоб доставити цінність кінцевому користувачу. Це може бути загальним, але це не так, як ми обробляємо історії користувачів. Іноді такі типи завдань вважаються шипами, але ми також мали регулярні історії користувачів, які оцінювались як і будь-які інші користувацькі історії.

З того, що я бачив, значна частина інфраструктури вважається даною. Сюди входять такі речі, як:

• Система контролю ревізії;
• Автоматизована система побудови;
• IDE та інші інструменти для розробників;
• Сервери розробки;
• Процес розгортання; і
• Процес проекту та стандарти.

Більшість методологій, з якими я працював, не приділяють їм великої уваги. Вони формують те, що я називаю випуском 0. Ці речі повинні бути на місці, перш ніж почати розробку. Після того, як ви почнете працювати над історіями, будь-які зміни в цих речах можна відстежити як поліпшення процесу.

Незважаючи на те, що команда розробників може мати вклад, більшість із цих елементів повинна опрацьовуватися командою підтримки проекту. Стандартизація цих елементів у кількох проектах повинна мати значну віддачу організації.

Розглянемо наступне:

• Команда Scrum додає основні функції до існуючого набору продуктів.

• Існує потреба в удосконаленні технології розвитку / інструментів / утиліт, щоб залишатися в курсі, спираючись на найкращі інженерні практики.

• Має сенс завантажувати випуск за допомогою цього твору, щоб у ході випуску проблеми Sprints могли бути вирішені.

• Оскільки бізнес отримує опосередковану цінність від цих позицій, я вважаю, що в інтересах прозорості це елементи " Блокування товарів" (PBI).

• Команда розміщує ці предмети та ставиться до них як до будь-яких ІПВ.

Ця проблема для мене зводиться до того, що я не хочу витрачати час на спроби з'ясувати, як приховати цю роботу як завдання під іншими більш бізнес-орієнтованими ІТП.

Я не хочу, щоб розміри PBI були перекошені внаслідок такої інфраструктурної роботи. Я хочу побачити, що робиться, і зрозуміти, за що я плачу.

Я також думаю, що є цінність у тому, щоб команда зрозуміла зобов'язання, які бере на себе бізнес, інвестуючи в інфраструктуру, необхідну для забезпечення якісних рішень.

XP рекомендує запропонувати "нуль ітерації", де встановлені всі інструменти та інфраструктура. Писати розповіді для них необов’язково, але, мабуть, це гарна ідея. Можливість тестування вашої інфраструктури (інкрементальна збірка, автоматизоване тестування та розгортання, повідомлення тощо) корисна

У нашій команді ми робимо наступне:

1. Припустимо, менший фактор фокусування .
2. Спробуйте включити такі завдання в історії користувачів, які насправді потребують їх виконання.
3. Якщо деякі завдання є абсолютно необхідними, але не мають прямої ділової цінності (наприклад, міграція тестових одиниць з однієї рамки на іншу), на початку спринту ми створюємо список "безперервних завдань" . Це завдання, пов'язані з розвитком, які не є історіями, але команда розробників хоче, щоб вони були виконані. Ми перелічуємо ці завдання на нашій дошці, зберігаючи їх окремо від історій. Під час спринту на кожній щоденній зустрічі ми переглядаємо, що було зроблено для їх виконання.

Крок 2 - найважливіший. Як і в спритній практиці, в Scrum ви намагаєтеся зробити якомога менше, щоб виконати свої завдання. Прийміть це як спосіб не витрачати своє життя на непотрібну роботу: мій досвід показує, що цілі 50% речей, що закінчуються, залишаються покинутими та без збереження в довгостроковій перспективі.