Це спритний більше, ніж просто невеликі водоспади?


18

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

Чи моє розуміння правильне чи є в ньому більше, ніж це? Що таке спритна філософія?


4
Ви насправді читали маніфест Agile? agilemanifesto.org .
С.Лотт

Відповіді:


20

На простому рівні, так. Просто проведення водоспаду кожні два тижні не робить вас спритним , але він є ітеративним (що становить половину проворного).

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

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

Індивіди та взаємодія над процесами та інструментами

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

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

У програмному проекті першочерговою метою є доставка програмного забезпечення. Однак у деяких проектах є марнотратне виготовлення документів, які не додають ніякої цінності. Скотт Амблер написав хорошу статтю про Agile / Lean Documentation . Йдеться не про не виготовлення документації, а про вибір документації, яка додасть цінності вашій команді, майбутнім розробникам, замовнику чи користувачеві. Замість того, щоб виготовляти документацію, яка не додає цінності, ваші інженери програмного забезпечення натомість виробляють програмне забезпечення та пов'язані з ними тести.

Співпраця з клієнтами щодо укладання договорів

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

Відповідаючи на зміни протягом наступного плану

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

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


2
Так, "Agile" - це скоріше швидше ставлення, а не конкретна техніка. Прочитайте halfarsedagilemanifesto.org про уявлення про те, як деякі організації не в змозі прийняти "Agile" методології, навіть якщо вони заявляють, що вони дотримуються певного методу "Agile" ...
Білл Мішелл,

2

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


1

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

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

http://autumnofagile.net/


1

Забудьте Agile на хвилину, подумайте, що означає «водоспад».

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

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

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

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

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

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

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

Для чудового огляду того, що намагаються зробити спритні методології, я настійно рекомендую спритний розробник програмного забезпечення Allistair Cockburn : Кооперативна гра .


0

Так, це більш-менш правильно. Про те, як це робити, було написано чи обговорено багато, але суть маленьких водоспадів - суть цього.

Конкретна реалізація того, як використовувати купу маленьких водоспадів, не все одно. Наприклад, ви не збираєтеся переходити від великих проектів за пару років до створення кількох малих проектів. Є ще великий проект, на який потрібно вкласти 1-2 роки роботи. Тож вам потрібно розділити великий проект на ряд малих проектів. Це може здатися досить очевидним, але воно заповнює сторінки та сторінки книг.


0

Це правильно чи є в цьому більше, ніж це

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


0

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

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

У Agile Manifesto підкреслює деякі відмінності між гнучким і водоспадом (сприйнятими тих , хто підписав).


0

Дійсно "спритний" часто означає водоспади 1-2 дні, а не тижні. Це не означає, що ви не дотримуєтесь загального плану і що реальні цикли випуску - 1-2 дні. Але вам слід намагатися мати робочий, перевірений продукт щодня, і ви могли випускати його - теоретично - щодня.

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

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