Як представити спритний проект людям, орієнтованим на водоспад [закрито]

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

Хоча у нас є загальне уявлення про те, над чим ми працюємо далі, ми не впевнені на 100%, поки не плануємо ітерацію. До цих пір наша команда в значній мірі працювала у вакуумі і не вимагала представляти нашу методологію чи показники сторонам. Ми дотримуємося більшості практик, що використовуються в програмі Екстремального програмування .

Ми проводимо щоквартальні зустрічі з плануванням, щоб мати загальне уявлення про історії, над якими ми будемо працювати протягом чверті. Однак, наші історії задокументовані на картках 3х5 і оцінюються лише на початку ітерації, в якій вони збираються працювати. Після оцінки ми документуємо історію в Team Foundation Sever . Під час ітерації ми додаємо код до оповідань і відзначаємо розповіді як завершені, щойно закінчені. З цих даних ми можемо генерувати діаграми згоряння та швидкості. Найголовніше, що ми знаємо нашу середню швидкість ітерації, що не дає нам кусати більше, ніж ми можемо жувати.

Я не хочу змінювати спосіб розвитку, але хочу представити нашу діяльність з розробки у звіті, який зрозуміє лише той, хто знайомий із водоспадом. В Що таке моторному Project Plan Подивіться , як , Kent McDonald робить хорошу роботу виклавши відмінності між гнучким і каскадних планами проекту. Він визначає відмінності в витратних куль:

• Складний план проекту на основі функцій
• Складний план проекту організований в ітерації
• Складний план проекту має різні рівні деталізації залежно від часових рамків
• Команда належить привабливому плану проекту

Вміти пояснити відмінності - це чудово, але як найкраще представити дані?

Покажіть їм напівскладений маніфест спритності .

Це безумовно говорить вам, що Agile система все, порівнявши його з методами водоспаду :

Індивіди та взаємодія над процесами та інструментами,
і ми маємо обов'язкові процеси та інструменти для контролю того, як ці люди (ми віддаємо перевагу терміну "ресурси") взаємодіють

Працює програмне забезпечення над всеосяжною документацією до
тих пір, поки це програмне забезпечення є всебічно задокументованим

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

Відповідь на зміни, наступні за планом, за
умови створення детального плану для реагування на зміну, і це дотримується точно

Мені довелося це зробити один раз. Команда хотіла зробити Agile, Клієнт хотів (і розумів Agile), зовнішню Третю сторону (називайте їх "Аудиторами"), хотів побачити звіти про водоспад.

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

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

Що ти робиш? Брехня , але біла брехня.

• Перефразовуйте функції, як вимогу "Must have Feature".
• Ваша робота в Ітераціях, ітерації, як правило, тривають X тижнів, план водоспаду любить бачити речі, як правило, за тиждень, тому немає великої проблеми. Ви можете позначити кінець кожної ітерації як віху. Віхи - водоспад. Ітерації, як правило, мають тему (або пов’язаний епос), тому ви можете наклеїти тему / епічний заголовок на рубіж (напр., 21/11 має заповнити графічний інтерфейс.)
• Обчисліть свою швидкість (з діаграм згоряння / згортання) і опрацюйте, скільки часу в середньому представляє пункт історії історії (принаймні на поточній швидкості), це дасть вам тривалість завдання. Часто дикі неточні, але вони будуть значущими до певної міри.
• Ваш план має різний рівень деталізації залежно від часових рамків - в основному однаковий для водоспаду. Можливий різний план водоспаду має різні деталі залежно від аудиторії.

• Agile план належить команді. План водоспаду належить керівнику проекту. Ви вже отримали менеджера проекту, і вони, ймовірно, роблять цей переклад . Вони повинні взяти на себе власність на цей перекладений документ і захистити команду від флексу, який може з-за нього дощити дощ. Завдання керівника проекту Agile або Waterfall - захистити команду від відволікань, які не дозволять їм працювати.

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

В основному це біль. Переклад буде багато годин роботи. Якщо вам доведеться це зробити багато, автоматизуйте це.

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

Ми пережили щось подібне, і зрештою (якщо Agile працює) воно продасть себе (якщо це не так, то чому ви це робите?). Люди починають розуміти "зусилля" і те, що певна команда здатна "спалити" 40 очок зусиль у спринті за 2 тижні і насправді є досить хорошою в середньому для оцінки цих балів. Щойно вони побачать для них переваги, вони продадуть процес решті бізнесу за вас. Але головне в тому, що ти ніколи не можеш когось змусити когось, оскільки вони просто відбиватимуться.