Окончательное введение в гибкое управление проектами

Бриф

Вы отвечаете за реализацию последней и величайшей инициативы вашей компании, которая навсегда изменит лицо «Widgets International». Это программный проект, который привлечет и увлечет ваших клиентов, облегчит жизнь вашим коллегам и принесет компании миллионные доходы. Есть много предвкушения, пыла, волнения и ожидания. Вам нужно сделать это как можно быстрее, чтобы ваш бизнес начал пожинать плоды. Будущий успех компании зависит от вас. Все глаза на вас. Вы не можете потерпеть неудачу.

Сначала вы думаете про себя: «Отлично, я готов принять вызов. Давайте сделаем это дело!» Вы останавливаетесь на мгновение, делаете шаг назад и думаете про себя: «Хорошо, так как же нам это сделать?» Вы начинаете общаться со своими коллегами и сверстниками. Вы тратите время на поиск лучших практик разработки программного обеспечения и методов управления проектами, но вариантов и подходов бесчисленное множество. Существует множество акронимов и методологий. Знаменитые поднимаются на вершину. Закрадывается сомнение. Какой из них мы должны использовать? Как я могу гарантировать успех? Что, если я приму неверные решения?

Когда дело доходит до управления программными проектами, существует огромное количество вариантов, поддерживаемых множеством мнений. Голоса из углов комнаты шепчут: «Попробуй сделать так»; другие кричат: «Это единственный способ сделать это»; а остальные только хнычут: «Ни в коем случае не берись за это, просто продолжай». На самом деле все эти голоса говорят какую-то правду. Но важно определить, что подходит именно вам, вашей команде, вашему бизнесу и вашим клиентам.

Настройка сцены

Было время, когда управление проектами по программному обеспечению находилось прямо в одном из трех лагерей. Были тяжелые фреймворки, которые позволяли вам принимать решения о том, как вы выполняете и доставляли, предлагая структуру для поддержания контроля и управления. Были предписывающие последовательные методологии, такие как водопад, который заставлял вас планировать длительные проекты, понимать и выполнять все ваши требования, проектировать и подписывать сложные системы, писать много кода, а затем тестировать (и все это до того, как ваш клиент увидит это в первый раз). время). И, наконец, менее директивные, но итеративные жизненные циклы разработки программного обеспечения (SDLC), которые поощряют быстрое прототипирование или проектирование, создание и поставку более крупных систем поэтапно, каждое из которых строится поверх другого.

Agile-разработка программного обеспечения и Agile-управление проектами родились из-за недостатков водопада и преимуществ итеративных подходов к доставке программного обеспечения. Их корни можно проследить до 1950-х годов, идейное лидерство — в 70-х, зрелость — в 90-х, а усыновление — в 00-х. В 2001 году группа практиков и экспертов создала Agile-манифест, направленный на определение 4 ценностей и 12 руководящих принципов, которые стремятся воплотить дух Agile-разработки программного обеспечения и способствовать его развитию. И он определенно эволюционировал.

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

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

Ранее я упоминал, что Agile применительно к разработке программного обеспечения или управлению проектами может быть разным. Короче говоря, Agile-разработка программного обеспечения заботится о разработке отличного программного обеспечения в обычном бизнесе (BAU) или в контексте проекта. Гибкое управление проектами, с другой стороны, обеспечивает управление и контроль, необходимые для реализации сложных проектов, включая, помимо прочего, программное обеспечение.

Существует множество доступных методов разработки программного обеспечения Agile, таких как Scrum, Kanban, XP и Lean Software Development. Но точно так же, как игра в регби — это нечто большее, чем схватка, так и Agile. По отдельности эти парадигмы Agile не охватывают полный жизненный цикл управления проектами, необходимый в сложных проектах, таких как управление, ресурсы, финансы, явное управление рисками и многие другие важные концепции управления проектами. Для них вы можете рассмотреть Agile PMI или PRINCE2 Agile — думайте об этом как о «управляемой гибкости».

Почему нам нужно быть гибкими?

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

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

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

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

Ниже перечислены некоторые преимущества, которые вы можете ожидать:

