"Черные страницы Scrum", по версии Ивана Селиховкина

Публикация № 949714

Управление - Управление проектом

21
Иван Селиховкин более 12 лет занимается управлением проектами, программами, портфелями. И в статье он расскажет о проблемах использования Scrum, которые могут поставить под угрозу вашу карьеру или ваш проект, если вы неловко неудачно примените этот фреймворк.

 

 

В последние годы я работаю в проектном офисе, где мы, в том числе, подбираем методологии для реализации на проекте и опираемся на самые распространенные подходы: проектный – PMI, продуктовый – Scrum, процессный – Канбан. И поскольку мы ответственный проектный офис, мы не просто играем в методологии, мы пытаемся ответить на вопрос, оптимально ли мы подобрали методологию для конкретного проекта. Мы их подбираем, пытаемся скоординировать, где необходимо. Заодно проверяем себя, пытаемся придумать критерии эффективности, чтобы оценить, удачно ли была выбрана методология, можно ли было выбрать другую – более оптимальную, не ошиблись ли мы.

Во время работы мы ориентируемся на ядро каждого подхода. Например, у PMI есть библия PMBoK, у Scrum – Scrum Guide, с Канбан – несколько сложнее.

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

Кроме того, вызов, с которыми мы сталкиваемся, – мы должны отвечать на запросы проектной команды, особенно это характерно для молодых IT-команд, которые хотят работать по современному Scrum вместо устаревших диаграмм Ганта. И нам надо уметь отвечать на вопрос, можем ли в данном случае работать по Scrum, почему, какие проблемы до этого необходимо решить. И мы ищем ответы на эти вопросы. Мы применяем подходы, комбинируем их.

 

Почему именно Scrum?

 Я выбрал тему про один их самых популярных Agile подходов – это фреймворк Scrum.

 

И сразу хочу обратить внимание, что эта статья - это не критика Scrum. Это перечень проблем, которые, с моей точки зрения, вы должны уметь решать. Либо вы знаете, как их решить, либо у вас могут возникать сложности, которые поставят под угрозу проект или вашу карьеру.

 

Итак, сложности, проблемы, с которыми нужно уметь работать, если вы хотите использовать Scrum  

 

Проблема 1. Scrum Guide противоречит Agile манифесту

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

 

В теории можно представить себе такую историю, где-то в глубине “банкинга”, когда действительно процесс очень важен, потому что если вы его меняете, риски очень высоки. И тут действительно лучше пусть полкоманды уволится, чем нарушатся процессы. Ибо риски очень велики. Но в целом в абсолютном большинстве проектов все менеджеры, как бы они не работали – по Канбан или Scrum – все согласны, что люди важнее процессов. И это очень хорошо. Ведь упираться в первоначальный план, вопреки здравому смыслу, нелепо.

Тем интереснее, что на эту тему пишет Scrum. Для этого нужно дочитать так называемое исчерпывающее руководство по Scrum до конца, до последних страниц. Там есть такое заключение:

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

 

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

Интересно сопоставить эти вещи: с одной стороны, есть Agile манифест, в котором люди и взаимодействие важнее процессов, а готовность изменений важнее планов, а с другой – Scrum говорит, что он существует только в виде цельного фреймворка. И как же они сосуществуют? Что же важнее?

 

Это кажется умозрительной проблемой. Но она оказывается важной, потому что из нее вытекают другие проблемы, связанные с применением Scrum.

И сложность, которую надо понимать, – Scrum Guide не совсем соответствует Agile манифесту, в том числе, благодаря вышеназванным заключениям. Он очень жестко ставит рамки.

 

Вообще Scrum Guide – самый жесткий из всех фреймворков, которые я знаю в управлении в принципе. Подходы в традиционном проектном управлении гораздо мягче.

 

Проблема 2. Нет возможности удовлетворить потребности заказчика

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

Знаете эту картинку? Ее очень любят сторонники Agile.

 

Понимаете, в чем здесь проблема? В том что это невозможно.

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

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

 

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

Вывод, который мы сделали: проверяйте себя. Если продукт, который вы собираетесь делать, содержит много пользовательской функциональности, тогда Scrum может быть применим. Если же у вас что-то похожее на наш сервер, и вы сперва долго работаете, а потом выдаете значимый элемент, и промежуточные части не важны, тогда Scrum подойдет гораздо хуже - ему просто не за что будет “зацепиться”.

