Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.
Контекст очень важен, потому что он помогает понять, что может для вас сработать, а что — нет. Мы создаем TargetProcess, достаточно большое веб-приложение. Наша команда находится на одном этаже в одном офисном здании — никакой распределенности нет и близко.
Одна команда → мини-команды. С ростом компании одна команда была заменена несколькими мини-командами. Мини-команда полностью отвечает за дизайн и реализацию большой фичи, и обычно состоит из дизайнера, 1-3 программистов, Product Owner, 1-2 тестировщиков и писателя. Мини-команда принимает все технические решения, брейнстормит идеи и находит решения задачи. Она очень автономна и сфокусирована. На текущий момент у нас 6 мини-команд.
Технология. Серверная часть достаточно стабильна. Это все тот-же .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 играючи. В целом, мы двигаемся к визуальным спецификациям, где много картинок, но мало слов.
И немного статистики на текущий момент:
Вот к чему мы пришли за последние 4 года
P.S. Если кто-то знает, как заставить Хабр форматировать нормально таблицы — дайте знать.
Контекст
Контекст очень важен, потому что он помогает понять, что может для вас сработать, а что — нет. Мы создаем TargetProcess, достаточно большое веб-приложение. Наша команда находится на одном этаже в одном офисном здании — никакой распределенности нет и близко.
| 2008 | 2009 | 2011 | 2012 |
| Размер компании (в человеках) | |||
| 15 | 22 | 30 | 40 |
| Структура команды | |||
| Одна кросс-функциональная команда | Две комадны: Ядро (5 разработчиков, Scrum Master, 3 тестировщика) Интеграция (3 разработчика, Team Lead, тестировщик) |
Несколько мини-команд. Мы формируем мини-команды для каждой большой фичи. Мини-команда полностью ответственна за реализацию этой фичи | Несколько (но уже больше) мини команд |
| Технологии | |||
| C#, ASP.NET, ASP.NET Ajax, NHibernate | C#, ASP.NET, ExtJS, NHibernate | C#, jQuery, NHibernate, NServiceBus | C#, NHibernate, NServiceBus, 100% Javascript front-end, REST, Python |
Наблюдения
Одна команда → мини-команды. С ростом компании одна команда была заменена несколькими мини-командами. Мини-команда полностью отвечает за дизайн и реализацию большой фичи, и обычно состоит из дизайнера, 1-3 программистов, Product Owner, 1-2 тестировщиков и писателя. Мини-команда принимает все технические решения, брейнстормит идеи и находит решения задачи. Она очень автономна и сфокусирована. На текущий момент у нас 6 мини-команд.
Технология. Серверная часть достаточно стабильна. Это все тот-же .NET стэк. Хотя за это время мы мигрировали с .NET 2.0 до .NET 4. Мы добавили ESB для плагинов в прошлом году, что улучшило расширяемость и масштабируемость системы. Мы все меньше и меньше довольны тем, как работает NHibernate, и двигаемся в сторону CQRS. Front-end стабильным назвать нельзя. Текущий UI представляет собой достаточно печальный коктейль из ASP.NET Ajax, ExtJS и нашего собственного фреймворка. Текущие усилия направлены на унификацию всего этого счастья, так что в самом ближайшем будущем старый UI будет полностью заменен на новый. Что приятно, системой можно будет пользоваться и в старом, и в новом интерфейсе, а это должно серьезно упростить миграцию существующих пользователей. Вот как менялся наш фокус на технологии по годам:
Процесс
| 2008 | 2009 | 2011 | 2012 |
| Итерации | |||
| 1 неделя | а нету итераций, мы переключились на Kanban | ||
| Инструменты контроля прогресса | |||
| Task Board, Iteration burn down, release burn down | Kanban Board, Cycle time | Kanban Board, Cycle time, Builds board | Kanban Board, Team Board, Cycle time, Builds board, roadmap на кухне |
| 2008 | 2009 | 2011 | 2012 |
| Ретроспективы | |||
| каждые 2 недели | Делаем собрания, когда это требуется, нет никаких периодов. Придумали Issue Board с лимитом в 3 проблемы. Как только накапливается 3 проблемы — делаем собрание и решаем их. Проблемы может писать кто угодно. | У нас stop-the-line собрания только с людьми, которых проблема касается. Происходит это не часто. | |
| Оценка работы | |||
| Planning poker. Оцениваем User Story в поинтах | А вообще не оцениваем работу | ||
| Учет потраченного времени | |||
| Четкий учет на всех задачах и багах. | Не ведем учет. Надоело. | ||
| 2008 | 2009 | 2011 | 2012 |
| Обсуждение требований | |||
| Собрание по планированию итерации | «Стартовое собрание» для User Story. Каждая User Story обсуждается перед ее началом. На собрании есть Product Owner + Тестировщик + Разработчики + Дизайнер. | ||
| WIP лимиты | |||
| Итерации | Лимит в 3 User Story. Больше в прогрессе работы быть не должно. | Забили на лимиты | 2 user stories на разработчика (рекомендована 1). Вообще мини-команда сама решает. |
| Планирование релизов | |||
| Формальное собрание. Обычно релиз длиться месяца 2 | Нет никакого планирования | Создаем высокоуровневый roadmap на следующие несколько месяцев. Пересматривается каждые 3 месяца. | |
| 2008 | 2009 | 2011 | 2012 |
| Дробление User Stories | |||
| User Story должна влезать в недельную итерацию | Пытаемся дробить, но как-то не очень получается | Все еще не очень... | Немного лучше, но по-прежнему сложная для нас практика |
| Definition of Done (DoD) для User Story | |||
| Спецификация актуальна Набор пройденных тест кейсов Юнит тесты |
Стартовое собрание Спецификация актуальна Набор пройденных тест кейсов Пользовательская документация Демо команде |
Стартовое собрание Спецификация актуальна Набор пройденных тест кейсов Набор автоматических кейсов Пользовательская документация Демо команде |
Стартовое собрание Спецификация актуальна Набор пройденных тест кейсов Набор автоматических кейсов Пользовательская документация Демо команде Зеленый билд Человеческие тексты Тесты производительности |
| 2008 | 2009 | 2011 | 2012 |
| Собрания | |||
| Планирование релиза (команда) Планирование итерации (команда) Демо итерации (команда) Ретроспектива (команда) Ежедневный (команда) |
Запуск User Story (3-4 человека) User Story демо (4+ человека) Ретроспектива (команда) Ежедневный |
Запуск User Story User Story демо Stop-the-line (команда) Ежедневный |
Запуск User Story User Story демо (до начала тестирования!) Stop-the-line (нужные люди) Ежедневный |
| Ежедневное собрание | |||
| Есть, в 10 утра, занимает около 10 минут | Есть, в 11 утра, занимает около 15 минут | ||
| UX | |||
| Что? | Wireframes | Скетчи (много идей и быстро), Живые прототипы, юзабилити тесты на живых людях, design studio | Скетчи, Живые прототипы, юзабилити тесты на рабочей системе |
| Craftsmanship | |||
| Что что? | Семинары | Зарплата зависит от обучения Мини-конференции Оплаченное посещение крутой конференции Семинары Пятничные шоу 5 часов на самообразование в неделю |
Зарплата зависит от обучения Мини-конференции Оплаченное посещение крутой конференции 5 часов на самообразование или на персональный проект в неделю |
Наблюдение
Итерации → 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, когда вся стратегия развития была полностью пересмотрена и изменена. Сейчас у нас тотальный дух знаний. Серьезно.
Вот как менялся фокус развития компании по годам:
Технические практики
| 2008 | 2009 | 2011 | 2012 |
| Source control и бранчи | |||
| Subversion. Один бранч. | Git. Каждая фича или баг-фикс делается в отдельном бранче. Мастер всегда готов к релизу. | Git. Возвратились к одному бранчу, чтобы двигаться к continuous delivery | |
| Парное программирование | |||
| Парное программирование строго обязательно. Разработчики меняют пару каждый день, чтобы посмотреть на проблему свежим взглядом, обменяться опытом и добиться реального коллективного владения кодом | Обязательно для всех User Stories и сложных багов. Иногда люди работают в одиночку над более простыми задачами. Смена пар отменена. Оказалось, что это мешает сосредоточиться и раздражает | Используется только для сложных задач | Полностью опционально. Мини-команда решает сама, как ей работать |
| TDD/BDD | |||
| TDD настоятельно рекомендуется. Юнит тесты строго обязательны для каждой user story | Весь новый код покрыт тестами. На стороне JavaScript ситуаци похуже. Также пытаемся использовать BDD | На стороне JavaScript тоже все хорошо, используем QUnit. BDD ширится и растет | Четкий фокус на BDD. Мы немного переделали NBehave под собственные нужны и сделали VS add-in для быстрого написания тестовых сценариев |
| Автоматические функциональные тесты | |||
| Несколько тестов на Selenium | Много тестов на Selenium. Мы сделали собственный фреймворк на C# чтобы писать и поддерживать тесты | Функциональные тесты запускаются параллельно на 20 виртуальных серверах | Мигрируем на Selenium WebDriver. Виртуальных серверов уже почти 40 |
| Continuous Integration | |||
| Очень простая. Компиллируется исходный код, запускаются юнит тесты в Cruise Control. | Используем Cruise Control с несколькими разными сетапами | Перешли на Jenkins | По-прежнему используем Jenkins. Новая цель — перейти на Continuous Delivery со временем. |
| Feature toggling | |||
| Нету | Мы используем feature toggling и двигаемся к continuous delivery. | ||
| Тестовое покрытие | |||
| черт его знает | 50% покрытие юнит тестами и 30% покрытие функциональными тестами | 70% покрытие юнит тестами и 40% покрытие функциональными | |
Наблюдения
Один бранч → Бранчи по фичам → Один бранч. Любопытная петля. Бранчи по фичам стали возможны после внедрения 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 году
В заключение
Вот к чему мы пришли за последние 4 года
P.S. Если кто-то знает, как заставить Хабр форматировать нормально таблицы — дайте знать.