• Скорость выхода на рынок
• Раннее получение дохода
• Регулярная доставка реальной стоимости
• Защита ваших инвестиций
• Данные, данные, данные
• Лучшее качество продукции
• Управляемые ожидания
• Повышение удовлетворенности клиентов
• Команды с более высокими показателями
• Улучшена видимость прогресса
• Предсказуемость, прозрачность и уверенность
• Управляемый риск

Успех не окончателен, неудача не фатальна: важна смелость продолжать.

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

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

осуществимость

Итак, теперь вы думаете: «Хорошо, я понял. Как мне начать? С чего начать?» Что ж, со всеми хорошими вещами, мы начнем с самого начала. А в Agile нужно задать себе вопрос: «Какую ценность для бизнеса я хочу принести?» В конце концов, именно поэтому мы беремся за проекты, чтобы создавать ценность для бизнеса. Для того, чтобы установить, стоит ли браться за проект для получения ценности для бизнеса, вам необходимо понять, осуществимо ли это.

Зрение

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

• Ваше видение может исходить из разных источников — вашего собственного смелого стартапа для решения общей проблемы, стратегии управления бизнесом, любимого проекта вашего генерального директора, конкретной группы разработчиков продукта или даже потребностей вашего клиента.
• Попробуйте сделать шаг назад и «увидеть», как выглядит будущее с вашим новым продуктом или услугой в руках ваших клиентов.
• Привлекайте заинтересованные стороны — генерального директора, специалиста по продукту и клиентов. Практикуйте это, не пытайтесь делать это в одиночку. Бросьте вызов предположениям и подтвердите аргументы.
• Запишите его, будьте кратки. Сосредоточьтесь на ценности бизнеса.
• Уточняйте его до тех пор, пока вы все не согласитесь, что видение находит отклик у всех и соответствует общепринятой интерпретации, указывающей, куда вы направляетесь.
• Ваше видение, если оно правильное, редко меняется. То, как вы туда доберетесь, наверняка будет.

Люди не покупают то, что вы делаете или как вы это делаете. Они покупают «почему» вы это делаете. Это то, что создает эмоциональную связь между вашим бизнесом и вашими клиентами. Видение поможет проиллюстрировать это.

Возможно ли это?

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

• Если вы хотите совершить поездку в любую точку мира менее чем за час, у вас могут возникнуть проблемы с технической осуществимостью. Поскольку наука, физика и технология еще не догнали эту мечту, ваше техническое решение может оказаться нежизнеспособным ни в чем, кроме теории. Кроме того, если бы ваше решение было новым, оно вышло бы далеко за рамки идеи минимально жизнеспособного продукта (MVP).

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

  «Некоторые из лучших знаний, которые мои команды получили для понимания технической осуществимости, были получены при выполнении шипа. И часто побеждает самое простое решение!»

• Второй оттенок осуществимости, который следует учитывать, заключается в том, есть ли у вас, вашей команды или вашего бизнеса навыки и мотивация, чтобы заставить все это работать. Например, если вы умеете печь торты дома на день рождения своего ребенка, это мило. Но если вы хотите превратить это в бизнес по продаже лучших тортов в мире, вам нужно понять, сможете ли вы его масштабировать, управлять бизнесом, а также производством, управлять распределением и доставкой, а также заботиться об обслуживании клиентов.
• Этот тип видения может быть достижим в долгосрочной перспективе. Но пока, возможно, нет. Так что уменьшите его, думайте о мелочах, возьмите небольшой кусок, который выглядит реалистично, и сконцентрируйтесь на реализации наилучшего меньшего стремления, которое вы можете. Если вам удастся заинтересовать и порадовать ваших клиентов, заставьте их возвращаться, чтобы узнать больше и рассказать своим друзьям, а затем масштабируйте это, используя отзывы клиентов в качестве своего руководства и компаса.
• Кроме того, вам необходимо знать, осуществим ли ваш проект с точки зрения бюджета и сроков. Может ли ваш бизнес позволить себе реализовать этот проект? Достижимы ли сроки? Время и деньги — два из трех фиксированных ограничений Agile-проекта. Мы стремимся доставить в течение заданного фиксированного времени и в рамках заданного фиксированного бюджета.
• Качество продукта относится к конечному продукту, который используют ваши клиенты, и к инженерным методам, которые использует ваша команда для создания отличного, надежного и надежного программного обеспечения. Качество – это также то, с чем мы не скупимся. Критерии качества, с другой стороны, могут меняться. Если вы не собираетесь строить Ferrari, продукт может не иметь высокого качества. Если вы не строите космические ракеты, то допуски, достигнутые в производственных условиях, могут быть намного выше. Установите соответствующий тон и ожидание на ранней стадии.

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

