Galvojums




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

Внедрение Scrum


Было проведено совещание для выбора ПО, которое заменит физическую доску. Команда единогласно согласилась использовать Agilo, так как данный продукт требовал меньше всего затрат на установку, настройку и обучение. Руководству очень понравилась возможность создавать отчёты и видеть прогресс с помощью burn down chart, а также оповещений о каждом изменении статуса задания.

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

Результат обсуждения необходимой для отображения информации на рис. 2:



Рис. 2. Пример виртуальной Scrum доски

Описание полей:

  • ID – уникальный идентификатор задания в Agilo;

  • Summary – краткое описание задания;

  • System – система, для которой необходимо выполнить данное задание;

  • RfC No – уникальный номер задания из БД Lotus, в которой храниться подробное описание задания с дополнительной информацией, например, контактными данными заказчика;

  • Business Value – оценка важности задания от меньшего к большему, взятая из БД Lotus;

  • Planned assignee – запланированный исполнитель задания;

  • Owner – исполнитель, взявшийся за реализацию задания;

  • Status – собственно, статус задания. Возможны следующие варианты:

    • New – новое задание, ещё не начато;

    • Accepted – задание начато исполнителем;

    • Closed – задание завершено исполнителем;

  • Initial estimate – начальная оценка времени, необходимого для реализации задания;

  • Spent hours – количество потраченных часов на реализацию задания;

  • Remaining hours – количество часов, которое необходимо для реализации задания по оценке разработчика после начала задания.

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

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

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

Планирование спринтов пришлось разбить на две части:

  • Планирование с заказчиком. Так как у каждой системы свой представитель, было решено проводить отдельное планирование. В результате этого совещания ScrumMaster получает задания, упорядоченные по приоритету в количестве, достаточным для заполнения спринта;

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

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

По окончанию спринта и перед планированием нового были введены два совещания:

  • Sprint demo – разработчики представляли заказчикам и всей команде результаты своей работы;

  • Sprint retrospective – разработчики совещались о проблемах разработки в течении спринта с целью избежать подобные проблемы в будущем. Также обсуждались и положительные стороны предыдущего спринта и их причины.

Конечно же не обошлось без ежедневных совещаний, где каждый разработчик отчитывается, что было сделано в течении предыдущего дня, что будет сделано в течении текущего дня, а также упоминает проблемы, с которыми столкнулся. В отличие от опыта других организаций, команда всегда укладывалась в отведённые 15 минут.
1   2   3   4   5   6   7   8   9   10   ...   14

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


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