Когда проектов больше чем людей: процесс разработки в маленькой, но амбициозной

компанииГорник АлександрИсполнительный директор компании ITCD

О себе

• Александр Горник• www.itcd.ru, Исполнительный директор

• http://agornik.moikrug.ru/• agornik@gmail.com• Google for other things

История бизнеса

• Маленькая компания, почти веб студия• Требование быстрой самоокупаемости• Постоянная нехватка ресурсов• Множество быстрых, мелких проектов• Выход в определенный сегмент рынка

(промо), желание делать продукт• Клиенты – маркетологи, требования не ясны,

fixed cost контракты

Чего нам удалось достичь

• > 100 loc продукт• Ежедневные релизы• Одновременно силами 7ми разработчиков

– 5+ проектов с ежедневным (или чаще) релизом по необходимости– 5+ поддержка– 2-5 в разработке

• Запуск проекта за неделю• 2000-4000 транзакций в секунду, ~0,5 TB базы, 3+ M хитов в

месяц только на сайтах• Белая, самоокупаемая компания c двухзначным ежегодным

ростом оборота

Эволюция процесса разработки

• Внедрение SCRUM по результатам консалтинга ScrumTrek (2008) + joel on software

• Кризис (2008-2009)

• Оптимизация всего (2009-2010), естественная эволюция процесса

• Ретроспектива, ревью практик и новая итерация (2011)

Кто и как

Команда, менеджмент и общие практики

Текущие роли и коммуникации

Product Owner, Tester, Account

manager

Scrum master, deploy master,

team lead, technical manager

Technical manager, lead dev

Разработчики

Дизайнеры на аутсорсе

Клиенты

Html Верстка

Генеральный Исполнительный (технический)

Не начальник разработчика!

КомандаТеория Практика

• Кросс функциональные команды мотивированных самородков– Аналитика– Дизайн– Верстка– Разработка– Тест– Приемка и релиз

• Менеджер говорит по телефону – не может сидеть рядом

• Дизайн – на фрилансе• Верстка –отдельна и слабо

связана • Менеджер – он же тестер• Программист не хочет ничего

видеть кроме кодаКонечно, хочется стремиться к идеалу. Технический менеджер (он же аналитик) в одной комнате с разработчиками и выделенными тестерами. Но пока и так получилось неплохо.

Product owner / менеджерТеория Практика

• Клиент участвует в разработке как PO

• Клиент квалифицирован и держит руку на пульсе, т.к. заинтересован

• Клиент не участвует и ему все пофиг

• PO – менеджер внутри компании, но его мотивация слаба

• PO – не технарь• Менеджер = тестер

Менеджер – полностью ответственный за весь конечный результат. Без оговорок. Это нужно постоянно доносить до людей.

Нужен технический менеджер (а где их взять?), тестеры

Чек лист менеджера

• Нет в багтрекере = забыли и не сделали. «А я говорил(а) по телефону» - не считается.

• Задача = «что разработчик должен показать менеджеру». Не технические US.

• Оценка сроков - разработчик. Рули приоритетом и дедлайном

• Срочные задачи – зло, все что можно – отложи и вставь в план

• Все документы и требования – должны быть общедоступны, нет почте, телефону и локальным папкам

Топы – конфликтыТехнический Клиентский• Это сделать нельзя• Это невозможно успеть в срок• Не знаю, что делать c сначала• Не понимаю что нужно сделать• Не знаю как поставить задачу• Кто это должен делать?• Не знаю, как клиенту перевести

то, что сказал разработчик• Не понимаю разработчика

• Клиент недоволен, я не знаю как это исправить

• Несогласие с техническим директором

• Презентация косяков клиенту

• Договора, сметы и прочее• Паника !

Рабочие условия

• Аккаунты отдельно от программистов• Мощные компьютеры, SSD• Удобная мебель и достаточно места• 2 монитора у каждого• Работа без овертаймов• Здоровая атмосфера плавной работы без нервов

• Дополнительно: – Программистами руководит технарь– Индивидуальный график, и бесплатные сладости – Возможность расслабиться

Что и зачем

Процессные практики – теория, жизнь и светлое будущее

ИтерацииТеория Практика

• Гарантировать завершение работы

• Timebox фичей• Управлять набором задач в

разработке (firefighting)• Обозримые сроки, точность

оценки• Борьба с изменением

требований

• Суровые дедлайны (сроки и продакшен)

• Фиксированные требования (смена после старта)

• Мало поддержки• Разделить команды для

длительных и коротких задач

