Agile - шипи та загальна хронологія

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

Проект передбачає три речі, з якими ніхто з команди не має досвіду: Інтеграція із системою оплати праці Foo, вміти обробляти тип файлу XYZ89 (де "XYZ89" = певний тип файлу, про який ви ніколи не чули) та конвертувати деякі інші файли, щоб їх можна обробляти Frobnobdicator.

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

Отже, мої запитання:

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

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

Який найкращий спосіб впоратися з кількома шипами, коли вони в основному не відповідають вимогам проекту?

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

Ось чому багато проектів Agile зазвичай починаються з " Sprint 0" , який я люблю називати .

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

Ви повинні робити в порядку пріоритету, встановленого власником товару (або замовником). Немає сенсу вбивати себе над чимось, що було насправді приємним. Ідея полягає в тому, що якщо у вас не вистачає часу, а щось не вдається зробити, це повинні бути пункти з найменшим пріоритетом.

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

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

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

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

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