Софт за 30 дней. Как Scrum делает невозможное возможным - Джефф Сазерленд 16 стр.



Таблица 7.1. Опросник


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

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

Управление с помощью цифр

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

КОНЕЦ ОЗНАКОМИТЕЛЬНОГО ОТРЫВКА

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

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


Рис. 7.2. Инструментальная панель проекта


1. Продуктивность  это количество единиц бизнес-функционала, которое разработано на определенное количество денег (например, на 100 тысяч долларов инвестиций). Продуктивность также называют скоростью. Это показатель не ценности, а только количества произведенного функционала. Изначально произвольная единица функционала определяется и измеряется. Размер измеряется в функциональных точках, объективной и абстрактной системе измерений для программного обеспечения[8]. Функциональные точки универсальны и могут быть применены везде в пределах системы, продукта или для любой другой системы. Весь другой функционал определяется относительно базовой единицы. Эта система измерений (измерение размера единицы функционала в функциональных точках) становится стандартным показателем студии. Базовая единица требует периодической калибровки, чтобы гарантировать ее соответствие.

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

3. Ценность  мера того, насколько ценен созданный функционал для организации. Это мера эффективности (в процентах) от каждого доллара, потраченного на разработку программного обеспечения, которая создает ценность для организации. Показатель ценности не включает рыночную ценность. Рыночная ценность отражает показатель ROI, о котором мы не станем говорить в рамках этой книги. В среднем в общем уровне затрат на создание ценности в организации на разработку программного обеспечения затрачивается меньше 10 % от каждого доллара. Значительный процент расходуется на поддержание и сохранение существующих систем. Также большое количество средств идет на разработку функционала, который используется не очень часто. Большая часть денег тратится на создание программного обеспечения, которое могло быть полезным где угодно, но не в пределах организации, которая за него платит.


Инструментальная панель студии отражает тенденции по повышению продуктивности и качества, как показано на рис. 7.3.


Рис. 7.3. Инструментальная панель качества и продуктивности


Следующая панель отражает тенденции в увеличении ценности и ROI, как показано на рис. 7.4.


Рис. 7.4. Инструментальная панель ценности и возврата инвестиций


Можно учитывать еще несколько показателей.


1. Стоимость владения. Программное обеспечение имеет три составляющие расходов для организации разработчика, которые определяют полную стоимость владения продуктом:

 разработка  средства, выделяемые на разработку продукта или системы;

 техническое обслуживание  затраты на поддержание, сохранение и развитие продукта;

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

2. Проекты. Количество проектов, чьи данные объединяются и отображаются.

3. ROI студии. Это показатель накопительного возвращения инвестиций, или общее значение прибыли, полученной от проектов, деленное на затраты на содержание студии. Это также показатель экономии, полученной в процессе улучшения производительности, в сравнении с затратами на поддержание и улучшении студии. Многие организации не знают показателей продуктивности своих подразделений, занятых разработкой программного обеспечения, особенно с точки зрения предоставляемого бизнес-функционала. Scrum-студии часто вынуждены создавать первые измерения производительности. Они используются в качестве исходных условий для всех последующих улучшений.

КОНЕЦ ОЗНАКОМИТЕЛЬНОГО ОТРЫВКА

Таблица 7.2 показывает примеры показателей, которые могут быть сделаны в студии.


Таблица 7.2. Инструментальная панель тенденций


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

Рассмотрим некоторые из этих воздействий.


 Функциональные возможности, которые редко используются, по-прежнему должны быть сохранены и увеличивают эксплуатационные расходы.

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

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


Вы, наверное, привыкли к гораздо большему количеству показателей, таких как «заработанная ценность». Эти показатели были для вас очень важными, потому что отсутствовал другой способ оценить прогресс и текущий риск разработки проекта. Scrum заменяет эти показатели на надежное материальное свидетельство в конце каждого спринта. У вас есть серьезный инкремент функционала, который может быть незамедлительно использован. Все показатели подчинены ценности и стоимости этого функционала.

Показатели зависят от прозрачности

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

Scrum обеспечит вам следующие возможности.


1. Знание того, как много функционала программного обеспечения осталось создать. Даже после того, как вы внесли массу изменений, вы всегда сможете спрогнозировать, что осталось сделать.

2. Представление о том, какой функционал уже сделан. Функционал соответствует тому, сколько денег потрачено. Это прибыльно.

3. Понимание, сколько функционала было реализовано за несколько последних спринтов. Это позволит вам сделать прогноз относительно того, сколько времени займет создание оставшегося функционала. Помните, что это сложная работа и будущее может измениться, но что-то всегда лучше, чем ничего.

4. Возможность взять один или несколько инкрементов функционала, которые уже закончены, и начать ими пользоваться, изучая ценность на раннем этапе.


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

Законченный инкремент функционала

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

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

У нас есть опыт работы с последствиями отсутствия прозрачности в крупной энергетической компании в 2002 году. Scrum был опробован в одном из отделов, менеджер которого, Дэвид, был в восторге от прозрачности, обеспечиваемой Scrum. К сожалению, он не убедился, что инкремент полностью доделан и годен к употреблению. Он даже не знал, что должен это делать. Вот его история.

Дэвиду нужно было автоматизировать получение его департаментом сведений об изменении собственности  они занимались обработкой и выплатой лицензионных платежей землевладельцам в начале каждого финансового года. Дэвид должен был быть уверен, что информация актуальная, поскольку отвечал за имущество на территории Соединенных Штатов и Канады.

Назад Дальше