Чи можна використовувати розробку програмного забезпечення Agile у проектах, визначених договором?


14

Нещодавно я мав розмову з колегою-розробником про Agile Software Development. Хоча я розумію принцип, схоже, що постійні зміни вимог створюють потенціал для того, щоб проект тривав назавжди. Але, принаймні там, де я працюю, проекти потребують завершення, оскільки це контракт.

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

Якщо Agile Software Development передбачає зміни вимог, як ви знаєте, де це закінчується? Як можна скласти бюджет на проект, коли кінцевий результат завжди змінюється?

Чи є Agile Software Development більше про спритний процес, ніж про спритний продукт?


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

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

@Martin Wickman: Я розумію це, але тут є проблема "товар, який може отримати клієнт". У такому випадку перша ітерація може зайняти кілька місяців, оскільки для деяких проектів замовник не може використовувати неповну програму. Для деяких проектів я думаю, що вам потрібно визначити спочатку готовий, потім ви можете розбити його на ітерації та уточнити своє визначення після кожної ітерації. Але ви ВЖЕ ПОВИННІ мати таке визначення.
Веракс

@Verax: Agile маніфест створений для управління змінами. Якщо ваш проект не має змін, то спритний не для вас. Кінець історії.
Мартін Вікман

2
@Verax: Вам слід уточнити своє запитання та додати до нього більше контексту. Ваші коментарі показують, що питання є ще більше. Це також очевидно з підрахунку голосів за відповідь, і що прийнята відповідь не пов'язана з фактичним текстом запитання (і навіть каже "з коментарів ОП ...").
Мартін Вікман

Відповіді:


7

З коментарів ОП видно, що він, як я, працює в Консалтинговому магазині, де ми надаємо послуги з розвитку для наших клієнтів ... Я думаю, тому що в цій структурі розуму, яка викликає його / її плутанину ... Тож я збираюся констатуйте добре відомий, але ніколи не констатований факт.

Agile несумісний з розробкою програмного забезпечення, яке визначено договором.

  • Контракти повинні бути жорсткими, ви платите X ми робимо Y. Ви хочете, щоб X + M ви платили нам Y + (M * N)
  • Контракти ОБОВ'ЯЗКОВО бути задоволеними (IE не відкриті), інакше вони не є юридичними контактами. (Якщо задіяний контакт, вам потрібно пройти суворий процес контролю змін.)

Багато консалтингових магазинів претендують на Agile, вони брешуть. Вони просто кажуть, що тому, що Agile досяг статусу слова Buzz.

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


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

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

2
Я маю згоду з цією відповіддю. Причина полягає в тому, що якщо у вас є договір, який не є відкритим, це означає, що ви не хочете керувати масштабом повзучості (що майже завжди буває). Контракти, які я звик бачити, починаються з: Ви платите X, ми робимо Y. Потім у них є пункт, який говорить про те, що будь-яка зміна сфери дії має додаткову ціну. Поки ви дуже рано повідомляєте про повзучість сфери (що вимагає додаткових ресурсів та часу), то більш ранні клієнти можуть реагувати на зміни (отримання схвалення та бюджету від вищого керівництва тощо). Тоді сам процес управління стає гнучким.
Спойк

Це не несумісне, якщо договір призначений на обслуговування (код написання) на відміну від продукту (готового програмного забезпечення). Agile дозволяє оцінити, що буде зроблено під який бюджет, якщо зміниться вимога, і бюджет повинен змінитися. Ви хочете ще одну функцію? Ви повинні укласти ще 500 людино-годин. Особливістю повзучості є також повзуча ціна, цілком задовільна для розробників, і якщо замовник готовий платити, хто ми це ставимо під сумнів?
СФ.

2
Є спритні контракти , тому очевидно, що ця відповідь є неправильною за визначенням.
Мартін Вікман

20

Якщо ви орієнтуєтесь на те, щоб спочатку робити (у що ви вважаєте) найважливіші речі, тоді проект закінчиться, коли:

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

5
1. Немає більше грошей - Клієнт витратив усі свої гроші на неповний непотрібний товар. 2. Немає більше часу - Замовник все ще має неповний непотрібний товар. 3. Нічого додати - Так правильно! 4. Не варто - Замовник просто відмовився від проекту. --- Що я пропускаю? Це не має для мене сенсу.
Веракс

7
Для 1 і 2: Якщо ви робите найважливіші речі спочатку, тоді, коли у вас закінчуються гроші, у вас з’являться найважливіші речі, які ви можете отримати за гроші. Схожий за часом. Зізнаюся, 3 рідкість. Для 4: зупинка не обов'язково означає, що клієнт просто відмовився. Це може означати, що у них є найважливіші речі, які вони від цього хотіли, а тепер скоріше робити інші речі своїми грошима. Як ви вирішуєте, коли закінчити інші проекти? Якими б критеріями ви не користувалися зараз, все ще доступні для спритних проектів.
Дейл Емері

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

5
@Verax: Не існує такого поняття, як продукт, який вимагає "все або нічого". Завжди є функції, які просто "приємно мати", і помилки, які є косметичними, а не функціональними. Проект з фіксованою вартістю - це успіх, якщо це все, що залишається, коли гроші закінчуються. Спритні методи намагаються максимально підвищити ймовірність цього.
Майкл Боргвардт

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

14

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

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


5

Ніколи, і в цьому краса.

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

