В некоторых организациях гибкое внедрение может потерпеть неудачу, я даже работал в компании, где водопад был единственным (верным) способом, но только потому, что они попробовали Agile на проекте и потерпели неудачу.
Когда я спросил людей, которые все еще помнили это (я был младшим), меня сильно закрыли, как будто я напоминал им плохой кошмар, который действительно случился.
Я не знаю, почему проект провалился. В Интернете есть ресурсы, из-за которых Agile терпит неудачу, это некоторые компании, но причина в основном экономическая. Поэтому я подумал, что прошу здесь несколько отзывов.
Каковы причины провала Agile в некоторых организациях? Или другой способ выразить это. Что нужно для успеха в Agile?
agile
methodology
waterfall
technique
curiousAboutIt
источник
источник
Ответы:
Вы нуждаетесь в руководстве, клиентах и разработчиках, каждый из которых понимает и поддерживает Agile образ мышления и Agile методы. Подробнее:
По моему опыту, это первая точка, которая чаще всего стоит за провальными Agile-проектами, но две другие также могут вызвать проблемы.
Обновить
Под «управлением» я имею в виду не только непосредственного руководителя проекта, но и более высокий уровень. Как совершенно справедливо заметил @Michael, некоторые более или менее внешние стороны (например, QA или сторонний исполнитель задач) также могут влиять на успех / провал Agile-проектов, но я полагаю, что это возможно только в том случае, если их соответствующий руководитель позволяет им, и / или если обязанности и командование не ясны в организации.
источник
Тебе нужно:
Кажется, все так просто, но многие из них - большие вопросы в этой отрасли.
источник
Гибкий проект чаще всего терпит неудачу, когда ключевой игрок отказывается быть гибким, или (что еще хуже), когда кто-то не искренне заинтересован в успехе проекта или просто саботирует его. Последний может убить любой проект (как и многие другие), но гибкие процессы дают людям больше гибкости, в том числе гибкость в разрушительной политике.
Примеры:
источник
Я могу только дать свой совет из своего личного опыта.
Один работодатель, которого я полностью провалил в Agile. Работа выполнялась на разовой основе, тестирования не было, требования были задокументированы в электронных письмах и протоколах заседаний. Единственным используемым методом разработки была анархия, или «кодирование с огнем и забыванием». Реализация какого-либо метода разработки программного обеспечения была бы невозможна, так как разработчики были слишком перегружены работой, чтобы установить какое-то программное обеспечение для управления проектами с отслеживанием историй.
У другого работодателя в нашей команде был героический член, который отчаянно пытался установить некоторые лучшие практики Agile - у нас была доска объявлений Kanban, отслеживание проблем, мы использовали TDD и BDD (хотя сами по себе они не Agile, они, как правило, присутствуют в Agile группах) , К сожалению, нам не хватало таких вещей, как сюжетные точки, сеансы оценки, планирование емкости, диаграммы выгорания, диаграммы скоростей - полезные вещи для управления проектами Agile, которые позволяют плавно проходить работу. Как классический признак провала Agile, когда наша доска Kanban была переполнена, мы купили большую доску: /
Место, в котором я сейчас нахожусь, использует сюжетные точки как способ планирования возможностей с двухнедельными итерациями, TDD, ежедневными переходами в режим ожидания, ретроспективами с временными интервалами итерациями и парным программированием для большинства вещей. Это является результатом полного участия менеджмента и обучения клиентов.
Думаю, что для того, чтобы Agile преуспел в компании, вам нужны следующие вещи:
РЕДАКТИРОВАТЬ: Также важно убедиться, что у вас есть хорошее понимание, почему полезны такие вещи, как ежедневные занятия и короткие итерации.
источник
Мой опыт гибкого провала не имел ничего общего с экономикой, а с корпоративной / ведомственной / личной политикой.
На личном уровне есть просто некоторые люди, чьи личности столкнутся. Форсирование их в Agile-команду или, что еще хуже, в парную команду программистов перерастет их неприязнь друг к другу до точки кипения. Это может стать очень неприятным, очень быстрым и привести к таким вещам, как акты саботажа, достойные реалити-шоу, превращение собраний схваток в круговой отряд обвинения или еще хуже.
Кроме того, есть управление развитием. Я видел, что это пошло не так в двух разных направлениях.
Во-первых, это «Agile культа грузов», где менеджер настаивает на том, чтобы следовать манифесту и тому классу / книге / веб-сайту, который они читают точно, не понимая, почему, когда их использовать и когда импровизировать. Это как если бы Agile-менеджер ждал волшебства, потому что он точно следовал заклинанию. Эта прокрустовая реализация Agile может привести к ряду проблем, которые приведут к провалу проекта.
Другой - «Agile In Name Only», где используются такие термины, как спринты и схватки, но на самом деле они просто обозначают старые практики, такие как микроуправление, нечестность, идущая вверх и вниз по цепочке команд, длительные бесполезные встречи о статусе и другие подобные вещи. , Проекты терпят неудачу, как и раньше, но теперь в этом можно обвинить Agile, а не плохое управление.
Кроме того, клиент / клиент проекта не принимает участия в проекте. Эти люди будут иметь собственные департаментские приоритеты и могут сопротивляться работе с командой разработчиков, если только их руководству не станет ясно, что это важная часть их работы. Это может усугубиться политикой департамента или корпоративной политикой. Например, и операции, и маркетинг вносят свой вклад в проект, и ваша команда в конечном итоге крутит колеса, поскольку обе стороны не могут договориться ни о чем. Другой пример - когда корпоративная политика по управлению временем и выставлению счетов вызывает конфликты. Я действительно обнаружил, что с внешними клиентами было легче иметь дело, чем с внутренними. Им понравилось внимание, которое они получили от процесса и знали, что они получают ценность своих денег.
источник
ИМО «Agile» терпит неудачу, когда нет оптового скупки практик. Я имею в виду, что Agile полагается на то, что «клиент» (обычно другой отдел или менеджер) понимает, что:
Все это очень трудная вещь для большинства менеджеров, и IMO - причина № 1, почему это трудно сделать Agile - менеджеры привыкли говорить: «Это будет сделано к х дате» и «магическим образом» к этой дате. (после того, как разработчики потратили 80 часов в неделю), и это 180, чтобы понять, что команда разработчиков скажет вам, что этот проект будет выполнен через 3 месяца, и единственный выбор, который у вас есть, - это принять его или уменьшить требования, чтобы получить это сделано раньше.
Во-вторых, должно быть доверие к команде разработчиков. Идя рука об руку с номером 1 выше, очень немногие менеджеры действительно доверяют мнению людей, нанятых в качестве экспертов; если разработчик говорит, что проект займет х времени, а х больше, чем думает руководство, это никогда не означает, что «я не знаю, как писать программное обеспечение, поэтому разработчик, вероятно, прав», это больше » Эти бесполезные разработчики хотят бездельничать на работе, поэтому они сказали, что это займет 3 месяца ".
В-третьих, ваша команда разработчиков должна быть позади Agile; это означает не срезать углы и не игнорировать постоянную обратную связь и вопросы «Правильно ли это? Когда x случается, что должен делать Y?». Даже если вы не следите за TDD или парным программированием, ваша команда разработчиков должна быть достаточно компетентна, чтобы выполнять гибкие процессы (например, спринты, итерации). Это подразумевает наличие руководителя / менеджера, который может правильно оценить задачи и понимает, что вам не нужно делать каждую функцию приоритетом, нормально иметь отставание в работе, и вы не должны переутомляться людьми.
источник