3 клопки на Scrum и как да ги поправим

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

Снимка на Ранди Фат на Unsplash

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

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

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

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

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

Провеждайте полезни ежедневни срещи за стенд-ап

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

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

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

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

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

PS Ако сте мениджър в тази история, знам, че е трудно да се отрежете от срещата. Още по-трудно е членовете на екипа да поискат отсъствието ви. Може би обсъждането на това с вашия екип и изпробването на срещи без мениджър за кратък период от време може да бъде добър начин за измерване дали срещата става не по-продуктивна без вас.

Снимка на Роб Хампсън на Unsplash

Не затлъстявайте над потребителската стойност

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

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

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

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

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

Не приемайте оценки за Евангелието

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

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

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

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

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

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

Докато екипите наистина стават по-добри в оценяването на работата във времето, винаги имайте предвид, че и най-малките неща могат напълно да отхвърлят оценката. Реалната стойност е в действително свършената работа, а не в това дали оценката е била правилна или не.

заключение

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

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

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

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

Най-добрият начин за разработване на софтуер е начинът, който работи за вашия екип. Съсредоточете се върху това. Забравете останалото.