Сегодня в методах разработки ПО исключения не подтверждают, а скорее заменяют правила. Чистокровный Аgile днем с огнем не сыщешь ни в одной компании. Зато плодятся разные гибридные методологии. Некоторые проджекты задаются совсем уж крамольным вопросом: зачем нужны эталонные системы, если на практике все работают по-разному?
Думается, что они выступают в качестве удачных базовых рабочих процессов, которые можно и нужно модифицировать. Однако перед тем, как что-то менять, постараемся в общих чертах разобраться, что не так с популярными методологиями разработки, в чем их особенности и как выбрать подходящую.
Спойлер: многие затронутые вопросы спорные, и готовых решений у нашей команды нет (как, наверное, у большинства PM). Так что заранее приглашаю всех желающих к диалогу и обмену опытом в комментариях.
Ни Waterfall, ни Agile, ни любая другая существующая методология разработки ПО — не истина в последней инстанции, а всего лишь отправная точка. Это как Open Source: каждый берет нужное и допиливает под свои задачи. И не важно, что порой методологии работают не совсем правильно или вовсе используются не по назначению. Периодически в таких экспериментах даже рождаются удачные гибридные подходы. Однако если не знаешь, что именно менять и дорабатывать, — велик риск сделать еще хуже и сломать рабочие механизмы. Так что взглянем на сильные и слабые стороны распространенных методологий разработки.
Критиковать классику — это классика. Waterfall
Традиционный Waterfall не пнул разве что ленивый, но за годы существования водопадная модель стала основой многих жизненных циклов разработки программного обеспечения. У нее есть сильные стороны.
Достоинства Waterfall
Во-первых, эта методология проста для понимания благодаря четкой линейной структуре. Чтобы работать по водопадной методологии, не нужно становиться гуру менеджмента — достаточно последовательно идти по шести основным проектным фазам: определение требований, проектирование, разработка, тестирование, внедрение и сопровождение.
Водопад не постулирует абстрактных принципов вроде аджайловских «коммуникации, адаптивности и уважения». Он оставляет подобные вопросы за скобками. В отличие от Agile, это утилитарная методология, а не философия создания ПО.
Во-вторых, водопад подталкивает тщательно оценивать и прорабатывать риски прямо «на берегу». Можно сказать, что у Waterfall девиз чеховского человека в футляре: как бы чего не вышло. Зачастую госкомпании и консервативные организации признают только такую методологию, а сами слова «Аgile», «Scrum» или «Kanban» для многих под строжайшим запретом. Так что хотите побеждать в тендерах и получать госконтракты — готовьтесь к «прыжкам в водопад».
Недостатки Waterfall
Главная претензия большинства специалистов к водопадной модели — заложенное в ее дизайн неприятие изменений и корректив «на лету». Работа по Waterfall означает нудное проектирование толстого ТЗ, которое потом все проклинают, растянутая на месяцы, а иногда и годы (бывает и такое) реализация. Этапы работы выполняются строго поочередно — их нельзя менять местами. Если команда следует Waterfall, то она не может вернуться назад и внести корректировки на ходу — ей придется мириться с допущенными ошибками до конца шестой фазы и лишь затем планировать исправления. UPD. В комментариях справедливо замечают, что в Waterfall все же есть менеджмент изменений к требованиям, но применяется он крайне редко.
Такой недостаток гибкости сильно мешает. Положа руку на сердце, сколько проектов обходится без того, чтобы заказчик не изменил по ходу требования к отдельным фичам? Выходит, старый добрый Waterfall заметно отстал от жизни и современных реалий разработки.
Agile — когда одного манифеста мало
Не удивительно, что так много разработчиков предпочитают различные Agile-методологии, но у них свои фичи и баги.
Достоинства Agile-методологий
Одно из самых существенных преимуществ гибких методологий — прямая коммуникация между разработчиками и заказчиками. Последние могут непрерывно давать фидбек и реально влиять на рабочий процесс, а не только согласовывать требования и принимать конечный результат. Впрочем, этот плюс имеет оборотную сторону, но о ней чуть позже.
Важно и то, что отхождение от изначального плана в Agile не нарушает рабочий процесс. В случае с Kanban все неожиданные задачи берутся в реализацию чуть ли не по щелчку пальцев, исполнители сменяются на лету, а приоритеты постоянно корректируются. Не нужно получать сотни согласований — достаточно переставить карточки на доске проекта.
В Scrum отношение к изменениям тоже довольно гибкое, но все же чуть более осторожное. Иногда это помогает избежать «фальстартов». Если спринт уже идет, то, скорее всего, новые фичи возьмут в разработку только в следующую итерацию. Поэтому у руководителей и специалистов остается больше времени на анализ хода проекта.
Scrum также вводит дополнительную детализацию по ролям, которые играют члены команды разработки в рамках проекта. Эта методология регулирует коммуникации, например, рекомендует проводить Daily Scrums. В общем, в Scrum чуть меньше свободы, чем в Kanban, зато больше организации и порядка. Однако всем плюсам соответствуют свои минусы.
Недостатки Agile в целом
Особенность Agile-методологий в том, что с ними уже нельзя спрятаться в футляре из формально зафиксированных требований. Как правило, нет четкого ТЗ и оценки рисков на старте: нужно быстрее «ввязаться в драку», и только затем проясняются перспективы проекта.
Другая ахиллесова пята — сложность внедрения гибких методологий в крупных организациях со зрелыми процессами. В отличие от формального по своей сути водопада, Agile претендует на звание философии разработки, требует смены мышления и базовых принципов организации процессов всей компании. В «монастыре» с давно сложившимся уставом такие предложения зачастую воспринимают как ересь.
Даже если разработчики прониклись гибкостью Agile, не факт, что их поймут в других подразделениях. Например, отдел кадров крупной компании может по-прежнему требовать строгого соблюдения штатного расписания и четкого следования определенным ролям.
Препятствием к внедрению Agile становятся и чисто методологические трудности. Манифест Agile на то и манифест: использовать его как пошаговую инструкцию проблематично. Закреплены лишь основные постулаты, но не способы их реализации.
Причем недостаточно взять на вооружение отдельные инструменты — Kanban-доски или спринты. Важно осознать, зачем они используются и что дают команде. Иначе, по сути, ничего не меняется: те же спринты на поверку оказываются мини-водопадами в новой обертке. Частый привет из Waterfall — оценки задач в виде оставшегося рабочего времени и их разбивка, полностью оторванная от того, что делается по факту.
Играет злую шутку и дробление процесса на короткие итерации. Бывает, что руководители используют терминологию Scrum, но в действительности просто заставляют команды брать на себя неоправданные объемы задач в сжатые сроки. Разработка становится настоящим бегом в колесе, а сотрудники выгорают.
Вдобавок канонический Agile не учитывает отраслевую и бизнес-специфику. В результате, чтобы адаптировать, например, Scrum, в некоторых компаниях просто опускают отдельные практики в рамках методологии или разрешают части сотрудников работать по-прежнему. Получается, что все равны, но некоторые равнее, а решения так и принимаются методом командно-административного управления. Это противоречит манифесту Agile.
Другая слабая сторона Agile — отсутствие адекватных способов оценки результативности отдельных специалистов. В итоге вклад каждого разработчика либо никак не измеряется, либо рассчитывается, исходя из субъективных и оторванных от реальности KPI. Это снижает мотивацию исполнителей и качество работы.
Еще один существенный минус — в наиболее распространенных Agile-подходах, например, Scrum и Kanban, нет высокоуровневого управления требованиями. Заказчики или инвесторы постоянно дают фидбек, корректируют пожелания к ПО. Но в масштабных проектах такие запросы могут выдвигать сразу несколько заинтересованных сторон. Кроме того, менеджерам часто бывает сложно разбить высокоуровневые требования до размеров, позволяющих адекватно оценить трудозатраты. В таких условиях необходимы связующее звено и процессы, которые позволят оценить и «подружить» требования между собой, отсеять лишнее, выстроить коммуникацию со всеми ЛПР-ами.
Гибкие методологии критикуют и за низкий уровень долгосрочного планирования. Типичные бэклоги в рамках Agile описывают лишь небольшие временные отрезки, например, двухнедельные спринты. Зачастую Agile-методологии не охватывают цели и ориентиры проекта, и об этом стоит подробно поговорить в отдельной статье.
Недостатки Kanban
Простота изменений — это, конечно, хорошо, но до некого предела. Иногда Kanban все же не хватает ограничителей. Скажем, заказчик ПО только заикнулся, что ему нужна та или иная дополнительная функциональность, и на доске мгновенно появляется новая карточка. Задача в работе, и вот уже специалисты бьются над тем, как «изобразить каменный цветок». А уже через неделю выясняется, что заказчик передумал...
Вспоминается давний случай из практики. Однажды разрабатывали мобильное приложение — криптовалютный кошелек. У заказчика было несколько ключевых требований к функциональности: чат для пользователей, система обработки ERC20-транзакций.
Первым делом реализовали прием и отправку BTC и ETH, потом занялись чатом... Должны были доделать его примерно через полтора месяца, но спустя три недели заказчик поменял приоритеты в пользу обработки платежей и функции обмена. Наработки по чату отправились в морозильник, где лежат до сих пор. Время по большому счету было потрачено впустую.
Помимо фальстартов, Kanban плох тем, что рассеивает внимание и подталкивает разработчиков перескакивать между задачами.
Недостатки Scrum
Scrum часто критикуют за перекос в сторону руководителей и менеджеров, которые держат в своих руках все рычаги воздействия на ход проекта. Конечно, грамотный PM или тимлид должен прислушиваться к команде, но на деле так происходит не всегда. При неумелом руководстве спринты превращаются в формальность и обязанность «штамповать» определенный объем работы каждую неделю-две даже тогда, когда спешить некуда.
По нашему опыту за первые несколько месяцев проекта крайне редко удается раскрыть и продемонстрировать бизнес-пользу отдельных фич. Так почему бы не скорректировать планы в ходе спринта и немного не разгрузить специалистов, если в начале возник форс-мажор? Но нет: методология не велит.
Многие scrum-команды из мира заказной разработки грешат частой ротацией составов: далеко не все участники проходят проект «от и до». Следовательно, разработчики не видят результатов и не делают выводов. Порой анализировать ошибки, вскрывшиеся на поздних этапах проекта, просто некому, так как виновники уже работают над чем-то другим.
Продолжая командную тематику, отмечу, что Scrum ориентирован на работу группами по 6 — 9 специалистов. Если участников существенно больше, методология начинает сбоить
Не нравится многим и то, что Scrum исключает прямое участие внешних стейкхолдеров в спринтах. В итоге обратная связь запаздывает, возникают сложности с подготовкой Definition of Done (критерии приемки) для фич, которые разрабатываются в ходе итераций.
Вызывают проблемы и ограничения ролевой модели Scrum. Владелец продукта, скрам-мастер и разработчик — вот и все доступные роли. Абстрактные «разработчики» сливаются в единую массу и методологически не привязаны к задачам или областям. Это может вызывать путаницу, когда непонятны степень вовлеченности и сфера ответственности конкретного специалиста.
Упрекают Scrum и за перебор с совещаниями и установочными мероприятиями. Стендапы, спринт-ревью, сторипоинты и другие активности могут отнимать столько времени, что непосредственно разработкой заниматься некогда.
Направо пойдешь… или Как выбрать подходящую базовую методологию
Это вопрос из серии «в чем смысл жизни?», ведь однозначного ответа на него нет. Но, ориентируясь на плюсы и минусы разных методологий, можно выделить некоторые базовые предпосылки к применению того или иного подхода.
Предпосылки к применению WaterFall
Первую уже назвал — это участие в тендерах и стремление получить госконтракты. Обычно в таких проектах требования зафиксированы, а вероятность их изменения сравнительно мала. Взаимодействие с заказчиком идет на заранее определенных этапах работ.
Вторая предпосылка — низкая динамичность и консервативность рынка, для которого создается продукт. Наглядный пример — бухгалтерия с ее учетными системами, такими же классическими, как симфоническая музыка или костюм-тройка. Большая часть подобного ПО разработана еще при царе Горохе, и заменяют его крайне медленно и аккуратно. Вот где можно и даже нужно перестраховаться по полной программе, на старте просчитать все риски и четко следовать ТЗ.
Предпосылки к применению Agile
Гибкие методологии, напротив, подходят для динамичных отраслей, в которых технический прогресс мчится, как скоростной поезд. Удачный пример — машинное обучение, где идут постоянные исследования.
Отраслевой фактор актуален для всех гибких подходов, но как выбрать между Kanban и Scrum?
Когда подходит Kanban
Лучше всего он показывает себя для небольших команд и бюджетов. Разбивать на scrum-команды «полтора землекопа» незачем — только запутаете коммуникацию и процессы. Несколько разработчиков, тимлид да проектный менеджер договорятся между собой безо всяких стендапов и спринт-ревью. Кстати, так и получилось в ходе вышеописанной разработки криптокошелька.
Тот пример показателен еще и в плане типа создаваемого ПО. Методики Kanban и Times and Materials оптимальны при реализации небольших разовых проектов для узких сегментов рынка — разработке несложного отраслевого приложения, трекера и т. д. Изменения «на лету» здесь обычное дело, но они не столь глобальные и многочисленные, как при создании корпоративной CRM-системы. Дробить все это на итерации — лишь усложнять себе жизнь. Команде вполне хватит Kanban-доски, чтобы эффективно управлять задачами.
Когда подходит Scrum
Применение Scrum оправдано, если команда растет, а отдельный проект превращается в полноценный продукт, который присутствует на рынке долгое время и приносит бизнесу ощутимый доход. Продукт развивается, а пользователи постоянно дают обратную связь, которая нуждается в обработке.
Допустим, у службы поддержки банковского приложения все время спрашивают, когда появится поддержка новой системы переводов. Становится понятно, что такая фича назрела. Можно смело планировать ее доставку пользователям, назначать дату релиза, делать из этого PR-событие. В таких ситуациях Scrum помогает справиться с растущим объемом изменений на основе фидбека. При помощи спринтов обеспечивается достаточный уровень планирования, чтобы не хвататься за все подряд.
Scrumban: срединный путь
Некоторые управленцы пытаются сгладить шероховатости традиционных методологий при помощи гибридных моделей. Эта тенденция началась с микширования Waterfall и Agile, но потом «селекционеры» отважились на скрещивание гибких подходов. У нас в Magnus Tech довольно высокую эффективность показала система с говорящим названием Scrumban.
Суть метода заключается в скрамовской работе спринтами, в ходе которых используется Kanban-доска. На ней фиксируются и приоритизируются запланированные на итерацию задачи.
Таким образом, свобода и гибкость Kanban отчасти уравновешивается правилами Scrum. Разработчики не распыляются между тасками и не берутся за все подряд. При этом в границах спринта можно гибко распределять задачи, корректировать загрузку по ситуации. То, что несложно изменить сразу, тут же идет в графу «открыто» на Kanban-доске и берется в реализацию. Более трудоемкие задачи улетают в следующий спринт. Присутствуют и традиционные стендапы, спринт-ревью и другие установочные встречи, которые помогают лучше координировать действия и дают командообразующий эффект.
Конечно, здесь свои издержки, ведь, наряду с достоинствами, Scrumban унаследовал и слабые стороны «родителей». Поскольку «фривольный» Kanban не заботят такие детали, как размеры команд, участие стейкхолдеров в процессе разработки и распределение ролей, то здесь слово дается Scrum со всеми вышеупомянутыми недостатками.
К тому же этот гибридный подход крайне чувствителен к любым пробелам в планировании. Следовательно, PM и аналитикам приходится прикладывать немало усилий по поддержке актуальной roadmap проекта. Только так реально отследить, в какой момент пора браться за ту или иную функциональность в соответствии с заданными стейкхолерами приоритетами.
На всякий случай подчеркну, что «укладывать» функциональности в roadmap следует с осторожностью, учитывая фактическую производительность команд, человеческий фактор (больничные, отпуска и т. п.). Если обратиться к схеме выше, то видно, что иной раз важная функция передается из дизайна в разработку в пределах одного спринта. Но надеяться, что так будет всегда, наивно, ведь обстоятельства могут складываться по-разному.
Когда подходит Scrumban
Подобный гибридный подход «выстреливает», если у ПО еще немного пользователей, но впереди большой объем работ по функциональности. Другими словами, между MVP и полноценным мажорным релизом — на стадии активной разработки объемного проекта. В начале пути в методологии будет преобладать Kanban, в то время как спринты могут иметь упрощенный вид. Но по мере развития продукта фокус сместится в сторону Scrum, поскольку обратной связи станет больше, а горизонт планирования расширится. Соответственно, гибкость разработки несколько уменьшится, зато появятся гарантии своевременной доставки фич пользователям.
Готовые советы из интернета вам не помогут
Waterfall |
Kanban |
Scrum |
Scrumban |
Низкая динамика и консервативность рынка |
Инновационность и высокая динамика рынка |
||
Участие в государственных тендерах |
Небольшие команды и бюджеты разработки |
Команды и бюджеты растут |
|
|
Разовые проекты для узких сегментов рынка |
Полноценный продукт, который приносит доход бизнесу |
Проект постепенно превращается в полноценный продукт |
Если обобщить вышесказанное, то Kanban лучше подходит для локальных и небольших проектов, Scrum — полноценных продуктов, а Scrumban — проектов, постепенно переходящих в продукты.
Однако эти предпосылки для применения разных методологий — это не закон, а наблюдения на основе нашего проектного опыта. Конечно, есть те самые пресловутые исключения, подтверждающие правила. Допустим, локальный проект с крохотной командой может реализовываться по водопадной модели, если этого требует консервативный госзаказчик.
Поэтому любые готовые рекомендации по внедрению и применению методологий разработки стоит пропускать через призму самоанализа, примерять на себя, отбирая лучшие практики и вырабатывая такую методику, которая будет хорошо работать в конкретном случае. В продолжении этой статьи как раз поговорим про самые сложные проблемы методологий разработки, которые стоит попытаться решить в первую очередь.
А сейчас давайте обсудим в комментариях, какие методы и подходы вы применяете и что хотите в них поменять?
Комментарии (37)
Anatol2007
11.01.2024 09:41+2Понимаю боль автора и сообщества PM, спасибо за структурное изложение мыслей!
Ни Waterfall, ни Agile, ни любая другая существующая методология разработки ПО — не истина в последней инстанции, а всего лишь отправная точка. Это как Open Source: каждый берет нужное и допиливает под свои задачи.
С поправкой на это добавлю от себя. Вроде бы где то писал, но всё же. Была практика в энтерпрайз финтеха такого гибрида:
1) Каскад как брутто бизнес и технических целей, для долгосрочного и краткосрочного планирования (квартал).
2) Канбан внутри квартала по следующим стадиям Инициатива(с согласованием ЛПР)-РазвёрнутоеБизнесТребование - ФункциональноеТребование(Согласованное и оцененное разработкой). Что в последней стадии, то уходит в спринты.
3) Спринты на месяц. Причём с пониманием, что новая фича требует организационных, юридических и других изменений. К примеру, при внедрении расчёта ПДН(показателя долговой нагрузки) и МПЛ(макропруденциальных лимитов) постоянно были качели, т.к. для расчёта в системе базис это Правила расчёта, а чтобы написать эти Правила сильно влияет, можно ли так или иначе посчитать в системе. Такого рода фичи внедрять как раз помогает прямой контакт бизнеса и разработки. иначе можно бесконечно футболить мячики.
4) Внутри такого длинного спринта тоже Канбан с классическими стадиями реализации, вплоть до досрочного переноса в прод автономных готовых фич.
P.S. Да, при этом разумеется, также были форс мажоры в виде переноса в следующий спринт, внеочередных горячих пирожков, фальшстарты и псевдо-фичи(которые в следующем спринте уже были не нужны). Но в целом был тоже интересный и успешный опыт
DewT-Mag Автор
11.01.2024 09:41Интересно, а как вы пришли к этой конструкции, и из каких предпосылок она сформировалась?
Anatol2007
11.01.2024 09:41+1Попытка подружить линейность каскада с "аа,побежали" скрама, ну и плюс безмерная любовь к канбану. Тут стоит добавить, что много лет был больше со стороны бизнеса, поэтому каскад бизнес-целей для их реализации декомпозировался на организационные, операционные и иногда технические задачи. Если из вышеуказанного примера выкинуть уровень со спринтами, то получается вполне обычный бизнес-роадмап, положенный на канбан.
Plamenirium
11.01.2024 09:41+1Основная проблема с agile в том, что он требует перестройки организационной структуры. Невозможно внедрять эджайл, если у вас вертикальная структура управления. Много у нас компаний отказались от роли тимлида? А между тем в scrum нет никаких лидов, есть PO и scrum-мастер. Попытки внедрить эджайл наполовину приводят к поялению псевдоэджайла, а он неэффективен. Об этом в частности пишет Мартин Фаулер.
Myz17
11.01.2024 09:41+3то, что в скраме нет лидов, не значит, что в команде не может быть лидов. Ещё как могут и я бы сказал обязаны быть. И техлиды и тимлиды. Просто в скрам процессах нет такой роли.
Plamenirium
11.01.2024 09:41-1"В Scrum-команде нет начальника, как нет и технического лидера." (с) Клод Обри "Все о scrum"
Myz17
11.01.2024 09:41+2тимлид не начальник, у него другие задачи. Техлида можно явно не выделять, но он всё равно будет. У вас концептуальным проектированием и финальным рецензированием будет один человек заниматься, иначе это просто коллективная безответственность будет.
Plamenirium
11.01.2024 09:41Будет, вот только он будет не назначен, а выбран командой. Хотя "выбран" здесь не точное слово, он просто благодаря своим знаниям получит в команде авторитет естественным путем. Что же касается "других задач", то они распределяются между PO и scrum-мастером. Тимлид просто не нужен, если у вас работающий scrum.
Myz17
11.01.2024 09:41+1Что же касается "других задач", то они распределяются между PO и scrum-мастером. Тимлид просто не нужен, если у вас работающий scrum.
ни PO, ни scrum-мастер не занимаются стратегией развития команды, лидированием процессов, развитием членов команды. Вы забываете, что помимо продуктовых задач, есть ещё деятельность не связанная с разработкой.
Kanut
11.01.2024 09:41Даже если взять тимлидов за пределами скрама, то и среди них отнюдь не большинство занимается тем что вы перечислили.
То есть даже если исходить из того что этим обязательно кто-то должен заниматься,, то это совсем не обязательно должен быть именно тимлид.
Myz17
11.01.2024 09:41+2Даже если взять тимлидов за пределами скрама, то и среди них отнюдь не большинство занимается тем что вы перечислили.
То есть даже если исходить из того что этим обязательно кто-то должен заниматься,, то это совсем не обязательно должен быть именно тимлид.
Вообще понятие функций такой роли как тимлид очень сильно разнится между организациями. Где-то это самый опытный разработчик, но в моём понимании это техлид. Где-то это руководитель команды, но опять же в моём понимании это именно руководитель, а не тимлид. Тимлид - это "капитан футбольной команды", он не просто играет наряду с остальными членами команды, он лидирует игру. Он доносит до команды: кто мы, куда нам надо двигаться, что нам надо сделать, чтобы туда придти.
В рамках проектной работы он управляет бэклогом спринта, мощностью команды, планированием загрузки, разрешением внутренних конфликтов в соответствии с политиками и принципами команды, хранителем и евангелистом которых он является.
Скрам-мастер - это вообще про другое.
Kanut
11.01.2024 09:41Вообще понятие функций такой роли как тимлид очень сильно разнится между организациями.
Как собственно и задачи которые выполняют эти самые тимлиды. Поэтому я и не особо понимаю почему вы выбрали один вариант и считаете его единственно верным.
Тимлид - это "капитан футбольной команды", он не просто играет наряду с остальными членами команды, он лидирует игру.
Это всего лишь один из возможных вариантов. И остальные варианты не менее легитимны.
В рамках проектной работы он управляет бэклогом спринта,
Вы смешиваете всё в одну кучу. Спринт и бэклог это в общем-то артефакты скрама. В скраме тимлида нет.
А то что вы описали в скраме делает команда целиком. И да, это вполне себе работает. Не всегда и не со всеми. Но работает. По крайней мере по моему опыту.
Скрам-мастер - это вообще про другое.
Конечно про другое. Причём здесь вообще скрам-мастер?
Plamenirium
11.01.2024 09:41Если под "развитием команды" имеется в виду обучение, то это задача hr, а не тимлида. Что значит "лидирование процессов"? Каких? Фасилитация это есть первостепенная задача scrum-мастера. Вторая задача это устранение препятсвий. Задача PO давать направление, приоритезировать цели и давать обратную связь по результатам. Чем вы еще хотите покомандовать? Я рекомендую все же ознакомится со scrum и agile глубже, чем участие в конференциях. Литературу там почитать, например.
Myz17
11.01.2024 09:41Если под "развитием команды" имеется в виду обучение, то это задача hr, а не тимлида.
ну положим не HR'а, а скорее RM'а. В его задачи входит обеспечение развития сотрудника - найти курсы, выбрать ментора. А кто определяет, что именно должен изучить сотрудник? Он сам? Гораздо лучше, если это определяется на one-2-one с тимлидом, где лид расскажет, что у нас есть проблемы с производительностью продукта (условно) и неплохо бы актуализировать нагрузочные тесты, но сейчас для этого в команде не хватает компетенций. И предложит сотруднику пройти доп.обучение по нагрузочному тестированию.
Что значит "лидирование процессов"? Каких? Фасилитация это есть первостепенная задача scrum-мастера.
причём тут фасилитация? Возникла в команде потребность что-то сделать не в рамках разработки фич, например те же нагрузочные тесты сделать. Скрам мастер будет в команду тыкать и искать, кто сделает? А потом проверять будет? Я для вас может открытие сделаю, но скрам-мастер обычно вообще не является членом команды, традиционно он ведёт несколько команд.
Чем вы еще хотите покомандовать?
Командой. Не логично?
Я рекомендую все же ознакомится со scrum и agile глубже, чем участие в конференциях. Литературу там почитать, например.
А вам я рекомендую не делать поспешных суждений о других. Я уже больше 20 лет команды в работу организую. И XP внедрял и аджайл и скрам. Я практик, а не теоретик, как многие скрам-мессии.
Homyakin
11.01.2024 09:41+1имеется в виду обучение, то это задача hr
Но погодите, ведь hr тоже нет в скраме. Там есть ПО, разработчик и скрам-мастер.
Мне кажется, что ситуация, когда все равны, возможна в условной команде где все "синьоры" с примерно одинаковым опытом работы. Тогда у них примерно одинаковые навыки, знания о продукте и никто им не нужен.
Но в реальном мире существуют джуны, мидлы, новички. Им нужен онбординг, нужен более тщательный присмотр в каких-то аспектах, нужно как-то строить их план развития. Да даже синьорам нужно развитие и его должен кто-то направлять.
И как не назови человека, который будет этим заниматься, его уже нет в скраме.
Kanut
11.01.2024 09:41Но погодите, ведь hr тоже нет в скраме.
Бухгалтера тоже нет в скраме, но бухгалтерией всё равно кто-то занимается. Скрам это не о том как организовать фирму в целом. Это конкретно о процессе создания продукта.
С точки зрения скрама(как впрочем и водопада и всех известных мне подходов) абсолютно ортогонально как вы там у себя организовали "процесс развития" и организовали ли вы его вообще.
Мне кажется, что ситуация, когда все равны, возможна в условной команде где все "синьоры" с примерно одинаковым опытом работы.
Вообще-то в скраме совсем не обязательно все должны быть равны. То есть определение скрама этого не требует. Скрам ожидает что члены команды не являются узкими специалистами. Чтобы при необходимости всегда можно было подменять друг-друга. Но это не означает что все равны и даже не означает что все должны одинаково хорошо во всём разбираться.
Plamenirium
11.01.2024 09:41-1безответсвенность будет
Это одна из причин, которая мешает внедрению scrum в РФ. Вы не верите в самоорганизацию и нанимаете людей экспертизе которых не доверяете. Зачем нанимаете тогда?
Myz17
11.01.2024 09:41+1Это одна из причин, которая мешает внедрению scrum в РФ. Вы не верите в самоорганизацию и нанимаете людей экспертизе которых не доверяете. Зачем нанимаете тогда?
Вы невнимательно читаете, либо не понимаете смысл термина "коллективная безответственность". Никто не сомневается в экспертности команды. Но если вы думаете, что каждый в команде является и техническим спецом и лидером, то сильно ошибаетесь. Ответственность всегда должна быть персональна.
Plamenirium
11.01.2024 09:41-1Ответственность за что? За решения? Что вам даст персональная ответственность за решения? Моральное удовлетворение за то, что вы накажете человека, когда он ошибется? Не нужно быть техническим спецом во всем, для этого в scrum-командах существует практика привлечения экспертов. А у вас лиды то есть, которые шарят вообще за все интересно?
Myz17
11.01.2024 09:41+1Ответственность за что? За решения? Что вам даст персональная ответственность за решения? Моральное удовлетворение за то, что вы накажете человека, когда он ошибется?
ответственность - это не про наказание, это про то, кто за результат отвечает.
Не нужно быть техническим спецом во всем, для этого в scrum-командах существует практика привлечения экспертов. А у вас лиды то есть, которые шарят вообще за все интересно?
а кто говорит о техническом спеце-универсале? Например в моей команде тимлид не является техническим экспертом. Для этого у нас два техлида есть.
Plamenirium
11.01.2024 09:41-1Если вы не верите, что команда может отвечать вместе за то, что они делают, то agile и в частности scrum для вас плохой выбор. Это буквально суть agile. Если вы не отказываетесь от микроменеджмента и при этом просто внедряете ритуалы то вы получите псевдоэджайл и зомби-скрам.
Myz17
11.01.2024 09:41+2Если для вас это трудно, воспринимайте термин "отвечать за результат" буквально - иметь возможность вербально что-то ответить. Для простоты. Команда сделала что-то, получила результат. По этому результату возникли вопросы. Кто будет отвечать на них? Команда не может, у неё нет рта. Или вы думаете, что при получении вопроса, команда уходит на обдумывание, а потом один такой выходит и говорит "Отвечать на вопрос будет Друзь"?
Понятно что за артефакты спринта ответственность на всей команде. Но внутри команды есть люди, которые приняли те или иные решения. Есть решения технические - их приняли техлиды. Есть решения организационные в рамках процесса разработки, их возможно принял скрам-мастер. Есть другие решения по работе (например решили в рамках спринта поменять приоритет задач), развитию (решили выделить время на изучение новых инструментов), внутрикомандные (развернуть ещё один тестовый стенд, увеличить покрытие модульными тестами, сделать новый автодеплой). Всегда есть человек, который принимает итоговое решение и он же за него отвечает, а не абстрактная команда.
К слову, роль скрам-мастера вообще не обязательна для скрама. Со временем команда начинает работать без его помощи и фактически функции мастера переходят к человеку внутри команды. Обычно это и есть тимлид.
Kanut
11.01.2024 09:41-1это про то, кто за результат отвечает.
И что это означает в вашем понимании? То есть вот есть Вася и он отвечает за результат. Результат не достигнут. Дальше что?
Stan88
11.01.2024 09:41+2Что значит дальше что? Именно Вы отвечаете за результат вашей работы. Деньги любым наемным сотрудникам, коими разработчики также являются, платят именно за результат, а не за общественные деяния. Результат может быть негативным, промежуточным, позитивным и так далее. Но он обязательно должен быть, и за то каким он будет несете ответсвенность именно Вы.
Мне всегда интересно было почему во всех других отраслях есть и персональные задачи, и ответсвенность, и планирование и даже относительное нормирование выполняемых работ - одни айтишники все еще считают себя помазанниками божьими (хотя судя по развитию ИИ и кризису отрасли многим таки придется изменить текущее мнение). Я лично видел как организована работа инженеров-конструкторов, АСУТПшников, математического моделирования и других - нигде такого бардака как в айти и близко нет. И если вы со всеми этими скрамами и аджайлами попали в небольшую, сработанную и ответственную команду - не забывайте угащать их коффе по утрам с круасанами!!! Ибо по больше части отношение к общему делу с общей ответсвенностью зачастую заканчивается общей задней точкой.
И тут совершенно не играет роль талант, опыт, софт скилы и прочее. Сто раз видел прекрасных и толковых разработчиков, которые десятку инженеров фору дадут, но пока их не пнешь делать они ничего не будут.
Kanut
11.01.2024 09:41Что значит дальше что?
То и значит. Вот результат не достигнут. Что будет дальше? Денег не заплатят? Уволят? Что конкретно должно случиться по мнению моего оппонента?
Мне всегда интересно было почему во всех других отраслях есть и персональные задачи, и ответсвенность, и планирование и даже относительное нормирование выполняемых работ
Потому что иногда это есть, а иногда нет. В других отраслях тоже бывают разные виды организации процесс.
И в ИТ скрам тоже не всегда используется. И когда он используется, то делается это не просто по приколу.
Сто раз видел прекрасных и толковых разработчиков, которые десятку инженеров фору дадут, но пока их не пнешь делать они ничего не будут.
И? Ну значит не подходят они для скрама. Как будто инженеры все поголовно ответственные...
Newbilius
11.01.2024 09:41+1Ответственность - это, например, про "за кем последнее слово" в случае спорной ситуации, про право вето и право принимать решение)
Yuriy_75
11.01.2024 09:41Я бы даже сказал - лидерство. Лидерство ведь не про то, что лидер принимает все решения сам. Это скорее про то, что в спорной ситуации нескольких мнений есть тот, кто может быстро сделать выбор.
Ну а в скрам единственный выделенный лидер - это PO. Который в основном отвечает за коммуникации с заказчиком и не является техническим специалистом. Поэтому, с точки зрения технических деталей: какую архитектуру и какие средства разработки использовать, какие требования к коду - все это отдано на откуп команде.
А тут либо появляются неформальные технические лидеры, с которыми команда согласна, либо бесконечные заседания без возможности выработать результат.
Thisnicknameisbusy
11.01.2024 09:41+1PMBOK почитайте
domr
11.01.2024 09:41Читали. Сложилось впечатление, что авторы пишут про строительство атомной станции с нуля или пилотируемую миссию на Юпитер. Возможно плохо читали, тогда поделитесь своим видением решения проблем, описанных в статье)
Anatol2007
11.01.2024 09:41Ну так с этого же автор вроде и начал, что Waterfall (а о чистом нём как раз и PMBoK), не догма, а сборник бест-практикс, как рекомендаций, а не пошаговая инструкция, от которой нельзя отступиться. И для длинных тяжёлых проектов это отличная практическая методология, чтобы добежать вообще для финиша. А если у Вас проектик по созданию сайта на дюжину страниц с одной интеграцией с каким нибудь лидогенератором, то Вы будете ли, как пример, сосредоточенно матрицу рисков вести или критический путь рассчитывать?
Mike-M
11.01.2024 09:41+2Судя по статье получается, что недостатков меньше всего у Waterfall. Личный опыт участия в различных проектах это подтверждает. Да и невысокое качество современного ПО тоже.
Gryphon88
11.01.2024 09:41+2По моему опыту, в водопаде получается наилучший анализ, потому как на этапе написания ТЗ волей-неволей приходится собрать всех необходимых экспертов у заказчика и разобраться, а что же надо сделать и как оно в итоге должно работать. В гибких методологиях по идее должен быть в быстром доступе представитель заказчик, но он один, часто неинформирован, не заинтересован или не уполномочен принимать какие-то решения, в итоге его фидбек имеет очень низкую ценность и качество продукта зависит от усилий аналитика и внутренней экспертизы.
DewT-Mag Автор
11.01.2024 09:41+1Кстати, если взять срез по научным статьям, то там тоже прослеживается такая закономерность. Возможно это разновидность ошибки выжившего. Мы вот чаще работаем по Agile и все эти проблемы очень знакомые, а болячки Waterfall не такие натоптанные. Так и в литературе - в последние годы все носятся с гибкими методологиями, а тема каскадной остается недораскрыта.
newintellimouse
В каскадной модели есть менеджмент изменений к требованиям. Остановка, внесение изменений в требования, изменение задания, составление дополнительного задания на изменение затронутых ранее разработанных модулей, переоценка сроков и бюджета (с согласованием), продолжение реализации по изменённому плану. Но этот инструмент кажется заказчику очень дорогостоящим, поэтому менеджер проекта часто стесняется его применять.
DewT-Mag Автор
Это применяется так редко, что просто забываешь, что он есть xD
lamerok
На самом деле, есть еще такое понятие как Configutation Change Management, где ты управляешь изменениями, в том числи и в каскадной моделе. Ты просто заносишь запрос на изменения (на любом этапе) в систему управления изменениями, а Configuration Change Team (разных уровней) её потом либо апрувит, либо отклоняет, это позвляет внести изменения на любом этапе в любой артифакт предущих этапов.
Просто придется менять дофига всего (скажем если вы находитесь на этапе Implementation, а поменять надо требования, то придется менять требования, дизайн, код), но для этого Configuration Change Team и существует, чтобы все риски и расходы по этому изменению определить и в случае его дороговизны - отклонить либо принять, если изменения незначительные.