Size: a a a

Архитектура ИТ-решений

2020 February 27

DK

Daria Kaftan in Архитектура ИТ-решений
Eugene Istomin
Сохраняем пирамидку, да?
какую?
источник

A

Alexey in Архитектура ИТ-решений
главнюк > важняки > холопы
источник

ОИ

Олег Игонин in Архитектура ИТ-решений
> таджики
источник

Ms

Mutko says in Архитектура ИТ-решений
> пехота
источник

A

Alexey in Архитектура ИТ-решений
Пехота на галерах - деньги на ветер!
источник

Ms

Mutko says in Архитектура ИТ-решений
смотря какой день, если ветренный - галера сама доплывает
источник

A

Alexey in Архитектура ИТ-решений
Но пехоту-то туда сажать зачем? Только если абордаж...
источник

Ms

Mutko says in Архитектура ИТ-решений
морской десант, для высадки и ИБД на территории клиента
источник

Ms

Mutko says in Архитектура ИТ-решений
потом засылается главнюк и разгоняет
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Alexey
Пехота на галерах - деньги на ветер!
пусть волоком тащуть
источник

A

Alexey in Архитектура ИТ-решений
Бурлаки на волоке...
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Sergey V
Наверно у вас был не скрам, а «скрам, но» (scrum, but), судя по проблеме. В скраме программистам дают бизнес задачу, они сами погружаются на этапе оценки в проблему и обсуждают все (в том числе с аналитиками) от уровня бизнес постановки до реализации чуть ли не в классах. [и только после этого оценивают]. А проблема, похожая на вашу, на моем опыте часто возникала, когда на словах декларируется скрам, а по сути программистам без объяснений спускается 500-страничное ТЗ и пилится по задачам. Ну да, нормальный программист он ленивый и будет читать не весь документ а только нужную часть.

Лечится возвращением к основам — адекватный backlog груминг, планирование и обзоры спринта всей командой с заказчиком и обратной связью.
При таком подходе возникает и другая проблема: команда не фиксирует принятые решения, описание предметной области. То есть “в скраме” отсутствует документооборот, все на словах.
В сложных, длительных проектах критически важно фиксировать знание в документах. Иначе команда будет замедляться, ввиду растущей сложности решения и непонимания предметки.
Нужны выделенная роль для ведения документооборота? Специальный аналитик, который фиксирует все решения команды?
источник

DK

Daria Kaftan in Архитектура ИТ-решений
На прошлом моем месте работы у меня была такая роль. А также у аналитиков, которых давали мне в помощь. Мы фиксировали в том числе архитектурные решения, детализировали, описывали системные постановки. А также после реализации дорабатывали, если вдруг что-то изменилось.
источник

A

Alexey in Архитектура ИТ-решений
А разве это не задача Продукт-Овнера - фиксировать общие вопросы? В сложных кейсах: архитектор/аналитик фиксирует "архитектурные" особенности, разработчики - особенности реализации.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
за каждым модулем был выделенный аналитик, который отвечал за актуальность описания реализации модуля. детализация решения - описание ui, api, физическая модель бд, связь ui с вызываемыми методами api, связь api с используемыми сущностями в бд, алгоритмы. указание ответственных за модуль и названий частей модуля в коде. например, название схемы в бд.
источник

A

Alexey in Архитектура ИТ-решений
Как идею слышал (сами мы пока до попробовать это  не дошли): делаешь разбиаение таски на сабтаски, включаешь туда "документирование/описание"
источник

DK

Daria Kaftan in Архитектура ИТ-решений
еще можно добавлять в жц таски "документирование"
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Alexey
А разве это не задача Продукт-Овнера - фиксировать общие вопросы? В сложных кейсах: архитектор/аналитик фиксирует "архитектурные" особенности, разработчики - особенности реализации.
PO он как-бы отвечает за бизнес, а в технологической части как свинья в апельсинах. От него быть инженером и не требуется, ему надо думать про новые возможности денег заработать
источник

А

Артём in Архитектура ИТ-решений
Alexey
А разве это не задача Продукт-Овнера - фиксировать общие вопросы? В сложных кейсах: архитектор/аналитик фиксирует "архитектурные" особенности, разработчики - особенности реализации.
его )
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Daria Kaftan
еще можно добавлять в жц таски "документирование"
По моему опыту документирование после реализации не работает. После того как ребенок уже получил конфетку (релиз, задача выполнена), у него нет никаких стимулов что-то еще делать.
источник