Долгосрочное и гибкое планирование?

Моя команда недавно прошла процесс составления почти годичного плана нашей работы. Мы разделили план на три этапа. Каждый этап будет включать пару запусков.

Интересно, с ловкой точки зрения, это неправильно? Я думаю, что это неплохая идея, потому что мы не тратили слишком много времени на разработку чего-либо, кроме первых нескольких шагов. Мы можем изменить направление. В то же время приятно, что мы действуем не только в ближайшем будущем.

Иметь представление о том, куда пойдет проект, - это Good Thing ^TM .

Верить, что это именно то, что произойдет, это не так.

«При подготовке к битве я всегда обнаруживал, что планы бесполезны, но планирование необходимо».

- Дуайт Д. Эйзенхауэр

Подход Agile методологии состоит в том, чтобы разбить вещи на удобоваримые кусочки и заново настроить вид после того, как каждый кусочек был переварен.

Это означает, что ваша конечная точка через год не будет точно такой, какой вы сейчас думаете. Тем не менее, вы должны были заняться всеми важными вопросами в вашем списке и поддерживать заинтересованные стороны заинтересованными в процессе продвижения вперед.

Хорошо, менеджменту был представлен миф для планирования. Ради тебя, я надеюсь, что они тебя не держат. Потому что, зрение невидимое, я готов поспорить, что ваша команда не выполнит ничего, о чем говорит этот долгосрочный план. На самом деле, если вы достигнете среднего показателя по отрасли, вы пропустите примерно в 2 раза. И в большинстве организаций оценка, однажды предоставленная, становится клубом, в котором они могут побить вас настолько, насколько захотят.

Вы, вероятно, думаете, что я просто циничен. В конце концов, вы просто сообщали о неопределенных временах для неуказанных наборов функций, которые, как все знают, могут происходить гораздо медленнее или быстрее, чем прогнозировалось, верно? Извините, большая часть этого может быть правдой, но люди не склонны слышать эти цифры. Они слышали даты, и однажды произнесенная дата, как правило, звучит более убедительно, чем вы сказали. Кроме того, если есть цепь связи, она станет еще более прочной. И как только внешним покупателям что-то пообещали по продажам, исходя из того, что вы сказали, вы внезапно обнаружите, что в этих цифрах гораздо меньше гибкости, чем должно быть. И я гарантирую, что вы недооценили время, которое потребуется.

С этой очевидной точкой зрения я рекомендую вам прочитать « Оценка программного обеспечения», чтобы узнать, как в действительности следует проводить оценку программного обеспечения . Вы узнаете много нового о том, что вы сделали неправильно, и как сделать это лучше в следующий раз. (В процессе вы узнаете, почему я так уверен, что вы переоценили свои действия.)

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

С учетом вышесказанного я настоятельно советую вам узнать ключевой факт о датах, о которых вы сообщили, которые, к сожалению, могут вернуться в качестве крайних сроков, чтобы вас укусить. И этот факт таков. Что волнует людей: дата или набор функций? Вот что я имею в виду. Часто организации имеют конкретные даты, которые имеют значение. Например, сделать что-то для конференции или перед праздничным спешкой. В этом случае важно что-то выпустить, а не столько, насколько это что-то завершено. В других случаях есть набор функций, которые действительно должны быть выпущены вместе, и полнота важнее, чем когда это происходит. Если вы сможете определить, в какой ситуации вы находитесь, то ваша команда будет в гораздо лучшем положении, чтобы спланировать, как справиться с (почти) неизбежными кризисами, которые надвигаются.

Хорошо иметь план, если вы считаете его незавершенным, а не что-то написанное в камне.

Главное здесь - регулярно выпускать релизы (не реже одного раза в месяц), собирать реальные отзывы ваших пользователей и обновлять свой план на основе этих отзывов.

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

Если предположить, project-managementи agileвы имели в виду Scrum, это не будет точным путем.

В Scrumперспективе, если у вас есть план на один год, у вас должно быть как минимум столько же спринтов, сколько месяцев в году. Следовательно, ваш годовой план становится более гибким, поскольку его можно менять между двумя спринтами.

А Sprintможет быть не более месяца, когда Teamсовершается обязательство довести Sprint Backlog Itemsстатус до Done.

DoneЭто важное слово здесь, и у каждого из них Scrum Teamдолжно быть одно определение «выполнено», то есть там, где не осталось работы, которую нужно выполнить. Когда Sprint Backlog Itemбудет Готово , это означает , что документация анализа, архитектуры и технического написано, и что эта функция была тщательно протестирована (юнит - тесты, интеграционные тесты, функциональные тесты ...).

