Что нужно для успеха в Agile?

В некоторых организациях гибкое внедрение может потерпеть неудачу, я даже работал в компании, где водопад был единственным (верным) способом, но только потому, что они попробовали 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 и быть готовыми выслушать советы своих разработчиков в отношении того, что может быть разработано в данный период времени.

РЕДАКТИРОВАТЬ: Также важно убедиться, что у вас есть хорошее понимание, почему полезны такие вещи, как ежедневные занятия и короткие итерации.

Мой опыт гибкого провала не имел ничего общего с экономикой, а с корпоративной / ведомственной / личной политикой.

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

Кроме того, есть управление развитием. Я видел, что это пошло не так в двух разных направлениях.

Во-первых, это «Agile культа грузов», где менеджер настаивает на том, чтобы следовать манифесту и тому классу / книге / веб-сайту, который они читают точно, не понимая, почему, когда их использовать и когда импровизировать. Это как если бы Agile-менеджер ждал волшебства, потому что он точно следовал заклинанию. Эта прокрустовая реализация Agile может привести к ряду проблем, которые приведут к провалу проекта.

Другой - «Agile In Name Only», где используются такие термины, как спринты и схватки, но на самом деле они просто обозначают старые практики, такие как микроуправление, нечестность, идущая вверх и вниз по цепочке команд, длительные бесполезные встречи о статусе и другие подобные вещи. , Проекты терпят неудачу, как и раньше, но теперь в этом можно обвинить Agile, а не плохое управление.

Кроме того, клиент / клиент проекта не принимает участия в проекте. Эти люди будут иметь собственные департаментские приоритеты и могут сопротивляться работе с командой разработчиков, если только их руководству не станет ясно, что это важная часть их работы. Это может усугубиться политикой департамента или корпоративной политикой. Например, и операции, и маркетинг вносят свой вклад в проект, и ваша команда в конечном итоге крутит колеса, поскольку обе стороны не могут договориться ни о чем. Другой пример - когда корпоративная политика по управлению временем и выставлению счетов вызывает конфликты. Я действительно обнаружил, что с внешними клиентами было легче иметь дело, чем с внутренними. Им понравилось внимание, которое они получили от процесса и знали, что они получают ценность своих денег.

ИМО «Agile» терпит неудачу, когда нет оптового скупки практик. Я имею в виду, что Agile полагается на то, что «клиент» (обычно другой отдел или менеджер) понимает, что:

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

Все это очень трудная вещь для большинства менеджеров, и IMO - причина № 1, почему это трудно сделать Agile - менеджеры привыкли говорить: «Это будет сделано к х дате» и «магическим образом» к этой дате. (после того, как разработчики потратили 80 часов в неделю), и это 180, чтобы понять, что команда разработчиков скажет вам, что этот проект будет выполнен через 3 месяца, и единственный выбор, который у вас есть, - это принять его или уменьшить требования, чтобы получить это сделано раньше.

Во-вторых, должно быть доверие к команде разработчиков. Идя рука об руку с номером 1 выше, очень немногие менеджеры действительно доверяют мнению людей, нанятых в качестве экспертов; если разработчик говорит, что проект займет х времени, а х больше, чем думает руководство, это никогда не означает, что «я не знаю, как писать программное обеспечение, поэтому разработчик, вероятно, прав», это больше » Эти бесполезные разработчики хотят бездельничать на работе, поэтому они сказали, что это займет 3 месяца ".

В-третьих, ваша команда разработчиков должна быть позади Agile; это означает не срезать углы и не игнорировать постоянную обратную связь и вопросы «Правильно ли это? Когда x случается, что должен делать Y?». Даже если вы не следите за TDD или парным программированием, ваша команда разработчиков должна быть достаточно компетентна, чтобы выполнять гибкие процессы (например, спринты, итерации). Это подразумевает наличие руководителя / менеджера, который может правильно оценить задачи и понимает, что вам не нужно делать каждую функцию приоритетом, нормально иметь отставание в работе, и вы не должны переутомляться людьми.