Comments 15
Часто сталкиваюсь с подобным на практике консультанта, поэтому небольшой перевод.
"продукт работает в сложных рыночных условиях" — зачем изучать рынок и потребности клиентов, давайте просто начнем, авось да небось получится
"все понимают, что четкое ТЗ на продукт не сформировать" — и нечеткое тоже, потому что это требует ответственности и компетентности
"очень важно, чтобы бизнес был вовлечен" — только тогда бизнес будет оплачивать карусель из спринтов
Добавлю, что аджайл неплохо работает для сопровождения уже существующего продукта, когда имеется стабильный входящий поток багов и небольших изменений.
"продукт работает в сложных рыночных условиях" — зачем изучать рынок и потребности клиентов, давайте просто начнем, авось да небось получится
"все понимают, что четкое ТЗ на продукт не сформировать" — и нечеткое тоже, потому что это требует ответственности и компетентности
"очень важно, чтобы бизнес был вовлечен" — только тогда бизнес будет оплачивать карусель из спринтов
Добавлю, что аджайл неплохо работает для сопровождения уже существующего продукта, когда имеется стабильный входящий поток багов и небольших изменений.
В корпоративном мире принято давать деньги под детально просчитанные требования и экономическое обоснование. Но рост сложности продуктов (это, например, большое количество факторов, влияющих на функциональные требования, высоко конкурентный цифровой рынок, отсутствие экспертизы по новым для рынка продуктам) делает такой подход скорее вредным. Менеджеры потом едва ли прикрываются ТЗ и рекомендациями разного рода «консультантов» в случае провала.
Agile в этом плане намного честнее, он предполагает гораздо более строгий контроль, и направлен на достижение результата, а не на соблюдение процесса. Предпринимателю приходится подписываться под конкретные метрики, а в случае неудачи брать всю ответственность на себя. Это неслабо повышает уровень осознанности и мотивирует всю продуктовую команду на поиск оптимальных решений. Меня всегда вдохновляли такие люди.
Чеклист, собственно, для того, чтобы снизить риск ошибок на старте. В том числе и ошибок с выбором подхода к разработке. Сейчас, после последнего запуска скрам команды, я добавил бы еще один пункт, но об этом уже в следующий раз =)
Agile в этом плане намного честнее, он предполагает гораздо более строгий контроль, и направлен на достижение результата, а не на соблюдение процесса. Предпринимателю приходится подписываться под конкретные метрики, а в случае неудачи брать всю ответственность на себя. Это неслабо повышает уровень осознанности и мотивирует всю продуктовую команду на поиск оптимальных решений. Меня всегда вдохновляли такие люди.
Чеклист, собственно, для того, чтобы снизить риск ошибок на старте. В том числе и ошибок с выбором подхода к разработке. Сейчас, после последнего запуска скрам команды, я добавил бы еще один пункт, но об этом уже в следующий раз =)
Все гораздо проще, нужен просто скрам-мастер хорошо и правильно обученный и команда профессионалов. Остальное это просто фантазии на вольную тему.
Было бы просто, если бы где нибудь этому учили… но нет. Содержимое чеклиста получено из боли и страданий личного опыта =)
Не надо через боль, нужно сначала обучится, https://www.scrum.org/. В штатах эта профессия в топе высокооплачиваемых профессий наряду с прокурорами, инженерами т.п. https://www.forumdaily.com/top-25-samyx-vysokooplachivaemyx-professij-v-ssha/. Боль и страдания уже прошли предыдущие поколения разработчиков, которые уже выработали успешные рабочие модели.
Я больше пяти лет уже в этой профессии, учусь регулярно несколько раз в год. Любой тренер вам скажет, что скрам — фреймворк эмпирический, это значит, что значительную часть вашего процесса будет составлять личный опыт. Успешные рабочие модели уникальны для компании и рыночного окружения, именно поэтому нельзя скопировать, например, операционную модель Spotify, или любой другой успешной фирмы.
Скрам Фреймворк это достаточно жёсткий, с четко прописанными артефактами и событиями, каждое из который имеет достаточно глубокий смысл. Скрам это одна и та же модель, которая применяется для разных проектов (от ремонта до разработки ПО). И знать его надо как воинский устав, ибо высунулся из окопа полголовы снесло (проект забуксовал, упёрся в бесконечность, команда разваливается или начинает заниматься не тем чем нужно). Это жёсткий каркас в который гибко помещают запутанную среду (проекты со слабо сформулированными требованиями, командой и т.п.), для которой он и был создан. Я поэтому и написал, чтобы не было зомби-скрама, нужен Скрам мастер который обучен всем этим жёстким артефактам и событиям, и как хорошим инструментом эмпирически вытачивает успешные проекты. А зомби скрам это нарушение правил скрама, из-за неполного его применения. Там возьму чуть чуть из скрама а это нам не нравится и мы это не будем применять, вот и зомби скрам. Скрам это инструмент его — не надо переделывать и гибко изменять, его надо изучить понять, и умело применять в запутанных средах.
Scrum (skrʌm; англ. scrum «схватка») — Фреймворк гибкой разработки ПО. Фреймворк основан на эмпирическом методе и предназначен для разработки продуктов высокой ценности в запутанной среде.
Неполное применение скрама это просто следствие недообучения или недопонимания скрама, либо просто отсутствие скрам мастера, который и наводит порядок в хаосе организации проекта с помощью этого метафреймворка и фокусирует продакт овнера и всю команду на результате.
Scrum (skrʌm; англ. scrum «схватка») — Фреймворк гибкой разработки ПО. Фреймворк основан на эмпирическом методе и предназначен для разработки продуктов высокой ценности в запутанной среде.
Неполное применение скрама это просто следствие недообучения или недопонимания скрама, либо просто отсутствие скрам мастера, который и наводит порядок в хаосе организации проекта с помощью этого метафреймворка и фокусирует продакт овнера и всю команду на результате.
Я не устаю с этого всего смеяться: знаменитый Agile-манифест, одной из основных ценностей которого была «Готовность к изменениям», а гибкость так или иначе упоминалась где-то в 5-ти пунктах из 12-ти породил вот это вот (цитаты из комментария выше): «четко прописанными артефактами и событиями», «знать его надо как воинский устав», «Это жёсткий каркас» и т.д.
Т.е. борьба с драконом (ватерфол и прочее) привела к порождению ещё более ужасного дракона. Вот так и живём.
Т.е. борьба с драконом (ватерфол и прочее) привела к порождению ещё более ужасного дракона. Вот так и живём.
в ватерфоле, можно подстраиваться к новым бизнес требованиям после каждого спринта (или там все запланировано все до релиза)?
в ватерфоле проводятся ретроспективы после каждого спринта, для адаптации командного взаимодействия (там пока все беды в релизе не вскроются никого ничего не волнует)?
в ватерфоле есть тесное взаимодействие владельца продукта с командой? (как правило овнер только в конце увидит результат)
мне кажется главная ошибка в понимании скрама, это в понимании термина «agile» (гибкости, проворности), эту гибкость воспринимают как анархию для разработчиков (как нам удобно так и будем работать), а на самом деле механизм(правила) скрама позволяет сфокусировать команду на результате (коучинг) и следить и гибко подстраиваться под бизнес требования продакт овнера (аналитика, заказчика, пользователей) эмпирически после каждого спринта, грамотно(гибко) работать с беклогом до запуска задач в спринт, помогать овнеру правильно формулировать пользовательские сценарии(истории) в беклог и т.п. Этим занимается скрам-мастер, который ведет и команду и владельца продукта и отвечает за успех всего мероприятия(проекта) )).
в ватерфоле проводятся ретроспективы после каждого спринта, для адаптации командного взаимодействия (там пока все беды в релизе не вскроются никого ничего не волнует)?
в ватерфоле есть тесное взаимодействие владельца продукта с командой? (как правило овнер только в конце увидит результат)
мне кажется главная ошибка в понимании скрама, это в понимании термина «agile» (гибкости, проворности), эту гибкость воспринимают как анархию для разработчиков (как нам удобно так и будем работать), а на самом деле механизм(правила) скрама позволяет сфокусировать команду на результате (коучинг) и следить и гибко подстраиваться под бизнес требования продакт овнера (аналитика, заказчика, пользователей) эмпирически после каждого спринта, грамотно(гибко) работать с беклогом до запуска задач в спринт, помогать овнеру правильно формулировать пользовательские сценарии(истории) в беклог и т.п. Этим занимается скрам-мастер, который ведет и команду и владельца продукта и отвечает за успех всего мероприятия(проекта) )).
Скрам это не корсет, он не сковывает движений, а помогает команде экспериментировать и раскрыться для того, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью. Знание воинского устава никому еще не помогло выиграть войну. Ниже цитата из The Scrum Guide:
«Scrum is not a process, technique, or definitive method. Rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear
the relative efficacy of your product management and work techniques so that you can
continuously improve the product, the team, and the working environment»
Зомби скрам — это формальное «внедрение» внешних признаков скрама — того самого устава с муштрой и тотальной потерей смысла. Одним обучением, или попыткой найти «правильного» скрам мастера проблему не решить (вообще поиск подходящего кандидата на эту роль — история, достойная отдельного поста). Системный фреймворк проведения изменений Дэниела Кима говорит о том, что изменение шаблонов поведения возможно только через изменение системных (организационных) структур, которые их поддерживают. Чеклист позволяет еще перед стартом проверить организацию на наличие таких структур, которые неизбежно превратят скрам команду в зомби команду, что бы вы ни делали.
«Scrum is not a process, technique, or definitive method. Rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear
the relative efficacy of your product management and work techniques so that you can
continuously improve the product, the team, and the working environment»
Зомби скрам — это формальное «внедрение» внешних признаков скрама — того самого устава с муштрой и тотальной потерей смысла. Одним обучением, или попыткой найти «правильного» скрам мастера проблему не решить (вообще поиск подходящего кандидата на эту роль — история, достойная отдельного поста). Системный фреймворк проведения изменений Дэниела Кима говорит о том, что изменение шаблонов поведения возможно только через изменение системных (организационных) структур, которые их поддерживают. Чеклист позволяет еще перед стартом проверить организацию на наличие таких структур, которые неизбежно превратят скрам команду в зомби команду, что бы вы ни делали.
) ну тогда это не скрам, а какая то своя agile-методология, которую можно назвать, например, скрампам-парампампам. Ибо несоблюдение базовых событий и артефактов скрама уже к скраму имеет небольшое отношение. Первый уровень сертификации по скраму как раз и цементирует этот каркас, другое дело если люди его не понимают и не могут адаптироватся в нем для эмпирического развития, ну так это уже более высшие ступени постижения скрама www.scrum.org, после того как они назубок знают базовые вещи, которые обкатаны под контролем большого сообщества.
то есть сначала лучше жестко выучить цифры, буквы, слова и пунктуацию, а потом эмпирически пытаться писать стихи, повести и рассказы, также и в обучении, сертификации и применении скрама, там несколько уровней
Можете написать мне в fb, я подскажу с обучением и сертификацией. Хотя по мне, ценность сертификата, как такового переоценена (все сертификации, кроме scrum.org и pmi просто подтверждают прохождение курса). В этом смысле практическая работа в скрам командах даст бОльший результат. Вы даже вопросы будете другие задавать.
Со стихами и рассказами не помогу, это в другой хаб =)))
Со стихами и рассказами не помогу, это в другой хаб =)))
Я согласен, дело не в сертификации, а в реальном обучении, сертификат это всего лишь ориентир или просто значок, а какой путь в обучении прошел человек и какой багаж знаний приобрел, чтобы получить этот значок, очень быстро выявляется в рабочих условиях. Если чеклисты и эксперименты в практической работе начинаются без обучения, вот оно и есть «зомби-скрам». Но, есть вероятность, что может быть будет изобретен какой-то новый более эффективный метафреймворк, но вероятность этого очень мала, и придется загубить немало проектов для обкатки этого нового инструмента, а потом убедить весь мир, что это лучше чем скрам.
«Демократия — наихудшая форма правления, если не считать всех остальных» У. Черчилль.
Плюс в том, что инициатива идет от людей в теме.
напомнило мне статью об «эффективных» менеджерах отсюда:
Людей третьего типа, которые сейчас есть практически на всех предприятиях, вы знаете – это те самые «эффективные» менеджеры. Они приходят на завод, чтобы получать. Но не просто получать – получать в рамках «темы». Я прошу прощения, так и не смог подобрать приличного и понятного синонима для этой «темы». Слово, само по себе, не плохое, но смысл, который в него вкладывается, не выдерживает никакой критики.
Смысл прост: увидеть популярную «тему», прочитать пару (в лучшем случае) книжек по ней, запомнить первые ходы по внедрению «темы» (как Остап Бендер знал первый ход шахматной партии), и грамотно себя «продать». По каждой составляющей есть масса информации в интернете, особенно – по «продаже», как универсальной, меж«тематической» практике.
Sign up to leave a comment.
Чеклист: запускаем SCRUM-команды и делаем прививки от зомби-скрама