Не часто згадувана бізнес-особливість цієї технології, чи не так?


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

4

Тут є помилкова думка: Agile не заохочує зміни вимог проекту. Це натомість дозволяє змінити, не витрачаючи на роботу чи жертвуючи важливими сферами розвитку.

Існує чотири основні обмеження для будь-якого інженерного проекту; сфера, вартість, час та якість. Водоспад припускає, що вони будуть статичними. Це неправильне припущення; одна або декілька цих ЗАВЖДИ змінюються. Повзучість масштабів, зменшені бюджети та інші "невідомі невідомі" ВЖЕ перешкоджають проекту, змінюючи обмеження. Водоспад цього не передбачає, тому коли це трапляється, проект змінюється небажаними способами; важливі функції, які ще не додані, відходять, або швидко виконуються, або випуск повинен бути відсунутий назад, або коштувати повітряні кулі, оскільки прем'єр-міністр кидає гроші новим розробникам, щоб прийти і допомогти зробити все правильно.

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

Він також передбачає кращі оцінки часу та витрат, необхідних для виготовлення заданої сфери необхідної якості. Люди, як відомо, погано оцінюють велику роботу; Для цього потрібно багато досвіду, і НЕ МОЖЛИВЕ передовий розрахунок. Навпаки, люди, як правило, хороші судді того, що їм можна зробити за день, тиждень чи два. Це швидко створює стабільний стан, коли ви можете екстраполювати час і вартість роботи, що залишилася виконати, виходячи з ваших історичних темпів, з неабиякою точністю.

Щодо визначення кінцевих точок, ви маєте рацію; Agile проект МОЖЕ продовжуватись назавжди. Однак це може зробити традиційний SLDC; клієнт часто повертається з більшими грошима та списком побажань за оновлення. Різниця полягає в тому, що немає чіткої межі між "аналізом", "дизайном", "розробкою" та "технічним обслуговуванням", якщо дивитися на проект в цілому; все це відбувається цегла за цеглою, спринт за спринтом. Якщо в будь-який момент власник захоче назвати проект "зробленим", вони можуть, і вони отримають загальну суму "цегли", яку вони заплатили за тверду "стіну"; він може бути не таким високим або розтягнутим, наскільки вони планувались спочатку, але він міцно стоїть на місці, виконує роботу і може бути доданий до нього пізніше, з мінімальним скороченням.


Вибачте, але "натомість дозволяє змінити, не витрачаючи на роботу", - це гнучка помилка, яка використовується, щоб переконати керівництво в тому, наскільки це велике. Чи не рефакторинг та / або перепроектування системи на пристосування несподіваних змін не вважаються витратою роботи? У водоспадному таборі це роблять, мабуть, не у спритному таборі. Крім того, якщо замовник хотів лише виконати роботу, яка займає 2 тижні, то не має значення, яка методологія використовується, люди можуть дати хороші оцінки. Замовник дійсно хоче - це задовго до того, як я отримаю повний продукт, де спритний не кращий за інші методи оцінки.
Данк

1
Крім того, вам здається, що це добре, що власник може зателефонувати в будь-який момент, і те, що ви закінчили, це те, що він отримує. IME, як правило, замовник хоче знати, що його X долари нададуть певний набір функцій, перш ніж він знизить готівку. Я не бачу в цьому користі, коли клієнт витратив купу грошей і отримав лише половину тих можливостей, які очікував. Я вважаю це невдачею з боку компаній, що розвиваються, навіть якщо вони, можливо, доставили щось, що вони називають працюючим ....
Данк

2
Що робити, якщо клієнт уклав договір на будинок, але гроші закінчилися перед тим, як поставити дах? Спритний табір все ще називав би це успіхом. Ніхто інший не хотів би; зокрема замовник.
Данк

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

1
Що робити, якщо це було зроблено в SLDC водоспаду? Або розробка припиниться, і клієнт може отримати кодову базу з серйозними дірками функціональності, або передчуваючи дефіцит грошей / часу, решту розкладу буде зафіксовано на час, що залишився. Це ВЖЕ жертвує якістю, і наприкінці такого проекту команда розробників обсмажується. Також трапляється багато перевищення витрат, оскільки традиційний водоспад не дає продукту до завершення розробки; що обмежує здатність замовника сказати "це не те, що я хотів".
KeithS

1

Він закінчується, коли всі функції реалізовані та всі помилки виправлені.

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

Частина 1 з фіксованою ціною, що так погано?

Частина 2 з фіксованою ціною, зафіксуйте її спритно


Важко дізнатися, коли всі помилки виправлені.
Мартін Вікман

Можливо, "коли всі відомі помилки, які варто виправити"?
Ден Рей

@CharithJ, ваші посилання порушені. Вони ще десь доступні? Спасибі.
TwainJ

1

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

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


1
Прихильні прихильники висловлюють дуже неправильне припущення, що у світі водоспадів розробники зникають після підписання контракту і більше ніколи не чутимуть, поки продукт не вискочить у двері. Те, як це працює в реальному житті, полягає в тому, що існує досить багато контрольних пунктів і багато відгуків про те, що замовник може займатися настільки, на скільки їм подобається. Якщо їм не подобається напрямок чи рішення, вони можуть вимагати змін. До моменту доставки товару він повинен бути тим, що замовник хотів, наскільки клієнт вирішив брати участь. Agile не покращує це в багатьох проектах.
Данк
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.