Обоснование

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

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

• Напишите, протестируйте и подтвердите свой бизнес-план. Теперь это совсем не похоже на те, которые ваш банк или ваш бизнес и финансовый отдел сказал вам производить. Не используйте их — они устареют раньше, чем высохнут чернила. Вместо этого ознакомьтесь с канвой бизнес-модели. По сути, это краткий бизнес-план, в котором вы сосредоточены на своем ценностном предложении, ваших клиентах, доходах и затратах. Используйте его, чтобы проверить, есть ли у вас бизнес, который будет работать.

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

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

Как только у вас будет свое обоснование и все ваши заинтересованные стороны будут на борту, вы будете в огне.

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

Посвящение

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

Команда

В спорте, думая о своей любимой командной игре, вы сможете распознать ключевые роли, которые позволяют команде действовать так, как они. Традиционно вы найдете менеджера, капитана и остальных членов команды. Помимо этого, вы найдете тренеров, физиотерапевтов, диетологов и целый ряд вспомогательного персонала. Но если мы посмотрим на игру в регби, то увидим, что внутри команды есть команда: игроки, составляющие схватку. Этот пакет состоит из назначенных игроков, чья задача состоит в том, чтобы отыграть мяч и продолжить игру. Когда в игре схватка, игроки с каждой стороны работают без лидера как единое целое настолько совместно, коммуникабельно и эффективно, насколько это возможно, чтобы вернуть мяч обратно во владение. Именно игра в регби вдохновила Джеффа Сазерленда назвать свою методологию разработки программного обеспечения «Scrum».

• Scrum — не единственный метод разработки программного обеспечения в методологии Agile. Но это то, что лучше всего описывает концепцию и поведение Agile при работе в команде, мотивации отдельных лиц, создании доверительных отношений, самоорганизации, лидерстве-слуге, общении, прозрачности и сотрудничестве.
• Ваша команда будет сформирована в основном в зависимости от обстоятельств, в которых вы оказались. У вас могут быть разработчики. Некоторые, никто или все они могут быть знакомы с Agile в разной степени. Возможно, вы захотите нанять новую команду или стать партнером третьей стороны.
• Потребуются и другие роли, но мы обсудим их позже.
• Говорят, что если вы формируете команду разработчиков, значит, вы выбрали свою технологию. В зависимости от того, откуда вы соберете свою команду, у них будут определенные наборы навыков. Итак, тщательно продумайте, как вы формируете команду разработчиков и нужно ли вам проводить техническую оценку, прежде чем вы доберетесь до этой точки своего пути.
• Это приводит нас к кросс-функциональным командам. Команды работают лучше всего, когда они работают вместе, когда отдельные люди вмешиваются в работу, независимо от их должности. Постарайтесь создать команду, которая самодостаточна, и людей, которые берут на себя более одной роли.
• Создайте среду, культуру и центр взаимоотношений — место, где команда может работать, не обремененная ограничениями или запретами. Предоставьте команде инструменты, людей, ресурсы и пространство, чтобы она была эффективной и результативной.
• Сохраняйте размер команды не более семи или восьми человек. Если вам нужно больше разработчиков, разделите команду на несколько новых команд. Затем каждая команда может нести ответственность за определенную функциональную область. Если у вас есть несколько команд в разных местах, рассмотрите возможность проведения Scrum of Scrums. А там, где их много в сложных средах, используйте Agile-управление проектами.
• Убедитесь, что команда, бизнес, заинтересованные стороны и даже клиенты имеют доступ друг к другу. Убедитесь, что они общаются и сотрудничают, и удалите все, что мешает прогрессу. Ежедневное общение — лучшее лекарство от недугов проекта. Когда люди говорят, они что-то делают.

Существует множество способов собрать команду для разработки программного обеспечения.

Краткое описание проекта

