tass neposeda
Мне кажется, что вы правильно подметили - и в t&m и в ретейнере на протяжении продолжительного времени набор исполнителей может не меняться. отличие только в юридических деталях - в t&m договорились, что оплатят время и "материалы", а в ретейнере обычно договариваются о цене за команду и за её состав. Различия могут проявляться тогда, когда поток задач от заказчика становится неоднородным. Такое бывает. То в бэкенде масштабные работы, то на фронт навалится, то дизайнерам перепало. В этом смысле разница между типами контракта скорее не в возможности заменить исполнителей одного типа между собой, а в балансировке компетенций в команде под текущие нужды заказчика. Хотя на практике изменения всегда приносят боль управленцам :)
Что касается терминов аджайл и итеративно-инкрементальный подход - я не оч понимаю, как и зачем их можно сравнивать и противопоставлять. первый в своём манифесте постулирует о ранней и регулярной поставке. Второй в названии содержит что-то оч близкое (что-то типа "регулярно наращивать результат"). Кажется, что Алексей не противопоставляет одно другому, а просто использует устоявшиеся в быту термины. Просто местные идиомы.
Ну и про ТЗ - лично я согласен! :) Вижен является важной точкой синхронизации. Если ТЗ отвечает на вопрос "как будут жить счастливые пользователи будущего продукта / ПО / ИС - вотэва" - пусть будет ТЗ!
—-
Неумение разобраться в своих процессах нередкое явление. Системы бывают разные, диаграммы бывают разные. И да, бывают такие проекты, в которые без аналитика лучше не ходить.
Уточнение - сейчас количественно речь идёт про одну команду продуктовой разработки, а не про весь джет
:) неееее, такое только у Грега Хауса в 4м сезоне бывает :) У нас не настолько "поточное производство". в среднем одномоментно у нас 1-3 джуна. И да, испытательный срок у нас правда испытательный. Если человек не развивается и подвис - мы всегда стараемся разобраться, что его фрустрирует - бывает что дело совсем не в нём, а мы упустили какие-то нюансы. В общем пытаемся поправить ситуацию. Но бывает, что это повод расстаться.
В большинстве проектов есть часть работы, которую можно условно назвать проектированием или архитектурой, а другая часть - рутинной.
У нас итерационный процесс, когда мы вначале стараемся максимально быстро сделать как-то работающий основной флоу, чтобы вместе с заказчиком проверить продуктовые гипотезы (типа MVP). В этот момент по сути уточняются ключевые свойства системы и действительно сеньору нужно быть максимально включённым. Далее, бэклог начинает наполняться новыми фичами и доработками старых фич. и среди задач появляется изрядное количество тех, которые находятся в зоне развития джуна, а сеньора отвлекают от "движения вперёд".
Безусловно, каждую из них, сеньор поправит сильно быстрее. Но зачем, если джун сможет сделать это сам, обучиться и освободить сеньора от рутины, которую он уже "сто раз делал".
И это боль, да :)
Хороший вопрос. Есть понятие ownership, которое описывает отношение кого-то к процессам, команде, продукту. Вот мы делаем ставку на то, чтобы все члены команды были заинтересованы в развитии вместе с командой.
Мне кажется, что нормальный сеньор в какой-то момент приходит к выводу, что его способ масштабирования - делегирование своим подопечным.
В целом, при таком подходе просто увидеть, что мотивация не только в отношении деньги к часу. Тогда польза от прокачки новичков становится понятной.
Кадровик в команде из 12 человек нахрен не нужен. HR это же не только про найм и "личные дела". Круто, когда в своих задачах HR находят возможность интеграции в процессы разработки, видеть изнутри общее состояние и ещё пользу в ведении скрам-активностей наносить.
То, что вы указали как полезные практики аджайла - классные штуки, которые в джетстайле знают и практикуют. статья как раз про это, как мне кажется.
...никогда не любил терминологические споры, поэтому что про итерационно-инкрементальную модель, что про ТЗ - я согласился с вашими доводами относительно важного в организации работы продуктовой команды. я согласился от самого себя и наверное такое может случиться, что мнение автора может не совпадать с мнением комментаторов ;)