методология за развитие Scrum

Scrum (skrʌm «битка») - методология за управление на проекти. Основният акцент на използването на тази методология е на контрола на качеството на процеса на развитие. Scrum е един от най-популярните "методология" на разработка на софтуер. В допълнение към разработване на софтуер за управление на проекти, Scrum може да се използва за програми за техническо обслужване.

метод Първо Scrum беше представен на широката прегледът се документира, ясно оформен и е описано във връзка Schwaber и Джеф Съдърланд, който през следващите няколко години са работили заедно за описание и представяне на всички от техния опит и модели най-добри практики за управление на проекти в едно, в методологията, която е известна днес като Scrum.

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

процес на управление на Scrum проект

Scrum Терминология проект

• Sprint - етап на развитие;
• Sprint изоставането - задачата на фазата на развитие;
• изоставането на проекта - Списък на изискванията за функционалност.

Sprint итерация

В основата на Scrum е Sprint - етап на развитие, по време на които извършват работа на продукта. Пълна развитие на проекта се състои от кратки етапи Sprint'ov. Функциите, които трябва да бъдат изпълнени от двете Sprint'e. строго фиксирана и не може да се променя по време на спринта; те са разделени на задачите, с оценки и приоритети.

Преди всяко Sprint направи Sprint планиране. който е оценен изоставането Съдържание на проекта и формира Sprint изоставането. съдържа задачи (история бъгове, задачи), които трябва да бъдат изпълнени в текущия спринт. Всеки спринт трябва да има цел, мотивиращ фактор, който може да се постигне чрез изпълнение на задачите на изоставането Sprint.

Sprint винаги е ограничена във времето (1-4 седмици) и е със същата дължина целия период на експлоатация на продукта. В края на Sprint трябва да бъдат получени от новата работа, но не и окончателен вариант на продукта.

изисквания изоставането проекта Списък на проекти

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

В класическия Scrum разбира, че собственикът на проекта може да прави промени директно в хода на проекта, но не и в сегашната Sprint. В повечето случаи, бюджета за разработка на софтуер е фиксиран. Това означава, че клиентите с възможност за влияние върху напредъка твърде ограничен. Въпреки това, ако е необходимо, може да бъде издаден на "Допълнение" към договора, като се вземат предвид промените във финансовата съставяне на проекта и необходимостта да добавите или промените някоя от функциите на проекта за клиента е много спешно. Това допринася за развитието на проекта се изисква от клиента, а не това, което е официално представена в техническото задание.

Ето защо, като изоставането. Като правило, използван в списъка на задачите на техническите спецификации, описани и фиксирани в договора, плюс фиксирани в подобрения извънбюджетните споразумения, възникнали в процеса на работа.

Списък на изискванията за спринт Спринтов списък

Списанието желае Sprint Sprint изоставането съдържа функционалността на проекта до определен етап Sprint'a.

Роли в Scrum управление на проекти

Като се следва процедурата от Скръм в производствения процес има някои роли, разделени на 2 групи, "прасета" и "пилета." Тези имена са били използвани широко поради следната шега:

Пиле предлага прасето: "Да отворим ресторант!" Прасето се взира в пилето и казва: "Идеята е добра, но как искаш да се нарича?" Пиле кратко мисли и реагира. "Защо не се обади" Бъркани яйца с бекон? ".
"Това няма да направи, - отговаря на прасе - защото тогава аз трябва да се посвети на проекта, а ти ще бъдеш само частично участие."

Според "Pigs" схватката се създаде продукт, а "пиле" е не толкова се интересуват от крайния продукт. Те не се интересуват дали проектът е успешен или не, за тях това е малко засегнати. Ето защо, "пилетата" изисквания, желания и идеи са взети под внимание, но те нямат право да включват пряко в хода Scrum-проекта.

Класически Скръм използва 3 основни роли ( "свине"):

Допълнителни функции (допълнителни роли) в методология Скръм ( "Пилета"):

• Заинтересовани клиенти - физически лица, които са започнали на проекта, и за които проектът ще бъде печеливш. Те участват в Scrum само по време на срещата за преглед на Sprint Sprint преглед;
• Управляващи фондове персонал;
• Експертни консултанти Consulting експерти.

етапите на работата

В началото на всеки етап от екипа набира Отчет за списък изоставането на проекта, тъй като много задачи, като да може действително да изпълнява за етап Sprint'a. Той се разделя на подзадачи и точен график.

Sprint планиране Sprint Среща за планиране

В началото на нова итерация Sprint'a вие трябва да планирате съответно. За да направите това, проектът Backlog'a избрани задачи, които в продължение на отбора Sprint DT трябва да изпълняват. Въз основа на избрани задачи, създадени Backlog Sprint'a.

