О чем это и для кого
Фреймворк Scrum практически с момента своего появления и до сих пор вызывает споры о границах применимости, получаемых выгодах и рисках.
В данной заметке описаны ограничения и допущения в использовании этого подхода, предварительные условия, какие риски могут возникнуть, где Скрам будет уместен и где его точно не стоит применять.
Думаю, что для опытных менеджеров и Скрам-мастеров здесь не будет ничего нового, материал пригодится скорее начинающим Скрам-мастерам или разработчикам, работающим по Скраму.
Easy to learn, hard to master
Философия Agile (назовём это так для простоты) вызвала достаточно оживленные обсуждения почти сразу после своего появления в 2001 году, и долгое время Agile ассоциировался в основном с фреймворком Scrum. В общем это актуально и сейчас, т. к. второй по популярности Канбан метод в 2015-2017 вышел из под крыла Agile и стал развивать концепцию Business Agility, а другие подходы, такие как EP, DSDM, FDD, менее распространены.
Как основной представитель Agile, фреймворк Скрам тоже поднял большую волну хайпа. Которая, судя по комментариям на Хабре, не улеглась до сих пор. В самом начале его популярности на применении Скрама часто настаивали разработчики. Подход считался новым и передовым, этакой серебряной пулей в индустрии разработки. Программисты были счастливы наконец избавиться от "бесполезных паразитов-менеджеров" в команде, долгих совещаний с рисованием WBS и диаграмм Ганнта, анализа рисков и вот этого вот всего. Cейчас кажется, что значительная часть разработчиков разочаровалась в Скраме и перешла в оппозицию, дискутируя со Скрам-мастерами, Agile-коучами, менеджерами, которые пытаются перевести свои команды на Скрам рельсы.
Зачастую менеджеры на старте проекта вынуждены выбирать метод управления из тех, которые сейчас на слуху (чаще всего это Скрам, Канбан, классический PMI / PRINCE2). Но менеджеры часто не обладают достаточным опытом и знаниями о методологиях, их преимуществах и недостатках. А ведь из всех перечисленных подходов Скрам наиболее революционный и бескомпромиссный. Он меняет устоявшиеся принципы работы в компании. Он не принимает существующие структуры и процессы, и жестко устанавливает свои.
О преимуществах, которые может дать работа команды по Скрам, сказано уже очень много. Но во вселенной Agile и Скрам не принято открыто говорить об ограничениях этого подхода. А именно - где вообще можно применять Скрам, а где делать этого не стоит, какие допущения и ограничения есть у этого подхода, каким требованиям должны удовлетворять проект и команды чтобы успешно работать по Скрам, какие есть риски и т.п.
Попробуем разобраться в этом вопросе со следующими оговорками:
говорим только о Скрам и частично о философии Agile, каковую Скрам представляет. Другие методологии (Kanban, XP, DSDM, FDD, Crystal, etc) не рассматриваем.
говорим о применимости Скрам в основом в пределах "классической Скрам команды" — 7-9 человек. Масштабируемые гибкие методологии, как то SAFe, LeSS, Nexus и т.п. не рассматриваем, там свои преимущества и недостатки, и Скрам там обычно только на нижнем уровне, выше начинается Канбан.
данная статья не ставит своей целью критику или обесценивание Скрам как такового — это отличный подход, но только там, где он уместен.
Scrum — это не метод управления проектами
Ключевые слова — "управления проектами". Что такое проект? Это деятельность, связанная с сочетанием конечности (имеет начало и конец, ограниченность ресурсов) и высокой доли неопределенности (включая уникальный результат работы).
Скрам хорошо работает с неопределенностью — короткие итерации со сбором обратной связи, вовлечение заказчика, постоянная рефлексия. Но он ничего не хочет знать о конечности — ограничения сроков, бюджета. Скрам не умеет контролировать попадание в "проектный" треугольник Time - Budget - Scope, фактически он фокусируется только на удовлетворенности заказчика. Даже про контроль состояния команды в Скраме вообще ничего нет - считается что она сама себя умеет организовать и мотивировать.
Да, формально авторы и не позиционируют его как метод для управления проектами. Скрам заявлен как фреймворк, то есть каркас основных принципов и инструментов, наполняемый любым удобным команде содержимым. Скрам хорошо применим в определенных условиях для управления задачами в разработке программного обеспечения. При переходе на Скрам вместо каких-то имеющихся в компании практик, важно помнить что он не покрывает полный спектр задач по управлению проектом, он вообще не предназначен для этого. Есть целые области знаний, которые Скрамом управляются плохо или не управляются вообще - риски, мотивация команды, долгосрочное планирование, контроль персональной производительности членов команды. Не говоря уже о таких вещах, как например закупки.
Вывод: не отдавайте всё управление на откуп Скраму, он этого не умеет. Scrum — это не инструмент менеджмента, а способ организации рабочих процессов для продуктовой разработки.
Scrum — продуктовый подход в разработке ПО
Несмотря на то, что в руководстве по Скраму авторы пишут:
Руководство по Скрам 2017 года
Скрам – это фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов.
Руководство по Скрам 2020 года
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем....Мы следим за тем, как Scrum все больше используется в постоянно растущем комплексном мире. Мы приятно удивлены, как Scrum применяется не только при разработке программных продуктов, для которой он изначально создавался, но и во многих других областях, где выполняется комплексная работа. По мере распространения Scrum помогает выполнять работу разработчикам, исследователям, аналитикам, ученым и другим специалистам.
— есть очень много комплексных проблем, где Скрам применим ограниченно или не применим вовсе. В аутсорсинговой разработке очень часто клиенты хотят контракты по модели Fixed Price — в этом случае использование Скрам очень рискованно. Даже при работе по модели Time&Material клиент должен понимать, какие риски несёт работа по Скрам — отсутствие четких планов по бюджету и длительности проекта, очень высокие требования к специалисту в роли Владельца Продукта (очень часто это сотрудник со стороны заказчика), очень высокая степень вовлеченности заказчика (не все этого хотят и к этому готовы), полная немасштабируемость подхода (хотя для этого есть SAFe, LeSS и т.п.), невозможность работы паралельными связаными потоками работ, достаточно высокие накладные издержки на "планирование и перепланирование", слабый контроль рисков в работе. Скрам плохо подходит для организации работы внутреннних отделов — поддержка, юристы, маркетинг.
Вывод: Скрам хорошо подходит для разработки новых продуктов в области программного обеспечения. И очень ограниченно подходит для аутсорсинговых проектов, тем более не софтверных.
Scrum ничего не знает о дедлайнах или фиксированном бюджете
Как уже сказано выше, Скрам не умеет следить за попаданием в классический проектный треугольник.
Это делает затруднительным его применение например в Fixed Price проектах, либо проектах с жесткими дедлайнами. Даже при продуктовой разработке конечный заказчик часто хочет знать, когда будет готово и сколько в итоге будет стоить.
Что отвечает Скрам?
"А вам и не нужно это знать"!
По мнению авторов подхода, необходимость точного прогнозирования вытекает из высоких рисков неопределенности — то ли заказчик получит в итоге, что он просил? И Скрам предлагает другое решение — короткие итерации и демо результата (причем, что важно - рабочего инкремента, полезного заказчику уже сейчас). Таким образом заказчик уверен что разработка движется в целом туда, куда ему нужно (максимум потеряем один спринт — поэтому они должны быть как можно короче), и довольно грубо может оценить сколько времени еще осталось на "переваривание" всего имеющегося бэклога.
Тем не менее, далеко не каждого заказчика на вопрос:"Сколько нужно времени / денег?" устроит ответ: "Заранее сказать невозможно, давайте попробуем и посмотрим, как пойдёт".
Вывод: Скрам плох в прогнозировании. В работе с жесткими ограничениями (бюджет, сроки) его применение рискованно.
Scrum — инкрементальный подход (мост по Скраму не построить)
Поставка ценности небольшими полезными заказчику инкрементами возможна не всегда. Есть проекты где продукт нужен целиком, частично он или бесполезен (булочка вместо хотдога) или невозможно постепенно наращивать функционал (известный слайд из рекламы Скрама про самокат - велосипед - мотоцикл - автомобиль).
Тут нужно учесть аспект, что даже если какой-то завершенный инкремент в конце спринта можно отдать заказчику, это должен быть полезный и применимый результат работы — без этого не получится собрать действенную обратную связь.
Пример — разработка электроники. Да, мы можем в конце спринта отгрузить клиенту принципиальную схему, или конструкторскую документацию на печатные платы, или отчет о тепловом моделировании. Насколько полезный для дальнейшей работы фидбэк можно собрать? "Ну мы посмотрели, вроде всё ок"? Всё Ок или не Ок в любом случае можно понять, только получив готовое устройство на руки и проведя тестирование. Поэтому даже если внешне это может выглядеть как Скрам, по сути таковым оно часто не является, если нет ценного, полезного инкремента в каждом спринте.
Вывод: перед началом проекта нужно проверять, возможно ли поставлять инкрементами что-то полезное заказчику и получать с этого обратную связь для коррекции работ.
Scrum — командный подход
Что такое Scrum-команда
Scrum Team привержена своим целям и поддержке друг друга. Их важнейшим фокусом в работе в Sprint является максимально возможный прогресс в достижении целей. Scrum Team и заинтересованные лица открыты к обсуждению работы и вызовов. Участники Scrum Team уважают друг друга как профессионалов и независимых людей, и точно так же их уважают люди, с которыми они работают. Участники Scrum Team обладают смелостью поступать правильно и работать над решением сложных проблем.
Для ускорения принятия решений и достижения наилучших результатов Скрам делает ставку на командный подход. Подход выделяет лишь три роли — Владелец продукта, Скрам-мастер и команда. Причем Скрам-мастером может быть один из разработчиков. Не допускается никакая структура или иерархия внутри команды.
Чтобы Скрам заработал, нужна высокая степень вовлечённости всех участников команды — ВП, СМ и разработчиков. Ответственность за результат коллективная, поэтому управленческие решения принимаются совместно всей Скрам-командой, а не каким-то одним руководителем или менеджером.
Аналогичным образом все встречи в Скраме рассчитаны на активное вовлечение всех участников команды и коллективное принятие решений. Каждая встреча Scrum нацелена на одно из двух:
координация работы команды (дейли встречи, планирование, обзор спринта),
развитие командного взаимодействия и взаимопомощи, опыта или навыков команды (ретроспектива)
Руковоство по Скраму прямо говорит, что для успешной работы вам нужна сплоченная, самоорганизованная и вовлеченная в работу команда. Команда (!) а не просто группа разработчиков, объединённая одним проектом. Чем отличается команда от рабочей группы можно легко найти в гугле, например https://asana.com/ru/resources/group-vs-team
Исходя из целей встреч в Скраме, одна из важных компетенций — это навык фасилитации встреч. Фасилитация — это умение так организовать обсуждение вопроса, чтобы все члены команды смогли высказаться, услышать и понять друг друга, выбрать наилучшее решение и при этом остаться в рамках продуктивности и в хороших отношениях.
Пару рекомендаций на этот счет
Есть специальные техники проведения встреч с вовлечением всех участников, например Liberation Structures — https://www.liberatingstructures.com или на русском https://liberating-structures.ru Также могу посоветовать книгу Лиссы Аткинс "Коучинг Agile команд"
Все метрики в Скраме тоже собираются только в отношении команды, никакого персонального perfomance или velocity. И поскольку в реальной жизни в команде все время происходят какие-то изменения — увольнения / найм новых сотрудников, отпуска, отгулы, болезни и т.д., то основной показатель работы velocity (мощность команды, какой объём работы в условных story points она может "съесть" за один спринт) — тоже редко остается стабильным в команде из 7-9 человек. Это к вопросу выше о планировании в Скраме.
Отдельный вопрос — о лентяях и "токсичных" людях в команде. Предполагается что команда сама вытолкнет таких паразитирующих личностей из коллектива, что на практике бывает крайне редко, либо может занять продолжительное время (вспоминаем модель Брюса Такмана и 5 пороков команды Патрика Ленсиони). Нужен менеджер, который будет разруливать такие вопросы, а никаких менеджеров в Скраме, как мы помним, нет.
Вывод: Скрам требует наличия сплоченной самоорганизованной команды. Нужно заранее продумать, есть ли она, или как её планируется создать.
Scrum опирается на кросс-функциональную команду
Кросс-фунциональная — означает, что
... члены команды обладают всеми навыками, необходимыми для создания ценности в каждом Sprint. Также они самоуправляемы, то есть сами решают, кто, что, когда и как делает.
Что на практике это должно значить: каждый член команды должен уметь и бизнес-анализ провести, и дизайн нарисовать, и код написать, и потестить; или команда должна включать в себя всех необходимых специалистов — руководство по Скраму ответа на даёт. Но такие мульти-функциональные специалисты если и есть, то мне никогда не встречались. Действительно кросс-функциональная команда — редкость. В жизни бывает что команда состоит только из разработчиков, а QA / UI/UX / DevOps — это другие команды, или структурные «подкоманды», которые в Скраме делать нельзя.
Включение же в команду всех ролей — BA, UI/UX, Dev, QA — тоже имеет определенные особенности работы. Все они не могут одновременно работать над одними и теми же задачами, чаще всего последовательность — BA -> UI -> Dev -> QA. И сложно организовать работу всех внутри спринта так, чтобы Скрам-команда не разбилась на несколько подкоманд внутри, или спринты не разделилиь на паралельные потоки для бизнес-анализа, разработки, тестирования, что тоже противоречит идее Скрама.
Важно также не забывать, что Скрам требует привлечения специалистов на 100% загрузки. Для разработчика совмещать работу в нескольких Скрам командах — плохая идея.
Вывод: Перед началом проекта проверить действительно ли кросс-функциональна команда, либо найти способ обойти это (напр. замена QA автотестами, вовлеченность команды в планирование с PO — аналитик не нужен).
В Scrum достаточно высокие накладные расходы на "церемонии"
Главный принцип Скрама — работа как можно более короткими итерациями (спринтами) с поставкой и сбором обратной связи от заказчика. Короткие спринты уменьшают потери в случае разработки не того или не так, как нужно клиенту. Но есть и тёмная сторона работы короткими (например недельными) спринтами. При спринтах длительностью в одну неделю слишком высокие накладные расходы на церемонии: планирование + дейли + демо + ретро + бэклог груминг = 1.65 дня при недельном спринте — почти 30% всего рабочего времени!. При двухнедельном спринте накладные расходы составляют около 18ч с учетом работ по уточнению бэклога. Возможно, это не совсем то, что вы ожидали увидеть, когда читали что в Скраме "нет долгих митингов по планированию".
Вывод: Скрам поощряет работу короткими спринтами для быстрой адаптации к меняющимся требованиям, но слишком короткие спринты (одна - две недели) влекут за собой достаточно высокие накладные расходы на обязательные церемонии Скрам.
Scrum не масштабируется на большие команды, и не умеет управлять паралельными потоками связанных работ
Скрам by design может работать только на уровне небольшой команды — как правило, 7–9 человек максимум. Также нет смысла пытаться работать по Скрам, когда у вас в команде только 1-2 человека (Владелец продукта и Скрам-мастер не учитываются при определении размера команды), и больше никто не задействован в работе над продуктом. Скрам в такой ситуации будет явно избыточен. Два человека и так легко договорятся, и какого-то специального процесса для этого не требуется.
Руководство по Скрам о размере команды
Оптимальный размер Команды Разработки достаточно мал, чтобы команда оставалась гибкой, и достаточно велик, чтобы выполнять значимую работу за время Спринта.Когда в Команде менее трех человек, взаимодействие и производительность снижается. Небольшие Команды Разработки могут столкнуться с проблемой нехватки навыков для создания готового к выпуску Инкремента Продукта. Команды размером более девяти человек испытывают трудности с координацией работы. Сложность работы в больших Командах Разработки возрастает настолько, что эмпирический процесс становится неприменим.
Скрам, в первую очередь, делает ставку на ускорение и упрощение коммуникации между людьми, а также умение договариваться. Поэтому главные трудности применения Скрам на большом масштабе связаны именно с этими аспектами.
Чтобы преодолеть эти трудности на большом масштабе, приходится применять "общую" фасилитацию, проводить громоздкие и долгие встречи (например, Big Room Planning в SAFe), чтобы все Скрам-команды успели обсудить и спланировать совместную работу, синхронизировать дальнейшие цели и контекст работы.
Так как у каждой команды своя собственная Скрам-доска и свой бэклог (в идеале PBI в бэклоге должны быть сформулированы по приницпу INVEST, то есть в т.ч. независимы), то в процессе общей работы над частями большого продукта нужны регулярные синхронизирующие встречи (например, Scrum of Scrums или PO Sync), на которые будут приходить представители от команд (Скрам-мастера́ или Владельцы Продуктов).
Вывод: при работе нескольких команд над одним продуктом Скрам как таковой уже не подходит, применяются другие подходы - SAFe, LeSS.
Сторонники Scrum скупы на критику
В Agile-вселенной вам никогда не скажут «Здесь Скрам подходит, здесь — нет». Там обычно пытаются натянуть сову на глобус и как-то прилепить Скрам всегда и везде. Во многом это обусловлено чрезмерным хайпом на тему гибких методологий, приведшим в индустрию множество людей со стороны, без технического бэкграунда, без опыта в разработке ПО, да и без нужных софт-скиллов зачастую тоже. И явно заинтересованных в продвижении именно этого подхода.
На Западе Agile–коуч, как правило, специалист с 15-20-летним опытом работы в области разработки ПО или управления разработкой, с большой "насмотренностью" и устойчивостью к повторениям "ошибок выжившего".
На нашем рынке — обычно позитивный молодой человек / девушка лет 25-28 плюс минус, чаще всего с гуманитарным образованием и недельным курсом Скрам-мастера в багаже. Эти люди понимают, что востребованы они только до тех пор, пока популярен Скрам на рынке.
Вывод: придется во всем разбираться самому, на помощь со стороны сильно не надейтесь.
Scrum побуждает к привлечению внешних специалистов — Скрам-мастеров и Agile коучей
Авторы подхода не скрывают, что Скрам прост в изучении (всего 16 страниц в последней версии руководства), но сложен в применении. Если у вас нет опытных Скрам-мастеров или специалистов по Agile, обычно ненавязчиво рекомендуется привлечь стороннего специалиста.
Про неопытных Скрам-мастеров, которые могут в рекордно короткие сроки вывести из себя всю команду, сказано выше. Опытные Agile коучи - обычно довольно дорогие спецы, и при этом по определению не несут никакой ответственности за конечный результат. Он задает правильные вопросы и подталкивает вас к правильным ответам — но если ответы оказались не такими уж и правильными, придраться не к чему. Вы же сами пришли к таким решениям.
Всё это слишком напоминает классическую воронку инфобиза:
Этап 1 — низкий порог входа, простые понятные принципы/инструменты.
Этап 2 — короткий, недорогой тренинг, где расскажут, что делать.
А вот КАК делать, вам расскажут на Этапе 3 — весьма дорогостоящий платный консультант, на этом этапе основные деньги и делаются.
Вывод: у Agile коуча всегда много вопросов и нет ответов.
Высокие требования в Scrum к Владельцу Продукта (Product Owner)
Скрам не предусматривает достаточный по времени этап сбора и анализа требований. Откуда они возьмутся, как правильно оценить их взаимосвязь, влияние на бизнес, выставить приоритет — ответов Скрам не даёт. Для всего этого есть роль Владельца продукта, который должен одновременно работать с заказчиком и командой, сочетать в себе аналитика, представителя бизнеса и маркетолога. Много вы встречали людей с таким набором компетенций?
Повезёт, если это будет представитель со стороны заказчика. Но это своего рода читерство — единственную роль с ответственностью за результат мы передали заказчику. Заказчик редко и ТЗ внятное самостоятельно написать может, а тут полная ответственность за продукт.
Привлечь с рынка готового специалиста тоже не получится — ему потребуется довольно длительное время чтобы понять бизнес клиента и ваши процессы.
Вывод: без толкового Владельца продукта процесс не полетит. А найти такового очень непросто.
Резюмируем сказанное
Скрам — не для управления проектами. Многие аспекты управления остаются вне его рамок. Это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов.
Основные преимущества Скрама проявляются в разработке инновационных продуктов на быстро меняющемся рынке.
Скрам плохо подходит для разработки с ограничениями по срокам или бюджету. Он вообще довольно плох в планировании.
Скрам подходит только там, где возможна поставка ценности заказчику небольшими работающими полезными инкрементами.
Скрам это командный подход, что означает высокую степень вовлечения всей команды, коллективное принятие решений и коллективную ответственность.
Команда должна обладать автономностью и быть кросс-функциональной — то есть включать все роли для создания инкремента за спринт.
Несмотря на то, что долгосрочного планирования в Скраме нет, в реальности при коротких спринтах (одна-две недели) могут быть довольно высокие накладные расходы на обязательные церемонии.
Скрам работает только в командах 3-9 человек, он не масштабируется ни вниз ни вверх.
Скрам не самокритичен, и его сторонники тоже не особо склонны говорить о ограничениях подхода.
Подход неявно подталкивает к привлечению внешних (довольно дорогостоящих) консультантов, если сходу не получилось самостоятельно все запустить. При этом такие консультанты чаще всего не отвечают за результат — добро пожаловать в мир коучинга.
Скрам предъявляет высокие требования к роли Владельца продукта. Со стороны заказчика такие бывают редко, просто нанять на рынке тоже не получится.
Чтобы Scrum начал приносить пользу, нужно удовлетворять довольно объемному списку предусловий:
-
Выделить Владельца продукта — специального представителя бизнеса, который:
будет наделен полномочиями для самостоятельного принятия решений о том, как должен выглядеть продукт,
несет ответственность за наполнение продукта действительно ценным для клиента функционалом
будет тесно взаимодействовать с командой разработки
Выделить на 100% всех необходимых специалистов в кросс-функциональную Скрам-команду, и договориться с их линейными руководителями, что теперь задачи этим специалистам может ставить только Владелец Продукта.
Выделить Скрам-мастера, который будет следить за правильностью процессов и способствовать развитию самоорганизации в команде.
При необходимости — выделить Скрам-команде свой контур инфраструктуры, чтобы они могли самостоятельно делать end-to-end разработку.
Обучить основам работы по Скрам всех участников Скрам-команды, заказчика и всё окружение, в котором работает команда.
Комментарии (32)
FlyingDutchman
04.10.2022 09:38+2Очень хорошая статья, чтобы сказать начальству и коллегам "А я же говорил, что не взлетит!"
SigSauer Автор
04.10.2022 09:53+2Вот так делать не надо ))
Лучше сразу сказать "Вангую, не взлетит, и вот почему"FlyingDutchman
04.10.2022 11:24+1Ну вы что?! В тот самый момент когда менеджмент окрылён рассказами очередного консультанта о том, что
скоро Нью-Васюки станут шахматной столицей мираscrum решит все их проблемы и впереди их ждёт прекрасный вкусный бонус за выполнение и перевыполнение? Да ни в жизнь! Не стоит в такие момент лезть со своим скептицизмом, чревато...SigSauer Автор
04.10.2022 13:00+1Неужели до сих пор платят бонусы за "успешное внедрение Скрама"? )
Мне кажется такое только в крупных компаниях может быть, а там уже по скрам-граблям не ходят. Хотя...
sshmakov
04.10.2022 13:17+1Сейчас платят за
успешное внедрение Agileуспешную трансформацию процессов, но имеют в виду именно Скрам
DaMaNic
04.10.2022 13:20Забавно, но под указанную методологию (слайд из рекламы Скрама про самокат — велосипед — мотоцикл — автомобиль) идеально попадает проектирование военных кораблей в 1850-1950 годах. Закладываем вот такой тип броненосца, поплавал, учли недоработки, заложили другой тип, не понравилось, пошли в сторону дредноутов, и так 100 лет, спринты длиной в 3-5 лет каждый, причем на каждом выкатывался работоспособный продукт, только фреймворки меняются (паруса/паровые двигатели/дизели/атомоходы, мелкие орудия/ покрупнее/ даст из мощь орудия/не, клепаем самолетиконосцы).
SigSauer Автор
04.10.2022 13:45+3Так это же не инкрементальный подход, это обычное эволюционное развитие.
Точно так же и любая другая техника создается
Gryphon88
04.10.2022 14:29+1При этом «Дредноут» как вершина броненосцев плохо подходит под паттерн постепенного улучшения: технологически (пушки, броня, двигательная установка) он был передовым, но не прорывным, а «похоронил» броненосцы за счет кардинальной перекомпоновки.
Ivan22
04.10.2022 14:57+4вооьще не в тему аналогия с "самокат — велосипед — мотоцикл — автомобиль ".
В скраме в первом спринте выкатывается рама на 4-х колесах, она может ездить туда сюда если ее толкать руками - круто. Во-втором спринте отдельно показывется кузов, все красивое, но руками не трогать - краска еще сохнет. В 3-м спринте на раму ставится двигатель - заводится, гудит, но пока ездить нельзя - карданы еще не готовы. В 4-м спринте ставятся сиденья и руль - но ездить все еще нельзя - топливный насос не той системы , надо менять на опенсорсный. В 5-м спринте кузов надевается на раму - выглядит круто, почти как настоящий автомобиль - но ездить все еще нельзя - пока все на скотче и стяжках держится. Ну так далее....
SigSauer Автор
04.10.2022 15:42Да, в вашем примере это имеет некий смысл. Потому что в том примере, о котором говорил я - а он легко гуглится, модная была картинка, напр https://community.atlassian.com/t5/Agile-articles/Scrum-Artifacts-with-pictures/ba-p/1265154 - скажите мне как из самоката сделать велосипед, а их него авто? ) У вас то как раз то, на что Атлассиан говорит "не надо так делать!" ))
Даже к вашему примеру сразу возникают вопросы:А что вообще клиенту надо, автомобиль для передвижения вероятно? Ок, в первой итерации мы ему дали самай самый MVP, можно катать как тележку. А дальше что? Он сможет поехать на авто с рамой, колесами и кузовом, но без руля и двигателя? Какую ценность он извлечет из сверкающего новым лаком авто который не едет? И какой фидбэк он даст, что мы сможем скорректировать в работе? А не получится так что он покатает руками раму, потом посидит в салоне, порулит, "все Ок, продолжайте парни!" - а в финале, любуясь на сверкающий спорткар, спросит "Супер тачка, а куда тут бетонные плиты то грузить?"
Тут изобретать примеры можно долго, но думаю идея понятна - если вы не сможете каждый спринт отгружать ценный рабочий инкремент и получать по нему фидбэк "да, это то что надо", или "нет, мне нужно совсем другое" - толку от Скрама не будет.
WASD1
04.10.2022 15:20+1Спасибо отличная статья!
До того было лишь смутное понимание: Scrum(как реализация Agile) нужен если мы не знаем куда мы идём, что в IT почти всегда кроме "интернет-магазина № (n+1)".
Но вот так вот разложить по полочкам - это браво, апплодирую стоя.
hippoage
04.10.2022 15:40+3Для определенности, буду писать только об ИТ-проектах.
В этом случае вся разработка инкрементальна, а вот ценность может быть бинарна (когда подписали акт, например).
Скрам, прежде всего, это организационный фреймворк. Просто невозможно говорить о Скраме, когда у вас нет скрам-мастера, команды и владельца продукта как отдельных людей. Это уже просто не Скрам (повторение любых артефактов или собраний ничего от Скрама не даст -- все они были и до Скрама, может быть под другими названиями).
Да, Скрам делался для продуктов. Вполне возможно использовать его и для достаточно длинных контрактов (особенно если команда уже была сформирована и до конкретного контракта).
Немного о проектном треугольнике: время, стоимость, функционал и качество. В классических проектах небольшая группа экспертов это все оценивает, затем контрактом фиксирует. При этом возникают проблемы при реализации, на то он и проект, а не процесс. Тогда чем-то нужно жертвовать. В классических проектах начинают смотреть в контракт и жертвуют недоописанными вещами (качество и функционал), при адекватных заказчиках увеличивают стоимость (change request), иногда еще жертвуют своей прибыльностью (увеличивают время). Agile (не только скрам) же говорит, что мы фиксируем стоимость и время, о качестве тоже договариваемся (но можем поменять по желанию заказчика), а функционал делаем с самого критичного до самого некритичного (и предполагаем, что на горизонте в полгода-год к нам еще придет бизнес и скажет, что приоритеты теперь другие).
Понятно, что у заказчика всегда есть подозрение, что люди не будут работать, поэтому это проще достигается с внутренними командами.
А роль Скрама здесь -- это как раз мотивировать команду и прозрачно показать весь процесс заказчику.
Теперь немного комментариев по тексту:
Scrum - это не метод управления проектами
Метод управления, но не всеми вариантами проектов, есть ограничения (минимальные размеры проекта прежде всего).
Скрам не умеет контролировать попадание в "проектный" треугольник Time - Budget - Scope, фактически он фокусируется только на удовлетворенности заказчика.
Умеет. Точнее никто не умеет, всегда чем-то жертвуют.
Вывод - Скрам хорошо подходит для разработки новых продуктов в области программного обеспечения. И очень ограниченно подходит для аутсорсинговых проектов, тем более не софтверных.
Если проект достаточно длинный (от полугода со стабильной командой), то, по моему опыту, Скрам вполне применим. При этом о том, что он практикуется заказчику вообще нет особой нужды знать -- это внутренний способ работы аутсорсера.
Scrum ничего не знает о дедлайнах или фиксированном бюджете
Как раз наоборот: у Скрама всегда фиксированный дедлайн и бюджет. При этом в самом Скраме совсем не описано как оценивать сложность/длительность задач, это можно делать как и без Скрама делаете. Скрам лишь позволяет выстроить процесс постепенного приблежения к цели с максимальной отдачей за единицу затрат в любой момент времени.
Поэтому даже если внешне это может выглядеть как Скрам, по сути таковым оно часто не является, если нет ценного, полезного инкремента в каждом спринте.
Похоже на передергивание. Понятно, что в самом начале, когда мы добавили, например, только авторизацию, продукт еще нельзя использовать конечными пользователями, но так же и нельзя сказать, что в спринте ничего ценного не добавили. Ценное -- добавили, заказчику -- показали, а выпускать текущий артефакт на пользователей заказик решает сам -- когда, на какую группу и тп. Другими словами под ценным мы понимаем видимое продвижение к цели продукта, а не возможность продукта сразу же быть использованным, тк да, бывают ситуации, когда это невозможно.
Вывод - перед началом проекта нужно проверять, возможно ли поставлять инкрементами что-то полезное заказчику и получать с этого обратную связь для коррекции работ.
Обратную связь всегда возможно получать. Если даже нет, то это особо ничего не меняет -- лишь добавляет дополнительный этап опытно-промышленной эксплуатации, когда заказчик бужет уже смотреть. При этом Скрам команда с самого начала все так же итеративно поставляет сборки, которые могут быть продемонстрированы заказчику, чтобы показать, что прогресс идет, или отданы отдельной команде тестирования (если уж заказчик не хочет смотреть промежуточные этапы).
Scrum - командный подход
Вывод - Скрам требует наличия сплоченной самоорганизованной команды. Нужно заранее продумать, есть ли она, или как её планируется создать.
Тут полностью согласен. Только сформулирую по-другому: нужно заранее понимать необходимость формирования команды (и это и есть основная задача скрам-мастера) и должно быть достаточное количество времени и стабильность команды, чтобы это имело смысл. Иначе нужно использовать не Скрам, а что-то другое.
Scrum опирается на кросс-функциональную команду
Вывод - Перед началом проекта проверить действительно ли кросс-функциональна команда, либо найти способ обойти это (напр. замена QA автотестами, вовлеченность команды в планирование с PO – аналитик не нужен).
Немного не так. Не обязательно, чтобы все отделы работали по Скраму (или все команды по контракту работали по Скраму). Например, IT обычно по Скраму не работают. Не обязательно, чтобы каждый член команды все мог (хотя это и мечта и традиционных руководителей проектов). Важно, чтобы задачи, который попадают в команду, могли бы быть решены этой командой. Например, дизайнеров можно вывести из Скрам-команды в команду владельца продукта, если они, в основном, будут нужны эпизодами. Аналитики и QA могут быть как внутри, так и снаружи -- опять же зависит скорее от кол-ва часов, которые они тратят на этот проект.
В Scrum достаточно высокие накладные расходы на "церемонии"
Вывод - Скрам поощряет работу короткими спринтами для быстрой адаптации к меняющимся требованиям, но слишком короткие спринты (одна - две недели) влекут за собой достаточно высокие накладные расходы на церемонии Скрам.
Есть такая проблема, но она разделяется на:
- дейли так или иначе обычно есть всегда, вполне понятно как их контролировать по времени
- демо позволяют получить обратную связь от заказчика и далее правильнее принимать тысячи мелких решений, которые программист делает чуть ли ни ежедневно, так что вполне себе окупаются
- ретро призваны повысить эффективность уже со следующего спринта -- т.е. окупаются моментально или проводятся как-то не так
- бэклог груминг -- тут сложнее всего контролировать время. Например, иногда на груминг берут не всех людей из команды, если это скорее совещание с аналитиками и дизайнерами по первоначальным уточнениям от разработчиков. Опять же на уровне ТЗ (когда еще нет кода) проще всего исправить проблемы (например, найти нестыковку с другим функционалом) и тут нужна вся команда (и тогда это окупается), но сами задачи уже должны быть достаточно хорошо проработаны.
Scrum не масштабируется на большие команды, и не умеет управлять паралельными потоками связанных работ
Вывод - при работе нескольких команд над одним продуктом Скрам как таковой уже не подходит, применяются другие подходы - SAFe, LeSS.
В целом -- да, но нельзя прям сказать, что другие. Скрам обычно остается на нижнем уровне и появляются надстройки для управления многими скрам-командами. Тут еще часто появляются микросервисы, чтобы отделить команду от команды.
Сторонники Scrum скупы на критику
Вывод - придется во всем разбираться самому, на помощь со стороны сильно не надейтесь.
Ну, и у нас есть подобные профессионалы. Есть книги, конференции, тот же Хабр, но да, если в вашей компании нет опыта, то нужно его нарабатывать. И сначала на не самом критичном проекте. А лучше найти человека в штат с опытом.
Scrum побуждает к привлечению внешних специалистов - Скрам-мастеров и Agile коучей
Вывод - у Agile коуча всегда много вопросов и нет ответов.
Мое искреннее мнение -- скрам-мастер не может быть внешним, это основа Скрама.
Нужен коуч или нет и в каком формате -- все решают сами, тут ничего нового.
Высокие требования в Scrum к Владельцу Продукта (Product Owner)
Скрам не предусматривает достаточный по времени этап сбора и анализа требований. Откуда они возьмутся, как правильно оценить их взаимосвязь, влияние на бизнес, выставить приоритет - ответов Скрам не даёт.
Вывод - без толкового Владельца продукта процесс не полетит. А найти такового очень непросто.Не согласен. Как раз в традиционном подходе заказчик изначально все подписывает и получает, что подписал. Или платить кучу денег за дополнительные соглашения. Agile (даже не Скрам) позволяет заказчику уточнять задачу по мере увеличения понимания. Не обязательно запускать Скрам с момента подписания контракта или запуска нового продукта -- какое-то время до начала разработки может проводиться первоначальный анализ, прототипы дизайна и UI, это никак не противоречит Скраму, тк скрывается за абстракцией владельца продукта, а скрам-команда либо еще не начала работать, либо занимается какими-то заранее известными задачами (пишет интеграции с другими системами, например).
Резюмируем сказанное
Понятно, что резюме тоже другое. Для длительных проектов или продуктов Скрам вполне себе подходит, но нужно четко понимать роль скрам-мастера, иначе это просто не Скрам.
PS: Большое спасибо автору за статью, тему поднимать надо и рассуждать об этом тоже полезно всем.
SigSauer Автор
04.10.2022 16:26В классических проектах небольшая группа экспертов это все оценивает, затем контрактом фиксирует. При этом возникают проблемы при реализации, на то он и проект, а не процесс. Тогда чем-то нужно жертвовать.
Не соглашусь, в классических подходах есть инструменты удержания проекта внутри треугольника. В Скраме нет.
Я вот не совсем понял мысль про фиксацию времени и стоимости в Agile - это как и где, поясните? Каким образом Скрам контролирует попадание в дедлайны и бюджет? Только очень грубые оценки по burndown чартам, основываясь на эмпирическом замере velocity (термин "мощность" тут ближе всего, но большинство считает что это скорость, так что сорри за англицизм). И эта самая велосити нифига не прогнозируема, и в Скраме нет никаких инструментов коррекции если понятно что не укладываемся. Переприоритизация элементов бэклога это в данном случае эрзац, а не инструмент коррекции.Метод управления, но не всеми вариантами проектов, есть ограничения (минимальные размеры проекта прежде всего).
Я собственно поэтому и не считаю его методом управления проектом, что в нем нет очень многих инструментов, нужных для проекта. Ничего нет о предпроектной активности (анализ и выбор по фин показателям, сбор и анализ требований), нет планирования кроме как "на лету" на ближайший спринт, и очень очень грубо дальше, нет инструментов корреции по срокам, нет управление рисками (кроме опять таки все того же backlog refinement), нет управления стоимостью. Да можно просто открыть PMBoK и читать по главам - по сути кроме части процессов исполнения - ничего больше и нет.
Обратную связь всегда возможно получать. Если даже нет, то это особо ничего не меняет -- лишь добавляет дополнительный этап опытно-промышленной эксплуатации, когда заказчик бужет уже смотреть. При этом Скрам команда с самого начала все так же итеративно поставляет сборки, которые могут быть продемонстрированы заказчику, чтобы показать, что прогресс идет, или отданы отдельной команде тестирования (если уж заказчик не хочет смотреть промежуточные этапы).
Так вы по сути уже нарушили основные принципы Скрама - постоянные инспекция и адаптация. Какая же здесь адаптация? Мы занимаемся самоуспокоением - ну мы же работаем инкременты деливерим, если заказчик их не может или не хочет смотреть - его проблема. От нас пули улетели.
Agile (даже не Скрам) позволяет заказчику уточнять задачу по мере увеличения понимания. Не обязательно запускать Скрам с момента подписания контракта или запуска нового продукта -- какое-то время до начала разработки может проводиться первоначальный анализ, прототипы дизайна и UI, это никак не противоречит Скраму, тк скрывается за абстракцией владельца продукта, а скрам-команда либо еще не начала работать, либо занимается какими-то заранее известными задачами (пишет интеграции с другими системами, например).
Да, согласен. Но тут очень важный момент - чтобы вся эта деятельность не превратилась в эксперименты за счет клиента. Которые вообще никак не противоречат идее Скрама, и даже в общем-то поощряются.
РО - единственный, кто отвечает за ценность продукта. Если это человек со стороны заказчика, значит очень повезло. Если с вашей стороны - он должен быть полностью погружен в бизнес заказчика, мне кажется.hippoage
04.10.2022 17:41Я собственно поэтому и не считаю его методом управления проектом, что в нем нет очень многих инструментов, нужных для проекта. Ничего нет о предпроектной активности (анализ и выбор по фин показателям, сбор и анализ требований), нет планирования кроме как "на лету" на ближайший спринт, и очень очень грубо дальше, нет инструментов корреции по срокам, нет управление рисками (кроме опять таки все того же backlog refinement), нет управления стоимостью. Да можно просто открыть PMBoK и читать по главам - по сути кроме части процессов исполнения - ничего больше и нет.
Тут полностью согласен, но немного под другим углом. Абсолютно понятно, что 16 страниц Scrum не заменяют PMBoK. Это просто невозможно по размеру текстов. Но я на это смотрю как Angular (PMBoK) vs React (Scrum): да, он меньше, но под конкретные условия можно подобрать (написать) дополнительные инструкции. Понятно, что Scrumу присущи уникальные преимущества из-за которых его вообще рассматривают, но не об этом сейчас.
Только очень грубые оценки по burndown чартам, основываясь на эмпирическом замере velocity (термин "мощность" тут ближе всего, но большинство считает что это скорость, так что сорри за англицизм). И эта самая велосити нифига не прогнозируема
В Скраме нет определения как делать оценки. Хотите применяйте этот метод, хотите другой. Тут уже и так много текста, не буду про разные способы оценок -- про это есть отдельные книги.
Так вы по сути уже нарушили основные принципы Скрама - постоянные инспекция и адаптация. Какая же здесь адаптация? Мы занимаемся самоуспокоением - ну мы же работаем инкременты деливерим, если заказчик их не может или не хочет смотреть - его проблема. От нас пули улетели.
Ну, не совсем нарушил -- я как раз предлагал это делать внутри, даже если не удалось объяснить заказчику ценность. Понятно, что ситуация не идеальная, но это жизнь.
РО - единственный, кто отвечает за ценность продукта. Если это человек со стороны заказчика, значит очень повезло. Если с вашей стороны - он должен быть полностью погружен в бизнес заказчика, мне кажется.
В целом, хороший скрам-мастер будет и свою команду на это настраивать, но да, PO нужен и важен. От него скорее требуется не столько какие-то специальные навыки, сколько высокая заинтересованность в продукте и готовность на это тратить время. Я работал и по обычным контрактам, в успешных проектах это и там важнейший фактор. Просто в Scrum об этом говорится открыто и подчеркивается такая необходимость.
Не соглашусь, в классических подходах есть инструменты удержания проекта внутри треугольника. В Скраме нет.
Я вот не совсем понял мысль про фиксацию времени и стоимости в Agile - это как и где, поясните? Каким образом Скрам контролирует попадание в дедлайны и бюджет? ... И эта самая велосити нифига не прогнозируема, и в Скраме нет никаких инструментов коррекции если понятно что не укладываемся. Переприоритизация элементов бэклога это в данном случае эрзац, а не инструмент коррекции.Обычно Agile-контракт (внешний или внутренний) подписывают на время (дату), сумму и команду, описывают качество как в обычном проекте, функционал по разному (описывают больше или меньше), но на него не комитятся. Из-за этого опять же обычно так работают только внутренние команды. Если контракт внешний agile, то его чаще всего подписывают как обычно, но делают рамочным (опять же фиксируется дата окончания и сумма, а ТЗ/заказы выдаются помесячно). В любом случае, это уже получше, т.к. объем оцениваемых задач ниже и максимальная возможная ошибка пониже. Бывают и совсем обычные контракты, тогда уж использовать Скрам или нет -- отдельный вопрос, тут нужен внутренний продвинутый владелец продукта, чтобы все приемы классических подходов в себе абстрагировать.
То, что нет многого -- очевидно. Весь вопрос мешает ли Скрам классическим инструментам -- если нет, то вообще проблемы нет.
Основная мысль про фиксацию возвращает нас к пирамидке. Аксиома: чаще всего с применением всех классических и неклассических подходов в нее уложиться не получается (есть какая-то американская статистика по проектам и у каждого собственный опыт). Тогда нужно что-то двигать (описал ранее как обычно двигают). В Agile у нас такой порядок работ, чтобы все самое критичное было сделано сразу же (и как только что-то становится более критичным, сразу же этим и занимаемся, поэтому спринты по неделе -- длина спринтов зависит от необходимой скорости изменения задач). Т.е. мы останавливаемся там до куда успеваем, но не успели мы самые незначительные вещи. После этого уже заказчик смотрит что делать: устраивает его так или делаем новый этап (сразу или через какое-то время).
SigSauer Автор
04.10.2022 22:45Обычно Agile-контракт (внешний или внутренний) подписывают на время (дату), сумму и команду, описывают качество как в обычном проекте, функционал по разному (описывают больше или меньше), но на него не комитятся. Из-за этого опять же обычно так работают только внутренние команды. Если контракт внешний agile, то его чаще всего подписывают как обычно, но делают рамочным (опять же фиксируется дата окончания и сумма, а ТЗ/заказы выдаются помесячно).
Так причем здесь Скрам. Это просто budget cap, лимит бюджета, может быть может не быть - Скрам никак не контролирует и не управляет. Никаких обязательств по срокам и бюджету команда не берет. В PMI за такое "управление бюджетом" сразу канделябром бьют )
Основная мысль про фиксацию возвращает нас к пирамидке. Аксиома: чаще всего с применением всех классических и неклассических подходов в нее уложиться не получается
Я бы это выразил по другому - в PMI или Prince2 есть (хотя и не всегда) обязательства по срокам - бюджету - объему работ. Есть инструменты контроля, есть способы коррекции. В Скраме может быть лимит бюджета, может не быть - Скраму всё равно, он никак не контролирует.
есть какая-то американская статистика по проектам и у каждого собственный опыт
Да, у Standish Group есть Chaos reports по годам.
hippoage
06.10.2022 12:52Так причем здесь Скрам.
Да, я даже слово Скрам не использовал. Просто это часто используется совместно со Скрамом.
Никаких обязательств по срокам и бюджету команда не берет.
Команда берет обязательства на 1 спринт. На весь проект не берет.
Я бы это выразил по другому - в PMI или Prince2 есть (хотя и не всегда) обязательства по срокам - бюджету - объему работ. Есть инструменты контроля, есть способы коррекции. В Скраме может быть лимит бюджета, может не быть - Скраму всё равно, он никак не контролирует.
Мы тут забываем одну вещь: если бы PMI давал результат, то Agile движение не появилось бы вообще. Другими словами, из статистики мы знаем, что все эти инструменты, которые есть в классических методах в итоге не работают.
Постарался раскрыть эту мысль в отдельной статье: https://habr.com/ru/post/691800/
SigSauer Автор
06.10.2022 13:33Мы тут забываем одну вещь: если бы PMI давал результат, то Agile движение не появилось бы вообще. Другими словами, из статистики мы знаем, что все эти инструменты, которые есть в классических методах в итоге не работают.
По такой логике и гибкие методологии бесполезны - если бы это было не так, PMI / IPMA / Prince2 и иже с ними давно канули бы в небытие - манифесту Agile уже больше 20 лет, Скрам и того старше. Достаточно времени чтобы забыть то, что не даёт результаты, не так ли?
Посмотрите на Chaos репорты - около 30% проектов успешны, около 50% - завершились с проблемами, остальные 20 провалены. И такая статистика плюс минус уже довольно давно, насколько помню (надо поискать и проверить кстати).
Более того, где-то видел исследование лет года 3-4 назад, оценка эффекта перехода на гибкие методологии в работе, по-моему там именно Скрам фигурировал - по оценке компаний, рост эффективности около 3-4% отмечен. Можете прикинуть сами, насколько затратен переход на Скрам и окупается ли.
PMI прекрасно работает. Есть условия где Скрам будет лучше, есть человеческий фактор - в PMI сложнее разобраться (на первый взгляд, как мне знаем Скрам тоже с двойным дном штука), сложне работать (то жа замечание про двойное дно в Скраме), он менее хайповый и откровенно скучный, "академический". Поэтому выбор в пользу Скрама часто не основан на глубоком анализе, а банально "модно, современно, заказчик требует".Ну и да, не так давно ставший известным Cynefin активно тоже к использованию Скрама подталкивает. Ещё аукнется многим )
hippoage
06.10.2022 17:29Я ни в коем разе не утверждаю, что Agile и/или Скрам справились с возложенной на них задачей. Я лишь утверждаю, что классические методологии не справились (и из-за этого появились популярные альтернативы). В частности, PMI чаще не работает, чем работает (и его сложность -- это его проблема, не нужно тут вдруг сущность людей отдельно рассматривать).
Что и как внедрять в конкретном случае -- даже чтобы это определить нужен не один день. Это вполне себе полноценная работа. Тут призываю как раз проводить довольно широкий анализ и рассматривать максимум доступных инструментов.
SigSauer Автор
06.10.2022 18:14Да, открываем 7-ю версию PMBoK, домен исполнения "Подход к разработке и жизненный цикл" и вуаля - предиктивные, гибридные, адаптивные подходы, каденции поставок и прочее, целых 20 страниц в помощь менеджеру )
SigSauer Автор
06.10.2022 16:26Тут интереснее даже другое, если задуматься - признаваемые всеми эксперты в отрасли говорят например, что люди самый важные фактор в разработке ПО, и при этом нелинейный и непредсказуемый, и большинство проблем в проектах имеет не технологическую природу, а социологическую (Кобёрн, Демарко).
И что предлагает Скрам? Позволю себе побыть критиком.Полное и безальтернитивное вовлечение заказчика в процесс. А он точно хочет, готов, его спросили? У Agile-вселенной есть ответ - а не хочет вовлекаться, мы
ему газ отключимвыставим его на Waterfall, вот там он наплачется и сам умолять будет. Как будто других вариантов кроме Скрама и водопада нет.Мотивация команды методом "представим что у нас все самомотивированные професионалы". А где взять таких, а если нет? А нет самоорганизованной команды - нет Скрама, говорит нам руководство ) Хотя впрочем одно решение предлагает - этим должен заняться профессиональный Скрам-мастер. Где его взять? Обучите или наймите со стороны. Это такой человек, от которого в конечном итоге сильно зависит успех проекта (ок, не проекта а деятельности), но который за результат не отвечает.
Вишенка на торте - Владелец продукта, который один отвечает за всё, по сути. И рынок знает, и бизнес модель заказчика, и кастдев успевает, и с командой плотно работает, направляя её энергию туда куда нужно. Прямо и жнец, и швец и на дуде грец )
Gryphon88
06.10.2022 16:51+1Извините за мнение непрофессионала:
1. Если не вовлечь заказчика в процесс, то в лучшем случае получится не то, что заказчик хочет/ему нужно, а то, что он написал в тз.
2. Самый сложный пункт. Давайте возьмемнастоящих коммунистовсамомоорганизованную команду, они внутри себя разрулят…
3. РО, имхо, дублер и переводчик заказчика, на случай если тот недововлечется.SigSauer Автор
06.10.2022 18:041. Если не вовлечь заказчика в процесс, то в лучшем случае получится не то, что заказчик хочет/ему нужно, а то, что он написал в тз.
Верно, и здесь самое время вспомнить что в PMBoK есть целая область знаний - Управление заинтересованными сторонами, со всякими интересными штуками как реестр заинтересованных сторон, матрица power / interest grid, стратегия вовлечения и прочими. Но это же скучно!
Скрам все это спокойновыбросилупростил, и директивным порядком установил - Скрам-мастер берет ключевых стейкхолдеров за воротник и тащит на Sprint Review. Не хотят? Ну значит Скрама не будет. Что делать с остальными заинтересованными сторонами, можно ли привлекать их на другие церемонии, как кого информировать вообще - Скраму это неинтересно, он намеренно неполный. Почитайте где-то в другом месте, да хоть в PMBoK - там то все детально расписано, в отличие от.
И тут внезапно появляются мнения "PMI вообще не работает, поэтому будет Скрам". Но постойте...
hippoage
06.10.2022 17:43По вовлеченности: попробуйте сделать дома ремонт и не вникать в детали. В принципе, такое возможно, но тогда нужно нанимать отдельных людей, которые будут вникать. Конкретно в Скраме это все скрывается через абстракцию Владельца продукта и его команду (не путать со скрам-командой).
По мотивации: как раз про это и есть значительная часть Скрама. Ровно для этого выделяется скрам-мастер.
По ответственности: вы опять хотите назначить 1 ответственного человека за все. Так не работает Скрам. У скрам-мастера, команды и владельца продукта у каждого есть свои зоны ответственности. И это одна из основных проблем Скрама (что часто люди так или иначе все равно пытаются выделить 1 человека ответственного за все). Конкретно владелец продукта отвечает за приоритизацию задач (из всего массива были выбраны самые важные и достаточно мелкий, чтобы не тянули в себе неважные подзадачи). Откуда берутся задачи (анализ рынков, процессов и тп) -- это за пределами Скрама (или может быть отдельная скрам или не скрам команда аналитиков, например).SigSauer Автор
06.10.2022 18:28А вы попробуйте сделать ремонт дома по Скрам.
Без оценки срока и бюджета ("попробуем и увидим как пойдёт"), с вашим глубоким вовлечением ("мы стяжку залили, норм или переделать?"), без управления закупками ("надо клей плиточный купить, мы понятия не имеем как это сделать") и так далее ))
Вы уже не первый раз пишете о некой "команде ВП". Что это вообще? В Скраме нет этой сущности. Вы в курсе, что "Product Owner — это один человек, а не комитет."?
E32_735i
05.10.2022 10:18что- то я чувствую седину на голове, а когда скрам стали называть фреймворком?
это же инструмент для самоудовлетворения эффективных гумманитариев, т.е. формально, это методолия
SigSauer Автор
05.10.2022 10:24Я бы сказал что методика, на методологию он не тянет. Но фреймворком его называют сами авторы.
Придуманный и успешно применяемый, кстати, самыми махровыми технарями.
В том что его оседлали "эффективные гумманитарии", Скрам не виноват.
Mike-M
06.10.2022 00:45чаще всего последовательность — BA -> UI -> Dev -> QA.
Такой подход противоречит незыблемой истине: чем раньше QA вовлекается в процесс разработки, тем дешевле обходится исправление багов.либо найти способ обойти это (напр. замена QA автотестами
Это одно из распространенных заблуждений: «сейчас мы заменим всех ручных тестировщиков QA-автоматизаторами и заживем весело и сча́стливо».Но есть и тёмная сторона работы короткими (например недельными) спринтами.
Недельные спринты? Не представляю, как такое возможно.
SigSauer Автор
06.10.2022 11:17Такой подход противоречит незыблемой истине: чем раньше QA вовлекается в процесс разработки, тем дешевле обходится исправление багов.
Всё верно, но часто эта незаблемая истина разбивается о суровую реальность - тестировщики на раннем этапе привлекаются для описания DoD для стори, может быть еще для DoR, и собственно на этом все до тех пор пока разработчик не переместит эту задачу на доске в колонку "ready to test". Если только работа не организована по процессу Test Driven Development, но я честно говоря не встречал рабочего симбиоза TDD и Scrum
Недельные спринты? Не представляю, как такое возможно.
Даже на Хабре можно найти материалы по такой работе. Видимо кому-то удаётся, либо команда не парится подсчетом временных затрат на митинги, либо планируют и проводят демо/ретро как-то очень быстро.
courage_andrey
Это всем пригодится. Надоело слышать от людей, что Скрам и Аджайл подходят везде и для всего, а PMI - это только для HelloWorld-ов.
hippoage
Было бы с PMI все было хорошо, то не было бы и ITIL/ITSM, и Agile/Scrum. Просто везде свое. И, конечно, тут панацеи нет, нужно смотреть что за задача и окружение, а уж после под это подбирать решение.
courage_andrey
Так я ровно про это и говорю, что танцевать надо от задачи, а не натягивать
сову на глобусзадачу на Agile.