Знаете фразу: «Нельзя построить мост по Scrum»? Так вот нельзя построить мост по Scrum! Заказчику нужен мост целиком. Никакие половинки и четвертинки или просто сваи ему не нужны, он не может их использовать. Поэтому нужно проверять себя, сколько у вас полезной функциональности, годится ли здесь продуктовый подход такого рода или нет.

 

Проблема 3. Невозможно оценить сроки

Еще одна проблема, с которой мы столкнулись, и вы должны уметь ее решать, если хотите, чтобы Scrum работал. Это оценка сроков. 

Коллеги, сейчас я расскажу очевидную для многих вещь. Но мне важно это сделать, чтобы подвести вас к проблеме. Как Scrum работает со сроками? Он отвергает экспертные оценки, он считает, что попытка прогнозировать сроки в IT – это всегда самообман, это химера, какая-то выдумка. И Scrum говорит, не надо пытаться придумать, сколько работа длится, надо померять это по факту: мы поработаем, увидим и вместо гипотез будем пользоваться фактами. И такой способ оценки сроков будет точнее.

Как это выглядит на практике? Scrum собирает у заказчика все его пожелания («хотелка» 1, 2, 3) и складывает их в некое условные «ведро» под названием backlog. Я очень упрощаю, но смысл такой. Затем мы находим самую простую задачу, наименее трудоемкую, и, вместо оценки сроков, спрашиваем себя, какова ее трудоемкость. Этот показатель у нас будет условной единицей трудоемкости. Это так называемый один условный стори поинт (story point). Потом мы оцениваем, какая трудоемкость у соседней задачи. Например, она вдвое более трудоемкая, чем самая простая. Тогда ее оценивают в 2 стори поинта. А еще есть задачи, у которых 3 стори поинта, 4 стори поинта. Найдется еще задача, которая будет такой же простой, как самая легкая, и ей тоже присвоят оценку в 1 стори поинт. И так мы продвигаемся по всем «хотелкам», все их оцениваем, а каждая получает оценку в стори поинтах.

Дальше мы идём работать. В Scrum важна ритмичность, поэтому мы решаем идти двухнедельными спринтами. Сколько задач мы можем «переварить» за 1 спринт? Мы не знаем. Как это определять? На глаз – методом, так называемого, комсомольского прищура. Вы прикидываете, что, наверное, 5 стори поинтов будет нормально, берете задачи на 5 стори поинтов и всей командой работаете 2 недели.

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

В очередной спринт вы берете, скажем, задач на 4 стори поинта и справляетесь довольно спокойно. И когда вы поработали 2-3 спринта, вы можете подсчитать так называемую мощность команды (velocity). Это не скорость, а именно мощность – сколько вы  можете «переваривать» задач за спринт.

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

Что дальше делает Scrum со сроками? Он спрашивает себя, сколько осталось не отработанных задач. Допустим, на 30 стори поинтов. Если наша velocity находится где-то между четырьмя и пятью, возьмем пять, чтобы команда работала в высоком тонусе, значит, с задачами мы справимся за 6 спринтов. Зная, сколько длится спринт, мы можем сказать, когда закончим проект.

Это называется диаграмма сгорания. Ее можно нарисовать и понять, какие у нас сроки. Это то, что предлагает Scrum.

Еще важно понимать: velocity – это командный показатель. Это тоже философия Scrum, где очень важно чувство локтя, чувство плеча, взаимовыручка. Scrum постоянно говорит нам, что команды являются самоорганизующимися. То есть если мы подходим к завершению спринта и видим, что кто-то не справляется со своей задачей, то мы бросаемся ему помогать и дожимаем этот спринт, и обязательно укладываемся в сроки. Так  команда становится сплоченной и самоорганизующейся, развивается и так далее.

Так работает Scrum, поэтому velocity меряет обязательно команду, а не человека. Если вы начинаете втихаря мерить velocity каждого человека, это убьёт ту самую командность.

Представьте, я инженер. И вдруг я понимаю, что какой-то менеджер меряет мои задачки, мою производительность. У меня как минимум появляется вопрос, а нужно ли помогать коллеге. Если я пойду ему помогать, он свои задачки закроет, я справлюсь хуже, мои метрики упадут.

