Чи має пізнє значення в методах Agile?

Це з’явилося з деяких відповідей та коментарів до іншого питання ( цього ).

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

Моє запитання: чи поняття "пізно" має якесь значення у поступливому, якщо так, то що?

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

Тож якщо ви точно не знаєте, що саме збираєтеся доставити, поки ви не доставите його, і користувач не прийме його, і якщо у вас немає розкладу поза наступним спринтом, як ви могли коли-небудь запізнитися, насправді має значення?

(Очевидно, я розумію, що спринт може подолати, але я говорю про це поза цим.)

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

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

Я не погоджуюся з тим, що проект Agile не має попереднього плану.

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

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

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

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

ви дізнаєтеся з цього і налаштуєтесь на наступну ітерацію

Різниця полягає в тому, що це може відбуватися кожні 2-4 тижні, тому уроки засвоюються і процес швидко налагоджується

Так, але знадобиться лише 1 місяць, щоб ви дізналися, що ви не потрапите на свою 9-місячну-міфічну-фінальну-проектну-дату замість 9.

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

Щоразу, коли ви берете на себе зобов'язання, ви ризикуєте запізнитися. Це стосується і спритного.

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

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

І саме про це спритно. Розумний спосіб управління цим незручним уявленням про те, що запізнення - це факт, і ми просто мусимо з цим боротися якнайкраще.

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

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

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

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

У Agile SCRUM є два типи "пізніх">

1. Carryover - Історії, які не закінчуються в кінці спринту, розробники "зобов'язуються" отримати PBI, тому коли це не зроблено, його можна вважати носієм.

2. Дорожня карта - якщо припустити, що у вашої організації є дорожня карта, і якщо припустити, що вона має дати, якщо основні результати для цих дат пропущені, це можна вважати "пізнім".