Comments 38
Думаю, что для опытных менеджеров и Скрам-мастеров здесь не будет ничего нового, материал пригодится скорее начинающим Скрам-мастерам или разработчикам, работающим по Скраму.
Это всем пригодится. Надоело слышать от людей, что Скрам и Аджайл подходят везде и для всего, а PMI - это только для HelloWorld-ов.
Очень хорошая статья, чтобы сказать начальству и коллегам "А я же говорил, что не взлетит!"
Вот так делать не надо ))
Лучше сразу сказать "Вангую, не взлетит, и вот почему"
Ну вы что?! В тот самый момент когда менеджмент окрылён рассказами очередного консультанта о том, что скоро Нью-Васюки станут шахматной столицей мира scrum решит все их проблемы и впереди их ждёт прекрасный вкусный бонус за выполнение и перевыполнение? Да ни в жизнь! Не стоит в такие момент лезть со своим скептицизмом, чревато...
Так это же не инкрементальный подход, это обычное эволюционное развитие.
Точно так же и любая другая техника создается
вооьще не в тему аналогия с "самокат — велосипед — мотоцикл — автомобиль ".
В скраме в первом спринте выкатывается рама на 4-х колесах, она может ездить туда сюда если ее толкать руками - круто. Во-втором спринте отдельно показывется кузов, все красивое, но руками не трогать - краска еще сохнет. В 3-м спринте на раму ставится двигатель - заводится, гудит, но пока ездить нельзя - карданы еще не готовы. В 4-м спринте ставятся сиденья и руль - но ездить все еще нельзя - топливный насос не той системы , надо менять на опенсорсный. В 5-м спринте кузов надевается на раму - выглядит круто, почти как настоящий автомобиль - но ездить все еще нельзя - пока все на скотче и стяжках держится. Ну так далее....
Да, в вашем примере это имеет некий смысл. Потому что в том примере, о котором говорил я - а он легко гуглится, модная была картинка, напр https://community.atlassian.com/t5/Agile-articles/Scrum-Artifacts-with-pictures/ba-p/1265154 - скажите мне как из самоката сделать велосипед, а их него авто? ) У вас то как раз то, на что Атлассиан говорит "не надо так делать!" ))
Даже к вашему примеру сразу возникают вопросы:
А что вообще клиенту надо, автомобиль для передвижения вероятно? Ок, в первой итерации мы ему дали самай самый MVP, можно катать как тележку. А дальше что? Он сможет поехать на авто с рамой, колесами и кузовом, но без руля и двигателя? Какую ценность он извлечет из сверкающего новым лаком авто который не едет? И какой фидбэк он даст, что мы сможем скорректировать в работе? А не получится так что он покатает руками раму, потом посидит в салоне, порулит, "все Ок, продолжайте парни!" - а в финале, любуясь на сверкающий спорткар, спросит "Супер тачка, а куда тут бетонные плиты то грузить?"
Тут изобретать примеры можно долго, но думаю идея понятна - если вы не сможете каждый спринт отгружать ценный рабочий инкремент и получать по нему фидбэк "да, это то что надо", или "нет, мне нужно совсем другое" - толку от Скрама не будет.
Вот хорошая статья от автора той картинки, которая поясняет логику: https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
TLDR: Разработка исходит не из озвученных требований а от потребностей клиента.
Когда клиент говорит "хочу вот такую вот машину" - надо разобраться "чтобы что" и потом, в рамках scrum команды, найти способ первого приближения к удовлетворению потребности за один спринт. Показать клиенту, проверить как оно решает потребность, учесть новый опыт, пойти улучшать за спринт.
Идея в том, что если потребность была "хочу комфортно ездить каждый день из точки А в точку Б" - возможно, электросамоката ему хватит и от него получит дальше большее удовлетворение, чем от изначальной идеи Mercedes S-Klasse.
Спасибо за ссылку, интересно почитать.
Однако, если задуматься, это все очень плохоже на следующее - если упростить до несколькх фраз - "Многие менеджеры и компании не понимают и не умеют правильно применять классические (предиктивные) подходы. Поэтому мы взяли оттуда некоторые идеи (да, в Скраме ничего революционно нового нет), акцентировали на них внимание, отбросили остальное и придумали Скрам. Попутно для усиления эффекта мы исказили смысл и демонизировали классические подходы. И вот ведь незадача, многие менеджеры снова неправильно поняли суть Скрама, приходится многократно объяснять"
Есть разные варианты как можно применять scrum к разработке продукта.
Есть вариант итеративный - как раз это про пример с "самокат - велосипед - мотоцикл - автомобиль". В этом варианте мы каждый новый спринт поставляем ценность, удовлетворяющую потребность клиента но, возможно, не обладающая полным набором необходимых свойств. С помощью этого способа появляется обучение, т.к. нашим продуктом можно пользоваться с самого начала и мы можем действительно его проверять.
Есть вариант инкрементальный - это как раз ваш пример. Каждый спринт к нашему продукту добавляется ещё кусочек, но пользоваться ещё нельзя. Минус тут в том, продуктом нельзя пользоваться.
Идеалогически, скрам близок к итеративному способу. С точки зрения стейкхолдеров это даёт гибкость, ради которой фреймворк и создавался. После каждого спринта получается работающий продукт и в любой момент на Sprint review можно сказать "нам достаточно, останавливаем инвестиции" и не остаться в ситуации "есть кузов на раме, но не ездит и потребности не удовлетворяет".
Вам не кажется, что описанный вами инкрементальный способ прямо и недвусмысленно противоречит руководству по Скрам?
Не просто кажется - он противоречит ?
Но часто применяется на практике в fixed-scope проектах.
Я с этой практикой не согласен. Если в конце спринта нет инкремента - значит на ревью не будет инспекции, значит не будет получена информация для адаптации.
Нет инспекции и адаптации - это уже не скрам.
А если при этом все продолжает работать - значит домен не комплексный а значит скрам там изначально был не нужен.
Спасибо отличная статья!
До того было лишь смутное понимание: Scrum(как реализация Agile) нужен если мы не знаем куда мы идём, что в IT почти всегда кроме "интернет-магазина № (n+1)".
Но вот так вот разложить по полочкам - это браво, апплодирую стоя.
Для определенности, буду писать только об ИТ-проектах.
В этом случае вся разработка инкрементальна, а вот ценность может быть бинарна (когда подписали акт, например).
Скрам, прежде всего, это организационный фреймворк. Просто невозможно говорить о Скраме, когда у вас нет скрам-мастера, команды и владельца продукта как отдельных людей. Это уже просто не Скрам (повторение любых артефактов или собраний ничего от Скрама не даст -- все они были и до Скрама, может быть под другими названиями).
Да, Скрам делался для продуктов. Вполне возможно использовать его и для достаточно длинных контрактов (особенно если команда уже была сформирована и до конкретного контракта).
Немного о проектном треугольнике: время, стоимость, функционал и качество. В классических проектах небольшая группа экспертов это все оценивает, затем контрактом фиксирует. При этом возникают проблемы при реализации, на то он и проект, а не процесс. Тогда чем-то нужно жертвовать. В классических проектах начинают смотреть в контракт и жертвуют недоописанными вещами (качество и функционал), при адекватных заказчиках увеличивают стоимость (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: Большое спасибо автору за статью, тему поднимать надо и рассуждать об этом тоже полезно всем.
В классических проектах небольшая группа экспертов это все оценивает, затем контрактом фиксирует. При этом возникают проблемы при реализации, на то он и проект, а не процесс. Тогда чем-то нужно жертвовать.
Не соглашусь, в классических подходах есть инструменты удержания проекта внутри треугольника. В Скраме нет.
Я вот не совсем понял мысль про фиксацию времени и стоимости в Agile - это как и где, поясните? Каким образом Скрам контролирует попадание в дедлайны и бюджет? Только очень грубые оценки по burndown чартам, основываясь на эмпирическом замере velocity (термин "мощность" тут ближе всего, но большинство считает что это скорость, так что сорри за англицизм). И эта самая велосити нифига не прогнозируема, и в Скраме нет никаких инструментов коррекции если понятно что не укладываемся. Переприоритизация элементов бэклога это в данном случае эрзац, а не инструмент коррекции.
Метод управления, но не всеми вариантами проектов, есть ограничения (минимальные размеры проекта прежде всего).
Я собственно поэтому и не считаю его методом управления проектом, что в нем нет очень многих инструментов, нужных для проекта. Ничего нет о предпроектной активности (анализ и выбор по фин показателям, сбор и анализ требований), нет планирования кроме как "на лету" на ближайший спринт, и очень очень грубо дальше, нет инструментов корреции по срокам, нет управление рисками (кроме опять таки все того же backlog refinement), нет управления стоимостью. Да можно просто открыть PMBoK и читать по главам - по сути кроме части процессов исполнения - ничего больше и нет.
Обратную связь всегда возможно получать. Если даже нет, то это особо ничего не меняет -- лишь добавляет дополнительный этап опытно-промышленной эксплуатации, когда заказчик бужет уже смотреть. При этом Скрам команда с самого начала все так же итеративно поставляет сборки, которые могут быть продемонстрированы заказчику, чтобы показать, что прогресс идет, или отданы отдельной команде тестирования (если уж заказчик не хочет смотреть промежуточные этапы).
Так вы по сути уже нарушили основные принципы Скрама - постоянные инспекция и адаптация. Какая же здесь адаптация? Мы занимаемся самоуспокоением - ну мы же работаем инкременты деливерим, если заказчик их не может или не хочет смотреть - его проблема. От нас пули улетели.
Agile (даже не Скрам) позволяет заказчику уточнять задачу по мере увеличения понимания. Не обязательно запускать Скрам с момента подписания контракта или запуска нового продукта -- какое-то время до начала разработки может проводиться первоначальный анализ, прототипы дизайна и UI, это никак не противоречит Скраму, тк скрывается за абстракцией владельца продукта, а скрам-команда либо еще не начала работать, либо занимается какими-то заранее известными задачами (пишет интеграции с другими системами, например).
Да, согласен. Но тут очень важный момент - чтобы вся эта деятельность не превратилась в эксперименты за счет клиента. Которые вообще никак не противоречат идее Скрама, и даже в общем-то поощряются.
РО - единственный, кто отвечает за ценность продукта. Если это человек со стороны заказчика, значит очень повезло. Если с вашей стороны - он должен быть полностью погружен в бизнес заказчика, мне кажется.
Я собственно поэтому и не считаю его методом управления проектом, что в нем нет очень многих инструментов, нужных для проекта. Ничего нет о предпроектной активности (анализ и выбор по фин показателям, сбор и анализ требований), нет планирования кроме как "на лету" на ближайший спринт, и очень очень грубо дальше, нет инструментов корреции по срокам, нет управление рисками (кроме опять таки все того же backlog refinement), нет управления стоимостью. Да можно просто открыть PMBoK и читать по главам - по сути кроме части процессов исполнения - ничего больше и нет.
Тут полностью согласен, но немного под другим углом. Абсолютно понятно, что 16 страниц Scrum не заменяют PMBoK. Это просто невозможно по размеру текстов. Но я на это смотрю как Angular (PMBoK) vs React (Scrum): да, он меньше, но под конкретные условия можно подобрать (написать) дополнительные инструкции. Понятно, что Scrumу присущи уникальные преимущества из-за которых его вообще рассматривают, но не об этом сейчас.
Только очень грубые оценки по burndown чартам, основываясь на эмпирическом замере velocity (термин "мощность" тут ближе всего, но большинство считает что это скорость, так что сорри за англицизм). И эта самая велосити нифига не прогнозируема
В Скраме нет определения как делать оценки. Хотите применяйте этот метод, хотите другой. Тут уже и так много текста, не буду про разные способы оценок -- про это есть отдельные книги.
Так вы по сути уже нарушили основные принципы Скрама - постоянные инспекция и адаптация. Какая же здесь адаптация? Мы занимаемся самоуспокоением - ну мы же работаем инкременты деливерим, если заказчик их не может или не хочет смотреть - его проблема. От нас пули улетели.
Ну, не совсем нарушил -- я как раз предлагал это делать внутри, даже если не удалось объяснить заказчику ценность. Понятно, что ситуация не идеальная, но это жизнь.
РО - единственный, кто отвечает за ценность продукта. Если это человек со стороны заказчика, значит очень повезло. Если с вашей стороны - он должен быть полностью погружен в бизнес заказчика, мне кажется.
В целом, хороший скрам-мастер будет и свою команду на это настраивать, но да, PO нужен и важен. От него скорее требуется не столько какие-то специальные навыки, сколько высокая заинтересованность в продукте и готовность на это тратить время. Я работал и по обычным контрактам, в успешных проектах это и там важнейший фактор. Просто в Scrum об этом говорится открыто и подчеркивается такая необходимость.
Не соглашусь, в классических подходах есть инструменты удержания проекта внутри треугольника. В Скраме нет.
Я вот не совсем понял мысль про фиксацию времени и стоимости в Agile - это как и где, поясните? Каким образом Скрам контролирует попадание в дедлайны и бюджет? ... И эта самая велосити нифига не прогнозируема, и в Скраме нет никаких инструментов коррекции если понятно что не укладываемся. Переприоритизация элементов бэклога это в данном случае эрзац, а не инструмент коррекции.
Обычно Agile-контракт (внешний или внутренний) подписывают на время (дату), сумму и команду, описывают качество как в обычном проекте, функционал по разному (описывают больше или меньше), но на него не комитятся. Из-за этого опять же обычно так работают только внутренние команды. Если контракт внешний agile, то его чаще всего подписывают как обычно, но делают рамочным (опять же фиксируется дата окончания и сумма, а ТЗ/заказы выдаются помесячно). В любом случае, это уже получше, т.к. объем оцениваемых задач ниже и максимальная возможная ошибка пониже. Бывают и совсем обычные контракты, тогда уж использовать Скрам или нет -- отдельный вопрос, тут нужен внутренний продвинутый владелец продукта, чтобы все приемы классических подходов в себе абстрагировать.
То, что нет многого -- очевидно. Весь вопрос мешает ли Скрам классическим инструментам -- если нет, то вообще проблемы нет.
Основная мысль про фиксацию возвращает нас к пирамидке. Аксиома: чаще всего с применением всех классических и неклассических подходов в нее уложиться не получается (есть какая-то американская статистика по проектам и у каждого собственный опыт). Тогда нужно что-то двигать (описал ранее как обычно двигают). В Agile у нас такой порядок работ, чтобы все самое критичное было сделано сразу же (и как только что-то становится более критичным, сразу же этим и занимаемся, поэтому спринты по неделе -- длина спринтов зависит от необходимой скорости изменения задач). Т.е. мы останавливаемся там до куда успеваем, но не успели мы самые незначительные вещи. После этого уже заказчик смотрит что делать: устраивает его так или делаем новый этап (сразу или через какое-то время).
Обычно Agile-контракт (внешний или внутренний) подписывают на время (дату), сумму и команду, описывают качество как в обычном проекте, функционал по разному (описывают больше или меньше), но на него не комитятся. Из-за этого опять же обычно так работают только внутренние команды. Если контракт внешний agile, то его чаще всего подписывают как обычно, но делают рамочным (опять же фиксируется дата окончания и сумма, а ТЗ/заказы выдаются помесячно).
Так причем здесь Скрам. Это просто budget cap, лимит бюджета, может быть может не быть - Скрам никак не контролирует и не управляет. Никаких обязательств по срокам и бюджету команда не берет. В PMI за такое "управление бюджетом" сразу канделябром бьют )
Основная мысль про фиксацию возвращает нас к пирамидке. Аксиома: чаще всего с применением всех классических и неклассических подходов в нее уложиться не получается
Я бы это выразил по другому - в PMI или Prince2 есть (хотя и не всегда) обязательства по срокам - бюджету - объему работ. Есть инструменты контроля, есть способы коррекции. В Скраме может быть лимит бюджета, может не быть - Скраму всё равно, он никак не контролирует.
есть какая-то американская статистика по проектам и у каждого собственный опыт
Да, у Standish Group есть Chaos reports по годам.
Так причем здесь Скрам.
Да, я даже слово Скрам не использовал. Просто это часто используется совместно со Скрамом.
Никаких обязательств по срокам и бюджету команда не берет.
Команда берет обязательства на 1 спринт. На весь проект не берет.
Я бы это выразил по другому - в PMI или Prince2 есть (хотя и не всегда) обязательства по срокам - бюджету - объему работ. Есть инструменты контроля, есть способы коррекции. В Скраме может быть лимит бюджета, может не быть - Скраму всё равно, он никак не контролирует.
Мы тут забываем одну вещь: если бы PMI давал результат, то Agile движение не появилось бы вообще. Другими словами, из статистики мы знаем, что все эти инструменты, которые есть в классических методах в итоге не работают.
Постарался раскрыть эту мысль в отдельной статье: https://habr.com/ru/post/691800/
Мы тут забываем одну вещь: если бы PMI давал результат, то Agile движение не появилось бы вообще. Другими словами, из статистики мы знаем, что все эти инструменты, которые есть в классических методах в итоге не работают.
По такой логике и гибкие методологии бесполезны - если бы это было не так, PMI / IPMA / Prince2 и иже с ними давно канули бы в небытие - манифесту Agile уже больше 20 лет, Скрам и того старше. Достаточно времени чтобы забыть то, что не даёт результаты, не так ли?
Посмотрите на Chaos репорты - около 30% проектов успешны, около 50% - завершились с проблемами, остальные 20 провалены. И такая статистика плюс минус уже довольно давно, насколько помню (надо поискать и проверить кстати).
Более того, где-то видел исследование лет года 3-4 назад, оценка эффекта перехода на гибкие методологии в работе, по-моему там именно Скрам фигурировал - по оценке компаний, рост эффективности около 3-4% отмечен. Можете прикинуть сами, насколько затратен переход на Скрам и окупается ли.
PMI прекрасно работает. Есть условия где Скрам будет лучше, есть человеческий фактор - в PMI сложнее разобраться (на первый взгляд, как мне знаем Скрам тоже с двойным дном штука), сложне работать (то жа замечание про двойное дно в Скраме), он менее хайповый и откровенно скучный, "академический". Поэтому выбор в пользу Скрама часто не основан на глубоком анализе, а банально "модно, современно, заказчик требует".
Ну и да, не так давно ставший известным Cynefin активно тоже к использованию Скрама подталкивает. Ещё аукнется многим )
Я ни в коем разе не утверждаю, что Agile и/или Скрам справились с возложенной на них задачей. Я лишь утверждаю, что классические методологии не справились (и из-за этого появились популярные альтернативы). В частности, PMI чаще не работает, чем работает (и его сложность -- это его проблема, не нужно тут вдруг сущность людей отдельно рассматривать).
Что и как внедрять в конкретном случае -- даже чтобы это определить нужен не один день. Это вполне себе полноценная работа. Тут призываю как раз проводить довольно широкий анализ и рассматривать максимум доступных инструментов.
Тут интереснее даже другое, если задуматься - признаваемые всеми эксперты в отрасли говорят например, что люди самый важные фактор в разработке ПО, и при этом нелинейный и непредсказуемый, и большинство проблем в проектах имеет не технологическую природу, а социологическую (Кобёрн, Демарко).
И что предлагает Скрам? Позволю себе побыть критиком.
Полное и безальтернитивное вовлечение заказчика в процесс. А он точно хочет, готов, его спросили? У Agile-вселенной есть ответ - а не хочет вовлекаться, мы
ему газ отключимвыставим его на Waterfall, вот там он наплачется и сам умолять будет. Как будто других вариантов кроме Скрама и водопада нет.Мотивация команды методом "представим что у нас все самомотивированные професионалы". А где взять таких, а если нет? А нет самоорганизованной команды - нет Скрама, говорит нам руководство ) Хотя впрочем одно решение предлагает - этим должен заняться профессиональный Скрам-мастер. Где его взять? Обучите или наймите со стороны. Это такой человек, от которого в конечном итоге сильно зависит успех проекта (ок, не проекта а деятельности), но который за результат не отвечает.
Вишенка на торте - Владелец продукта, который один отвечает за всё, по сути. И рынок знает, и бизнес модель заказчика, и кастдев успевает, и с командой плотно работает, направляя её энергию туда куда нужно. Прямо и жнец, и швец и на дуде грец )
1. Если не вовлечь заказчика в процесс, то в лучшем случае получится не то, что заказчик хочет/ему нужно, а то, что он написал в тз.
2. Самый сложный пункт. Давайте возьмем
3. РО, имхо, дублер и переводчик заказчика, на случай если тот недововлечется.
1. Если не вовлечь заказчика в процесс, то в лучшем случае получится не то, что заказчик хочет/ему нужно, а то, что он написал в тз.
Верно, и здесь самое время вспомнить что в PMBoK есть целая область знаний - Управление заинтересованными сторонами, со всякими интересными штуками как реестр заинтересованных сторон, матрица power / interest grid, стратегия вовлечения и прочими. Но это же скучно!
Скрам все это спокойно выбросил упростил, и директивным порядком установил - Скрам-мастер берет ключевых стейкхолдеров за воротник и тащит на Sprint Review. Не хотят? Ну значит Скрама не будет. Что делать с остальными заинтересованными сторонами, можно ли привлекать их на другие церемонии, как кого информировать вообще - Скраму это неинтересно, он намеренно неполный. Почитайте где-то в другом месте, да хоть в PMBoK - там то все детально расписано, в отличие от.
И тут внезапно появляются мнения "PMI вообще не работает, поэтому будет Скрам". Но постойте...
По вовлеченности: попробуйте сделать дома ремонт и не вникать в детали. В принципе, такое возможно, но тогда нужно нанимать отдельных людей, которые будут вникать. Конкретно в Скраме это все скрывается через абстракцию Владельца продукта и его команду (не путать со скрам-командой).
По мотивации: как раз про это и есть значительная часть Скрама. Ровно для этого выделяется скрам-мастер.
По ответственности: вы опять хотите назначить 1 ответственного человека за все. Так не работает Скрам. У скрам-мастера, команды и владельца продукта у каждого есть свои зоны ответственности. И это одна из основных проблем Скрама (что часто люди так или иначе все равно пытаются выделить 1 человека ответственного за все). Конкретно владелец продукта отвечает за приоритизацию задач (из всего массива были выбраны самые важные и достаточно мелкий, чтобы не тянули в себе неважные подзадачи). Откуда берутся задачи (анализ рынков, процессов и тп) -- это за пределами Скрама (или может быть отдельная скрам или не скрам команда аналитиков, например).
А вы попробуйте сделать ремонт дома по Скрам.
Без оценки срока и бюджета ("попробуем и увидим как пойдёт"), с вашим глубоким вовлечением ("мы стяжку залили, норм или переделать?"), без управления закупками ("надо клей плиточный купить, мы понятия не имеем как это сделать") и так далее ))
Вы уже не первый раз пишете о некой "команде ВП". Что это вообще? В Скраме нет этой сущности. Вы в курсе, что "Product Owner — это один человек, а не комитет."?
что- то я чувствую седину на голове, а когда скрам стали называть фреймворком?
это же инструмент для самоудовлетворения эффективных гумманитариев, т.е. формально, это методолия
чаще всего последовательность — BA -> UI -> Dev -> QA.Такой подход противоречит незыблемой истине: чем раньше QA вовлекается в процесс разработки, тем дешевле обходится исправление багов.
либо найти способ обойти это (напр. замена QA автотестамиЭто одно из распространенных заблуждений: «сейчас мы заменим всех ручных тестировщиков QA-автоматизаторами и заживем весело и сча́стливо».
Но есть и тёмная сторона работы короткими (например недельными) спринтами.Недельные спринты? Не представляю, как такое возможно.
Такой подход противоречит незыблемой истине: чем раньше QA вовлекается в процесс разработки, тем дешевле обходится исправление багов.
Всё верно, но часто эта незаблемая истина разбивается о суровую реальность - тестировщики на раннем этапе привлекаются для описания DoD для стори, может быть еще для DoR, и собственно на этом все до тех пор пока разработчик не переместит эту задачу на доске в колонку "ready to test". Если только работа не организована по процессу Test Driven Development, но я честно говоря не встречал рабочего симбиоза TDD и Scrum
Недельные спринты? Не представляю, как такое возможно.
Даже на Хабре можно найти материалы по такой работе. Видимо кому-то удаётся, либо команда не парится подсчетом временных затрат на митинги, либо планируют и проводят демо/ретро как-то очень быстро.
Почему Scrum не надо применять там, где не надо — ограничения и допущения фреймворка