Чи є дослідження щодо ефективності / ефективності Agile vs водоспад [закрито]


22

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

Чи є якісь дослідження, які порівнюють ці два?


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

6
Запитайте джерело претензії.
Мартін Йорк

Добре, якщо у оригінальної людини є джерело, то воно може містити посилання на інші дослідження.
Мартін Йорк

4
@Chad Чому це було не твоє місце? Хто це казав? Якщо це був зовнішній постачальник, яка хороша можливість зрозуміти їх здатність керувати проектами, перш ніж працювати з ними.
Томас Оуенс

1
@CHad: Перефразовуючи Дугласа Адамса .... I refuse to prove that Agile is more efficient,каже Бог,for proof denies faith, and without faith Agile is nothing.
mattnz

Відповіді:


12

У книзі "Створення програмного забезпечення: що насправді працює і чому ми віримо в це" є деякі глави про Agile методи, включаючи XP, Scrum, динамічну розробку програмного забезпечення та Lean, з хорошою науковою підтримкою. Це висока якість, як можна було б очікувати від O'Reilly. Одним із редакторів був чудовий Грег Вілсон , надійний автор інформатики, редактор та ведучий.

Сама книга узагальнює багато дослідницьких досліджень, у тому числі багато про спритний. В одному розділі узагальнено дослідження, включаючи "Чи дві голови краще, ніж одна? Про ефективність парного програмування" , Dybå, T .; Арісгольм, Е .; Sjøberg, DIK; Hannay, JE; Шулл, Ф .; та " Емпіричні дослідження розвитку гнучких програмних засобів: систематичний огляд " Торе Дібо та Торгейра Дінгшёра.

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

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


* Це не обов'язково моя думка!


1
Будь-який шанс, що ви можете додати цитати та посилання? Це може допомогти з'ясувати, чи вартий він один із моїх слотів для книжкових полиць сафарі. * 8 ')
Марк Бут

1
Версія Nook теж :) Дякую, ви перевірите це сьогодні ввечері.
SoylentGray

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

Спасибі Кайл, але я думаю, що підсумок був би кращим, ніж те, що схоже на захоплення екрана. Трохи важко отримати те, про що вони говорять, без більшого контексту, наприклад, що вони означають під зусиллям ? Ми говоримо про години розробника на проект?
Марк Бут

1
Книга відповідає на питання так, як я повинен був би задати її, хоча я думаю, що це було б занадто широко. Дякую за посилання
SoylentGray

10

Наскільки я не люблю заголовок, я вважаю, що Балансування спритності та дисципліни: Посібник із здивованим може містити інформацію, яка стосується вас. Ця книга двох експертів із програмного забезпечення та управління проектами програмного забезпечення - Баррі Боем та Річардом Тернером. У цій книзі розглядаються різні аспекти спритних та орієнтованих на плану методологій, порівнюється та протиставляється їм, а також обговорюється їх інтеграція для досягнення ситуації "найкращого з обох світів".

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

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

У програмі швидкого розвитку: приборкання диких програмних програм , Стів МакКоннелл визначає ряд факторів, які слід враховувати при виборі методології життєвого циклу: рівень розуміння вимог, рівень розуміння архітектури, бажана надійність, управління ризиками, обмеження графіку, кількість процесу накладні витрати, виправлення курсу в середині проекту, можливість забезпечити замовник наочності, можливість забезпечити керівництво наочністю, а також складність команди розробки та менеджменту. Є й інші, такі як організаційна культура, тому, ймовірно, ніде не існує вичерпного списку.

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

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


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


6

У мене немає дослідження, але я хотів би передати свій досвід.

Ефективність будь-якої із згаданих методологій сильно залежить від аналітиків.

Якщо у вас є чудовий власник продукту, наприклад, SCRUM, звичайно, швидше, ніж підхід до водоспаду з поганою специфікацією.

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

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

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


4

Agile був лише 60% ефективним у часі розвитку

Правда.

Але, це кульгавий вимір.

Агільні методи зазвичай швидше доставляють реальну цінність

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

Далі.

Ви можете вимірювати "час розробки" окремо від "час розробки та тестування".

Agile зазвичай включає тестування. Так це здається повільніше.

Розвиток водоспадів можна чітко відокремити від тестування. Тож код "готовий до тестування" швидше. Але це не зроблено набагато пізніше.

Так. Вони абсолютно праві. За що вони вимірювали.


8
Я не знаю, чи завжди це правда - це залежить від того, як (на якому рівні) ви вимірюєте ефективність. Якщо я водоспад через проект, який займає 2 роки, я просто провів два роки, розробляючи все. Але якщо я використовую ітеративний / поступовий підхід, я можу дізнатися, що лише 40% моїх вимог потрібно виконати, і проект успішно завершується після впровадження 40% відставання продукції за 15 місяців. Це 9 місяців часу на розробку іншого проекту. Для мене це підвищення ефективності - я не тільки задовольнив усі бізнес-потреби одного клієнта, але вже підтримую другого.
Томас Оуенс

3
Ще один випадок "Ви отримуєте те, що вимірюєте". Виміряйте неправильну річ, і це не допомагає.
Мартін Йорк

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

3
Повторне затвердження оригінального твердження насправді не відповідає на запитання. Чи є у вас будь-які докази, крім анекдотичних, про те, що твердження є правильним?
Марк Бут

1
Ви отримуєте те, що вимірюєте, такий ризик ви берете на себе.
Скотт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.