1.2.1.1. Эмпирический процесс против процесса планирования. Scrum основан на убеждении, что сегодня большинство систем разработки имеют неправильную философскую основу, а именно что через все более и более эффективное планирование мы можем достичь более предсказуемых и более качественных результатов. Scrum определяет процесс разработки приложений как непредсказуемый и необычайно сложный (подумайте о сотнях тысяч созданных вручную строк программного кода). Ценность такого процесса может быть измерена только эмпирически. В конце концов каждое ваше приложение, разработанное другой командой в другом месте и при других обстоятельствах, будет отличаться от созданного вашей командой и в вашем контексте, поэтому готового рецепта, основанного на процессе пошагового планирования, не может быть.
Scrum определяет процесс разработки систем как свободный комплекс мероприятий, который сочетает в себе известные, эффективные инструменты и методы под управлением команды разработчиков в тесном сотрудничестве с владельцем/потребителем продукта. Так как многие из этих видов деятельности неточные, применяются средства контроля, такие как постоянный осмотр и демонстрация, чтобы управлять рисками в реальном времени и предоставлять эмпирическое подтверждение состояния проекта в любой момент времени.
Рекламный слоган Scrum прост:
Знать, где ты находишься каждый день, используя Scrum
или
Думать, что знаешь, где ты находишься, на основе хорошо составленного плана, и потом, но гораздо позднее, обнаружить, что сильно ошибался.
1.2.1.2. Устранить препятствия, чтобы команда могла делать свою работу. С годами организационные процессы и методы разработки программного обеспечения в каждой компании, как правило, накапливаются до тех пор, пока создание программного обеспечения не становится довольно сложной задачей. Когда Scrum начинает применяться, эти «организационные препятствия» на пути выпуска эффективного программного обеспечения становятся очевидными, потому что влияют на способность команды соответствовать быстрому, итеративному, пошаговому характеру Scrum. Удаление или изменение этих процессов и методов работы может выявить необходимость начала крупного проекта изменений на предприятии под контролем и управлением высшего руководства (более подробно эта тема раскрывается далее).
Более того, в Scrum команда – главное звено. В конце концов члены команды – те, кто реально проектирует, разрабатывает и предоставляет программное обеспечение, поэтому оптимизация производительности команды за счет устранения препятствий оптимизирует коммерческую производительность всего предприятия по доставке ценного продукта клиентам. Управляющий персонал делает свою работу, когда устраняет препятствия. Команда делает свою работу, когда выполняет свои обязательства, описанные в каждом бэклоге спринта.
Другими словами, в Scrum команда одновременно наделена и полномочиями, и обязанностями по доставке продукта. Команда хорошо делает свою работу, когда она самоорганизованна, самоуправляема и самостоятельно добивается выполнения целей спринта. Для многих организаций это переворачивает все с ног на голову. Иерархический, директивный стиль управления при применении Scrum естественным образом устраняется. Владелец продукта теперь только устанавливает набор задач и приоритеты, а члены команды решают, как этого добиться, и никто не должен указывать, как им это делать в процессе работы.
1.2.1.3. Лучший, хотя и не такой предсказуемый, результат против фальшивой уверенности. Scrum начинается с допущения, что создание программного обеспечения – сложный бизнес, существующий в изменчивом специализированном техническом пространстве, и никто не в состоянии надежно предсказать или точно спланировать, что команда сможет произвести, когда она сможет это сделать и какими в итоге будут качество и стоимость. Scrum считает, что только команды могут оценить эти вопросы, просчитать стоимость, договориться о ближайшем плане работы в зависимости от различных рисков и потом скорректировать этот план в процессе работы. Соглашение состоит в том, что команда предоставит лучшее из возможного в данных обстоятельствах программное обеспечение. Следование любому другому подходу, основанному на пошаговом выполнении плана, не способствует «улучшению» и только мешает команде отзываться на сложности реального мира и на его непредсказуемость.
Исторически сложилось, что пренебрежение этой философией создает ряд организационных проблем:
• руководство на самом деле считает, что может предсказать стоимость, срок выпуска и функциональность, которые будут предоставлены на основании планирования;
• разработчики и руководители проектов вынуждены жить во лжи: они притворяются, что могут планировать, прогнозировать и выполнять планы; они движутся своим путем, но делают вид, что идут по другому пути; в конце концов они, по существу, работают без контроля;
• к моменту релиза система часто оказывается неподходящей или требует существенного изменения; ключевая причина – то, что долгий процесс разработки и высокая стоимость повторной работы ограничивают нашу видимость полезности того, что команда на самом деле разрабатывает.
Признание этих реалий не происходит без проблем. Например, какой менеджер захочет сказать своему руководству, что он точно не знает, что ему предоставит команда разработки к определенной дате. Но у такого подхода имеются и преимущества: организация получит то, в чем действительно нуждается, – способность создавать лучшие продукты для конечных пользователей и делать это быстро и четко, обеспечивая себе конкурентное преимущество для ведения бизнеса.
1.2.2. Scrum и гибкость разработки программного обеспечения
Scrum используется начиная с середины 1990-х годов и в настоящее время применяется в тысячах проектов по всему миру. Наряду с ним за этот период получили признание несколько новых итеративных методологий. Как и Scrum, каждый метод представляет собой комбинацию старых и новых идей, но все они подчеркивают, что необходимо следующее:
• тесное взаимодействие между командой разработки и бизнес-экспертами;
• общение лицом к лицу (это более эффективно, чем документальная переписка);
• частое предоставление готового к развертыванию, представляющего ценность для бизнеса программного обеспечения;
• прозрачность целей, прогресса и артефактов;
• создание крепких, самоорганизованных команд;
• создание способов программирования и команды разработки, позволяющих обеспечивать непрерывную адаптацию к изменяющимся требованиям.
В 2001 году многочисленные основатели и последователи таких методологий, включая лидеров, использующих Scrum, встретились, чтобы понять, что у них всех есть общего.
Они выбрали слово «гибкий» в качестве объединяющего термина и создали Манифест гибкой разработки программного обеспечения, в котором заявили общие ценности.
