Да започна. Scrum и Agile - каква е разликата? Накратко, Agile е философия, семейство от гъвкави подходи към разработката на софтуер. Scrum е един такъв подход. Има брат - Канбан. Това е и подходът, използван в Agile.

Елена Трусковаказва:

Тази седмица преминах двудневно обучение по Agile/Scrum (произнася се „agile“ и „scrum“). За гъвкавите методологии за разработка на софтуер е изписана много неразбираема и не толкова литература, четох много. Но само след два дни потапяне в темата най-накрая имах основно разбиране за темата, от която пиша тази бележка.

Agile и Scrum помагат да се организира процесът на работа в екип по такъв начин, че редовно и често да се пуска продукт, който е интересен за потребителя.

В някои банки, благодарение на agile, пътят на идеята до потребителите беше намален от две години на шест месеца - в други компании шестмесечният цикъл на разработка беше компресиран на три. В тези забързани времена това е истинско конкурентно предимство, особено за по-малките играчи.

Принципите на Scrum могат да се прилагат за абсолютно всичко: например за работа върху творчески продукт. Това, разбира се, не е „каноничен пъргав“, Scrum евангелистите ще скърцат със зъби, но вашите процеси ще се движат по-весело. Дама или отивам?

Някои от Agile и Scrum дори могат да бъдат взети в индивидуална работа. Осигурете редовно публикуване на публикации, измервайте натоварването на изпълнителя, оценявайте бъдещите задачи по отношение на времето и не забравяйте да анализирате качеството на свършената работа - вижте, всичко вече е обмислено за нас. Остава да се реализира.

Пъргав

(Английски agile - "пъргав, умен, бърз")

Концепция за гъвкавост:

Заменете вашия вид дейност вместо думата "развитие" - и тези принципи ще станат близки и разбираеми.

„Работещият продукт е основният показател за напредък“, „простотата като изкуство за минимизиране на ненужната работа“ и „хората и взаимодействието са по-важни от процесите и инструментите“ – звучи ли разумно?

Scrum

(англ. scrum - смачкване в борбата за топката в ръгбито)

Тук си струва да припомня, че това е моята лична и субективна гледна точка относно Scrum. Тук разсъждавам върху приложимостта на елементите на Scrum както в творчески проекти, далеч от ИТ, така и в индивидуална работа (да речем в блог). Много точни подробности за това ще трябва да бъдат пропуснати; Опитвам се да поддържам текста прост и да не претоварвам читателя с терминология.

Твърдостта на Scrum се крие в структурата. Има определен набор от подходи, които работят по-добре заедно, отколкото поотделно. Извадете нещо и го използвайте за вас, дано никой не забранява.

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

Ако работите в екип, Scrum изисква всички участници в процеса да се стремят към взаимозаменяемост, способност да „вдигнат“ провиснала задача, ако съсед е болен, обмен на умения и колективна отговорност за продукта. В Scrum има малко индивидуализъм. Решенията се вземат колективно (съгласно строги принципи), никой не може да ги притиска и принуждава да изберат друго решение, ако екипът е сигурен, че се е спрял на правилното.

Да имаш такова доверие в Scrum не е страшно, тъй като всеки марш продължава точно един спринт (ясен период от време, обикновено от една до четири седмици). След като спринтът приключи, идва момент на анализ: как го преодоляхме? Какво може да се направи още по-добре следващия път?

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

Екип в Scrum

Стандартният размер на Scrum екип е 7 плюс или минус 2 души. Това е пет до девет. Има скалиране на схватка: можете да изградите система за работа по гигантска задача от 25 екипа. Но основната единица на Scrum е екипът.

Всеки отбор има:

• участници (в случай на IT - разработчици, кои са тези седем души, които имате - решете сами)
• собственик на продукт (собственик на продукт, собственик на продукт). Неговата роля: да разбира пазара и потребителя, да формулира задачи на езика на бизнеса и потребителите, да има предвид посоката, в която трябва да се развива стойността и ползата, да измисля и избира задачи за разработване на продукта. Нещо като продуктов (не екипен) лидер.
• scrum master (скръм майстор, скръм евангелист). Неговата роля: следи процеса, наблюдава вътрешния живот на екипа, мотивира хората, премахва пречките. Нещо като треньор.
  Около екипа има потребители и stake-cholers (заинтересовани страни, клиенти). Собственикът на продукта отива при тези хора за съвет.

Спринт на устройството

Scrum работата се състои от спринтове. Всички спринтове са настроени по един и същи начин. Предполага се, че с всеки следващ спринт отборът става все по-кооперативен и ефективен. В Scrum се учиш от грешките си, но бързо – всеки спринт анализираш какво точно си направил и как искаш да го поправиш.

Собственикът на продукта има списък с бизнес идеи, за да направи потребителите доволни. Нарича се „продуктово изоставане“ (списък с идеи за продукти). В него идеите са сортирани по важност и значимост.

Всеки спринт има изоставане в спринта (назад в спринта, списък със задачи за спринт) - сортиран списък с идеи, които екипът е решил да направи в следващия спринт. Смисълът на Scrum е, че екипът сам оценява сложността на всяка задача и решава кои задачи ще бъдат включени в следващия спринт.

Задачата в спринта е с тежест, известна на екипа (знае се колко време ще отнеме), към нея има изпълнител, тя е разбираема и важна. Ако не знаете колко време ще отнеме дадена задача, трябва да я разделите на по-малки части.

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

Обикновено 5 плюс или минус 2 идеи се вписват в един спринт. Ако идеите са твърде големи, екипът ги разделя, така че във всеки спринт да има нещо малко за показване.

В Scrum идеите се наричат ​​потребителски истории (потребителски истории, истории за потребители) и се формулират по следния начин: „Харесвам (роля?) Искам (какво?), за да (защо?)“. Така екипът вижда не само функционалността, но и смисъла на създаването му, и то за конкретна роля: потребител, клиент, купувач.

Резултатът от спринта винаги има какво да покаже. Показва работата на екипа върху демото в края на спринта.

Според мен процесът Scrum е подобен на работата в екипен блог. Такъв процес би помогнал да се поддържа редовността, да обедини експертния опит на авторите и да не набира толкова много, че да не можете да го направите.

Структура на спринта

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

Всеки ден има стояща среща (стояща среща, стояща среща) за 15 минути. Важно е да го правите, докато стоите: ако някой говори, останалите красноречиво ще се преместят от крак на крак и ще се почешат по ухото. Можете да използвате някакъв предмет, така че само един участник да говори в даден момент, и да го предавате в кръг.

Всеки стоящ участник се редува да отговаря на три въпроса:

• какво направих вчера
• какво ще правя днес
• какво ме забавя

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

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

В края на спринта има демонстрация (демо, демонстрация), показваща какво успяхме да създадем по време на спринта, преглед на спринта (преглед на спринта, преглед на спринта) с ревизия на изоставането на продукта и говорене за КАКВО правим, както и ретроспектива (retro ) - какво не сме направили по най-добрия начин през целия спринт и искаме да подобрим допълнително - за това КАК го правим.

„Ако имах осем часа, за да отсека дърво, щях да прекарам шест часа в точене на брадва.“ (Приписва се на дървосекача и президента Ейбрахам Линкълн)

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

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

Scrum методологията е създадена от американците Джеф Съдърланд, изследовател и бизнес консултант, и Кен Швабер, практикуващ програмист, през 1993 г. През 1995 г. авторите на концепцията официално представиха нейните подходи на научната конференция на Асоциацията за компютърни машини в Остин, Тексас.

Идеята за съавторите на Scrum не беше нова: както концепцията, така и името, те възприеха от работата на японски изследователи в областта на управлението, публикувана през 1986 г. Още тогава японските производители използваха подходите, които са в основата на Scrum. А името на методиката е заимствано от речника на ръгбистите. Scrum или схватка е елемент от играта, който показва важността на екипната работа за победа на терена.

Scrum в ИТ и извън него

Scrum е използван за първи път в софтуерни компании. Първият проект, който Дж. Съдърланд ръководи още преди официалното представяне на Scrum, е създаването на софтуер за ATM мрежата (1983 г.). Екипите по програмиране в ИТ компаниите и подразделенията все още са основните потребители на scrum. Авторът на методологията обаче настоява, че Scrum е приложим за решаване на всякакви проблеми и дава примери за използването на Scrum в производството, строителството, образованието, политиката и дори при решаване на ежедневни задачи като общо почистване или организиране на празник.

Всъщност, според Scrum Alliance за 2016 г., 21% от проектите, завършени по Scrum, не са свързани с ИТ сферата. Вижте кои отдели успешно използват scrum:

Scrum срещу Agile срещу Waterfall

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

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

Представете си, че гъвкавото е християнството, а скръмът е едно от неговите течения, например протестантството. И въпреки че християните като цяло и протестантите в частност изповядват едни и същи принципи, протестантите имат свои собствени уникални ритуали за проявление на вярата.