В результате: итерации отмерли вместе с внедрением багтрекера и отказа от доски (время!). Сейчас хочется вернуть ради выделенного, т.к. поддержки стало больше.

ДемонстрацииТеория Практика

• Повысить ответственность • Сплотить команду• Definition of Done• Получить фидбэк

• Ответственности – выше крыши

• Все пашут, это прозрачно (daily, bt, релиз, managers)

• Фидбэк только от клиента, менеджер дает его во время теста

Итого, от демонстраций отказались ради экономии времени. Пока желание вернуть не возникает, максимум – для команды с длительными задачами.

РетроспективыТеория Практика

• Повышать скорость разработки

• Повышать удовлетворенность людей

• Выявлять и решать проблемы

• Сплачивать команду

• Нулевая текучка• Притертая команда• Очень большая

производительность (по опыту)

Быстро сошли на нет, т.к. говорить не о чем. Сейчас рост команды, новые люди – хотелось бы вернуть, хотя бы разок в месяц (еще нежно просто говорить со всеми)

Дейли митингТеория На практике

• Выявить проблемы• Убедиться что все

работают• Поддержать темп• Обсудить срочные задачи

(лимитировать общение менеджера и разработчика)

• Оказался мегаполезным, без него никак

• Отнимает не больше 5-10ти минут

• Поддерживает дисциплину и тонус

ДА!

ПланированиеТеория Практика

• Оценка, планирование сроков

• Выяснение задач на итерацию

• Timebox, ориентиры производительности

• Итераций нет• Сроки оценивать все

равно нужно• Общие планирования с

покером – только на проекты (сайт/акция)

• Прежде чем начать работу – оценка (багтрекер)

Самое важное – сроки всегда оценивает разработчик, они не спускаются сверху. Планинг покеру – ДА!

СпецификацияТеория Практика

• Agile: no specs• Joel: no code without a spec• Wiki

• Не технические менеджеры• Спецификация нужна

клиенту = office + sharepoint • Спецификация нужна, чтобы

оценить риски и планировать загрузку

Минимальные спецификации (по joel) пишутся до планирования проекта в doc. Планирование проходит на их основе, дальше спецификации не поддерживаются, или поддерживаются минимально. CR -> tickets.

Хочется перейти на wiki (FB + Createrly + Balsamiq), уменьшить кол-во документов, приблизить их к кейсам, сделать, чтобы разработчики сами писали. Должен писать человек с техническим бэкграундом (хотя бы частично)

Метрики процессаТеория Практика

• Burndown• Velocity• Focus factor

• Timesheets• Working on• Work in progress

Новые люди = очень хочется начать мерить velocity и focus factor для измерения динамики процесса.

Еще хочется мерить количество поступающих незапланированных задач от менеджеров (как? тэг в багтрекере).

Отдельно о KanbanТеория Практика

• Оптимизация конвеера с кучей стадий

• Минимизация потерь передачи

• У нас конвейер сделать не так просто (аналитика далеко от разработки)

• Потери на передаче вроде не так страшны

• Затраты на визуализацию и поддержку

Хотелось бы измерить потери (как?). Возможное будущее - к примеру, для команды поддержки (если такая будет). Или, как вариант, внутри каждой итерации, если мы увидим что есть существенные потери времени на передаче

Резюмируя

Joel test – просто, но метко• Используете ли вы сорс контроль?• Можете ли сделать билд одним шагом?• Делаете ли ежедневные билды?• Есть ли у вас багтрекер?• Чините ли вы баги, прежде чем писать новый код?• Есть ли у вас актуальный график работ?• Есть ли у вас спецификация?• Работают ли программисты в тишине?• Используете ли вы лучшие доступные инструменты?• Есть ли у вас тестеры?• Пишут ли кандидаты код на интервью?• Проводите ли вы юзабилити тестирование в коридоре?

No silver bullet• Наш опыт – не догма, напротив, очень специфичен• Процесс должен быть изменчивым и обладать

мощной обратной связью– Но! Опасайтесь шрамов и бюрократии– Лучше всего процесс разрабатывать итерациями

• Не надо внедрять методологию – осознайте проблемы и решайте их (теория ограничений)– http://en.wikipedia.org/wiki/Theory_of_Constraints– Методология – просто способ затыкания дырок в

квалификации людей, если люди идеальные – все и так и будет работать в таких масштабах

Референсы• http://scrumtrek.ru/• http://www.joelonsoftware.com (и книги)• Экстремальное программирование, Kent

Beck• AgileDays и другие конференции

СПАСИБО!

И приходите к нам работать!

Мы ищем менеджера прекрасных продуктов и smart & gets things done разработчиков.

www.itcd.ru