У Scrum, чи слід керувати такими завданнями, як налаштування середовища розробки та розвиток можливостей як підзадачі в межах фактичних історій користувача?

Іноді в проектах нам потрібно витратити час на такі завдання, як:

1. вивчення альтернативних рамок та інструментів
2. вивчення рамки та інструментів, вибраних для проекту
3. налаштування серверів та інфраструктури проекту (контроль версій, середовище побудови, бази даних тощо)

Якщо ми використовуємо Історії користувачів, куди слід піти всі ці роботи?

Один із варіантів - зробити їх частиною першої історії користувача (наприклад, зробити домашню сторінку для програми). Інший варіант - зробити шип для цих завдань. Третій варіант - зробити завдання частиною проблеми / перешкоди (наприклад, середовище розробки ще не вибране), а не користувача Story.

Ми досить багато думали над цією проблемою минулого року.

Хоча я погоджуюся, що основна рамка повинна існувати до початку проекту, але на практиці це може бути частиною самого проекту. Тож треба якось керувати.

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

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

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

Історії : Орієнтовані лише на перспективу бізнесу, історії завжди приносять помітну цінність для замовника. Внутрішня якість - це те, що поєднується з виробництвом вартості бізнесу.

Ми навіть присвоюємо завданням історії, а іноді працюємо з ними так само, як і з історіями.

Зрештою, я б запропонував це рішення у вашому випадку (яке можна було б застосувати і загалом):

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

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

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

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

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

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

Один з варіантів - зробити їх частиною першої історії користувача, наприклад, зробити домашню сторінку для застосування.

Розбиває "історію користувача" як концепцію. Який користувач бере участь у цьому? Немає. Це робота, яку ви вже повинні були виконати.

Ще один варіант - зробити для цього шип.

Непогано.

Третій варіант - зробити завдання частиною випуску (наприклад, середовище розробки ще не вибране), а не користувачам Story.

Приблизно те саме, що і шип, що стосується планування та накладних витрат.

Налаштування - це не історія користувача.

Це те, що ви повинні мати, перш ніж ви навіть розпочали цей проект.

Ви не можете реально розпочати проект, якщо у вас не буде налаштована рамка / інструмент та сервери та ви готові розпочати роботу.

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

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

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

Вони можуть не застосовуватися у вашому робочому середовищі, але вони добре працювали для нас.

Я думаю, ви змішуєте дві незалежні речі. Історія користувача не повинна містити технічних деталей.

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

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

Комусь новому в методології Scrum, як я, це здається фантастичним рішенням, оскільки він позбавляє вас історій користувачів та всіх інших аспектів нормального спринту, наприклад відгуків користувачів.

Оскільки Sprint 0 - це такий самий проміжок часу, що і ваші інші спринти, він виступає як спосіб гарантувати, що ви не витрачаєте занадто багато часу на налаштування речей, оскільки їх завжди можна буде виправити пізніше. Головний момент - потрапити в такий стан, коли ви можете реально почати розробку продукту.

про вивчення 2-3 альтернативних рамок / інструментів

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

потім, вивчаючи рамки, які ми вибираємо для проекту

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

Якщо вам справді доводиться використовувати щось особливе (наприклад, обраний клієнтський API чи замовник інструменту), яке ви ніколи не використовували, перш ніж ви повинні повідомити клієнта, що ціна буде збільшена на час, необхідний для того, щоб навчитися користуватися API. Можливо, клієнт передумає, якщо зростання цін буде занадто великим.

Звичайно, я не маю на увазі ситуацію, коли потрібно шукати якусь нову проблему в рамках, яку ти багато разів використовував. Я маю на увазі ситуацію, коли ви починаєте використовувати новий API або фреймворк, не витрачаючи значного часу (поза проектом) на навчання.

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

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

налаштування серверів (SVN, баз даних тощо)

Це ваша інфраструктура та внутрішні витрати. Коли ви запускаєте проект, очікується, що у вас буде підготовлена ​​ваша інфраструктура. Налаштування вашого середовища розробки не має значення для замовника і не повинно бути частиною будь-яких показників, пов'язаних з проектом - наприклад, швидкості в Scrum. Я бачив, що це реалізується як спеціальна ітерація перед проектом, яка використовується лише для налаштування середовища, створення базової інфраструктури тощо.