Что представляют собой Agile-подходы и в частности Scrum?

Что бы было более понятно, и если кратко, то быструю и дешевую адаптацию к изменяющимся требованиям. Слово «дешевая» здесь подразумевает не только экономию денег заказчика, но и экономию нервов исполнителей. Помните анекдот? «Молодцы, классную яму выкопали! А теперь подвиньте ее на пять метров левее». Ситуации, когда твоя работа идет на свалку, – страшный демотиватор.

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

– Я скажу так: если у вас все хорошо, то и скрам не нужен. Если же что-то идет наперекосяк, то практики скрам могут пригодиться. Правая рука не знает, что делает левая? Стендапы в помощь. Заказчик замучил проверками и считает бездельниками? Будет полезен еженедельный показ достижений, то есть демо. Часто приходится переделывать результаты работы, которая заняла месяц? Опять же, делаем еженедельные демо. Срываем сроки, потому что все время происходят какие-то неожиданности? Помогут Planning Poker и Burndown’ы. Planning Poker при всей своей наигранности позволяет вскрыть проблемы на этапе планирования, а не тогда, когда уже поздно. Срываем сроки, потому что их спускают сверху? А вот это уже со скрам совместимо только тогда, когда команда может определять объем работ для этих сроков.

Вот, кстати: для каких компаний, заказчиков, команд и проектов Scrum подходит, а для каких – нет?

– Скрам сам по себе не нужен, разве что продажникам, чтобы продать услуги клиенту, который знает, что «Scrum – это круто и модно». И то: продажа – это уже цель. Scrum решает задачи, причем не все – бывает, и несовместимость. Например, очень сложно совместить авторитарный стиль управления с гибкостью. Это показывают и практика, и обширная теоретическая база психологии: можно почитать, в частности, у Эрика Берна о модели «Родитель-Взрослый-Дитя» и т. д. Если в компании много (!) значимых людей-тиранов, всезнаек, капризных звезд, нытиков и ворчунов, раздолбаев и болтунов – тут также будут сложности.
«И фигурально, и буквально: для ремонта в отдельно взятой квартире скрам вполне подходит, а для уборки картошки – нет. Разве что в том случае, если в процессе возникают непредсказуемые сложности: от визита санэпидемстанци до изменения гравитационной постоянной».
Дізнайтесь по договорі відносини в Україні, та також, про земельні відносини в Україні. Оренда землі. Нові закони. Плата за землю.

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

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

Часто Scrum используется не целиком, а отдельными практиками: бэклогами (Backlog), берндаунами (Burndown), стэндапами (Standup). Backlog – это список задач проекта: ближайшие описываются подробно, а остальные – нет. Burndown – это график, в котором ось X – время, а ось Y показывает, сколько работы осталось. Там же есть идеальный график, то есть прямая линия от старта до финиша. Стендапы – это короткие пятиминутки, которые проводятся стоя для всех каждый день в одно и то же время. Каждый участник в трех предложениях рассказывает о том, что делал, что будет делать и какие есть проблемы.

Какие ошибки и неудачные ситуации типичны в практике Scrum?

– Основная ошибка, которую я вижу: люди не понимают, зачем им скрам нужен. Здесь хорошо работает техника «договор на крови». Пара примеров.

«Коллеги, у нас сложилась такая ситуация: Вася и Петя начали работать над одним и тем же модулем одновременно. В результате поломали друг другу работу и будут сидеть совмещать изменения. Каждый не знал, что второй сейчас тоже работает над этим модулем. Мы потеряли один день, а релиз все ближе. Как мы можем предотвратить такие провалы в будущем?» Слушаем ответы, пробуем по предложенному. Если предложений нет или они себя не оправдали, предлагаем внедрить пятиминутки с тремя вопросами: «Что закончил за день? Что планирую закончить на завтра? Есть ли проблемы?»

Или такой пример: «Мы классно сделали модуль отчетов. Спроектировали, реализовали, прикрутили дизайн, протестировали, исправили ошибки, перепроверили. Показали заказчику – он сказал, что ему совсем другие отчеты нужны. Что делать, чтобы в будущем это не повторялось? Пусть заказчик точнее формулирует требования? Хорошая мысль, попробуем, только этот заказчик  – "творческий" человек, четкости от него ждать не стоит. Еще идеи? Как минимизировать потери? А давайте показывать сырой вариант, без дизайна и багфикса? Скажем, раз в неделю?»

Это все к тому, что практики Scrum внедряем по мере надобности и для решения задач, а не для галочки.

То есть их можно внедрять по отдельности: брать то, что подходит к задаче и команде? А можно так: «Ребята: с понедельника всю работу переводим на скрам»?

– Можно и так и так. Кто-то говорит: «Давайте сделаем сразу». А кто-то: «Давайте сделаем постепенно». В моей практике получалось и так и так, но с оговоркой, что сторонники подхода «все и сразу» имели успешный опыт работы по Scrum в других компаниях или были директорами.

Необходимо ли юридически регламентировать разработку продукта по Scrum в договоре с заказчиком?

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

Возникает ощущение, что в Scrum невероятное множество теоретических и эмпирических нюансов: можно ли научиться Scrum самостоятельно и начать практиковать в своей компании? Или так: тренинг, а затем самостоятельная практика?

– Лучше всего, конечно, поработать по Scrum в компании, в которой это «работает». Например, там, где проект набирает достаточно много баллов по Nokia Scrum Test. Если же внедрять скрам с нуля и без возможности попробовать, все пути подойдут: и чтение книг, начиная с коротенькой «Scrum и XP: заметки с передовой» Хенрика Книберга, и наш обучающий курс «Эмоциональный Scrum», и тренинги – по Scrum, по коммуникациям на проекте и по конфликтологии. Тренинги для команды многое могут дать. Часто какие-то практики разработки не приживаются не по техническим причинам, а из-за человеческого фактора. Это касается и Scrum, и Test Driven Development и т. д. Пример: в команде формально практикуют скрам, но задачи раздает один человек, он же выдает оценку по времени и контролирует результат. Его желание все контролировать сводит к нулю энтузиазм и скорость работы остальных. Или другой пример: кто-то попробовал внедрить практику стендапов, но не смог уговорить всех проводить их стоя и слушать собеседников. В результате один человек бубнит десятиминутную лекцию о том, как ему сложно работать, а остальные тихо храпят в креслах в ожидании своей очереди. (Zillion: TDD – разработка через тестирование. Continuous Integration – практика разработки «Непрерывная интеграция», суть которой в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.)

Если почитать отзывы, то ощущение, что скрам-опыт очень разнообразен, и во всех проектах/командах возникают свои нюансы. Вы могли бы привести еще показательные примеры, отражающие типичные ситуации в скрам-проектах?

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

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

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