Pull to refresh

Всем привет!

Недавно посмотрел интересное видео про управление техдолгом https://youtu.be/pvZDcytPU3w

На самом деле видео не про управление техдолгом в целом. Там нет архитектурного техдолга, технологического. Оно про техдолг, возникающий при реализации конкретной фичи - когда появляется TODO в коде.

Речь идет о извечной проблеме разработчика - "сделать все идеально". Но идеально может потребовать дни или даже недели. А у нас Agile, спринты в 2 недели, бизнес ждет свою фичу.
Что предлагается:

  1. не надеяться, что декомпозиция задачи на планировании будет идеальной

  2. если при реализации выясняется, что фичу невозможно сделать в запланированные сроки, а их можно прикинуть исходя из длины спринта, числа задач и их оценки - нужно сделать часть фичи, допускающую продвижение дальше команды. Опять же - декомпозировать сложно, но итеративно это получается лучше.

  3. расставить по коду подробные TODO, рассказать команде что сделано, а что нет и почему, и влить доработку. Т.об. мы гарантировано получаем большую прозрачность. А если правильно удалось определить, что блокер для команды - еще и лучший Lead Time.

  4. далее некий робот сканирует код, находит TODO и делает из них таски в вашем трекере

  5. таски будут оценены на очередном планировании и взяты в работу, возможно другим разработчиком

    Самое интересное - для одной и той же задачи пункты 1-5 могут повторяться. Наверное, если это происходит в 5-й раз - стоит детальнее взглянуть на задачу. Похоже она сильно влияет на архитектуру.

    Итого - идея мне нравится!

Tags:
Total votes 1: ↑1 and ↓0+3
Comments0

Articles