Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agile проекте | HappyDev'12

Креативный менеджмент
глазами разработчика:
Как выжить в "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#) Backend
(Java)

Frontend C++ BlackBerry .NET CF
(ExtJS)

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

● Заказная разработка
● Небольшие проекты
● Микро-команды - 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 человек
+ Левый код отсеивается сразу
+ Меньше затрат, чем при работе в парах

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


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

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

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

vshibaev@issart.com
Skype: shibvit

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

Для создания видео:
Gource (+ ffmpeg)
http://code.google.com/p/gource/

Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agile проекте | HappyDev'12

More Related Content

What's hot (19)

Viewers also liked (18)

Similar to Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agile проекте | HappyDev'12 (20)

More from HappyDev (20)

Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agile проекте | HappyDev'12