Планирование веб-релизов в условиях многопоточности задач со скачущими приоритетами Евгения Фирсова, Яндекс.Деньги. - презентация

1 Планирование веб-релизов в условиях многопоточности задач со скачущими приоритетами Евгения Фирсова, Яндекс.Деньги

2 Манифест Мы пытаемся: Радовать пользователей – запусками крупных проектов на фоне стабильного потока мелких улучшений; Выполнять требуемое заказчиками – делать то, что просят, и тогда, когда просят. Мы стараемся: трезво оценивать свои возможности; не давать ложных обещаний; работать наиболее оптимальным и удобным нам способом.

3 Входящий поток – количественные оценки Пример: 46 релизов / 177 задач за квартал – много? + проекты + «мелочи» – багофикс сколько успеваем за 91 день?

4 Входящий поток – количественные оценки Пример: 46 релизов / 177 задач за квартал – много? + проекты + «мелочи» – багофикс сколько успеваем за 65 дней?

5 Входящий поток – количественные оценки Пример: 46 релизов / 177 задач за квартал – много? + проекты + «мелочи» – багофикс сколько успеваем за 36 дней?

6 Изменения во входящем потоке Изменения требований: фиксируем; оцениваем сложность и примерные трудозатраты – «может, на второй этап?» Изменения внешних приоритетов: фиксируем; информируем о конфликтующих задачах, каскадно меняем внутренние приоритеты; информируем о возможных нарушениях в нормальном процессе выкладок.

7 Как это работает

8 Требования к людям Тимлид: держит в голове (почти) весь код; помнит про все текущие задачи, сравнивает их с планами на будущее; мгновенно начинает реагировать на изменяющуюся ситуацию. Разработчик: умеет быстро переключаться между задачами; понимает чужой код; не стесняется задавать вопросы и просить о помощи.

9 Входящий поток – качественные оценки Первичная оценка каждой задачи: полнота постановки (неполная не берём); непротиворечивость с другими задачами; приоритет по сравнению с имеющимися/ожидаемыми задачами; deadlineы; наличие (оптимального) ресурса разработки; зависимость от других команд/компонент; возможность и тип необходимого тестирования; наличие «окна» для выкладки; варианты реализации; примерные трудозатраты.

10 Входящий поток – качественные оценки Первичная «неофициальная» оценка каждой задачи: вероятность отмены задачи; вероятность значительного изменения требований; внутренняя потребность в результате; зависимости от текущего/планируемого рефакторинга; вероятность ошибки в реализации/тестировании; допустимость отката выкладки.

11 Пакеты и релизы Параллельные разработка и тестирование – «пакеты задач». Последовательное обновление production – релиз. Кодирование в названии: код «пакета» – ответ на вопрос «что?» номер релиза – ответ на вопрос «когда?»

12 Разработка – пакеты в CVS

13

14 Узкие места Потенциально проблемные моменты: логические ошибки при актуализации веток; повторное ручное тестирование; долгий рефакторинг; «реанимация» веток.

15 Базовые принципы Условия работы конвейера: не «мариновать» собранные пакеты; при планировании компенсировать неравномерность выходного потока (календаря выкладок) ; оставлять время на исправление ошибок; знать о ещё непоставленных задачах; соотносить свой темп с командой тестеров.

16 Когда начинать заканчивать разработку Откладываем начало работ, если: пакет не может сразу уйти в тестирование; после выкладки другого релиза заведомо предстоит переделка; параллельно идёт долгий рефакторинг; выгоднее тестировать вместе с задачами, постановка которых ещё не готова; известно, что разработку придётся прервать ради других задач. Не откладываем: хотфиксы; «дешёвые» мелочи по упрощённой схеме тестирования.

17 Взаимодействие с тестерами Помогаем друг другу: постоянно держим тестеров в курсе наших планов; совместно оцениваем длительность тестирования: – знаем, когда текущий пакет будет готов к выкладке; – знаем, сколько времени надо отводить на тестирование аналогичного пакета; – знаем среднее время проведения автотестов; «виртуально» планируем ресурсы тестеров: – знаем о специализации каждого тестера; – знаем примерную скорость работы каждого тестера.

18 Взаимодействие с эксплуатацией Помогаем друг другу: по возможности заранее сообщаем о планируемых релизах; планируем совместные действия на случай экстренных релизов; интересуемся планами и загруженностью админов.

19 Результаты

20 Пытаемся планировать В рамках квартала – считаем будущие задачи по головам; В рамках месяца: – гарантируем работу над задачей (до момента каскадной смены приоритетов); – совместно с тестерами расписываем опорные точки поэтапного тестирования (считая, что баги правятся без задержки тестирования). В рамках недели: – «выкладываем завтра».

21 Критерии оценки Время подготовки релиза: от 5 минут; Минимальный временной диапазон между двумя последовательными релизами: 10 минут; Оценки входящей задачи: от 5 минут до трёх часов.