Поэтому Scrum категорически не поощряет индивидуальные метрики. И velocity – эта командная метрика.

И вот проблема: вы потратили 2 - 3 спринта, а обычно спринты не меньше двух недель (мало кто использует недельный спринт), померяли velocity, прикинули, какие могут быть сроки завершения проекта. И в этот момент, скорее всего, произойдет что-нибудь такого плана: кто-то из сотрудников уволился, кто-то ушёл в отпуск, кто-то приболел. Или у вас новичок в команде появился. То есть изменилась ваша команда. Временно или навсегда. Вопрос: какая у вас velocity на следующий спринт? Неизвестно! Вы этого не знаете. Это же метрика командная, а команда только что изменилась. Что нужно, чтоб понять velocity? Конечно, поработать еще два-три спринта, т.е. месяц-полтора. Тогда вы снова ее нащупаете.

 

И представьте, что примерно каждые два месяца команда будет меняться, и velocity будет все время непредсказуемо меняться. И вам придется опять работать с обновленной командой, чтобы нащупать, какая она теперь.

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

Проблема Scrum в том, что он почти никогда не позволит вам нормально предсказывать сроки. Вы все время будете додумывать, придумывать, не сможете положиться на ту метрику, которую вам предлагают по умолчанию. Потому что команда изменчива, а вы меряете только командную velocity, а она меняется.

 

 

Что с этим делать? На самом деле достаточно просто понимать, что Scrum никогда нормально не может спрогнозировать сроки окончания разработки. К счастью, на многих проектах это неважно. На многих проектах сроки ставятся умозрительно – из серии, заказчик сказал, что «хотелось бы к декабрю закончить». Этот срок он взял из головы, и с ним можно договориться. Но если у вас есть жесткий срок, он определён каким-то неизменным контрактом или привязан к чему-то объективному (у заказчика что-то случится по истечении этого срока), и не может быть сдвинут, тогда Scrum использовать тяжело. Он никогда не может нормально предсказывать сроки окончания. Там это никак не сделать.

 

Проблема 4. Ваша команда не кроссфункциональна

Еще одна сложность Scrum в том, что ваша команда наверняка не кроссфункциональна, как бы вам не казалось обратное.

Что вообще такое кроссфункциональность? В Скрам-гайд сказано:

«СкрамR08;команды являются самоорганизующимися и кроссфункциональными» (стр. 5).

И: «Кроссфункциональность – наличие в рамках команды всех необходимых навыков для командного создания Инкремента Продукта» (стр. 7).

Это можно понимать двумя способами. Первый – каждый специалист умеет и программировать, и тестировать, и выступать бизнес-аналитиком, и проектировать интерфейс. Вот он кросс функциональный. Но это звучит очень страшно, потому что команду из таких людей собрать крайне затруднительно.

 

Второй способ, как обычно все понимают кросс функциональность, – это когда в команде есть все нужные роли: есть и аналитики, есть и те, у кого лучше программирование получается, и тестирование, т.е. команда в целом обладает всем нужным набором, чтобы делать продукт. Сориентируемся именно на втором варианте.

В Scrum есть такое пояснение: разработчик – это единственная роль в команде разработки, и другие роли в команде разработки не признаются. А если дальше посмотреть Scrum Guide, то там написано, что подкоманды делать в нем нельзя.

 

Как вы помните, выкидывать из Scrum ничего нельзя, иначе это не Scrum. Пока помним про этот абзац, но не будем в него вдаваться.

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

 

Как они делят между собой полномочия внутри спринта? Начинается спринт. Мы взяли какую-то «хотелку» заказчика в реализацию. Первое, что нужно сделать, – включиться аналитику, он задачи прорабатывает и передает дальше. Он начинает работать (у него красные глаза), а остальные пока ждут.

 

Аналитик поработал, по мере его работы появляются какие-то постановки, спецификации. Тут подключается разработчик.

 

Разработчик начинает работать (теперь уже у него красные глаза), спринт идет дальше. Аналитик, тем временем, немного отходит от дел, потому что свою часть работы сделал.

 

Со временем просыпается еще и тестировщик.