Съответно визуални разлики и прилики междуScrum иAgile може да се представи по следния начин:

* Артефактив scrum това са обекти, които са създадени от екипа, докато работи по проекта. Те включват изоставането на продукта, изоставането на спринта и увеличението на продукта, тоест работната част от функционалността, която екипът демонстрира в края на спринта.

Практиките за гъвкаво развитие се съпротивляват каскаден модел (каскада, водопад, водопад), който през 90-те се използва от почти всички екипи за разработка.

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

Но каскадният методологичен подход не проработи – екипите пропуснаха крайни срокове и изпаднаха от бюджета. Методът на водопада не отчита възникващи проблеми, закъснения и откази, променящите се изисквания на клиентите и околната среда. Трябваше да се търси алтернатива и да се промени процесът на работа - редовно да се обръщаме назад, да анализираме свършената работа и незабавно да премахваме пречките и да правим промени. Поради това се появиха гъвкави гъвкави методологии и неговите производни.

Как да работите със Scrum

Роли в Scrum

Скръм екип

Scrum се основава на екип или група - добре координирано тяло от професионалисти. Scrum екипите са автономни, членовете сами решават как да изпълнят задачата. Те са многофункционални - знанията и уменията на членовете на екипа са достатъчни за решаване на проблема.

Scrum изисква малък екип: 7±2 души. С повече хора членовете на екипа харчат твърде много ресурси за комуникация. В средата на 90-те Лорънс Пътнам анализира 491 екипа за разработка: всички те създаваха нов продукт и бяха с различни размери. Проучването показа, че големите екипи (9-20 души) се нуждаят от 4 пъти повече време и усилия за решаване на проблем, отколкото малките групи (3-7 души).

Scrum Master

Scrum Master е официалният лидер на Scrum екипа, асистент, който наблюдава правилното прилагане на методологията и поддържа морала на екипа. Той отговаря за това как да свърши работата.

Собственик на продукт, собственик на продукт

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

Клиент

Клиентът или клиентът е този, за когото се прави проектът. Клиентът може да е трета страна или организация или вътрешен човек. Например отдел продажби, който поръча на разработчиците да разработят CRM система.

Редовни Scrum срещи и работна секция

Планиране

Първата среща, която започва спринта. На него екипът, с помощта на Scrum Master и Product Owner, избира задачи от горната част на изоставането, които ще имат време да изпълнят.

Избраните задачи се вписват в спринт проекта със срок и изпълнител.

Ежедневни срещи в движение

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

За да направят това, те отговарят на три въпроса:

1. какво направих вчера, за да помогна на отбора да постигне целта си?
2. какво ще направя днес, за да накарам отбора да постигне целта си?
3. какво ми пречеше да си върша работата?

Срещите продължават не повече от 15 минути и се провеждат прави.

За тази среща всеки може да види отчета си за избрания ден.

Демо или спринт преглед

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

Използват се отчети за съответния период от време, "клиентски достъп" до проекти (напредъкът се вижда, вътрешната кухня не се вижда), коментари и емоции.

ретроспекция

Това е среща, на която екипът обсъжда изпълнените задачи по време на спринта, степента на тяхното изпълнение и проблемите, които трябва да бъдат решени. Съотношението на планираните и изпълнените задачи определя ефективността на екипа. В ретроспекция потърсете начини за подобряване.

Използват се справки за съответния период от време по хора, отдели, сметки и подробни.

Алгоритъм. Какво да правя?

1. Изберете собственик на продукткойто ясно определя какво трябва да се направи.

2. Сформирайте Scrum Team.

3. Назначете Scrum Master.

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

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

5. Оценка на задачите от изоставането, като се използват относителни стойности, като размери на тениски или числа от редицата на Фибоначи: 0, 1, 1, 2, 3, 5, 8, 13 и т.н. Оценете задачите с целия екип, като използвате покер за планиране: използвайте тесте карти или приложение за смартфон.

Покерът за планиране е специално тесте карти с числа на Фибоначи. Всеки член на екипа получава свой собствен комплект. Когато Scrum Master обяви задачата, членовете на екипа едновременно поставят карти на масата с числа, които според тях отговарят на трудността на задачата. Ако картите на участниците се различават с една или две единици, например 3 и 8, тогава на задачата се задава сложност, равна на средноаритметичната стойност на тези числа. Ако несъответствието е по-голямо, тогава участниците, които са изхвърлили най-малката и най-голямата карта, обясняват решенията си. След това всички членове на екипа подреждат отново картите. И така, докато всички се споразумеят.

6. Планирайте спринта: Изберете задачи и ги разпределете между изпълнителите.

7. Вземете Scrum Board, разделете го на три части: предстои да се направи, в ход, готово. Преместете стикерите със задачи, за да видите динамиката на работа. Използвайте реална или виртуална бяла дъска.

8. Не забравяйте ежедневните си срещи.

9. Демонстрирайте в края на спринта.

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

11. Започнете следващия си спринт с планиране(точка 6).

Ръководство за Scrum. Окончателното ръководство за Scrum: Правилата на играта / Кен Швабер, Джеф Съдърланд

Указания за Scrum: Описва роли, дейности, Scrum артефакти и как да ги използвате. съставен и поддържан от съавторите на методологията Scrum.

Scrum. Революционен метод за управление на проекти / Джеф Съдърланд

Управление на продукти в Scrum. Гъвкави методи за вашия бизнес / Роман Пихлер

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

Scrum и XP: Бележки от фронтовата линия / Хенрик Книберг

За практическото приложение на съвременните agile подходи – Scrum и Extreme Programming – в конкретен екип. Много примери, инструменти, Scrum методи в действие без вода и теория.

Манифест за гъвкава разработка на софтуер

Състои се от няколко линии, които са базирани на гъвкави методологии.

Предимства и недостатъци на Scrum в ИТ

Scrum е страхотна методология: високо ефективна, прозрачна, мотивираща. Това е печеливш подход, който е от полза както за екипа, така и за клиента.

1. Прозрачност.В екипа има открит обмен на информация, знания, проблеми, всеки се чувства съпричастен към една обща цел. Клиентът винаги е наясно с напредъка на работата, прави промени в процеса, получава надеждна информация за сроковете.
2. Автономия на отбора.з Членовете на екипа решават как да работят по проекта, свободата на действие и отговорността мотивират. Клиентът съобщава изискванията на екипа директно, без повреден телефон.
3. Мотивация от резултата.Концепцията за scrum позволява на всеки член на групата да вижда своите собствени и общи постижения ежедневно. Клиентът получава увеличение на функционалността с всяка итерация.
4. Минимизиране на пазарните рискове.Екипът бързо реагира на променящите се изисквания на проекта и не извършва допълнителна работа. Клиентът получава това, което иска и което се търси на пазара.
5. Минимизиране на финансовите рискове.Малко време и пари се изразходват за премахване на грешки и добавяне на функционалност, всичко се инвестира в бюджета.

Но Scrum е формализирана методология и за някои проекти не е толкова лесно да се приложи.

Ето очевидните недостатъци на Scrum:

• не е подходящ за проекти с неясни изисквания към крайния продукт, т.к клиентът може да увеличи функционалността до безкрайност;
• трудно е да се научите как правилно да приоритизирате и оценявате задачите;
• успехът на проекта зависи твърде много от Scrum Master;
• Scrum е труден за използване в големи проекти, трябва да мащабирате методологията и да въведете scrum of scrum срещи. Тези митинги се посещават от представители на няколко Scrum екипа, работещи върху свързани продукти.

В нашия проект те веднага се опитаха да практикуват scrum на две нива: глобално и на ниво отдели (продажби, маркетинг, финанси и др.). Първо ръководителите на отдели определиха задачи в глобалното планиране, след което се спуснаха на ниво отдел. Справихме се зле – крайният резултат беше твърде размазан.

• високоефективните екипи се отпускат и спират да се подобряват. Индикатор за наличието на проблем е намаляването на динамиката на изпълнение на спринтовете. Scrum Master трябва да предаде сериозността на проблема на екипа. Ако екипът не излезе сам от безизходицата, ръководството се намесва: наемат се нови служители, персоналът се смени.

Scrum компании

Според доклада на Scrumaliance 70% от ИТ компаниите използват Scrum. Сред тях са такива гиганти като Google, Amazon, Salesforce.com, Microsoft, Adobe.

Salesforce.com

Американец, водещ разработчик на CRM системи за бизнеса. Нейните продукти се използват от 150 000 компании. В продължение на много години той използва agile методологически подходи, водени от Scrum, създавайки на негова основа уникален хибрид от няколко agile frameworks.

Използва гъвкави практики от 1999 г., а до 2004 г. няколко екипа за разработка вече използват Scrum. До 2009 г. повечето от разработчиците бяха целенасочено прехвърлени към Scrum.

