Все о SCRUM. Изучение, разработка, интеграция

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

В предыдущем издании я говорил об усилиях, но не о размере. Я изменил мнение после многократного опыта, подкрепленного чтением книги «Exploring Scrum» [Роастхорн, Exploring]. В ней Дэн Роастхорн развил концепцию Рона Джеффриса об относительной сложности.

Оценка размера, основанная на относительной сложности, включает в себя объем информации, которую нужно обработать для одной истории. История может быть простой, но состоять из множества фрагментов. Это не просто техническая сложность. Речь обо всем, что необходимо сделать для завершения истории.

18.6.3 Не та аудитория

Ситуация. Узнав об индикаторах, бывший менеджер проекта, а ныне Scrum-мастер, с большим рвением составляет всевозможные графики и представляет их руководству.

Последствия. Он тратит много времени за составлением графиков. Некоторые индикаторы предназначены для команды и совершенно бесполезны для заинтересованных сторон – например, burndown-график спринта.

Как сделать лучше? Недостаточно просто составлять графики, нужно понимать, для кого какой индикатор предназначен. Гениальность – в простоте.

Использование небольшого количества самых простых индикаторов способствует прозрачности и позволяет Scrum-мастеру не тратить времени на построение графиков, а затем их объяснение – особенно тем, кто привык к традиционному управлению проектами.

Рисунок 18.8 – Измерение и индикатор

Чтобы идти дальше

Книги

‣ Норман Балларжон, «Petit cours d’autodéfense intellectuelle», издания Lux, 2006. Книга, чтобы научиться считать и правильно толковать индикаторы.

‣ Dan Rawsthorne, Doug Shimp, «Exploring Scrum, The Fundamentals», CreateSpace Independent Publishing Platform, 2011

Онлайн-ресурсы

‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/

‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum

19 Объединение инженерных практик и Scrum

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

В сети регулярно появляются колкие, но справедливые комментарии об их важности – например, этот пост @pierreroth64 в Твиттере:

В ином случае это гарантированное кровопролитие и несправедливо ужасная реклама Scrum.

Scrum не сосредоточен на инженерных практиках разработки ПО, их применение совершенно добровольно, ведь Scrum может использоваться и в других областях.

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

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

Цель этой главы – объединить Scrum с практиками разработки программного обеспечения. Мы обсудим самые распространенные из них и посмотрим, как они вписываются в Scrum-фреймворк.

19.1 Практики, относящиеся к коду

Мы коснемся только тех практик, что появились в Экстремальном Программировании (XP). Однако старые методы разработки – управление версиями, отслеживание правил кодирования, просмотр кода и т. д. – также необходимы для обеспечения качества разработки ПО.

19.1.1 Непрерывная интеграция

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

• Важная практика

Регулярная интеграция кода каждого разработчика – практика, важная при последовательной разработке.

Как сказал Мартин Фаулер, ярый приверженец этой практики: «Я считаю, что все команды должны использовать непрерывную интеграцию. Инструменты бесплатные. Цена – разве что обучение» [57].