Galvojums




НазваниеGalvojums
страница14/14
Дата публикации12.07.2013
Размер0.64 Mb.
ТипРеферат
exam-ans.ru > Информатика > Реферат
1   ...   6   7   8   9   10   11   12   13   14
^

Сравнение показателей, не относящихся к Scrum


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

        Отношение сделанных заданий относительно запланированных


На рис. 21 отображён график, показывающий отношение сделанных заданий к планируемым.



Рис. 21. Отношение сделанных заданий к планируемым

Данный график похож на предыдущий, но позволяет с большей лёгкостью прогнозировать, какой процент заданий из запланированных будет сделан. Так как разные разработчики работают над разными системами, то уменьшение заданий на Спринт может оставить кого-либо из них без задания и не всегда один разработчик способен помочь другому опять по причине разных систем, с которыми они работают.
      1. ^

        Количество дефектов за час разработки


В связи с тем, что приложения имеют очень много дефектов, было решено собирать статистику по количеству дефектов, найденных на этапе тестирования. Так как имеется статистика по затраченному на разработку времени, то было решено построить график, который отображает, как часто в коде появляются ошибки. График для системы A изображён на рис. 22.



Рис. 22. Показатель дефективности для системы A

Исходя из данного графика видно, что до начала использования Scrum методологии в коде было большое количество ошибок, почти одна ошибка за два часа разработки. Это очень высокий показатель, который не устраивал никого. После того, как команда смогла фокусироваться на конкретных заданиях и её практически перестали отрывать от работы, показатели существенно улучшились и в среднем за день разработки разработчик совершал лишь одну ошибку, которая находилась тестерами, а не самим разработчиком.

На рис. 23 изображён график для системы B.



Рис. 23. Показатель дефективности для системы B

Из графика видно, что для системы B проблем с дефектами не было, а некоторое возрастание обнаруженных ошибок – следствие серьёзной переработки внутренней логики системы.

На рис. 24 изображён график для системы C.



Рис. 24. Показатель дефективности для системы C

Система C, как и система B не имела серьёзных проблем с количеством дефектов, в отличие от системы A. Однако, после внедрения Scrum методологии, отношение дефектов к потраченным часам разработки всё равно улучшилось, опять-таки из-за возможности лучше фокусироваться на определённом задании. К тому же представители бизнеса чётко знали, что делают разработчики и заранее имели ответы на вопросы.

На рис. 25 изображён график для системы D.



Рис. 25. Показатель дефективности для системы D

К сожалению, на систему D изменения положительно не повлияли, хотя и негативными их назвать нельзя. Отношение дефектов к затраченным часам разработки на достаточно низком уровне было и осталось, хотя некоторое повышение дефективности настораживает. Однако, повышение количества дефектов в последних двух релизах – следствие изменений внутренней логики системы, так как необходимо существенно повысить её производительность, а это приводит к ошибкам, предвидеть которые разработчикам достаточно сложно.

На рис. 26 изображён график для системы E.



Рис. 26. Показатель дефективности для системы E

Система E является не приоритетной системой и содержит большое количество небольших полезных сервисов, помогающих службе поддержки. Разработчиков данной системы постоянно просили доделать что-либо, изменить или просто помочь разобраться, что крайне негативно сказывается на возможности разработчика вникнуть в проблему и разработать что-либо. Из-за этого до внедрения Scrum было очень много дефектов. После внедрения новой методологии, службе поддержки было запрещено отвлекать разработчиков, а все вопросы пошли через лидера команды разработки, который в прошлом занимался этой системой и на большинство вопросов мог сам ответить, а на запросы по каким-либо изменениям требовал соблюдать официальную процедуру с созданием запроса на изменение в системе. Таким образом система E встала на один уровень с другими системами по дефективности.
      1. ^

        Качество оценки планирования


На уровне организации необходимо измерять качество оценки планирования разработки. Другими словами, на стадии анализа разработчик должен оценить, как много времени потребуется на выполнение задания. Исходя из этой оценки планируется спринт. Также на основе таких оценок строится график точности оценивания. Границы, в которые должна попадать оценка между 70 и 130 процентами. То есть, при планировании работы на 10 часов, разработчик обязан выполнить её за время от семи часов до триннадцати. Если разработка займёт меньше, либо больше времени, то считается, что оценка было сделана не верно.

