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

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

1. Люди важнее процессов
2. Результат (ПО) важнее чем его описание
3. Заказчик должен максимально участвовать в проекте
4. Изменения на лету, это природно

Основное кредо Agile можно смело сформулировать как "Гибкость, коммуникация и результат, результат, результат".

Давайте распишем принципы чуть подробнее..

Люди важнее процессов

Как и любой процесс, процесс создания программного обеспечения, страдает формализмом и оторванностью от реального мира хотя бы в силу того, что многообразие окружающей среды невозможно точно и подробно описать в 15 или 150 пунктах, а процессы из 150 000 шагов не поддерживаемы по определению. Поэтому никакой процесс не является панацеей от провала. А вот команда профессионалов своего дела способна создавать действительно гениальные вещи. Отсюда напрашивается вывод:

Agile процессы должны стимулировать

1. коммандную работу
2. мотивацию и ответственность каждого члена команды за результат
3. работу, повышающую мотивацию сотрудника

Agile процессы должны минимизировать

1. механическую работу
2. работу, уменьшающую мотивацию сотрудника

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

Результат (ПО) важнее чем его описание

В конечном счете заказчик платит за продукт а не за его описание, поэтому если у вас есть выбор, на что тратить деньги и время, здравый смысл подсказывает: на разработку функционала, конечно. А еще давайте вспомним предыдущие рассуждения о мотивации. Двойная выгода, не так ли?

Заказчик должен максимально участвовать в проекте

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

Изменения на лету, это природно

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

Ограничения Agile методологии

1. Fixed Price проекты. Попробуйте адекватно оценить проект если вы декларируете поздний сбор требований.
2. Проекты ПО, выполняющего критические работы. Согласитесь, если ПО на атомной станции сбойнет, это будет очень грустно. Именно поэтому для таких проектов важны стандартизирвованные шаблоны и процессы, поскольку они позволяют создавать ПО заранее оговоренного качества, хотя и стоит это будет дорого. Но за безопасность нужно платить…
3. Проекты в совершенно новой области. Абсолютно не зная специфики предметной области будет преступлением начинать проект с чего либо другого, кроме как глубокого анализа, сбора требований, прототипирования, фиксирования архитектуры и т д.
4. Проекты большого размера и сложности, имеющие длительный срок разработки и внедрения. Чем  больше проект, тем тяжелее держать его под контролем, тем сложнее оценивать влияние одних фич на другие, тем больше важности приобретает документирование и проектирование.
5. Низкий уровень квалификации команды. Впрочем с такой командой трудно будет создать нечто при любом подходе

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

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

Еще по теме

1. Управление комплексными интеграционными проектами
2. Billing mediation или за все нужно платить
3. Scrum, Scrum и Scrum
4. А что собственно разрабатывать или DAAP как оно есть