Spotify

Дигитална музикална услуга, която успешно се конкурира с гигантите Google, Apple и Amazon. Spotify счита своето конкурентно предимство за максимално използване на възможностите на Scrum. Ръководството на компанията наема най-добрите Scrum Coaches, които да действат като Scrum Masters. Работата се извършва от малки автономни екипи, които се третират като стартиращи фирми.

Използва Scrum от 2008 г., 4 хиляди разработчици в стотици екипи от 10-12 души работят по методологията на Scrum, пускайки нов продукт на всеки три седмици. Корпорацията успешно мащабира Scrum, за да отговаря на размера си.

Фактът, че Scrum се използва не само в ИТ сферата, показва проектът - инициатива на учител по химия в училище в холандския град Алфен ан ден Рейн. С подкрепата на бизнес общността в Холандия беше създадена фондация eduScrum, която обучава учители да използват Scrum в класната стая. Студентите, които работят в Scrum екипи, учат по-добре и с по-голямо удоволствие от своите връстници.

Проект Sentinel за ФБР

Въвеждането на методологията Scrum спаси от крах многомилионния проект на американското правителство - единна база данни "Guardian" за ФБР. The Guardian беше вторият опит за разработване на единна информационна система за ФБР. Първият се провали без дори ден работа.

"Гардиън" започва да се създава през 2005 г. по каскадния модел. На проекта бяха отпуснати 4 години и 450 милиона долара. В началото на петата година фирмата изпълнител свърши половината работа и изразходва 95% от бюджета. Според експерти за завършването на проекта ще са необходими още 350 милиона и 6-8 години.

Когато екипната работа на scrum замени модела на водопада в началото на 2010 г., продуктивността на разработчиците се утрои и на 2 юли 2012 г. Guardian беше използван от ФБР във всички щати.

Приложения

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

Лесен и интуитивен за работа по проекти и решаване на различни бизнес проблеми.

Worksection сега финализира и тества функции за scrum преди внедряването (от октомври 2017 г.): диаграмите за изгаряне на задачи и изоставането са чисто инструменти на Scrum. Може също да бъдепланиране на покер.Наш консултант по този въпрос,

Напоследък често ме питат какво е Scrum от хора, които имат много далечна връзка с ИТ. В тази връзка реших да обясня с прости думи какво означава Scrum. Така че господа Scrum-последователи не ме съдете строго.

Scrum (Scrum) не е съкращение, този термин е взет от rugby, което означава битка около топката.

Самият термин Scrum, бих го дефинирал по следния начин, е методология за управление на проекти, която е изградена на принципите на управление на времето. Основната му характеристика е участието в процеса на всички участници, като всеки участник има своя специфична роля. Изводът е, че не само екипът работи върху решаването на проблема, но всички, които се интересуват от решаването на проблема, не просто го поставят и се отпускат, но постоянно „работят“ с екипа и тази работа не означава само постоянен контрол.

Основните термини, използвани в методиката са:

Собственик на продукта - човек, който има пряк интерес от качествен краен продукт, той разбира как този продукт трябва да изглежда / работи. Този човек не работи в екип, той работи от страна на клиента/клиента (може да е друга компания или друг отдел), но този човек работи с екип. И това е човекът, който приоритизира задачите.

Scrum Master - това е човек, който може да се нарече ръководител на проекти, въпреки че това не е съвсем вярно. Основното е, че това е човек, който е толкова „заразен със Scrum бацила“, че го пренася както на своя екип, така и на клиента, и съответно се грижи за спазването на всички принципи на Scrum.

Скръм екип е екип, който приема всички принципи на Scrum и е готов да работи с тях.

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

изоставане (назад) е списък на всички работни места. Можем да кажем, че това е дневник за общо ползване 🙂

Има 2 вида неизпълнени задачи: изоставане на продукта и натрупване на спринт.

Продуктово изоставане — това е пълен списък на всички работи, по време на изпълнението на които ще получим крайния продукт.

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

Планиране на спринт е среща, на която присъстват всички (екип, Scrum Master, Product Owner). По време на тази среща собственикът на продукта приоритизира задачите, които би искал да види завършени в края на спринта. Екипът преценява във времето каква част от желаното може да изпълни. Резултатът е списък със задачи, които не могат да се променят по време на спринта и трябва да бъдат напълно завършени до края на спринта.

Ще се опитам да обясня всичко това на примера на работата на PR агенция, как би могло да изглежда, ако работят по Scrum.

Фирмата клиент "Х" иска да проведе мащабно събитие за своите партньори и журналисти след 2 месеца. Фирма "Х" поръча услуги за организиране на такова събитие от агенция "Z". Фирма "Х" се представлява от PR-мениджър, който отговаря за организирането на събитието от името на клиента. В терминологията на Scrum това лице се нарича Собственик на продукта. От страна на агенцията акаунт мениджърът е отговорен за организирането на събитието ( Scrum Master), която е подчинена на командата ( Скръм екип). На съвместна среща планиране на спринта) компанията и агенцията решават, че ще докладват-планират на всеки 2 седмици ( дължина на спринта). За първите 2 седмици те планираха списък със задачи ( спринт изоставане), обаче, екипът прецени, че няма да могат да попълнят целия този списък. Тогава PR мениджърът (известен още като Собственик на продукта), казва кои от този списък със задачи са по-приоритетни за следващите 2 седмици, след което екипът поема задачите. Единственото нещо, което трябва да се вземе предвид тук е, че в момента на планиране на първия спринт трябва да бъде планиран целият списък със задачи за 2 месеца ( продуктово изоставане), за да не се случи така, че до провеждането на събитието нещо да не е свършено.

В заключение искам да кажа, че всъщност има много повече термини и цялата методика е много по-дълбока. Надявам се, че всичко по-горе ще бъде достатъчно, за да добавим първата идея 🙂

Scrum на разбираем език

„От всички трудности, с които НАСА се сблъска при изпращането на човек на Луната, контролът вероятно беше най-трудната задача“

— Роджър Лаунис, историк на НАСА

През цялата история човечеството е натрупало впечатляващ списък от успешно реализирани комплексни проекти. От построяването на пирамидите в Гиза до изпращането на човек на Луната, най-смелите човешки начинания изискват координираната работа на хиляди хора. А това предполага сложна система за управление на проекти.

И въпреки че само няколко от нас ще се сблъскат със задачи от такъв мащаб, повечето от читателите на този блог ще изпитат управление на проекти по един или друг начин. До 2020 г. PMI се очаква да бъдат там - и много други професионалисти често трябва да управляват мини-проекти, поне на лично ниво.

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

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

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

В тази статия ще разгледаме:

• Класическо управление на проекти
• Пъргав
• Scrum
• Постно
• Канбан
• шестСигма
• ПРИНЦ 2

И преди да разгледаме конкретни методи, нека отговорим на очевидния въпрос - „Защо изобщо се нуждаем от системи и методи за управление на проекти?“- нека разгледаме, разбира се, накратко историята на управлението на проекти и да дефинираме основните термини на управлението на проекти.

Защо "управление на проекти"?

Имената на Нийл Армстронг и Бъз Олдрин ще останат завинаги в историята като символи на едно от най-големите постижения на човечеството – кацането на човек на Луната. Основният принос за това събитие обаче бяха 400 000 служители на НАСА и 20 000 компании и университети, които работиха заедно по мисията Аполо.

През 1961 г. Джон Ф. Кенеди постави задачата да кацне човек на спътник на Земята и да го върне обратно - въпреки факта, че по това време НАСА изпрати човек в космоса само за 15 минути. Такава амбициозна цел изискваше невероятно количество ресурси, сътрудничество, иновации и планиране.

Както се посочва в книгата на НАСА „Управление на лунната програма“, основният проблем не беше „ какво да правя?", и в това, " как да направя толкова много за толкова кратко време?Според д-р Макс Фагет, ръководител на инженерния отдел в космическия център Линдън Джонсън (Космическият център Линдън Б. Джонсън, JSC), тогава НАСА нямаше представа как да извърши всички необходими действия за 10 години. Така че първата стъпка беше да „разбием проекта на управляеми стъпки“.

След това беше важно да се ускори изпълнението на всяка отделна фаза и да се гарантира, че екипите и компаниите, работещи във всяка фаза, комуникират ефективно помежду си и предоставят резултати навреме. Тази задача беше поверена на д-р Джордж Е. Мюлер, който управляваше всяка част от проекта Apollo, от Белия дом до доставчика на най-малката част. За да улесни контрола над проекта, той реши да раздели проекта на 5 области: Програмен контрол, Системно инженерство, Тестване, Надеждност и качество и Полетни операции. Схемата за управление на програмата Apollo е показана в Фигура 1.