На этапе технико-экономического обоснования вы выяснили, «почему» вашего проекта, и либо укрепили свою уверенность, чтобы продвигаться вперед с вашим стартапом, либо получили поддержку для продолжения. Краткое описание проекта — это живой документ, который объединяет «почему» с «что», «когда» и «кто». Он «живой», потому что по мере вашего продвижения ваше знание, понимание и путь могут меняться. Оставить этот документ однажды написанным и никогда больше к нему не возвращаться — значит, привязывать свои мысли к определенному моменту времени. В Agile-мире эталонная точка во времени может меняться еженедельно или даже ежедневно на раннем этапе, поэтому важно поддерживать ее в актуальном состоянии.

• Отличным инструментом для составления и поддержания брифа проекта является то, что Джонатан Расмуссон называет «начальной колодой» в своей книге «Проворный самурай ». Здесь вы найдете отличные советы о том, как убедиться, что все, кто интересуется вашим проектом, затрагивает его или участвует в нем, находятся на одной странице.
• Величайшим врагом реализации проектов является нечеткое, непоследовательное или просто отличное понимание того, что представляет собой проект и какие «требования» должны быть удовлетворены. Если даже у одного важного заинтересованного лица другое понимание или точка зрения на то, что вы делаете, последствия могут быть существенными.
• Хороший бриф проекта сообщает:
  1. Общее и согласованное ожидание между заинтересованными сторонами и членами команды.
  2. Понимание проекта с одинаковым пониманием у всех сторон.
  3. Цель, видение, задача, масштаб и контекст проекта.
• У вас будет много полезной информации для брифа, собранной из технико-экономического обоснования. Бриф проекта поможет вам определить и найти ответы на поисковые вопросы. Он объединит заинтересованные стороны, ваш смысл существования , масштаб высокого уровня, риски, целевое решение, бюджет, сроки, ожидания и приоритеты.

Однажды коллега остановил меня в коридоре и спросил, где можно взять техническое задание для проекта. Я пошутил: «Нам не нужен бриф, мы Agile». Он выглядел сбитым с толку, как будто сомневался в моем здравомыслии или авторитете. Он был прав.

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

Культура и методы работы

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

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

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

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

• Направьте свою команду на определение концепций, методов, моделей поведения и фреймворков Agile, которые, по вашему мнению, соответствуют вашим коллективным потребностям.
• Принимайте запросы от членов вашей команды о том, какие у них есть требования, чтобы помочь им работать как можно лучше. Некоторые из этих запросов вы сможете решить немедленно. В других случаях вам может понадобиться бюджет или помощь извне. Сделайте все возможное, чтобы это произошло.
• Это ваши первые шаги к тому, чтобы стать настоящим лидером-слугой.
• Подумайте об организации соответствующего обучения концепциям и методам, которые ваша команда решит принять. Это лучший способ убедиться, что все члены вашей команды, даже заинтересованные стороны, находятся на одной странице и получают одно и то же сообщение. Работайте с организацией-поставщиком, которая может адаптировать свое предложение к вашим потребностям.
• Будьте благоразумны. Никто не станет Agile-ниндзя после нескольких дней обучения на семинаре, как стать Agile. Твой путь будет долгим. Слово «стать» вполне определяющее. Только когда вы действительно примете Agile, вы увидите его ценность. Это должно вас взволновать. Если это волнует вас, то идите и возбуждайте других.
• Теперь, когда ваша команда согласовала концепции и методы, выполнила свои пожелания и прошла обучение Agile, обратите внимание вашей команды на самих себя и на то, что они ожидают от вас, бизнеса и друг от друга.
• Определение некоторых способов работы (WoW) внутри команды и внутри нее помогает укрепить доверие, отношения и ожидания. WoW — это не война и мир . Оно должно быть кратким и содержательным, от семи до десяти предложений, отмеченных маркером. Эти предложения ясно показывают, как люди ведут себя, общаются, сотрудничают, поддерживают, доставляют и работают вместе. В нем также должно быть указано, что команда ожидает от бизнеса.

• Agile — это не только образ мышления, но и руководящие принципы и концепции. Это помогает вам развиваться в том, как вы ведете себя, думаете, ведете переговоры, взаимодействуете, общаетесь, выполняете и совершенствуетесь. Он опирается на мотивированных людей, поддерживающих друг друга для достижения общей цели вместе как один. Есть африканская пословица:

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

Отставание

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

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

Вещь, которая нужна или желательна. Или, вещь, которая обязательна; необходимое условие.

