CC BY
67
Коротченко Е.Л.
Новосибирский государственный университет экономики и управления «НИНХ», г. Новосибирск, аспирант факультета прикладной информатики в экономике,
Применение адаптационного механизма использования относительных оценок в методологии скрам для реализации IT-проектов
КЛЮЧЕВЫЕ СЛОВА
Скрам, Scrum, разработка программного обеспечения, гибкая методология, agile, относительные оценки, стори пойнт, Planning poker, IT-проект.
АННОТАЦИЯ
В статье анализируется проблема применения одной из популярных методологий гибкой разработки программного обеспечения — "Scrum" (далее скрам). Цель данного исследования заключается в разработке адаптационного механизма использования относительных оценок в методологии скрам для реализации IT-проектов в консалтинговых организациях. В качестве основных методов исследования использовались: наблюдение, анкетирование и интервьюирование, системный и структурный анализ. Научная новизна работы заключается в совершенствовании теоретических положений методологии "скрам", практическая значимость работы выражена в разработке методики оценивания задач для успешного внедрения гибкой методологии скрам в организациях.
1. Введение в проблему
Популярность использования гибких методологий разработки программного обеспечения обусловливается возможностью учета дополнительных требований заказчика, появившихся уже после старта IT-проекта, а также быстротой адаптации к изменениям в проектных решениях.
Под процессом разработки программного обеспечения понимают структуру, которая определяет процедуру разработки программного обеспечения [8]. Выделяют несколько моделей такого процесса (методологий разработки программного обеспечения), каждая из которых описывает свой подход, в виде задач и/или деятельности. Все группы моделей можно условно разделить на две группы [5]:
• каскадная модель разработки или модель водопада — модель процесса разработки программного обеспечения, в которой процесс
разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки; • гибкая методология разработки (Agile) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы.
Несмотря на то, что гибкие методологии разработки достаточно распространены в Российской индустрии разработки программного обеспечения, их внедрение является трудоемким процессом, который неизменно сопровождается рядом проблем.
Результаты исследования «Что представляет собой страна Agile в 2012 году?», проведенного «Agile Survey» [13] (далее исследование Agile) показали (рис. 1) показали, что всего 18% респондентов (из 4 048 специалистов в области разработки программного обеспечения) считают, что у них не было проектов по внедрению agile, которые бы закончились провалом, 12% респондентов считают, что причиной провала таких проектов является философия или культура компании, которая противоречит ценностям agile, 11% респондентов видят основную проблему во внешнем давлении, которое провоцирует следовать традиционной каскадной модели, другие 11% опрошенных винят во всем глубокие организационные проблемы и проблемы с коммуникациями.
<У>о
■ Н ед о с глточ! и я под готовкл
■ Отсутствие шишерянсо crop aw Н"Н*ЯТТГТГ" б^о ^ ■ Ношааюкодендыслсдщ ать тцннцжпи Лф1с
РОтсу tciei ie i I'iiuehtid п[ в культур енцеюМСХЯх коьешние
■ Огсутеши? опьиа работы с гибкими методологиями 19% методологиям I
■ Ор г лншлштокныс гц> обяемы ЕНфоблемы с конмуш кл це еягп i
■ Б екшнее давление, пр ов«д|иующее следов пть ки осадной иодепн
■ Фшссофня нпн культур а игаинпи. гер шево^с'епшж'ценности л uiic 12* 9 ■ Не было пр о«дов. которые бызанончнлнсь прсе wwu
Ее знаю Другое
Рисунок 1. Причины провала проектов по внедрению agile Приведенные статистические данные позволяют сделать вывод о том, что у 82% респондентов возникли трудности с внедрением гибкой методологии разработки программного обеспечения. Актуальным является вопрос, как правильно выбрать разновидность методологии и эффективно ее внедрить в деятельность организации.
2. Методология гибкой разработки программного обеспечения Методология гибкой разработки программного обеспечения детально описана в документе «Манифест гибких методологий разработки» («Agile Manifesto»). Ключевое положение методологии
заключается в разделении всего процесса разработки на отдельные итерации, что позволяет предоставлять заказчику версию работающего программного обеспечения как можно чаще и раньше. Основные тезисы «Манифеста гибких методологий разработки» следующие:
• люди и их взаимодействие важнее процессов и инструментов;
• готовый продукт важнее документации по нему;
• сотрудничество с заказчиком важнее жестких контрактных ограничений;
• реакция на изменения важнее следования плану.
По своей сути, аgile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды. Основные предпосылки к появлению гибких методологий заключались в следующем [11].
1. Заказчик не всегда может сформировать четкие требования к программному обеспечению:
• у заказчика существует только идея приложения, и он не представляет всю его функциональность;
• у группы проекта есть расхождение во взглядах на функциональность приложения;
2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
3. Заказчики и разработчики программного обеспечения не удовлетворены процессом взаимодействия.
Как и любая другая методология Agile обладает своими достоинствами и недостатками. Главный недостаток гибких методологий — это «плавающая» оценка сроков разработки и бюджета, постоянно изменяющихся параллельно корректировке требований. К достоинствам же можно отнести низкие сроки производства продукта, его соответствие ожиданиям клиентов, отсутствие простоев, возникающих в связи с необходимостью согласования проектной документации.
Более 84% участников исследования Agile подтвердили, что у них в организациях применение гибких методологий разработки используется больше на 80%, чем в 2011 году. Половина респондентов работают в компаниях, практикующих работу по гибким методологиям разработки в течение двух лет или меньше, а более чем одна треть опрошенных в диапазоне от 2 до 5 лет. В этом году был отмечен рост количества команд, работающих по принципам agile в рамках каждой организации на 15%.
В теории проектирования и разработки программного обеспечения выделяют следующие разновидности методологий гибкой разработки.
1. Скрам (scrum) — это гибкий подход для управления проектами c высокой степенью неопределенности. В отличие от методологий детально описывающих все процессы управления, скрам по своей
сути является системой взглядов и ценностей, а точнее рабочей средой;
2. Экстремальное программирование (XP) — методология быстрой разработки программного обеспечения. Состоит из набора методик и принципов, позволяющих как по отдельности, так и в комплексе, оптимизировать процесс разработки. Этот подход также регламентирует права разработчиков и заказчиков;
3. Методология «бережливого производства» (Kanban) — методология трансформации организационной культуры и поощрения процесса постоянного улучшения;
4. Функционально-ориентированная разработка (Feature Driven Development (FDD)) — основной целью методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки;
5. Crystal Clear — методология, позволяющая менять степень формализации процесса разработки в зависимости от критичности задач и количества участников разработки [12].
Результаты исследования Agile показали (рис. 2), что наиболее популярной методологией гибкой разработки программного обеспечения является скрам.
Гибрид 21%
FDD
in.
Kanban
1 о
Другие J о% Л
Hi iHiiJO 3%
Скрам 58%
Рисунок 2. Популярность гибких методологий разработки программного
обеспечения
Одним из факторов успешного внедрения скрам является использование системного подхода, который включает в себя правильную мотивацию сотрудников, эффективное распределение ролей в проектной команде, методологию оценки задач, способы визуализации процесса выполнения проекта, разработку регламента проведения встреч команды проекта.
Но одной из ключевых проблем внедрения методологии для реализации 1Т-проектов является переход команды на использование
относительных оценок, так называемых стори пойнтов6, при планировании.
3. Использование относительных оценок для эффективного планирования
Эффективное планирование — залог успешного выполнения любого проекта. Поэтому в методологии скрам этап планирования играет важную роль. На планировании спринта 7 члены команды:
• анализируют пользовательские истории;
• оценивают задачи;
• обозначают критерии приемки.
При оценке задач команда руководствуется их приоритетами в журнале продукта8, при необходимости задачи декомпозируются. Но существуют разные взгляды и методики оценивания задач. В Agile-сообществе есть сторонники использования относительных оценок и сторонники оценивания задач в идеальных часах. Майк Кон
придерживается мнения, что задачи необходимо оценивать в часах. В тоже время, Джеф Сазерленд считает, что эффективнее работают команды, которые оценивают задачи в стори пойнтах.
Исследователи норвежского научно-исследовательского института Simula Research Lab доказали, что большинство людей не умеет давать объективную временную оценку задаче.
Они попросили несколько групп разработчиков дать оценку некоторых задач, описанных в спецификации. В среднем, группы оценили работу в 100 часов.
После чего, начались эксперименты (табл. 1):
Таблица 1 — Коррективы в спецификации
Коррективы в спецификации Средняя оценка
Увеличение количества страниц 150 часов
Внесение дополнительной информации, не имеющей отношения к делу 200 часов
К первоначальной спецификации добавили 2 приложения, которые просили не оценивать 200 часов
Напоследок исследователи решили протестировать эффект «заякоривания» разработчиков (табл. 2). За основу взяли спецификацию, которая была оценена несколькими группами разработчиков в среднем в 500 часов.
6 Стори пойнт^огу point)- это сравнительная оценка, которая показывает «размер» задач относительно друг друга [3].
7 Спринт — одна итерация разработки продукта. По итогам спринта команда проводит демонстрацию реализованных функциональностей.
8 Журнал продукта — это упорядоченный список всего, что может быть нужным в продукте, он является единственным источником требований для любых изменений, которые может потребоваться внести в продукт. Ответственность за него несет владелец продукта[10].
Коррективы в спецификации Средняя оценка
«Заякоревание вверх»( Product Owner говорил, что другие оценили это в 1000 часов ) 600 часов
«Заякоревание вниз»(Product Owner говорил, что другие оценили это в 50 часов) 100 часов
Таким образом, можно сделать вывод, что оценка, которую член команды дает задаче зависит от различных факторов. Но при этом, зачастую, сотрудник, который завершил задачу ранее запланированного времени, откладывает решение других задач, используя оставшееся время в личных целях. Такой ситуации не возникает при использовании относительных оценок, когда члены команды сравнивают размер задач относительно друг друга. И берут на себя обязательство выполнить за спринт определенное количество стори пойнтов, причем команда увеличивает скорость от спринта к спринту, соответственно, количество стори пойнтов растет, а количество часов в спринте остается прежним. Это позволяет добиться наилучших результатов и увеличить скорость выполнения проектов.
Проблема перехода на относительные оценки в том, что сотрудники невольно начинают переводить стори пойнты в часы. Существующая методика оценивания задач Planning Poker предполагает использование при планировании колоды, которая состоит из карт, содержащих числа Фибоначчи, включая ноль: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.
Аргумент в пользу использования последовательности Фибоначчи — отражение типичной неопределённости при обсуждении самых важных и больших пунктов. Одна из имеющихся в продаже видов колод содержит следующую последовательность: 0, %, 1, 2, 3, 5, 8, 13, 20, 40, 100 и иногда знак вопроса «?», означающий неуверенность, и чашку кофе, означающую требование перерыва.
Но когда появляются цифры, люди начинают измерять и перестают сравнивать. Очень часто цифры становятся эквивалентом идеальных часов.
Поэтому появилась альтернатива Planning Poker. Для осуществления относительных оценок задач может использоваться так называемый «фруктовый покер» (Fruit Estimation Poker), размер задачи соответствует определенному фрукту. Но на практике достаточно сложно сказать, что больше вишенка или клубника.
Автором статьи была предложена и внедрена методика оценки задач «Скрам-питомцы» (Planning Poker) с использованием пластиковой колоды карт (рис. 3.). В колоду кроме карты с правилами входят следующие карты:
• хомяк — очень маленький и легкий (1 стори пойнт);
• утка — маленькая, немного тяжелее, чем хомяк (2 стори пойнта);
• панда — средняя тяжесть (3 стори пойнта);
лось — тяжелее среднего (5 стори пойнтов); жираф — достаточно тяжелый (8 стори пойнтов); слон — очень тяжелый (13 стори пойнтов);
кот в мешке — используется, когда член команды затрудняется дать оценку задаче;
засыпающая собака — хватит животных! Пора сделать перерыв.
1
Ой?"9
|SCRUM|
Рисунок 3. «Скрам-питомцы»
Если при планировании задача была, оценена, как слон, на ретроспективе, члены команды решают, действительно ли это был слон? Если да, то пользовательская история берется за основу, и всем аналогичным задачам в последствие присваивается статус «слон». В процессе работы оценки могут пересматриваться, если найдется задача крупнее, текущую задачу можно оценить в меньшее количество стори пойнтов. В итоге команда начинает измерять свою скорость, сколько стори пойнтов было завершено за спринт, а не время, потраченное на одну задачу. Первый спринт, который был оценен с помощью «питомцев», будет основой для последующего планирования. Например, если команда запланировала на спринт 40 стори пойнтов, а выполнила 20, на следующий спринт должно быть запланировано 20 стори пойнтов. На планировании первых двух спринтов можно использовать оценки в часах, за это время у команды появятся задачи, которые можно взять за эталон, и впоследствии использовать для относительных оценок.
Стори пойнты — хорошая альтернатива оценкам в часах. Их использование позволяет повысить скорость работы команды и ее производительность. Методика оценки задач «Скрам-питомцы» (Planning Poker) позволит с наименьшими потерями внедрить систему
относительных оценок в работу команд, работающих по скрам.
Литература
1. Бек К.Экстремальное программирование. [Пер. с англ.] СПб.: Питер, 2002.224 с.
2. Дмитриев С. Люди не умеют оценивать// СMS magazine: аналитический портал рынка веб-разработок, 2011. URL: http://wwwxmsmagazine.ru/authors/sergej_dmitriev/people-are-not-able-to-assess/ (дата обращения: 11.05.2013).
3. Евграшин Т. Как научить команду оценивать в попугаях (story points)// The Improved Methods. Все об Agile управлении IT-проектами, организации команд и саморазвитии: электронный журнал, 2010. № 10.URL: http://timxom.ua/2010/10/how-to-estimate-in-story-points/ (дата обращения: 29.03.2013).
4. Евграшин Т Фруктовый Покер — хорошая альтернатива техникам оценки задач// The Improved Methods. Все об Agile управлении IT-проектами, организации команд и саморазвитии: электронный журнал, 2013. № 01.URL: http://timxom.ua/2013/01/fruit-estimation-poker/ (дата обращения: 29.03.2013).
5. Закис А. RUP и другие методологии разработки ПО. Часть 2. Сравнение методологий разработки ПО //КомпьютерПресс: электронный журнал, 2006. №11.URL: http://wwwxompress.ru/artide.aspx?id=16880&iid=781(дата обращения: 09.05.2013).
6. Книберг Х., Скарин М. Kanban и Scrum: выжимаем максимум. [Пер. с англ.] М.: InfoQ.com, 2010. 78 с.
7. Манифест гибких технологий,2001г. URL: http://agilemanifesto.org/(дата обращения: 20.02.2013).
8. Тельнов Ю.Т Реинжиниринг бизнес-процессов. М. Финансы и статистика, 2005. 99 с.
9. Функционально-ориентированная разработка (Feature Driven Development, FDD). URL:http://proagile.blogspot.ru/2009/08/224-feature-driven-development-fdd.html(дата обращения: 26.06.2013).
10. Швабер К., Сазерленд Дж. Авторитетное руководство по Скраму: Правила Игры. [Пер. с англ.] М.: InfoQ.com, 2011. 19 с.
11. Agile-подход в разработке программного обеспечения: преимущества для Заказчика, 2012г. URL: http://www.pmoffice.by/Ыog/study/agile-approach.html(дата обращения: 20.04.2013).
12. Cockburn, A., Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley, 2005. 336 р.
13. 7th annual State of agile development survey, 2013. URL: http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf (дата обращения: 21.05.2013).