Тази 5-степенна система - наречена "Етапи на GEM" след инициалите на д-р Мюлер - е проектирана "да се фокусира върху тестването на продукта и разработването му със знанието, че ще бъде тестван", според самия Мюлер. Контролът на програмата определя какво трябва да се направи, управлява бюджета и изискванията и управлява връзката на програмните елементи. Системното инженерство беше отговорно за разработването на нови устройства и модули, Тестването беше отговорно за гарантирането, че тези нови елементи работят, Надеждността и качеството провериха разработените елементи за съответствие с изискванията и стандартите, а Flight Operations беше отговорен за гарантирането, че тези възли ще работят по време на полета.

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

Кратка история на управлението на проекти

Управлението на проекти не е измислено от НАСА и д-р Мюлер. Египетските пирамиди и Великата китайска стена са продукти на управлението на проекти от праисторически времена. За съжаление, няма документални доказателства за това как е станало изпълнението и управлението на тези проекти, а текущото управление на проекти е отделено от знанията от миналите векове.

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

Ако обаче сте готвач и приготвяте повече от едно ястие, а няколко, например салата (която се състои от 3 етапа) и десерт (който трябва само да се сервира), тогава ще ви трябва инструмент, който ви позволява да проследите времето, прекарано за всеки от тях и кога трябва да са готови. И тук на помощ идва един от първите съвременни инструменти за управление на проекти: диаграмата на Гант, представена на Фигура 2.

Изобретен независимо от К относноВ ролята на Корол Адамецки и Хенри Л. Гант в началото на 20-ти век диаграмата на Гант показва графика на проекта въз основа на крайни дати и крайни дати за задачи. В него се въвеждат задачите, тяхната продължителност и взаимоотношения, след което се изчислява критичният път - най-дългата верига от взаимосвързани задачи, които определят продължителността на проекта. Връзките между началото и края на различните задачи са много важни - не можете да сервирате супа на гостите си, докато не я сготвите, нали?

И така, един типичен проект е много подобен на проект за готвене и сервиране на вечеря, само че има много повече задачи, взаимоотношения, срокове и видове ресурси. За проекти с кратки срокове диаграмата на Гант помага да се реши кога е по-добре да се започнат определени задачи, за да се намали времето за изпълнение. А за проекти със силни ограничения на ресурсите, диаграмата на Гант предоставя възможност за изграждане на схема под формата на управлявана от събития верига процеси за планиране на ресурси.

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

Гъвкавите методи за управление на проекти и свързаните с тях подходи като Lean, Kanban и други са по-подходящи за такива проекти. Има и методи, които ви позволяват да управлявате както работния процес, така и времето и ресурсите – 6 Sigma и Scrum.

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

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

Преди да започнем да разглеждаме най-популярните методи, нека дефинираме някои ключови термини.

Основни термини от управлението на проекти

ПъргавГъвкав итеративно-инкрементален подход за управление на проекти и продукти, фокусиран върху динамичното формиране на изискванията и осигуряването на тяхното изпълнение в резултат на постоянно взаимодействие в рамките на самоорганизиращи се работни групи, състоящи се от специалисти в различни области. Има много методи, базирани на идеите на Agile, най-популярните от които са Scrum и Kanban.

Критична пътека:Непрекъсната последователност от дейности и събития от началото до края, която отнема най-дълго време за завършване.

Събитийна верига от процеси (EPC диаграма):диаграма, показваща последователността на изпълнение на работата по проекта въз основа на наличността и натоварването на ресурсите

Времеви резерв:Времето, с което началото на работата може да бъде отложено, без това да повлияе на общата продължителност на проекта. Така застойът за дейности по критичния път ще бъде нулев.

крайъгълен камък (контролна точка,крайъгълен камък):Ключово събитие, което бележи например края на даден етап. В диаграмата на Гант се обозначава със задача с нулева продължителност.

Мениджър на проекта (ръководител на проекта,проектмениджър,PM ): Ръководител на екипа на проекта, отговорен за управлението на проекта (планиране, изпълнение и приключване на проекта).

ресурси:Елементи, необходими за изпълнението на проекта. Ресурсите са време, оборудване, материали, служители и т.н.

спринт (спринт):Итерация (работен цикъл) в Scrum, с продължителност от седмица до месец, по време на която се създава работеща версия на продукта или негов елемент, която е ценна за клиента.

„Класическо“ или „традиционно“ управление на проекти:Най-широко използваният метод за управление на проекти, базиран на така наречения "Водопад" (Waterfall) или каскаден цикъл, при който задачата се прехвърля последователно през етапите, наподобяващи поток.

Класическо управление на проекти

Най-очевидният начин да направите проекта си по-управляем е да го разделите на последователни стъпки. На тази линейна структура се основава традиционното управление на проекти. В този смисъл наподобява компютърна игра - не можете да преминете на следващото ниво, без да завършите предишното. Диаграмата на работния процес е показана в Фигура 3.

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

Обикновено има 5 етапа на класическо управление на проекти, но могат да се добавят допълнителни етапи, ако проектът го изисква.

5 етапа на традиционно управление:

Етап 1. Посвещение.Ръководителят на проекта и екипът определят изискванията към проекта. На този етап често се провеждат срещи и брейнсторминг сесии, на които се определя какъв да бъде продуктът на проекта.

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

Етап 3. Развитие.Този етап не се изпълнява за всички проекти - като правило той е част от фазата на планиране. Във фазата на разработка, характерна за технологичните проекти, се определя конфигурацията на бъдещия проект и/или продукт и техническите средства за нейното постигане. Например при ИТ проекти на този етап се избира език за програмиране. ( Във вътрешната практика тази фаза обикновено не се разграничава и не се използва терминът "развитие" - ок. прев.)

Етап 4. Внедряване и тестване.На тази фаза всъщност протича основната работа по проекта – писане на код, изграждане на сграда и други подобни. Следвайки разработените планове, съдържанието на проекта, дефинирано по-рано, започва да се създава, контролът се извършва според избраните показатели. Във втората част на тази фаза продуктът се тества, проверява се за съответствие с изискванията на Клиента и заинтересованите страни. По отношение на тестването недостатъците на продукта се идентифицират и коригират.

Етап 5. Мониторинг и завършване на проекта.В зависимост от проекта, тази фаза може да се състои от просто прехвърляне на резултатите от проекта към клиента или дълъг процес на взаимодействие с клиентите за подобряване на проекта и повишаване на тяхното удовлетворение и подкрепа на резултатите от проекта. Последното се отнася за проекти в областта на обслужването на клиенти и софтуера.

Описаното по-горе е основата, върху която се изграждат различни методи за управление на проекти. Различните проекти се нуждаят от различни фази на изпълнение – някои се нуждаят от три фази, други много повече. Понякога се използва така нареченият "итеративен водопад", при който всеки етап е вид подпроект, по време на който задачите се изпълняват във фиксирани итерации. Но същността остава същата - проектът е разделен на етапи, които се изпълняват в строго определена последователност.

Поради факта, че класическото управление на проекти е строго обвързано с времето за изпълнение на задачите, като правило, предварително определено на етапа на планиране, инструментите за календарно-мрежово планиране са отлични за изпълнение на проекти в рамките на този подход. Най-често срещаният инструмент за планиране е споменатата по-горе диаграма на Гант. Има много инструменти за изграждането му, от прости електронни таблици като Excel и Smartsheet до професионални софтуерни пакети като Microsoft Project и Primavera.

Силни страни на класическото управление на проекти

Днес често се казва, че класическият водопаден подход е остарял, но той дори не мисли да губи позиции. Голямото предимство на този подход е, че той изисква Клиентът и ръководството на компанията да определят какво искат да получат още на първия етап от проекта. Ранното включване носи известна стабилност в работата на проекта, а планирането ви позволява да рационализирате изпълнението на проекта. В допълнение, този подход включва мониторинг на индикатори и тестване, което е абсолютно необходимо за реални проекти с различни размери.

Потенциално класическият подход избягва стреса поради наличието на свободно време на всеки етап, заложено в случай на усложнения и изпълнение на рискове. Освен това, с правилно проведен етап на планиране, ръководителят на проекта винаги знае с какви ресурси разполага. Дори ако тази оценка не винаги е точна.

Слабости на класическото управление на проекти

Основната слабост на класическото управление на проекти е непоносимостта към промените. Ръководството на Toyota, известно със създаването на системи като Lean и Kanban, често е критикувано за класическия подход при разработването на софтуер за тяхната компания и именно за липсата на гъвкавост.

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

Пъргав

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

И тук влиза в действие Agile – семейство от гъвкави итеративно-постепенни методи за управление на проекти и продукти. Според този подход проектът не се разделя на последователни фази, а на малки подпроекти, които след това се „сглобяват“ в завършен продукт. Схемата на работа е показана на Фигура 5.

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

