Не так давно я писал о книге “Черный лебедь. Под знаком непредсказуемости“, где говориться о маловероятных явлениях, которые, случившись, могут кардинально повлиять на наши планы или наши представления, основанные на нашем опыте. Такие явления называются «Черным лебедем», так как до открытия Австралии люди не могли даже предположить, что лебеди могут быть НЕ белыми.

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

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

Лебедь первый: «человеческий фактор»

Обычно, на «человеческий фактор» принято списывать все непредсказуемые явления и многие даже не пытаются их предугадывать и страховаться от них.

Однажды читал о таком интересном «коэффициенте автобуса» (Bus factor) – который можно посчитать как 1/x, где x показывает, сколько человек из вашего проекта нужно сбить автобусом, чтобы проект потерпел крах. Жестоко, зато наглядно. Если коэффициент равен 1, то значит, у вас есть один незаменимый человек, потеря которого критична. И даже если он не болел последние пять лет, то это не означает, что такого не случиться в ближайшем будущем (черный лебедь).

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

Лебедь второй: незаметные задержки

Как написано в любой книге или презентации про Scrum, Burndown график является одним из обязательных артефактов. Такой ниспадающий график, показывает количество оставшегося времени, необходимого для завершения того, что находится в бэклоге спринта. Сам по себе график является мощным инструментом, конечно при условии, что его регулярно и правильно обновляют :-).

Так получилось, что я чаще работаю с командами-оптимистами, которые изначально планируют спринт почти по максимуму. Так или иначе, жизнь вносит свои сюрпризы (просто стаи лебедей), и в течение даже двухнедельной итерации много чего может пойти не так, как планировали. Собственно, график и показывает, что если на борьбу с трудностями мы потратили времени больше, чем планировалось, то, скорее всего, мы не сделаем все, что планировали. И тут уже не нужно ждать конца итерации, чтобы «обрадовать» своего владельца продукта, а лучше вовремя распознать проблему и прийти договариваться о возможных вариантах.

Кстати, точно такой же график можно строить для всего выпуска продукта (релиза). Представьте себе, что на картинке снизу по оси Х отложены спринты, которые у нас есть до дня Д, часа Ч и полной демонстрации готового продукта широкой общественности. Если у вас на проекте кривая имеет такую же тенденцию, то тут уже точно придется вызывать скорую для менеджеров, а команде, возможно, придется работать по вечерам и выходным. «И оно вам надо?», как говорят в Одессе. Всего этого можно избежать, если регулярно обновлять график после каждой итерации, и анализировать сложившуюся ситуацию с последующей коррекцией планов.

Лебедь третий: мусор под ногами

Как уже говорилось, задним числом эффект «Черного лебедя» кажется предсказуемым. Чаще всего наша психика сама отсекает «плохие варианты», и мы не замечаем того, что у нас буквально под носом. Самым видимым радиатором информации в проекте является Доска Задач. Вот пара примеров из недавней практики…

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

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

Вариантов решения может быть много, я не буду на них останавливаться – главное, чтобы команда и ScrumMaster своевременно поднимали панику обращали внимание на такую ситуацию.

Еще один знак, который подает нам доска – это колонка «в работе». И не надо быть большим знатоком Lean процесса, который говорит об ограничении «незавершенного производства», чтобы предположить, чем это нам чревато.

С ходу могу предложить следующие варианты «лебедей»:

• В работе находится требований больше, чем разработчиков.
  Люди редко могут успешно работать больше, чем над двумя задачами, все остальное, скорее всего, отсутствие реального прогресса, что в целом распыляет фокус и снижает общую продуктивность
• Каждый разработчик взял себе по требованию, а то и  по два.
  В этом случае теряется эффект совместной командной работы. Каждый занят «своим», и зачастую даже нет времени помочь другому, когда тот открыто просит о помощи. Ведь в этом случае «я свое не успею» 😉
• В работе находятся требования не по порядку приоритетов, а по тому, что смогли взять разработчики в силу своих интересов или специализации (привет первому лебедю).
  Тут очевидно, что наш заказчик не будет счастлив, когда не увидит в конце спринта наиболее критичную для него функциональность. Ведь он же ее специально поместил  на верх списка 😉

Как видите, легкий и поверхностный анализ знаков, которые подает нам наш проект, позволит выявить возможных «черных лебедей» и как следствие избежать ненужных проблем. Не за это ли мы ценим Agile подходы? 🙂