Всяка задача трябва да бъде да се направи оценка на спринта при идеални човекочаса. Решение на проблема би трябвало да отнеме от 8 до 16 часа, т.е. не повече от два работни дни. Ако е необходимо, задачата може да бъде разделена на подзадачи.

По време на планирането се обсъжда и определя по реда на реализиране на пълния обхват на работа. Продължителността на срещата има строги ограничения (по-малко от един работен ден) и зависи от продължителността и команда итерация опит.

Ежедневно наблюдение, Дневни срещи

Ежедневните срещи. иначе известни като стоящ среща се провежда всеки ден. През целия екип Sprint'a заседава редовно по едно и също време. Всеки член на екипа DT трябва да отговори на три въпроса:

• Какво беше направено вчера?
• Какво ще бъде направено днес?
• Какви са проблемите?

При провеждане на Daily-среща е важно да не се падне, за да обсъдят технически подробности по проекта, официално изясняване статуса на проекта.

Спрете спринт, аварийно прекъсване

Спирането на спринта предсрочно то може да се направи при изключителни обстоятелства. Ако отборът осъзнава, че не може да се постигне целта за спринта в определеното време, а след това може да спре Sprint. Sprint също може да спре собственика на проекта, ако вече не е необходимо да се постигне целта на спринта.

След спиране на Sprint проведе среща с командването DT. обсъждане на причините за спиране. След това екипът продължава към следващия Sprint'a.

Фигура задачи горене Burndown структура

За визуално представяне на състоянието на проекта, използвайки горене Burndown задачи диаграма диаграма. показване на размера на извършената работа и работа оставащите по отношение на времето, отделяно за разработване на проекти. Диаграма трябва да бъде редовно (всеки ден) се актуализира в реално време, за да покаже напредъка и разходи на работата по проекта и Sprint. Burndown диаграма трябва да бъде на разположение на всички членове на проекта.

Има два вида графики:

• диаграма горене работи за спринт, което представлява сумата и неизпълнени задачи, изпълнявани в текущия спринт;
• Изгаряне работа схема за проект, който представлява сумата на неуредените задачи, изпълнявани и завърши софтуерен продукт (обикновено на базата на броя на спринтове).

Характеристики Scrum-проект

1. промени Scrum-проекта в изискванията могат да се правят по всяко време.
По този начин е възможно да се промени броят на висящите Каталог в хода на изпълнението. Това го прави по-трудно да се използва Скръм принципи в проекти с фиксирана цена / фиксирани работно време. Scrum идеология твърди, че е невъзможно да се предвиди всички промени, така че няма смисъл да се планира предварително за целия проект е ограничен само от график точно във времето, това е. Д. Само планирането на дела, за да бъде изпълнена в следващия Sprint'ah.

2. Scrum-проект, основният източник на достоверна информация е емпиричен опит на участниците.
В «The Scrum ръководство» се отнася до необходимостта от по-пълно и точно изпълнение на разпоредбите на Scrum в отсъствието на официална лидер и мениджър.

3. Мотивация отбор играе важна роля за успеха на Scrum-проект.
Един от основните принципи на Scrum-проект е наличието на мулти-функционален и самоорганизираща отбор DT. Изследванията на социолозите показват, че броят на самостоятелно мотивирани служители, способни да самоорганизация не е голям. По този начин, само една малка част от персонала е в състояние да работи ефективно в проект-без Scrum значителни промени в ролите, което води до неправилно използване на принципите на Scrum.

Плюсове и минуси на Scrum-проект

Един от най-големите предимства от гледна точка на клиента, бърз старт Srcum-проект с най-висок приоритет функции и най-ниската възможна бюджет. По този начин, Scrum се фокусира върху клиента. Scrum дава възможност на клиента да направи промени в изискванията по всяко време, но не може да гарантира, че тези промени ще бъдат изпълнени. Възможността за променящите се изисквания е привлекателен за много клиенти. В допълнение към това, Scrum опростява проследяването на напредъка на работата.

Въпреки това, за промени в изискванията Scrum-дизайн също ще се променят бюджета на проекта. Разумен компромис е да се сключи споразумението за разработване на проекта с нарастващо разрушаване плюс допълнително споразумение за промените, настъпили в хода на развитие на проекта.

Важна слабост на Scrum е да се създаде многофункционални самоорганизиращи се екипи. Образуване на ефективен екип за развитие на Скръм-проекти често са свързани с липсата на подходящи специалисти (знания + опит + заплата) в компанията и пазара на труда.

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