Он принимает от разработчика задачи, и под конец спринта уже в основном работает тестировщик (до красноты глаз). Периодически он возвращает разработчику какие-то дефекты, их правят, иногда вместе ходят к аналитику, если оба не поняли задачу.

 

То, о чем я рассказал, – бред. Потому что треть спринта «спит» каждая из ролей: в конце не особо нужен аналитик, а в начале не особо нужен тестировщик и разработчик, им делать нечего. Но это абсурд.

Что делают многие команды? Очень часто они запускают как бы аналитика с опережением. Как это может выглядеть? Аналитику предлагают работать заранее, чтобы он шел на 1 спринт вперед, прорабатывать задачки. И тогда разработчику будет, что делать. Попробуем представить себе это. Аналитик включается на 1 спринт раньше, берет задачки, делает по ним постановки, работает по ним с какой-то своей мощностью. На спринт позже просыпается разработчик. И у него уже всегда есть работа. Принимая задачки от аналитика, он работает с какой-то своей velocity.

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

Это только три роли, а представьте, если их больше. Понятно, что это опять бред.

Каждый, кто так делал, понимает, что рано или поздно произойдет: споткнется аналитик и повалится вся схема. Например, он не успеет дать задачки разработчику, и у них у всех не будет работы. Более того, мы только что сильно усложнили подход. У нас есть теперь три команды, и у каждой своя velocity. И вообще все это подозрительно похоже на диаграмму Ганта, которую мы так не любим.

 

 

Сейчас полезно вспомнить тот абзац, про который мы говорили раньше: разработчик – единственная роль в команде разработки, других Scrum не признаёт. 

Отсюда вывод, который мы сделали для себя: кроссфункциональность – это в прямом смысле слова, именно в первом смысле слова, когда все умеют всё. Scrum без костылей и без лишних вопросов работает тогда, когда у вас действительно все члены команды могут всё: разработчик может и протестировать, и выступить аналитиком, и дизайн немного запилить, если нужно. Вот тогда понятно.

Что делать? Одно из двух: либо спросить себя, является ли наша команда на самом деле кросс функциональной (так бывает, но редко), либо придумать свой способ решения проблемы переключения ролей.

 

 

Как ее еще пытаются решать? Аналитика, например, выносят вообще из Scrum команды, чтобы он работал с задачами  на уровне backlog’а. Тестировщика пытаются заменить автотестами. Но это тоже не очень просто, на практике еще миллион вопросов возникает.

 

Проблема 5. Слишком много времени на планирование

Одна из ценностей Scrum, особенно если верить книжкам, которые написал один из авторов Scrum Guide, – Scrum экономит время на планировании. Команда не тратит время на то, чтобы делать планы в начале, а сразу идет работать. Но давайте посчитаем, сколько на самом деле уходит времени на планирование в Scrum.

Представим себе недельный спринт. Что такой недельный спринт? Это 5 рабочих дней, 5 прямоугольников.

 

На что тратится время при планировании Scrum? Во-первых, в Scrum есть планирование спринта. Если бы спринт был месячный, то планирование должно было бы занимать не более 8 часов, а он у нас недельный. Согласно обтекаемой формулировке Scrum Guide, если спринт короче, то на его планирование нужно меньше времени. Насколько меньше, непонятно. Но на практике очень мало команд может планировать спринт быстрее чем за три-четыре часа, это в среднем.

 

Есть еще так называемый ежедневный Scrum. Так называемый стендап - очень полезная практика, когда в начале каждого дня все члены команды собираются и отвечают на три вопроса (условно):

- что я делал вчера?

- что я буду делать сегодня?

- чем мне можно помочь?

На это уходит не больше 15 минут в день. В 15 минут не так-то просто уложиться, но это достижимо. Если возникают вопросы в ходе ежедневного Scrum, то они переносятся на отдельное совещание: специалисты, которых касаются проблемы, остаются и между собой все обсуждают. Они тратят на это столько времени, сколько нужно – 40 минут, 50 минут, сколько потребуется.

 

На что уходит время еще? Есть такая вещь, как обзор спринта и ретроспектива. Обзор спринта в месячном спринте занимает не больше 4 часов, а ретроспектива – не больше 3 часов. Если бы спринт был месячным, то на ретроспективу и обзор ушел бы целый рабочий день – 7 часов. В нашем примере он не месячный, но опять же по нашему опыту, быстрее, чем за три-четыре часа и обзор, и ретроспективу провести сложно.

 

 

