презентация к моему докладу на SWP11 про наш процесс разработки

1. Когда проектов больше чем людей: процесс разработки в маленькой, но амбициозной компании Горник Александр Исполнительный директор компании ITCD

2. О себе Александр Горник www.itcd.ru, Исполнительный директор http://agornik.moikrug.ru/ agornik@gmail.com Google for other things

3. История бизнеса Маленькая компания, почти веб студия Требование быстрой самоокупаемости Постоянная нехватка ресурсов Множество быстрых, мелких проектов Выход в определенный сегмент рынка (промо), желание делать продукт Клиенты – маркетологи, требования не ясны, fixed cost контракты

4. Чего нам удалось достичь > 100 locпродукт Ежедневные релизы Одновременно силами 7ми разработчиков 5+ проектов с ежедневным (или чаще) релизом по необходимости 5+ поддержка 2-5 в разработке Запуск проекта за неделю 2000-4000 транзакций в секунду, ~0,5 TB базы, 3+ M хитов в месяц только на сайтах Белая, самоокупаемая компания c двухзначным ежегодным ростом оборота

5. Эволюция процесса разработки Внедрение SCRUM по результатам консалтинга ScrumTrek (2008) + joel on software Кризис (2008-2009) Оптимизация всего (2009-2010), естественная эволюция процесса Ретроспектива, ревью практик и новая итерация (2011)

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

7. Текущие роли и коммуникации Генеральный Исполнительный (технический) Не начальник разработчика! Scrum master, deploy master, team lead, technical manager Дизайнеры на аутсорсе Product Owner, Tester, Account manager Technical manager, lead dev Клиенты Разработчики Html Верстка

8. Команда Теория Практика Кросс функциональные команды мотивированных самородков Аналитика Дизайн Верстка Разработка Тест Приемка и релиз Менеджер говорит по телефону – не может сидеть рядом Дизайн – на фрилансе Верстка –отдельна и слабо связана Менеджер – он же тестер Программист не хочет ничего видеть кроме кода Конечно, хочется стремиться к идеалу. Технический менеджер (он же аналитик) в одной комнате с разработчиками и выделенными тестерами. Но пока и так получилось неплохо.

9. Product owner / менеджер Теория Практика Клиент участвует в разработке как PO Клиент квалифицирован и держит руку на пульсе, т.к. заинтересован Клиент не участвует и ему все пофиг PO – менеджер внутри компании, но его мотивация слаба PO – не технарь Менеджер = тестер Менеджер – полностью ответственный за весь конечный результат. Без оговорок. Это нужно постоянно доносить до людей. Нужен технический менеджер (а где их взять?), тестеры

10. Чек лист менеджера Нет в багтрекере = забыли и не сделали. «А я говорил(а) по телефону» - не считается. Задача =«что разработчик должен показать менеджеру». Не технические US. Оценка сроков - разработчик. Рули приоритетом и дедлайном Срочные задачи – зло, все что можно – отложи и вставь в план Все документы и требования – должны быть общедоступны, нет почте, телефону и локальным папкам

11. Топы – конфликты Технический Клиентский Это сделать нельзя Это невозможно успеть в срок Не знаю, что делать c сначала Не понимаю что нужно сделать Не знаю как поставить задачу Кто это должен делать? Не знаю, как клиенту перевести то, что сказал разработчик Не понимаю разработчика Клиент недоволен, я не знаю как это исправить Несогласие с техническим директором Презентация косяков клиенту Договора, сметы и прочее Паника !

12. Рабочие условия Аккаунты отдельно от программистов Мощные компьютеры, SSD Удобная мебель и достаточно места 2 монитора у каждого Работа без овертаймов Здоровая атмосфера плавной работы без нервов Дополнительно: Программистами руководит технарь Индивидуальный график, и бесплатные сладости  Возможность расслабиться

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

14. Итерации Теория Практика Гарантировать завершение работы Timeboxфичей Управлять набором задач в разработке (firefighting) Обозримые сроки, точность оценки Борьба с изменением требований Суровые дедлайны(сроки и продакшен) Фиксированные требования (смена после старта) Мало поддержки Разделить команды для длительных и коротких задач В результате: итерации отмерли вместе с внедрением багтрекера и отказа от доски (время!). Сейчас хочется вернуть ради выделенного, т.к. поддержки стало больше.

15. Демонстрации Теория Практика Повысить ответственность Сплотить команду Definition of Done Получить фидбэк Ответственности– выше крыши Все пашут, это прозрачно (daily, bt, релиз, managers) Фидбэк только от клиента, менеджер дает его во время теста Итого, от демонстраций отказались ради экономии времени. Пока желание вернуть не возникает, максимум – для команды с длительными задачами.

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

17. Дейли митинг Теория На практике Выявить проблемы Убедиться что все работают Поддержать темп Обсудить срочные задачи (лимитировать общение менеджера и разработчика) Оказался мегаполезным, без него никак Отнимает не больше 5-10ти минут Поддерживает дисциплину и тонус ДА!

18. Планирование Теория Практика Оценка, планирование сроков Выяснение задач на итерацию Timebox, ориентиры производительности Итераций нет Сроки оценивать все равно нужно Общие планирования с покером – только на проекты (сайт/акция) Прежде чем начать работу – оценка (багтрекер) Самое важное – сроки всегда оценивает разработчик, они не спускаются сверху. Планинг покеру – ДА!

19. Спецификация Теория Практика Agile: no specs Joel: no code without a spec Wiki Не технические менеджеры Спецификация нужна клиенту = office + sharepoint Спецификация нужна, чтобы оценить риски и планировать загрузку Минимальные спецификации (по joel) пишутся до планирования проектав doc. Планирование проходит на их основе, дальше спецификации не поддерживаются, или поддерживаются минимально. CR -> tickets. Хочется перейти на wiki (FB + Createrly+ Balsamiq), уменьшить кол-во документов, приблизить их к кейсам, сделать, чтобы разработчики сами писали. Должен писать человек с техническим бэкграундом (хотя бы частично)

20. Метрики процесса Теория Практика Burndown Velocity Focus factor Timesheets Working on Work in progress Новые люди = очень хочется начать мерить velocity и focus factor для измерения динамики процесса. Еще хочется мерить количество поступающих незапланированных задач от менеджеров (как? тэг в багтрекере).

21. Отдельно о Kanban Теория Практика Оптимизация конвеера с кучей стадий Минимизация потерь передачи У нас конвейер сделать не так просто (аналитика далеко от разработки) Потери на передаче вроде не так страшны Затраты на визуализацию и поддержку Хотелось бы измерить потери (как?). Возможное будущее - к примеру, для команды поддержки (если такая будет). Или, как вариант, внутри каждой итерации, если мы увидим что есть существенные потери времени на передаче

22. Резюмируя

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

24. No silver bullet Наш опыт – не догма, напротив, очень специфичен Процесс должен быть изменчивым и обладать мощной обратной связью Но! Опасайтесь шрамов и бюрократии Лучше всего процесс разрабатывать итерациями Не надо внедрять методологию – осознайте проблемы и решайте их (теория ограничений) http://en.wikipedia.org/wiki/Theory_of_Constraints Методология – просто способ затыкания дырок в квалификации людей, если люди идеальные – все и так и будет работать в таких масштабах

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

26. СПАСИБО! И приходите к нам работать!  Мы ищем менеджера прекрасных продуктов и smart & gets things done разработчиков. www.itcd.ru