Pull to refresh

Comments 27

У меня вопрос к людям, которые занимаются скрамом


Скрам (сущ.) – фреймворк, предоставляющий спектр возможностей для продуктивной и 
творческой разработки продуктов с максимально возможной ценностью и решения 
нетривиальных задач в процессе работы. 

За счет чего именно скрам распологает команду к творчеству?

Я конечно не занимался скрамом с института, но скрам не только фрейм, это и набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
А вообще все творчество начинается на этапе спринтов, команда во время спринта работает независимо и основная цель — выполнить все задачи поставленные Мастером. А в силу того, что каждый член команды универсален, то решение задач и представляю собой творческий процесс.
Вот ссылка тут все довольно понятно.
Но стоит отметь, что у всех по разному.

Это я понимаю, это общие слова, которые написанны в руководстве


Компетенций кроссфункциональной команды достаточно для выполнения полного 
объема работ. Под последним следует понимать весь комплекс работ в сочетании с 
оптимальным способом ее исполнения, необходимым для реализации бизнес‐ценности

Основное отличие творческого процесcа — это уникальность.
Один из вариантов определения творческого мышления.


  1. Подготовка — формулирование задачи; попытки её решения.
  2. Инкубация — временное отвлечение от задачи.
  3. Озарение — появление интуитивного решения.
  4. Проверка — испытание и/или реализация решения.

Как это можно ограничить четкими временными рамками? И немного переформулирую, есть ли в скраме индивидуальный творческий процесс?

Как это можно ограничить четкими временными рамками?

Четкие временные рамки приходят обычно с опытом, опять же зависят они от профессионализма каждого члена команды. Да и сам скрам использовать обычно решаются только те кто уже сработался. И не стоит забывать что при работе над любой задачей обычно каждый из членов команды сообщает тимлиду сколько времени приблизительно будет затрачено, после чего формируется список на спринт. Да не всегда все идеально, появляются отставания, опять же в документации написано про это и про то как с этим бороться.
Есть ли в скраме индивидуальный творческий процесс?

Скорее нет, чем да. Но никто не мешает творить главное чтоб это не замедляла общую работу команды во время спринта. По крайней мере у нас так было.

Например, есть какая-то задача, и четкого решения у тебя на данный момент нет.


Сначала ты пытаешь, пробуешь, эксперементируешь, более детально изучаешь предметную область, строишь какие-то прототипы. Но, вот не пулучается добиться того, чем ты будешь на данный момент доволен.


Потом проходит какое-то время и ты очень четко начинаешь осознавать что нужно делать. Это невероятное ощущение. Я думаю, программисты меня поддержат, у многих такое бывает.


Затем с новыми силами, окрыленный родившейся идеей, получаешь решение (иногда не получаешь). И это решение уникально.


Вот, что я понимаю под индивидуальным творческим процессам.

В скраме обычно нет такого чтоб строить прототипы и изучать предметную область, это все делается в при подготовке. Во время спринтов обычно все прозаичней, нет если вы конечно изучаете предметную область параллельно и тебе приходит ты можешь ее реализовать, возможно она выживет, для этого обычно используют системы контроля версии и подобные вещи.

Ну т.е. на планирование перед спринтом, команда общими силами декомпозирует задачи, находит оптимальное решение, строит спринт, все члены команды это решение четко понимают, определятся срок, назначается исполнитель. В этом, заключается профессионализм и сработанность команды и именно это подразумевается под творческой разработкой продуктов из определения.

А что не так? Я вас не троллю. Я просто хочу понять определение из официального руководства.
Какая часть спектра тех возможностей, которые предоставляет скрам, поощряет творчество и что именно под этим творчеством подразумевается.

Просто исполнитель он не один, это вся команда разработчиков, планирует в основном Скрам-мастер. А под творчеством скорее имеется в виду возможность каждого привносить свои идей для решения той или иной задачи для пула, ведь сколько людей столько и способов решить задачу, иногда их можно объединить иногда применить и то, и другое. На самом деле это так не объяснить.

А в какой момент можно привносить свои идеи, я могу по середине спринта изменить решение обговоренное, на планирование? Скажем, предложить более эффективное решение (вся команда согласится что решение более эффективное), но реализация, которого потребует больше запланированного времени, хотя бы потому что половина первоначально решения уже сделана?

Промахнулся веткой. Читайте ниже.
Обычно скрам-мастер не вовлекается в планирование в такой роли. Его зона ответственности это сам scrum-процесс, как форма организации деятельности. Он обучает участников правилам игры, следит за тем, чтобы правила соблюдались, и напоминает, если что-то идет не так. Решений по существу он не принимает. Работу при планировании делают Product Owner и команда.
Для сравнения, если разработка устроена в проектном стиле.
Есть менеджер проекта, у него есть план сделать 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 к креативности имеет крайне косвенное отношение,
важно понимать что если есть хорошая идея — то ее стоит высказать в любой подходящий момент.

Из ваших пунктов следует, что творчество сводится к процессу "играть в игру" всей командой. Но сама разработка (это может быть часто исследование), культура кода, с технической стороны, глазами програмиста — вторична. Просто потому что это процесс индивидуальный и с точки зрения краткосрочной выгоды он не интересен.

