Креативный менеджмент глазами разработчика:

Как выжить в "agile" проекте

Виталий Шибаев

Компания ИСС Арт

Разработчик в 1-м поколении. Верю в TDD и рефакторинг.

Зачем этот доклад?

Будут:+ Решения фундаментальных проблем разработки+ Примеры из реальной работы большой команды (25-30 человек)

Не будет:- Теоретических выкладок- Низкоуровневых технических деталей

Context context = me.DescribeContext();Debug.Assert(context.ProblemCount == 4);

for (int i = 0; i < context.ProblemCount; ++i){ if (i == 2) me.ShowVideo();

Problem problem = context.Problems[i]; me.Analyze(problem);}me.Summarize();

Структура доклада

Обзор проекта

Продолжительность 4+ года (c мая 2008)

Технологии Java, JS, Groovy, Flex, C#, C++, PHP, ...

Средний размер команды

20-25 разработчиков

Всего работало 75 человек

Инструменты Git, JIRA, Bamboo, Review Board

Архитектура

Render Server (C#)

.NET CFBlackBerryC++Frontend (ExtJS)

Backend (Java)

Жили-были...

● Заказная разработка● Небольшие проекты● Микро-команды - 2-4 человека

Заказчик

● Крупный заказчик● Масштабный проект● Множество идей

И понеслось...

● Неопытный менеджер● Резкий рост команды (8+ разработчиков)● Много разноплановых задач● Эйфория от работы над новым кодом

Разные члены команды пишут много кода в разных частях системы без должных проектирования и синхронизации.

В результате:● Сырой код;

● Проблемы при интеграции;

● Люди знают только свой код;

Проблема 1: После релиза обнаруживаются критичные баги

Почему?● Мало времени на написание кода● Невнимательно тестировали код● Низкий уровень знания разработчиков● Не учли реальные условия

Как не допустить?

Тестировать продукт перед релизом

Идея:Нельзя релизить непротестированный продукт.

Как:Перед релизом тестируем продукт, фиксим обнаруженные баги.

Пример 1: Продукт тестируют все разработчики

+ Можно оперативно пофиксить проблему;+ Хорошо знают систему, при должной внимательности могут найти много всего.

- Не замечают ошибок в собственном коде;- Лень фиксить, проще забить;- Разработчики не любят тестирование и тестируют поверхностно;- Можно увлечься локальным фиксом и забыть про остальное;

Пример 2: Продукт тестирует аккуратный разработчик

+ Другие разработчики не отвлекаются на тестирование - только фиксят;+ Хорошо знает систему, при должной внимательности может найти много всего;+ “Это не баг, а фича” - не пройдет.

- Тестирование быстро надоедает, особенно регрессионное;- Тяжело найти такого разработчика.

Пример 3: Продукт тестируют тестировщики

+ Не дергаем разработчиков;+ Полная объективность;+ Профессионально занимаются этим;+ Взгляд со стороны на систему.

- Ниже уровень технических знаний;- Разработчики отрицают баги - “так и должно быть”;- Первое время часто репортят ерунду.

Проект сейчас

Команда из 7 тестировщиков в ОмскеРелизная ветка фиксируется за 2 недели2 раунда регрессионного тестированияSanity тестирование сразу после релиза50 тестовых серверовТестовые скрипты в TestLink

РезюмеПосле релиза обнаруживаются критичные баги

Тестировщики - лакмусовая бумажка качества разработки.

Иногда привлекайте разработчиков к тестированию.

Разработчики должны помогать тестировщикам.

Проблема 2: После релиза ломается старый функционал

Почему?● Невнимательно тестировали свой код● Низкий уровень знаний разработчиков

(код, система, язык)● Невозможно все учесть

Как не допустить?

Автоматические тесты

Идея:Покрывать код автоматическими тестами. Перед релизом все тесты должны проходить.

Как:Пишем модульные и интеграционные тесты для новых фич и багов.

Пример 1: Выделенный разработчик пишет интеграционные тесты после

завершения задачи

+ Другие разработчики не отвлекаются на написание тестов;+ Взгляд на код со стороны;

- Не успевает за остальными;- Тесты поверхностные - подгоняются под функционал, а не наоборот;- Если обнаруживаются проблемы - исправление затягивается.

Пример 2: Java - все разработчики пишут интеграционные тесты

+ Позволило проекту дожить до сегодняшнего дня

- Много интеграционных тестов - проходят долго;

Пример 3: Render Server - покрытие большой базы существующего кода

Проект:● зависит от многих сторонних компонентов● многопоточный и многопроцессный● требует тонких настроек окружения

Тесты:+ Уверенность в отсутствии регрессий+ Упростили отладку

Пример 4: Тесты для фронтенда (ExtJS)

+ Защищают от регрессий

- Сложно писать- Сложно обеспечить глубокое покрытие- Могут замедлять работу продакшн кода- Очень чувствительны к окружению

Пример 5: Тесты проходят долго

Интеграционные тесты:● работают долго● зависят от окружения

Сервер для автоматических тестов (Bamboo):+ Продолжаем разработку пока тесты идут- Дополнительный сервис- Узкое место - нужен всей команде

Проект сейчас

Java 4 плана Bamboo 2175 тестов

Flex 1 план Bamboo 1048 тестов

C++ 3 плана Bamboo 290 тестов

C# 2 плана Bamboo 109 тестов

JS 2 плана Bamboo 60 тестов

Java Doc 1 план Bamboo 1 тест

РезюмеПосле релиза ломается старый функционал

Тесты - ваш проводник в светлое будущее.

Тесты должны писать разработчики.

Интеграционные тесты будут работать долго.

Покройте UI базовым набором тестов.

ВИДЕО

Проблема 3: Не можем выкатить релиз - код в репозитории нестабилен

Почему?● Код не тестируется перед попаданием в

публичный доступ● Тесты занимают много времени● Нельзя коммитить локально

Как не допустить?

Continuous integration

Идея:Любые изменения в коде должны тестироваться. Непротестированному коду запрещено попадать в публичный доступ.

Как:В основной ветке - только стабильный код.Код стабилен, если проходят все тесты и тестировщики не нашли багов.

Пример 1: Тесты перед каждым коммитом в SVN

- Коммиты становятся “жирными” и долгими- Тестировщики не участвуют в проверке кода

Пример 2: Каждая задача в отдельной ветке. С SVN на Git.

+ Легкая работа с ветками+ Проще рулить конфликты+ Возможность коммитить локально

- Мигрировать всю историю- Другая идеология - людей надо учить- Неудобный клиент под Windows

Пример 3: Жесткий workflow

Ограничения:● Мержить в master может только JIRA.

Jira2Bamboo plugin.● Мерж возможен только когда пройдут все

тесты и нет конфликтов.

+ Проблема решается железобетонно- merge plugin не стабилен- мержить может только один человек - надо ждать, когда освободится

Пример 4: Эволюция merge plugin

Улучшения:● Баг фиксы● Поддержка очереди с приоритетом● E-mail уведомления

+ Отправил в мерж и гуляй+ Приоритетные задачи мержатся раньше+ Задачи, где мало тестов, мержатся раньше

Пример 5: Единый QA сервер -> N тестовых серверов

Сделано:● JIRA plugin для резервирования сервера● Скрипт для автоматического билда

заданной ветки на сервере

Проект сейчас

До мержа обязательный прогон тестов и полное ручное тестирование.

Обязательное обучение людей работе с Git и workflow.

Jira2Bamboo плагин с поддержкой очереди.

Оптимизация работы с Bamboo - не гонять тесты лишний раз.

РезюмеНе можем выкатить релиз - код в репозитории нестабилен

В большом проекте создайте "островок" стабильного кода.

Используйте DVCS для большой команды

Обучайте людей workflow и работе с DVCS.

Сделайте коммиты, билды, запуск тестов простыми и быстрыми операциями.

Проблема 4: Нужно править незнакомый код

Почему?● Автор кода недоступен

Следствия:● Тратится много времени на понимание кода● Вероятность ошибок возрастает

Как не допустить?

Совместное владение кодом

Идея:Любой участок кода должно знать минимум 2 разработчика.

Как:Писать код в парах.Обязательное ревью кода

Пример 1: Парное программирование обязательно

+ Качественней код+ Непрерывная разработка - не нужны перерывы+ Люди учатся друг у друга

- Все равно получается медленней- Надоедает- Могут отвлекать других болтовней- Гибкий график может быть проблемой

Пример 2: Парное программирование только для серьезных проблем

+ Взгляд со стороны на проблему+ Максимально качественное решение+ Не успевает наскучить

Пример 3: Неопытные разработчики работают в парах

+ Минимизируем негативный эффект в первое время+ Вдвоем проще осваивать незнакомую систему

Пример 4: Позадачное code review

+ Любой код знает минимум еще 1 человек+ Левый код отсеивается сразу+ Меньше затрат, чем при работе в парах

- Опытный разработчик может скептически относиться к замечаниям- Затягивает процесс завершения задачи- Разработчики ленятся ревьювить чужой код

Пример 5: Review Board

Проект сейчас

Обязательное ревью перед тестированием.

Review Board, нет интеграции с JIRA.

Новые разработчики начинают ревьювить код через 1-2 месяца.

Парное программирование только при необходимости.

РезюмеНужно править незнакомый код

Используйте Code Review непрерывно.

Сделайте процесс Code Review удобным.

Применяйте парное программирование только в сложных случаях.

Итоги

Непродуманные решения превратятся в серьезные проблемы в будущем.

В большой команде проблемы будут происходить постоянно.

Решайте проблемы фундаментально, чтобы избежать повторного появления вовсе.

Готовьте команду к изменениям.

Итоги

На большом проекте с самого начала:● Пишите тесты● Наймите тестировщиков● Используйте DVCS● Следуйте принципам Continuous

Integration● Внедрите обязательное Code Review

Спасибо за внимание!

Виталий Шибаев

vshibaev@issart.comSkype: shibvit

Компания ИСС Артhttp://issart.com/

Для создания видео:Gource (+ ffmpeg)

http://code.google.com/p/gource/