Хората създават продукти. Това са хората, които пишат софтуер. Все още хората трябва да си сътрудничат и да повтарят, за да създадат нещо ценно. Гъвкавият манифест подчертава факта, като заявява „Индивиди и взаимодействия върху процеси и инструменти“. Това е напомняне. Трябва да поставим ударението върху индивидите и взаимодействията, а не върху процеса и инструментите.
Видяхме различни идеи, методологии и рамки да се появяват около Agile и научихме няколко неща по пътя. Agile е основният начин за създаване на софтуер в наши дни. Но имаше и много критики и негативни нагласи към него, по-точно, най-вече срещу Scrum. Scrum е основната Agile рамка, така че очевидно ще има много мнения, точно както при всеки широко разпространен инструмент, рамка, език за програмиране и т.н. Все пак изглежда, че има разминаване между теорията и реалността.
На теория Scrum е рамка, която идва лека с няколко дефиниции на роли, формати на срещи и идеи на високо ниво как да управлявате вашия продукт. На теория.
Реалността изглежда различна, много различна всъщност дори вътре в екип или компания. Собственици на продукти, scrum майстори, разработчици, мениджъри, всеки изглежда има различен опит или мнение за Scrum. Разработчиците изглежда имат най-големите проблеми със Scrum, прочетете например „това“, „това“ и „това“. Всички публикации имат валидни аргументи плюс това са опит от реалния свят. От тази гледна точка Scrum не успя да постигне или — за да бъдем по-точни — хората, внедрили Scrum, се провалиха. Гъвкавостта, внедрена по начин, който набляга на ритуали, артефакти, изгаряне на диаграми и отчитане, пропуска смисъла на „да си гъвкав“. Всичко това е процес. Но не забравяйте, че става дума за „хората над процеса“, така че каква роля играят хората в това уравнение? Очевидно проблемът не е само в Scrum, но и в хората. Хората прилагат Scrum. Другият проблем, който виждам, е, че имаме нужда от по-добри отговори на тези проблеми. Някой е имал или има много негативен опит с Agile/Scrum/XP/…. Какъв съвет можем да дадем? Най-често това е най-вече една от следните реакции:
а. „Scrum е единственият начин за създаване на софтуер. Не правите достатъчно Scrum. Трябва да го направите според книгата.”,
b. „Agile или Scrum са ужасни.“
° С. „Agile или XP, или Scrum имат няколко добри идеи, нека създадем нова методология, която съчетава всички добри идеи и добавя нови идеи и правила, докато сме там.“
С. или b. са общите отговори. Това явно е преувеличено.
Изглежда има много погрешно схващане какво означава Agile, agile, Scrum или XP. Коя книга всъщност имат предвид всички? Има редица отлични книги по темата и още по-голям брой книги, пълни с подходи „един размер за всички“. Някой чел ли е Extreme Programming Explained напоследък? Все още има страхотни идеи. Така че, когато някой хвърли аргумента „направи го според книгата“, може би е по-добре да каже прочетете ръководството за scrumили прочетете книга за XP . Много от тези преживявания със Scrum, XP и т.н. идват от външни консултанти или някой треньор или може би някой вътрешно въвеждащ Agile framework. Така че чуваме аргументи, според които XP или Scrum казват, направете това или онова, докато очевидно същите хора, които правят твърденията, не са чели никакви книги, манифеста или по друг начин са се заровили по-дълбоко в основните основи.
Грешка на разработчиците ли е, че тя или той смята, че да си гъвкав означава, че трябва да сменяш екипи на всеки 8 седмици или че трябва да докладваш на scrum master по време на стендъп? Същото важи и за сюжетни точки, ретроспективи на игри за обвиняване и дълъг списък от други често срещани проблеми със Scrum. Когато една компания цени твърдението, че „прави гъвкаво“ пред насърчаването на гъвкаво мислене, тогава не можете да обвинявате разработчиците, че са загубили мотивация. И мотивирани индивиди става въпрос за всичко, помните ли?
Изграждайте проекти около мотивирани личности.
Осигурете им средата и подкрепата, от която се нуждаят,
и им се доверете, за да свършат работата.
Може би трябва да се връщаме към гъвкавия манифест по-често. Това е разумно, всичко е свързано с ценности и много недогматично. Все още е валиден.
Трябва да помним, че всичко зависи от хората в края на деня. Опитен екип от разработчици ще достави, при всяка методология. Твърдението „Agile ще реши всичките ви проблеми“ е маркетинг, но предполагам, че повечето ще се съгласят с факта, че Scrum може да бъде много полезно въведение за преминаване към територията на гъвкавостта. От друга страна cargo-cult Scrum също е нещо истинско.
Ето някои точки, които съм записал, за които може да се наложи да помислите повече. Моля, чувствайте се свободни да критикувате или разширявате, в случай че видите нещо липсващо, или ме уведомете дали може да греша в единия или другия аспект.
На коя книга трябва да се позоват хората, когато бъдат помолени да го направят „по книгата“?
Или спрете да твърдите, че трябва да се прави „по правилата“, или дайте шанс на екипа да разбере основните принципи. Всички замесени знаят ли какво всъщност означава „по книгата“?
Каква роля играе техническото съвършенство?
XP има силен фокус върху този аспект, докато Scrum има много силен фокус върху бизнеса. Scrum без аспекта на техническо съвършенство е по-малко ефективен, може би дори неефективен.
Повече внимание върху разработчиците. Много книги за „Agile“ говорят за управление
Спрете да наричате разработчиците „само част от екипа“. Виждал съм това в няколко публикации и книги. Разработчиците са толкова целева аудитория, колкото и мениджърите, scrum masters и собствениците на продукти. Това лошо. Нищо чудно, че никой не се интересува от разбирането на основните основи. Говорете и пишете на разработчиците, на борда на всички.
От какво се нуждае отборът? Как се чувства отборът
Отново същата точка като по-горе. Хората над процеса. Това важи особено за скръм майстори и консултанти. Екипът не е тук, за да улесни работата ви. Обратно е, трябва да сте сигурни, че разбирате хората, които съставят екипа. Всеки разработчик е различен, всеки екип е различен. Ще имате нужда от правилния scrum master, консултант за правилния екип. По-често, отколкото не, някой е избран да стане скръм майстор, без умения, но със сертификат. Можем да се справим по-добре от това.
Твърде много фокус върху лесните части
Артефактите и срещите са лесните части. Организирането на ежедневен стендъп е лесната част. Но тук е насочен по-голямата част от вниманието. Ограничихме ли времето това? Имаме ли публикацията? Трудните части са сътрудничеството между хората, разбирането как работи занаятът, как да се гарантира, че всеки може да превъзхожда технически, привличането на потребители на ранен етап и т.н. Всичко опира до хората. Хората създават продукти за хората. Не можете да научите това в двудневен семинар и не можете да разберете това, без да сте работили с или да сте били част от изпълняващи екипи за известно време.
Спрете да използвате аргумента „Това проработи за X — така че трябва да работи за Y“
Това е класика. Върви ръка за ръка с предишните две точки.
Объркващи аргументи. Противоречиви съвети
„Ние не оценяваме времето. Но ако историята има 13 точки, трябва да я разделим, тъй като ще отнеме повече от спринт, за да я приложим.“ Добавете измерване на скоростта въз основа на тези точки от историята. Сега какво? оценяваме ли времето, функциите или сложността?
Работещият софтуер е единственият показател.
Добре, така че защо е стъпката назад към въвеждането на показатели, подобни на отчетите, вижте диаграми за изгаряне например? Работещият софтуер е единственият показател, всичко останало са числа и диаграми — каква стойност или прозрения наистина добавят или дават тези показатели?
Проблеми с прозрачността.
Прозрачността може да доведе до микроуправление. Това е един от най-силните аргументи, изтъкнати от разработчиците. Прозрачността не може да бъде еднопосочна улица, тя трябва да работи и в двете посоки. Разработчиците придобиват представа за бизнеса и обратно.
Поще много може да се пише по темата. Това е само отправна точка. Ако имате отзиви или въпроси, моля, свържете се с twitter.
