Про Scrum часто можно услышать фразы вроде «православный Scrum», «мы используем best practices из Scrum» или «что почти всегда остается» от техник Scrum при его реализации.
Говоря это, подразумевают, что Scrum — это некоторая эзотерическая методика, которая неприменима в реальной жизни по той или иной причине. Например потому что «для скрам нужно очень много бабла, а мы должны жить по средствам» или «в Scrum разработчики должны быть супер универсальными, а у нас таких нет». А раз так — делается вывод, что «нужно думать головой», и все нужно делать по-своему. В результате такого подхода в рабочем процессе появляются некоторые улучшения, но в целом ничего не меняется, что еще больше убеждает в том что Scrum — это фантазии не имеющие отношения к реальному миру. Это не так.
Практически все кто пытаются внедрить Scrum совершают две ключевые ошибки. Во-первых, пытаются внедрить Scrum только в разработке, не меняя отношения с бизнесом, что гарантирует провал затеи. Во-вторых, Scrum пытаются внедрить частично, что также делает затею безнадежной.
В этом посте я расскажу почему Scrum нужно внедрять в разработке, только добившись поддержки этой идеи во всей компании.
Наиболее точное описание Scrum вынесено на титульный лист Scrum Guide.
Scrum — это правила игры.
Scrum — это не только описание процесса (planning, daily, review, retro), но и определение ролей участников игры, их отношений друг с другом и ценностей которые они разделяют.
Например, шахматы. Два игрока перемещают фигуры на поле. Один — только белые. Другой — только черные. Есть очередность ходов и правила, по которым ходит конь и пешка. В серьезные шахматы играют на время.
Что будет если игроки заявляют, что играют в “шахматы”, а на самом деле продолжат играть в шашки шахматными фигурами? Что будет, если, играя в “шахматы”, один игрок будет следовать правилам настоящих шахмат, а второй будет играть в “Чапаева”?
Scrum Guide — продуманный, разумный, глубокий, сбалансированный, сложный для понимания документ. К текущей редакции 2016 года ему более 20 лет (Scrum был публично анонсирован в 1995), при этом его объем всего 17 страниц. Достаточно ли его одного, чтобы организовать работу компании? Нет, как и шахматных правил недостаточно, чтобы научиться играть хорошо.
В то же время Scrum Guide не появился из вакуума и в действительности основывается на принципах и техниках организации работы, выработанных в производстве и доказавших свою состоятельность на практике. История знает примеры применения теоретических принципов на практике с разной степенью успешности.
Хенниг Бранд, основываясь на принципах алхимии, пытался получить золото, выпаривая воду из мочи. Основная идея была в том, что и то, и другое золотистого цвета. Нельзя сказать, что затея полностью провалилась. В результате он в 1669 году получил фосфор, который, как и золото, имеет определенную коммерческую ценность. Но это все же была чистая удача. Построенный на этих принципах “стартап”, хотя и принес владельцу поначалу некоторый доход, в целом быстро провалился и был продан за сравнительно небольшую сумму.
С другой стороны, Гемфри Деви, основываясь на принципах электролиза, в 1807 году открыл калий, натрий, барий и кальций (И это далеко не полный список химических элементов им открытых). Трудно назвать его результат иначе как закономерным. Что, впрочем, не умаляет его личного таланта, упорства и бесстрашия.
Элияху М. Голдратт, признанный гуру теории бизнес менеджмента, автор Теории Ограничений, в книге «The Goal» объясняет техники поиска и устранения узких мест в производственном процессе. В «Isn’t it Obvious?» он рассказывает о том, как увеличить продажи, сократив количество отсутствующих позиций наиболее популярных товаров за счет реорганизации работы системы магазина-склада.
Его теории объединяет идея, что для достижения реальных результатов для компании, все эти процессы должны быть реорганизовывать одновременно, в комплексе и с учетом интересов всех сторон. Эту мысль он высказывает в книге, подводящей итог предыдущим, «Beyond the Goal». Парадокс заключается в том, что оптимизация только части процессов компании, например, только разработки, не только не приведет к росту бизнеса в целом, но и может негативно сказаться на сотрудниках подразделения, добившегося существенных улучшений в продуктивности своей работы.
Это в полной мере относится к Scrum. Внедрять его только в разработке, не достигнув понимания и согласия работы по Scrum во всей компании — заведомо плохая идея. Да, техники Scrum позволяют существенно расширить возможности разработки. Это позволит быстро и качественно выпустить множество новых функций приложения… которые в результате будут совершенно не нужны пользователям. “Ваш продукт слишком сложный, мы не смогли разобраться, грустный смайлик”. Результат — недовольство со стороны бизнеса и разочарование на стороне разработки.
Прежде чем менять что либо в процессе разработки, необходимо добиться полного признания Scrum всеми в компании. В частности это требует общего принятия ценностей Scrum (Scrum Guide, Scrum Values: commitment, courage, focus, openness and respect.): исполнительность, смелость, сфокусированность, открытость и уважение.
Пренебрегая ценностями Scrum, легко уничтожить все выгоды которые он может дать.
Если владелец бизнеса не уважает право Product Owner’а принимать решения по развитию продукта и навязывает ему конкретный план действий, вся Scrum-команда лишается возможности быстро адаптироваться, поскольку не сможет принять никакие решения самостоятельно.
Если Product Owner не будет исполнять обязательство по увеличению ценности продукта, что является единственной его ответственностью, как он сможет сохранить доверие со стороны владельцев бизнеса?
Если Product Owner не будет иметь смелости менять продукт и пробовать что-то новое, как он сможет добиться увеличения ценности продукта? Ведь любое улучшение — это в конечном итоге изменение.
Если Product Owner не будет уважать право Development Team на самоорганизацию, и на ежедневной основе будет вмешиваться в работу команды, постоянно меняя планы и контролируя все этапы работы, Development Team не сможет улучшить свою производительность. Результат ее работы будет стабильно мизерным и посредственным.
Если Development Team не будет исполнять обещания по достижения целей взятых в спринт, как она сможет сохранить самостоятельность и доверие со стороны Product Owner?
Если Scrum Team не сумеет сфокусировать свою работу на конкретной цели для конкретного спринта, а вместо этого будет распылять усилия по множеству направлений, как она добьется ощутимых результатов? А если от работы не будет видно отдачи, пусть и негативной, как можно будет понять, стоит ли дальше развивать выбранное направление или наоборот нужно вернуть все, как было, и выкинуть то, что сделано. А на то чтобы уметь выкидывать из продукта то, что было сделано, но оказалось ненужным, тоже нужна смелость и решительность.
Если все стороны не будут открыты друг другу в тех проблемах, с которыми они сталкиваются и будут скрывать трудности коммерческого или технического плана, это все равно со временем станет известно. Но доверие и уважение будет потеряно.
Недостаточно просто сказать “да, мол, мы все понимаем, что такое Scrum и будем действовать по его принципам”. Прежде всего всем нужно прочитать Scrum Guide. Серьезно, нужно прочитать. Возникшие вопросы и недопонимания нужно обсудить и согласовать. Когда все конфликты будут разрешены, каждая из сторон должна прямо и недвусмысленно заявить, как она собирается работать по Scrum, либо взаимодействовать со Scrum командами. И только тогда можно будет начинать действовать, и действовать нужно решительно и незамедлительно.
Для достижения общего понимания процесса все должны придерживаться единой терминологии. Хотя это кажется мелочью и формализмом, это действительно важно. Если владелец бизнеса называет Product Owner’а “Продукт-менеджером”, разработчики “начальством”, а сам Product Owner величает себя, например, “Императором”, можно ли говорить о том, что достигнуто взаимопонимание?
Достижение общей стратегии работы компании по Scrum — важная и сложная задача. Без ее решения двигаться дальше бессмысленно. Тем не менее она выполнима. Но это лишь первый шаг, и трудности только начинаются.
В следующем посте я постараюсь подробнее раскрыть типичные ошибки при реализации Scrum в разработке, причины, по которым они сводят пользу от Scrum к нулю и способы их исправления.
Дмитрий Мамонов
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Младший оператор баш консоли
Говоря это, подразумевают, что Scrum — это некоторая эзотерическая методика, которая неприменима в реальной жизни по той или иной причине. Например потому что «для скрам нужно очень много бабла, а мы должны жить по средствам» или «в Scrum разработчики должны быть супер универсальными, а у нас таких нет». А раз так — делается вывод, что «нужно думать головой», и все нужно делать по-своему. В результате такого подхода в рабочем процессе появляются некоторые улучшения, но в целом ничего не меняется, что еще больше убеждает в том что Scrum — это фантазии не имеющие отношения к реальному миру. Это не так.
Практически все кто пытаются внедрить Scrum совершают две ключевые ошибки. Во-первых, пытаются внедрить Scrum только в разработке, не меняя отношения с бизнесом, что гарантирует провал затеи. Во-вторых, Scrum пытаются внедрить частично, что также делает затею безнадежной.
В этом посте я расскажу почему Scrum нужно внедрять в разработке, только добившись поддержки этой идеи во всей компании.
Scrum как Игра
Наиболее точное описание Scrum вынесено на титульный лист Scrum Guide.
Scrum — это правила игры.
Scrum — это не только описание процесса (planning, daily, review, retro), но и определение ролей участников игры, их отношений друг с другом и ценностей которые они разделяют.
Например, шахматы. Два игрока перемещают фигуры на поле. Один — только белые. Другой — только черные. Есть очередность ходов и правила, по которым ходит конь и пешка. В серьезные шахматы играют на время.
Что будет если игроки заявляют, что играют в “шахматы”, а на самом деле продолжат играть в шашки шахматными фигурами? Что будет, если, играя в “шахматы”, один игрок будет следовать правилам настоящих шахмат, а второй будет играть в “Чапаева”?
Scrum Guide — продуманный, разумный, глубокий, сбалансированный, сложный для понимания документ. К текущей редакции 2016 года ему более 20 лет (Scrum был публично анонсирован в 1995), при этом его объем всего 17 страниц. Достаточно ли его одного, чтобы организовать работу компании? Нет, как и шахматных правил недостаточно, чтобы научиться играть хорошо.
В то же время Scrum Guide не появился из вакуума и в действительности основывается на принципах и техниках организации работы, выработанных в производстве и доказавших свою состоятельность на практике. История знает примеры применения теоретических принципов на практике с разной степенью успешности.
Хенниг Бранд, основываясь на принципах алхимии, пытался получить золото, выпаривая воду из мочи. Основная идея была в том, что и то, и другое золотистого цвета. Нельзя сказать, что затея полностью провалилась. В результате он в 1669 году получил фосфор, который, как и золото, имеет определенную коммерческую ценность. Но это все же была чистая удача. Построенный на этих принципах “стартап”, хотя и принес владельцу поначалу некоторый доход, в целом быстро провалился и был продан за сравнительно небольшую сумму.
С другой стороны, Гемфри Деви, основываясь на принципах электролиза, в 1807 году открыл калий, натрий, барий и кальций (И это далеко не полный список химических элементов им открытых). Трудно назвать его результат иначе как закономерным. Что, впрочем, не умаляет его личного таланта, упорства и бесстрашия.
Scrum и теория ограничений Голдратта
Элияху М. Голдратт, признанный гуру теории бизнес менеджмента, автор Теории Ограничений, в книге «The Goal» объясняет техники поиска и устранения узких мест в производственном процессе. В «Isn’t it Obvious?» он рассказывает о том, как увеличить продажи, сократив количество отсутствующих позиций наиболее популярных товаров за счет реорганизации работы системы магазина-склада.
Его теории объединяет идея, что для достижения реальных результатов для компании, все эти процессы должны быть реорганизовывать одновременно, в комплексе и с учетом интересов всех сторон. Эту мысль он высказывает в книге, подводящей итог предыдущим, «Beyond the Goal». Парадокс заключается в том, что оптимизация только части процессов компании, например, только разработки, не только не приведет к росту бизнеса в целом, но и может негативно сказаться на сотрудниках подразделения, добившегося существенных улучшений в продуктивности своей работы.
Это в полной мере относится к Scrum. Внедрять его только в разработке, не достигнув понимания и согласия работы по Scrum во всей компании — заведомо плохая идея. Да, техники Scrum позволяют существенно расширить возможности разработки. Это позволит быстро и качественно выпустить множество новых функций приложения… которые в результате будут совершенно не нужны пользователям. “Ваш продукт слишком сложный, мы не смогли разобраться, грустный смайлик”. Результат — недовольство со стороны бизнеса и разочарование на стороне разработки.
Игра для всех
Прежде чем менять что либо в процессе разработки, необходимо добиться полного признания Scrum всеми в компании. В частности это требует общего принятия ценностей Scrum (Scrum Guide, Scrum Values: commitment, courage, focus, openness and respect.): исполнительность, смелость, сфокусированность, открытость и уважение.
Пренебрегая ценностями Scrum, легко уничтожить все выгоды которые он может дать.
Если владелец бизнеса не уважает право Product Owner’а принимать решения по развитию продукта и навязывает ему конкретный план действий, вся Scrum-команда лишается возможности быстро адаптироваться, поскольку не сможет принять никакие решения самостоятельно.
Если Product Owner не будет исполнять обязательство по увеличению ценности продукта, что является единственной его ответственностью, как он сможет сохранить доверие со стороны владельцев бизнеса?
Если Product Owner не будет иметь смелости менять продукт и пробовать что-то новое, как он сможет добиться увеличения ценности продукта? Ведь любое улучшение — это в конечном итоге изменение.
Если Product Owner не будет уважать право Development Team на самоорганизацию, и на ежедневной основе будет вмешиваться в работу команды, постоянно меняя планы и контролируя все этапы работы, Development Team не сможет улучшить свою производительность. Результат ее работы будет стабильно мизерным и посредственным.
Если Development Team не будет исполнять обещания по достижения целей взятых в спринт, как она сможет сохранить самостоятельность и доверие со стороны Product Owner?
Если Scrum Team не сумеет сфокусировать свою работу на конкретной цели для конкретного спринта, а вместо этого будет распылять усилия по множеству направлений, как она добьется ощутимых результатов? А если от работы не будет видно отдачи, пусть и негативной, как можно будет понять, стоит ли дальше развивать выбранное направление или наоборот нужно вернуть все, как было, и выкинуть то, что сделано. А на то чтобы уметь выкидывать из продукта то, что было сделано, но оказалось ненужным, тоже нужна смелость и решительность.
Если все стороны не будут открыты друг другу в тех проблемах, с которыми они сталкиваются и будут скрывать трудности коммерческого или технического плана, это все равно со временем станет известно. Но доверие и уважение будет потеряно.
Недостаточно просто сказать “да, мол, мы все понимаем, что такое Scrum и будем действовать по его принципам”. Прежде всего всем нужно прочитать Scrum Guide. Серьезно, нужно прочитать. Возникшие вопросы и недопонимания нужно обсудить и согласовать. Когда все конфликты будут разрешены, каждая из сторон должна прямо и недвусмысленно заявить, как она собирается работать по Scrum, либо взаимодействовать со Scrum командами. И только тогда можно будет начинать действовать, и действовать нужно решительно и незамедлительно.
Для достижения общего понимания процесса все должны придерживаться единой терминологии. Хотя это кажется мелочью и формализмом, это действительно важно. Если владелец бизнеса называет Product Owner’а “Продукт-менеджером”, разработчики “начальством”, а сам Product Owner величает себя, например, “Императором”, можно ли говорить о том, что достигнуто взаимопонимание?
Достижение общей стратегии работы компании по Scrum — важная и сложная задача. Без ее решения двигаться дальше бессмысленно. Тем не менее она выполнима. Но это лишь первый шаг, и трудности только начинаются.
В следующем посте я постараюсь подробнее раскрыть типичные ошибки при реализации Scrum в разработке, причины, по которым они сводят пользу от Scrum к нулю и способы их исправления.
Дмитрий Мамонов
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Младший оператор баш консоли
Поделиться с друзьями
Комментарии (25)
den_golub
19.11.2016 00:51Если вы полностью читали доку или хотя бы википедию, то существует понятие Daily Scrum, вот оно и отвечает за то о чем вы говорите.
ServPonomarev
19.11.2016 08:56+2Если владелец бизнеса не уважает право Product Owner’а принимать решения по развитию продукта и навязывает ему конкретный план действий, вся Scrum-команда лишается возможности быстро адаптироваться, поскольку не сможет принять никакие решения самостоятельно.
Полное очарование. Если бизнес не понимает, зачем ему скрам, а команда, следуя моде, давит на бизнес — они расстанутся в среднесрочной перспективе. А чаще — в краткосрочной.
excoder
19.11.2016 18:26+1Скрам — это реальный мир бизнеса скрам-мастеров. «Скрам нужен вам целиком, и значит вам нужен я».
hoack
21.11.2016 20:59Нельзя забывать, что Скрам подходит далеко не всем и далеко не всегда. В определенных случаях подходят другие Agile-методики (Канбан, Скрамбан); в других случаях Agile вообще не подходит.
dm_wrike
22.11.2016 19:26Вы отчасти правы. Scrum действительно подходит не всем, поскольку он требует существенного изменения в подходе к работе, а многие не готовы или не хотят что то менять в своем рабочем процессе. Это проблема.
Что касается «технической» применимости, я с вами не согласен. В разработке скрам будет работать с пользой всегда. Отговорки вроде «у нас не может быть scrum потому что у нас web-приложение/мобильное приложение/банковское приложение» — это всего лишь отговорки.
в других случаях Agile вообще не подходит.
Agile очень расплывчатый термин, что именно вы имеете в виду по agile в данном контексте не понятно.hoack
22.11.2016 20:32Нет, дело не только в готовности к переменам. Agile — под которым я имею в виду появившуюся в начале 2000-х идеологию разработки — подразумевает итеративность процесса и его адаптивность. Это прекрасно работает для определенного класса проектов, в которых короткие итерации позволяют успевать адаптироваться к стремительно меняющемуся рынку, а неполная версия продукта имеет смысл: бизнес-разработки, enterprise, разработки игр, веб… С другой стороны, есть классы проектов, для которых подобный подход нехорош, поскольку предполагает динамическое формирование цели. Я, правда, в этом не специалист, но думаю, что для разработки встроенного ПО, систем управления технологическими процессами и т.п. такого рода методологии не годятся.
Теперь давайте конкретно про Скрам. Он очень хорошо работает, когда основная работа состоит в разработке. Если же параллельно с разработкой идет активная поддержка, или если речь идет о часто меняющихся приоритетах, то Скрам начинает сбоить, по причине необходимости на ходу менять спланированный спринт. Канбан гораздо лучше приспособлен к таким ситуациям, поскольку плана никакого нет, а есть просто ограниченная по размеру очередь задач. В моей команде, например, мы пришли к гибридному варианту типа Скрамбана — Канбан с наложенными двухнедельными циклами релизов и планирования.dm_wrike
23.11.2016 01:05+1Теперь давайте конкретно про Скрам. Он очень хорошо работает, когда основная работа состоит в разработке.
Да, в Scrum Guide вопрос разработки продукта параллельно с его поддержкой проработан плохо.
Если быть откровенным на эту тему там нет ничего конкретного.
Более того, в книге Сазерленда «Scrum: The Art of Doing Twice the Work in Half the Time», приводятся примеры успешного применения Scrum, но какие:
1. Разработка информационной системы для FBI — «под ключ»,
2. Ремонт кухни — тоже «под ключ»
Были и другие примеры, но на память приходят эти два, и там точно не было ничего про проекты включающие цикл поддержки. Такое ощущение что авторы Scrum сознательно избегают эту проблемную тему.
При этом с 1995 года ситуация сильно изменилась, и сейчас абсолютное большинство проектов
имеют достаточно короткий цикл релиза (в среднем около недели, редко больше месяца ref: JRebel делали исследование на эту тему). Мы все ведем разработку и поддержку продукта параллельно. Сейчас никого не удивишь исправив баг в тот же день.
Скрам начинает сбоить, по причине необходимости на ходу менять спланированный спринт.
1. Менять план спринта в процессе — нормально. Неизменной должна оставаться цель. Более того, если в процессе спринта вы не вносите никакие коррективы в план, это признак проблемы.
2. Главное в спринте — цель. Конкретный план полученный на этапе планирования это лишь примерный способ ее достижения.
3. Если для достижения цели спринта вам нужно 100% ресурсов спринта, скорее всего цель будет провалена.
Если на достижение цели спринта планируется от 30% до 70% ресурсов спринта это нормально.
Остальные ресурсы можно запланировать на другие полезные работы, от которых в спринте можно будет отказаться. Это запас прочности.
4. Да, у всех есть поддержка, можно планировать 20%-40% ресурсов на поддержку в каждый спринт. Если ресурсы запланированные на поддержку будут оставаться, можно будет использовать их на цель спринта или просто сделать что то полезное. Если на поддержку будет требоваться больше ресурсов — это повод задуматься о больших проблемах с качество и начать решать именно эту проблему в первую очередь.
5. Вы говорите что работаете по 2-х недельным спринтам. Это само по себе сложно. За две недели очень трудно получить какой то значительный результат, особенно если существенную часть времени отнимает текучка. Может быть есть смысл рассмотреть спринты длительностью 3-и или 4-ре недели.
6. При этом вы говорите о часто меняющихся приоритетах. Это не звучит как аргумент.
Выбрать одну цель на ближайшие две недели и не менять ее — можно.
Менять стратегию два раза в неделю — безумие. Скорее всего у вас не все так плохо, вы преувеличиваете.
7. К слову, Kanban это не техника Agile, это техника бережливого производства (lean), появилась она где то в 1950-х.
Я ни в коем случае не говорю что Kanban это плохая идея вообще, часто это может быть разумный тактический прием.
Тем не менее, из всех приемов lean, техника Kanban хоть и наиболее проста во внедрении но при этом и самая примитивная, из разряда «если не получается ничего лучше, давайте хотя бы Kanban».
Возможно, придя к идее «скрамбана» вы на самом деле упустили многое важное в Scrum,
и вместо того что бы постоянно искать и исправлять проблемы в вашем процессе вы решили
что Kanban-а будет достаточно.
P.S. спасибо за хороший комментарий.
rumkin
23.11.2016 12:10+1В этом посте я расскажу почему Scrum нужно внедрять в разработке, только добившись поддержки этой идеи во всей компании.
Да что уж там. Во всем мире! То о чем вы говорите – не имеет отношение к скраму. Это иерархический хаос. Когда разработчику выставляют задания все подряд, его продуктивность устремляется к нулю. По какой бы методологии вы не работали, но разработчик должен подчиняться только непосредственному начальнику и только через него получать задания и уж точно не заниматься приемом входящих заявок в процессе разработки. В таком случае скрам можно будет внедрить в системе, которая работает возможно вообще без системы.
PkXwmpgN
У меня вопрос к людям, которые занимаются скрамом
За счет чего именно скрам распологает команду к творчеству?
den_golub
Я конечно не занимался скрамом с института, но скрам не только фрейм, это и набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
А вообще все творчество начинается на этапе спринтов, команда во время спринта работает независимо и основная цель — выполнить все задачи поставленные Мастером. А в силу того, что каждый член команды универсален, то решение задач и представляю собой творческий процесс.
Вот ссылка тут все довольно понятно.
Но стоит отметь, что у всех по разному.
PkXwmpgN
Это я понимаю, это общие слова, которые написанны в руководстве
Основное отличие творческого процесcа — это уникальность.
Один из вариантов определения творческого мышления.
Как это можно ограничить четкими временными рамками? И немного переформулирую, есть ли в скраме индивидуальный творческий процесс?
den_golub
Четкие временные рамки приходят обычно с опытом, опять же зависят они от профессионализма каждого члена команды. Да и сам скрам использовать обычно решаются только те кто уже сработался. И не стоит забывать что при работе над любой задачей обычно каждый из членов команды сообщает тимлиду сколько времени приблизительно будет затрачено, после чего формируется список на спринт. Да не всегда все идеально, появляются отставания, опять же в документации написано про это и про то как с этим бороться.
Скорее нет, чем да. Но никто не мешает творить главное чтоб это не замедляла общую работу команды во время спринта. По крайней мере у нас так было.
PkXwmpgN
Например, есть какая-то задача, и четкого решения у тебя на данный момент нет.
Сначала ты пытаешь, пробуешь, эксперементируешь, более детально изучаешь предметную область, строишь какие-то прототипы. Но, вот не пулучается добиться того, чем ты будешь на данный момент доволен.
Потом проходит какое-то время и ты очень четко начинаешь осознавать что нужно делать. Это невероятное ощущение. Я думаю, программисты меня поддержат, у многих такое бывает.
Затем с новыми силами, окрыленный родившейся идеей, получаешь решение (иногда не получаешь). И это решение уникально.
Вот, что я понимаю под индивидуальным творческим процессам.
den_golub
В скраме обычно нет такого чтоб строить прототипы и изучать предметную область, это все делается в при подготовке. Во время спринтов обычно все прозаичней, нет если вы конечно изучаете предметную область параллельно и тебе приходит ты можешь ее реализовать, возможно она выживет, для этого обычно используют системы контроля версии и подобные вещи.
PkXwmpgN
Ну т.е. на планирование перед спринтом, команда общими силами декомпозирует задачи, находит оптимальное решение, строит спринт, все члены команды это решение четко понимают, определятся срок, назначается исполнитель. В этом, заключается профессионализм и сработанность команды и именно это подразумевается под творческой разработкой продуктов из определения.
den_golub
Не совсем так, но почти.
PkXwmpgN
А что не так? Я вас не троллю. Я просто хочу понять определение из официального руководства.
Какая часть спектра тех возможностей, которые предоставляет скрам, поощряет творчество и что именно под этим творчеством подразумевается.
den_golub
Просто исполнитель он не один, это вся команда разработчиков, планирует в основном Скрам-мастер. А под творчеством скорее имеется в виду возможность каждого привносить свои идей для решения той или иной задачи для пула, ведь сколько людей столько и способов решить задачу, иногда их можно объединить иногда применить и то, и другое. На самом деле это так не объяснить.
PkXwmpgN
А в какой момент можно привносить свои идеи, я могу по середине спринта изменить решение обговоренное, на планирование? Скажем, предложить более эффективное решение (вся команда согласится что решение более эффективное), но реализация, которого потребует больше запланированного времени, хотя бы потому что половина первоначально решения уже сделана?
den_golub
Промахнулся веткой. Читайте ниже.
funca
Обычно скрам-мастер не вовлекается в планирование в такой роли. Его зона ответственности это сам scrum-процесс, как форма организации деятельности. Он обучает участников правилам игры, следит за тем, чтобы правила соблюдались, и напоминает, если что-то идет не так. Решений по существу он не принимает. Работу при планировании делают Product Owner и команда.
dm_wrike
Для сравнения, если разработка устроена в проектном стиле.
Есть менеджер проекта, у него есть план сделать A, Б, Ц.
Допустим он обсуждает этот план с Lead команды.?Lead прикидывает что нужно делать, нарезает работу по разработчикам.
Разработчики пишут код, фиксят баги. Немного утрировано, но в целом так часто бывает.
Согласитесь, не слишком располагает к творчеству со стороны разработчиков.
В плане творчества и личного вклада в конечный продукт в scrum задумано довольно много:
1. Все разработчики в scrum команде имеют одну должность — разработчик. Не выделяются junior/senior, backend/frontend/qa. Это важно, в частности, для того что бы каждый имел право высказать свою точку зрения по любому вопросу на равне с другими. Пример: «если Вася, по опыту junior, предлагает использоваться тестовый фреймфорк X, это нормально. Даже если в команде есть более сильные разработчики. Никто не имеет права отказать кому то высказать мнение, только по тому что у него мало опыта либо что то еще. Другое дело, насколько конкретное предложение будет полезно, может да а может нет.»
2. В планировании работы принимает участия вся команда (Dev Team, Scrum Master и Product Owner), при этом задача Product Owner предложить наиболее ценные направления работ, но что и как конкретно делать решает Dev Team. Фактически разработчики, в определенных пределах, имеют возможность выбирать чем именно они хотят заняться.
3. На ревью работы перед stakeholders (в частности, перед владельцами бизнеса) результат работы показывает вся команда (Dev, SM и PO), и опять же вся команда участвует в обсуждении результатов спринта и оценке дальнейший приоритетов. Опять же каждый разработчик имеет возможность высказаться и повлиять на дальнейшую разработку.
Есть и тонкости. В книге «Driving Honda» приведен хороший пример.
Когда в компании 3M, «креативном» подразделение General Electric,
(например за ней зарегистрирована торговая марка Scotch) внедрили TQP и 6Signma,
результаты исследовательской деятельности стали оцениваться на регулярной, периодической, основе.
Результат — приоритет получили исследования дающие быстрый результат.
Конечно, при этом фундаментальные разработки требующие существенного
времени на исследования и не гарантирующие прибыль в краткосрочной перспективе,
да и успешный результат вообще, — были задвинуты на второй план.
Итог — за 5 лет компания перестала быть технологическим лидером
(потом они поменяли процесс и все наладилось, но это другая история).
Так же и в scrum, регулярные спринты и их оценка сами по себе хорошие идеи, но к сожалению такой подход
может привести к тому что сиюминутные приоритеты всегда будут ставиться выше долгосрочных.
Что самой собой приведет к провалу в долгосрочной перспективе.
Не то чтобы в scrum требовалось «всегда ставить краткосрочную выгоду выше долгосрочной»,
это не так. Но как то оно самом собой к этому идет. Бороться с этим можно только на уровне здравого смысла,
общей культуры разработки и общего приоритета компании работать успешно и долго.
P.S. А вот Daily Scrum к креативности имеет крайне косвенное отношение,
важно понимать что если есть хорошая идея — то ее стоит высказать в любой подходящий момент.
PkXwmpgN
Из ваших пунктов следует, что творчество сводится к процессу "играть в игру" всей командой. Но сама разработка (это может быть часто исследование), культура кода, с технической стороны, глазами програмиста — вторична. Просто потому что это процесс индивидуальный и с точки зрения краткосрочной выгоды он не интересен.
dm_wrike
Не совсем, я говорю о том что в Scrum это само собой не получается и требует личных и целенаправленных усилий,
иногда даже «против течения». Но результат того стоит.
funca
Scrum это фреймворк для управления командой исполнителей, нацеленный на обеспечение решения тактических задач в рамках текущего проекта.
По моим ощущениям, данная система очень похожа на те, что описываются руководствах по боевой работе армейских подразделений. Когда есть SMART-цель, задача и приказ. А креативный подход, творчество и смекалка со стороны исполнителей конечно же всячески приветствуются, если они позволяют как-нибудь оптимизировать решение поставленной задачи.
Но если вы мечтаете, что-то творить выходящее за рамки конкретных задач спринта — нет, это не про скрам. Это абсолютно прямо противоположная затея. Так же Scrum не предназначен для стратегического планирования, планирования инвестиционной деятельности, целеполагания и еще многих других важных для организации штук.