Но и это еще не все. Еще есть такая вещь, как уточнение backlog’а, которая может занимать до 10% времени от всего свободного времени команды.

 

 

А теперь давайте посчитаем, что получилось на нашем недельном спринте:

- планировать спринт – полдня в неделю;

- ежедневный Scrum, если все дни сложить, это 0,15 дня за всю неделю в сумме;

- вопросами, которые требуют обсуждения, мы пренебрежем, посчитаем, что их не было, и мы потратили 0, хотя на практике будут такие вопросы, и мы на них время потратим;

- на обзор и ретроспективу ещё полдня в неделю;

- еще примерно полдня в неделю на уточнение backlog’а.

В сумме получается 1,65 дня, то есть 30% рабочего времени. Столько уходит на планирование недельного спринта.

 

Понятно, что если спринт длиннее, то времени на планирование удельно будет тратиться меньше. Вот почему никто не использует недельные спринты: слишком много времени уходит на планы.

Но если у вас принят месячный спринт, там другие проблемы. Вы же обещали заказчику вовлечение, частые поставки, где же они? Раз в месяц? Scrum отбирает у заказчика возможность прогнозировать сроки, но зато дает ему вовлечение, «руку на пульсе» и частые поставки – регулярно. Но раз в месяц – это не частные поставки. Любой  проектный подход запросто обеспечит ежемесячные релизы. Тут Scrum уже ни при чем. Поэтому  месячные спринты – тоже не очень популярный подход. В основном используются двух-трехнедельные спринты, и там у каждого свои особенности. И там тоже довольно много времени уходит на планирование.

 

Что с этим делать? Просто понимать, что Scrum – это один из очень прожорливых до времени на планирование фреймворков. Если проектные подходы тратят много времени в начале и не очень много – в процессе, то Scrum очень много времени тратит на планирование постоянно.

 

Другие проблемы Scrum

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

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

 

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

 

 

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

 

 

 

В завершение скажу: мы применяем Scrum. Просто это не так легко и не так безопасно, как кажется иногда.

*******

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2018 EDUCATION/

21

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. user1096347 24.11.18 14:35 Сейчас в теме
Все эти проблемы довольно распространены, на любом качественном тренинге по скрам о них говориться, как и о том, как их решить, конечно же, тоже. :)
Vladimir Litvinenko; +1 Ответить
3. user1096704 25.11.18 13:34 Сейчас в теме
(1) автор ведь не говорит, что решений нет. Он говорит, что решения есть, но они не являются частью кошерного скрама)) и решения эти известны и без ваших тренингов и аджайл-наклеечек
Автору респект и плюс 100 к карме за то, что все баги в одном месте собрал. Обычно спорить лень с последователями Великого и Могучего Гудвина Скрама, теперь их можно к этой ссылке отправлять ;)
DonAlPatino; LordKim; +2 Ответить
2. Vladimir Litvinenko 24.11.18 16:08 Сейчас в теме
Отличная публикация, хорошо отрезвляет.

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


Лично мне приятно работать с людьми, которые не только способны написать кусок кода, который "ну работает же" , но и интерфейс проработают хороший. И проверить качество своего решения и решения коллег способны. Иначе говоря, способными быть чуть-чуть дизайнерами и хорошими QA.

По наблюдениям подход к написанию кода, проверке качества и подход к проектированию интерфейса очень коррелируют. Если в интерфейсе бардак, то и код, даже выдающий результат, окажется неподдерживаемым набором костылей написанным для себя-любимого, а не для команды. С аргументацией, что стандарты написания кода и проектирования интерфейса нарушают тонкую творческую натуру и замедляют разработку )) “Мы же не фирма 1С чтобы им следовать”. И внедрённое решение становится кандидатом на перевнедрение. При этом руководители будут долго питать иллюзии что продукт в порядке, а потом окажется что за вырезание скрытых метастаз никто уже не хочет браться. И придется с рынка набирать программистов у которых просто нет выбора куда пойти и они готовы и с таким бардаком работать.


Книгу тоже прочитал.

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



Хотелось бы еще пару заметок сделать, может быть они покажутся полезными.


QA. Оно же тестирование.