И, к сожалению, если мы начнем определять, каким должно быть наше решение, заявив, что вещи «обязательны», мы в конечном итоге окажемся в беде. Слишком легко сказать, что все эти пользовательские истории обязательны. Если мы примем эту точку зрения, мы рискуем выйти за рамки графика и бюджета в попытке реализовать все заданные объемы. Не проблема сказать, что для этого продукта эти истории необходимы для того, чтобы решение было жизнеспособным, мы просто хотим избежать толкования этого конкретного слова.

• Всегда пишите истории с точки зрения личности. Персона представляет пользователя или заинтересованного лица решения. Это хорошая идея, чтобы развить эту персону, прежде чем вы начнете невыполненную работу.
• На этом этапе пишите только короткие, простые утверждения, которые в основном предлагают напоминание о более глубоком разговоре о пользовательской истории, когда придет время.
• Реальные люди мыслят категориями задач, которые им необходимо выполнить для достижения цели. Пишите свои истории с точки зрения личности и с точки зрения того, что им нужно сделать.
• Вам не нужно писать полный список невыполненных работ — просто напишите столько, сколько, по вашему мнению, потребуется вашим клиентам, чтобы ваш продукт был жизнеспособным.
• Позже вы обнаружите, что пользовательские истории изменятся, станут более или менее важными или могут быть полностью удалены. Частое освобождение, получение обратной связи и оценка того, что является приоритетом, будут способствовать такому поведению.
• Не пишите истории в одиночестве. Вовлекайте свою команду, заинтересованные стороны и даже ваших клиентов. Истории можно обновлять в любое время в течение жизни проекта, но их следует избегать после того, как над ними началась работа по разработке.
• Некоторые из ваших историй можно считать «эпосами». Это большие истории, которые охватывают многое и будут разбиты ближе к моменту доставки на более мелкие истории.
• Рассмотрите возможность использования модели INVEST, контрольного списка для проверки качества хорошей пользовательской истории.
• Любой может добавить историю в бэклог. Его следует разместить внизу, либо на специально созданной «парковке». Эта добавленная история служит подсказкой для обсуждения с командой и бизнесом. Если бизнес и команда поддерживают это, это можно оценить и расставить приоритеты.
• Вы также можете рассмотреть те части системы, которые являются наиболее рискованными. Если у вас есть сложная, новая или технически неизвестная пользовательская история или функция, поместите их в начало списка невыполненных работ. Таким образом, вы не будете пытаться представить сложные и важные части вашего продукта всего за несколько недель до первого выпуска.

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

Высокоуровневая оценка и расстановка приоритетов

Высокоуровневая оценка — это процесс определения размера вашего отставания. Насколько «большой» проект и какую ценность он приносит? Приоритизация — это процесс принятия решения о том, какие истории наиболее важны для вас, жизнеспособности продукта и интересах ваших клиентов. Мы хотим поставлять самые ценные товары как можно раньше, чтобы приносить максимальную пользу бизнесу, получать отзывы от клиентов и не волноваться по мелочам. Результатом будет упорядоченный невыполненный заказ, ранжированный по приоритету и соответствующему размеру.

• Истории в верхней части считаются наиболее ценными. Мы хотим доставить наиболее ценные предметы как можно раньше.
• Существует множество методов определения размера и оценки, но на данном этапе вы просто хотите получить хорошее ориентировочное представление о размере истории.
  • Используйте размеры футболок, относительные размеры, идеальные дни или баллы.