Въпреки факта, че Agile влезе на мода сравнително наскоро, идеята за итеративно развитие не е нова. (за историята на появатаAgile може да се чете - прибл. на.).Семейството от гъвкави методологии получи сегашното си име през 2001 г. с публикуването на Agile Manifesto (Agile Manifesto), който консолидира основните ценности и принципи на гъвкавото разработване на софтуер, които се основават на работа в екип и адаптация, дори „любов“ към промяна.

Agile сам по себе си не е метод за управление на проекти. Това е по-скоро набор от идеи и принципи за това как трябва да се изпълняват проектите. Вече въз основа на тези принципи и най-добри практики са разработени отделни гъвкави методи или, както понякога се наричат, рамки: Scrum, Kanban, Crystal и много други. Тези методи може да са доста различни един от друг, но следват същите принципи.

Силни страниПъргав

Най-важното предимство на Agile е неговата гъвкавост и адаптивност. Може да се адаптира към почти всякакви условия и процеси на организацията. Именно това определя сегашната му популярност и колко системи за различни области са създадени на негова основа.

Един от принципите на Agile е: „Отговорът на промяната е по-важен от следването на план.“ Именно бързата и сравнително безболезнена реакция при промяна е причината много големи компании да се стремят да направят процесите си по-гъвкави. В допълнение, Agile е страхотен за отворени проекти като стартиране на услуга или блог.

Сферата на Agile е разработването на нови, иновативни продукти. В проектите за разработване на такива продукти има висока степен на несигурност и информацията за продукта се разкрива по време на проекта. При такива условия става невъзможно да се реализира проектът на "водопада" - няма информация за планиране.

Слаби страниПъргав

За разлика от PRINCE2 и PMBOK, Agile не е нито методология, нито стандарт. Agile е набор от принципи и ценности. Слабата страна е, че всеки екип ще трябва самостоятелно да състави собствена система за управление, ръководена от принципите на Agile. Това е сложен и продължителен процес, който ще изисква промени в цялата организация, от процедурите до основните ценности. Това е трънлив път и не всички организации могат да го направят.

Този път ще изисква от лидера на промяната не само знания и постоянство, но и сериозен административен ресурс, както и разходи. За щастие има готови набори от практики, които улесняват една организация да трансформира Agile. Тези комплекти включват Scrum framework, метода Kanban и много други - Crystal, LeSS, SAFe, Nexus.

Scrum

Agile рамката, създадена през 1986 г., се счита за най-структурираната от Agile семейството. Създаден през 1986 г., той съчетава елементи от класическия процес и идеите за гъвкав подход към управлението на проекти. Резултатът е много балансирана комбинация от гъвкавост и структура.

Следвайки предписанията на Agile, Scrum разделя проекта на части, които могат да бъдат използвани незабавно от клиента за получаване на стойност, наречени продуктови неизпълнени задачи. И въпреки факта, че „назад на продукта“ е доста точен превод и се използва в професионалната литература, в руската практика най-често се използва просто „назад“. След това тези части се приоритизират от Product Owner - представител на клиента в екипа. Най-важните „парчета“ са първите, които се избират за изпълнение в Sprint – така наречените итерации в Scrum, с продължителност от 2 до 4 седмици. В края на спринта на клиента се представя работеща продуктова стъпка – най-важните „парчета“, които вече могат да се използват. Например сайт с част от функционалността или програма, която вече работи, макар и частично. След това екипът на проекта преминава към следващия спринт. Продължителността на спринта е фиксирана, но екипът я избира самостоятелно в началото на проекта, въз основа на проекта и собственото си представяне.

За да сме сигурни, че проектът отговаря на изискванията на клиента, които са склонни да се променят с времето, преди началото на всеки спринт, обхватът на проекта, който все още не е завършен, се преоценява и се правят промени в него. Всички участват в този процес – екипът на проекта, Scrum Master (Scrum Master, лидер на проектния екип) и Product Owner. И всеки носи отговорност за този процес.

Както вече споменахме, Собственикът на продукта е представител на Клиента в проекта или олицетворява всички клиенти на бъдещия проект, ако Клиентът не присъства. За да направи това, той трябва да познава задълбочено техните нужди и начин на мислене, както и да разбира продукта и технологията на неговото производство. Scrum Master е предназначен да помогне на участниците в проекта да разберат и приемат по-добре ценностите, принципите и нормите на Scrum практиката. Той е лидер и посредник между външния свят и екипа. Неговата задача е да гарантира, че никой не пречи на екипа сам и удобно да работи по задачите. Екипът е отговорен да гарантира, че в края на спринта всички необходими задачи са изпълнени и доставките са завършени.

Основната структура на процесите на Scrum се върти около 5 основни срещи: последователност на неизпълнените задачи, планиране на спринт, ежедневни срещи, разбор на спринт и ретроспекция на спринт.

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

Силни страниScrum

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

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

По време на всяка итерация разработчиците добавят и тестват нови функции на сайта и премахват тези, които не са били използвани от клиентите. Според екипа на Netflix основното предимство на Scrum е, че ви позволява да се „проваляте бързо“. Вместо дълго и скъпо основно издание, scrum доставките са малки по размер. Те са лесни за проследяване и, ако нещо се обърка, бързо го коригират.

Слаби страниScrum

Scrum е много взискателен към екипа на проекта. Той трябва да е малък (5-9 души) и многофункционален – тоест членовете на екипа трябва да имат повече от една компетентност, необходима за изпълнението на проекта. Например, разработчикът на софтуер трябва да има познания за тестване и бизнес разузнаване. Това се прави, за да не "бездейства" част от екипа на различните етапи от проекта, както и за да могат служителите да си помагат и да се заместват.

Освен това членовете на екипа трябва да бъдат „отборни играчи“, да поемат активно отговорност и да могат да се организират. Намирането на такъв зрял екип е много трудно!

Scrum не е подходящ за всички екипи и организации и защото предложеният процес може да не е подходящ за разработването на конкретен продукт - например индустриална машина или изграждане на сграда.

Постно

Agile ни казва какво да разделим на малки, управляеми пакети от работа, но не казва нищо за това как да управляваме разработката на този пакет. Scrum ни предлага своите процеси и процедури. Lean от своя страна добавя схема на работен процес към принципите на Agile, така че всяка от итерациите да се изпълнява със същото качество.

В Lean, точно както в Scrum, работата е разделена на малки пакети за доставка, които се изпълняват отделно и независимо. Но в Lean, за разработването на всеки пакет за доставка, има работен процес със стъпки, подобни на тези, създадени за проекта Apollo. Както при класическото управление на проекти, това могат да бъдат етапите на планиране, разработка, производство, тестване и доставка - или всякакви други етапи, необходими за качественото изпълнение на проектите.

Lean етапите и тяхната гъвкавост ви позволяват да сте сигурни, че всяка част от проекта се изпълнява според изискванията. Lean няма ясни граници на етапа, както Scrum прави с ограниченията на Sprint. Освен това, за разлика от класическото управление на проекти, Lean ви позволява да изпълнявате няколко задачи паралелно на различни етапи, което увеличава гъвкавостта и увеличава скоростта на изпълнение на проекта.

Подобно на Agile, Lean е по-скоро концепция, начин на мислене, отколкото нещо, поставено в камък. Използвайки идеите на Lean, можете самостоятелно да създадете система, която отговаря на вашите изисквания в управлението на проекти.

Силни страниПостно

Ако харесвате Agile идеите, но проектът изисква много гладко качество и прецизно изпълнение, Lean предоставя набор от инструменти, за да отговори на тези изисквания. Lean съчетава гъвкавост и структура като Scrum, но по малко по-различен начин.

Слаби страниПостно

Не всяка част от проекта изисква същото подробно и щателно проучване и внимание. Но Lean предполага точно този подход към всяка задача и етап. Това е основният недостатък на използването на Lean за големи и хетерогенни проекти.

Освен това, за разлика от Scrum, Lean не предлага ясен работен процес за изпълнение на „парчета“ от проекта, което допринася за разтягане на графика на проекта. Този проблем може да бъде решен с ефективно лидерство и ясни комуникации ̶ основното нещо, което трябва да запомните е това.

Канбан

Lean изглежда малко абстрактно само по себе си, но когато се комбинира с Kanban, става много по-лесно да го използвате, за да изградите своя собствена система за управление на проекти. Създаден от инженера на Toyota Тайичи Оно през 1953 г., Kanban е много подобен на индустриалното производство. На входа на този процес влиза парче метал, а на изхода се получава готовата част. Също така в Kanban нарастването на продукта се предава от етап на етап и накрая се получава готов за доставка артикул.

Освен това създателят на Kanban се е вдъхновил от супермаркетите, а именно от техния принцип – „дръж на рафтовете само това, от което клиентът се нуждае“. Следователно Kanban ви позволява да оставите незавършена задача на един от етапите, ако нейният приоритет се е променил и има други спешни задачи. Нередактирана публикация в блог, висяща без дата на публикуване или част от код за функция, която може да не е включена в продукта, са нормални за работа с Kanban.

