Когда проектов больше чем людей - процесс разработки в маленькой, но амбициозной компании (SWP #11)

1,047 views

Published on

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

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,047
On SlideShare
0
From Embeds
0
Number of Embeds
100
Actions
Shares
0
Downloads
36
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Когда проектов больше чем людей - процесс разработки в маленькой, но амбициозной компании (SWP #11)

  1. 1. Когда проектов больше чем людей: процесс разработки в маленькой, но амбициозной компании<br />Горник Александр<br />Исполнительный директор компании ITCD<br />
  2. 2. О себе<br />Александр Горник<br />www.itcd.ru, Исполнительный директор<br />http://agornik.moikrug.ru/<br />agornik@gmail.com<br />Google for other things<br />
  3. 3. История бизнеса<br />Маленькая компания, почти веб студия<br />Требование быстрой самоокупаемости<br />Постоянная нехватка ресурсов<br />Множество быстрых, мелких проектов<br />Выход в определенный сегмент рынка (промо), желание делать продукт<br />Клиенты – маркетологи, требования не ясны, fixed cost контракты<br />
  4. 4. Чего нам удалось достичь<br />> 100 locпродукт<br />Ежедневные релизы<br />Одновременно силами 7ми разработчиков<br />5+ проектов с ежедневным (или чаще) релизом по необходимости<br />5+ поддержка<br />2-5 в разработке<br />Запуск проекта за неделю<br />2000-4000 транзакций в секунду, ~0,5 TB базы, 3+ M хитов в месяц только на сайтах<br />Белая, самоокупаемая компания c двухзначным ежегодным ростом оборота<br />
  5. 5. Эволюция процесса разработки<br />Внедрение SCRUM по результатам консалтинга ScrumTrek (2008) + joel on software<br />Кризис (2008-2009)<br />Оптимизация всего (2009-2010), естественная эволюция процесса<br />Ретроспектива, ревью практик и новая итерация (2011)<br />
  6. 6. Команда, менеджмент и общие практики<br />Кто и как<br />
  7. 7. Текущие роли и коммуникации<br />Генеральный<br />Исполнительный (технический)<br />Не начальник разработчика!<br />Scrum master, deploy master, team lead, technical manager<br />Дизайнеры на аутсорсе<br />Product Owner, Tester, Account manager<br />Technical manager, lead dev<br />Клиенты<br />Разработчики<br />Html Верстка<br />
  8. 8. Команда<br />Теория<br />Практика<br />Кросс функциональные команды мотивированных самородков<br />Аналитика<br />Дизайн<br />Верстка<br />Разработка<br />Тест<br />Приемка и релиз<br />Менеджер говорит по телефону – не может сидеть рядом<br />Дизайн – на фрилансе<br />Верстка –отдельна и слабо связана <br />Менеджер – он же тестер<br />Программист не хочет ничего видеть кроме кода<br />Конечно, хочется стремиться к идеалу. Технический менеджер (он же аналитик) в одной комнате с разработчиками и выделенными тестерами. Но пока и так получилось неплохо.<br />
  9. 9. Product owner / менеджер<br />Теория<br />Практика<br />Клиент участвует в разработке как PO<br />Клиент квалифицирован и держит руку на пульсе, т.к. заинтересован<br />Клиент не участвует и ему все пофиг<br />PO – менеджер внутри компании, но его мотивация слаба<br />PO – не технарь<br />Менеджер = тестер<br />Менеджер – полностью ответственный за весь конечный результат. Без оговорок. Это нужно постоянно доносить до людей.<br />Нужен технический менеджер (а где их взять?), тестеры<br />
  10. 10. Чек лист менеджера<br />Нет в багтрекере = забыли и не сделали. «А я говорил(а) по телефону» - не считается.<br />Задача =«что разработчик должен показать менеджеру». Не технические US.<br />Оценка сроков - разработчик. Рули приоритетом и дедлайном<br />Срочные задачи – зло, все что можно – отложи и вставь в план<br />Все документы и требования – должны быть общедоступны, нет почте, телефону и локальным папкам<br />
  11. 11. Топы – конфликты<br />Технический<br />Клиентский<br />Это сделать нельзя<br />Это невозможно успеть в срок<br />Не знаю, что делать c сначала<br />Не понимаю что нужно сделать<br />Не знаю как поставить задачу<br />Кто это должен делать?<br />Не знаю, как клиенту перевести то, что сказал разработчик<br />Не понимаю разработчика<br />Клиент недоволен, я не знаю как это исправить<br />Несогласие с техническим директором<br />Презентация косяков клиенту <br />Договора, сметы и прочее<br />Паника !<br />
  12. 12. Рабочие условия<br />Аккаунты отдельно от программистов<br />Мощные компьютеры, SSD<br />Удобная мебель и достаточно места<br />2 монитора у каждого<br />Работа без овертаймов<br />Здоровая атмосфера плавной работы без нервов<br />Дополнительно: <br />Программистами руководит технарь<br />Индивидуальный график, и бесплатные сладости <br />Возможность расслабиться<br />
  13. 13. Процессные практики – теория, жизнь и светлое будущее<br />Что и зачем<br />
  14. 14. Итерации<br />Теория<br />Практика<br />Гарантировать завершение работы<br />Timeboxфичей<br />Управлять набором задач в разработке (firefighting)<br />Обозримые сроки, точность оценки<br />Борьба с изменением требований<br />Суровые дедлайны(сроки и продакшен)<br />Фиксированные требования (смена после старта)<br />Мало поддержки<br />Разделить команды для длительных и коротких задач<br />В результате: итерации отмерли вместе с внедрением багтрекера и отказа от доски (время!). Сейчас хочется вернуть ради выделенного, т.к. поддержки стало больше.<br />
  15. 15. Демонстрации<br />Теория<br />Практика<br />Повысить ответственность <br />Сплотить команду<br />Definition of Done<br />Получить фидбэк<br />Ответственности– выше крыши<br />Все пашут, это прозрачно (daily, bt, релиз, managers)<br />Фидбэк только от клиента, менеджер дает его во время теста<br />Итого, от демонстраций отказались ради экономии времени. Пока желание вернуть не возникает, максимум – для команды с длительными задачами.<br />
  16. 16. Ретроспективы<br />Теория<br />Практика<br />Повышать скорость разработки<br />Повышать удовлетворенность людей<br />Выявлять и решать проблемы<br />Сплачивать команду<br />Нулевая текучка<br />Притертая команда<br />Очень большая производительность (по опыту)<br />Быстро сошли на нет, т.к. говорить не о чем. Сейчас рост команды, новые люди – хотелось бы вернуть, хотя бы разок в месяц (еще нежно просто говорить со всеми) <br />
  17. 17. Дейли митинг<br />Теория<br />На практике<br />Выявить проблемы<br />Убедиться что все работают<br />Поддержать темп<br />Обсудить срочные задачи (лимитировать общение менеджера и разработчика)<br />Оказался мегаполезным, без него никак<br />Отнимает не больше 5-10ти минут<br />Поддерживает дисциплину и тонус<br />ДА!<br />
  18. 18. Планирование<br />Теория<br />Практика<br />Оценка, планирование сроков<br />Выяснение задач на итерацию<br />Timebox, ориентиры производительности<br />Итераций нет<br />Сроки оценивать все равно нужно<br />Общие планирования с покером – только на проекты (сайт/акция)<br />Прежде чем начать работу – оценка (багтрекер)<br />Самое важное – сроки всегда оценивает разработчик, они не спускаются сверху. Планинг покеру – ДА!<br />
  19. 19. Спецификация<br />Теория<br />Практика<br />Agile: no specs<br />Joel: no code without a spec<br />Wiki <br />Не технические менеджеры<br />Спецификация нужна клиенту = office + sharepoint<br />Спецификация нужна, чтобы оценить риски и планировать загрузку<br />Минимальные спецификации (по joel) пишутся до планирования проектав doc. Планирование проходит на их основе, дальше спецификации не поддерживаются, или поддерживаются минимально. CR -> tickets.<br />Хочется перейти на wiki (FB + Createrly+ Balsamiq), уменьшить кол-во документов, приблизить их к кейсам, сделать, чтобы разработчики сами писали. Должен писать человек с техническим бэкграундом (хотя бы частично)<br />
  20. 20. Метрики процесса<br />Теория<br />Практика<br />Burndown<br />Velocity<br />Focus factor<br />Timesheets<br />Working on<br />Work in progress<br />Новые люди = очень хочется начать мерить velocity и focus factor для измерения динамики процесса.<br />Еще хочется мерить количество поступающих незапланированных задач от менеджеров (как? тэг в багтрекере).<br />
  21. 21. Отдельно о Kanban<br />Теория<br />Практика<br />Оптимизация конвеера с кучей стадий<br />Минимизация потерь передачи<br />У нас конвейер сделать не так просто (аналитика далеко от разработки)<br />Потери на передаче вроде не так страшны<br />Затраты на визуализацию и поддержку<br />Хотелось бы измерить потери (как?). Возможное будущее - к примеру, для команды поддержки (если такая будет). Или, как вариант, внутри каждой итерации, если мы увидим что есть существенные потери времени на передаче<br />
  22. 22. Резюмируя<br />
  23. 23. Joel test – просто,но метко<br />Используете ли вы сорс контроль?<br />Можете ли сделать билд одним шагом?<br />Делаете ли ежедневные билды?<br />Есть ли у вас багтрекер?<br />Чините ли вы баги, прежде чем писать новый код?<br />Есть ли у вас актуальный график работ?<br />Есть ли у вас спецификация?<br />Работают ли программисты в тишине?<br />Используете ли вы лучшие доступные инструменты?<br />Есть ли у вас тестеры?<br />Пишут ли кандидаты код на интервью?<br />Проводите ли вы юзабилити тестирование в коридоре?<br />
  24. 24. No silver bullet<br />Наш опыт – не догма, напротив, очень специфичен<br />Процесс должен быть изменчивым и обладать мощной обратной связью<br />Но! Опасайтесь шрамов и бюрократии<br />Лучше всего процесс разрабатывать итерациями<br />Не надо внедрять методологию – осознайте проблемы и решайте их (теория ограничений)<br />http://en.wikipedia.org/wiki/Theory_of_Constraints<br />Методология – просто способ затыкания дырок в квалификации людей, если люди идеальные – все и так и будет работать в таких масштабах<br />
  25. 25. Референсы<br />http://scrumtrek.ru/<br />http://www.joelonsoftware.com (и книги)<br />Экстремальное программирование, Kent Beck<br />AgileDaysи другие конференции<br />
  26. 26. СПАСИБО!<br />И приходите к нам работать! <br />Мы ищем менеджера прекрасных продуктов и smart & gets things done разработчиков.<br />www.itcd.ru<br />

×