• На этом этапе у вас также не будет всей доступной информации, и это нормально. Просто беги с ним.
• Привлеките заинтересованных лиц или менеджера по продукту, если он у вас есть, и команду, которая будет выполнять эту работу.
• Мы хотим, чтобы те, кто будет проектировать, разрабатывать и тестировать работу, оценили ее, потому что лучшие люди, которых можно оценить, — это эксперты.
• Команда может начать разбивать истории на более мелкие части. Если это произойдет, напишите более детализированные, но дискретные истории.
• Команда также может начать ранжировать некоторые истории, поскольку, естественно, некоторые вещи должны быть доставлены раньше других, чтобы поддержать технологию или заданный путь пользователя.
• Между вами и командой вы также можете начать находить дыры в невыполненной работе, которые необходимо заполнить. Просто заполните эти пробелы новыми историями, оцените и расставьте приоритеты по мере необходимости.
• Расстановку приоритетов проще всего выполнить с помощью анализа MoSCoW. MoSCoW — это простой метод, который поможет вам решить, какие истории «обязательны» для успеха вашего продукта.
• Вы можете выполнить проход по приоритизации до того, как начнется оценка. Однако размер некоторых элементов также может определять решение о приоритете и реальной ценности бизнеса. Так что играйте в оценку и расстановку приоритетов друг от друга, но не ссорьтесь из-за этого!
• Никакие две истории не могут быть столь же важными, как другая. История на ранге 1 более важна или ценна, чем история на ранге 2.
• Отличный способ продемонстрировать важность или ценность истории — добавить к ней денежную ценность. Если, например, предполагается, что история А принесет 5000 долларов дополнительного дохода, а история Б может привлечь 100 долларов, то история А более ценна. Точно так же, если история C спасает бизнес больше, чем история D, история C более ценна.
• После того, как вы определите размер невыполненной работы, у вас останется число. When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Работа с небольшими приращениями имеет огромное преимущество. Это означает, что вы сосредотачиваетесь только на ближайшем будущем доставки, и с новыми входными данными, отзывами и обучением вы можете реагировать на изменения в течение короткого итеративного цикла.
• В начале релиза выполните спринт 0. Это позволит команде, бизнесу и вашему релизу проекта подготовиться и настроиться на успешную реализацию. Нарисуйте базовую техническую структуру и архитектуру, которые будут поддерживать основу для выпуска. Настройка сред, учетных записей и инструментов. Выполняйте шипы, чтобы понять сложные или неизвестные проблемы. Разработайте свои пользовательские истории для подготовки к спринту 1. Спринт 0 — это подготовка.
• Во время релиза продолжайте улучшать отставание. По мере того, как вы будете больше понимать или узнавать что-то новое, ваши приоритеты могут измениться, могут появиться новые требования, и то, что вы раньше считали отличной функцией, может быть полностью удалено.
• Не начинайте работу, которую нельзя завершить за спринт. Если это невозможно, разбейте его на более мелкие куски. И не начинайте новую работу, если ранее начатая работа не была завершена. Вы не создаете никакой ценности, начиная множество дел, которые нельзя считать завершенными. Кроме того, избегайте переключения контекста. Это деятельность по началу одной задачи, раздражению, началу другой и, что наиболее проблематично, не завершению ни того, ни другого.
• Ограничьте объем работы, выполняемой командой в любой момент времени. Например, если у вас есть три разработчика и один тестировщик, вы можете установить ограничение WIP для разработчиков и тестировщика.
• Никогда не добавляйте больше работы к спринту после того, как он был запланирован. Никогда не останавливайте спринт на полпути. Исключениями являются:
  • Если вы справились быстрее, чем ожидалось, подумайте о том, чтобы взять следующую историю из верхней части бэклога, если она подготовлена ​​должным образом.
  • Если спринт выполняется настолько плохо, что не будет завершен. Обычно это происходит только в том случае, если произошла какая-либо катастрофа.
  • Если цель спринта больше не может поддерживаться из-за немедленных изменений потребностей бизнеса.
• Если вы отмените спринт, сделайте это изящно, найдите время, чтобы переориентироваться, и начните новый спринт, как и любой другой.
• Ближе к концу релиза рассмотрите окончательный спринт релиза. Никаких новых функций не пишется, некоторые ошибки могут быть исправлены, и может быть проведена подготовка к фактическому выпуску новой версии вашего продукта для ваших клиентов. Это не значит, что вы не можете делать дополнительные выпуски для клиентов в то же время — просто это контролируемый, взвешенный и устойчивый механизм выпуска.
• В конце релиза вы можете подумать о недельном спринте. В этом спринте вы можете поработать с командой над новыми идеями или придумать новую технологию. Это отличные инструменты, которые приносят пользу бизнесу и дают команде пространство для размышлений и творчества. Это не для того, чтобы дурачиться, и все равно будет создавать ценность. В равной степени всем нужен отдых. Отпуск в это время помогает сохранить ваш каденс и скорость в хорошей форме, когда вы находитесь в середине релиза.

Определение Готово

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

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

Непрерывное измерение

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