Kanban е много по-малко строг от Scrum - не ограничава времето за спринтове, няма роли, освен за собственика на продукта. Kanban дори позволява на член на екипа да изпълнява много задачи, което Scrum не позволява. Също така срещите за състоянието на проекта не са регламентирани по никакъв начин - можете да го правите както искате, а можете и да не го правите.

За да работите с Kanban, трябва да дефинирате стъпки от работния процес. В Kanban те се показват като колони, а задачите представляват специални карти. Картата се движи през етапите, като част от фабрика, която се движи от машина на машина, и на всеки етап процентът на завършеност е по-висок. В резултат на това получаваме продукт, готов за доставка до клиента. Дъска с колони и карти може да бъде както истинска, така и електронна - дори тук Kanban не налага никакви ограничения на потребителите.

Вашата собствена Kanban система може да бъде толкова гъвкава, колкото искате, защото в много отношения Kanban е визуализация на Agile идеята. Но Канбан има 4 стълба, върху които почива цялата система:

1. Карти:За всяка задача се създава индивидуална карта, в която се въвежда цялата необходима информация за задачата. Така цялата необходима информация за задачата е винаги под ръка.
2. Ограничение на броя задачи на етап:Броят на картите на един етап е строго регламентиран. Благодарение на това веднага става ясно, когато възникне „задръстване“ в работния процес, което се отстранява своевременно.
3. Непрекъснат поток:Задачите от натрупаните задачи попадат в потока по приоритет. Така че работата никога не спира.
4. Непрекъснато подобрение (кайзен)кайзен)):Концепцията за непрекъснато усъвършенстване се появява в Япония в края на 20 век. Същността му е постоянен анализ на производствения процес и търсене на начини за подобряване на производителността.

Силни страниКанбан

Подобно на Scrum, Kanban е много подходящ за доста сплотени екипи с добра комуникация. Но за разлика от Scrum, Kanban няма твърди срокове, което е добре за силно мотивирани и опитни екипи.

Когато е правилно настроен и управляван, Kanban може да донесе голяма стойност на екипа по проекта. Точното изчисляване на натоварването на екипа, правилното поставяне на ограниченията и фокусът върху непрекъснатото подобрение - всичко това позволява на Kanban сериозно да спести ресурси и да се вмести в срокове и бюджет. И всичко това съчетано с гъвкавост.

Слаби страниКанбан

Често можете да чуете, че Kanban, за разлика от Scrum, може да работи с почти всеки екип. Но не е така. Kanban е най-подходящ за екипи, чиито умения на членовете се припокриват. По този начин те могат да си помогнат взаимно за преодоляване на трудностите при решаването на проблеми. Без това Kanban няма да бъде толкова ефективен, колкото би могъл да бъде. Освен това, както вече споменахме, Kanban е по-подходящ в случаите, когато няма твърди срокове. За кратки срокове класическият подход или Scrum е по-подходящ.

6 сигма (Шест сигма)

Motorola, заедно с Toyota, също допринесоха за развитието на глобалното управление на проекти. Бил Смит, инженер в тази компания, създава концепцията за 6 Sigma през 1986 г. Това е по-структурирана версия на Lean от Kanban, която добавя повече планиране за спестяване на ресурси, подобряване на качеството и намаляване на скрап и проблеми.

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

За това е предложен процес от 5 стъпки, известен като DMEDI:

• определение (дефинирам):Първият етап е много подобен на ранните етапи на други системи за управление на проекти. Той определя съдържанието на проекта, събира информация за предпоставките на проекта, поставя цели.
• Измерение (мярка): 6 Sigma е фокусирана върху събирането и анализа на количествени данни за проекта. На този етап се определя кои индикатори ще определят успеха на проекта и какви данни трябва да бъдат събрани и анализирани.
• проучване (Разгледайте):По време на етапа на проучване ръководителят на проекта решава как екипът може да постигне целите си и да изпълни всички изисквания навреме и в рамките на бюджета. На този етап е много важно нестандартното мислене на ръководителя на проекта при решаването на възникналите проблеми.
• развитие (Разработване):На този етап се изпълняват плановете и решенията, взети на предишните етапи. Важно е да се разбере, че на този етап е необходим подробен план, който описва всички действия, необходими за постигане на целите. На този етап се измерва и напредъкът на проекта.
• Контрол (контрол):Ключов крайъгълен камък в методологията на 6 Sigma. Основната му цел е дългосрочно подобряване на процесите по изпълнение на проекти. Този етап изисква внимателно документиране на научените уроци, анализ на събраните данни и прилагане на придобитите знания както в проекти, така и в цялата компания като цяло.

6 Sigma е много подобен на Kanban, само с установените етапи на изпълнение на задачите - планиране, поставяне на цели и тестване на качеството. Най-вероятно ще има значително повече екипни срещи с 6 Sigma, отколкото с Kanban, но процесът на изпълнение на проекта е по-структуриран и е по-трудно за екипа да се заблуди. И подобно на Kanban, 6 Sigma е относително лесен за адаптиране към нуждите на определена компания или екип. Строго изискване е само задълбочено измерване и контрол на показателите на проекта на етапите на изпълнение - без това е невъзможно непрекъснато дългосрочно подобряване на процесите на изпълнение на проекта.

Силните страни на 6 Сигма

Six Sigma предоставя ясен план за изпълнение на проекта и непрекъснато подобряване на процеса. Чрез дефиниране на цели, след това внимателно анализиране и преразглеждане, вие получавате количествени данни за по-задълбочено разбиране на проекта и вземане на по-добри решения. Докато събирането на данни, анализът и обучението може да отнеме известно време, това ще подобри и рационализира процесите на изпълнение на проекта и по този начин ще спести ресурси в бъдеще.

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

Слабости на 6 Sigma

Проблемът с 6 Sigma е, че въпреки че основната декларирана цел е намаляване на разходите и повишаване на ефективността, удовлетвореността на клиентите често излиза на преден план. Като се имат предвид някои от разликите в целите на различните етапи от проекта, екипите често се объркват относно приоритетите и избягването на това не е лесно.

Освен това основният лайтмотив на 6 Sigma е: „Всичко винаги може да бъде направено още по-добро“. Това може да демотивира служителите, които не се чувстват удовлетворени от свършената работа. Освен това, ако проектът е еднократен и компанията не планира да изпълнява подобни проекти в бъдеще, всички разходи за анализ и обучение може да са напразни.

ПРИНЦ 2

НАСА не е единствената правителствена организация, допринесла за развитието на управлението на проекти. Британското правителство отдавна е оценило ефективността на управлението на проекти и през 1989 г. е създадена британската методология PRINCE2. Името идва от съкращението " PRобекти IN ° Сконтролирани д nvironments версия 2 ”, което се превежда като „Проекти в контролирана среда версия 2”. За разлика от гъвкавите методи, PRINCE2 не използва итеративен подход към проекта. В сравнение с други продукти, PRINCE2 може да се сравни с хибрид на класическия подход за управление на проекти и фокус върху качеството от 6 сигма.

Методологията PRINCE2, за разлика например от тялото на знанията PMBOK, не съдържа:

• Специализирани аспекти на управлението на проекти, като индустрия;
• Специфични практики и инструменти за управление на проекти като диаграма на Гант, WBS и др.

PRINCE2 се концентрира върху аспектите на управлението на проекти, изразени в 7 принципа, 7 процеса и 7 теми на проекта.

• 7 принципа определят общите правила за управление на проекти според PRINCE2, определят основата на методологията;
• 7 процеса определят стъпките за преминаване през цикъла на проекта;
• 7-те теми са аспектите, които се наблюдават, за да се постигне успех на проекта.

В началото на проект PRINCE2 ни моли да дефинираме 3 основни аспекта на проекта:

• Бизнес аспект (ще донесе ли този проект ползи?)
• Потребителски аспект (Какъв продукт е необходим, какво ще направим?)
• Ресурсен аспект (Имаме ли достатъчно, за да постигнем целта?)

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

Според PRINCE2 всеки член на екипа има отделна роля във всеки от 7-те процеса:

