Когато разработчикът на софтуер чуе новини за „нова JavaScript рамка“ или „нова IDE“, той не трябва да задава повече въпроси, за да изясни за какво става въпрос. Но ако чуе за „нова гъвкава рамка“, той вероятно ще направи кима на Омир-Симпсън, преструвайки се, че знае за какво става въпрос, но ще има един и само един въпрос: Какво, по дяволите, означава „пъргава рамка“?
В съвременната среда за разработка на софтуер все по-често чуваме думи като „пъргав“, „скрам“ и „канбан“ и те често се използват неправилно. В тази статия ще се опитам да обясня и да изясня някои от тези термини.
Пъргав
Ако искате да бъдете умен на тълпата, трябва да използвате думата „пъргав“ във всяко друго изречение, когато говорите за работния процес. Той има доста широк диапазон, не ви задължава да знаете много за темата, за която говорите, и е наистина хубаво прилагателно или наречие: „мислене пъргаво“, „пъргав подход“, „според гъвкавите принципи“. Но какво всъщност означава „пъргав“?
„Agile“ се отнася до „ гъвкава разработка на софтуер , ”Подходът към развитието, който следва гъвкави принципи. Но по дяволите са „пъргавите принципи?“ Погледни пъргавият манифест и в 12 принципа на пъргавината , които поставят основите на пъргавото развитие. От манифеста:
Индивиди и взаимодействия над процеси и инструментиРаботещ софтуер над изчерпателна документация
Клиентско сътрудничество над договарянето на договора
Отговаряне на промяната следвайки план
Agile принципите насърчават непрекъсната доставка на работещ софтуер, тясна комуникация между екипите и висока адаптивност към променящите се нужди. Ако следвате тези ценности и принципи в работата си, можете да кажете, че работите в пъргава среда. Така че гъвкавата разработка на софтуер не е методология, а просто набор от различни методологии, рамки и техники, които следват едни и същи принципи. Може да се каже, че „пъргав“ е рамка за мислене и вземане на решения.
Agile е рамка за мислене и вземане на решения.
Но защо е толкова важно да следваме тези принципи в нашата работа?
Манифестът и принципите са резултат от търсенето на най-добрите решения, които са се развили през десетилетията в отговор на предизвикателствата на разработката на софтуер. През 70-те, 80-те и 90-те години различни разработчици и екипи по целия свят експериментираха с методи на работа и подходи за решаване на проблеми, измисляха различни рамки и техники (като scrum и Extreme Programming) и дори стигаха до едни и същи паралелно идеи. И накрая, през февруари 2001 г., седемнадесет разработчици се събраха и намериха общите знаменатели за всички тези разнообразни идеи и опит. Така е създаден манифестът.
Agile Manifesto е резултат от различен опит и практически решения, възникнали през десетилетията.
Scrum
Ако говорите за „пъргави“ методи, без да знаете какво означават, може да се подхлъзнете и да кажете неща, които ще ви разкрият пред събеседника, който познава темата: „Scrum и други гъвкави методологии“.
Scrum не е методология , макар че всички сме чували, че се нарича по-често от броя на убийствата в Игра на тронове . Scrum няма да даде отговор на всеки въпрос и няма да ви предостави точната процедура за реагиране на всяка ситуация, с която се сблъсквате. И вероятно в резултат на тази неправилна интерпретация, повечето изпълнения на scrum също са погрешни: Екипите не получават стойност. Това води до може би най-глупавото твърдение за scrum: „Scrum не работи.“
Какво е скрам? Ръководството за Scrum определя scrum като:
„Рамка, в която хората могат да се справят със сложни адаптивни проблеми, като същевременно продуктивно и творчески доставят продукти с възможно най-висока стойност“.Така че е рамка , както и всяка друга рамка, тя може да бъде и редовно се използва по грешен начин. Ефективното използване на scrum изисква не просто възприемане на структурата, определена от scrum, но и дълбоко разбиране и признателност за пъргавите принципи в целия екип.
Scrum се състои от следните роли: Собственик на продукт, Scrum Master, Екип за разработка.
Съществуват и четири Scrum церемонии: Планираща среща, Ежедневен скрам, Sprint Review, Sprint Retrospective
И трите артефакта: Продуктово изоставане, Спиртно изоставане, Увеличаване на продукта.
Scrum проектите са организирани в редовни времеви рамки, които ние наричаме спринтове. Те обикновено продължават две седмици.
сметкоплан на софтуерна фирма
ДА СЕ Собственик на продукта отговаря за ръководството на насоките на проекта. Тъй като се определят нови задачи и функции, собственикът на прокуратурата ги добавя към изоставане на продукта. Спринтът започва с среща за планиране, където екипът за разработка избира задачите от изоставането, по които да работи, и планира как ще бъдат изпълнени. Това е последвано от разработка, по време на която екипът за разработки използва изоставането, за да проследява напредъка и се среща за ежедневната среща, за да синхронизира дейностите и да коригира плана, ако е необходимо. Резултатът от разработката трябва да бъде увеличение на продукта, нещо, което може да се приложи към продукта и да се освободи незабавно. В края на спринта, увеличението на продукта се представя на собственика на продукта при прегледа на спринта, където изоставането на продукта се увеличава, ако са необходими допълнителни промени. След това целият екип присъства на ретроспективата на спринта, където говори за работния процес и как той може да бъде подобрен.
Лесно е да се научи и разбере скрам, но е трудно да се възприеме. Има много причини, поради които тази рамка може или не е подходяща за даден проект. Често изисква много промени, не само във всекидневното развитие, но и в културно отношение. Scrum се вписва най-добре при разработването на сложни продукти, такива, които продължават дълго и които включват различни видове специалисти.
Защо scrum е толкова популярен и защо има предимство пред традиционния модел водопад? Казано по-просто, защото осигурява по-голяма стойност за даден продукт и клиенти. С „тежки“ методи като водопад изобилстват истории на ужасите, при които никой не вижда нищо от проекта в продължение на месеци. При скрам това не е възможно.
Scrum е всичко за стойност който се доставя на крайните потребители. Ако наистина използвате скрам, трябва да доставяте нещо ценно всеки спринт. Стойността може да бъде измерена и екипът също е принуден да инспектира пречките и да се адаптира, с цел да предостави повече стойност при следващата итерация.
В повечето софтуерни разработки ние не изграждаме небостъргач; не е нужно да подготвяме целия план, преди да започнем, и да се придържаме към него до края. Разработваме софтуер и имаме способността да се адаптираме към различни ситуации и да променяме изискванията на продукта по време на разработката. Дълго време много разработчици виждаха това като осмия смъртоносен грях, но от продуктова гледна точка това е огромна полза за оптимизиране на предсказуемостта и контрол на риска. Scrum е разработен около тази способност и нейното прилагане дава надежден и ефективен начин за справяне с необходимите промени.
Много техники се използват заедно със скрама: планиране на покер, програмиране на двойки, разработено чрез тест (TDD), поведенческо развитие (BDD) и други. Те всъщност не са част от скрама, а по-скоро съвместими техники. Един метод, често споменаван едновременно със скрама, е канбан и има много объркване относно това какво означават тези две неща във връзка помежду си.
Канбан
Когато говорите за scrum и kanban, един често задаван въпрос от тълпата ще бъде: „Кое е по-добре, scrum или kanban?“ И няма да знаете какво да отговорите, защото е като да сравните ябълки и портокали или да попитате: „Кое е по-добре, палачинки или бира?“ И двете са по-добри.
Kanban е прост метод, който се стреми към доставка точно навреме, като същевременно не претоварва членовете на екипа. Подобно е на scrum, тъй като целта е да се предостави максимална стойност в края, но е много по-гъвкаво от scrum.
Kanban не е изобретен от общността за разработка на софтуер. Всъщност той произхожда от производствените процеси в Toyota и има широко приложение в други сфери. Няма строги процедури, които трябва да следвате, и няма строг начин да прилагате и използвате канбан; това е по-скоро набор от принципи и практики и можете да избирате от тези практики, за да отговарят на вашите нужди. Но има една най-често използвана реализация на kanban при разработването на софтуер, която включва използването на дъска канбан , състоящ се от колони, представящи етапи от работата, и задачи.
Колоните представляват състоянието на дадена задача в процеса на разработване. Най-простият пример се състои от три колони: „Завършване“, „В процес на изпълнение“ и „Готово“. И така, задачите се добавят към „Завършване“, преместени в „В процес на изпълнение“, когато стартира разработката, и се считат за „Готово“ при преместване в последната колона. Но разбира се, може да е по-сложно:
Назад → Дефиниране на спецификация → Готов за разработка → Разработка → Преглед на кода → Тестване → Разполагане (→ Никой наистина не го използва → Напълно премахнат).
Всяка колона може да има подколони; например „Развитие“ може да бъде разделено на „Планиране“ и „Кодиране“; „Тестване“ може да бъде разделено на „Тестване на единица“ и „Интеграционно тестване“ и т.н. Ако е уместно, колоните могат да бъдат посветени на специалисти. Екипът определя колоните и етапите според своите нужди. Съгласно философията „дърпане“ задачите трябва да влизат в работния процес само когато търсенето за тях е непосредствено.
Целта на тази дъска е да визуализирайте работния процес , което е първата ключова практика в канбан. Всъщност канбан може да се направи изобщо без дъска! Това може да бъде прост списък със задачи в лист на Google с различни цветове на фона, показващи състоянието на задачата, или може да бъде диаграми на Гант, диаграми, таблици ... Може дори да е набор от кофи във вашия офис, където всяка от тях представлява състоянието на задачата и къде топките се използват като задачи. Просто визуализирайте работния процес и осигурете прозрачност на целия процес.
Друг важен принцип е да намалете размера на партидата на вашите усилия . Опростено, това означава да избягвате многозадачност. Това може да означава намаляване на обема на задачите, по които работите едновременно. Ако имате трима дизайнери в екип, екипът може да зададе максимален брой задачи в колоната „Проектиране“ на три.
Подобно на схватката, канбан също вижда екипа като най-важната фигура в процеса. Но това не предлага роли като scrum и можете да запазите съществуващите роли, за да избегнете промени в съществуващия процес. Същото означава непрекъснато усъвършенстване: Kanban обикновено ви насърчава да се учите и усъвършенствате непрекъснато, но не предписва конкретно събитие само за този процес, както прави ретроспективата на scrum’s Sprint
как да изградим raspberry pi 3
Кой да използвам?
Scrum и kanban не се изключват взаимно и не са наистина сравними. В схватката има определени роли, докато канбан казва: „Какво, по дяволите, запазете текущите си роли и отговорности.“ Scrum ще ви принуди да промените начина си на работа; kanban ви позволява да започнете със съществуващия процес. В scrum, рамката предписва ясен график за събития; в канбан нямате събития. И все пак те имат много прилики: И двамата са ценностно ориентирани, членовете на екипа са уважавани като „шефове“ на системата и по същество имат една и съща мисия: Непрекъснато да елиминират отпадъците и да премахват препятствията.
Но въпросът: „Какво трябва да използвам в моя конкретен проект и с моя конкретен екип?“ има много повече смисъл. Kanban не изисква толкова много от процеса и културните промени и в повечето случаи ще бъде по-лесен за възприемане, отколкото за сблъсък. Scrum, от друга страна, предлага значително повече структура за насочване на процеса, която може да елиминира голяма част от режийните, стига всички да са на една и съща страница.
Но красотата и на двете е, че и двете не са строг набор от правила. Нищо не ви пречи да избирате и да избирате най-добрите за вас елементи, като например ежедневна среща или преглед. И няма причина да не можете да включите канбан дъска в скрам.
Scrum се доказа като изключително ефективна рамка, когато целият екип го разбира добре. Според моя опит обаче ми е трудно да работя в борба с някои клиенти. Процесът и културните промени, необходими за правилното изпълнение на scrum, могат да бъдат твърде много (особено когато се занимавате с някой, който вярва, че създава нов Google!). От друга страна, канбанът е по-гъвкав и не принуждава хората да се променят. Някои автори също казват, че канбанът е добър път към пъргавината и предлага по-лесно прилагане на скрама. Други казват, че използването на скрам трябва да доведе до канбан в края.
Истината е, че всеки проект е различен и няма универсално решение. Като ръководител на проекти, от вас зависи да определите кое работи най-добре за вашия екип.