К счастью, Agile поставляется с полезными инструментами и методами. Первое, что нужно сделать, это вернуться к Agile Manifesto, ввести следующие слова в свой любимый текстовый процессор, увеличить их до размера 96pt, распечатать и прикрепить к стене, чтобы все видели:

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

Вот некоторые другие инструменты:

• Ежедневный стендап: есть несколько вариантов этой церемонии, но суть в том, чтобы все члены команды разговаривали друг с другом лицом к лицу: будьте краткими, сфокусированными и легкими. Если что-то нуждается в длительном обсуждении, оставьте это для более продолжительного разговора между теми, кто нужен после стендапа. Если возникнут препятствия, опишите их в виде истории, добавьте в список невыполненных работ и устраните их как можно скорее. Все, что мешает вашей команде, замедляет их прогресс и может быть продемонстрировано в сниженной скорости и программном обеспечении, которое не соответствует ожиданиям.
• Velocity: это исторический инструмент. Это немного похоже на те финансовые предупреждения, которые говорят, что прошлые результаты не являются гарантией будущих результатов. Но в случае с Agile мы надеемся добиться плавной скорости команды. Именно скорость позволяет нам прогнозировать будущие результаты и уверенность в наших планах. Могут быть факторы, находящиеся вне вашего контроля, которые могут снизить количество баллов за данный спринт. Если это произойдет, вы, вероятно, сможете восстановиться. Никогда не используйте скорость как палку, чтобы победить свою команду; это не принесет вам никакой пользы. Одно можно сказать наверняка: скорость будет неустойчивой в течение первых 2–4 спринтов. Однако где-то в этом временном интервале вы должны начать видеть последовательность и стабильность. Если ваша скорость колеблется от одной крайности к другой, у вас есть проблема, которую вам нужно решить с вашей командой.
• Диаграмма выгорания: Теперь эта мера прогресса терниста. По этой причине я не дал ссылку, чтобы узнать больше — вам придется провести собственное исследование и договориться, как команда и бизнес, который работает для вас. Причина, по которой это тернисто? Ну, ни один ресурс не рассказывает ту же историю! Одна вещь, о которой договорились, заключается в том, что в рамках спринта или релиза он покажет, как вы работаете в соответствии с вашим временем. Если поддерживать его ежедневно, он покажет, находитесь ли вы на правильном пути или отклоняетесь от него. Некоторые команды используют его, чтобы показать, сколько ценности еще осталось создать, чаще всего другие используют его, чтобы показать, сколько работы осталось выполнить. Первое — это праздник успеха и создания ценности, второе менее вдохновляет и мотивирует.
• Диаграмма выгорания: если вы должны показать скорость завершения работы, используйте для этого диаграмму выгорания. Но использование диаграммы выгорания позволяет вам показать, сколько ценности было создано и сколько еще ценности вы планируете создать к концу спринта. Гораздо более мотивирующий инструмент для команды, чтобы продемонстрировать бизнесу, что было сделано (или немного, если дела идут не так хорошо…), и на что они еще нацелились. В любом случае используйте диаграммы, чтобы определить, где прогресс не отслеживается, как ожидалось, ищите шаблоны или отклонения и беритесь за них, чтобы как можно скорее устранить основную проблему. Обновляйте их ежедневно для спринтов и один раз в конце спринта для графиков выпусков.
• Доски задач: это отличные визуальные излучатели для демонстрации создаваемой ценности. При ежедневном обновлении или в любой момент дня они немедленно показывают достигнутый прогресс. В сочетании с Kanban они также являются отличными инструментами для визуализации потока и блокировок в системе. Если вы видите, что большая часть разработки была завершена, но тестирование не столь продуктивно, вы можете увидеть возникновение проблемы и отреагировать надлежащим образом и быстро.

Другими инструментами, которые следует учитывать, являются освоенная стоимость Agile, время цикла и кумулятивные блок-схемы (CFD).

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

Постоянное улучшение

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

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

Адаптируйте процесс. Удалите все, что не работает. Устранить препятствия. Ваша зрелость как Agile-команды не будет знать границ, если вы позволите.

Помимо гибкого управления проектами

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

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

Структура управления или модель управления Agile используется в сочетании со стандартными процессами Agile, такими как Scrum. Они работают двумя конкретными способами:

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

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

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

Наслаждайся путешествием.