Коли Agile піде не так [закрито]

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

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

На що слід звернути увагу, коли проект Agile піде не так?

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

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

Це три, які ви побачите послідовно «застосовані» в цих умовах, але дуже малі зобов'язання насправді бути спритними. Насправді ви почуєте, як керівництво говорило, що ми робимо поворот. (Біжіть за цими двома словами, це поганий знак.)

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

Інші ключові фрази: "Я знаю, що ці історії не повністю визначені, але ми робимо спритність, щоб ми могли їх виправити в процесі роботи".

"Ми робимо спритну розробку, щоб ви могли вмістити те, що мені потрібно в спринті, коли я його ідентифікую".

"Ми не в змозі зафіксувати наші скоєні історії на початку спринту, оскільки потреби продовжують змінюватися в середині спринту".

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

Люди, які не розуміли, що таке спритне (було?), І застосовують це до:

• клієнти, які недоступні для коментарів до встановленого терміну
  ... та погроза після цього;

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

  Дивіться також: управління грибами , він же "тримається незрозумілим, згодовується гноєм" та гострими босами . :)

• команди, які занадто великі, щоб їхати куди завгодно;

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

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

Agile - це дуже добре для післяпроектної фази, коли ви робите додаткові оновлення та виправлення помилок.

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

Ось декілька питань, які можуть бути корисними для пошуку відповіді з точки зору пошуку прикладу, коли спроба Agile може бути поганою:

• Чи новий Agile новий мікроуправління?
• Процес Agile: як і що слід документувати?
• Правильний поєднання планування та програмування нового проекту

Ви коли-небудь чули про "псевдо Agile"? Ось кілька записів у блозі:

• Від Pseudo-Agile до водоспаду - шлях невеликої та нової програмної компанії
• Псевдо спритний!

Що можна сказати компаніям, які можуть сприйняти власне уявлення про те, що є Agile, і викласти це щось інше.

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

Успішний мав такі елементи:

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

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

Команда, на якій я не працював Agile, також мала кілька елементів:

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

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

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

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

• Проекти, продукт яких важливий для життя або властивості - Наприклад, ви не хочете використовувати спритний для розробки програмного забезпечення, яке працює з вашим кардіостимулятором. Чому? Тому що у вас майже нульова толерантність до помилок. Розглянемо класичний приклад помилки програмування в медицині щодо Therac 25 . Зрозуміло, вона не була побудована спритно, але справа в тому, що розвивати життєво важливе значення або властивість - ніде сказати: "Ми будемо прибирати це в наступному спринті" або "нам не потрібно велике, просто добре достатньо."

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

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

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

Тільки пам’ятайте, що коли єдиним інструментом у вас є молоток, кожна проблема виглядає як цвях. Не всі проекти - це цвяхи.

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

Я не обов'язково сказав би, що Водоспад обов’язково працюватиме в таких умовах, це не чорно-біла ситуація, дуже мало справді чорно-білих.

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

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

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