Закриття проекту в Scrum

У типовому середовищі розробки програмного забезпечення закриття проекту позначає кінець проекту.

1. Записи проекту заповнюються та архівуються,
2. звільнені ресурси,
3. питання та уроки задокументовані та
4. урочиста вечеря / вечірка, проведена для святкування.

Останній крок не є обов'язковим, хоча є дуже мотивуючим для учасників. :-)

Контрастуйте це з Scrum. Я знаю, що scrum працює на історії з відсталих . Отже, технічно кожна ітерація закриває певні історії. Отже, тут є два питання.

1. Як група, яка працює над кількома одночасними проектами , як укладається закриття проекту?
2. Як застосовується ця концепція для проекту, що включає декілька груп ?

Або, чи термін закриття проекту взагалі не застосовується до проектів T&M ?

Як група, яка працює над кількома одночасними проектами, як укладається закриття проекту?

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

Однак Scrum нічим не відрізняється від неприступного (водоспадного) методу. Коли відставання зменшиться приблизно до нуля, ви все одно зробите. Так само, як якщо б у вас підхід до водоспаду замість спритного підходу.

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

Як застосовується ця концепція для проекту, що включає декілька груп?

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

Або, чи термін закриття проекту взагалі не застосовується до проектів T&M?

Чому виставлення рахунків може змінити щось про характер твору чи церемонії наприкінці?

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

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

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

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

У Scrum, як і у всіх методах Agile, проекти - це незначні речі, які приходять і йдуть, тоді як команда залишається разом. Тож немає жодного ритуалу «проект-кложур» як такого. Скоріше проект зменшується, а інший віск. Потік предметів відставання поступово зміщується від одного до іншого. Команда ледь знає різницю.

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

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

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