Публикую мысли, сформулированные одним из наших заказчиков. Без правки и корректировок – как есть. И давайте срочно обсуждать. И так:
Основные причины обратиться к Agile – неудовлетворенность сроками внедрения решений/процессов и соответствия результатов требованиям в динамично меняющейся среде.
Итак, что такое Agile применительно к внедрению и развитию процессов?
Берем Agile manifesto (есть терпимый перевод на Википедии). Выписываем. Меняем слова.
Ценности Agile:
1. Individuals and interactions over processes formal rules and tools.
Личности и их взаимодействие важнее, чем формальные правила и инструменты
Не совсем адекватная замена, плюс морально сложно вычеркивать слово "процесс", но в противном случае это звучало бы как "личности и их взамиодействие важнее, чем процессы развития процессов и инструменты".
2. Working software processes over comprehensive process documentation.
Работающий процесс важнее, чем полная документация по нему
3. Customer collaboration over contract negotiation.
Сотрудничество с заказчиком важнее, чем контрактные обязательства
Это не очень четко ложится на процессную тематику, но тоже поддается расшифровке.
4. Responding to change over following a plan
Реакция на изменения важнее, чем следование плану
Аналогично корректируем
Принципы Agile:
-
удовлетворение клиента за счёт ранней и бесперебойной поставки
ценного ПОпроцессов, приносящих пользу; -
приветствие изменений требований, даже в конце разработки (это может повысить
конкурентоспособностьработоспособность полученногопродуктапроцесса); -
частая
поставка рабочего ПОобновление процесса (каждые несколько месяцев или недель, желательно – чаще); - тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
- проектом должны заниматься мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
- рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
-
работающее ПОработающий процесс — лучший измеритель прогресса; - спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
- постоянное внимание на улучшение технического мастерства и удобный дизайн;
- простота — искусство НЕ делать лишней работы;
- лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды
- команда регулярно должна искать пути стать более эффективной, найдя – начинать вести себя соответственно
Ключевое отличие подходов waterfall и agile:
- waterfall фиксирует scope (требования), стоимость и сроки являются зависимыми величинами
- agile фиксирует срок (продолжительность итерации), scope является зависимой величиной
Очевидные плюсы и минусы:
Плюсы:
- гораздо более высокая вероятность получить в результате работающий процесс, а не комплект документации в стол
- возможность получить ранние полезные результаты, опыт эксплуатации которых поможет на следующих итерациях
Минусы:
- существуют риски получения конечного результата (в нашем случае – полноценного всеохватывающего процесса) в более долгие сроки, чем при waterfall подходе
- более высокие требования к квалификации и дисциплине команды, чем при waterfall
- Agile практически не совместим с Fixed-price контрактным подходом, подходит только для внутренних процессных команд или внешних подрядчиков, к которым у заказчика есть полное доверие
- предполагает частые, но небольшие изменения процесса, что каждый требует дополнительной организационной работы (хотя непонятно, почему ИТ не так сильно заботит то, что бизнес каждый раз должен корректировать свои процессы при выходе новой версии ПО)
-
Agile считается ограниченно годным для критичных для организации
ПОпроцессов (хотя к ИТ это может относиться только разве что к Incident Management, и то не везде) и для крупных проектов (хотя я пока не видел ITSM проекта, в котором бы участвовало более 20 проектировщиков).
Минусов вроде как получилось больше, но плюсы таковы, что могут все их перевесить. Могут?
Думаю, что могут. Пробую, как раз сейчас на практике.
Кстати, в случае с ITSM, я бы обратил внимание на Lean и Kanban принципы больше, чем на манифест. 🙂
И ещё. Если не трудно, поясните вот это утверждение примером:
Agile практически не совместим с Fixed-price контрактным подходом, подходит только для внутренних процессных команд или внешних подрядчиков, к которым у заказчика есть полное доверие