Ну если хочется исследований, то есть еще довольно известный CHAOS-репорт, который гласит что подавляющий процент IT проектов фейлится (то есть выходят за рамки бюджета или не достигают поставленных целей), и только 7% фейлов - вина разработчиков (техническая некомпетентность). Этот репорт в совокупе с тем что я наблюдаю вокруг себя заставляет усомниться в том что текущие подходы себя оправдывают, если честно. https://www.projectsmart.co.uk/white-papers/chaos-report.pdf.

> про какую именно ответственность писалось выше я не понял - то ли про самоощущение, то ли про неотвратимость наказания в случае факапа, то ли ещё про что.

Про ответственность вида "в чем конкретно мои обязанности: за что конкретно я получу премию, и за что конкретно огребу пенальтей".

Звучит как Structure and clarity - действительно очень важная хрень получается.
Спасибо за CHAOS-report, не слышал о таком честно говоря.
Фокус обсуждения по-моему опять слегка поплыл - от того как заставить программистов работать лучше мы перешли на то почему проекты фейлятся.
Тут два поинта:
1. Я не вполне согласен с тем что выход за рамки бюджета всегда = фейл. В кровавом энтерпрайзе вендор вполне осознанно может в убыток делать проект, а прайс и сроки могут формироваться не по результатам планирования, а по результатам взамных попыток зафиксировать бизнес-партнёра в устойчивой колено-локтевой позиции.
2. Кажется статья о том что эффективность работы программстиов делает не сильно большой вклад в итоговый успех - главный источник факапаов провал в коммуникациях с заказчиком. Скрамы/аджайлы ставят себе целью закрыть этот гэп, непонятно каким боком нам тут помогут микротаски.

1. Формально это все же - фейл. Но никто не признается в фейле, потому что придется нести за него ответственность кому то. Как один из результатов - те самые премии за фейлы. "вы молоцы, ребят, все правильно сделали, теперь посидите и подеградируйте еще релиз, пока мы с партнерами еще бабло попилим".

2. Микротаскинг изолирует программиста от тех компетенций, где он все равно по определению не особо эффективен. Вместо огромной расплывчато описанной фичи и просьбой "сделай чтоб хорошо", подкрепленной пропагандой о том что "вы все ответственны за проект поровну" и "тыж программист, должен разбираться в нашем бизнесе", на вход он получает конкретную таску с конкретным описанием, и требованием "сделай как написано". Получив микротаску, оного больше не будет волновать фидбэк юзера, дыры в требованиях и прочие факапы начальства: микротаска - его личный микропроект. Организовать сбор фидбека от юзера и собрать требования - не его забота.

А кто формирует микротасках? При твоём описании это лежит на плечах архитектора

Необязательно. Микротаски проходят модерацию через архитектора, и архитектор ответственен за конечный результат, но никто не говорил что архитектор должен все делать сам.

Были случаи когда мне прилетали "микротаски" объемом с эпик, в таком случае моей задачей за те 30 минут отведенных мне было запилить костяк со стабами и описать дальнейший план действий, породив при этом еще с десяток микротасок (это уже - PDD). А на ревью уже бы смотрели - адекватен ли мой пропозал или нет.

На самом деле такие эпик-микротаски - имхо действительно объект для критики, признаю. Хрен их сделаешь за 30 минут, пока спеку прочитаешь и осмыслишь эти 30 минут пройдут. И хрен там адекватно проверишь на ревью адекватность пропозала. Но все решаемо, целиком концепцию это не опровергает

что то я наверное плохо понимаю роль архитектора на проекте. мне видилось, что архитектор не мыслит в терминах "фича" или "эпик", а мыслит в терминах "стабильность", "поддерживаемость" и "хотелки легче впиливать"

Где я сказал в каких категориях он мыслит? Я всего лишь сказал что он там главный и делегирует, вот и все.

ты описал ответственность архитектора - фичи и формирование микротасок в рамках фич, эпиков и тд

он там их модерирует, ревьюит и вообще за всем следит

Приведи цитату где я это сказал. Может оговорился

вот эта например

архитектор не имплементит, но модерирует сами таски, потом еще и ревьюит результат

Архитектор - не единственный источник тасок. Таски могут идти отовсюду - от архитектора, от бизнеса, от юзеров и от девелоперов. Задача архитектора - видеть картину в целом и не пропускать откровенную дичь.

Есть примеры где все это посмотреть?

то есть ему надо следить за 100500 микротасок(источник которых еще может быть все что угодно) и при этом не терять фокус за происходящим + продолжать думать о стабильности проекта?

Что из себя представляет микротаска?

пахнет супергероями