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

Кстати Вы когда-нибудь писали банковский софт?
Лично я писал, и никакие версионированные требования никак не помогали реализации и дальнейшему поддержанию. Например, на Украине требования к банковской отчетности достаточно часто меняются, и очень часто приходится их оперативно реализовывать. Конечно есть исходные документы которые воспринимаются как требования, но они приходят сверху (в данном случае от НБУ). И практически нет никакого смысла их вести версионированно в своей системе, т.к. нужно опять таки поддерживать эту документацию и код отдельно.

Просто не все еще понимают существенные отличия между QC, QD и прочими великими абревиатурами.

Например, я не понимаю... но это чертовски важно...

Да с уникальность и богатым внутренним миром там похоже все на недосягаемой высоте.

Более того внутренний мир дошел до того чтобы наставлять других на путь истинный...

Из реального пример проект длился значительно больше чем 2 года, люди практически все поменялись ведение всей детальной документации никак не помогало. Выкинули нафиг «процесс» стало на порядок проще жить и поддерживать. Другое дело что для того чтобы это работало нужно понимать что делаешь. Из серии использования здравого смысла для додумывания незадокументированных явно вещей. Но это выдвигает определенные требования к квалификации... хотя документация написанная не сильно квалифицированными сотрудниками это та еще песня.

Подпорки и надстройки — ну это наверно в любом проекте есть.

Просто если подумать то ведение формальной документации достаточно осложняет жизнь на большинстве проектов именно на этапе поддержания. Причина простая — нужно поддерживать в актуальном состоянии не только код (реализацию) но и документацию. А обычно делаются изменения, в документации их отразить забывают (ну хоть иногда правда же такое бывает?), и ... начинается больше непоняток на уровне «где же правильно в документации или в коде». При том что реально правильно может быть именно в коде.

Хотя каждый делает свой выбор сам, возможно не попробовав работать по-другому это не поймешь.

Если серьезно, то чем меньше таких тулзов тем будет проще делать проект.
Оно так кажется что такие тулзы упрощают жизнь, на самом деле сильно усложняют. Причем не зависит от сложности проекта. Даже наоборот чем сложнее проект тем сложнее будет потом разобраться в том что наделаете в таком туле. Пытайтесь упрощать себе жизнь, а не усложнять. Таки тулзы реально усложняют жизнь потом когда таких требований насобирается много и причем разных версий.

Если хочется себе трудностей, то пользоваться можно чем угодно, если нужно сделать проект то лучше придумать как без таких тулзов обойтись.

Ну или как вариант документация есть финальный результат работы, тут конечно лучше ее чем больше тем лучше :)

Когда-то пользовался разными тулзами, например Power Designer MetaModeler.
Потрачено было ой как много времени, а результат не сильно помогал реально проекту. Зато были все заняты и типа много документации было сделано.

честно говоря для меня Delivery Unit Manager бесмысленный набор слов :)

Если есть что по теме то пиши, а пытаться типа кого-то обидеть или показать свою «крутизну» (причем именно в кавычках), зачем?

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

Оценить производительность работы человека по собеседованию очень сложно, как бы хорошо не отвечал на вопросы и как бы хорошо не решал задачи на собеседовании есть всегда шанс, что работодатель хотел чего-то другого от твоей работы.

Это другое может быть все что угодно начиная от производительности, коммуникаций, ну мало ли чего — очень сильно зависит от работодателя и от проекта. Кстати когда увольняли не сказали почему?
Кстати далеко как не всегда есть формальная причина увольнения, практически всегда такое решение принимается не на основании набора формальных критериев.

По поводу того что кандидат просит мало или много это не всегда приводит к изменению требований предъявляемых к позиции на которую берут кандидата. Так что мотивация я же просил мало че вы от меня ждали это не аргумент.
С другой стороны работодателю может быть интересно твое развитие, и может огонь в глазах? :)

По поводу никто не ошибался — конечно все ошибаются, другое дело видит ли работодатель перспективу лично в тебе.

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

По поводу знаю все понемножку — может таки на чем-то сфокусироваться?

Delivery Unit Manager = типа менеджер по доставке модулей?

Как по мне так набор несвязанных слов. Похоже в Сиклуме таки трава или грибы более правильные чем у остальных, без этого такие великие названия тупо не понять.

Как бы повторяя известную песню: «И тема была прежней — я самый крутой.»

Чет я не понял по поводу пола?
Ну и что я при перекрутил? Кто написал что можно делать FP проекты при помощи скрама очень успешно?

Если у вас что-то не получилось, — это не значит что оно не работает эффективно в принципе.

Исходя из этого получается что все у кого «не получилось» просто не умеют работать эффективно.

да уж Сиклум и скрам близнецы братья :)

А если серьезно у Сиклума очень хороший маркетинг и продажи, поэтому они и успешны, а аутстафинг вообще состоит в том что как можно больше людей продать заказчику, так что процесс совсем ни при чем.

Я ничего не путаю в понятиях. А должности можно придумать хоть космонавт, хоть шахтер.

Я бы сказал что некоторые товарищи ратующие за скрам — теоретики и явно не понимают реальной жизни.

Ну пусть живут в своих розовых облаках.

даже не знаю когда начинается забор и где обед в данном случае :)

понимание причин того что как и зачем делается конечно помогает в работе. После понятия дзена начинаешь например меньше слушать всяких популяризаторов Agile и поддаваться на их агитацию.

хм это где же скрам то не применим?

Ну типа ПМ завалил проект — увольняем его нафиг? :)

при чем здесь шахтеры? имеется в виду что без ПМ ничего не умирает. Практически в том же скраме именно ПМ и нет, есть типа команда которая работает. Вот эта команда и делает результат.

Задача скрам мастера именно обеспечить неотвлечение людей на задачи не связанные с текущим спринтом, поскольку такие отвлечения явно мешают работе.