Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - читать онлайн книгу. Автор: Роб Коул, Эдвард Скотчер cтр.№ 7

• взаимодействием людей друг с другом и творческими подходами к решению проблем;

• участием бизнес-представителей и заказчика во всем процессе работы над проектом, начиная от концепции и заканчивая получением прибыли;

• сокращением «времени до рынка» для получения или сохранения конкурентоспособности;

• ранним получением работающего продукта и, как следствие, быстрой обратной связью;

• поэтапным добавлением улучшений с целью сохранить актуальность продукта;

• атмосферой гибкости и способности к изменениям;

• возможностью вносить значительные изменения, чтобы «оставаться в игре»;

• требованиями заказчика и конечного пользователя как основой для принятия решений;

• выпуском продукта, который является самым главным!

Блистательный пример

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

• начинать с самых важных требований и не более того;

• урезать стартовый бюджет до минимума;

• предполагать прибыли;

• расширять возможности команды;

• быстро приступать к разработке;

• изменять направление разработки, как только возникнет такая необходимость.

Лакмусовая бумажка для Agile-проекта – удалось ли воплотить концепт в реальность.

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

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

Может возникнуть ощущение, что Agile-проекты выглядят как жизнь на Диком Западе – почти никакого управления, никакой документации, слабо разграниченные роли и обязанности. Но на самом деле все обстоит не так. Все организовано более легковесно, чтобы не перегружать рабочий процесс.

Блистательное определение

Есть тонкая грань между фреймворком и процессом. В данном контексте фреймворк – это серия гибких ориентиров, а процесс проекта – более жесткая и негибкая схема. Фреймворк позволяет, процесс – ограничивает.

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

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

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

Agile-вариант позволяет меньше волноваться о соблюдении правильности процесса и сосредоточиться на конечном продукте.

Блистательный пример

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

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

Время до рынка (time-to-market) имеет решающее значение, но сама разработка продукта занимает только часть времени от момента высказывания идеи до ее успешной реализации. Часто бывает, что само начало разработки сопряжено с определенными усилиями, и этот период простоя сам по себе проблема и является частью процесса под названием технико-экономическое обоснование (feasibility study).

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

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