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