Частые примеры с тем, что именно разработчик при нехватке ресурсов на тестирование начинает участвовать в тестировании, а не наоборот QA начинает разрабатывать, связан во многом с тем, что обычно компании экономят на QA.

В качестве примера, на текущем моем проекте более 10 разработчиков-кодеров и только 2 инженера QA. Считается что тестировать должны консультанты, которые увы не могут сделать это качественно и всесторонне. Качество очень низкое, руководство начинает метаться между скрамом, водопадом и просто плеткой.

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

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



Velocity - мощность команды

Пример с увольнением, болезнью, отпуском не совсем корректен в качестве недостатка гибких подходов.

Если вы оцените работу в часах по любой другой технологии и кто-то из разработчиков заболеет или уволится или уйдет в отпуск (такой пример приведен в выступлении и в книге) то оценка ведь также будет неточной. Причем здесь скрам или любая другая технология? Вы можете хоть на голове стоять вместо применения скрама, применять любые проектные подходы. Увольнение сотрудника или всей команды в любом случае приведет к срыву сроков, если нет запасной команды.

И в случае когда вы кровью расписались, что сдадите проект к нужному сроку, будет больше проблем, чем когда продукт выдается итерациями и финальный срок может двигаться более свободно.


Мощность (velocity) не нужно знать с точностью до десятых часа/сторипонинта. К чему это вообще? Если у вас 5 разработчиков и один из них заболел понять какой будет мощность на следующий спринт и сильно ошибиться сложно. Для этого нужно совсем не знать свою команду. Вы же знаете, сильный это разработчик ушел на больничный или джуниор. Оцените примерно. Даже если ошибетесь на 10%-20% это не фатально, чтобы записывать в жуткий недостаток инкрементального подхода.

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

Это делает спринт - мини проектом (почти по водопадной модели!), а не просто двухнедельным индивидуальным забегом по хаотично набранным задачам из таск-трекера.

Кто-то формулирует цель спринта при планировании чтобы сделать его мини-проектом? Или напрягаться не хочется и слишком лень это делать? )))



Фрейморк - жуткое непереводимое слово

Пожалуйста, хватит уже страдать англофобией. Слово фреймворк - шикарно. И очень хорошо применимо в IT. Оно понимается как набор ограничений и инструментов. Почему “фреймворк Spring” и даже “фреймворк - платформа 1С” в вакансиях от самой фирмы 1С не вызывает взрыва мозга, а “фреймворк Скрам” вызывает англофобию и топанье ногами? Ууух…. страшные иностранные слова….. То ли дело наш тёплый ламповый желтый мир , где всё понятно и мы уже такие опытные )))

Если мы не собираемся строить мост по скрам, а применяем его в ИТ , то слово фреймворк можно и нужно применять.


Противоречие Agile подходу

Скраму 30 лет. Подход зародился примерно за 15 лет до того, как появился Agile-манифест. И да, его уже потом притянули к Agile за его итеративность и декларируемую необходимость часто взаимодействовать с заказчиком. В скрам-гайде нет ни одного упоминания про Agile, что становится открытием для многих и причиной стремления изобрести "свой правильный скрам"

(Здесь должна быть отсылка к публикациям Ивана Белокаменцева)

История конечно мало кому интересна, а жаль.

И действительно Agile - это очевидные вещи про гуманизм. Скрам - это жесткий понятный подход и правила. Чем он и ценен, так как приводит в Agile регулярный менеджмент и делает его более надежным и предсказуемым.



Канбан

На слайде под ним стоит большой черный вопрос. А материалы ведь есть - имена, явки, пароли, руководства. В последнее время несколько раз приходилось делиться ссылкой на уже старенький материал : https://youtu.be/lrDLbp0XeFA?t=287


А за статью еще раз спасибо!
FB_1811930315551820; Valerych; LordKim; +3 Ответить
7. FB_1811930315551820 27.12.18 14:32 Сейчас в теме
(2) Пока читал статью, набрасывал на листок тезисно возражения, чтобы потом ответить "системно"... После Вашего коммента все тезисы пришлось вычеркнуть, кроме одного:

И про планирование:
1. Возьмем самый распространенный срок спринта - 2 недели (1 - никто не делает, 3 - теряется та самая "вовлеченность" и частота релизов).
Планирование спринта - 4-5 часов (6-8 может быть в самом начале проекта, когда много отнимает стратегия)
Ретроспектива - 3-4 часа (хотя это уже не чистое планирование, но об этом потом)
Ежедневки - считать просто недобросовестно (давайте еще перекуры и кофе-паузы посчитаем)
2 недели = 80 часов, план+ретро = (7+12)/2=9.5 часов
Итого имеем около 12% затрат на планирование. В классике водопада - весьма эффективный результат (и по времени, и по стоимости)
Теперь о том, почему эти 12% раза в два эффективнее, чем те же 12%, потраченные в начале проекта.
В НАЧАЛЕ ПРОЕКТА ЗАКАЗЧИК НЕ ЗНАЕТ, ЧТО ИМЕННО ЕМУ НУЖНО! Весь мой скромный опыт говорит, что большая часть первоначальных планов идет в корзину. И потом ВСЕ РАВНО тратится время на перепланировку этих планов. Только проектом и графиком это уже НЕ ПРЕДУСМОТРЕНО! И тогда приходит он - всеми любимый песец аврал. И иногда мы даже укладываемся в график. Ну, то есть заваливаем сроки не так уж чтобы сильно. Вобщем, заказчик тоже человек, он же все понимает, тем более что сам и является основной причиной... И все довольны, все хорошо (если проект взлетел, конечно). Но простите, как же можно при всем при этом говорить, что "Ужасный СКРУМ скрумкал аж 30% от чистого рабочего времени нашего проекта"?? В ЛЮБОМ случае это время будет потрачено на планирование и перепланирование.
И теперь вишенкой на торте: про ретроспективу.
Если что-то на проекте идет не так - стопорится коммит понятного вроде функционала, или прототипы раз за разом не принимаются заказчиком - в любом случае надо уделить этому время, понять причину стопора и постараться ее устранить вместо того, чтобы "пробивать стену лбом". Введение плановой ретроспективы - всего лишь дань очевидной потребности соотносить свою деятельность с меняющейся реальностью. Так что по-хорошему, время на ретроспективу из "затрат на планирование" стоит убрать - ведь в идеальном случае "все идет по плану, проблем никаких" вся ретроспектива занимает минут 30 (а могла бы и меньше, но ведь каждому приятно похвалиться достигнутыми результатами). А в реальном случае "что-то пошло не так" - все время, потраченное на ретро, окупается с лихвой тем, что ценные ресурсы не сжигаются в тупую, потому что "мы ж так изначально планировали, не отступать, не сдаваться!". Вот и выходит. что НА ПЛАНИРОВАНИЕ у нас уходит не более 8% времени.
Vladimir Litvinenko; +1 Ответить
4. CheBurator 3386 26.11.18 17:00 Сейчас в теме
Полезно для меня.
Получил ответы на некоторые вопросы, по которым ощущал что "как-то не так оно"...
Спасибо.
5. Rico17 29 28.11.18 12:37 Сейчас в теме
Было бы намного полезней рассматривать "узкие места" в проектной деятельности (любых проектов?) в сравнении: PMI vs Скрам vs Канбан.
Сразу обнаружится, что это и правда "узкие места" ;)
6. DAV 05.12.18 11:10 Сейчас в теме
(5) Полезно голову включать, а не гоняться за модой. И делать проекты исходя из здравого смысла, а уж как это потом обозвать - дело маркетинга.
ЗЫ. Не примите на свой счет, это именно мое ИМХО. А рассматривать методологии противопоставляя их друг-другу? Что сравнивать, теплое и мягкое? Канбан - речь за процесс, Скрам - речь про продукт, PMI - речь про проект. И да, в водопаде есть еще PRINCE2 например, что же только PMI ограничиваться?
8. FB_1811930315551820 27.12.18 14:54 Сейчас в теме
(6) Согласен с тем, что здравый смысл - всему голова. Все методы и "фреймы" - всего лишь инструменты, а не серебряная пуля. И если ПМ ясно представляет себе задачу, предметную область вообще, и главное - соотносит все со способностями своей команды, то он практически интуитивно (на самом деле - на основе набитых ранее шишек, своих и чужих) должен понимать, какими инструментами надо воспользоваться здесь и сейчас. Нет такого ПМа - бедный, бедный проект...
Оставьте свое сообщение