Но сама разработка (это может быть часто исследование), культура кода, с технической стороны, глазами програмиста — вторична.

Не совсем, я говорю о том что в Scrum это само собой не получается и требует личных и целенаправленных усилий,
иногда даже «против течения». Но результат того стоит.
Scrum это фреймворк для управления командой исполнителей, нацеленный на обеспечение решения тактических задач в рамках текущего проекта.

По моим ощущениям, данная система очень похожа на те, что описываются руководствах по боевой работе армейских подразделений. Когда есть SMART-цель, задача и приказ. А креативный подход, творчество и смекалка со стороны исполнителей конечно же всячески приветствуются, если они позволяют как-нибудь оптимизировать решение поставленной задачи.

Но если вы мечтаете, что-то творить выходящее за рамки конкретных задач спринта — нет, это не про скрам. Это абсолютно прямо противоположная затея. Так же Scrum не предназначен для стратегического планирования, планирования инвестиционной деятельности, целеполагания и еще многих других важных для организации штук.
Если вы полностью читали доку или хотя бы википедию, то существует понятие Daily Scrum, вот оно и отвечает за то о чем вы говорите.
Если владелец бизнеса не уважает право Product Owner’а принимать решения по развитию продукта и навязывает ему конкретный план действий, вся Scrum-команда лишается возможности быстро адаптироваться, поскольку не сможет принять никакие решения самостоятельно.


Полное очарование. Если бизнес не понимает, зачем ему скрам, а команда, следуя моде, давит на бизнес — они расстанутся в среднесрочной перспективе. А чаще — в краткосрочной.
Скрам — это реальный мир бизнеса скрам-мастеров. «Скрам нужен вам целиком, и значит вам нужен я».
Нельзя забывать, что Скрам подходит далеко не всем и далеко не всегда. В определенных случаях подходят другие Agile-методики (Канбан, Скрамбан); в других случаях Agile вообще не подходит.
Вы отчасти правы. Scrum действительно подходит не всем, поскольку он требует существенного изменения в подходе к работе, а многие не готовы или не хотят что то менять в своем рабочем процессе. Это проблема.

Что касается «технической» применимости, я с вами не согласен. В разработке скрам будет работать с пользой всегда. Отговорки вроде «у нас не может быть scrum потому что у нас web-приложение/мобильное приложение/банковское приложение» — это всего лишь отговорки.

в других случаях Agile вообще не подходит.

Agile очень расплывчатый термин, что именно вы имеете в виду по agile в данном контексте не понятно.
Нет, дело не только в готовности к переменам. Agile — под которым я имею в виду появившуюся в начале 2000-х идеологию разработки — подразумевает итеративность процесса и его адаптивность. Это прекрасно работает для определенного класса проектов, в которых короткие итерации позволяют успевать адаптироваться к стремительно меняющемуся рынку, а неполная версия продукта имеет смысл: бизнес-разработки, enterprise, разработки игр, веб… С другой стороны, есть классы проектов, для которых подобный подход нехорош, поскольку предполагает динамическое формирование цели. Я, правда, в этом не специалист, но думаю, что для разработки встроенного ПО, систем управления технологическими процессами и т.п. такого рода методологии не годятся.

Теперь давайте конкретно про Скрам. Он очень хорошо работает, когда основная работа состоит в разработке. Если же параллельно с разработкой идет активная поддержка, или если речь идет о часто меняющихся приоритетах, то Скрам начинает сбоить, по причине необходимости на ходу менять спланированный спринт. Канбан гораздо лучше приспособлен к таким ситуациям, поскольку плана никакого нет, а есть просто ограниченная по размеру очередь задач. В моей команде, например, мы пришли к гибридному варианту типа Скрамбана — Канбан с наложенными двухнедельными циклами релизов и планирования.
Теперь давайте конкретно про Скрам. Он очень хорошо работает, когда основная работа состоит в разработке.

Да, в 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. спасибо за хороший комментарий.

В этом посте я расскажу почему Scrum нужно внедрять в разработке, только добившись поддержки этой идеи во всей компании.

Да что уж там. Во всем мире! То о чем вы говорите – не имеет отношение к скраму. Это иерархический хаос. Когда разработчику выставляют задания все подряд, его продуктивность устремляется к нулю. По какой бы методологии вы не работали, но разработчик должен подчиняться только непосредственному начальнику и только через него получать задания и уж точно не заниматься приемом входящих заявок в процессе разработки. В таком случае скрам можно будет внедрить в системе, которая работает возможно вообще без системы.

Жаль только, что полноценный Scrum нельзя построить в Wrike…
Только из-за этого нам пришлось переехать из удобного, но неприспособленного под Agile врайка на более простой, но удобный для этой цели Trello…
Честно говоря, увидев статьи про Scrum у Wrike, уже решил что что-то изменилось, но похоже я ошибся…
Мы работаем на этим :) А пока могу рассказать несколько техник, как организовать Scrum процесс в Wrike прямо сейчас, если вам интересно.
Sign up to leave a comment.