Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban . Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

Контекст

Контекст очень важен, потому что он помогает понять, что может для вас сработать, а что — нет. Мы создаем TargetProcess , достаточно большое веб-приложение. Наша команда находится на одном этаже в одном офисном здании — никакой распределенности нет и близко.

Наблюдения

Одна команда → мини-команды. С ростом компании одна команда была заменена несколькими мини-командами. Мини-команда полностью отвечает за дизайн и реализацию большой фичи и обычно состоит из дизайнера, 1-3 программистов, Product Owner, 1-2 тестировщиков и писателя. Мини-команда принимает все технические решения, брейнстормит идеи и находит решения задачи. Она очень автономна и сфокусирована.

Технология

Серверная часть достаточно стабильна. Это все тот же .NET-стэк. Хотя за это время мы мигрировали с .NET 2.0 до .NET 4. Мы добавили ESB для плагинов в прошлом году, что улучшило расширяемость и масштабируемость системы. Мы все меньше и меньше довольны тем, как работает NHibernate, и двигаемся в сторону CQRS . Front-end стабильным назвать нельзя. Текущий UI представляет собой достаточно печальный коктейль из ASP.NET Ajax, ExtJS и нашего собственного фреймворка. Текущие усилия направлены на унификацию всего этого счастья, так что в самом ближайшем будущем старый UI будет полностью заменен на новый. Что приятно, системой можно будет пользоваться и в старом, и в новом интерфейсе, а это должно серьезно упростить миграцию существующих пользователей.

Процесс

Наблюдения

Итерации → Kanban. Мы использовали итерации 3 года, а потом переключились на Kanban. В целом это было хорошим событием. Главная цель — возможность выпускать каждую фичу и каждый фикс отдельно и как можно быстрее. Многие периодичные собрания были упразднены и заменены на собрания-по-требованию. Со временем мы отказались от учета времени и оценки работы. Одним негативным эффектом отказа от итераций стало стремление фич становится большими. Когда нет итераций — нет особой необходимости разбивать работу на более мелкую. Мы с этим боролись на протяжении 3 лет с переменным успехом. В целом пока большие фичи побеждают, но в этом году ситуация стала лучше.

Поинты → Отказ от оценок. В итеративной разработке оценки необходимы. Когда мы перешли на Kanban, стало ясно, что от оценок особой пользы нет. Сейчас мы оцениваем работу на уровне «ну пару дней», «ориентировочно неделя», «не больше месяца», «очень долго». Иногда Product Owner скучает по оценкам, но, когда мы стали делать roadmap, такие общие оценки больших фич оказались достаточно точными.

Учет времени → Отказ от учета . Мы вели учет потраченного времени с первого дня жизни проекта, даже когда нас было всего четверо, работающих по вечерам и выходным. Так что учет времени был у нас в крови, и даже зарплата была привязана к количеству потраченных часов. Решение об отмене учета времени было непростым, многие в команде были против. На удивление, через пару месяцев все утряслось и подавляющее большинство людей с содроганием вспоминало заполнение тайм-шита за день. На самом деле нет никакого смысла учитывать время, если вы не оцениваете работу.

Планирование релизов → Ничего → Roadmaps. Такие шатания из стороны в сторону могут выглядеть странно (со стороны). Изначально у нас были формальные собрания по планированию релизов. А потом мы ввели Kanban, и собрания как-то умерли. Оказалось, что без планирования релизов стало хуже. Мы постоянно теряли фокус. Релиз с четким фокусом — это очень хорошая и полезная вещь. Вы фокусируетесь на важных вещах и игнорируете остальное. Если фокуса нет, то имеется огромный соблазн сделать много мелких и не очень фич, которые слабо связаны между собой. Это размывает усилия и, в конечном итоге, выпускается просто список фич. Не так давно мы решили создавать roadmaps вместо планирования релизов. В разработке у нас может быть 3-4 большие фичи. Каждая фича имеет конкретную цель и занимает от 3 до 12 месяцев. Roadmap показывает все текущие фичи и некоторые будущие, только и всего.

