Согласитесь, что по сравнению с “В основе нашего корпоративного стандарта управления проектами лежит PMBoK” или “Стандартные фазы проекта ведутся в соответствии со стандартом PRINCE2”, фразы “Мы используем гибкие методологии” или “Мы Agile команда” звучат как-то ну совсем неубедительно. В современной научной и отраслевой литературе идет бесконечное сравнение и рассуждение на тему эффективности Agile подхода к управлению проектами по разработке/внедрению программного обеспечения. Далеко не все компании сегодня готовы строить свои процессы на основе “гибких” методологии и тому виной огромное количество причин: некоторые из них, прямо скажем, абсурдные, и высказываются из-за неполного понимания принципов Agile, а другие вполне объективные. Но в этой статье мы расскажем не об эффективности Agile подхода и о возможностях его применения (этому мы посвятим, пожалуй, целую серию статей). Здесь мы решили рассказать о его основах и поделиться интересным видео о разработке по принципу Agile.
Итак, начнем с того, что же такое Agile подход (далее информация будет основываться на официальном документе Agile Manifesto, 2001 год). Все очень просто, есть ряд принципов, которые его определяют:
- Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки.
- Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Вроде все достаточно ясно и понятно любому человеку. Ключевые слова, которые определяют разработку по принципу Agile: готовность к изменениям, коммуникация, простота, мотивация, фокус на конечный продукт, быстрая доставка. Конечно, все это звучит довольно просто и очевидно, но на практике по-настоящему Agile команд вы встретите не так много, обратите внимание, хотя бы, на то, что “изменения приветствуются”, и вспомните, что мы рассказывали про изменения ранее. Они дорого стоят, и они таят в себе большое количество рисков. Далее, “регулярная и ранняя поставка программного продукта” подразумевает, что мы отдадим Заказчику не готовый программный продукт целиком по истечении нескольких месяцев, а сначала сделаем базу, дадим его “потрогать”, добавим “фичей” и т д.
Представьте, заказчик захотел Феррари. Вы говорите, что сделаете Феррари, примерно через год, но сначала вы сделаете ролики, зато через неделю. Через неделю вы делаете заказчику ролики, они вполне удобные и передвигаться на них уже можно, а дальше вы обещаете сделать самокат, еще через неделю. Сделав самокат, вы разрабатываете для заказчика велосипед, потом мотоцикл, а в конце концов доходите до Феррари. А возможно, вы доходите до Камаза, но выясняется, что именно Камаз то и нужен был заказчику, просто сформулировал он потребность неправильно в самом начале. Но благодаря тому, что вы постепенно шли к конечному продукта, у заказчика была возможность думать постепенно и ориентироваться на рыночную ситуацию.
У многих возникает вопрос, а что если заказчику больше не надо “фичей”, все, проект закрывается? А не проще сразу все согласовать, спланировать бюджет и сесть за разработку, через пару месяцев отдать продукт и закрыть проект? Возможно, проще. А что если потребности заказчика за месяцы разработки уже изменились и продукт будет для него уже бесполезен, когда будет наконец-то готов? Вопросов спорных, разумеется, очень много, когда мы переходим от теории к практике. Мы будем постепенно разбирать все сложные и неоднозначные моменты с практической и научной точек зрения.
Адаптация этого подхода на практике весьма интересна и заслуживает внимания, ознакомление у вас займет всего 15 минут, но, возможно, откроет много нового и интересного. Об Agile за 15 минут смотрите здесь:
