Чи можна коли-небудь встановити рамки + фіксований термін + договір з фіксованою ціною, щоб працювати з "спритним"?

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

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

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

Я хотів би поставити зустрічне запитання:

Чи можна коли-небудь встановити дію + фіксований термін + договір з фіксованою ціною колись працювати, періодично ?

Вислів "добре / швидко / дешево - вибери два" - це не просто дурний інженерний жарт. Кожен керівник проекту, який коштує своєї солі, знає про Трикутник управління проектами :

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

Проблема полягає в тому, що це ніколи не відбувається насправді, якщо ваш проект планується і виконується людьми.

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

• Несподівані витрати спливуть, що призведе до перевищення бюджету. Термін дії підписки минув. Виробник припинив підтримку товару, який ви використовуєте, і вам доведеться знайти новий. Погодинний підрядник підвищив свою ставку під загрозою від'їзду. Уся ваша команда страйкувала, вимагаючи підвищення на 10% та додатковий тиждень відпустки.

• Розклади ковзають. Виникають непередбачувані проблеми; той компонент діаграми, який ви використовуєте протягом 5 років, не сумісний із Windows 95, який ваш клієнт все ще використовує. Незрозуміла помилка в 64-розрядної Windows спричиняє серйозні збої в інтерфейсі, і ви витрачаєте майже тиждень на її відстеження та розробку обходу (це насправді трапилося зі мною). Ваш старший розробник потрапив у автобус, і вам доведеться набирати і тренувати новий. Передбачувана дата доставки завжди неправильна. Завжди.

  Дивіться Закон Гофстадтера :

  Закон Хофстадтера: Це завжди займає більше часу, ніж ви очікували, навіть якщо ви враховуєте закон Хофстадтера.

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

Це не має сенсу для проекту, який є (або заявляє, що є) або фіксованим обсягом, або фіксованим графіком.

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

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

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

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

Я люблю цю цитату:

"Scrum чудово підходить для змінної області з фіксованою датою, або для" змінної області "(яка завжди зростає) змінної дати. Якщо ви робите фіксовану дату з фіксованою датою, я рекомендую водоспад або RUP, який придбає вам кілька місяців, щоб шукати нову роботу. "~ Майкл Джеймс

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

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

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

Фіксована ціна / фіксований термін / фіксований обсяг можна зробити принаймні настільки ж спритною, як і у водоспаді.

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

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

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

Я певною мірою згоден з Брюсом. Хоча я не надто знайомий із водоспадом чи РУП, і тому не можу це коментувати.

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

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

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