Comments 38
Если команда следует Waterfall, то она не может вернуться назад и внести корректировки на ходу — ей придется мириться с допущенными ошибками до конца шестой фазы и лишь затем планировать исправления.
В каскадной модели есть менеджмент изменений к требованиям. Остановка, внесение изменений в требования, изменение задания, составление дополнительного задания на изменение затронутых ранее разработанных модулей, переоценка сроков и бюджета (с согласованием), продолжение реализации по изменённому плану. Но этот инструмент кажется заказчику очень дорогостоящим, поэтому менеджер проекта часто стесняется его применять.
Это применяется так редко, что просто забываешь, что он есть xD
На самом деле, есть еще такое понятие как Configutation Change Management, где ты управляешь изменениями, в том числи и в каскадной моделе. Ты просто заносишь запрос на изменения (на любом этапе) в систему управления изменениями, а Configuration Change Team (разных уровней) её потом либо апрувит, либо отклоняет, это позвляет внести изменения на любом этапе в любой артифакт предущих этапов.
Просто придется менять дофига всего (скажем если вы находитесь на этапе Implementation, а поменять надо требования, то придется менять требования, дизайн, код), но для этого Configuration Change Team и существует, чтобы все риски и расходы по этому изменению определить и в случае его дороговизны - отклонить либо принять, если изменения незначительные.
Понимаю боль автора и сообщества PM, спасибо за структурное изложение мыслей!
Ни Waterfall, ни Agile, ни любая другая существующая методология разработки ПО — не истина в последней инстанции, а всего лишь отправная точка. Это как Open Source: каждый берет нужное и допиливает под свои задачи.
С поправкой на это добавлю от себя. Вроде бы где то писал, но всё же. Была практика в энтерпрайз финтеха такого гибрида:
1) Каскад как брутто бизнес и технических целей, для долгосрочного и краткосрочного планирования (квартал).
2) Канбан внутри квартала по следующим стадиям Инициатива(с согласованием ЛПР)-РазвёрнутоеБизнесТребование - ФункциональноеТребование(Согласованное и оцененное разработкой). Что в последней стадии, то уходит в спринты.
3) Спринты на месяц. Причём с пониманием, что новая фича требует организационных, юридических и других изменений. К примеру, при внедрении расчёта ПДН(показателя долговой нагрузки) и МПЛ(макропруденциальных лимитов) постоянно были качели, т.к. для расчёта в системе базис это Правила расчёта, а чтобы написать эти Правила сильно влияет, можно ли так или иначе посчитать в системе. Такого рода фичи внедрять как раз помогает прямой контакт бизнеса и разработки. иначе можно бесконечно футболить мячики.
4) Внутри такого длинного спринта тоже Канбан с классическими стадиями реализации, вплоть до досрочного переноса в прод автономных готовых фич.
P.S. Да, при этом разумеется, также были форс мажоры в виде переноса в следующий спринт, внеочередных горячих пирожков, фальшстарты и псевдо-фичи(которые в следующем спринте уже были не нужны). Но в целом был тоже интересный и успешный опыт
Интересно, а как вы пришли к этой конструкции, и из каких предпосылок она сформировалась?
Попытка подружить линейность каскада с "аа,побежали" скрама, ну и плюс безмерная любовь к канбану. Тут стоит добавить, что много лет был больше со стороны бизнеса, поэтому каскад бизнес-целей для их реализации декомпозировался на организационные, операционные и иногда технические задачи. Если из вышеуказанного примера выкинуть уровень со спринтами, то получается вполне обычный бизнес-роадмап, положенный на канбан.
Основная проблема с agile в том, что он требует перестройки организационной структуры. Невозможно внедрять эджайл, если у вас вертикальная структура управления. Много у нас компаний отказались от роли тимлида? А между тем в scrum нет никаких лидов, есть PO и scrum-мастер. Попытки внедрить эджайл наполовину приводят к поялению псевдоэджайла, а он неэффективен. Об этом в частности пишет Мартин Фаулер.
то, что в скраме нет лидов, не значит, что в команде не может быть лидов. Ещё как могут и я бы сказал обязаны быть. И техлиды и тимлиды. Просто в скрам процессах нет такой роли.
"В Scrum-команде нет начальника, как нет и технического лидера." (с) Клод Обри "Все о scrum"
тимлид не начальник, у него другие задачи. Техлида можно явно не выделять, но он всё равно будет. У вас концептуальным проектированием и финальным рецензированием будет один человек заниматься, иначе это просто коллективная безответственность будет.
Будет, вот только он будет не назначен, а выбран командой. Хотя "выбран" здесь не точное слово, он просто благодаря своим знаниям получит в команде авторитет естественным путем. Что же касается "других задач", то они распределяются между PO и scrum-мастером. Тимлид просто не нужен, если у вас работающий scrum.
Что же касается "других задач", то они распределяются между PO и scrum-мастером. Тимлид просто не нужен, если у вас работающий scrum.
ни PO, ни scrum-мастер не занимаются стратегией развития команды, лидированием процессов, развитием членов команды. Вы забываете, что помимо продуктовых задач, есть ещё деятельность не связанная с разработкой.
Даже если взять тимлидов за пределами скрама, то и среди них отнюдь не большинство занимается тем что вы перечислили.
То есть даже если исходить из того что этим обязательно кто-то должен заниматься,, то это совсем не обязательно должен быть именно тимлид.
Даже если взять тимлидов за пределами скрама, то и среди них отнюдь не большинство занимается тем что вы перечислили.
То есть даже если исходить из того что этим обязательно кто-то должен заниматься,, то это совсем не обязательно должен быть именно тимлид.
Вообще понятие функций такой роли как тимлид очень сильно разнится между организациями. Где-то это самый опытный разработчик, но в моём понимании это техлид. Где-то это руководитель команды, но опять же в моём понимании это именно руководитель, а не тимлид. Тимлид - это "капитан футбольной команды", он не просто играет наряду с остальными членами команды, он лидирует игру. Он доносит до команды: кто мы, куда нам надо двигаться, что нам надо сделать, чтобы туда придти.
В рамках проектной работы он управляет бэклогом спринта, мощностью команды, планированием загрузки, разрешением внутренних конфликтов в соответствии с политиками и принципами команды, хранителем и евангелистом которых он является.
Скрам-мастер - это вообще про другое.
Вообще понятие функций такой роли как тимлид очень сильно разнится между организациями.
Как собственно и задачи которые выполняют эти самые тимлиды. Поэтому я и не особо понимаю почему вы выбрали один вариант и считаете его единственно верным.
Тимлид - это "капитан футбольной команды", он не просто играет наряду с остальными членами команды, он лидирует игру.
Это всего лишь один из возможных вариантов. И остальные варианты не менее легитимны.
В рамках проектной работы он управляет бэклогом спринта,
Вы смешиваете всё в одну кучу. Спринт и бэклог это в общем-то артефакты скрама. В скраме тимлида нет.
А то что вы описали в скраме делает команда целиком. И да, это вполне себе работает. Не всегда и не со всеми. Но работает. По крайней мере по моему опыту.
Скрам-мастер - это вообще про другое.
Конечно про другое. Причём здесь вообще скрам-мастер?
Если под "развитием команды" имеется в виду обучение, то это задача hr, а не тимлида. Что значит "лидирование процессов"? Каких? Фасилитация это есть первостепенная задача scrum-мастера. Вторая задача это устранение препятсвий. Задача PO давать направление, приоритезировать цели и давать обратную связь по результатам. Чем вы еще хотите покомандовать? Я рекомендую все же ознакомится со scrum и agile глубже, чем участие в конференциях. Литературу там почитать, например.
Если под "развитием команды" имеется в виду обучение, то это задача hr, а не тимлида.
ну положим не HR'а, а скорее RM'а. В его задачи входит обеспечение развития сотрудника - найти курсы, выбрать ментора. А кто определяет, что именно должен изучить сотрудник? Он сам? Гораздо лучше, если это определяется на one-2-one с тимлидом, где лид расскажет, что у нас есть проблемы с производительностью продукта (условно) и неплохо бы актуализировать нагрузочные тесты, но сейчас для этого в команде не хватает компетенций. И предложит сотруднику пройти доп.обучение по нагрузочному тестированию.
Что значит "лидирование процессов"? Каких? Фасилитация это есть первостепенная задача scrum-мастера.
причём тут фасилитация? Возникла в команде потребность что-то сделать не в рамках разработки фич, например те же нагрузочные тесты сделать. Скрам мастер будет в команду тыкать и искать, кто сделает? А потом проверять будет? Я для вас может открытие сделаю, но скрам-мастер обычно вообще не является членом команды, традиционно он ведёт несколько команд.
Чем вы еще хотите покомандовать?
Командой. Не логично?
Я рекомендую все же ознакомится со scrum и agile глубже, чем участие в конференциях. Литературу там почитать, например.
А вам я рекомендую не делать поспешных суждений о других. Я уже больше 20 лет команды в работу организую. И XP внедрял и аджайл и скрам. Я практик, а не теоретик, как многие скрам-мессии.
имеется в виду обучение, то это задача hr
Но погодите, ведь hr тоже нет в скраме. Там есть ПО, разработчик и скрам-мастер.
Мне кажется, что ситуация, когда все равны, возможна в условной команде где все "синьоры" с примерно одинаковым опытом работы. Тогда у них примерно одинаковые навыки, знания о продукте и никто им не нужен.
Но в реальном мире существуют джуны, мидлы, новички. Им нужен онбординг, нужен более тщательный присмотр в каких-то аспектах, нужно как-то строить их план развития. Да даже синьорам нужно развитие и его должен кто-то направлять.
И как не назови человека, который будет этим заниматься, его уже нет в скраме.
Но погодите, ведь hr тоже нет в скраме.
Бухгалтера тоже нет в скраме, но бухгалтерией всё равно кто-то занимается. Скрам это не о том как организовать фирму в целом. Это конкретно о процессе создания продукта.
С точки зрения скрама(как впрочем и водопада и всех известных мне подходов) абсолютно ортогонально как вы там у себя организовали "процесс развития" и организовали ли вы его вообще.
Мне кажется, что ситуация, когда все равны, возможна в условной команде где все "синьоры" с примерно одинаковым опытом работы.
Вообще-то в скраме совсем не обязательно все должны быть равны. То есть определение скрама этого не требует. Скрам ожидает что члены команды не являются узкими специалистами. Чтобы при необходимости всегда можно было подменять друг-друга. Но это не означает что все равны и даже не означает что все должны одинаково хорошо во всём разбираться.
безответсвенность будет
Это одна из причин, которая мешает внедрению scrum в РФ. Вы не верите в самоорганизацию и нанимаете людей экспертизе которых не доверяете. Зачем нанимаете тогда?
Это одна из причин, которая мешает внедрению scrum в РФ. Вы не верите в самоорганизацию и нанимаете людей экспертизе которых не доверяете. Зачем нанимаете тогда?
Вы невнимательно читаете, либо не понимаете смысл термина "коллективная безответственность". Никто не сомневается в экспертности команды. Но если вы думаете, что каждый в команде является и техническим спецом и лидером, то сильно ошибаетесь. Ответственность всегда должна быть персональна.
Ответственность за что? За решения? Что вам даст персональная ответственность за решения? Моральное удовлетворение за то, что вы накажете человека, когда он ошибется? Не нужно быть техническим спецом во всем, для этого в scrum-командах существует практика привлечения экспертов. А у вас лиды то есть, которые шарят вообще за все интересно?
Ответственность за что? За решения? Что вам даст персональная ответственность за решения? Моральное удовлетворение за то, что вы накажете человека, когда он ошибется?
ответственность - это не про наказание, это про то, кто за результат отвечает.
Не нужно быть техническим спецом во всем, для этого в scrum-командах существует практика привлечения экспертов. А у вас лиды то есть, которые шарят вообще за все интересно?
а кто говорит о техническом спеце-универсале? Например в моей команде тимлид не является техническим экспертом. Для этого у нас два техлида есть.
Если вы не верите, что команда может отвечать вместе за то, что они делают, то agile и в частности scrum для вас плохой выбор. Это буквально суть agile. Если вы не отказываетесь от микроменеджмента и при этом просто внедряете ритуалы то вы получите псевдоэджайл и зомби-скрам.
Если для вас это трудно, воспринимайте термин "отвечать за результат" буквально - иметь возможность вербально что-то ответить. Для простоты. Команда сделала что-то, получила результат. По этому результату возникли вопросы. Кто будет отвечать на них? Команда не может, у неё нет рта. Или вы думаете, что при получении вопроса, команда уходит на обдумывание, а потом один такой выходит и говорит "Отвечать на вопрос будет Друзь"?
Понятно что за артефакты спринта ответственность на всей команде. Но внутри команды есть люди, которые приняли те или иные решения. Есть решения технические - их приняли техлиды. Есть решения организационные в рамках процесса разработки, их возможно принял скрам-мастер. Есть другие решения по работе (например решили в рамках спринта поменять приоритет задач), развитию (решили выделить время на изучение новых инструментов), внутрикомандные (развернуть ещё один тестовый стенд, увеличить покрытие модульными тестами, сделать новый автодеплой). Всегда есть человек, который принимает итоговое решение и он же за него отвечает, а не абстрактная команда.
К слову, роль скрам-мастера вообще не обязательна для скрама. Со временем команда начинает работать без его помощи и фактически функции мастера переходят к человеку внутри команды. Обычно это и есть тимлид.
это про то, кто за результат отвечает.
И что это означает в вашем понимании? То есть вот есть Вася и он отвечает за результат. Результат не достигнут. Дальше что?
Что значит дальше что? Именно Вы отвечаете за результат вашей работы. Деньги любым наемным сотрудникам, коими разработчики также являются, платят именно за результат, а не за общественные деяния. Результат может быть негативным, промежуточным, позитивным и так далее. Но он обязательно должен быть, и за то каким он будет несете ответсвенность именно Вы.
Мне всегда интересно было почему во всех других отраслях есть и персональные задачи, и ответсвенность, и планирование и даже относительное нормирование выполняемых работ - одни айтишники все еще считают себя помазанниками божьими (хотя судя по развитию ИИ и кризису отрасли многим таки придется изменить текущее мнение). Я лично видел как организована работа инженеров-конструкторов, АСУТПшников, математического моделирования и других - нигде такого бардака как в айти и близко нет. И если вы со всеми этими скрамами и аджайлами попали в небольшую, сработанную и ответственную команду - не забывайте угащать их коффе по утрам с круасанами!!! Ибо по больше части отношение к общему делу с общей ответсвенностью зачастую заканчивается общей задней точкой.
И тут совершенно не играет роль талант, опыт, софт скилы и прочее. Сто раз видел прекрасных и толковых разработчиков, которые десятку инженеров фору дадут, но пока их не пнешь делать они ничего не будут.
Что значит дальше что?
То и значит. Вот результат не достигнут. Что будет дальше? Денег не заплатят? Уволят? Что конкретно должно случиться по мнению моего оппонента?
Мне всегда интересно было почему во всех других отраслях есть и персональные задачи, и ответсвенность, и планирование и даже относительное нормирование выполняемых работ
Потому что иногда это есть, а иногда нет. В других отраслях тоже бывают разные виды организации процесс.
И в ИТ скрам тоже не всегда используется. И когда он используется, то делается это не просто по приколу.
Сто раз видел прекрасных и толковых разработчиков, которые десятку инженеров фору дадут, но пока их не пнешь делать они ничего не будут.
И? Ну значит не подходят они для скрама. Как будто инженеры все поголовно ответственные...
Ответственность - это, например, про "за кем последнее слово" в случае спорной ситуации, про право вето и право принимать решение)
Я бы даже сказал - лидерство. Лидерство ведь не про то, что лидер принимает все решения сам. Это скорее про то, что в спорной ситуации нескольких мнений есть тот, кто может быстро сделать выбор.
Ну а в скрам единственный выделенный лидер - это PO. Который в основном отвечает за коммуникации с заказчиком и не является техническим специалистом. Поэтому, с точки зрения технических деталей: какую архитектуру и какие средства разработки использовать, какие требования к коду - все это отдано на откуп команде.
А тут либо появляются неформальные технические лидеры, с которыми команда согласна, либо бесконечные заседания без возможности выработать результат.
PMBOK почитайте
Читали. Сложилось впечатление, что авторы пишут про строительство атомной станции с нуля или пилотируемую миссию на Юпитер. Возможно плохо читали, тогда поделитесь своим видением решения проблем, описанных в статье)
Ну так с этого же автор вроде и начал, что Waterfall (а о чистом нём как раз и PMBoK), не догма, а сборник бест-практикс, как рекомендаций, а не пошаговая инструкция, от которой нельзя отступиться. И для длинных тяжёлых проектов это отличная практическая методология, чтобы добежать вообще для финиша. А если у Вас проектик по созданию сайта на дюжину страниц с одной интеграцией с каким нибудь лидогенератором, то Вы будете ли, как пример, сосредоточенно матрицу рисков вести или критический путь рассчитывать?
Судя по статье получается, что недостатков меньше всего у Waterfall. Личный опыт участия в различных проектах это подтверждает. Да и невысокое качество современного ПО тоже.
По моему опыту, в водопаде получается наилучший анализ, потому как на этапе написания ТЗ волей-неволей приходится собрать всех необходимых экспертов у заказчика и разобраться, а что же надо сделать и как оно в итоге должно работать. В гибких методологиях по идее должен быть в быстром доступе представитель заказчик, но он один, часто неинформирован, не заинтересован или не уполномочен принимать какие-то решения, в итоге его фидбек имеет очень низкую ценность и качество продукта зависит от усилий аналитика и внутренней экспертизы.
Кстати, если взять срез по научным статьям, то там тоже прослеживается такая закономерность. Возможно это разновидность ошибки выжившего. Мы вот чаще работаем по Agile и все эти проблемы очень знакомые, а болячки Waterfall не такие натоптанные. Так и в литературе - в последние годы все носятся с гибкими методологиями, а тема каскадной остается недораскрыта.
Достоинства Waterfall
Во-первых, эта методология проста для понимания благодаря четкой линейной структуре. Чтобы работать по водопадной методологии, не нужно становиться гуру менеджмента — достаточно последовательно идти по шести основным проектным фазам: определение требований, проектирование, разработка, тестирование, внедрение и сопровождение.
О да! Гайд по водопаду обновляется каждый месяц! А какие конференции проходят ух! Доклады просто закачаешься!
PS. Автор ПМ и почему то запихнул внедрение и сопровождение в фазы проекта, наверно 9 версию пмбока вышла и он от туда это взял
Waterfall, Agile, Scrumban — плюсы и минусы, или Что не так с эталонными подходами к разработке