Galvojums




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

Проблемы, возникшие при внедрении


Не обошлось и без проблем при внедрении новой методологии в команду. Следующие проблемы возникли:

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

    • нестабильная работа сети;

    • проблемы с удалённым подключением к внутренний сети консультантов;

    • сложная бизнес логика, в результате чего даже заказчик не мог объяснить разработчику, как именно что-либо работает в данный момент, либо как именно он желает видеть результат работы разработчика;

    • проблемы с тестовым оборудованием, на исправление которого порой требовалось до двух дней;

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

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

  • Проблема приоритизации. Не смотря на жёсткость Scrum к изменениям в спринтах, руководство обязало принимать срочные задания в спринт. Таким образом раз в две-три недели появлялись срочные задания, на которые приходилось срочно переключаться разработчикам. Были предприняты попытки объяснить бизнесу, что внесение изменений в спринт не несёт ничего хорошего, но они так и не смогли изменить своё отношении в связи с отсутствием какого-либо планирования на своём уровне.
    1. ^

      Что не удалось внедрить


Не смотря на полученные знания, некоторые основы Scrum внедрить всё же не удалось. Среди них:

  • Planning Poker для планирования спринта. Для планирования спринта были заказаны специальные карты, облегчающие планирование. Однако в среднем над одной системой работал один разработчик и у него был лишь один заместитель, у которого была своя основная система. Таким образом разработчики не могли помочь друг другу с определением объёма работ. С другой стороны, существуют корпоративные правила, которые обязывают делать детальный анализ для тех изменений, которые требуют больше 8-ми часов разработки. В итоге было решено, что, если задание с первого взгляда требует больше 8-ми часов разработки, то оно автоматически попадает на анализ, а длительность анализа оценить куда проще. В результате анализа пишется документ, в котором указывается оценка необходимых часов разработки задания, что помогает планировать следующий спринт, если бизнес подтверждает разработку данного изменения.

  • Sprint demo – изначально, по окончанию спринта, команда презентовала свою работу всему отделу. Однако, после сокращения спринта до одной недели, презентации стали отнимать слишком много времени от общего времени, потраченного на разработку. Также посещение презентаций сократилось, так как большинство людей интересовало лишь 10-20% презентуемой информации. В связи с этим было решено отменить презентации, что в итоге повысило эффективность команды за счёт освободившегося времени как теряемого во время презентации, так и времени, необходимого на подготовку к презентации.

  • Sprint retrospective – изначально, по окончанию спринта, команда собиралась и обсуждала проблемы, с которыми участники столкнулись, а также способы избежания этих проблем. Отменить ретроспективу пришлось потому, что в течении недели происходило не так много событий, которые стоило обсуждать и решать. Также, так как каждый разработчик работал над своей системой, общих проблем было очень мало, что делало данное мероприятие бесполезным для большинства участников, пока их не касались какие-либо проблемы. После отмены ретроспектив, как и в случае презентаций, эффективность команды повысилась.
1   ...   4   5   6   7   8   9   10   11   ...   14

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


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