После того, как все Product Backlogбудет в порядке, а Предметы расставлены по приоритетам с менее важными функциями снизу, а наиболее важными - сверху, команда (разработчиков) определяет, сколько времени должна Product Backlog Itemзанять разработка каждого из них , основываясь на собственном опыте. Именно здесь вы можете определить, что проекту потребуется целый год работы. Учтите, что толькоProduct Ownerдолжен отдавать приоритет Товарам, поскольку именно он отвечает за возврат инвестиций или же знает, что является наиболее важным для конечного пользователя. Кроме того, команда должна оценить время, необходимое для полной разработки функции, хотя здесь и там могут быть многократно используемые фрагменты кода, которые могли бы удовлетворить потребности этой функции, то есть, чтобы избежать дальнейшей сложности и быть уверенным, что элемент не будет дольше, чем того требует команда. Отставание продукта не должно быть идеальным! На этом этапе процесса достаточно простого перечисления пользовательских историй, которые мы можем придумать для разработки системы.

Именно в течение Sprint Planning Meetingэтого времени команда должна принять решение о том, что будет развиваться для следующего Sprint, следовательно, создавая Sprint Backlog. Sprint BacklogСостоит из подмножества , основываясь на Product Backlog Itemsтом , что Teamкоммиты должны быть сделаны в конце спринта. Рассматривая, например, Журнал незавершенного производства, состоящий из 50 наименований, и для всех 50 наименований требуется год, тогда команда может захотеть выбрать, скажем, 5 наименований из журнала незавершенного производства, и создать отставание спринта с этими 5 наименованиями. Эти те же 5 Предметов могут быть расширены / разбиты на несколько других Предметов, когда это необходимо, что заставляет Команду, возможно, передумать после пересмотра и взять на себя обязательство делать только 4 Предмета из 5 ранее выбранных Предметов из Журнала Журнала продуктов.

По окончании Совещания по планированию спринта, которое может длиться не более 8 часов в течение всего месячного спринта, в течение которого команда не только обязуется выполнять работу для выбранных предметов, но и планирует, как она выполнит свою работу. так что все в Команде точно знают, что она / он должны делать, Sprintначинается. Для команды важно быть кросс-функциональным ради проекта.

Тем не менее, в конце каждого Спринта, который длится месяц в текущей ситуации, все Предметы, которые Teamобязуются сделать, должны быть доставляемым компонентом полнофункциональных функций, нацеленных на Предметы, выбранные из Журнала Продукта. Это должно быть доставлено, но это не обязательно, что это доставлено, если это не имеет смысла делать в соответствии с Product Owner.

Именно в тот момент, Sprint Review Meetingкогда Product Ownerтребуется вызвать, Teamдемонстрирует, что было сделано во время спринта, и где ему нужно сказать, почему он не выполнил, если применимо, всю работу, которую он совершил. Затем отмененная работа возвращается в Product Backlogи доступна для следующей Sprint. Конечно, эти неиспользованные предметы должны быть включены в следующий спринт, если владелец продукта не сообщит об ином, если цель изменилась. Но самое главное, хотя цель системы изменилась во время Спринта, не прерывайте ее без крайней необходимости. Только владелец продукта имеет право прервать спринт.

После окончания Sprint Review Meeting, которое должно длиться не более 4 часов для ежемесячного спринта (если я правильно помню), наступает время, чтобы добраться до Sprint Retrospective Meeting. Это Sprint Retrospectiveнеобходимо для того, Teamчтобы это произошло, чтобы он мог обсудить в присутствии Scrum Master и владельца продукта (необязательно), что пошло не так, как команда Scrum может улучшить свою производительность и т. Д. И внести соответствующие корректировки.

Когда временной интервал для этого Sprint Retrospectiveзакончится, тогда Sprint Planning Meetingдолжно появиться новое , чтобы спланировать следующее Sprintи создать новое Sprint Backlog.

Помните, что Teamответственность за проведение Daily Scrumэтого совещания составляет 15 минут, когда каждый член команды отвечает на три вопроса (не в указанном порядке):

1. Что вы сделали со времени последнего Ежедневного Скрама?
2. Что вы планируете делать до следующего Daily Scrum?
3. С какими проблемами или препятствиями вы столкнулись с момента последнего Ежедневного Скрама?

Он Scrum Masterне обязан присутствовать там, но обязан обеспечить, чтобы команда встречалась на Daily Scrum и чтобы участники правильно ответили на три вопроса.

Скрам Мастер отвечает за соблюдение Правил Скрама другими членами Скрам Команды (Скрам Мастер, Владелец продукта и Команда).

В конце концов, следуя этим простым правилам, ваша команда разработчиков станет гибкой. Ловкость - это возможность как можно быстрее отследить любое изменение, то есть, в конце каждого Спринта, где она может узнать об изменениях, внесенных Владельцем продукта в Журнал ожидания продукта. В случае полного стихийного бедствия и полного изменения ориентации максимальные потери, которые должна поглотить компания, - это месяц разработки, который совершенно пренебрежим, учитывая, что в месяце примерно 20 рабочих дней.

