Скрам - стр. 7
Я написал эту книгу, чтобы помочь людям понять, как использовать скрам для решения комплексных задач. Вместо описания процесса, ролей, артефактов, правил и практик скрама представляю вам набор реальных рабочих ситуаций, в которых люди используют скрам для разрешения комплексных проблем и выполнения комплексной работы. В некоторых из этих примеров действующие лица используют скрам правильно, и рассматриваемый проект в конечном итоге достигает своих целей. В других случаях люди сопротивляются скраму, и их проекты оказываются в итоге менее успешными.
Для тех, кто сопротивлялся, скрам не был интуитивно понятен. Я постарался разобраться, как такое может быть возможно, ведь скрам – очень простой процесс управления комплексными проектами. В сравнении со многими традиционными подходами к управлению проектами скрам практически не требует усилий. По крайней мере, сначала я так думал.
Большинство ответственных за управление проектами людей обучались предопределенному подходу к управлению проектами, в котором используются подробные планы, диаграммы Ганта и расписания. А скрам – полная противоположность. В отличие от традиционных инструментов, которые пытаются побороть естественное течение проекта, скрам демонстрирует менеджерам, как оптимально вести проект по курсу, который изменяется на ходу. Я слышал, что путешествие по кривой обучения начинается с момента, когда новичок должен все продумывать шаг за шагом, и заканчивается, когда он может выполнять новую работу неосознанно. Это особенно верно в отношении скрама, потому что люди, погруженные в традиционные методы управления, должны отучиться от многих привычных практик и инструментов.
Недавно я помог одной компании по разработке программного обеспечения начать использовать скрам. Первоначально компания планировала выпустить два релиза в течение следующих 12 месяцев. Однако благодаря успешному использованию скрама большая часть функциональных возможностей этих двух релизов была готова уже через пять месяцев. Посетив подразделение разработки, я узнал, что сотрудники работали по выходным и ночами, лишь бы добавить в релиз еще больше функциональности. Несмотря на то что инженеры трудились чрезвычайно продуктивно, маркетинг все еще ругал их за то, что они поставляли недостаточно и не выполняли «обязательства». Разработчики чувствовали себя виноватыми за то, что не делали всего, что просил маркетинг, поэтому вредили своей личной жизни. Эта патология сохранялась, несмотря на выполнение 12-месячной работы двух релизов за пять месяцев. Старые привычки побороть очень сложно.