P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
Если вы достаточно точно оценивает задачи на спринт в среднем, то что вы достаточно сильно промахнулись с оценкой отдельных задач не так страшно. Где то больше, где то меньше, — если в сумме за спринт вы добились результата не так важно что одну задачу вы переоценили а другую недооценили. Точные оценки требуют времени, а время можно потратить с большей пользой. Но и вообще игнорировать оценки нельзя, это бардак.
Отличная статья, очень наглядная, но я не согласен с названием поскольку Agile у вас не было даже близко.
Коротко: в компании произошла локальная оптимизация расходов на разработку,
никакого отношения к принципам Agile или Scrum они не имели, хотя слова использовались именно эти.
Субъективно: я бы назвал эту бизнес стратегию плохой,
добившись локальной (только разработка) и краткосрочной (ключевые сотрудники ушли) оптимизации разработки
компания вероятно сократила расходы здесь и сейчас — но потеряла гораздо больше в перспективе.
Ремарка: вы постоянно путаете концепции Agile и Scrum, далее я буду ориентироваться
на то что вы имели в виду только Scrum, поскольку по большей части вы пишете именно про процесс,
а Agile это набор принципов.
Из рассказанного вами очевидно что вы внедряли не Scrum а «НЕСкрам»,
вот несколько примеров.
1. «все разработки были переведены в TargetProcess» — никакой инструмент не имеет отношения к Scrum, и если внедренее Scrum началось с переходна на «новую клевую тулзу» — это была первая большая ошибка.
2. «получаем от менеджеров user-story (задачи что делать)» — здесь три ошибки:
1. в Scrum нет менеджера, есть Produc Owner, его роль никак не коррелирует со словом Manager.
2. «user-story» — это конкретная техника не являющаяся частью Scrum, ее можно использовать если она работает, но есть много других способом описать то что хочется получить которые могут работать лучше в конкретных обстоятельствах. Не факт что user-story то что нужно было действительно вам.
3. тут я не полностью уверен, но кажется что вы «получали» работу которую нужно сделать вместо того что бы «выбирать» какую работу делать (в определенных пределах). С точки зрения waterfall правильно первое, с точки зрения Scrum — второе, кажется у вас было первое.
3. «в конце спринта делаем ретроспективу» — по всей видимости Review вы не проводили, а это обязательно нужно делать.
4. «было велено списывать время на выполнение задачи в TargetProcess. » — это уже за гранью добра и зла, жесткий микроменеджемн и микрооптимизация. Мягко говоря, концепция тайм-трекинга полностью противоречит концепции и духу Scrum.
Я думаю из вашей статьи я смог бы продолжить список пунктов до 10,
но надеюсь и этих примеров достаточно что бы убедить вас что никакого Scrum у вас не было. У вас внедряли некий «Нескрам» и «Неаджайл».
Как конкретно называется методология которую вам пытались навязать,
я не уверен, «программист на час»?
«Методология Скрам, превращающая процесс разработки в конвейер» — нет, это так. Но конвейерную разработку сейчас действительно модно называть «Скрам», и не только в России. Не надо ставить себя выше других :)
«Говорить о том, что эти сотрудники виноваты сами» — обвинять разработчиков конечно глупо, но и общаться с ними «как с детьми» — малодушие.
Разработчики взрослые сознательные люди, со своими комплексами, тараканами, талантами, волей, амбицией и приоритетами, тем не менее, как и все.
Если люди построившие продукт и вложившие в него 5 лет жизни видя все это не встали и не сказали:
— засуньте в себе ж*** ваш таймтрекер
— мы сделали мажорное обновление ключевого фремворка всего за неделю, мы герои
— у нас баг в продакшн, я его исправлю — а вы — подождете
а вместо этого проголосовали ногами. Что ж, это их решение. И на них так же лежит часть отвественности за результат. Хаять Agile конечно легче, он же не может ответить.
Прошу прощения за резкий тон комментария, я старался быть конструктивным.
Прошу прощения что долго не отвечал, надеюсь мой ответ все еще будет полезен.
Вы указали большое количество организационных проблем,
пытаться спорить по каждому из пунктов думаю нет смысла — каждая гипотетическая ситуация возможна.
Ситуация когда разработка работает по «Scrum», при этом бизнес продолжает отношения с разработкой
по старому «В реальной жизни», «А по факту» и т.д. на самом деле складывается достаточно часто.
И это большая проблема.
Я бы посоветовал вам прочитать мою предыдущую статью в которой я пытаюсь предостеречь от внедрения Scrum только в разработке, без договоренности об изменении подхода к работе с бизнесом.
В описанной вами ситуации подход «пиши код!» действительно может оказаться наиболее эффективным,
просто потому что он соответствует ожиданиям бизнеса от разработки.
Скрам же, являясь фреймворком, предоставляет организационный инструмент, позволяющий, подобно лакмусовой бумаге, максимально быстро выявлять проблемы в этих двух областях и оперативно на них реагировать.
Конечно вы правы, Scrum это решение не только для разработки и он не содержит конкретных технических
рекомендаций, в отличии от XP. Scrum позволяет выявить проблемы, но найти решение — ответственность команды.
Будь то ревью кода, непрерывная интеграция или что то еще.
В целом вы делаете акцент на оптимизации разработки как таковой, это безусловно важно, но не достаточно.
Плохая разработка может провалить любой продукт, но и хорошая разработка не гарантирует успех.
Scrum предназначен не только для того что бы научиться «копать быстро»,
но и для того что бы понять «в каком направлении копать».
И второе в целом важнее первого, хоть и не отрицает его значимости.
Конечно вы имели в виду что Scrum Master не должен быть частью именно Development Team,
а в Scrum Team он само собой входит.
Да, с ролью Scrum Mater есть сложность. Но из своего опыта я не могу ни согласиться с вами ни опровергнуть.
С одной стороны если Scrum Master является частью Development Team:
1. Хорошо — он вовлечен в процесс и отлично понимает все его тонкости. Главное, команда воспринимает его как равного.
2. Плохо — он может быть завален работой по разработке и не сможет исполнять роль мастера должным образом.
3. Плохо — если в команде возникнут проблемы касающиеся именно его работы, ему сложно будет беспристрастно разобрать такую ситуацию с командой и найти решение.
С другой стороны, если Scrum Master это работа на полный день:
1. Хорошо — что Scrum Master имеет достаточно времени выполнять свою роль.
2. Хорошо — что позиция Scrum Master независимая и он может без лишних эмоций разбирать любые конфликты.
3. Плохо — что он не вовлечен в реальный рабочий процесс. Это отделяет его от команды. Как офицер который командует рядовыми из бункера.
Вероятно оба подхода имеют право на жизнь, и нужно просто постараться получить максимум
от конкретной сложившейся ситуации а не пытаться искать недостижимый идеал на рынке труда.
Хотя чем черт не шутит, вдруг повезет.
Большое спасибо за комментарий и прошу прощения за задержку с ответом.
1. Конечно Scrum создали не боги, но его создали умные люди с обширным жизненным опытом.
За 20 лет существования Scrum он был достаточно глубоко продуман и сбалансирован.
2. Конечно в Scrum нужно «делать с головой», Scrum Guide очень сложен. Кроме того Scrum Guide
это не готовое решение, а способ его получить.
3. «ничего страшного в отхождении от канонов» — вот тут нужно быть очень аккуратным,
это тонкий лед который может треснуть и вы провалитесь в ледяную воду.
4. то что вы выбираете «скрам мастера» перед стендапом, на самом деле не противоречит Scrum,
поскольку Scrum Master не обязан сам организовывать что либо, он должен обеспечить организацию.
Если вы пришли к тому что игра с кубиком для вас подходит, отлично.
Правда называть человека проводящего дейли «скрам мастером» неправильно — это подмена понятий.
5. «прессует QA команду» — я уверен что ваши отношения с QA на самом деле хорошие,
вы просто выбрали неудачную формулировку. Тем не менее тут есть большая проблема.
Наверняка тестирование является обязательной частью вашего процесса,
необходимым шагом что бы выполнить работу. Из того что вы сформулировали кажется
что либо QA не входят в вашу команду, либо формально входят но на самом деле живут отдельной
от программистов жизнью. Так часто бывает. И то и другое плохо для разработки в целом,
поскольку в таком случае не имеете возможность довести работу до конца в рамках Scrum команды.
6. То что вы отчитываетесь о прогрессе каждый день тоже имеет свои подводные камни.
Организация работы в рамках спринта это полностью ответственность Development Team,
и в нее никто не должен вмешиваться (механизм влияния на команду это Review).
Описанный вами подход ведет к следующим проблемам:
а) микроменеджмент команды вместо самоорганизации
б) ежедневное изменение планов вместо движения к цели (какая у вас цель спринта?)
Возможно вашей команде следует добиться большей самостоятельности,
но конечно я могу ошибаться.
Говоря что Agile это набор тактик я не имел в виду нравственную оценку идей Agile.
Ценности Agile, например то что работающее приложение важнее исчерпывающей документации,
позволяют принять решение в конкретной тактической ситуации. Вложиться и исправить проблемы
с тем что приложение хронически крешится вместо того что бы расписывать сотни воркэранудов.
При этом можно придумать миллионы вариантов процессов которые содержать в себе ценности Agile,
но совсем не похожи друг на друга и работают совершенно по разному для разных команд.
Можно найти разнообразие статей предлагающих разные Agile процессы, многие из них являются
описанием плохо реализованного Scrum из опыта конкретной компании. Такой подход может быть и сработал для авторов статьи, но нет причин что бы он сработал у вас.
Scrum не единственный подход к разработке. Но противопоставлять ему Agile неправильно.
Шилдик Agile вешают на все товары подряд, так что нужно быть очень внимательным в выборе производителя
что бы получить качественный продукт.
Спасибо за комментарий. К сожалению на ваше замечание я смогу ответить не раньше пятницы. В вопросах есть много интересных тем которые хотелось бы проработать со скрам мастерами прежде чем давать личный ответ. Прошу прощения за задержку.
Но сама разработка (это может быть часто исследование), культура кода, с технической стороны, глазами програмиста — вторична.
Не совсем, я говорю о том что в Scrum это само собой не получается и требует личных и целенаправленных усилий,
иногда даже «против течения». Но результат того стоит.
Теперь давайте конкретно про Скрам. Он очень хорошо работает, когда основная работа состоит в разработке.
Да, в 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-а будет достаточно.
Вы отчасти правы. Scrum действительно подходит не всем, поскольку он требует существенного изменения в подходе к работе, а многие не готовы или не хотят что то менять в своем рабочем процессе. Это проблема.
Что касается «технической» применимости, я с вами не согласен. В разработке скрам будет работать с пользой всегда. Отговорки вроде «у нас не может быть scrum потому что у нас web-приложение/мобильное приложение/банковское приложение» — это всего лишь отговорки.
в других случаях Agile вообще не подходит.
Agile очень расплывчатый термин, что именно вы имеете в виду по agile в данном контексте не понятно.
Для сравнения, если разработка устроена в проектном стиле.
Есть менеджер проекта, у него есть план сделать 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 не стоит использовать если бюджет является важным фактором?
Если вы достаточно точно оценивает задачи на спринт в среднем, то что вы достаточно сильно промахнулись с оценкой отдельных задач не так страшно. Где то больше, где то меньше, — если в сумме за спринт вы добились результата не так важно что одну задачу вы переоценили а другую недооценили. Точные оценки требуют времени, а время можно потратить с большей пользой. Но и вообще игнорировать оценки нельзя, это бардак.
Коротко: в компании произошла локальная оптимизация расходов на разработку,
никакого отношения к принципам Agile или Scrum они не имели, хотя слова использовались именно эти.
Субъективно: я бы назвал эту бизнес стратегию плохой,
добившись локальной (только разработка) и краткосрочной (ключевые сотрудники ушли) оптимизации разработки
компания вероятно сократила расходы здесь и сейчас — но потеряла гораздо больше в перспективе.
Ремарка: вы постоянно путаете концепции Agile и Scrum, далее я буду ориентироваться
на то что вы имели в виду только Scrum, поскольку по большей части вы пишете именно про процесс,
а Agile это набор принципов.
Из рассказанного вами очевидно что вы внедряли не Scrum а «НЕСкрам»,
вот несколько примеров.
1. «все разработки были переведены в TargetProcess» — никакой инструмент не имеет отношения к Scrum, и если внедренее Scrum началось с переходна на «новую клевую тулзу» — это была первая большая ошибка.
2. «получаем от менеджеров user-story (задачи что делать)» — здесь три ошибки:
1. в Scrum нет менеджера, есть Produc Owner, его роль никак не коррелирует со словом Manager.
2. «user-story» — это конкретная техника не являющаяся частью Scrum, ее можно использовать если она работает, но есть много других способом описать то что хочется получить которые могут работать лучше в конкретных обстоятельствах. Не факт что user-story то что нужно было действительно вам.
3. тут я не полностью уверен, но кажется что вы «получали» работу которую нужно сделать вместо того что бы «выбирать» какую работу делать (в определенных пределах). С точки зрения waterfall правильно первое, с точки зрения Scrum — второе, кажется у вас было первое.
3. «в конце спринта делаем ретроспективу» — по всей видимости Review вы не проводили, а это обязательно нужно делать.
4. «было велено списывать время на выполнение задачи в TargetProcess. » — это уже за гранью добра и зла, жесткий микроменеджемн и микрооптимизация. Мягко говоря, концепция тайм-трекинга полностью противоречит концепции и духу Scrum.
Я думаю из вашей статьи я смог бы продолжить список пунктов до 10,
но надеюсь и этих примеров достаточно что бы убедить вас что никакого Scrum у вас не было. У вас внедряли некий «Нескрам» и «Неаджайл».
Как конкретно называется методология которую вам пытались навязать,
я не уверен, «программист на час»?
«Методология Скрам, превращающая процесс разработки в конвейер» — нет, это так. Но конвейерную разработку сейчас действительно модно называть «Скрам», и не только в России. Не надо ставить себя выше других :)
«Говорить о том, что эти сотрудники виноваты сами» — обвинять разработчиков конечно глупо, но и общаться с ними «как с детьми» — малодушие.
Разработчики взрослые сознательные люди, со своими комплексами, тараканами, талантами, волей, амбицией и приоритетами, тем не менее, как и все.
Если люди построившие продукт и вложившие в него 5 лет жизни видя все это не встали и не сказали:
— засуньте в себе ж*** ваш таймтрекер
— мы сделали мажорное обновление ключевого фремворка всего за неделю, мы герои
— у нас баг в продакшн, я его исправлю — а вы — подождете
а вместо этого проголосовали ногами. Что ж, это их решение. И на них так же лежит часть отвественности за результат. Хаять Agile конечно легче, он же не может ответить.
Прошу прощения за резкий тон комментария, я старался быть конструктивным.
Вы указали большое количество организационных проблем,
пытаться спорить по каждому из пунктов думаю нет смысла — каждая гипотетическая ситуация возможна.
Ситуация когда разработка работает по «Scrum», при этом бизнес продолжает отношения с разработкой
по старому «В реальной жизни», «А по факту» и т.д. на самом деле складывается достаточно часто.
И это большая проблема.
Я бы посоветовал вам прочитать мою предыдущую статью в которой я пытаюсь предостеречь от внедрения Scrum только в разработке, без договоренности об изменении подхода к работе с бизнесом.
В описанной вами ситуации подход «пиши код!» действительно может оказаться наиболее эффективным,
просто потому что он соответствует ожиданиям бизнеса от разработки.
«Копать в правильную сторону» — это Apple, выпустившая в том же году iPhone.
Конечно вы правы, Scrum это решение не только для разработки и он не содержит конкретных технических
рекомендаций, в отличии от XP. Scrum позволяет выявить проблемы, но найти решение — ответственность команды.
Будь то ревью кода, непрерывная интеграция или что то еще.
В целом вы делаете акцент на оптимизации разработки как таковой, это безусловно важно, но не достаточно.
Плохая разработка может провалить любой продукт, но и хорошая разработка не гарантирует успех.
Scrum предназначен не только для того что бы научиться «копать быстро»,
но и для того что бы понять «в каком направлении копать».
И второе в целом важнее первого, хоть и не отрицает его значимости.
Конечно вы имели в виду что Scrum Master не должен быть частью именно Development Team,
а в Scrum Team он само собой входит.
Да, с ролью Scrum Mater есть сложность. Но из своего опыта я не могу ни согласиться с вами ни опровергнуть.
С одной стороны если Scrum Master является частью Development Team:
1. Хорошо — он вовлечен в процесс и отлично понимает все его тонкости. Главное, команда воспринимает его как равного.
2. Плохо — он может быть завален работой по разработке и не сможет исполнять роль мастера должным образом.
3. Плохо — если в команде возникнут проблемы касающиеся именно его работы, ему сложно будет беспристрастно разобрать такую ситуацию с командой и найти решение.
С другой стороны, если Scrum Master это работа на полный день:
1. Хорошо — что Scrum Master имеет достаточно времени выполнять свою роль.
2. Хорошо — что позиция Scrum Master независимая и он может без лишних эмоций разбирать любые конфликты.
3. Плохо — что он не вовлечен в реальный рабочий процесс. Это отделяет его от команды. Как офицер который командует рядовыми из бункера.
Вероятно оба подхода имеют право на жизнь, и нужно просто постараться получить максимум
от конкретной сложившейся ситуации а не пытаться искать недостижимый идеал на рынке труда.
Хотя чем черт не шутит, вдруг повезет.
1. Конечно Scrum создали не боги, но его создали умные люди с обширным жизненным опытом.
За 20 лет существования Scrum он был достаточно глубоко продуман и сбалансирован.
2. Конечно в Scrum нужно «делать с головой», Scrum Guide очень сложен. Кроме того Scrum Guide
это не готовое решение, а способ его получить.
3. «ничего страшного в отхождении от канонов» — вот тут нужно быть очень аккуратным,
это тонкий лед который может треснуть и вы провалитесь в ледяную воду.
4. то что вы выбираете «скрам мастера» перед стендапом, на самом деле не противоречит Scrum,
поскольку Scrum Master не обязан сам организовывать что либо, он должен обеспечить организацию.
Если вы пришли к тому что игра с кубиком для вас подходит, отлично.
Правда называть человека проводящего дейли «скрам мастером» неправильно — это подмена понятий.
5. «прессует QA команду» — я уверен что ваши отношения с QA на самом деле хорошие,
вы просто выбрали неудачную формулировку. Тем не менее тут есть большая проблема.
Наверняка тестирование является обязательной частью вашего процесса,
необходимым шагом что бы выполнить работу. Из того что вы сформулировали кажется
что либо QA не входят в вашу команду, либо формально входят но на самом деле живут отдельной
от программистов жизнью. Так часто бывает. И то и другое плохо для разработки в целом,
поскольку в таком случае не имеете возможность довести работу до конца в рамках Scrum команды.
6. То что вы отчитываетесь о прогрессе каждый день тоже имеет свои подводные камни.
Организация работы в рамках спринта это полностью ответственность Development Team,
и в нее никто не должен вмешиваться (механизм влияния на команду это Review).
Описанный вами подход ведет к следующим проблемам:
а) микроменеджмент команды вместо самоорганизации
б) ежедневное изменение планов вместо движения к цели (какая у вас цель спринта?)
Возможно вашей команде следует добиться большей самостоятельности,
но конечно я могу ошибаться.
Говоря что Agile это набор тактик я не имел в виду нравственную оценку идей Agile.
Ценности Agile, например то что работающее приложение важнее исчерпывающей документации,
позволяют принять решение в конкретной тактической ситуации. Вложиться и исправить проблемы
с тем что приложение хронически крешится вместо того что бы расписывать сотни воркэранудов.
При этом можно придумать миллионы вариантов процессов которые содержать в себе ценности Agile,
но совсем не похожи друг на друга и работают совершенно по разному для разных команд.
Можно найти разнообразие статей предлагающих разные Agile процессы, многие из них являются
описанием плохо реализованного Scrum из опыта конкретной компании. Такой подход может быть и сработал для авторов статьи, но нет причин что бы он сработал у вас.
Scrum не единственный подход к разработке. Но противопоставлять ему Agile неправильно.
Шилдик Agile вешают на все товары подряд, так что нужно быть очень внимательным в выборе производителя
что бы получить качественный продукт.
Не совсем, я говорю о том что в Scrum это само собой не получается и требует личных и целенаправленных усилий,
иногда даже «против течения». Но результат того стоит.
Да, в 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 потому что у нас web-приложение/мобильное приложение/банковское приложение» — это всего лишь отговорки.
Agile очень расплывчатый термин, что именно вы имеете в виду по agile в данном контексте не понятно.
Есть менеджер проекта, у него есть план сделать 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 к креативности имеет крайне косвенное отношение,
важно понимать что если есть хорошая идея — то ее стоит высказать в любой подходящий момент.