• Начало на проекта (Стартинж нагореа проект): По време на този процес се назначава ръководител на проекта и се определят общите изисквания за ефективност на продукта. Ръководителят на проекта, чиято основна отговорност е вниманието към детайлите, докладва на Управителния комитет на проекта, който отговаря за цялостното ръководство на проекта. Управителният комитет е този, който поддържа проекта в правилния план и е изцяло отговорен за успеха на проекта.
• Иницииране на проектаа проект): По време на този процес ръководителят на проекта подготвя „Документ за започване на проекта“, който съдържа поетапния план на проекта. Етапите могат да продължат различно време, но, както при класическия подход, те следват строго един след друг.
• Управление на проекти (Directiнг а проект): Този процес позволява на Управителния комитет да поеме цялостната отговорност за успеха на проекта, без да се затъва в подробности, които са в обсега на ръководителя на проекта.
• Контрол на етапа (Контроллинг а сцена): По време на изпълнението на проекта, дори и при идеални условия, ще бъдат направени някои промени. Процесът Stage Control прилага един от принципите на PRINCE2 - принципът на управление чрез изключения. Отговорност на ръководителя на проекта е да наблюдава по време на изпълнението на етапа отклонения от планираните параметри на проекта по отношение на време, обхват, бюджет и т.н. Ако тези отклонения надхвърлят правомощията, дадени на ръководителя на проекта от Управителния комитет (в PRINCE2 терминология - допустими отклонения), ръководителят на проекта е длъжен да информира Управителния комитет и да предложи изход от ситуацията.
• Управление на създаването на продукти (Управление Продукт доставка):Процесът на управление на създаването на продукт е взаимодействието между ръководителя на проекта и мениджъра на екипа за създаване на един от продуктите на проекта. Отговорностите на ръководителя на проекта в този процес включват делегиране на правомощията за създаване на продукта на ръководителя на екипа и приемане на създадения продукт.
• Управление на границите на сцената (Managинж а сцена граница): По време на този процес ръководителят на проекта предоставя на Управителния комитет цялата необходима информация, за да оцени резултатите от преминатия етап и да вземе решение за преминаване към следващия етап.
• Завършване на проекта (затварянеа проект): Една от разликите в PRINCE2 е, че процесът на завършване на проекта не е отделен в отделен етап или етап, както при класическия подход, а се извършва като част от крайния етап на създаване на продукта. Целта на процеса е да потвърди, че продуктът на проекта е приет или че проектът вече не може да предоставя нищо полезно.

PRINCE2 може да се адаптира към проекти от всякакъв размер и предметна област. Методологията предлага конкретни препоръки за промяна на жизнения цикъл на проекта, модел за подражание и набор от необходими документи в съответствие с нуждите на проекта.

Силните страни на PRINCE2

• Адаптивност към характеристиките на организацията;
• Наличието на ясно описание на ролите и разпределението на отговорностите;
• Акцент върху продуктите на проекта;
• Определени нива на управление;
• Фокус върху икономическата осъществимост;
• Последователност на работата по проекта;
• Акцент върху улавянето на опит и непрекъснатото усъвършенстване.

Слабости на PRINCE2

• Липса на индустриални практики;
• Липса на специфични инструменти за работа в проекта.

Най-добрата система за управление на проекти ... за вас!

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

« Цинизмът е отговор на нашето съзнание на чувство на отчаяние.».
Джеф Съдърланд

Колко силна е алтернативата на PM?

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

При второто, по-подробно разглеждане на метода Scrum, започнаха да се осъзнават характеристиките, които според мен все още заслужават внимателно внимание от страна на бизнес общността. Дори изглежда, че този метод е интересен не само за търговско-промишлената сфера, но и за други институции на нашето общество. Методът е приложим при проектиране на модели на образование, НИРД, държавно и общинско строителство. Въпреки това, както за всяко ново, важно е:

• изключват абсолютизирането и рецептурната безупречност на разглежданата технология;
• имайте предвид, че методът Scrum е идеологически суров и може просто да „не лежи на нашата почва“ със своите начини и традиции;
• вижте конфликтните точки, които носи този метод;
• разберете, че методът Scrum изисква прозрачна идеология на държавата и бизнеса по отношение на "правилата на играта" с персонала, участващ в разработката.

Дали съвременната парадигма за управление на проекти, международни и национални стандарти (ANSI PMbok Guide, PM ICB IPMA, NTK) са продукт, който потребителите използват: държавата, нейните институции, бизнес? Разбира се. Какви проблемни области съществуват в съвременната дизайнерска практика въз основа на методологията на работа? Има няколко от тях, но има две основни: неспазване на сроковете на проекта и надвишаване на бюджета на проекта.

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

Това свойство на проектите е особено остро в области, които изискват иновативен подход. Методът Scrum може значително да смекчи тези проблеми. В началото на 2000-те години това е резултат от работата на двама новатори Д. Съдърланд и К. Швабер (САЩ). В своето развитие авторите на метода са използвали елементи от теорията на Х. Такеучи и И. Нонака, както и идеите на системата на Тойота (Тайичи Оно). И като революционен метод за управление на проекти, моделът Scrum вече получи признание в западните страни и днес практиката на прилагането му не се ограничава само до бизнеса.

Терминология на метода

Авторите на метода основателно критикуваха класическия модел на планиране на проекти, който се използва от около 100 години въз основа на подхода на G. Gantt. Наистина нищо не може да се противопостави на твърдението, че визуалната диаграма на Гант е по същество за еднократна употреба. Не само, че работата по него отнема много време, почти веднага след началото на проектирането, каскадният модел в повечето случаи се оказва безполезен.

Причината е много проста: умствените конструкции по отношение на съдържанието и продължителността на операциите никога не съвпадат с действителните събития на проекта. Алтернатива на каскадното планиране на проекти, методологията Scrum предлага гъвкав механизъм за планиране. Ще го разгледаме малко по-късно, но засега ще анализираме основните концепции, върху които работи методът Scrum.

1. Собственик на продукта. Тази фигура е отговорна за гарантирането, че работата в екип води до резултат, който носи печалба (ползи) на компанията. Той трябва да познава добре същността на продукта, възможностите на екипа и приоритетите на пазара.
2. Scrum майстор. Метафорично, това е много интересна роля. „Лидер-слуга“, „капитан на отбора“, „треньор-треньор“. Основната му задача е да води екипа по пътя на непрекъснатото усъвършенстване, премахвайки пречките и причините за смущения.
3. Scrum дъска. Обикновена офисна дъска, разделена на части: „назад“, „на работа“, „в работа“, „за разглеждане“, „готово!“. По нея се движат залепващи стикери със задачи.
4. Колекция Scrum. Финална среща в края на спринта.
5. Спринт. Времеви период от 1 до 4 седмици, определящ работния ритъм на Scrum екипа за създаване на нова функционалност.
6. Срещи в движение или ежедневен Scrum. Кратки срещи на екипа на проекта за отговор на въпросите на Scrum Master за резултатите, плановете за деня и текущите пречки.
7. Назад (назад). Списък с текущи изисквания-задачи за създаване на функционалността на продукта на проекта.
8. Диаграма за изгаряне на задачи. Диаграма, показваща количеството свършена работа и оставащата работа по дадена задача.
9. Ред на Фибоначи. Математическа закономерност, присъща на природата на нашата Вселена, при която действа специален ред на числата. Тази последователност е добре приложима за алтернативна оценка на продължителността на проекта, благодарение на използването на така наречения "покер за планиране". По-долу е визуален модел на числовата последователност.
10. Шухари (Шу Ха Ри). Шухари е една от концепциите на японските бойни практики (например айкидо), която е включена в принципите на метода Scrum като метафора за възможността за поетапно (повтарящо се) постигане на съвършенство от екипа на проекта.
11. OODA. Принципът на метода Scrum за циклично внедряване: наблюдавайте, навигирайте, решавайте, действайте.

Модел на последователността на Фибоначи

Основният модел на метода Scrum. Източник: Асхат Уразбаев. Кратък преглед на методологията Scrum

Кратко описание на процеса

Методологията Scrum, така да се каже, потапя тъканта на изпълнението на проектната задача в доста твърд ритъм на циклични спринтове. За разлика от стандартните проектни дейности, в методологията първоначалното послание за планиране не са задачи (въпреки че проектната задача не е отменена), а истории и факти, които помагат да се разберат ценностите и нуждите на потребителя, клиента на проекта продукт. Необходимо е да се разберат мотивите, които предизвикват нуждата му от продукта.

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

Изпълнението на проекта чрез Scrum процеси се състои от четири основни блока.

1. Попълване на роли в Scrum екип.
2. Образуване на Scrum артефакти.
3. Изпълнение на дейността.
4. Възпроизвеждане на цикъла Scrum.

Визуален модел на процеса на метода Scrum

Съставът на ролите в метода Scrum е прост: собственик на продукта, ръководител на Scrum и екип. В същия ред се избират хора за тези роли. Най-близо до класическата роля на мениджъра на проекта е собственикът на продукта, той отговаря за формирането и редовната промяна на продуктовия беклог. След формирането на изоставането екипът на проекта започва да планира предстоящия спринт. В същото време „планиращият покер“ се използва активно като по-обективен и балансиран инструмент, базиран на метода Делфи и последователността на Фибоначи. Така се образува локален изоставане за предстоящия цикъл на новия спринт.

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

Пример за Scrum борд

