Днес в разработването на софтуер се използват много методологии. Може да сте чували модни думи като Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming и др.
В тази статия ще дефинирам тези термини, ще обсъдя как те са свързани помежду си и как се различават помежду си. Много от гореспоменатите модни думи се основават на концепции от Постно производство който първоначално се основава на Toyota Производствена система (TPS) така че първо ще говорим за това.
Терминът „постно“ води началото си от производството, където е създаден, за да опише производствен модел, базиран на производствената система на Toyota (TPS), първоначално разработена от Sakichi Toyoda, Kiichiro Toyoda и Taiichi Ohno, които първоначално са вдъхновени от Хенри Форд. TPS се фокусира върху философията на „пълното премахване на всички отпадъци“ и революционизира производството през 50-те до 70-те години. TPS стават известни като „Lean Manufacturing“ през 1990 г., когато „Машината, която промени света“ беше публикувано.
TPS идентифицира три широки вида отпадъци в Toyota:
Излишна обработка: от лоши инструменти или дизайн на продукта
TPS работи за премахване на отпадъците, като прилага следните две основни концепции:
С развитието на TPS тези основни стълбове и ценности са изградени върху концепциите за Джидока и JIT и се утвърди:
Диаграмата по-долу показва как основните понятия и основни ценности са свързани помежду си.
Продуктовата система на Toyota и Lean Manufacturing се развиха с течение на времето и бяха приложени в редица области, включително управлението.
Lean Management прилага основните ценности на непрекъснатото усъвършенстване и уважение към хората и ги дестилира в набор от пет предписани Lean принципа, които ще се повтарят няколко пъти за непрекъснато подобряване и елиминиране на отпадъците:
Тези принципи и други аспекти на Lean мениджмънта са формализирани, когато Womack & Jones публикуват „Lean Thinking“ през 1996 г.
Оттогава Lean се прилага за управление, разработване на софтуер и други области.
През 80-те и 90-те години индустрията за разработване на софтуер се приближаваше към криза, тъй като проектите, изпълнявани по традиционните методологии на водопада, отнемаха все повече и повече време. Това често води до огромно забавяне между идентифицирането на бизнес необходимост и доставянето на софтуерно решение. Понякога това изоставане се измерва в продължение на няколко години или дори в десетилетия в определени индустрии със специфични изисквания, като космическата индустрия.
По време на тези многогодишни срокове, изискванията, системите или дори целият бизнес се промениха. Често проектите биват анулирани частично или те ще завършат обхвата си, само за да установят, че това, което са доставили, вече не отговаря на бизнес нуждите, идентифицирани в началото на проекта.
The Методология на водопада възнаградиха заинтересованите страни за всичко, тъй като бяха принудени да напишат договор, въпреки че вероятно не бяха сигурни от какво се нуждаят. Методологията на водопада принуди решенията да се вземат по време на изискванията или фазата на проектиране и тези решения бяха много трудни за промяна, без да се променя договорът и да се добавят разходи към проекта. Голям процент от софтуерните проекти се провалиха напълно, или бяха доставени със закъснение и над бюджета, или не успяха да доставят необходимото.
Това общо разочарование доведе до различни лидери на мисли, които се опитваха да подобрят водопада. Ранните примери включват Бързо разработване на приложения (RAD) които се фокусираха върху намаляването на отпадъците чрез пряк път към изискванията и фазите на проектиране чрез бързо разработване на прототип и сътрудничество с бизнеса за по-нататъшно разработване на изискването. Имаше и ход към итеративно развитие, където беше завършен малък проект и бяха добавени функции в непрекъснати повторения. Въпреки че тези методологии помогнаха, те не разрешиха основни проблеми, свързани с водопада .
През 90-те и началото на 2000-те няколко автори публикуват книги за прилагане на Lean принципите при разработването на софтуер. Д-р Робърт Шарет публикува „Lean Software Development“ през 1993 г. и „12 принципа на постно разработване на софтуер“ през 2003 г.
Том и Мери Попендик публикуват „Lean Software Development: Agile Toolkit“ през 2003 г. Тази книга подробно описва седем принципа на Lean Development, които корелират пряко със седемте форми на отпадъци в Lean Manufacturing. Приликите и разликите между двете различни Lean публикации и Agile (обсъдени в следващия раздел) са изложени в диаграмата по-долу.
Според д-р Charette една от основните разлики между Lean и Agile е, че Agile е отдолу нагоре, докато Lean е отгоре надолу.
ЦелиLeant Software Development на Charette | Agile Manifesto | Lean на Poppendieck |
---|---|---|
|
|
Leant Software Development на Charette | Agile Manifesto | Lean на Poppendieck |
---|---|---|
|
|
|
Приблизително по същото време, когато Charette и Poppendiecks публикуваха своите книги, Agile Framework беше създадена, за да помогне за решаването на същите проблеми. През февруари 2001 г. група пъргави пионери се срещнаха на скандалната среща на Snowbird в Snowbird, Юта, за да се опитат да намерят решение.
Резултатът беше Agile Manifesto който изложи набор от ценности и принципи за методология, която се опитва да се адаптира към променящите се изисквания и нуждите на клиентите, да намали отпадъците и да осигури предимства по-бързо, използвайки постепенно итеративен подход.
Agile Manifesto гласи, както следва:
„Разкриваме по-добри начини за разработване на софтуер, като го правим и помагаме на другите да го правят. Чрез тази работа ние достигнахме до стойността:
Тоест, докато има стойност в елементите отдясно, ние оценяваме повече елементите отляво. '
Съобразени със стойностите в манифеста са 12-те принципа зад Agile Manifesto:
„Ние следваме тези принципи:
Горните стойности и принципи са приложения на Lean принципи като Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka и намаляване на отпадъците.
Agile е рамка, която се прилага за всеки процес, който прилага Agile набор от ценности и принципи.
Някои примери са:
Scrum е рамка, която прилага Agile принципи, измислена отделно от множество хора, няколко от които подписаха Agile Manifesto:
Schwaber и Sutherland си сътрудничат през 90-те години, за да разработят и усъвършенстват рамката в контекста на разработката на софтуер, като изказват на различни конференции. Schwaber работи с Майк Бийдъл, за да опише метода в книгата „Agile Software Development with Scrum“ през 2001 г.
Schwaber продължи да създава и двата основни органа за сертифициране на Scrum:
С течение на времето бяха създадени няколко рамки / сертифициращи органи, насочени към мащабиране на рамката на Scrum към по-големи екипи и проекти, тъй като Scrum първоначално беше проектиран за малки екипи (7 плюс или минус 2 члена):
Според Scrum Alliance:
Scrum е прост, но невероятно мощен набор от принципи и практики, които помагат на екипите да доставят продукти за кратки цикли, позволявайки бърза обратна връзка, непрекъснато усъвършенстване и бърза адаптация към промяната.
Scrum е предписателна, постепенна и итеративна рамка за разработване на софтуер, който прилага Agile принципите. Scrum стойностите и принципите са очертани в диаграмите по-долу и имат значително съответствие с Lean и Agile ценности и принципи.
Работата е разделена на кратки итерации, наречени спринтове, които обикновено са 1-3 седмици. Това е в пълен контраст с задълбоченото планиране на водопада. Планираната работа за текущия спринт се избира от горната част на приоритизирано изоставане на работни елементи, наречено Product Backlog (Pull System, Heijunka), и се фиксира след стартиране на спринта. Целта е в края на всеки спринт да има работещ софтуер, който позволява бърза обратна връзка.
В края на спринта екипът се среща, за да прегледа завършената свършена работа, как е преминал спринтът и да планира следващия спринт. Дължината на спринта, както и ритуалите и ритъма на спринта са фиксирани за всеки спринт.
Спринтовете се изпълняват от междуфункционални екипи, съдържащи всички умения, необходими за завършване на работата в спринта. Ежедневното планиране и проследяване на напредъка се извършва с помощта на визуални артефакти като scrum board и sprint burndown charts.
Работата в спринт е изтеглена от приоритизирано изоставане. Следването на тези методи дава възможност за промяна на изискванията във времето и насърчава постоянната обратна връзка от крайните потребители.
Диаграмата на умствената карта по-долу очертава някои от основните концепции на Scum, които ще бъдат обсъдени в следващите раздели.
Scrum има три роли:
Както беше обсъдено по-горе, Scrum има определен поток и набор от ритуали и дейности. Потокът на спринт е както следва.
Преди да започне спринт, Scrum Master улеснява среща с екипа на scrum и собственика на продукта, наречена среща за планиране на спринта, където собственикът на продукта идентифицира целите на предстоящия спринт, а след това екипът планира работата си според целите.
Това обикновено се прави със следните дейности:
Общият обем на работата или обхвата, поети за спринта, се измерва в сюжетни точки.
По време на спринта членовете на екипа изтеглят работни елементи (потребителски истории, задачи и т.н.) от горната част на списъка със задачи на спринта, за да работят. Различни членове на екипа ще работят по различните работни елементи или техните подзадачи. Те ще актуализират състоянието на елемент, когато е подходящо, като го преместят от една колона в следващата (обикновено За да направите> В процес> Тестване> Готово или някакъв негов вариант) на Scrum Board, докато не приключи.
Напредъкът се проследява с помощта на изгорена диаграма, която показва обема на завършената работа и оставащите измерени в сюжетни точки. Останалите точки са показани на оста Y, а оставащото време е показано на оста X. Графиката за изгаряне се актуализира, когато историите са готови.
Ежедневно Scrum Master се фокусира върху:
Ежедневен Standup
В началото на всеки ден в спринта, Scrum Master улеснява кратка 15-минутна среща с екипа на scrum и собственика на продукта, за да планира деня и да прегледа напредъка на спринта. Това е кратка среща, на която всички застават пред Scrum Board и всеки човек в срещата отговаря на следните въпроси за 2 минути или по-малко, позовавайки се на конкретни елементи на спринт борда:
Това позволява на всички да видят върху какво работят всички, да видят какъв напредък е постигнат или не, и да идентифицират пречките и / или необходимата помощ.
Scrum Master улеснява две церемонии за затваряне от спринта, преди да планира следващия спринт.
Демонстрация на спринт
В края на спринта Scrum Master улеснява демонстративна среща за спринт, където всяка завършена история се демонстрира на работещия софтуер на собственика на продукта и останалата част от екипа. Собственикът на продукта или ще приеме историята, ако са изпълнени всички критерии за приемане, или ще отхвърли историята. Ако дадена история бъде отхвърлена, недостатъците се идентифицират и историята се връща обратно в изоставането на продукта в приоритетния му ред, за да бъде завършена по-късно или изобщо не. Често частите от материал, които собственикът на продукта не приема, се разделят на отделни материали и оригиналната история се затваря.
Общият брой завършени сюжетни точки на спринт (скорост) се изчислява и спринтът се затваря. Скоростта се използва за проследяване на изходното ниво на екипа и се използва за оценка на това кога функции или версии ще бъдат завършени.
Ретроспектива на спринта
След демонстрацията на спринта, но преди следващата среща за планиране на спринта, Scrum Master улеснява ретроспекция на спринта, където екипът разсъждава върху току-що завършилия спринт и обсъжда какво е минало добре и какво не, за да могат непрекъснато и постепенно да подобряват процеса и качество във времето (Kaizen, Hansei). Има множество ретроспективни формати или упражнения, които могат да бъдат използвани, за да помогнат на екипа да генерира дискусия.
Изготвя се списък с елементи за действие за подобряване и понякога те водят до добавяне на елементи към изоставането на продукта, промени в DoD или устав на екипа и т.н.
Създаване на натрупвания на продукти
Преди да може да се планира или изпълни спринт, собственикът на продукта трябва да създаде изоставане в работата на продукта. Натрупването обикновено започва с елементи за разработка на функции, наречени истории, написани от собственика на продукта, и с течение на времето също се запълва със задачи за разработка или QA, пикове и дефекти и т.н., потенциално създадени от който и да е член на екипа. Всички елементи в изоставането са подредени в приоритетен ред.
Поддържане на изоставане
След като първоначалното натрупване на продукти е създадено и приоритизирано, непрекъснатият процес на подреждане на желязото поема. Целта е винаги да има най-малко достатъчно най-добрите елементи в изоставането, подредени и оценени, така че да са готови да бъдат изтеглени в спринт по време на среща за планиране на спринта. Това обикновено се прави чрез провеждане на редовни текущи срещи за подреждане на изоставането с продуктов мениджър и екипа, подпомогнат от Scrum Master.
Преди срещата на екипа се изпраща списък с истории, за да могат те да прегледат и да се подготвят за срещата. На срещата за подстригване всеки елемент се обсъжда по отношение на критериите за приемане, сложността, риска, размера, стратегията за изпълнение и др. Критериите за приемане и други подробности от историята се преглеждат и преразглеждат, докато екипът, собственикът на продукта и Scrum Master имат общо разбиране за историята. В този момент историята се изчислява в сюжетни точки, използвайки техника, наречена планиране на покер.
Оценка на историята
Историческите точки са единица усилия, която използва относително оразмеряване, където историите се сравняват с предишни, известни, добре разбрани произведения. Винаги задавате въпроса „тази история е по-голяма, по-малка или приблизително със същия размер“ като някоя друга работа.
Скалата на Фибоначи (1, 2, 3, 5, 8, 13, 21 ...) е най-често използваната скала, при която всяка стъпка е приблизително два пъти по-голяма от предишната (т.е. история с пет точки е повече или по-малко два пъти голям като история с три точки). Понякога се използват и други везни като размери на тениски (XS, S, M, L, XL) или дори риби (мино, златни рибки, пъстърва, риба тон, кит и др.). Всяка скала, която ви позволява да сравнявате размера на нещо спрямо друго, ще работи.
Историческите точки представляват цялостните усилия на екипа да приложи история, включително разработка, тестване, проектиране и други различни задачи, необходими за Дефиницията на Готово. Оценката отчита обема на работата, сложността и риска. След като се определи относителният размер на историята, като оценка се определя размер на скалата.
Екипите се подготвят за процеса на оценка на сюжетни точки, като първо установят базова линия за оценка, като избират „най-среден” разказ, който целият екип разбира като референтен разказ. Избрани са и някои допълнителни справочни материали, които са все по-големи и по-малки.
Оценката на сюжетни точки се прави по време на срещи за подстригване и понякога по време на планирането на спринта с помощта на Planning Poker:
Предимствата на оценката на историята са:
Публикуване на оценка и проследяване
Оценката на точката на сюжета също се използва в контекста на планирането на изданието, като се използва следната техника:
Оценките на историята за всички истории в дадено издание, комбинирани със скоростта на екипа, ще ви позволят да прецените кога дадено издание ще бъде завършено и да проследите напредъка му. Това често е показано в таблица за изгаряне на издание.
Основното предимство на Scrum е приложението на Agile ценности и принципи, както и на Lean концепции като Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System и Iterations. Прилагането на тези принципи позволява на екипите на проекта да получават непрекъсната обратна връзка, бързо да се адаптират към променящите се изисквания и несигурност, да намаляват отпадъците, да увеличават видимостта и прозрачността и да се стремят към непрекъснато подобряване. Винаги като се фокусира върху най-важните елементи в изоставането на продуктите и работи само на кратки итерации, които винаги произвеждат работещ софтуер, Scrum е по-фокусиран върху клиентите и позволява на клиентите да видят какво им харесва (и не им харесва) и да правят промени при нужда. Режийните разходи по отношение на процеса и управлението са по-малки, което води до по-бързи и по-евтини резултати.
Scrum е чудесна методология за проекти с изисквания, които не са ясно известни и / или се очаква да се променят. Това се отнася за повечето проекти. Scrum също е чудесен за опитни, мотивирани екипи, тъй като позволява на екипите сами да организират работата си и осигурява видимост, прозрачност и отчетност както за напредъка, така и за проблемите. Всичко това ще доведе до това екипите да се подобрят и да станат по-продуктивни с времето.
Scrum има някои недостатъци и не е най-добрата методология в някои ситуации:
Kanban е по-лек процес, който прилага много от стойностите на Lean и Agile, както и подмножество на Scrum стойностите и принципите, но има и някои основни разлики. Kanban се фокусира върху визуализацията, потока и ограничаването на текущата работа.
Kanban е японски за „табела“ или „билборд“. Линейните работници на Toyota използваха канбан (т.е. действителен борд), за да сигнализират за допълнителен капацитет в различни стъпки от производствения си процес. В софтуера това се прави с дъска Kanban, която много прилича на платката Scrum. Има приоритизирани изоставания от задачи и вертикални колони за всеки статус, който може да има работен елемент. Подобно на Scrum, работните елементи се преместват от един статус в друг; в Kanban обаче количеството незавършена работа е строго ограничено до максимален брой елементи във всеки статус въз основа на капацитета на екипа. Нова работа не може да бъде изтеглена, докато съществуващата не бъде преместена към следващата стъпка в процеса. В Scrum, незавършената работа е косвено ограничена чрез контролиране на обема на работата, планирана за спринт.
В Kanban няма фиксирани итерации или спринтове, просто постоянен поток, при който работните елементи се изтеглят от един етап на следващия. Това означава, че дъската Kanban никога не се нулира. Това също означава, че много от Scrum ритуалите не се използват. Екипите на Kanban често имат ежедневни срещи за изправяне, но те не са предписани. Няма редовно планирани срещи за планиране на спринт, демонстрации на спринт или ретроспективи на спринта, така че процесът е по-лек. Някои от дейностите в тези ритуали могат или не могат да се извършват на неформално ниво. Непрекъснатото усъвършенстване се постига чрез проследяване и анализ на потока от елементи от едно състояние в друго и извършване на постоянни допълнителни подобрения въз основа на разкритите проблеми.
Kanban също не предписва ролите, които Scrum изпълнява. Единствената необходима роля е ролята на член на екипа, но често има Ръководител проект който управлява екипа и изоставането. Често една дъска на Kanban може да обслужва множество функции и / или екипи, базирани на функции, които работят само върху елементи в определен статус. Например, екип за разработка може да изтегли елементи от „Завършване“ към „В процес“ и да ги премести в „Тестване“, а тестовият екип може да тества елементи в „Тестване“ и да ги премести в „Готово“.
Много от дейностите по управление на изоставането за определяне на приоритети и поддържане на работни елементи все още трябва да бъдат извършени, за да се гарантира, че даден работен елемент е добре разбран и готов за работа, но оценката на работните елементи се предписва като незадължителна.
Следващата таблица сравнява Scrum и Agile:
Канбан | Scrum |
---|---|
Непрекъсната доставка | Спринтове с времева кутия |
По-малко процес и режийни разходи | Предписал е ритуали и роли на Спринт |
Фокусира се върху бързото попълване на отделни елементи | Фокусира се върху бързото изпълнение на една партида работа |
Измерва времето на цикъла | Измерва скоростта на спринта |
Фокусира се върху ефективния поток | Фокусира се върху предсказуемостта |
Ограничава WIP за отделни артикули | Ограничава WIP на ниво спринт |
Изтеглят се отделни работни предмети | Работата се извършва на партиди в Sprint Planning |
Няма предписани роли | Има предписани роли (Scrum Master, собственик на продукт, член на екипа) |
Kanban Board може да бъде организиран около един многофункционален екип или множество специализирани екипи | Scrum Board е организиран от единен многофункционален екип |
Промените могат да се правят по всяко време -> по-гъвкави | Промените са разрешени само в изоставането на продукта. Не се допускат промени в спринта |
Изисква по-малко обучение | Изисква повече обучение |
Добре за екипи, където са необходими само допълнителни подобрения | Добре за екипи, където са необходими фундаментални промени |
В тази част разгледахме няколко от най-популярните методологии, използвани за разработване на софтуер. Досега трябва да разбирате добре Lean, Agile, Scrum и Kanban и техните исторически корени в Lean Manufacturing и TPS. В следващата част от поредицата ще продължим да преглеждаме и сравняваме други методологии за разработване на софтуер като Водопад , JTBD , и БЕЗОПАСНО (и други рамки за мащабиране), както и хибридни методологии, така че всички те са удобно обяснени на едно място.
Agile е рамка, която се прилага за всеки процес, който прилага Agile набор от ценности и принципи. Някои от примерите са: Екстремно програмиране, Scrum и Kanban.
Scrum е прост, но невероятно мощен набор от принципи и практики, които помагат на екипите да доставят продукти за кратки цикли. Scrum е рамка, която прилага Agile принципи, която е измислена отделно от множество хора, няколко от които подписаха Agile Manifesto.
Kanban е по-лек процес, който прилага много от стойностите на Lean и Agile, както и подмножество на Scrum стойностите и принципите, но има и някои основни разлики. Kanban се фокусира върху визуализацията, потока и ограничаването на текущата работа.