DK
Сохраняем пирамидку, да?
какую?
Size: a a a
2020 February 27
A
главнюк > важняки > холопы
ОИ
> таджики
Ms
> пехота
A
Пехота на галерах - деньги на ветер!
Ms
смотря какой день, если ветренный - галера сама доплывает
A
Но пехоту-то туда сажать зачем? Только если абордаж...
Ms
морской десант, для высадки и ИБД на территории клиента
Ms
потом засылается главнюк и разгоняет
DK
Пехота на галерах - деньги на ветер!
пусть волоком тащуть
A
Бурлаки на волоке...
RT
Наверно у вас был не скрам, а «скрам, но» (scrum, but), судя по проблеме. В скраме программистам дают бизнес задачу, они сами погружаются на этапе оценки в проблему и обсуждают все (в том числе с аналитиками) от уровня бизнес постановки до реализации чуть ли не в классах. [и только после этого оценивают]. А проблема, похожая на вашу, на моем опыте часто возникала, когда на словах декларируется скрам, а по сути программистам без объяснений спускается 500-страничное ТЗ и пилится по задачам. Ну да, нормальный программист он ленивый и будет читать не весь документ а только нужную часть.
Лечится возвращением к основам — адекватный backlog груминг, планирование и обзоры спринта всей командой с заказчиком и обратной связью.
Лечится возвращением к основам — адекватный backlog груминг, планирование и обзоры спринта всей командой с заказчиком и обратной связью.
При таком подходе возникает и другая проблема: команда не фиксирует принятые решения, описание предметной области. То есть “в скраме” отсутствует документооборот, все на словах.
В сложных, длительных проектах критически важно фиксировать знание в документах. Иначе команда будет замедляться, ввиду растущей сложности решения и непонимания предметки.
Нужны выделенная роль для ведения документооборота? Специальный аналитик, который фиксирует все решения команды?
В сложных, длительных проектах критически важно фиксировать знание в документах. Иначе команда будет замедляться, ввиду растущей сложности решения и непонимания предметки.
Нужны выделенная роль для ведения документооборота? Специальный аналитик, который фиксирует все решения команды?
DK
На прошлом моем месте работы у меня была такая роль. А также у аналитиков, которых давали мне в помощь. Мы фиксировали в том числе архитектурные решения, детализировали, описывали системные постановки. А также после реализации дорабатывали, если вдруг что-то изменилось.
A
А разве это не задача Продукт-Овнера - фиксировать общие вопросы? В сложных кейсах: архитектор/аналитик фиксирует "архитектурные" особенности, разработчики - особенности реализации.
DK
за каждым модулем был выделенный аналитик, который отвечал за актуальность описания реализации модуля. детализация решения - описание ui, api, физическая модель бд, связь ui с вызываемыми методами api, связь api с используемыми сущностями в бд, алгоритмы. указание ответственных за модуль и названий частей модуля в коде. например, название схемы в бд.
A
Как идею слышал (сами мы пока до попробовать это не дошли): делаешь разбиаение таски на сабтаски, включаешь туда "документирование/описание"
DK
еще можно добавлять в жц таски "документирование"
RT
А разве это не задача Продукт-Овнера - фиксировать общие вопросы? В сложных кейсах: архитектор/аналитик фиксирует "архитектурные" особенности, разработчики - особенности реализации.
PO он как-бы отвечает за бизнес, а в технологической части как свинья в апельсинах. От него быть инженером и не требуется, ему надо думать про новые возможности денег заработать
А
А разве это не задача Продукт-Овнера - фиксировать общие вопросы? В сложных кейсах: архитектор/аналитик фиксирует "архитектурные" особенности, разработчики - особенности реализации.
его )
RT
еще можно добавлять в жц таски "документирование"
По моему опыту документирование после реализации не работает. После того как ребенок уже получил конфетку (релиз, задача выполнена), у него нет никаких стимулов что-то еще делать.