Съставът на атрибутите на дъската Scrum може да отразява специфичните характеристики на подхода на компанията към дизайна. Освен това могат да бъдат включени диаграми за изгаряне на задачи, декларации за целите на спринта и т.н. След приключването на спринта се провеждат две събития по проекта: срещата за преглед на спринта и срещата за ретроспекция. Резултатът от срещата за преглед е продукт на проекта с модифицирана или напълно завършена функционалност. След ретроспективния анализ се очертава списък с необходимите подобрения в работата на Scrum екипа. Цикълът се затваря, продуктовото изоставане се коригира. От него се „изтеглят“ нови задачи и процесът започва отново.

Коментари за попълване на роли

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

Стъпка 1 от алгоритъма на методологията Scrum

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

• семантично компетентна трансформация на ролята на ръководител на проекти в собственик на продукти, от позицията на НЛП, прецизно програмиране на лидер за резултата от дадена проектна задача;
• класиране на списъка със задачи (назад) на проекта по стойности (за клиента) и рискове;
• гъвкавост при приемане на промени в стойността на продукта за клиента на проекта;
• точкуване на задачи и възможност за замяна на задачи по проекта по време на преразпределение на приоритетите и спиране на спринта.

Стъпка 2 от алгоритъма на методологията Scrum

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

Стъпка 3 от алгоритъма на методологията Scrum

Първите осем метафори за следващата стъпка на Scrum могат да се разглеждат като правила за правене на бизнес или всякакъв друг вид дейност, включително проекти. Неволно си задавате въпроса: защо в реалностите на дизайнерската практика това не може да се види? Мисля, че трябва да се изяснят още няколко точки, за да се отговори на него.

1. Ако „лидерът не е шефът“, а Scrum Master е „играч-треньор“, тогава кой управлява Scrum екипа? Самоуправлението според мен не се вписва в концепцията за управление на проекти.
2. Възниква въпросът за мотивацията на собственика на продукта на проекта, Scrum Master и Scrum екипа. Методологията описва принципа на откритост на информацията, включително достъп до финансовите данни на проекта. Идеята не е лоша, но като се има предвид макиавелистката нагласа, която присъства в много руски компании, подобна възможност сред лидерите вероятно ще има много противници.

Въпросът за образуването на артефакти

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

Основното е, че този списък от изисквания на Scrum не се счита за нещо еднократно намерено и непоклатимо. Продуктовото изоставане претърпява динамично преосмисляне всеки път след края на спринта. А това е много ценно според мен. Мога да кажа от собствен опит, че такъв механизъм липсва в класическия модел на управление на проекти.

Стъпка 4 от алгоритъма на методологията Scrum

Петата стъпка от алгоритъма Scrum е не по-малко интересна. Абсолютно не искам да се гмуркам в мистичните аспекти на числата. Но имаме обикновена прагматична задача: да направим най-добрата прогноза за продължителността на проекта, използвайки най-обективната експертна оценка. За съжаление "гадаенето" чрез записване на часове в MS Project не е нищо по-мрачно и изтощително, дори и с участието на опитни експерти. Мога да заявя с увереност, че никога не съм срещал по-добър метод от „планиране на покер“ в проектната практика. Методът е широко известен, така че няма да се спираме на него. Само ще отбележа, че комбинацията от метода Делфи и редицата на Фибоначи дава невероятни резултати.

Пасианс Пример за метода на планиране на покер

Има няколко причини да разглеждаме метода Scrum не като настройка на съвременната PM доктрина, а като наистина революционен метод за управление на проекти. Едно от тях е отношението към описанието на работата по изпълнението на проектната задача от гледна точка на историите, което е противоположно на процесния подход на Д. Чампи и М. Хамър. Хората наистина мислят в картини. От една страна, трудно е да се съгласим, че човек не може да се страхува от загуба на недвусмисленото тълкуване на резултата от работата. От друга страна, ако се отдръпнете от натиска на задачите и погледнете на проблема от позицията на истинска ориентация към клиента на проекта, меките истории могат да направят повече, за да получите правилните резултати от задачата.

Стъпка 5 от алгоритъма на методологията Scrum

Разглеждайки стъпки 5 и 6, механизмите за изчисляване на динамиката на изпълнението, изоставането в спринта, датите на завършване на проекта и възможността за ускорение не са под съмнение. Всичко е доста очевидно. Трудностите в разбирането възникват по отношение на един въпрос: как в края на всеки спринт да се постигне визуално увеличение във функционалността на продукта? По отношение на проекти за разработка на софтуер това е напълно възможно. Но какво да кажем, например, при изпълнението на проект за въвеждане на система за бюджетиране по метода Scrum, където има много етапи на подготвителна работа, при които няма видимо увеличение на функционалността? Изглежда, че тази част от метода изисква допълнително потапяне.

Стъпка 6 от алгоритъма на методологията Scrum

Проблеми с активното действие в процеса

Третият процедурен блок на метода Scrum е изпълнението на дейностите. Под дейности имаме предвид действията на собственика на продукта, Scrum Master и целия Scrum екип за постигане на местни резултати от текущия спринт или проекта като цяло. Седмата стъпка от процеса на проектиране е противоречива. От една страна, говорим за доста работещи инструменти за колективна работа, осигуряващи високо ниво на публичност, комуникационна пълнота, видимост. Говорим за използването на Scrum дъски, стикери, диаграми за изгаряне на задачи. От друга страна, не само за мен, но и за много руски мениджъри е доста трудно да възприемат категорията щастие като елемент от управленската технология. Ще посветя цял раздел от статията на този въпрос.

Стъпка 7 от алгоритъма на методологията Scrum

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

Стъпка 8 от алгоритъма на методологията Scrum

На стъпка 9 от алгоритъма на метода Scrum се появява това, което ви притеснява и отново се връща към формулирането на задачите за спринта. В продължение на много години трябваше да култивирам убеждението, че контекстът на задачата на управлението на проекти предполага недвусмислеността на формулирането на резултата в смисъла на „постигнато – непостигнато“. Няма значение кой резултат се разглежда: задачата от най-високо ниво или декомпозираната. Във всеки случай ръководителят на проектната задача и отговорният ресурс трябва да бъдат лишени от възможността да манипулират неяснотата на формулировката.

Стъпка 9 от алгоритъма на методологията Scrum

Цикълът на спринта завършва с десетата стъпка, която е партньорска проверка на завършения спринт. Режимът на коучинг на взаимодействие с екипа на Scrum се включва отново в хода на оценка на напредъка на работата по задачите и търсене на подобрения. Руският манталитет винаги се характеризира с ценностни преценки с негативна конотация на неуспешни резултати и сривове. В този случай винаги трябва да се посочи „стрелочникът” – член на екипа на проекта, по чиято вина са настъпили загубите. По-ценни са принципите за приоритет на системната грешка над действията на участниците в Scrum процеса като субекти на проектна дейност и отказът от персонифициране на вината.

Стъпка 10 от алгоритъма на методологията Scrum

Scrum като код на антицинизма

Харесва ми метафората, представена в подзаглавието. Принадлежи на Джеф Съдърланд и в него има дълбоко чувство на цинизъм като важен порок на съвременния бизнес. Като цяло позицията на автора на метода Scrum със сигурност е искрена. Това е завладяващо. И по принцип не е лошо, че Съдърланд въвежда компонент на щастието в управленския контекст. Това се прави по американски начин. В същото време бих искал да разбера защо думата "щастие" и всичко свързано с нея в разглежданата революционна дизайнерска доктрина предизвиква вътрешен дискомфорт. Дали това е само субективно-лично възприятие, или е някакъв общ културен възглед за предложения подход?

Вие и аз най-вероятно си спомняме какво се случи в Русия в края на 90-те и началото на 2000-те години. Страната беше буквално залята от „нови богатства“ от цял ​​свят и главно от САЩ, излъчващи „истината“ за личния и корпоративния успех. Трябва честно да се каже, че подобни "разкрития" не минаха без следа, много бизнесмени възприеха ключовите аспекти на теориите за управление, донесени от Запада. Конкретно не посочвам курсове за обучение, авторски теории и изявени школи. Който ги е преживял ще разбере.

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

Има бързо отрезвяване както на държавно ниво, така и на ниво бизнесмени. И те започват да разбират, че някои от въведените решения, начини за правене на бизнес, изграждане на взаимоотношения с персонала са не само полезни, те са служили на враждебни и разрушителни цели, водещи до разпадане на нашата национална култура, включително културата на управление. Ще дам един единствен пример за противопоставянето на две идеологии: "Разделяй и владей!" и "Думата на търговеца е по-ценна от договора!".

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

Горното не омаловажава достойнствата на метода Scrum, обсъден в статията. Ако премахнете завесата на абсолютизирането, подценяването и малко патос, това е доста работещ инструмент за дизайн. Новото винаги е трудно да си проправи път. Първо, това са високи идеи, след това това са изолирани примери и накрая идва период на масово приемане. Изглежда, че бъдещето принадлежи на хибридните алгоритми за провеждане на проектни дейности и гъвкавата вариативност в използването на традиционни и революционни подходи.