'

Планирование веб-релизов в условиях многопоточности задач со скачущими приоритетами

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

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


Слайд 18

Результаты


Слайд 19

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


Слайд 20

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


×

HTML:





Ссылка: