Какое-то время назад ко мне обратилась Анастасия Подберезкина из zillion.net с просьбой дать интервью. Интервью давно опубликовано, а вот теперь дошли руки перенести и сюда тоже.
О себе – лично мой опыт в Скраме неоднозначен. Где-то он завелся, а где-то провалился. Так что дальше будет скептически-прагматический взгляд от человека, который знает IT, психологию, и имеет большой опыт в “хотели как лучше, а получилось… ну, получилось”
Если вы хоть что-то про Scrum/Agile знаете – первые вопросы/ответы будут банальными.
Что представляют собой Agile-подходы и в частности Scrum?
Если кратко – быструю и дешевую адаптацию к изменяющимся требованиям. Под дешевой здесь не только деньги заказчика, но и нервы исполнителей.
-
“Молодцы, классную яму выкопали! А теперь подвиньте ее на пять метров левее”.
Ситуации, когда твоя работа идет на свалку – страшный демотиватор. Agile позволяет узнавать о неправильных ямах заранее.
Как вам кажется, необходимо ли обучать работе в фреймворке Scrum в IT-вузах, на этапе изначального IT-образования. И идет ли речь только об IT-сфере или в других областях Scrum тоже эффективен?
Я читал про успешные примеры использования практик скрама в ремонте (бэклог, burndown), семейных текущих делах (скрам-доска).
Я бы сказал так – везде, где есть измеримое окончание задачи и важна инициативность участников. Ну и если на проекте все предсказуемо, нет частых изменений, то традиционное планирование может быть лучше.
-
Для ремонта в отдельно взятой квартире – скрам вполне подходит. А на уборке картошки – нет. Разве что по ходу возникают непредсказуемые сложности: от визита санэпидемстанции, засухи, наводнения, и до изменения гравитационной постоянной.
Часто набор практик использовался не целиком, часто только отдельными практиками – бэклогами (список задач проекта, ближайшие – подробно, остальные – нет), burndownами (график, по иксу – время, по игреку – сколько работы осталось. Там же на графике – идеальный график, прямая линия от старта до финиша), стэндапами (короткие пятиминутки стоя каждый день в одно и то же время для всех, где все в три предложения рассказывают о том, что делали, что будут делать, и говорят о проблемах).
Насчет обучения в ВУЗах – спорно это. Скрам, он для решения проблем. В ВУЗе еще нет понимания того, что проблема есть. Командная работа на курсовых и лабораторках обычно выглядит как “один пишет программу, второй – отчет, остальные – пиво им носят”.
Здесь много чего можно еще сказать – и про самоорганизацию команд (откуда она в ВУЗе?) и про ориентацию на конечный результат (задача “сдать” и “чтобы ей пользовались реальные люди” – это разные задачи).
То есть проблема получается глубже?: можно было бы учить решать проблемы по скрам, но из-за отсутствия прикладного обучения, не понимают даже, что такое проблемы в практике – так?
Да, именно так. Есть еще такой термин – “зона ближнего развития”. Эффективное обучение только в нем и идет. Например, мне будет бесполезен продвинутый курс китайского языка – я и начальным-то не владею.
Кому и для чего полезно использовать скрам? Какой эффект он дает и как те же процессы происходят при традиционной разработке – в сравнении? (Вопрос ориентирован на сомнения читателей, думающих, что это такая «забава», в которой больше игрового момента, чем реальной эффективности).
Я бы переформулировал так – если у вас все хорошо, то и скрам не нужен. Если же что-то идет наперекосяк, практики скрама могут пригодиться.
-
Правая рука не знает, что делает левая? Стэндапы в помощь.
-
Заказчик замучал проверками и считает бездельниками? Еженедельный показ достижений (демо) пригодится.
-
Часто приходится переделывать результаты месяца работы? Хорошо, делаем еженедельные демо.
-
Срываем сроки, потому что все время происходят какие-то нежданчики? Planning Poker и Burndown нам помогут. Про бюрндауны уже было сказано, а Planning Poker при всей своей наигранности позволяет вскрыть проблемы на этапе планирования, а не тогда, когда уже поздно.
-
Срываем сроки, потому что их спускают сверху? – Это со скрамом не совместимо
Для каких компаний, заказчиков, команд и проектов Scrum подходит, а для каких – нет?
Еще раз – Scrum сам по себе не нужен. Разве что он иногда нужен продажникам чтобы продать услуги клиенту, который знает, что “Scrum – это круто и модно”. И то – продажа – это уже цель.
Итак, Scrum решает задачи. Причем – не все. Бывает, и несовместимость. Например, очень сложно совместить авторитарный стиль управления с гибкостью. Это показывает и практика, и обширная теоретическая база психологии (см. Эрик Берн, модель Родитель-Взрослый-Дитя и т.д.)
Также, если в компании есть много(!) значимых людей-тиранов, всезнаек, капризных звезд, нытиков и ворчунов, раздолбаев и болтунов – тут будут сложности.
Какие ошибки и неудачные ситуации типичны в практике скрам?
Основная ошибка, которую я вижу: люди не понимают, зачем им скрам нужен. Здесь хорошо работает техника “договор на крови”.
-
“Коллеги, у нас сложилась такая ситуация, что Вася и Петя начали работать над одним и тем же модулем одновременно. В результате – поломали друг другу работу и будут сидеть совмещать изменения. Они не знали, что второй тоже сейчас над этим работает. Мы потеряли один день, а релиз – все ближе. Как мы можем предотвратить такие провалы в будущем?” <слушаем ответы> <Пробуем по предложенному>. Если предложений нет, или они себя не оправдали – предлагаем внедрить пятиминутки с тремя вопросами “Что закончил за день? Что планирую закончить на завтра? Есть ли проблемы?”
-
“Мы классно сделали модуль отчетов. Спроектировали, реализовали, прикрутили дизайн, протестировали, исправили ошибки, перепроверили. Показали заказчику – он сказал, что ему совсем другие отчеты нужны. Что делать, чтобы в будущем это не повторялось? … Пусть заказчик точнее формулирует требования? Хорошая мысль, попробуем, только этот заказчик очень творческий человек, четкости от него ждать не стоит. Еще идеи? … Как минимизировать потери? … А давайте показывать сырой вариант, без дизайна и багфикса? Скажем, раз в неделю?”
Практики скрама внедряем по мере надобности! И для решения задач, а не для галочки.
То есть их можно внедрять по отдельности – что подходит к задаче и команде? а не так, что “ребята: в понедельника всю работу переводим на скрам”?
Можно и так, и так. Кто-то говорит “давайте сделаем сразу”, кто-то “давайте сделаем постепенно”. С моего опыта, получалось и так, и так. С оговоркой – сторонники подхода “всё и сразу” имели успешный опыт работы по скраму в других компаниях или были директорами.
Необходимо ли юридически регламентировать разработку продукта по скрам в договоре с заказчиком?
Если вы знаете зачем вам это, то да :)
Скрам – это не цель, это инструмент для достижения цели.
В моей практике заказчики обычно больше на результат ориентируются, чем на формальные пункты. Хотя, с крупными корпорациями всякое может быть.
А зачем это делают? я встречала такие отзывы о необходимости юридического закрепления каких то моментов – какие проблемы в работе со скрам-разработчиками пытаются решить таким образом? Какой-то пример из жизни может быть, в двух словах?
У меня нет примеров, где скрам был оговорен в контракте. На мой взгляд, если заказчик требует скрам от команды, которая по скраму не работала, это до добра не доведет. Если же это испонитель требует от заказчика и вносит этот пункт в договор, то здесь нужно подробно расписывать, что именно от заказчика требуется. К примеру – регулярно смотреть на демо.
Возникает ощущение, что в Scrum невероятное множество теоретических и эмпирических нюансов: можно ли научиться Scrum самостоятельно и начать практиковать в своей компании? Необходимо ли всегда приглашать Scrum-тренера – какова его роль? Или же это тренинг, а затем самостоятельная практика? Как часто и каким образом нужно проводить обучение, тренинги для команды?
Лучше всего, конечно, поработать по скраму в компании, в которой скрам работает. Например, где проект набирает хорошее количество баллов по Nokia Scrum Test.
Если же его внедрять с нуля и без возможности попробовать – да, тут все пути подойдут. И чтение книг – от коротенькой “Scrum из окопов” Книберга” до нашего обучающего курса “Эмоциональный Scrum”, и тренинги – как по скраму, так и по комммуникацям на проекте и конфликтологии.
Тренинги для команды – многое могут дать. Часто какие-то практики разработки не приживаются не из-за технических причин, а из-за человеческих. И это касается и скрама, и test driven development и continuous integration и т.д.
Примеры:
-
в команде, формально, скрам. Но задачи раздает один человек, он же выдает оценку по времени и контролирует результат. Желание всё контролировать от него сводит к нулю энтузиазм и скорость работы остальных.
-
кто-то попробовал внедрить практику стэндапов, но не смог уговорить всех проводить их стоя и слушать собеседников. В результате, один человек бубнит десятиминутную лекцию о том, как ему сложно работать, а остальные тихо храпят в креслах в ожидании своей очереди.
Владимир, расскажите о вашем опыте скрам-тренера? А вообще где и как обучаются на скрам-тренера? Правильно ли я понимаю: есть сертифицированные тренеры и несертифицированные? Сколько стоит сопровождение проекта scrum-тренером и необходимо ли оно на каждом проекте?
Насколько я знаю, есть сертификация только на скрам-мастеров. Стоит сравнительно недорого, занимает курс всего несколько дней, работодателем особо не ценится.
Рынок скрам-тренеров обширен, у каждого свои подходы и решения, и у каждого свои цели. Определитесь со своими задачами и проблемами – и гуглите.
А как понять, что задачу поможет решить именно скрам?
Да, тут нужно просмотреть хотябы пару страниц описания. Или задать вопрос подходящим людям. Можно и мне написать на [email protected]
Если сравнивать с разработкой вне скрам по критериям времени и затрат: сколько будет стоить владельцу продукта разработка проекта по скрам и есть ли какой-то выигрыш во времени (сколько месяцев, среднем?)
С численной оценкой сложно, очень много входных параметров. О серьезных статистических исследованиях я здесь не слышал. Тут бы на команду и на заказчика посмотреть. Рискуя попасть пальцем в небо, попробую обозначить коридор значений: врядли удасться ускориться больше, чем вдвое. И врядли переход даст меньше, чем 10%.
Ну порядок цен, для общего представления – для команды скрам-суперзвезд и средних нормальных спецов)
Давайте попробуем вывести формулу для расчета цены опаздания (не помню проектов, которые бы опережали график).
Вот у нас есть проект с поэтапной оплатой, мы знаем, что потратим на первый этап N денег на зарплату, аренду, налоги, амортизацию железа и т.д. От заказчика же получим M денег. Наша ожидаемая прибыль = M-N. И пусть первый этап будет K месяцев.
В классической схеме, мы примерно к половине проекта понимаем, успеем или нет. Обычно, если не успеваем, то тут же начинаются идеи “а давайте таки успеем и будем работать по выходным”, “дальше задачи будут проще” и т.д. В результате, после 0.7 * K мы понимаем, что не успеем никак, и наша прибыль (M-N) будет съедена опазданием целиком. И весь выбор – продолжить работу себе в убыток или списать 0.7 * N денег.
-
Пусть этап – четыре месяца, и четверым сотрудникам мы платим по $1500 и еще столько же – на налоги, аренду и т.д. N = 4 * (4 + 1) * 1500 = $30000. C заказчика мы получим M=$50000. Тогда ближе к концу третьего месяца, когда уже будет нельзя закрывать глаза на отставание, и мы увидим, что осталось еще как минимум на два месяца работы, у нас будет выбор – списать или нет $30000 * 0.7 = $21000.
-
В схеме, в которой применены скрамовские практики burndown и velocity и недельные итерации, мы получим сколько-то заметно точный прогноз через шесть интераций. Т.е. в начале-середине второго месяца мы уже будем знать “успеем / не успеем”. N = $30000 * 1.2 / 4 = $9000
Итого, для этого примера в классической схеме мы рискуем $21000, а с подсчетом velocity – $9000. Конечно, в этом примере очень много чего упущено – репутационные издержки, пени и т.д. Но все же. Если хотите, составьте такую формулу для своего проекта.
Владимир, расскажите, пожалуйста, что такое «эмоциональный скрам» – о психологических основах подхода?
Да. О том, что лежит под каждой практикой, почему она работает, и почему она может не работать. Серия двадцатиминутных очень сжатых роликов на практики скрама.
-
К примеру, ретроспектива. В принципе, уже одной правильной ретроспективы достаточно, чтобы двигать проект процессы в компании вперед. Но есть нарушения, которые могут испортить любую ретроспективу:
-
Сама ретроспектива воспринимается как “разбор полетов” и “публичная порка провинившихся”
-
На ретроспективе начинаются обвинения с переходом на личности “Ты поступил плохо”, “ты всех подвел” и т.д.
-
Обвинения выходят на уровень идентичности “Как человек с таким уровнем seniority мог допустить такую детскую ошибку? За что тебя поставили лидом?”
-
Неконкретные условия исполнения “Ты не умеешь писать Unit-Testы, и поэтому в следующий спринт должен стараться в два раза больше”.
-
В целом насколько работа по Scrum стрессовая? (если говорить о ситуациях конфликтов и непонимания между заказчиком и командой). Может быть, пару слов о методах решения таких проблем в скрам (ретроспектива, Prime Directive и т.п.)?
По сравнению с традиционными методами разработки, стрессы чаще переносятся на начало работы. Т.е. в обычной схеме мы получаем огромный стрес в конце, при сдаче проекта, когда все неудачные решения вскроются. А в скраме – серию более простых стрессов по ходу, пока болезнь еще не запущена. В скраме для этого есть инструментарий, но приводить его описание здесь не буду, длинно получится. К примеру, под многими практиками прячется психологическая установка Prime Directive “Вне зависимости от того, что мы определили или нашли, мы понимаем и искренне верим, что каждый делал лучшее из того, что мог, беря во внимание их знания, умения, навыки, ресурсы и обстоятельства на тот момент”.
Почему бывает так, что пытаются внедрить скрам у себя в компании, начинают, но ничего не получается и бросают? Правда ли, что есть противники скрам и с чем это связано?
Обычно это тогда, когда не понимают, что хотят решить. Если человек при начале внедрения говорил “мы хотим повысить производительность” и прочий marketing bullshit, то при внедрении у него большой шанс заметить, что до внедрения производительность не мерялась, а сам процесс измерения – требует времени. Из разочаровавшихся людей, которые зашли без четко сформулированных задач и проблематики, и получаются потом противники скрам.
-
“До этой работы у меня было ничего, а теперь – ничего и дергающийся глаз”
Цель нужна!
Встретила такое мнение, что Scrum – методология, созданная для защиты разработчиков от изменений условий проекта в процессе. И потому product owner в рамках скрам находится в менее выгодном положении. Так ли это?
Это мнение – один из хороших лозунгов, с помощью которых можно продать Scrum исполнителям. Да, product owner отказывается от мелких вмешательств в середине спринта. Крупные он все равно может сделать – в явном виде прервав спринт.
Про выгодность положения можно поспорить, т.к. он что-то теряет, а что-то и приобретает. Например, он экономит то время, которое обычно уходит на переключение с задачи на задачу. Человек вообще с трудом входит в поток, в то самое состояние, которое наиболее эффективно. А прерыванием на короткую двухчасовую задачу можно еще и часа три на разгон потратить.
Если почитать отзывы, ощущение, что скрам-опыт очень разный и во всех проектах/командах возникают свои нюансы. Вы могли бы привести несколько показательных примеров скрам-проектов из вашего опыта, отражающих типичные или нетривиальные ситуации?
Да, скрам-опыт очень разный. На то и agile, чтобы быть гибким и подстраиваться к разным требованиям, людям и задачам.
Пожалуй, первым приходит в голову типичная ситуация – топ-менеджер или заказчик прочитал где-то, что скрам – это хорошо. И поручил подчиненным внедрить. Они полгода помучались и сказали – “фигня ваш скрам, не работает”
Есть ли какие-то тенденции внутри скрам?
Из явно видимого – есть тенденция к коротким итерациям. Раньше говорили про 4-6 недель, сейчас – спорят про “одна или две”.
Остальные тенденции сложно уловить – слишком большая разница между проектами.
