Появившись в сфере софтвера, молодые гибкие методологии совершили настоящий переворот:
-
на первое место вышли люди и коммуникации вместо жестких процессов;
-
основное внимание уделяется продукту, а не проектной документации о нем;
-
партнерские отношения с заказчиком встали на место жестких условий договора;
-
команда готова к изменениям в ходе проекта и корректировке плана.
Эти пункты сформулированы в документе Agile Manifesto от основателей гибких методологий. Прочитать его полностью можно на сайте agilemanifesto.org
Ориентируйтесь в своей работе на эти весы. Однако это не значит, что понятия с правой чаши полностью отсутствуют в гибкой методологии, просто они стоят на втором месте.
Принципы гибких методологий
Следуя этим правилам, вы получаете гибкую методологию и высокий результат:
-
На первом месте – удовлетворение заказчика регулярными постоянными поставками ценных для него продуктов. Сложность в том, что программный продукт невидим и часто непонятен потребителю. Ваша задача – постоянно поставлять продукт и собирать отзывы о нем.
-
Принимайте изменения в требованиях на любом этапе работ. Чаще всего клиент понимает, какой функционал ему действительно нужен, а какой нет, уже в ходе реализации проекта, и это нормально.
-
Работайте быстро и гибко. В современной софтверной сфере все меняется крайне быстро, и если выполнять проект годами, не реагируя на изменения, он будет никому не нужен.
-
Предоставляйте заказчику готовое ПО каждые несколько недель/месяцев (чем чаще, тем лучше) вместо бесконечных макетов и техзаданий.
-
Представители заказчика и исполнители должны сотрудничать. Знание специфики своей сферы и потребностей аудитории – вот то, чем вам может помочь клиент.
-
Мотивируйте людей, доверяйте им и создавайте подходящую среду. Гибкая методология подразумевает доверие команде без постоянного микроконтроля.
-
Оптимальный способ коммуникации – личная беседа. Проводить ее лучше наглядно – возле доски с маркером.
-
Главный показатель прогресса проекта – рабочее ПО, а именно, количество рабочего функционала.
-
Постоянно меняйтесь и улучшайтесь – всей командой.
-
Техническое совершенство и гибкая архитектура позволяют мобильно реагировать на любые изменения и оптимизировать проект в дальнейшем.
-
Создавайте простой продукт. В нем нет ничего лишнего и сложного, им удобно пользоваться, поддерживать и изменять.
-
Самоорганизация – залог хорошей работы. Помогите команде профессионалов самоорганизоваться, поставьте цель, и вы получите результат.
-
Постоянно ищите пути улучшения во всем, иначе будете обречены топтаться на месте.
И немного о Scrum
Сегодня это самая популярная гибкая модель управления проектами в сфере разработки ПО. Работа проходит в небольших командах, в которых есть все специалисты для осуществления проекта. Отдельный человек – скрам-мастер следит за процессами в команде и поддерживает продуктивную атмосферу.
Требования к продукту разбейте на конкретные независимые друг от друга элементы функционала, сортируйте их по приоритетности и оцените объем каждого. В итоге вы получите бэклог (журнал пожеланий продукта). Выделите человека, ответственного за реализацию требований – это владелец продукта.
Работа ведется в течение коротких отрезков (спринты или итерации) – 1-4 недели. В конце каждого дня проводится скрам-митинг, где обсуждается работа и проблемы, происходит синхронизация. За это время с учетом пожеланий и их приоритета создается завершенный функционал, готовый к выпуску на рынок – инкремент продукта.
По окончании каждого спринта проходит обзор спринта, оценка владельца продукта и анализ оптимизации процессов. На каждом этапе владелец может внести коррективы в требования и приоритеты и начать новый спринт.
Scrum, конечно, хорош, но это не мешает изучать другие методологии, брать из них лучшее и использовать на различных этапах.
Кстати, популярность гибких методологий, по исследованиям Agile Servey, выглядит таким образом:
Канбан
Система Канбан известна своей педантичностью. Неудивительно, ведь впервые ее стала использовать японская фирма «Toyota». Эта практика требует высокой самодисциплины участников и четкого следования правилам.
-
Визуализировать процесс. Неважно как: маркером на доске или в электронном варианте на проекторе – главное, чтобы этапы работы были четко размечены.
-
Ограничить объем незавершенной работы (Work in Progress). В каждом столбце нужно указать максимальное количество задач.
-
Оптимизировать процесс. Отслеживайте среднее время выполнения задачи и стремитесь уменьшить его путем оптимизации без потери для качества
Благодаря малому числу директив, перейти на систему Канбан совсем не сложно. Вы можете протестировать ее после Scrum или попробовать совместить методики.