Galvojums




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

ПРОБЛЕМА КАЧЕСТВА ПРОЦЕССА РАЗРАБОТКИ ПО


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

      Проблема использования сторонней организации для разработки ПО


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

  • Местоположение – поддержка и администрация в Риге, а разработчики – в Стокгольме. Это сильно усложнило общение, что приводило к непониманию разработчиков, что от них требовалось.

  • Стоимость – стоимость одного часа консультанта сторонней организации гораздо выше, чем стоимость внутреннего сотрудника компании. Рижские же сотрудники обходятся компании ещё дешевле из-за разной экономической развитости Швеции и Латвии.

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

      Проблема использования сотрудников компании для разработки ПО


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

  • Разработчиками были назначены лучшие специалисты по поддержке. Некоторые из них имели опыт в разработке ПО, некоторые – нет. Следовательно, как следует разрабатывать сложные корпоративные системы сотрудники представляли достаточно смутно.

  • Не использовалась какая-либо из общепринятых методологий разработки ПО. После формирования группы разработчиков, процесс разработки был начат на основе того, что администрация считала важным в какой-либо момент времени.
    1. ^

      Решение описанных проблем


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

Решение второй проблемы будет описано в данной работе.
  1. ^

    СРАВНЕНИЕ МЕТОДОЛОГИЙ


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


Scrum - методология управления разработкой информационных систем для Agile разработки программного обеспечения. В методологии Scrum всего три роли:

  • Скрам Мастер (ScrumMaster)

  • Владелец продукта (Product Owner)

  • Команда

Скрам Мастер – это самая важная роль в методологии. Скрам Мастер является интерфейсом между менеджментом и командой. Скрам Мастер отвечает за успех Scrum в проекте. Как правило, эту роль в проекте играет менеджер проекта или лидер команды. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой.

Основные обязанности Скрам Мастера:

  • Создает атмосферу доверия.

  • Участвует в митингах в качестве организатора.

  • Устраняет препятствия.

  • Делает проблемы и открытые вопросы видимыми.

  • Отвечает за соблюдение практик и процесса в команде.

Скрам Мастер ведет ежедневный Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. ScrumMaster может также помогать Product Owner создавать Backlog для команды. [1]

Владелец продукта - человек, который отвечает за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Владелец продукта - это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет. Обязанности Product Owner:

  • Отвечает за формирование видения проекта.

  • Управляет ROI.

  • Управляет ожиданиями заказчиков и всех заинтересованных лиц.

  • Координирует и приоритизирует Product backlog.

  • Предоставляет понятные и тестируемые требования команде.

  • Взаимодействует с командой и заказчиком.

  • Отвечает за приемку кода в конце каждой итерации.

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

В Scrum команда является самоорганизующейся и самоуправляемой. Команда берёт на себя обязательства по выполнению объема работ на спринт перед владельцем продукта. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. [2]

Обязанности команды:

  • Отвечает за оценку элементов Backlog.

  • Принимает решение по дизайну и имплементации.

  • Разрабатывает ПО и предоставляет его заказчику.

  • Отслеживает собственный прогресс (вместе со Скрам Мастером).

  • Отвечает за результат перед владельцем продукта.

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

В Scrum кроссфункциональные команды. В них входят люди с различными навыками - разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью. Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи. [3]

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

Product Backlog - это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.

Product Backlog постоянно пересматривается и дополняется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает владелец продукта. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.

Sprint Backlog содержит функциональность, выбранную владельцем продукта из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.

В Scrum итерация называется Sprint. Ее длительность составляет от 1 недели до 1 месяца. Результатом Sprint является готовый продукт, который можно передавать заказчику.

Короткие спринты обеспечивают быстрый отзыв проектной команде от заказчика. Заказчик получает возможность гибко управлять целью системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий спринт.

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

Список заданий спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменён никем, кроме команды.

В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, владелец продукта, Скрам Мастер и команда. [6]

Планирование спринта состоит из двух последовательных совещаний.

  • Планирование спринта, первое совещание.

Участники: команда, владелец продукта, Скрам Мастер, пользователи, менеджемент. Целью является определить цель спринта и Sprint Backlog -функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.

  • Планирование спринта, второе совещание.

Участники: Скрам Мастер, команда. Целью является определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность.

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

Ежедневное совещание проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга - поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы совещания. Scrum совещание проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды: „Что сделано вчера? Что будет сделано сегодня? С какими проблемами столкнулся?”
1   2   3   4   5   6   7   8   9   ...   14

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


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