Що вам потрібно, щоб досягти успіху з Agile?

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

Коли я запитав людей, які досі пам’ятають про це (я був молодшим), мене важко закрили, ніби я нагадував їм поганий кошмар, який справді стався.

Я не знаю, чому проект провалився. В Інтернеті є ресурси, через які Agile провалюється деякі компанії, але причина в основному економічна. Тому я подумав, що я прошу сюди відгуків.

Які причини невдалого прийняття системи Agile в деяких організаціях? Або інший спосіб його викласти .. Що вам потрібно, щоб досягти успіху з Agile?

Вам потрібні керівництво, клієнти та розробники, щоб зрозуміти та підтримати спритний спосіб мислення та методи Agile. Більш детально:

• Керівництво повинно бути зручним, щоб почути правду, на відміну від того, що вони традиційно очікують почути (тобто "так, проект на шляху" 11 місяців ... тоді раптом "ой, нам потрібно затримати термін на кілька тижнів ... ем, місяці ... ерм ... "в самому кінці). Вони також повинні бути зручні, дозволяючи кожній стороні виконувати (і брати на себе відповідальність) за свою роботу. Найголовніше, що розробники повинні приймати технічні рішення та кошториси. Тож ніякого жорсткого контролю та мікроуправління.
• Клієнти повинні розуміти, що Agile вимагає їхньої глибокої та постійної участі в процесі розробки, а не просто "оформлення замовлення", а потім отримання доставки через кілька місяців. Вони також повинні бути комфортними через відсутність великої специфікації з фіксованими вимогами та очевидну відсутність зобов'язання з боку команди розробників виконати те, про що спочатку вимагали.
• Розробникам потрібно зручно брати на себе відповідальність, приймати рішення, відкрито спілкуватися та працювати в команді. Тобто ніякого «володіння кодом», жодних «самотніх ковбоїв» та безрезультатного звинувачення інших у проблемах, які може вирішити сама команда.

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

Оновлення

Під "менеджментом" я маю на увазі не тільки безпосереднього керівника проекту, але і вищі рівні. Як справедливо зазначає @Michael, деякі більш-менш зовнішні сторони (наприклад, QA або зовнішній виконавець завдань) також можуть впливати на успіх / провал Agile проектів, але я вважаю, що це може бути можливим лише за умови, якщо їх відповідний керівник дозволить їм, та / або якщо в організації не є чіткими обов'язки та правила управління.

Тобі потрібно:

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

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

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

Приклади:

• QA наполягає, що клієнти не можуть бачити програмне забезпечення, якщо він не пройшов місячний цикл ручного тестування
• Керівництво встановлює нереальні терміни
• Клієнт відмовляється від пріоритетності вимог (" всі вони мають найвищий пріоритет!")
• Хтось, хто не є безпосереднім зацікавленим учасником, але має політичну роль, продовжує призначати ключові члени команди тривалі, не пов'язані між собою завдання, і керівник проекту не може цього запобігти.

Я можу дати свої поради лише з власного особистого досвіду.

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

У іншого роботодавця в нашій команді був геройський член, який відчайдушно намагався встановити деякі найгірші практики Agile - у нас була рада Kanban, відстеження випусків, ми використовували TDD та BDD (хоча самі по собі не Agile, вони, як правило, присутні в Agile групах) . На жаль, нам не вистачало таких речей, як точки розповіді, сеанси оцінювання, планування потужностей, графіки згоряння, графіки швидкості - такий вид корисних програм управління Agile, які дозволяють роботі протікати безперешкодно. Як класичний симптом того, що Agile піде не так, коли наша дошка Kanban була занадто повною, ми купили більшу дошку:

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

Думається, що для того, щоб Agile досяг успіху в компанії, вам потрібні наступні речі:

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

EDIT: Також важливо переконатися, що ви добре розумієте -що - корисні такі речі, як щоденні очікування та короткі ітерації.

Мій досвід невдачі Agile не мав нічого спільного з економікою, а з корпоративною / відомчою / особистою політикою.

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

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

По-перше, це «культовий культ Agile», де менеджер наполягає на дотриманні маніфесту та того, який клас / книгу / веб-сайт вони читають точно, не розуміючи причини, чому і коли ними користуватися та коли імпровізувати. Це так, ніби менеджер Agile чекає, коли станеться магія, оскільки вони точно виконують заклинання. Ця прокрутська реалізація Agile може призвести до низки проблем, які призведуть до провалу проекту.

Інше - "Agile In Name Only", де використовується термінологія, як спринти та scrum, але насправді є лише етикетками над старими методами, такими як мікроуправління, нечесність іти вгору і вниз по ланцюгу команд, тривалі марні зустрічі з статусом та інші подібні речі . Проекти провалюються так, як раніше, але тепер Agile може бути звинувачений у цьому, а не в поганому управлінні.

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

IMO "Agile" провалюється, коли немає оптової покупки методів. Я маю на увазі те, що Agile покладається на "замовника" (як правило, іншого відділу чи менеджера), розуміючи, що:

1. Вони не знають на 100%, що хочуть робити програмне забезпечення, навіть якщо вони думають, що роблять
2. Вони не мають уявлення, скільки часу пройде, навіть якщо вони думають, що це зробити
3. Їм скажуть, скільки часу це займе, і вони повинні прийняти його або зменшити функції, щоб виконати термін
4. Їм доведеться вибирати особливості кожної ітерації і не отримуватимуть повну, 100% повну програму за один кадр.

Все це дуже важко проковтнути для більшості менеджерів, і ІМО - причина №1, чому важко зробити Agile - менеджери звикли говорити "Це буде зроблено до дати" і зробити це "Магічно" до цієї дати (після того, як розробники покладуть 80 годин на тиждень), і це 180, які зрозуміють, що команда розробників повідомить вам, що цей проект буде здійснено через 3 місяці, і єдиний вибір, який ви маєте, - це прийняти його або зменшити вимоги, щоб отримати це робиться раніше.

По-друге, слід довіряти команді розробників. Ідучи рука об руку з №1 вище, дуже мало керівників насправді довіряють думці людей, найнятих як експертів; якщо розробник каже, що проект займе x кількість часу, а x - це більше, ніж керівництво думає, що це займе, це ніколи не стосується "я не знаю, як написати програмне забезпечення, тому розробник, ймовірно, правий" це більше " Ті розробники, які не платять нічого, хочуть відмовитися від роботи, тому вони сказали, що це займе 3 місяці ".

По-третє, ваша команда розробників повинна відставати від Agile; це означає не різати кути і не ігнорувати постійні відгуки та запитання "Це правильно? Коли x станеться, що слід робити Y?". Навіть якщо ви не дотримуєтесь програмування TDD або парного програмування, ваша команда розробників повинна бути достатньо компетентною для виконання гнучких процесів (наприклад, спринтів, ітерацій). Це передбачає наявність ведучого / менеджера, який може правильно оцінювати завдання і розуміє, що вам не потрібно робити кожну функцію пріоритетною, це нормально, щоб мати відставання в роботі, і ви не повинні перевантажувати людей.