Немного не понял про неувязки. Возможно не развернуто написал.
В этом блоке имелось ввиду, что если поступающая таска (а это собранные требования от заказчика) содержит не четкие требования (т.е. не до конца проработана бизнес-логика), то такая таска в работу не берется.
Рефактироинг очень важный и нужный этап. К сожалению в заказной разработке на проектах до него редко добираются. Обычно процесс рефактироинга запускаем на этапе передачи на сопровождение.
А хранятся ли где-то эти знания кроме как в устном фольклоре (эдакий сломанный телефон с задержкой по времени).
Это практика управления изменениями. Вся актуальная информация по реализованной функциональность должна хранить в технических проектах. Разработчики при внесении изменений в код предварительно актуализируют техпроекты. Новичок берет техпроект и изучает.
Можете рассказать как это организовано?
Плановое обучение команды, разбор частых вопросов.
Общий чат по проблемам. Если у разработчика есть вопрос, то он может его написать только в общий чат, прямой вопрос тимлиду или другим разработчикам в "личку" запрещается.
Также нужно отметить важность регрессионного тестирования, вы указали, что тестируете доработки, а остальной функционал?
Регрессивное тестирование производится на препродуктивном стенде. Специально обученные консультанты проводят тестирование по чек-листу. Мечтаем про автотесты ) но пока не удается включить в смету...
>> Парное программирование.
>> Влечет за собой умножение трудоемкости, и, как следствие, стоимости, на 2. Как к этому относятся заказчики? В нашем случае считаем внутренними издержками, на заказчика не выносится. В последние месяце парное программирование уже потеряло актуальность. Уже достаточно помогло в обучении разработчиков на практике.
Дмитрий, спасибо за информацию из Вашей практики, очень ценно!
Пока данный поход работает, если работать перестанет, то будем искать другие варианты.
Опять же отмечу, что это показатель тимлида. На разработчиков этот показатель не выносится.
Да, показатель следующий
количество закрытых тикетов техдолга < 2 — плохо (0 баллов)
количество закрытых тикетов техдолга >= 2 но < 4 — хорошо (1 балл)
количество закрытых тикетов техдолга >= 4 — отлично (2 балла)
Спасибо за вопрос! Да, такую ситуацию также ожидали, поэтому сделали ряд действий:
1. выделен сотрудник, который «разгребает» техдолг, т.е. это его приоритетная задача.
2. «разгребание» техдолга вынесли в отдельный показатель тимлида :).
Немного не понял про неувязки. Возможно не развернуто написал.
В этом блоке имелось ввиду, что если поступающая таска (а это собранные требования от заказчика) содержит не четкие требования (т.е. не до конца проработана бизнес-логика), то такая таска в работу не берется.
Рефактироинг очень важный и нужный этап. К сожалению в заказной разработке на проектах до него редко добираются. Обычно процесс рефактироинга запускаем на этапе передачи на сопровождение.
Это практика управления изменениями. Вся актуальная информация по реализованной функциональность должна хранить в технических проектах. Разработчики при внесении изменений в код предварительно актуализируют техпроекты. Новичок берет техпроект и изучает.
Плановое обучение команды, разбор частых вопросов.
Общий чат по проблемам. Если у разработчика есть вопрос, то он может его написать только в общий чат, прямой вопрос тимлиду или другим разработчикам в "личку" запрещается.
Регрессивное тестирование производится на препродуктивном стенде. Специально обученные консультанты проводят тестирование по чек-листу. Мечтаем про автотесты ) но пока не удается включить в смету...
>> Парное программирование.
>> Влечет за собой умножение трудоемкости, и, как следствие, стоимости, на 2. Как к этому относятся заказчики?
В нашем случае считаем внутренними издержками, на заказчика не выносится. В последние месяце парное программирование уже потеряло актуальность. Уже достаточно помогло в обучении разработчиков на практике.
Дмитрий, спасибо за информацию из Вашей практики, очень ценно!
Да, такая опасность есть. Поскольку метрика только для тимлида, то ему нет смысла ей манипулировать. Но опасность всегда есть, согласен.
1 тимлид
1 РП
5 консультантов
Вся команда: 12 сотрудников
Опять же отмечу, что это показатель тимлида. На разработчиков этот показатель не выносится.
количество закрытых тикетов техдолга < 2 — плохо (0 баллов)
количество закрытых тикетов техдолга >= 2 но < 4 — хорошо (1 балл)
количество закрытых тикетов техдолга >= 4 — отлично (2 балла)
1. выделен сотрудник, который «разгребает» техдолг, т.е. это его приоритетная задача.
2. «разгребание» техдолга вынесли в отдельный показатель тимлида :).
Мы в итоге отказались от диаграммы сгорания, ввели ряд показателей (метрик) и на них ориентируемся.