Гибкие методологии разработки - Часть 1
Гибкие методологии разработки - Часть 1. Семейство гибких методологий буквально ворвалось на софтверную сцену и перевернуло всё с ног наголовуAgile-методологии
Семейство гибких методологий буквально ворвалось на софтверную сцену и перевернуло всё с ног наголову:
- Мы стали сосредотачиваться на людях и улучшении коммуникаций между ними, вместо выстраивания сверхжестких процессов;
- Мы стали концентрироваться на продукте, вместо того чтобы писать изощренную проектную документацию, которую никто не читает;
- Мы больше не заставляем расписываться заказчика кровью, ограничивая его жесткими и неудобными условиями договоров, мы строим действительно партнерские отношения и выясняем, что хочет заказчик и что ему нужно;
- Мы всегда готовы к изменениям, потому что понимаем, что мир вокруг нас меняется и то, что месяц назад казалось абсолютно необходимым в нашем проекте, сейчас уже не нужно вообще.
В более строгом варианте эти тезисы были сформулированы отцами-основателями гибких методологий в документе, который получил название Agile Manifesto:
- Люди и их взаимодействие важнее процессов и инструментов;
- Готовый продукт важнее документации по нему;
- Сотрудничество с заказчиком важнее жестких контрактных ограничений;
- Реакция на изменения важнее следования плану.
Полный текст манифеста (и его переводы) доступны на сайте http://agilemanifesto.org.
Каждый, кто хочет работать по гибкой методологии должен ориентироваться на эти четыре «взвешивания»: как только начинает перевешивать не та «чаша весов», надо задуматься: «А на верном ли я пути?». Таким образом, манифест станет вашим компасом, по которому можно определять направление движения.
Принципы Agile
- Наш высший приоритет – это удовлетворение заказчика с помощью частых и непрерывных поставок продукта, ценного для него.
- Мы принимаем изменения в требования, даже на поздних этапах реализации проекта.
- Гибкие процессы приветствуют изменения, что является конкурентным преимуществом для заказчика.
- Поставлять полностью рабочее программное обеспечение каждые несколько недель, в крайнем случае, каждые несколько месяцев. Чем чаще, тем лучше.
- Представители бизнеса и команда разработки должны работать вместе над проектом.
- Успешные проекты строятся мотивированными людьми. Дайте им подходящую окружающую среду, снабдите всем необходимым и доверьте сделать свою работу.
- Самый эффективный метод взаимодействия и обмена информацией – это личная беседа.
- Рабочее программное обеспечение – главная мера прогресса проекта
- Гибкие процессы способствуют непрерывному развитию. Все участники проекта должны уметь выдерживать такой постоянный темп.
- Постоянное внимание к техническому совершенству и качественной архитектуре способствуют гибкости.
- Простота необходима, как искусство максимизации работы, которую не следует делать.
- Лучшая архитектура, требования, дизайн создается в самоорганизующихся командах.
- Команда постоянно ищет способы стать более эффективной, путем настройки и адаптации своих процессов
Scrum в двух словах
Организуйте работу в вашей организации в небольших кроссфункциональных командах, которые содержат всех необходимых специалистов. Выделите человека - скрам-мастера, который будет отвечать за соблюдение процессов в команде и конструктивную атмосферу.
Требования разбейте на небольшие, ориентированные на пользователей, функциональные части, которые максимально независимы друг от друга, в результате чего получите беклог продукта. Затем упорядочите элементы беклога по их важности и произведите относительную оценку объемов каждой истории. Выделите отдельного человека – владельца продукта, который будет отвечать за требования и их приоритеты, замыкая на себя всех заинтересованных лиц.
Всю работу ведите короткими (от 1 до 4 недель) фиксированными итерациями – спринтами, поставляя в конце каждого из них законченный функционал, который можно при необходимости вывести на рынок – инкремент продукта. Команда согласно своей скорости набирает задачи на неизменяемую по времени итерацию – спринт. Каждый день проводится скрам-митинг, на котором команда синхронизирует свою работу и обсуждает проблемы. В процессе работы члены команды берут в работу элементы беклога согласно приоритету.
В конце каждого спринта проводите обзор спринта, чтобы получить обратную связь от владельца продукта, и ретроспективу спринта, чтобы оптимизировать ваши процессы. После этого владелец продукта может изменить требования и их приоритеты и запустить новый спринт.
Вторая часть - Вольфсон Борис "Гибкие методологии разработки" - Часть 2