Технический долг затуманивает прозрачность и делает решения сомнительными. Мы измеряем наш прогресс путем сравнения законченных, готовых к использованию фрагментов функциональных возможностей программного обеспечения с оставшимися необходимыми фрагментами. Мы не берем в расчет незаконченную работу. Тем не менее очень много разработчиков программного обеспечения производят незаконченные инкременты. Обычно, когда членов команды спрашивают, почему они частично закончили некоторое количество требований бэклога продукта, вместо того чтобы выбрать меньшее количество и закончить полностью, они говорят: «У нас не было времени». Мы должны обратиться к нашему Scrum-мастеру, чтобы убедиться, что такого не произойдет.
Программное обеспечение за 30 дней обеспечивает предсказуемость, контроль рисков и оптимальную ценность. Краеугольный камень этих возможностей – постоянная прозрачность. Как минимум каждые 30 дней вы можете увидеть то, что покупаете. Многие разработчики борются со старыми привычками и недостаточными профессиональными навыками, чтобы создать эту прозрачность. Есть множество разработчиков, которые переступили эту пропасть. Вам следует выбирать разработчиков и инвестировать в них, пока они не смогут надежно создавать программный продукт, или найти других специалистов, которые смогут это сделать для вас.
Scrum-студия разработки программного обеспечения – обособленная организация внутри вашей общей организации. Студия не делает попыток изменить существующий процесс разработки всей организации – скорее она организуется для того, чтобы каждый, кто хочет использовать Scrum для разработки программного обеспечения, мог туда пойти. Студия начинает с малого и растет, пока не подтвердит свою ценность, постепенно становясь местом, где разработка программного обеспечения продуктивна, отличается высоким качеством и ценностью. Риск находится под контролем, а проекты управляются предсказуемо. Тестирование и показатели используются для достижения результатов опытным путем, чтобы вдохновить постоянное совершенствование.
Scrum-студия – простой и быстрый путь для начала использования инкрементального, непрерывного улучшения в разработке программного обеспечения. Scrum и показатели студии помогают выявить проблемные области.
8. Scrum на уровне организации
Многие организации принимают решение перейти на Scrum. Как и в случаях со многими другими типами организационных преобразований, результаты зависят от многих факторов. Некоторые фактические результаты описаны в этой главе наряду с обстановкой, которая создана для каждого из них.
Мы работали со многими организациями, большими и маленькими, чтобы помочь им трансформироваться и получить эти преимущества. Первая публикация об этих усилиях, The Playbook for Achieving Enterprise Agility («Пособие для достижения бизнес-гибкости»), выпущена в 2005 году в результате сотрудничества Кена Швабера с корпорацией Rally. Она не была доступна широкой публике, но часто используется при развертывании Scrum. С этой публикацией можно ознакомиться в Приложении 2.
Позже, в 2007 году, Кен написал книгу об адаптации Scrum на уровень организации, The Enterprise and Scrum[12]. Он описал стратегию и тактику для этой адаптации. Тактика применения Scrum для управления самой трансформацией также объяснялась.
Тип адаптации, который мы уже увидели, как правило, весьма приятен. Организация регулярно выпускает качественные, ценные релизы программного обеспечения, и они хорошо принимаются пользователями. Отделы разработки и продвижения продуктов эффективно работают вместе, чтобы формулировать и предоставлять новые релизы.
В процессе перехода к Scrum вся работа организации переворачивается, находясь в контролируемом хаосе в течение нескольких лет.
В конечном счете релизы программного обеспечения станут лучше, сотрудники будут ходить на работу с удовольствием, а потребители полюбят сотрудничество с вашей организацией. Тем не менее преобразование зависит от высшего руководства, которое его запускает. Очень часто этот человек идет на повышение, или его нанимают где-то еще до того, как другие люди, которые понимают новый способ мышления и работы, развиваются в рамках всей организации, и до того, как трансформации закреплены в самой организации. Поэтому, когда он покидает организацию, улучшения не закрепляются. Старая культура работы, на которую новые методы накладывались, не искоренена полностью и вновь проявляет себя. Совершенство и непрерывное улучшение медленно снижаются. Организация остается во много раз лучше, чем она была до того, как стала использовать Scrum, но не на том уровне, на котором могла бы быть. Люди начинают стараться. В течение нескольких лет организация становится лучше, чем в самом начале, но это еще не гибкая Scrum-организация. Возможность была упущена.