В течение многих лет разработка программного обеспечения считалась запретной зоной для бизнес-менеджеров, владельцев и даже широкой публики. Это колебание было в основном вызвано пробелами в общении при определении, отслеживании и сообщении как требований, так и результатов. Если говорить очень грубо, то разработка — это очень организованный процесс, в то время как бизнес-требования, как правило, весьма динамичны в зависимости от отрасли.
Внезапно это было решение всех проблем, гибкая методология проекта. И мы все ехали в хайппоезде, и во многих случаях agile творил чудеса. Владельцы бизнеса перестали слишком заботиться о структурировании своих потребностей, а разработчики перестали слишком заботиться о том, чтобы тратить свое время на управление проектами.
В последнее время, однако, многие из предостережений Agile становятся все более и более заметными: крупные задержки проекта, огромные накладные расходы на коммуникацию и выполнение. Другой ключевой проблемой является выбор между Scrum, Extreme Programming (XP), Lean и Kanban. Различия, какими бы небольшими они ни были, по-прежнему имеют решающее значение для своевременной реализации успешного проекта.
Мы в Code Runners выбрали Scrum, но также используем методы Lean и Kanban.
Позвольте мне рассказать вам все об этом.
В зависимости от настройки проекта наша команда выбирает цикл развертывания, который затем становится «спринтом»: минимальной единицей отчетности. Обычно спринты длятся одну, две или четыре недели, но это во многом зависит от бизнес-требований.
Выступления – это хороший способ удержать разработчиков и менеджеров по проектам на одной волне для крупных проектов, но это ужасная трата времени для небольших проектов. Поэтому мы делаем стендапы только в том случае, если заказчик хочет принять активное участие.
Доски Kanban и Scrum очень эффективны и являются ключевой частью нашего рабочего процесса. Мы принимаем это решение, главным образом, исходя из продолжительности спринта — и в случае, если мы выбираем Канбан, мы готовим разные доски для каждого спринта. Это помогает нам быстро и наглядно получить информацию о статусе проекта.
Что касается бережливого подхода, который мы используем, он проявляется в нашем постоянном стремлении к обсуждению MVP с клиентом. Как только мы выясним и создадим начальный минимально жизнеспособный продукт, который будет соответствовать наиболее важным бизнес-требованиям, мы можем начать добавлять функции и улучшения в уже развернутый продукт. Таким образом, мы реализуем самую фундаментальную гибкую ступеньку: вихрь небольших, легких, быстрых обновлений.