На рис. 27 изображён график оценок для системы A.



Рис. 27. Оценка планирования системы А

Из графика хорошо видно, что в момент перехода на Scrum, команда оценивала работу недостаточно хорошо и еле попадала в рубеж 70%. После перехода на новую методологию, качество оценки немного улучшилось, однако недостаточно. Увы, из-за сложности системы, даже оценка с запасом не позволяет добиться хорошей точности. Также на графике видно, что один раз оценка оказалась ниже 60%. Такой низкий показатель обусловлен проектом по обновлению системы интеграции, чего команда никогда ещё не делала. Проект очень сильно затянулся и все оценки оказались неточными.

На рис. 28 изображён график оценок для системы B.



Рис. 28. Оценка планирования системы B

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

На рис. 29 изображён график оценок для системы С.



Рис. 29. Оценка планирования системы C

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

На рис. 30 изображён график оценок для системы D.



Рис. 30. Оценка планирования системы D

Система D, как и все выше перечисленные системы, недооценивается разработчиками, в результате чего на разработку требуется больше времени, нежели планировалось. Хотя попадание в 70% рубеж выполняется всегда, недооценивание грозит не выполнением всех заданий спринта.

На рис. 31 изображён график оценок для системы Е.



Рис. 31. Оценка планирования системы Е

Система Е, как упоминалось выше, не является приоритетной, в связи с чем ей уделяется меньше внимания.
  1. Рекомендации


На основе полученного опыта и теоритической базы, в данной главе представлены рекомендации по использованию Agile методологий в случае поддержки существующего ПО.

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

      Использование Scrum


Scrum улучшил наглядность процесса благодаря ежедневным планёркам до 15 минут и Scrum-доской. Также еженедельное планирование заданий позволило заказчикам и разработчикам знать, какие задания должны быть выполнены в течении недели. Измерение производительности команды сделало планирование заданий на неделю достаточно точным, а также возможным оценивать команду и предоставлять отчёты руководству.

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

      Использование Kanban


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

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


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

Таблица 4

Результат ключевых метрик




До Scrum

Scrum

Kanban

Время жизни задания от создания до завершения

514,5

480

481

Процентное соотношение дефектов к затраченному времени

0,09

0,081

0,079

Оценка качества анализа

+-35%

+-27%

+-26%


На основе данных метрик можно сделать вывод, что Scrum и Kanban методологии существенно улучшили процесс разработки ПО.

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

После внедрения Agile методологий стало возможным следующее:

  • Отображение текущей работы. Теперь каждый желающий может посетить виртуальную доску и посмотреть, в каком статусе находится то или иное задание, кто работает над ним, сколько ориентировочно часов осталось до завершения.

  • Измерение производительности команды. В Scrum предписывается burndown chart, в Kanban – кумулятивная диаграмма потока.

  • Выявление лентяев. Так как ежедневно проводятся планёрки, во время которых каждый член команды рассказывает, что делал и что будет делать, то становится невозможным увиливать от работы продолжительное время.

Для поддержки существующих продуктов с большим количеством внеплановых заданий рекомендуется использовать Kanban, в противном случае Scrum является более предпочитаемой методологией.
  1. ^

    Список используемой литературы


  1. Henrik Kniberg. Scrum and XP from the Trenches. – C4Media Inc., 2007. – 142 с.

  2. Ken Schwaber, Jeff Sutherland. Scrum Guide 2010. – Scrum.org., 2010. – 121 с.

  3. Henrik Kniberg, Mattias Skarin. Kanban and Scrum - making most of both. – C4Media Inc., 2009. – 122 с.

  4. Орлов С. А. Технологии разработки программного обеспечения: Учебник для вузов. Санкт-Петербург: Питер, 2002. – 464 с.

  5. Martin Fowler. Новые методологии программирования. – SD Magazine, 2000. – 42 c.

  6. Scrum for Anyone. - http://www.scrumalliance.org/resources/1566 (2012.01.20)

  7. Jesper Boeg. Priming Kanban – C4Media Inc., 2011. – 42 с.

  8. Henrik Kniberg. Lean from the Trenches. – Free Press., 2011. – 72 c.

1   ...   6   7   8   9   10   11   12   13   14

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2015
контакты
exam-ans.ru
<..на главную