Съвсем малко преди да започна да чета книгата на Джеф Съдърланд разбрах въобще какво е методологията Scrum. Естествено е, че няколкото обяснения и търсения в Google ми дадоха общо въвеждащо познание, но това не ми се стори достатъчно. Самият процес по разработване на каквото и да е изисква внимателно планиране и усърдна работа. Но едва ли съм си давал сметка колко изискващо и сложно е, когато става дума за големи проекти. Признавам си, че мащабите ми са убягвали до този момент, не съм разбирал цялостно как стоят нещата. Затова и се впуснах в дълбокото, исках да разбера перспективата и смисъла за работата по такъв проект – Какво е това, което дава силата и възможността да наречем разработката ефективна? Какви са премеждията и защо въобще трябва да говорим за Scrum? Впускам се в дълбокото сега с тази страхотна книга по темата.
Първата глава (“The Way the World Works Is Broken”) започва с актуален пример от близкото минало, илюстриращо реален казус. Информационната система на ФБР има нужда от сериозно подобрение, така че да се впише в изискванията на сегашното време. Сложността и трудностите по нейното използване не само забавят работата на федералните служители, но също и изобщо не се вписват в дефиницията на това, което ние наричаме „съвременна среда“. Нейният заместник така и не проработи, това е било просто повод да бъдат изхарчени парите на данъкоплатците.
Това, което се е случило е, че разработчиците, които са спечелили договора за изработка на софтуер, реално са запланирали системата чрез алгоритмичния модел, наречен водопад – при него всеки един проект се планира в конкретни фази: проучване, дизайн, разработка и тестване. Но реално цялата тази сложност предизвиква едно: големи поръчки и сложен софтуер по-скоро биват забавяни в тяхната разработка. Логиката е, че може да се случи огромно забавяне на всяка една стъпка. Това довежда и до идеята за Scrum. Разделението между традиционната (водопадна) методология и Scrum се отстоява по отношение на пестенето на време и усилия. Scrum търси отговор на въпроса и задава метод на работа по отношение на това как работят хората, а не какво те казват, че работят.
Методологията залага не върху планирането и следването на консервативни и заложени процедури, а по-скоро върху творческото решаване на проблем. Екипите, които въвеждат някаква нова функционалност, изразяват не само какво са свършили, но също и по какъв начин. Полага се огромна грижа, за да се разберат какво реално води екипа към осъществяването на техните резултати. Интересното е, че смисъла на цялата идея може да се систематизира в една посока от точки:
- Когато се започва един проект е благоприятно често да се проверява прогреса към свършването на задачата.
- Полезно е да се знае дали предоставеното решение съвпада с това, което реално се изисква.
- Има ли някакви начини как целия процес може да бъде подобрен?
- Какво е това, което пречи или затруднява една задача да бъде свършена?
Главата продължава по-нататък с примера за системата на ФБР, давайки ни възможност да прегледаме проблемите от една малко по-различна от традиционната гледна точка. Как преценяваме проблемите и ги приоритизираме, кое е по-важното да се оправи, ако имаме много проблеми, а не знаем кое заслужава най-много внимание? Отговорът може би се крие в това кое носи най-голяма стойност към проекта?
Ключово в плавното разработване е контрола на „потока“ – създаването на нова функционалност или решаването на някакъв проблем трябва да се проследява, така че да няма съществени пречки. Ефективното справяне с проблемите може да бъде направено чрез работата в цикли – времево определени периоди, които да решават някакви задачи в рамките на това време. Логиката на тази организация е контрола по изпълнението и възможността за получаване на бърза обратна връзка. Идеята е, че в края на всеки цикъл (ако всичко е минало коректно) вече има произведена някаква новост или подобрение в рамките на продукта. Scrum е мощен инструмент, защото дава възможност да разберем как да работим по-добре, забележете, не като се работи по-дълго, а по-ефективно.
Направи ми впечатление, че възприетия подход за доказване на резултатите е гениално прост – екипите по разработка демонстрират в края на спринта какво са постигнали. Чрез презентирането на новата функционалност те реално могат да отчетат измеримо своя успех.
Въведението в тази глава не само обяснява за огромната сила на Scrum, но и задава един много важен въпрос – По какъв начин бихме могли да интегрираме този подход в нашата организация? Виждайки резултатите от примерите в тази глава наистина би си струвало поне да се опитаме.
Втората глава („The Origin of Scrum”) показват и част от личния живот на автора на книгата. Чрез житейските разкази разбираме как той е стигнал до някои от ключовите идеи за термини като Product Owner, Product Backlog и седмичните спринтове. Дава се и обяснението, че голяма и сложна разработка може да бъде разпределена на множество по-малки екипи. Показва се също, че ефективна стратегия е полагането на бонус система не на базата на индивидуалния принос, а на екипния прогрес.
Ценното за мен в тази глава бяха многото практически примери от реални компании, както и обяснения, давайки ми обяснението, че е важно да измерим и подобряване качеството на работата, което води до количествено по-голям успех.
Третата глава („Teams”) задава цялостно нова перспектива върху начина на организация на екипите по разработка. Оказва се, че е особено важно да разберем, че е важно да отчитаме груповите фактори на цялостната група, отколкото да следим индивидуалните възможности. Отново, множество изследвания и доказателства дават яснота, че е важно да дадем възможност на успешните отбори да ни зададат пример за работа. Именно тук е мястото, където се задават и характеристиките на някои от най-успешните екипи от света на реалния бизнес:
- Те са надминаващи – Екипите имат много по-ярко изразено чувство за смисъл от останалите. Тяхната гледка точка и заложена позиция е да бъдат не просто справящи се, но и да надмогват добрите резултати. Аз лично бих използвал думата „свръхмотивирани“.
- Те са автономни – Екипите имат възможността сами да решат как да управляват своите вътрешни процеси. Дава им се свободата да решат за себе си как ще решат възложените им задачи.
- Те са крос-функционални – Отделните екипи могат самостоятелни да свършат всички заложени задачи и изисквания. Отделните членове постоянно развиват своите умения и компетентности и могат да споделят наученото помежду си.
Ефективността на възможностите на даден екип по отношение на неговите възможности има все пак ограничения. Те най-явно се появяват при допълването на екипа, доказано е, че когато бройката на хора в един екип превиши 9 човека, тогава общата скорост на изпълнение спада. Доказва се по емпиричен начин, че 7 човека в един екип (в по-голямата част от случаите) е оптималния брой. Причините за това са две:
- Нужно е време да приравнят хората в екипа – Добавянето на нов човек означава той да бъде обучен и приведен до състоянието на ежедневна работа на всички, а това отнема време. Синхронизацията не винаги е лесна.
- Комуникацията става по-затруднена с повече участници – Необходимостта от комуникирането на идеи и готов продукт между участниците става много по-трудно, когато броя им е по-голям.
Въвеждането на фигурата на Scrum Master реално решава доста проблеми – той е този, който следи за спазването на методологията. Разграничава се от ръководителя и има по-скоро поддържаща функция. До този момент вече познаваме и основните движещи сили на Scrum итерацията: спринт, дневен stand-up, прегледи и срещи за ретроспекция. Всички те имат за цел да ни дадат конкретен фокус, и в крайна сметка, да ни доведат до успеха в края на спринта. Крайната цел при спазването на спринтовете е да ни доведе до отговорите на два въпроса:
- Какво може да променим по отношение на начина ни на работа?
- Какво ни забави през този период?
В четвъртата глава (“Time”) ни се представят размишления за нашия най-ограничен ресурс – времето. Тук реално се дава и практическата полза от това всеки един спринт да бъде в определени времеви граници – задават се правила за спазването на планираните задачи. Според моето разбиране за нещата това води и до създаване на много полезни навици, защото веднъж щом нещо е планирано в тези рамки, то тогава имаме измерими цели. Дневните срещи, които екипите използват, служат като контрол и отчет на свършената работа. Трите въпроса, които всеки си задава по време на тези кратки (15-минутни) сесии са следните:
- Какво свърши вчера, за да помогнеш на екипа да завърши спринта?
- Какво ще направиш днес, за да приключите всички успешно спринта?
- Какви пречки има в осъществяването на задачите?
Интересното за мен е това, че това решава един много съществен проблем, а именно комуникацията. Когато целият екип се събира и се докладва тази информация, тогава всички са наясно с това какво се случва. Така не се губи време всеки да се запознава индивидуално със свършеното до този момент от отделните членове. Някои от характеристиките на тези срещи имат и своите уникални специфики. На първо място, се премахват рамките на йерархичната структура – всички членове на екипите равнопоставено взимат участие. За целите на интегритета и равнопосочната комуникация, ако някой липсва от срещата, тогава тя не се състои: по този начин не се предава съобщението откъслечно само към определени членове на екипа.
Реално, групата от хора разсъждават не като отделни членове, а като едно цяло. По този начин и самите задачи се задават не от единствено, а от множествено число. Съвкупността от всички тези фактори водят до една изключително ефективна организация. Най-важното е, че този работещ модел може да бъде приложен във всяка една индустрия.
Петата глава („Waste is a Crime”) обръща специално внимание на важността за правилното разпределение на труда. Създаването и поддържането на работен режим в методология на Scrum е създадено на базата на естествените човешки потребности за навици. Хората са свикнали да работят на структурирани периоди, така че да има някаква предвидимост. Когато това се обвърже с работния процес, тогава имаме възможност да оптимизиране и на тази база.
Чрез емпирични подходи се доказва и позицията, че е по-добре да има краткотраен (или по-дълъг) фокус върху разрешаването на един частен проблем, отколкото да се работи по множество задачи. Загубата на енергия и разсейването може буквално „да убие“ продуктивността. А когато говорим за постоянни итерации, следване на план и въвличане в този планиран процес, е добре това да се избегне. Много полезното нововъведение за нас като читатели е термина „дефиницията на свършеното“ – би следвало итерацията да може да достави реално работеща функционалност към крайния продукт.
Тази глава също разисква и темата за физическото и ментално изтощение – преумората играе много важна роля, която често бива пренебрегвана. Множество примери от реалния свят показват колко е пагубно, когато един служител се измори. Той започва да допуска грешки и още по-лошото да изгуби фокуса. Именно затова следва да се спазват ограничителните времеви рамки и да не се излиза от тях. Научих за нов термин „изтощение на егото“ – взимането на каквото и да е решение изисква изчерпването на една единица енергия. Разбирам го като в компютърните игри – прекалено много изчерпана енергия ще доведе до умора и в крайна сметка няма да може да продължим напред.
Авторът идентифицира и няколко основни вида „боклук“, който затруднява екипите и, в крайна сметка, води до забавяне или невъзможност да се справят със зададените цели:
- Абсурдност – Поставянето на неизпълними и невъзможни цели в рамките на спринта.
- Невъзможни очаквания – Това се свежда до наблюдаването на т.нар. „героични постъпки“ – действията на един или двама човека от екипа, които успяват да „спасят“ спринта. Наличието на такъв тип случка генерално означава, че екипа реално разчита на отделни свои членове и те се явяват като незаменими.
- Претоварване – Това включва всякакви корпоративни политики, сложни доклади и други задължителни процедури, които затрудняват реалната работа.
Посочва се и четвърти допълнителен тип товар, който наричаме „емоционален“ и той се свързва с личните взаимоотношения в екипа. Типичен пример за такъв тип проблем е „надут“ мениджър или „токсична“ атмосфера вътре в екипа.
Шестата глава („Plan Reality, Not Fantasy”) разкрива повече подробности за това как може да се случи ефективното планиране, така че то да е успешно за организациите, опериращи по Scrum подход. Чрез дадените примери стигаме до заключението, че много често планирането става толкова подробно и приоритизирано, че то измества реалното изпълнение. Отнемането на огромно количество енергия (по смисъла на предишните глави за този термин) реално води до забавяне. Създаването на сложни и комплексни планове реално по-скоро би забавило цялостната работа. Затова и по тази методология е много по-добре цялостната задача е да бъде „разбита“ на по-малки „парчета“, които да бъдат решени в рамките на спринтовете.
Другата важна информация за мен в тази глава е разсъждението за това как хората възприемат някакъв план. Оказва се, че е много по-лесно да се мисли по различен начин. Разбираме плановете и това, което трябва да свършим, по-лесно като истории (сюжетни линии и наративи). По точи начин може да възлагаме и роли на конкретни персонажи, които имат определен тип взаимодействие и участие в рамките на историите. Тази концепция задава и възможност за открехването на по-творчески решения на проблемите, защото хората биха се почувствали и много по-комфортни, използвайки препратки, терминология и методи от разнообразни сфери.
В тази насока, ако използваме препратката с историите, би следвало да си зададем два въпроса, които да ни помогнат с цялостната подготовка и изпълнение на целевата задача: „Историята готова ли е?“ и „Как да разберем, че е готова?“. Предложението в тази насока е използването на мнемоника INVEST, давайки набор от критерии:
- Independent (Самостоятелен) – Историята трябва да може да бъде приключена самостоятелно и да не зависи от други такива.
- Negotiable (Договорен) – Докато бъде завършена трябва да може да бъде пренаписвана свободно, за да достигне крайната си форма.
- Valuable (Полезен) – Готовата история трябва да допринася с някаква реална стойност към крайния потребител.
- Estimable (Оценен) – Историята трябва да може да бъде преценена като обем, в съпоставка с други такива форми.
- Small (Малък) – Историята трябва да може да бъде толкова малка, така че да се впише в цялост в една итерация. Ако е много голяма, тогава тя би следвало да се „разбие“ в по-малки парчета.
- Testable (Проверен) – Цялата история трябва да може да бъде верифицирана за цялост.
В Scrum среда планирането се случва на специална среща, отредена за това. Тя е регулярна и се случва в началото на всеки един спринт. Всички участници в спринта се събират заедно и дискутират кои истории да влязат в новия спринт и по какъв начин те могат да бъдат решени. Важно уточнение е, че се прави и качествен преглед и на самите истории – дали те са достатъчно „готови“, за да бъдат включени, както и дали е практически възможно те да бъдат готови до края на итерацията.
Измеримата величина, която може да бъде наблюдавана, е скоростта на екипа. Тя е измерим фактор, който определя колко бързо работи екипа. Тази скорост се определя от формулата на завършените истории, събрани заедно с отредените им точки. Сравнението между скоростта на различните спринтове дава възможност на Scrum Master-а и екипа да разбере кой е фактора, който ефективно ги възпира от по-нататъшно ускорение.
Седмата глава („Happiness”) има важната роля да даде повече информация за това какво разбираме под термина „щастие“: според Scrum това включва не само крайните клиенти, но и всички „по веригата“, включително разработчици, мениджъри и т.н. Оказва се, че този (често неглижиран) фактор има огромен ефект върху цялостната разработка. Направените анализи и примери доказват, че щастливите и емоционално Необременени хора имат много по-висока продуктивност. Това означава, че повлиявайки (положително) върху емоциите на всички, ангажирани в разработката, бихме постигнали много по-добри резултати. Допълнително на това всичко това може да бъде измерено по емпиричен начин. Следователно, методологията има какво да допринесе.
Разбира се, когато става дума за производителност не е възможно да достигнем абсолютно нереалистични цели, трябва да бъдем реалисти. Затова и всички предложения за това какво може да подобрим реалистично и ефективно се дискутират в групата на Спринт ретроспекцията – специална среща, част от Scrum методологията. Авторът посочва два много важни фактора за една успешна сесия:
- Емоционална зрялост – Изразява се в това да се потърси логиката в процеса на извършената итерация. Ако някой някъде се е забавил или е допуснал пропуск, това не е мястото и времето да се поднасят критики. Взимането на отговорност не е индивидуално, а е групово, което в е контраст с традиционните практики.
- Доверие – Всеки участник има възможност да сподели, ако има някакви притеснения по отношение на следващите задачи. Това е времето, когато предложения могат да бъдат обсъдени и взети под внимание.
Друго интересно нововъведение в Scrum е възможността да използваме мерилото „Оценка на щастието“ – това е използването на кратък въпросник, за да оценим отношението на участниците в екипа спрямо спринта. Състои се от четири въпроса:
- В скала от 1 до 5 как бихте оценили Вашата роля в компанията?
- Използвайки същата скала какво мислите за компанията?
- Защо се чувствате по този начин?
- Кое е нещото, което би Ви накарало да се почувствате по-добре през следващия спринт?
Важното в този случай е всеки от екипа да е имал възможност изговорил това в рамките на групата. Всъщност, едно от важните моменти тук е да се стигне до конкретна идея за това какво може да се подобри и то да се включи в рамките на следващия спринт.
Много ключов момент е прозрачността – тя дава възможност да постигнем високо ниво на автономност, успех и следване на целта. В Scrum основополагаща черта е липсата на тайни канали, всичко трябва да е ясно видимо за всички, за да могат всички да бъдат разпознати в рамките на организацията. Това довежда и до създаването на т.нар. „Правило на слънчевата светлина“ – всички срещи са отворени за всички, записите на тези срещи да бъдат достъпни, както и да няма нищо скрито от дискутираното за определени лица.
Реално, възможностите за Scrum и организацията за работа се случва на „Таблото“, визуална репрезентация на това какво екипите работят. Категоризацията на елементите се прави най-основно в три групи: „Какво да се направи“, „Работа в момента“ и „Бъдещи задачи“. Една от целите на тази прозрачност е даването на възможност за контрол в реално време на случващото се. При ситуация, когато някой изпитва затруднения с неговата задача, друг би могъл да проследи това и да му помогне. По този начин се създава една доста по-добра организация от традиционните методологии.
Оказва се, че щастието на хората може да бъде насърчено и от самата организация. Дава се пример с компания, която създава т.нар. „корпоративна култура“, създавайки и подкрепяйки междуличностната комуникация между колегите. Компанията активно се опитва да премахне „бариерите“, които привидно поддържат строгата делова комуникация. Създаването на възможности за по-голяма близост и доверие води до по-малко стрес, следователно и до повече доволни служители.
Направи ми впечатление и една много важна подробност – организациите предпочитат да наемат хора вътрешно. По този начин се стимулира и кариерното израстване, дори и това да е обвързано с по-дълготрайно обучение или някакъв вид менторство. Това също създава едно високо ниво на доверие и помага на компаниите да задържат своите служители. Реално, голямата борба е да се повлияят служителите, така че да припознаят целите на компанията като собствени. Ако компанията прилича повече на семейство, отколкото на скучно задължение, тогава и отношението към работата се променя. Въпреки всичко е важно хората да останат реалисти, да могат реално да разберат доколко цялата тази формула е работеща.
В осма глава („Priorities”) може да намерите нещо много важно – определението за визия на продукта. Това е съвкупността от три фактора, които се срещат и се комбинират в общата картина. Визията разчита на възможностите за постигане, какво може да продадем на нашите клиенти и сферата, в която искаме да допринесем промяната. Особено важно уточнение е факта, че автора използва думата „страст“ – показва ни се, че трябва да имаме убедената вътрешна мотивация, така че да може максимално да разгърнем продуктовата визия.
Списъкът със задачи по Scrum е каталога на всичко онова, което е нужно да се направи, за да се постигне тази визия. Именно итерациите, които се явяват опитите за конструирането на финалния образ, са тези ,които „чистят“ този каталог. Разбира се, този набор постоянно бива обновяван и затова е нужно да се стигнат до безброй много успешни спринтове преди да има готов продукт на някакъв етап. Забележете, че не става дума за абсолютно финална версия – би следвало да се мисли в рамките на конкретни версии (вариации) на продукта, но той трябва да е напълно работещ и да отговаря на изискванията на клиентите. Именно затова и Scrum разчита толкова много на въведените по-рано дефиниции за завършеност. Приоритизирането е толкова важно, колкото и самото разработване.
В разработването на продукти важи доказаното правило „80% от стойността се намира в 20% от възможностите“—това означава да разработим първо най-търсеното и често използвано от клиентите като функционалност, след което да се насочим към останалата част от продукта. Прилагането на тази формула е един голям шанс за успех. В Scrum методологията има конкретна роля за човека, който е отговорен за визията и за определянето на печелившата формула – той се нарича Product Owner. Този човек е отговорен за „превеждането“ на продуктивността на екипа към реалната стойност. Има четири основни характеристики, които могат да се използват, за да се опишат неговите качества:
- Той трябва да е добре образован в дадената сфера на действие. Това означава до познава самия процес на работа в самите екипи. По този начин той може да проследи евентуалните спънки и да наблюдава прогреса по напредване със задачите. С познаването на пазара идва и точната преценка за това кое би било най-полезно и приоритетно.
- Product Owner трябва да бъде „овластен“ с правата и задълженията да взима свободно решенията за цялостната визия на продукта. Екипът може да взима решения по какъв начин да реши евентуалните проблеми, но те трябва да следват заложената визия.
- Product Owner трябва да бъде достъпен за екипа, той би следвало да може да обясни в подробности концепциите и идеите, които се въвеждат. Освен по работата по списъка със задачи, Product Owner изпълнява и задължения по отношение на разузнаване на конкуренцията и може да направи съпоставка между възможностите на собствения и чуждия продукт.
- Product Owner е отговорен за добиването на необходимата стойност в рамките на активната разработка.
Заложената цел на Scrum методологията е да даде работеща частица на съответния продукт, което дава възможност на Product Owner да направи реална оценка на придобитата стойност на пазара. Това означава, че той може с измерими (количествени и качествени) данни да прецени доколко е спазена формулата и е постигната задоволителна итерация.
Чрез множество примери се показва как работата на Product Owner-а е динамична и постоянна. Всеки един спринт променя реда на задачите, така че да се впишат оптимално във визията. С развитието на разработвания продукт се задават и нови цели ,които следва да бъдат изпълнени. Оказва се, че възможността за правилно приотиритизане е от наистина ключово значение.
Голямото предимство от създаването на „бързо оборотни версии“, които са в продължителна разработка е обратната връзка. Компаниите могат да проследят как клиентите реагират на нововъведенията и да преразпределят ресурсите си към определена функционалност или приоритет, така че да угодят максимално на техните потребности.
Последната глава (“Change the World) дава много любопитни примери как Scrum като подход се използва в най-различни ситуации, не само в сферата на разработката на софтуерни продукти. Много е любопитно как тази концепция се прилага от доста хора, а вероятно те дори и не подозират, че стъпват върху една доста ефективна и градивна теоретична концепция на работа. Една от основните цели на тази част от книгата е да „надъха“ читателите. Едновременно с това се стимулира съзнанието, така че да помислим и ние в какви ситуации Scrum би ни помогнало като стратегия на работа.
Книгата приключва с кратък апендикс, който дава бързи и лесни стъпки за въвеждането на Scrum подход. Макар и цялостното произведение да представя сложната методология под формата на разказ с примери, всичко е обяснено по лесен начин. Имах конкретната идея да разбера повече за методологията на съвсем базово ниво – след като оставих книгата почувствах, че съм цялостно обогатен. Препоръчвам я на всеки, който би искал да разбере как работят софтуерните разработчици по Agile методология. Но след прочитането разбрах и още нещо – силно я препоръчвам и на всеки, който иска да оптимизира своя собствен начин на работа. Книгата изобилства от полезни примери от буквално всички индустрии и сфери на живота. Благодарен съм за съветите. Успех пожелавам на всеки, който захване точно това заглавие. Чете се лесно и си заслужава. Наистина!