Управление IT-проектами #4 – Scrum – детальное рассмотрение методологии

Автор Ivan Samoilov
Управление IT-проектами #4 – Scrum – детальное рассмотрение методологии

Всем привет.

Я Чистяков. Антон и сегодня четвёртое занятие базовый курсы управление проектами. И так сегодня мы говорим об одном из наиболее часто используемых подходов при гибкой разработки it проекта подход в старом достаточно простой и его основная мысль изображено на данном флипчарте.

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

Пусть продуктовом сформировал цены данного продукта и перенес его в содержание задач как мы уже говорили в ней объём задачи которые необходимо выполнить происходит совместная встреча с заинтересованными сторонами с командой проекта где определяется основной объем работ которые имеют наибольшую ценность для заказчика он называется бэклог продукта то есть основной перечень задач которая имеет максимальную ценность для заказчика в конкретный период времени после этого этот блок передаётся в команду проекта состоит из скрам-мастера и собственно команды разработчиков которые принимают участие в проекте как. Мы помним гибкие подходы отличает итеративной разработки при интервальной в данном случае подходит кран эти интервалы называются с принтами спринты имеет интервалы по порядку от 1 до 3 недель в зависимости от того какой предстоит реализовать и какого — это определяется командой на самом первом этапе когда получают бэклог продукта и необходимо понять как мы будем этот продукт реализовывать как могут достигать тех задач которые перед нами поставлена каждого спринта команды набирает себе задачу бэклог спринта которые имеют максимальную ценности которые необходимо выполнить в первую очередь для того чтобы получить результат в среднем на каждые Sprinter команды выполняет порядка 20 и 40 задач в зависимости от их объема и по результатам каждого спринта команда получает некую версии продукта которая уже может быть использовано самим заказчиком либо может быть продемонстрированы. Ника и функции отдельно функциональность конкретного программного обеспечения например. Мы в качестве первой итерации можем прикрутить к сайту оплату только. Яндекс денег в следующий мужа прикрутить дополнительные способы оплаты. Также важно понимать, что в рамках спринтов каждый день проводятся совместные совещания с командой так называемый Daily meeting. Они они длятся порядка 15 их основная цель понять, что идёт в процессе достаточно хорошо, что не требует корректировок. А где необходима дополнительная помощь. Таким образом мы понимаем цикле разработки в подходе скраб то есть. Мы выполняем всё только лично с понтов который нам необходимо чтобы полностью выбрать бэклог продукта, а важно отметить, что после того как завершается каждый спринт у нас появляется некая версия продукта либо программа с усеченным функциональность можем продемонстрировать показать нашему заказчику. А по результатам всех спринцовку нас уже появляются готовые продукты продукты которые может приносить уже полноценная стопроцентным заказчик. Также важно отметить, что по результатам каждого спринта не только каждый день мы по результатам каждого клиента проводится ретроспективное совещание когда команда обсуждает, что удалось достаточно успешно сделать в рамках. Принца, что в следующий раз можно улучшить отдельно хочу отметить и ваше внимание на том, что эти формулировки носит позитивный характер и они направлены больше усовершенствование самого процесса они на поиски виноватых III на поиски проблемы которые есть. Так вкратце мы с вами рассмотрели процесс именно скрам по управлению проектами. Если говорить о тех ролях которые есть в целом подходит с там можно выделить следующие. Первое — это всегда есть заказчика и заинтересованные стороны которые формируют требования к продукту которые необходимо сделать всегда есть product owner. Я считаю, что больше похож на. Николая спонсоров проекта который выявляет основную ценность продукта еду ценность в виде четких задачи доносит до команда проекта есть сама команда проекта выполняет эту задачу. Я обязательно есть скрам-мастер который на мой взгляд конечно выполняет некую функции менеджера проектов который ведёт команду к намеченной цели, но некоторые. Адепт подходов могут со мной не согласиться потому, что как вы знаете аджайл не приемлет никакую. Россию Только горизонтальный подход к управлению проектами. А если говорить о роли мастера то она достаточно велика. Он следит за методологией соблюдение на подходах к управлению проектами. Если необходимо обучает как членов команды так и работников сопряженных отделов если — это крупная организация как. Мы помним одно из основных моментов в скрам — это самоорганизация команды так вот. СтройМастер как раз помогает командам самоорганизовываться если говорить об основном инструменте которые используются при управлении — это доска заказа в принципе по типу той которую мы видели в комбайне. Тоже имеет различные виды типы формы, но имеет часто просто три столбца. Что находится в задачах. Что находится в рамках реализации уже и, что завершено все задачи на доску попадают из продуктов и не делится в принципе на четыре основных составляющих — это некие пользовательские история то есть другие места.

0 комментариев
0

Читайте также