1. Введение 2
Глава 1. Методология Scrum
2.1. Базовые принципы гибкой методологии Scrum 4
2.2. Роли в гибкой методологии Scrum 5
2.3. Ритуалы 6
3. Глава 2. Гибкие методы оценки сложности задач
3.1. Обзор гибких методов оценки сложности задач 9
3.2. Достоинства и недостатки гибких методов оценки сложности
задач 10
3.3. Критерии для новой системы оценки сложности задач 12
3.4. Формула для оценки сложности задач 15
3.5. Свойства формулы оценки сложности задач 18
3.6. Применение оценки сложности задач
3.6.1. Подготовка 20
3.6.2. Процедура проведения 21
4. Глава 3. Внедрение новой системы оценки сложности задач 22
5. Заключение 41
6. Список Литературы 43
7. Приложение
В наше время, рынок информационных технологий является одним из самых динамично развивающихся рынков России. Показатели его активности стремительно движутся вверх, но, несмотря на позитивные прогнозы специалистов данной области, далеко не каждый проект может попасть в статистику успешных.
По результатам исследования, проведенного студенткой ИТИС[1], около 60% всех проектов завершаются неудачей. В ходе проведенного анализа было выявлено, что одной из главных причин такой не успешности является недостаточная оценка сложности задач проекта, что являет собой одну из важнейших сторон в гибкой методологии оценки.
Данный аспект есть один из базовых принципов по ведению проекта, так как именно от него зависят сроки выпуска конечного продукта. Оценка оказывает существенное влияние на стоимость и рентабельность проекта.
В целом, проблемы оценки сложности задач можно описать следующим образом[2]:
• неудачное прогнозирование оценки: слишком оптимистичная или слишком пессимистичная;
• неверный учет рисков при планировании задач;
• влияние незапланированных обстоятельств на выполнение задач, таких как: совещание, болезнь разработчика и прочее.
Решением данных проблем может стать создание нового метода оценки сложности задач.
Основной целью данной работы и проведенного исследования, является:
1. Выделение основных факторов-критериев при оценке сложности задач путем исследования, анализа и проведения анкетирования для проектных менеджеров и разработчиков;
2. На основе анализа уже существующих систем оценки в методологии
Scrum выявление плюсов и минусов каждого метода, и создание новой системы оценки с сохранением каноничности вышеуказанной методологии;
3. Нахождение нового метода оценки и выведение формулы для определения количественной оценки сложности задачи;
4. Внедрение новой системы оценки сложности задач в команды;
5. Анализ системы, на основе предоставленных данных участниками
каждой из команд.
При проведении исследования, анкетирования среди разработчиков и проектных менеджеров, выяснилось какие критерии лучше брать за основу при оценке сложности задачи. Таким образом, на данный момент есть 4 критерия: тип программы, риски, тестирование и объем. Благодаря оценке сложности задач, путём разбиения на аспекты, можно понять: стоит ли браться за написание кода сразу, или сначала уделить внимание поиску алгоритма для ее решения. В том случае, если у критерия большой балл при оценке, можно предположить, что у задачи есть “подводные камни”, на которые стоит обратить внимание и уделить им больше времени. В то же время, маленький балл дает возможность решить задачу быстро. Такая метрика позволит разработчикам вдумчиво подходить к решению задач, и не браться за нее без должного анализа.
В данном подходе, при определении итоговой оценки сложности задачи, акцент делается на том, что любая задача, даже самая легкая, подвергается анализу. Этим способом может воспользоваться каждый, не имеющий профессиональных навыков проектного менеджмента, потому что методология Scrum, нацелена на то, что оценку сложности задач проводят сами разработчики, не имея опыта в тайм-менеджменте.
В рамках диплома была проведена следующая работа:
1. Выделены основные факторы-критерии при оценке сложности задачи путем исследования, а также проведения анкетирования для проектных менеджеров и разработчиков;
2. На основе анализа уже существующих систем оценки сложности задачи в методологии Scrum, выявлены плюсы и минусы каждого метода для создания новой системы оценки;
3. Найден новый метод оценки и выведена формула для нахождения количественной оценки сложности задачи;
4. Была внедрена новая система оценки сложности задач в команды уже существующих проектов;
5. Проведен анализ системы на основе предоставленных данных участниками каждой из команд.
Результатом данной работы явилась новая система оценки сложности задач по типу метода покер планирования, но улучшенная до того вида, когда любая задача разбивается на критерии, каждый из которых оценивается,и в дальнейшем складывается. В конечном итоге мы получаем количественную оценку всей задачи без вероятности потерь, какого либо аспекта (например: рисков). Опираясь на данные команд, было выявлено преимущество метода, выраженное в сокращении времени проведения встреч для оценки сложности задач. Теперь любая команда за меньшее количество времени может качественнее оценивать задачу.
1. Г ерасимова Е, Признаки успеха и провала IT-проекта /2017.
2. Макконел С, Сколько стоит программный проект /2006.- 352 с.
URL: http://forcoder.ru/developing/skolko-stoit-programmnyj-proekt-712
3. Ken Schwaber, Jeff Sutherland, The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game /2013. -16 с.
URL: http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
4. Jeff Sutherland, Nafis Ahmad, How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum./ 2006. - 7 c.
URL: https: //34slpa7 u66f15 9hfp 1 fhl9aur1 -wpengine. netdna-ssl .com/wp-
content/uploads/2014/05/PMBOK-vs.-Scmm-Agile2011.pdf
5. Cohn M, Agile estimating and plaanning / Pearson Education, 2005
6. Манифест гибкой разработки ПО
URL: http: //agilemanifesto .org/iso/ru/principles.html
7. Покер планирование
URL: https: //ru.wikipedia.org/wiki/Покер_планирования
8. Dr. Barry Boehm, COCOMO II Model Definition Manual / 1981. -72 c. URL: http://www.dmi.usherb.ca/~frappier/IFT721/COCOMOII.PDF
9. Трусь А.А. Психология управления: Учебное пособие для студентов учреждений высшего образования по управленческим и психологическим специальностям / 2014. - 317 с.
10. Основа технического лидерства URL:https://pawelsamusev.com/post/osnova-tehnicheskogo-liderstva
11. ИдиятуллинаА, Повышение эффективности разработчиков /2017.