Разработка прикладных программных продуктов с использованием методологии SCRUM

Введение
1. Описание предметной области
1.1 Методологии разработки программных продуктов и их роль
1.2 Обзор популярных методологий разработки программных продуктов
1.3 Обоснование выбора методологии разработки программных продуктов
2. Проектный раздел
2.1 Описание деятельности предприятия
2.2 Рассмотрение процесса разработки программного продукта
2.3 Рассмотрение возможности применения методологии SCRUM
2.4 Инструментальные средства на основе методологии SCRUM
3. Экономическое обоснование внедрения методологии
3.1 Расчет стоимость проекта внедрения
3.2 Расчет затрат на основную заработную плату специалистам
3.3 Расчет отчислений на социальное страхование и обеспечение
3.4 Расчет стоимости дополнительных расходов
3.5 Расчет затрат на амортизацию ПК
3.6 Расчет затрат на электроэнергию, используемую ПК в процессе разработки
3.7 Обоснование экономической эффективности
Заключение
Список литературы

Команда разбивает описания функциональности пользователей на отдельные задачи, которые позволяют полнее понять эти описания и принять обоснованные обязательства относительно их реализации в спринте.Рис. 2.7 - Описание функциональности пользователяКоманды, обладающие большим опытом в реализации процессов Scrum, смогут определить обязательства без разбиения описаний функциональности на задачи.Оценка задачПосле определения задач команда оценивает продолжительность выполнения каждой задачи (в часах).Для оценки задач команды часто используют метод планирования с использованием покера.Этот метод позволяет удержать команды от попыток сделать более точную оценку, чем это требуется.Принятие обязательств по реализации описаний функциональности пользователейЧтобы убедиться в наличии достаточного количества рабочих часов для выполнения всех задач, команда использует книгу «Невыполненная работа по итерации».Если для спринта запланировано больше работ, чем может выполнить команда, необходимо удалить часть описаний функциональности пользователей с наименьшим приоритетом, чтобы запланированные работы соответствовали производительности команды, определенной для спринта.Более мелкие описания функциональности с низким приоритетом могут быть заменены на более крупные описания функциональности, которые невозможно реализовать в течение одного спринта.Рис. 2.8 - Книга «Невыполненная работа по итерации»Команда принимает обязательства реализовать те описания функциональности пользователей, которые она считает возможным выполнить.При принятии этих обязательств команда предполагает, что владелец продукта не будет пытаться включить в спринт дополнительную работу или изменить приоритеты реализуемых описаний функциональности пользователей.Выполнение спринтаВ ходе спринта команда выполняет задачи, необходимые для реализации описаний функциональности пользователей из списка невыполненных работ спринта.До завершения каждого спринта команда может отслеживать ход его выполнения и проверять соответствие готового программного обеспечения условиям приемки заказчиков и критериям, установленным в команде.Завершение описаний функциональности пользователейЗавершив планирование спринта, команда формирует список описаний функциональности пользователей, которые она обязуется реализовать в течение спринта.Эти описания функциональности разбиваются на задачи.В момент начала спринта каждый участник команды выбирает себе одну из задач.После завершения этой задачи участник команды обновляет ее состояние и выбирает следующую задачу.Таким образом, команда обрабатывает все задачи, необходимые для реализации описаний функциональности пользователей из списка невыполненных работ спринта.Член группы может указать выполненные задачи при возврате кода.Методология Scrum в первую очередь основана на взаимодействии людей, а не на формальных процессах. Благодаря этому достигается ясное понимание всех зависимостей и обеспечивается обмен полученными знаниями и опытом и эффективное внедрение изменений планов.Команда должна ежедневно проводить короткое Scrum-собрание, на котором каждый участник команды сообщает о работе, выполненной за предыдущий день и запланированной на текущий день. Кроме того, он докладывает обо всех проблемах или препятствиях, которые могут отрицательно сказаться на ходе работы или требуют помощи со стороны других участников команды.В своей книге «ExtremeProgrammingExplained» Кент Бек (KentBeck) рассказывает о том, почему гораздо эффективнее исправлять ошибки на ранних этапах работы.Учитывая этот факт, команда должна понимать приоритеты заказчика.Возможно, заказчик больше ценит качество продукта, чем поддержку большего количества функций.Владелец продукта обязан знать такого рода информацию, поскольку заказчики контролируют рабочий процесс команды.Программное обеспечение, создаваемое командой Scrum, не должно содержать ошибок.Однако команды, скорее всего, будут находить ошибки в своих проектах.Обрабатывая ошибки, команда должна понимать, что быстрее и дешевле сразу исправлять найденные ошибки, чем откладывать их исправление на более поздние сроки.При обнаружении ошибок команде следует исправлять их немедленно.Если команда не может устранить ошибку в тот же день, когда она была найдена, участник команды должен создать рабочий элемент ошибки в VisualStudio ALM и исправить ее до окончания спринта.Отслеживание хода выполнения спринтаКоманда может отслеживать ход выполнения спринта для проверки того, что работа выполняется должным образом и соответствует условиям приемки.Для отслеживания хода выполнения работ в течение спринта команды чаще всего используют отчет «Выработка».Рис. 2.9 - Отчет «Выработка»Платформа MSF для гибкой разработки программного обеспечения версии 5.0 предоставляет набор отчетов, которые могут использоваться командами для отслеживания хода выполнения спринта:Отчет «Выработка и темп работ» (гибкая разработка)Отчет «Индикаторы качества построения»Отчет «Ход выполнения плана тестирования»Отчет «Ход выполнения описаний функциональности» (гибкая разработка)Команды часто обнаруживают, что для выполнения задачи им требуется больше или меньше времени, чем они оценивали во время собрания по планированию выпуска.Этот тип отклонения является типичным.Можно записать эти сведения, указав фактическое время, затраченное командой на выполнение задачи.В ходе выполнения спринта команда может обнаружить незапланированную работу, необходимую для реализации описания функциональности пользователя.В этом случае команда должна создать задачу, оценить ее и определить, может ли она выполнить эту задачу за время, оставшееся в спринте.Если задачу можно выполнить, команде следует продолжить спринт.Если завершить задачу в рамках спринта невозможно, необходимо обсудить дальнейшее продолжение работы с владельцем продукта.Владелец продукта и команда могут разрешить проблему, внеся следующие изменения.Снижение условий приемки для пользовательского описания функциональности, что сделает данную задачу необязательной.Удаление пользовательского описания функциональности из списка невыполненных работ спринта.Отмена спринта.Завершение спринтаПо мере приближения завершения спринта необходимо убедиться в том, что все описания функциональности пользователей или требования полностью выполняются командой.Например, необходимо проверить, что приемочные тесты проходят успешно, и каждое описание функциональности пользователей отвечает установленным командой критериям.Отчет «Состояние ошибки»Отчет «Тенденции ошибок»В последний день спринта команда продемонстрирует реализованные описания функциональности пользователей владельцу продукта и, возможно, заказчикам.Владелец продукта и заказчики принимают решение о приемке по каждому описанию функциональности пользователя.После проверки заказчиков команда проведет ретроспективное собрание.Отслеживание проектаПо мере того как команда работает в спринтах для повышения готовности проекта, заказчики получают более полное представление об оставшихся потребностях и изменениях бизнес-среды, которые следует принять во внимание.Владелец продукт работает с заказчиками для анализа этих изменений.Владелец продукта ведет список невыполненных работ по продукту и обновляет план выпуска для документирования этих изменений и обеспечения команды всем необходимым для начала каждого спринта.Команда отслеживает ход разработки продукта в целом, чтобы убедиться в планомерном выполнении всех работ по проекту.Подготовка к следующему спринтуОбщее качество проекта и полнота его выполнения напрямую зависит от актуальности списка невыполненных работ по продукту.Список невыполненных работ должен регулярно обновляться, изменяться и пересматриваться для его подготовки к началу каждого спринта.При подготовке списка невыполненных работ по продукту для следующего спринта владелец продукта выполняет следующие действия.Обновляет пользовательские описания функциональности и их приоритеты в соответствии с изменениями потребностей заказчиков.Разбивает пользовательские описания функциональности, которые, возможно, будут реализованы в следующем спринте.Рис. 2.10 – Подготовка с следующему спринтуПосле завершения спринта в начале списка невыполненных работ по продукту оказываются другие описания функциональности пользователей.Владелец продукта должен проанализировать и разбить описания функциональности, находящиеся в начале списка, чтобы команда могла реализовать их в следующем спринте.Майк Кон часто называет этот процесс «айсбергом невыполненных работ по продукту».По мере того как команда работает над набором функций, айсберг тает; новые рабочие поверхности и сам айсберг становятся меньше.В этом процессе возникают дополнительные подробности — вовремя и в достаточном количестве.Владелец продукта должен понимать, что после начала работы над спринтом внимание команды к ведению учета невыполненных работ по продукту существенно снизится по сравнению с подготовкой первого спринта.Чтобы помочь владельцу продукта подготовить список невыполненных работ по продукту с минимальными помехами для работы в спринте, команда и владелец продукта проведут собрание для обсуждения невыполненных работ в течение спринта.Отслеживание хода подготовки к выпускуПо мере перехода проекта от спринта к спринту, команда отслеживает общий ход подготовки к следующему выпуску.Команда также отслеживает ход выполнения для оценки и повышения своей производительности.Отслеживая ход работ, команда должна ответить на следующие вопросы.Выполняется ли работа над наиболее оптимальными описаниями функциональности пользователей?В ходе реализации проекта в список невыполненных работ по продукту будут добавляться новые описания функциональности пользователей.Однако, если, несмотря на реализацию описаний функциональности пользователей в каждом спринте, общее число описаний в списке невыполненных работ не уменьшается, команда должна исследовать причины этого.Возможно, для реализации выбраны не самые лучшие описания функциональности.Команда должна определить концепцию и цель для каждого выпуска и обеспечить непосредственную связь описаний функциональности с требованиями заказчиков.Накапливаются ли технические задолженности?Некоторые команды считают описание функциональности пользователя завершенным, даже если часть работ, например исправление ошибок, остается невыполненной.Этим команды создают техническую задолженность, которую приходится оплачивать позднее, часто по более высокой цене.Рис. 2.11 - Отчет «Состояние всех итераций»VisualStudio ALM предоставляет несколько отчетов, которые помогут командам отслеживать ход выполнения в течение нескольких спринтов:Отчет «Состояние всех итераций» (гибкая разработка)Отчет «Обзор описаний функциональности» (гибкая разработка)Отчет «Ход выполнения описаний функциональности» (гибкая разработка)Можно создавать настраиваемые отчеты и запросы рабочих элементов для отслеживания хода выполнения работ.Дополнительные сведения см. в разделах Создание и настройка отчетов для VisualStudio ALM, а также управление ими и Поиск ошибок, задач и прочих рабочих элементов.Завершение выпускаЕсли команда не накапливает техническую задолженность, она может выпустить продукт после завершения спринтов данного выпуска, не выполняя дополнительной работы.Команда и владелец продукта предоставляют заказчику продукт на проверку и проводят ретроспективное собрание для изучения выпуска в целом.Однако технические задолженности создают сложные проблемы, которые не просто устранить командам.Если команда, как многие другие команды, по-прежнему накапливает техническую задолженность, перед выпуском продукта придется потратить время на дополнительную работу по завершению описаний функциональности пользователей.На ретроспективном собрании, посвященном выпуску, команда должна рассмотреть меры, которые необходимо предпринять в последующих спринтах, чтобы избежать накопления задолженности.3. Экономическое обоснование внедрения методологии3.1 Расчет стоимость проекта внедренияРасчет затрат на внедрение методологии SCRUM необходим для обоснования экономической эффективности системы. Плановые затраты на внедрение включают все расходы, связанные с ее выполнением, независимо от источника их финансирования. Определение затрат на внедрение производится путем составления калькуляции плановой себестоимости. Она является основным документом, на основании которого осуществляется планирование и учет затрат на выполнение.Смета затрат включает следующие статьи:основная заработная плата специалистов в области методологии SCRUM;отчисления на социальное страхование и обеспечение;расчет затрат на амортизацию используемого оборудования;расходы на электроэнергию, используемую при внедрении методологии SCRUM;накладные расходы. 3.2 Расчет затрат на основную заработную плату специалистамОплата труда представляет совокупность средств, выплаченных работникам в денежной и натуральной форме как за отработанное время, выполненную работу.Начисление основной заработной платы производится в зависимости от принятых на предприятии форм оплаты труда. При повременной оплате труда основная заработная плата начисляется работникам за фактически отработанное время, а при сдельной за фактически выполненную работу.Повременная форма оплаты труда находит применение при расчете заработной платы рабочих, служащих, специалистов и руководителей. При этой форме оплаты труда заработная плата рассчитывается исходя из месячного должностного оклада за проработанное время. Затраты на основную заработную плату (Зосн.) при повременной форме оплаты труда рассчитываются по формуле[16]:Зосн.=Омес.*Траб.*Кд/Др.мес., гдеОмес. - месячный оклад специалиста;Др.мес. - среднее количество рабочих дней в месяце;Траб. - фактическое время участия вовнедрении методологии;Кд - коэффициент, учитывающий доплаты к основной зарплате.При этом отношение Омес./Др.мес. характеризует среднюю дневную зарплату специалиста.В данном дипломном проекте:Омес. руководителя = 53 000 руб.Омес. консультанта SCRUM = 32 000 руб. Др.мес. = 21 день;Кд=1.Результаты расчета затрат на основную заработную плату специалистов представлены в таблице 3.1.Таблица 3.1Затраты на основную заработную платуИсполнителиВремя работы, кол.днейОкладСредняя дневная зарплата Омес./Др.мес, руб.Затраты на зарплату,руб.Руководитель2853 000214259976Консультант SCRUM14032 0001285176120Итого2360963.3 Расчет отчислений на социальное страхование и обеспечениеОтчисления в фонд социального страхования и обеспечения включают в себя (30% от суммы основной и дополнительной заработной платы):ФССиО=236096*30% = 70829 руб.3.4 Расчет стоимости дополнительных расходовСтоимость дополнительных расходов приведена в таблице 3.2.Таблица 3.2Стоимость дополнительных расходовИзделиеКоличество, шт.Цена за единицу, руб.Сумма, руб.Картридж для принтера112001200Бумага для принтераУпаковка(500 л.)150150Подключение к сети Интернет450450Итого1720Транспортно-заготовительные расходы, 7%120ИТОГО:18403.5 Расчет затрат на амортизацию ПКНорма амортизации:На = 1/ТслгдеНа – норма амортизации в %Тсл – срок полезного использования (3-5 лет).Расчет затрат на амортизацию оборудования производится следующим образом:Зам.=Сперв.*(На/100) * т * (фаб/Фд.о.),гдеСперв.- первоначальная стоимость используемой ЭВМ;На - норма амортизационных отчислений (20%), т - количество используемых ЭВМ; т = 1 шт.,фаб. - время работы ЭВМ;Фд.о. - действительный годовой фонд времени работы ЭВМ.В данной дипломной работе:Сперв. =30000 руб.,фаб. = 1120 час,Фд.о. == Кол.раб.дн. * Кол.смен * Продолж.смены = 252*1*8=2016 ч.На основе формулы определяем:Зам.= 30000*0.2*1*0.5=3000 руб.Результаты расчета затрат на амортизациюиспользуемогооборудования представлены в таблице 3.3Таблица 3.3Затраты на амортизациюНаименование оборудованияКоличество единиц оборудования, шт.Время работы оборудования,чНорма амортизационных отчислений %Затраты на амортизацию, руб.ПК111202030003.6 Расчет затрат на электроэнергиюЗатраты на электроэнергию (Зэл.эн.) рассчитываются по формуле:Зэл.эн.=Цэ. * Р * т * ф = 2,55*0,4*1* 1120=1142,4гдеР - мощность используемой ЭВМ;ф - время работы используемоqЭВМ;т - количество используемых ЭВМ;Цэ. - цена 1 кВт* ч электроэнергии. Результаты расчета затрат на электроэнергию представлены в таблице 3.4.Таблица 3.4Результаты расчета затрат на электроэнергиюНаименование оборудованияКоличествоЧасыработыПотребляемаямощность, кВтТариф за1 кВт-час,руб.Стоимость электроэнергии, руб.ПК111200,42,551142Результаты расчета затрат на внедрение методологии SCRUM сведем в таблицу 3.5.Таблица 3.5Смета затрат на внедрение методологии SCRUM№п/пСтатьи затратЗатраты, руб.Порядок расчёта затрат1Основная заработная плата специалистов236096рассчитываются по табл.5.22Отчисления в фонд социального страхования и обеспечения70829принимается в размере 30% от заработной платы3Расходы на покупные изделия1840рассчитываются по табл.5.34Амортизационные отчисления3000рассчитываются по табл.5.45Расходы на электроэнергию1035рассчитываются по табл.5.56Прочие расходы 59024принимается в размере 20-25% от заработной платы7Итого3718243.7 Обоснование экономической эффективностиЭкономический эффект от внедрения методологии SCRUMзаключается в уменьшении состава группы разработчиков проекта, а также сроков его реализации.Втаблице 3.6 представлено сравнение показателей до и после внедрения методологии SCRUMв компании Soft.su.Таблица 3.6Сравнение показателей до и после внедрения методологии SCRUMПоказательДо внедренияПосле внедренияСредний размер группы разработчиков, чел.106Средняя продолжительность проекта, дн.170110Риск срыва сроков проекта, %103Риск нереализации проекта и отказа клиента, %41Выводы: Как видно из сравнительной таблицы внедрением методологии SCRUMприведет к значительному сокращению сроков реализации проектов, к сокращению рабочих групп и минимизации рисков реализации проектов.Данный факт обуславливает целесообразность внедрения методологии SCRUM.ЗаключениеЦелью данного проекта является повышение эффективности процесса разработки программного обеспечения компанииSoft.suпутем внедрения в процесс разработки методологии SCRUM.В первой главе работы рассмотрена роль методологий разработки программных продуктов.Рассмотрены популярные методологии разработки программных продуктов:SCRUM;RUP;MSF;KANBAN;FDD;Crystal;DSDM;XP.Дано обоснование выбора методологии SCRUM.Во второй главе рассмотрена деятельность компании Soft.su – разработчика программного обеспечения. Компания занимается краткосрочными и среднесрочными проектами. В компании не использовались какие-либо методологии разработки программного обеспечения, что в свою очередь приводило к затягиванию сроков реализации проектов и отказам клиентов.Рассмотрена общая схема разработки программного обеспечения.Рассмотрены основные элементы методологии SCRUM: роли, артефакты и т.д.В третьей главе осуществлен расчет стоимости внедрения методологии SCRUMв работу компании Soft.su. Осуществлен расчет показателей экономической эффективности проекта.Затраты на внедрение методологии окупятся меньше, чем за год. При этом основной эффект получится за счет снижения трудозатрат на реализацию проекта и соответственно сокращению сроков его реализации.Таким образом, цель работы можно считать достигнутой, а задачи решенными.Список литературыПерКролл, ФилиппКрачтен. «RUP Made it easy». Addison-Wesley, 2003. А. Закис. RUP - знакомый незнакомец. Открытые системы, #06/2004. http://www.osp.ru/os/2004/06/038.htmW. Royce, «Managing the Development of Large Software Systems», Proc. Westcon, IEEE CS Press, 1970 КентБек. Экстремальное программирование. СПб., Питер, 2002.  АлистерКоберн. Быстрая разработка программного обеспечения. М., Лори, 2009Ситивен Р. Пальмер, Джон Ф. Фелсинг. Практическое руководство по функционально-ориентированной разработке ПО. М., «Вильямс»Walker Royce. CMM vs. CMMI: From Conventional to Modern Software Management http://www.therationaledge.com/content/feb_02/f_conventionalToModern_wr.jsp  Галахов И.В., Лапыгин Д.В., Новичков А.Н., Подоляк О.Р., Позин Б.А. Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational. http://www.citforum.ru/programming/case/gost_34_19Брауде, Э. Технология разработки программного обеспечения / Э. Брауде. - СПб,: Питер, 2004. - 655 с.Информационные системы: учеб пособие / под ред.В.Н. Волковой, Б.И. Кузина. - 2-е изд., перераб и доп. - СПб.: Изд-во СПбГПУ, 2004. - 224 с.Краткий философский словарь / под ред.А.П. Алексеева. - 2-е изд., перераб. и доп. - М.: ТК Велби, Изд-во Проспект, 2006. - 496 с.Непейвода, Н.Н. Основания программирования / Н.Н. Непейвода, И.Н. Скопин. - М. - Ижевск: Ин-т компьютерных исследований, 2003. - 868 с.Новый иллюстративный энциклопедический словарь / под. Ред.В.И. Бородулина, А.П. Горкина, А.А. Гусева, Н.М. Ланда и др. - М.: Большая Российская энциклопедия, 2003. - 912 с.Одинцов, И.О. Профессиональное программирование. Системный подход / И.О. Одинцов. - 2-е изд., перераб. и доп. - СПб.: БХВ-Петербург, 2004. - 624 с.Орлов, С.А. Технологии разработки программного обеспечения: учеб. пособие / С.А. Орлов. - 2-е изд. - СПб.: Питер, 2003. - 480 с.Петров, В.Н. Информационные системы: учеб.пособие / В.Н. Петров. - СПб.: Питер, 2002. - 588 с.