Если вам требуется более подробная информация о Scrum и Agile Software Development, пожалуйста, обратитесь к Scrum.org и его Scrum Guide .

Ну, это вполне ответ! Надеюсь, это поможет вам, по крайней мере, управлять вашим проектом.

РЕДАКТИРОВАТЬ # 1

Хотя вы планируете выполнить три или четыре фазы, как вы это называете, более вероятно, что ваша команда потеряет фокус с точки зрения основной цели. Если после первого квартала вы продемонстрируете, что сделала ваша команда, возможно, будут внесены некоторые важные изменения, которые потребуют серьезного изменения дизайна и переосмысления архитектуры вашего программного обеспечения, возобновив, возможно, более 20 дней потерянной работы. Принцип ловкости заключается в том, чтобы быть в состоянии отследить изменения, как только они происходят, или как можно скорее в течение разумного периода времени, то есть для Скрама, временного интервала Спринта.

1. Я думаю, у вас должно быть как можно больше запусков. Единственная реальная обратная связь / показатель для прогресса в разработке программного обеспечения - это код, развернутый в производстве. Таким образом, какой бы процесс вы ни использовали, чем чаще вы развертываете вживую, тем быстрее вы получаете гибкость. То есть вы получаете реальную обратную связь от реальных пользователей раньше и можете адаптироваться раньше.

2. Несмотря на то, что вы не должны делать Big Design Up Front , я думаю, что хорошо думать о большой картине каждый раз, когда вы собираетесь скорректировать и пополнить резерв, как для Scrum (для следующего спринта), так и для Kanban / flow (когда есть место). в пределе WIP). Если вы рассматриваете целое (продукт, услугу и т. Д.), Вам будет легче подумать, какие рабочие элементы принесут вам больше пользы.

3. Имейте в виду, что общая картина меняется. Как часто вы учитываете отставание, корректирующие приоритеты и т. Д., Также учитывайте изменения в общей картине. С течением времени все меняется, включая потребности конкретных клиентов и даже целых рынков. Ваша общая картина должна отражать это, чтобы ваши приоритеты могли быть согласованы с реальностью каждый раз, когда вы пополняете отставание, а не только в начале, когда вы составляете план.

В целом, я думаю, что вы становитесь более ловкими, чем больше вы проверяете и адаптируетесь.

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

Вам следует:

1. Имейте генеральный план (желательно без установленных сроков), который будет развиваться по мере вашего продвижения.

2. Когда вы определяете спринт, вы должны убедиться, что он соответствует общей картине. Это не всегда означает, что вы меняете представление о том, что нужно для спринта. Иногда при определении спринта вы обнаружите, что ваша большая картина должна быть скорректирована. Так или иначе, план общей картины и спринт должны соответствовать друг другу, участвуя в спринте.

3. Генеральный план должен быть скорректирован, как вы идете. Вы узнаете вещи, как вы работаете. Появятся новые возможности, появятся точки конфликта в плане. Вы можете настроить генеральный план на ходу. Но почти всегда вы должны пересматривать его между спринтами - чтобы включить уроки последнего спринта и убедиться, что следующий спринт находится в гармонии с общей картиной.

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

Отставание, в отличие от генерального плана, может быть добавлено другими членами команды. Владелец основного проекта должен убедиться, что элементы отставания и план общей картины остаются в гармонии - иногда корректируя элемент отставания, а иногда и план общей картины.

Этот метод сохраняет силу гибкости и способность выравнивать все элементы вашего проекта наилучшим образом в данный момент времени посредством планирования больших изображений.

Джим

Я добавлю краткую форму моей анти-проворной напыщенной речи здесь.

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

Я немного расстроен по этому поводу, потому что сам был сожжен этим. Мы переписываем некоторые из наших основных библиотек. Первые этапы были выполнены и выполнили основные задачи для их спринтов. Это все очень проворно. Затем меня взяли на борт, чтобы добавить некоторые функции динамической загрузки. Тем не менее, я был в тупике около шести недель, потому что то, что было написано ранее, предполагало, что никогда не будет динамической загрузки, я потратил много времени на переписывание и работу над тем, что уже было. Хуже всего то, что динамическая загрузка была в спецификации в начале; Если бы начальная работа учитывала все будущие требования и выполняла «большую работу по проектированию», которую гибкие практики считают плохой, я мог бы реализовать свою функцию за несколько дней.

Урок заключается в том, чтобы использовать Agile для небольших вещей, которые вы готовы выбросить. Иногда это может быть здорово. Тем не менее, это не единственный верный путь разработки программного обеспечения. При написании основополагающего кода, который сопряжен с высоким риском или имеет большой срок службы, сделайте большой дизайн.