Поводження зі «пов’язаною» роботою в межах одного спритного робочого елемента

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

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

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

Коли ця зайва робота мала, ми не проти. Проблема полягає в тому, коли ця додаткова робота спричиняє істотне розширення елемента за межі початкової оцінки точок функції. Іноді предмет на 5 балів дійсно займе 13 балів часу. В одному випадку у нас був предмет з 13 пунктів, який в ретроспективі міг би становити 80 балів і більше.

У нашій дискусії є два варіанти, як впоратися з цим.

1. Ми можемо прийняти додаткову роботу в тому ж робочому пункті і списати її як неправильну оцінку. Аргументи для цього включали:

   • Ми плануємо "набивання" в кінці спринту для обліку такого роду речей.
   • Завжди залишайте код у кращій формі, ніж ви знайшли. Не перевіряйте в роботі на півроку.
   • Якщо ми залишимо рефакторинг на пізніше, це складно запланувати і, можливо, ніколи цього не зробити.
   • Ви зараз в найкращому розумовому "контексті", щоб впоратися з цією роботою зараз, оскільки ви вже в глибині коду. Краще вимкнути це зараз і бути ефективнішим, ніж втрачати цей контекст, коли повернешся пізніше.

2. Ми малюємо лінію для поточного робочого пункту і кажемо, що додаткова робота йде в окремий квиток. Аргументи включають:

   • Окремий квиток дозволяє отримати нову оцінку, тому ми не брешемо собі про те, скільки балів насправді є, або ми маємо визнати, що всі наші оцінки жахливі.
   • Спринт "набивання" призначений для несподіваних технічних проблем, які є прямими перешкодами для виконання вимог до квитка. Він не призначений для бічних предметів, які є просто "приємними".
   • Якщо ви хочете запланувати рефакторинг, просто поставте його у верхній частині відставання.
   • Немає можливості нам належним чином враховувати цей матеріал, оскільки він здається дещо довільним, коли він з'являється. Переглядач коду може сказати, що "ті елементи управління користувальницьким інтерфейсом (які ви насправді не змінювали в цьому робочому елементі) трохи заплутані, чи можете це виправити?" це як година, але вони можуть сказати: "Ну, якщо цей елемент керування тепер успадковується від того ж базового класу, що й інші, чому б вам не перемістити весь цей (сотні рядків) код у базу та перемотувати все це , каскадні зміни тощо? " А це займає тиждень.
   • Він "забруднює місце злочину", додаючи в квиток неспоріднену роботу, роблячи наші оригінальні оцінки функції безглуздими.
   • У деяких випадках додаткова робота відкладає реєстрацію, викликаючи блокування між розробниками.

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

Оскільки ми користуємось Agile лише декілька місяців, що думаєш з більш досвідченими ветеранами Agile тут, як з цим впоратися?

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

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

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

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

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

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

З огляду на це визначення та на те, щоб воно було дотримане, 5-покажчик, який виявляється 13-покажчиком, був помилковою оцінкою. Те, що ви вважаєте за роботу з реконструкції, ймовірно, більше нагадувало реструктуризацію; вам довелося реорганізувати досить значну область кодової бази, щоб нова функціональність була включена в зрозумілий, ремонтований спосіб. Зазвичай це вказує на невдачу команди зрозуміти загальний майбутній шлях розвитку, що призводить до того, що щось реалізовується дуже просто в попередній ітерації, коли в кінцевому підсумку потрібно буде бути дуже ТВОРНИМ. Краще спілкування між керівниками та прем'єр-міністрами, які знають, що далі в відставанні, та командою розвитку, яка, як правило, зосереджена на поточному спринті, може зменшити це. Крім того, ця історія виявила велику кількість технічного боргу, який виник у минулому розвитку, і це просто наздогнало команду. Кращі процеси перегляду коду, крім кращого концептуального знання моделей дизайну та загального майбутнього шляху проекту, можуть допомогти зменшити такі випадки.

Слід пам’ятати, що рефакторинг - це «неідеальна» робота. У Agile SCRUM завдання оцінюються в "ідеальні години"; тобто кількість годин, проведених вниз з написанням абсолютно нового коду, який ніколи не існував, і сприяє розширенню базових можливостей проекту. 8-годинний день розробника може реально мати лише 5 ідеальних годин; іноді можна розраховувати на 6, особливо в "розтягуванні" проекту, де команда справді гуде. Рефакторинг або повернення назад та внесення змін, які не впливають на функціональність проекту, але покращують кодову базу іншими способами, не є ідеальною роботою, як планування, проектування, спілкування, огляд, перерви або технічні простої. Крім технічного простою, неідеальна робота є важливою, але не робить прогресу в очах власника товару.

Отже, за умови, що рефакторинг не подвоює фактично витрачених годин, слід очікувати певного обсягу робіт по рефакторингу, коли ви оцінюєте в ідеальні години. Скажімо, тому що я не знаю точно, як відкалібровано бальну шкалу вашої команди, що 5-покажчик еквівалентний одному ідеальному тижні розробника, або приблизно 25 ідеальних годин. Саме 5, який перетворився на 13 (більше двох тижнів розробника за однаковою шкалою), є причиною для деякої ретроспекції того, що спричинило складність повітряної кулі. Можливо, кодова база не потребувала стільки рефакторингу, як це було зроблено насправді, можливо, велика кількість технічної заборгованості накопичилася невідомо для команди, яку довелося вирішити, щоб нові функції спрацювали,

У альтернативному Всесвіті, давайте уявимо, що 5, як оцінюється, в ідеальні години, стало 7 (~ 35 годин) на основі фактичних годин, тому що вам знадобилося 10 годин додаткового рефакторингу, щоб помістити новий код і деякі попередні біти в правильний малюнок архітектура дизайну. У такому випадку додаткові знаходяться в межах "розриву" між ідеальною та загальною кількістю годин протягом кількості днів розробника, на які повинна була пройти історія. Отже, як керівник проекту, я назвав би 5, який став 7 розумною оцінкою, і продовжувати.

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

1. Розбийте історії до тих пір, поки вони не будуть в узгодженому діапазоні (3, 5 або 8 балів)
2. Припустимо, що історія включає будь-який необхідний рефакторинг

З часом це дасть базову лінію для швидкості. Кожна історія в 5 балів не займе стільки ж часу, як інші, але середня швидкість за спринт (скільки сюжетних очок команда може виконати) буде послідовною.

Турбуватися про те, скільки часу займе конкретна історія, є протипродуктивним. Оцінки є лише середніми за обсягом історій з розміром (IE, один 5 покажчик може зайняти трохи більше часу через рефакторинг, але ви отримаєте користь від цих зусиль на спорідненій).

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

Можливо, у спринтному плануванні розповіді до неї можуть бути додані додаткові критерії, щоб уникнути "повзучість", що може статися там, коли користувач хоче нову форму, а потім 101 зміниться у форму, що не реально іноді роби в спринті на 2 тижні.

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