Мы уже рассказывали как выбрать разработчика для вашего Интернет проекта, теперь остановимся на процессе разработке, одном из вариантов его организации.
Термин гибкой разработки или Agile давно и прочно вошел в наш лексикон и в нашу жизнь: его используют не только специалисты в области проектного управления, но и большинство из нас, он встречается в художественной литературе, новостях, анекдотах.
При этом далеко не все знают, что Agile это не конкретный метод управления проектом, а всего лишь набор приоритетов и установок. Всего 4 приоритета и 12 установок. Alige в целом называют манифестом; помните манифест . А конкретных методик, которые поддерживают эти принципы и установки очень много, 8 шт (на картинке) только самых известных и широко применяемых.
Итак, вот приоритеты манифеста Agile:
П1. Готовность к изменениям важнее первоначального плана
(и это, по моему мнению, главное, все остальное следствие)
То есть, мы делаем какую-то часть работ проекта (например, "прополка картошки" в проекте "выращивание картошки") и в процессе видим, что нужно сделать что-то дополнительное и не запланированное (заметили колорадских жуков) - быстро переиграли план работ и переключились (на жуков, так как они быстро все сожрут, если не переключиться). А те кто не переключился (сперва все прополю, а потом с жуками разберусь) - не по Agile работают.
Из этого приоритета следует и первые установки:
У1. Необходима адаптация к изменяющимся обстоятельствам на всем протяжении проекта. Участники проекта должны постоянно анализировать варианты улучшения эффективности; соответственно и изменять план и стиль работ по ходу процесса
У2. Нужно приветствовать изменения даже в на завершающих стадиях проекта, это может улучшить результат
У3. Особое внимание нужно уделять улучшению технической части (если это ПО, то вопросам архитектуры, например) и удобному дизайну;
П2. Работающий продукт важнее детальной документации.
Тут вообще все просто, весь смысл раскрывается старой доброй поговоркой: "Вам шашечки или ехать?". У нас часто бывает обратное - по бумагам все отлично, а на деле ничего не работает.
Данный приоритет задает такие установки:
У4. Работающий продукт — главный показатель эффективности и прогресса в проекте;
У5. Обязательны частые релизы: не реже, чем каждый месяц, а лучше каждую неделю, а в некоторых случаях необходимо ещё чаще;
П3. Взаимодействие и отношения в команде важнее формальных процессов и используемых инструментов.
Идея простая: нужно больше общаться, чтобы командная работа была эффективнее. Бывает ведь как - я написал письмо, вроде как жду ответа и хотя часть ответа я знаю с большой вероятностью наверняка, но формально пока начальник не дал отмашку - ничего делать не буду... это не гибко, это не Agile! Надо обсудить проблему всей командой ЛИЧНО, глядя в глаза друг другу или по крайней мере в групповом Скайп-звонке, но очно. Все таск трекеры и другие инструменты должны фиксировать данные и процессы, но не быть основной обсуждений.
У этого приоритета есть следствия-установки:
У6. Личное общение - лучший способ обсуждения и приема-передачи информации;
У7. Для получения лучшего результата команда проекта должна стремиться к самоорганизации;
П4. Взаимодействие с заказчиком и его интересы важнее условий изначальных соглашений.
С одной стороны этот приоритет спорный, потому что, как говориться, "а за чей счет этот банкет"? То есть, если в процессе выполнения работ по проекту у заказчика что-то изменилось в приоритетах и процессах - надо же пересматривать сметы, сроки, объем? И да и нет. На самом деле, Agile, как мы уже знаем, не является конкретным регламентом или методикой. А П4 говорит нам о том, что делать работу, которая не будет нужна, смысла нет, и более того, надо как можно скорее узнать о том, что работа не актуальна и осознать подобные риски. А это можно сделать эффективно и оперативно опять-таки только при личном ежедневном общении.
У8. Общение заказчика с исполнителями должно быть ежедневным и постоянным все время работы над проектом;
У9. Удовлетворение заказчика достигается засчёт быстрой и надежной поставки новых релизов, добавляющих ценность проекту;
Есть также общие установки, которые определяются, по сути, всеми принципами:
У10. Участники проекта должны быть должным образом замотивированы и обеспечены нужными условиями работы, поддержкой и доверием;
У11. Заказчики, исполнители в проекте и конечные пользователи должны иметь возможность поддерживать постоянный рабочий режим взаимодействия;
У12. Всем участникам проекта нужно стремиться к простоте, которая в данном случае понимается как искусство не делать лишней работы;
Как видите, все очень просто, логично и интуитивно понятно. Причем понятно и то, почему это хорошо и полезно. Более того, отдельные принципы и установки мы постоянно используем как в работе, так и в обычной жизни (не зря я приводил примеры с картошкой). Суть в том, чтобы использовать и учитывать их все без исключения.