Comments 21
Из моего опыта - оптимальные способы планирования и контроля сроков по задачам сильно зависят от того, является ли заказчик внутренним (т.е., разработчики - это подразделение в той же организации, что и заказчики) или внешним (сторонняя организация, для которой разрабытывается софт, который потом не будет значительно и постоянно меняться). В первом случае burn-down-chart как мне кажется, почти никогда и не должен опускаться до нуля, если брать весь массив задач целиком. Поэтому, мы немного доработали подход:
1) определили milestone - крайний срок, когда нужно запустить проект.
2) поделили задачи по приоритету - "до запуска", "после запуска" и "когда-нибудь потом". И burn-down-chart строили только по задачам "до запуска".
3) использовали модифицированный burn-down-chart, где каждый столбец состоял из двух частей стеком друг над другом - нижней, сколько осталось задач сделать и верхней, сколько задач уже сделано. Таким образом, "срединная" линия между частями была классическим burn-down, а верхняя - отражала общее количество. Эффект от этого - чисто психологический, не так грустно смотреть на график и показать почему мы не укладываемся в планы - потому что вон сколько задач сделали, а вон еще сколько накидали.
4) по мере необходимости пересматривали приоритеты, чтобы уложиться в срок к запуску.
5) после запуска доводили до подразделений-заказчиков длительности исполнения по запланированным задачам и максимальное суммарное время на двухнедельный спринт. И подразделения-заказчики между собой решали, какие задачи можно выкинуть, чтобы уложиться в лимит. Этот лимит был заложен меньше суммы рабочего времени всех разработчиков, таким образом, оставили время на тех.долг и экстренные исправления по критическим ошибкам, пробравшимся мимо тестировщиков. Самое сложное тут было убедить заказчика, что лимит должен быть меньше суммы рабочего времени разработчиков - что это вовсе не от лени.
Спасибо за статью!
Ввели отдельную колонку в Trello “Техдолг”
Не боитесь того, что вы просто переложили бардак в отдельную папочку (замели грязь под ковер), и когда это всплывёт - разгрести уже не удастся?
1. выделен сотрудник, который «разгребает» техдолг, т.е. это его приоритетная задача.
2. «разгребание» техдолга вынесли в отдельный показатель тимлида :).
«разгребание» техдолга вынесли в отдельный показатель тимлида
т.е. это что-то вроде количества закрытых тикетов из соответствующей колонки?
количество закрытых тикетов техдолга < 2 — плохо (0 баллов)
количество закрытых тикетов техдолга >= 2 но < 4 — хорошо (1 балл)
количество закрытых тикетов техдолга >= 4 — отлично (2 балла)
Получается странная ситуация: чтобы не разгребать техдолг, и не получать плохих показателей, разработчикам нужно его не записывать :)
Пока всё держится на честном слове, окей, но вам не кажется , что когда-нибудь это выстрелит?
Создавать знания и обмениваться ими
А хранятся ли где-то эти знания кроме как в устном фольклоре (эдакий сломанный телефон с задержкой по времени). Если придёт новичок в команду — откуда ему почерпнуть знаний? Тем более если проект большой — каждый новый разработчик будет много временить тратить на понимание всех «особенностей», которые успели наворотить его новые коллеги.
У себя в качестве попытки решения данной проблемы поднял форум (банальный phpBB прикрученный к AD), чтобы можно было знаниями делиться, но… народ активности не проявляет, и как заставить — вообще непонятно.
Занимается развитием разработчиков и расширением их компетенций.
Можете рассказать как это организовано?
Любые дефекты, несоответствия полученной функциональности требованиям появляются, когда код не проходит достаточную проверку качества.
Дело-то наверное не совсем в коде. Код может быть написан отвратительно (с точки зрения, скажем, стандартов оформления), но тем не менее решать поставленную задачу (пусть не оптимально, но решать). А вот вносить в него изменения — то еще приключение. И наоборот — всё красиво, по region`ам разделено, а баги есть. Дело-то больше в тестировании, которое позволяет убедиться работает код или нет. А еще дело может быть в подходе к тестированию, когда тест не учитывает всех вариантов, а только «сделали как написано в инструкции». Также нужно отметить важность регрессионного тестирования, вы указали, что тестируете доработки, а остальной функционал? CI как-нибудь организовывается?
Буквально недавно поймали крайне любопытный кейс, какой-то «разработчик» засунул в проект библиотеку, имя сборки у которой которой совпадало с именем другой сборки. По итогу ловили странную (и фатальную) ошибку в функционале, который ну вообще не трогали даже близко, он раньше стабильно работал! И свидетели есть (правда нет нотариальной надписи, ну да ладно). Так вот о чём я — при наличии регрессионного тестирования этот баг был бы виден заранее, не нервировал бы заказчика, и «разработчик» был бы более-менее спокоен за свое моральное состояние.
Втрое уменьшилось количество дефектов, фиксируемых конечными пользователями.
— Я на вас жалобу напишу!
— Пишите, их там всё равно уже никто не читает.
(с) Анекдот
Парное программирование.Влечет за собой умножение трудоемкости, и, как следствие, стоимости, на 2. Как к этому относятся заказчики?
А хранятся ли где-то эти знания кроме как в устном фольклоре (эдакий сломанный телефон с задержкой по времени).
Это практика управления изменениями. Вся актуальная информация по реализованной функциональность должна хранить в технических проектах. Разработчики при внесении изменений в код предварительно актуализируют техпроекты. Новичок берет техпроект и изучает.
Можете рассказать как это организовано?
Плановое обучение команды, разбор частых вопросов.
Общий чат по проблемам. Если у разработчика есть вопрос, то он может его написать только в общий чат, прямой вопрос тимлиду или другим разработчикам в "личку" запрещается.
Также нужно отметить важность регрессионного тестирования, вы указали, что тестируете доработки, а остальной функционал?
Регрессивное тестирование производится на препродуктивном стенде. Специально обученные консультанты проводят тестирование по чек-листу. Мечтаем про автотесты ) но пока не удается включить в смету...
>> Парное программирование.
>> Влечет за собой умножение трудоемкости, и, как следствие, стоимости, на 2. Как к этому относятся заказчики?
В нашем случае считаем внутренними издержками, на заказчика не выносится. В последние месяце парное программирование уже потеряло актуальность. Уже достаточно помогло в обучении разработчиков на практике.
Дмитрий, спасибо за информацию из Вашей практики, очень ценно!
Плановое обучение команды
Как веревочке не виться...а без планового действительно никуда. Поддерживаю!
Регрессивное тестирование производится на препродуктивном стенде. Специально обученные консультанты проводят тестирование по чек-листу.
Они прям весь функционал прогоняют?
Мечтаем про автотесты ) но пока не удается включить в смету...
На контрасте с предыдущим пунктом разница в цене должна быть ощутимой даже на небольших сроках.
Нечеткие цели и требования. Если есть такие задачи, то их отправляем на проработку и исключаем из Backlog. После детальной проработки задача может быть снова помещена в Backlog.
В одной фразе масса неувязок:
постановка задачи выносится за рамки процесса разработки.
и тем самым отрывается от ограничений реализации
где-то там, вне процесса есть супермозг, способный ставить задачи
проработка задачи при разработке "снизу-вверх" хорошо если не наполовину связана с увязыванием других задач в некий общий фреймворк
потому что не только код должен рефакториться, но и фугкциональная архитектура
Кстати, про рефакторинг что-то ничего и не написано...
Немного не понял про неувязки. Возможно не развернуто написал.
В этом блоке имелось ввиду, что если поступающая таска (а это собранные требования от заказчика) содержит не четкие требования (т.е. не до конца проработана бизнес-логика), то такая таска в работу не берется.
Мы решили внедрить Agile-Lean принципы в процесс разработки “на ходу” и вот что из этого получилось