Дробление User Stories . Забавно, но мы все еще не умеем делать это хорошо. Дробить работу — сложно. Да, у нас есть определенные улучшения, но время от времени большие User Stories все же просачиваются в разработку без всякого дробления. Кажется, в дроблении есть какая-то внутренняя сложность.

Definition of Done . Тренд четкий: DoD год от года становится более насыщенным и включает в себя все больше и больше вещей. Процесс развивается, и хочется быть уверенным, что каждая фича готова к релизу полностью. Недавно мы добавили в DoD проверку текстов и тесты производительности.

Ежедневные собрания. Старожил нашего обзора выдержал 4 года практически без изменений. С увеличением количества людей мы всячески пытались сохранить собрание коротким и конкретным. В целом это удалось: для 15 человек собрание длится около 15 минут.

Собрания. Сейчас у нас выжили только реально полезные собрания, которые сфокусированно решают конкретные проблемы. Единственное регулярное собрание — это ежедневное утреннее. В Scrum довольно много всяких собраний. Это, может, и хорошо, когда вы только начинаете внедрять нормальный процесс разработки, но со временем они приедаются и надоедают. Собрания-по-требованию гораздо лучше: меньше людей, четче фокус, лучше результат.

User Experience. Это было круто. 4 года назад мы вообще ничего не слышали про UX . В настоящий момент UX практически встроен в ДНК компании. Многие люди в команде уделают большое внимание вопросам юзабилити, дизайна и восприятия продукта конечным пользователем. Процесс насаждения UX был достаточно длительным и начался с изменения видения продукта. Мы обучали людей, отправляли на конференции, проводили семинары, читали книги и пробовали очень разные практики. Какие-то хорошие результаты появились только через 2 года. А сейчас мы работаем на новым большим релизом, и промежуточные результаты безумно классные (пока не покажем, создаем интригу).

Craftsmanship. Обучение и развитие профессиональных качеств не было частью культуры компании 4 года назад. Началось все в 2010, когда вся стратегия развития была полностью пересмотрена и изменена. Сейчас у нас тотальный дух знаний. Серьезно.

Технические практики

Наблюдения

Один бранч → Бранчи по фичам → Один бранч. Любопытная петля. Бранчи по фичам стали возможны после внедрения Kanban. Мы их использовали на протяжении 2 лет. Однако тяга к continuous delivery требует возврата в одному бранчу, что мы и сделали несколько месяцев назад. Переход был непростой, бранчи по фичам содержать гораздо проще и безопаснее, так что недели 3-4 trunk был красным 80% времени.

Парное программирование. Эта практика прошла путь от обязательно до совершенно опциональной. Обязательное парное программирование — довольно жесткая штука. Вы вынуждены работать в паре целый день, общаться, спорить, отстаивать свою точку зрения. Это высасывает энергию. Да, ты чувствуешь, что сделал много, но работать так хотя бы несколько месяцев подряд непросто. Сейчас мы используем парное программирование в основном только для очень сложных задач.

TDD → BDD. Разработка через тестирование применялась с самой первой строчки кода (ну почти) и использовалась все время. BDD более ориентированно на конечные кейсы и более понятно для Product Owner. Сейчас он пишет спецификации в формате Given/When/Then играючи. В целом мы двигаемся к визуальным спецификациям, где много картинок, но мало слов.

И немного статистики на текущий момент:

• 5200 юнит-тестов
• 2500 функциональных тестов (1700 Selenium и 800 JavaScript тестов)
• Все тесты запускаются на 38 виртуальных машинах
• Короткая сборка (без инсталляционного пакета) занимает 40 минут
• Полная сборка занимает 1 час
• 8400 коммитов в Git-репозиторий в 2011 году

Итог

Оригинал: http://dev.by/blog/55918