Интервью для zillion.net

Какое-то время назад ко мне обратилась Анастасия Подберезкина из 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 недель, сейчас — спорят про «одна или две».

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

Tagged , ,

Добавить комментарий

Ваш e-mail не будет опубликован.