Что такое Эмоциональный Scrum?

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

 - Сама ретроспектива воспринимается как «разбор полетов» и «публичная порка провинившихся».
 - На ретроспективе начинаются обвинения с переходом на личности «Ты поступил плохо», «Ты всех подвел» и т. д.
 - Обвинения выходят на уровень идентичности: «Как человек с твоим опытом мог допустить такую детскую ошибку? За что тебя поставили лидом?».
 - Неконкретные условия исполнения: «Ты не умеешь писать Unit-Test’ы, поэтому в следующем спринте должен стараться в два раза больше».

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

А в целом насколько работа по Scrum стрессовая? Если говорить о работе в команде и о ситуациях конфликтов и непонимания между заказчиком и командой?

– По сравнению с традиционными методами разработки, в Scrum - проектах стрессы чаще переносятся на начало работы. То есть при обычной схеме мы получаем огромный стресс в конце, при сдаче проекта, когда вскрываются все неудачные решения. А в Scrum это будет серия более простых стрессов по ходу работы, пока «болезнь» еще не «запущена». Для этого есть инструментарий, о нем можно долго говорить. Для примера: во многих практиках Scrum прячется психологическая установка Prime Directive: «Вне зависимости от того, что мы определили или нашли, мы понимаем и искренне верим, что каждый делал лучшее из того, что мог, и берем во внимание знания, умения, навыки, ресурсы и обстоятельства на тот момент».
«Если человек в начале внедрения говорил: "Мы хотим повысить производительность" и прочий marketing bullshit, то во время внедрения у него большой шанс заметить, что до внедрения производительность не мерялась, а сам процесс измерения требует времени. "До этой работы у меня было ничего, а теперь – ничего и дергающийся глаз". Цель нужна!»

Если сравнивать с традиционной разработкой по критериям времени и затрат, дает ли скрам какой-то выигрыш?

– С численной оценкой сложно: очень много «входных» параметров, и о серьезных статистических исследованиях я не слышал. Тут бы на команду и на заказчика посмотреть. Рискуя попасть пальцем в небо, попробую обозначить коридор значений: вряд ли удастся ускориться больше, чем вдвое, и вряд ли переход даст экономию времени меньше, чем 10%.

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

В классической схеме мы понимаем, успеем или нет, примерно к середине проекта. Обычно если не успеваем, то тут же начинаются идеи: «А давайте таки успеем и будем работать по выходным», «Дальше задачи будут проще» и т. д. В результате после 0,7*K мы понимаем, что не успеем никак и наша прибыль (M-N) целиком будет съедена опозданием. И выбор состоит в том, чтобы продолжить работу себе в убыток или списать 0,7*N денег. 0,7 вот откуда: через 50% времени начало появляться ощущение, что можем не успеть, а еще через 20% это стало очевидным настолько, что уже нельзя игнорировать.

Пусть этап – это четыре месяца, и четверым сотрудникам мы платим по $1500. Еще столько же уходит на налоги, аренду и т. д. Тогда N=4*(4+1)*1500. Таким образом, общая сумма зарплат составит $30 000. C заказчика мы получим (M) $50 000. Тогда ближе к концу третьего месяца, когда уже нельзя будет закрывать глаза на отставание и мы увидим, что работы осталось еще как минимум на два месяца, у нас будет выбор: списать или нет $30 000*0,7, то есть $21 000.

Если в схеме применены скрам-практики Burndown и Velocity, а также недельные итерации, то мы получим заметный и сколько-то точный прогноз через шесть итераций. То есть в начале-середине второго месяца мы уже будем знать, успеем или не успеем: N=$30 000*1,2/4=$9000. (Zillion: «Velocity» означает «скорость, быстрота». Это практика вычисления скорости команды путем подсчета завершенных частей работы за определенный отрезок времени.)

Итого в рамках этого примера, работая по классической схеме, мы рискуем $21 000, а с подсчетом Velocity, то есть скорости команды, при работе по Scrum – $9000. Конечно, в этом примере много чего упущено: репутационные издержки, пени и т. д. Но все же он достаточно нагляден. Такую формулу можно составить для своего проекта.
«Во многих практиках Scrum прячется психологическая установка Prime Directive: "Вне зависимости от того, что мы определили или нашли, мы понимаем и искренне верим, что каждый делал лучшее из того, что мог, и берем во внимание знания, умения, навыки, ресурсы и обстоятельства на тот момент"».
Більш детально, розповість Інна Старожукова, як спеціаліст, і дізнайтесь про семінари в Києві, та інших містах нашої країни.

Встретила такое мнение, что Scrum – методология, созданная для защиты разработчиков от изменений условий проекта в процессе. И потому Product Owner находится в менее выгодном положении. Так ли это?

– Это один из хороших «лозунгов», с помощью которых можно продать Scrum исполнителям. Да, Product Owner осознанно отказывается от мелких вмешательств в середине спринта. Но крупные он все равно может сделать: в явной форме – прервав спринт. Про выгодность положения можно поспорить, так как владелец продукта что-то теряет, а что-то и приобретает. Например, он экономит то время, которое обычно уходит на переключение с задачи на задачу. Человек вообще с трудом входит в поток – в то самое состояние, которое наиболее эффективно. А прерывание на короткую двухчасовую задачу, как правило, приводит к тому, что после этого сотрудник тратит часа три на разгон.

Как вам кажется, необходимо ли обучать работе в фреймворке Scrum в IT-вузах, на этапе изначального IT-образования?

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

Получается, проблема глубже: можно было бы учить решать проблемы по Scrum, но из-за отсутствия прикладного обучения студенты, по сути, не понимают даже, что такое практические проблемы?

– Да, именно так. Есть еще такой термин «зона ближнего развития»: эффективное обучение только в ней и идет. Например, мне будет бесполезен продвинутый курс китайского языка, я и начальным-то не владею.

А где и как обучаются на скрам-мастера?

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

А как понять, что задачу поможет решить именно скрам?

– Парой слов здесь не обойдешься. Просмотрите хотя бы пару страниц описания скрамовских подходов.

Есть ли какие-то тенденции внутри Scrum?

– Из явного – видна тенденция к коротким итерациям. Раньше говорили про 4-6 недель, а сейчас спорят: одна или две недели. Остальные тенденции сложно уловить, слишком большая разница между проектами.
«Скрам нужен для решения проблем, а в вузе еще нет понимания того, что проблема есть. Командная работа на курсовых и лабораторках обычно выглядит так: один пишет программу, второй – отчет, а остальные им пиво носят. Здесь много чего можно еще сказать. И про самоорганизацию команд – откуда она в вузе? И про ориентацию на конечный результат: "сдать" и "чтобы пользовались реальные люди" – это разные задачи».