Agile, Waterfall, Scrum ... насколько сложно перевести команду в итеративное развитие? [закрытый]
Каковы проблемы перехода команды в корпоративной атмосфере от традиционного неитеративного списка спецификаций, диаграммы Ганта, фазозависимой команды к более итеративному подходу?
Кроме того, каков был успешный способ добиться признания у других групп при использовании новой стратегии развития?
6 ответов:
Что мы сделали:
Объяснил руководству, что план (который призван предсказывать будущее) - это просто пух, пар, список предположений без фактической основы.
Запланировал список спринтов. Написал график выгорания. Забыл поставить в сводке сметы.
Начал выполнять по списку спринтов.
После первых двух или трех, руководство начало понимать, что "план" был просто список выгорания, без " дат", "риски", "предположения" или что-нибудь вроде традиционного плана проекта водопада.
В этот момент, конечно, уже слишком поздно. Мы уже закончили один спринт и почти закончили второй. Лошадь вышла из сарая. Колокол уже звонил.
Итак, менеджмент требует некоторых вещей.
Общий бюджет. Мы сказали: "сложите спринты, которые важны для вас. Просто нарисуйте случайную линию, где бы вы ни были счастливы. Это ваш бюджет.- Никто не любит. это потому, что слишком много контроля. -Как ты можешь это оправдывать?- они спрашивали. "Простой. Мы строим в приоритетном порядке, пока вы не отмените проект."
То, что мы должны были добавить, было ориентировочной продолжительностью для каждого спринта. Наши имеют переменный размер: от 2 до 4 недель. Список из 10 спринтов составлял примерно 26 недель-6 месяцев. После этого мы перестали записывать цифры.
Список "допущений". Мы просто отказались от этого. "Написать свой". Сами они ничего не могли придумать. Это было то, что.
Перечень "рисков". Опять же, мы спросили, Что напугало их. Если их что-то беспокоит, то, возможно, они должны изменить приоритет в burndown, чтобы решить эту проблему.
Срок исполнения. Мы обратили внимание на это и попросили их расставить приоритеты по срокам, бюджетам и рискам, которые были важны для них. Нам было все равно, какой заказ-это их дело как менеджеров.
После еще двух спринтов они прекратил делать "водопадные" запросы и начал устанавливать приоритеты и управлять выгоранием.
Интересно, что они никогда не спрашивали о scope creep. Менеджеры, которые спрашивают: "как вы контролируете сферу охвата?"активно отвергают инкрементное развитие. Они пытаются этого не понять.
Когда менеджеры хотят знать, как гибкие методы " предотвращают "ползучесть области, они (а) маркируют процесс обучения как" ползучесть " (что плохо) и (Б) сопротивляются идее, что обучение приводит к изменениям области. Единственный способ, которым у вас даже есть область "ползучести", - это когда вы фиксируетесь на определенной области, независимо от любого обучения, которое может произойти. Гибкие методы фиксируют только следующий спринт,а не полный охват. Если вы не привязаны к области, она не может ползти, потому что ее не существует.
Я пытаюсь сделать это прямо сейчас. У нас есть отдел развития клиентов на месте, и я могу сказать вам, что они играют ключевую роль в попытке захватить бай-ин для итеративного процесса разработки.
Некоторые отличные ответы на этот вопрос здесь.
Если у вас уже есть опыт выполнения проектов с опозданием и превышением бюджета из-за больших и неуправляемых кусков, которые не выполняются, это хорошее начало для убеждения заинтересованных сторон в ваших проектах, чтобы получить мяч смена роликов.
Процесс может проявить себя, но только при поддержке правильных сторон. Ваш ключ-заставить других игроков команды увидеть ценность в том, что вы пытаетесь сделать.Для нас это сводится к подходу к вещам с точки зрения клиентов. Нам нужно постоянно возвращаться к клиенту, чтобы убедиться, что мы строим именно то, что он представляет. Мы хотим упростить процесс, чтобы перестать тратить время каждого человека.
Теперь, конечно, другое части гибкой работы для различных организаций и очень немногие компании, которые действительно используют гибкие процессы, делают это в чистом смысле.
Методом проб и ошибок выясните, что работает для вашего бизнеса, культуры и команды. Ничто не говорит о том, что вы не можете постепенно принять общий процесс и выбрать те части, которые лучше всего подходят для вашей бизнес-модели.
Возможно, вас заинтересует книга Линн Мэннс и Линды Райзинг "бесстрашные перемены: паттерны для внедрения новых идей". Это сборник опыта внедрения гибких методов в организации.
Здесь все началось с одной команды, которая хотела идти вперед и быть более гибкой, используя Scrum. Эта команда была "пилотажной" и прошла несколько спринтов (3 месяца). Их тренировал кто-то изнутри, кто уже читал и изучал Scrum. Выполнение "пилота" вместо полного переключения помогло получить одобрение со стороны руководства и членов рефракционной команды.
Имея отношение "давайте попробуем" действительно помогает привлечь клиентов в процесс также (внутренние клиенты здесь, но клиентов не меньше).
И чтобы это закрепилось, вы должны принять во внимание достигнутый прогресс и преимущества, которые он приносит вам и вашей команде (это может быть лучшая производительность, лучшая коммуникация с членами команды/клиентами, лучшие результаты, более счастливые клиенты и т. д.)
Исходя из моего (правда, ограниченного) опыта, убедитесь, что все ваши программисты участвуют в принятии решения о переходе на Agile/Scrum/что угодно, и что все они выступают за это - или, по крайней мере, не собираются активно противодействовать этому. Я видел сопротивление со стороны членов команды, когда Agile/Scrum воспринимался как мандат сверху без их согласия/вклада. Достаточно сложно переобучать менеджеров, не убеждая при этом постоянно и свою команду.