Пъргав
План за управление на проекти Част 1: Изчерпателно сравнение на Agile, Scrum, Kanban и Lean
Общ преглед
Днес в разработването на софтуер се използват много методологии. Може да сте чували модни думи като Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming и др.
В тази статия ще дефинирам тези термини, ще обсъдя как те са свързани помежду си и как се различават помежду си. Много от гореспоменатите модни думи се основават на концепции от Постно производство който първоначално се основава на Toyota Производствена система (TPS) така че първо ще говорим за това.
Lean методология
Произход на постно и постно производство
Терминът „постно“ води началото си от производството, където е създаден, за да опише производствен модел, базиран на производствената система на Toyota (TPS), първоначално разработена от Sakichi Toyoda, Kiichiro Toyoda и Taiichi Ohno, които първоначално са вдъхновени от Хенри Форд. TPS се фокусира върху философията на „пълното премахване на всички отпадъци“ и революционизира производството през 50-те до 70-те години. TPS стават известни като „Lean Manufacturing“ през 1990 г., когато „Машината, която промени света“ беше публикувано.
TPS идентифицира три широки вида отпадъци в Toyota:
- Млади: преведено като „отпадъци“. В Toyota бяха идентифицирани седем вида муда, а по-късно беше добавен и осми. Това са:
- Дефекти: усилие, свързано с откриване и отстраняване на дефекти
- Свръхпроизводство: производство преди търсенето
- Очакване: изчакване на следващата производствена стъпка, прекъсвания и т.н.
- Неизползван талант: недостатъчно използване на способностите, неадекватно обучение и др
- Транспорт: движещи се части или продукти, които не са необходими за обработка
- Материални запаси: завършен опис и незавършено производство
- Движение: придвижване или ходене повече от необходимото за обработка
-
Излишна обработка: от лоши инструменти или дизайн на продукта
- В: преведено като „открит товар“. Мури обикновено е резултат от мура, но може да бъде резултат от муда. Мури се проявява в аварии, отсъствия, проблеми с безопасността и т.н.
- Ако: преведено като „неравности“. Mura може да се намери в колебанията в търсенето на клиентите, времето за обработка на продукт или варирането на времената на цикъла за различните оператори. Когато мурата не е намалена, човек увеличава възможността за мури и следователно муда. Мура може да бъде намалена чрез създаване на отвореност във веригата на доставки, промяна на дизайна на продукта и създаване на стандартна работа за всички оператори.
TPS работи за премахване на отпадъците, като прилага следните две основни концепции:
- Джидока: свободно преведено като „автоматизация с човешко докосване“ предвижда, че „Качеството трябва да бъде вградено по време на производствения процес!“ което означава, че когато възникне проблем, оборудването спира незабавно, предотвратявайки производството на дефектни продукти.
- Точно навреме: Направете само „това, което е необходимо, когато е необходимо и в необходимото количество“.
С развитието на TPS тези основни стълбове и ценности са изградени върху концепциите за Джидока и JIT и се утвърди:
- Непрекъснато усъвършенстване:
- Предизвикателство: формиране на дългосрочна визия и посрещане на предизвикателства със смелост и креативност за реализиране на мечтите
- Кайдзен: непрекъснато подобряване на бизнес операциите, като винаги се стремим към иновации и еволюция, като елиминираме една муда наведнъж
- Генчи Генбуцу: практикуване на genchi genbutsu, отиване до източника, за да се намерят фактите, за да се вземат правилни решения, да се постигне консенсус и да се постигнат цели с най-добрата ни скорост
- Уважение към хората:
- Уважение: уважаваме другите и полагаме всички усилия да се разбираме, поемаме отговорност и правим всичко възможно, за да изградим взаимно доверие
- Съвместна дейност: стимулиране на личния и професионален растеж, споделяне на възможности за развитие и максимизиране на индивидуалните и екипните резултати
- Andon: визуален индикатор за състояние или проблем
- Хейджунка: означава изравняване или изравняване на производството
- Хансей: означава саморефлексия. За да подобрят ефективността, работниците трябва да оспорват предположенията зад текущите процеси, за да намерят по-добри.
- Канбан: табела, използвана като визуален инструмент за контрол на производството
- Пока-иго: Нарича се още доказателство за грешки или доказателство за грешки
- Система за изтегляне: Материалът се изтегля в работната станция точно както е необходимо
- Сейри: е принципът, който отразява отпадъците. Сейри диктува, че ненужното трябва да бъде премахнато. Това обхваща всички първоначални седем отпадъци от TPS
- Стандартизация: организира всички работни места около човешкото движение и създава ефективна производствена последователност без муда. Това помага да се постигне качество, постоянно темпо и позволява непрекъснато подобряване.
Диаграмата по-долу показва как основните понятия и основни ценности са свързани помежду си.
Lean Management
Продуктовата система на Toyota и Lean Manufacturing се развиха с течение на времето и бяха приложени в редица области, включително управлението.
Lean Management прилага основните ценности на непрекъснатото усъвършенстване и уважение към хората и ги дестилира в набор от пет предписани Lean принципа, които ще се повтарят няколко пъти за непрекъснато подобряване и елиминиране на отпадъците:
- Идентифицирайте стойност: Посочете стойност от гледна точка на крайния клиент по семейство продукти.
- Поток на стойността на картата: Идентифицирайте всички стъпки в потока на стойността за всяко семейство продукти, като елиминирате, когато е възможно, тези стъпки, които не създават стойност.
- Създаване на поток: Направете стъпките за създаване на стойност да се извършват в строга последователност, така че продуктът да тече плавно към клиента.
- Установяване на издърпване: С въвеждането на потока, позволете на клиентите да извлекат стойност от следващата възходяща дейност.
- Търсете съвършенство: Когато стойността е посочена, потоците от стойности се идентифицират, изгубените стъпки се премахват и се въвеждат поток и изтегляне, започнете процеса отново и го продължете, докато се достигне състояние на съвършенство, при което се създава перфектна стойност без отпадъци.
Тези принципи и други аспекти на Lean мениджмънта са формализирани, когато Womack & Jones публикуват „Lean Thinking“ през 1996 г.
Lean Разработка на софтуер
Оттогава 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 |
|---|---|---|
|
|
|
Agile Framework
Произход на Agile и Agile Manifesto
Приблизително по същото време, когато Charette и Poppendiecks публикуваха своите книги, Agile Framework беше създадена, за да помогне за решаването на същите проблеми. През февруари 2001 г. група пъргави пионери се срещнаха на скандалната среща на Snowbird в Snowbird, Юта, за да се опитат да намерят решение.
Резултатът беше Agile Manifesto който изложи набор от ценности и принципи за методология, която се опитва да се адаптира към променящите се изисквания и нуждите на клиентите, да намали отпадъците и да осигури предимства по-бързо, използвайки постепенно итеративен подход.
Agile Manifesto гласи, както следва:
„Разкриваме по-добри начини за разработване на софтуер, като го правим и помагаме на другите да го правят. Чрез тази работа ние достигнахме до стойността:
- Индивиди и взаимодействия над процеси и инструменти
- Работещ софтуер над изчерпателна документация
- Сътрудничество с клиенти над договарянето на договора
- Отговаряне на промяната следвайки план
Тоест, докато има стойност в елементите отдясно, ние оценяваме повече елементите отляво. '
Съобразени със стойностите в манифеста са 12-те принципа зад Agile Manifesto:
„Ние следваме тези принципи:
- Нашият най-висок приоритет е да задоволим клиента чрез ранна и непрекъсната доставка на ценен софтуер.
- Добре дошли променящите се изисквания, дори късно в разработката. Agile обработва промените, използвани за конкурентно предимство на клиента.
- Предоставяйте работещ софтуер често, от няколко седмици до няколко месеца, с предпочитание към по-краткия срок.
- Бизнесмените и разработчиците трябва да работят заедно всеки ден по време на проекта.
- Изграждайте проекти около мотивирани индивиди. Осигурете им средата и подкрепата, от които се нуждаят, и им се доверете, за да свършат работата.
- Най-ефективният и ефективен метод за предаване на информация до и в рамките на екипа за разработки е разговорът лице в лице.
- Работещият софтуер е основната мярка за напредък. Подвижните процеси насърчават устойчивото развитие.
- Спонсорите, разработчиците и потребителите трябва да могат да поддържат постоянно темпо за неопределено време.
- Непрекъснатото внимание към техническото съвършенство и добрият дизайн повишава пъргавината.
- Простотата - изкуството да максимизираш обема на несвършената работа - е от съществено значение.
- Най-добрите архитектури, изисквания и се появяват дизайни от самоорганизиращи се екипи.
- На редовни интервали екипът обмисля как да стане по-ефективен, след това настройва и коригира поведението си в съответствие с това. '
Горните стойности и принципи са приложения на Lean принципи като Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka и намаляване на отпадъците.
Подвижни принципи, приложени към разработването на софтуер
Agile е рамка, която се прилага за всеки процес, който прилага Agile набор от ценности и принципи.
Някои примери са:
- Екстремно програмиране
- Scrum
- Канбан
Scrum
Кратка история на измет
Scrum е рамка, която прилага Agile принципи, измислена отделно от множество хора, няколко от които подписаха Agile Manifesto:
- Hirotaka Takeuchi и Ikujiro Nonaka първоначално въведоха термина „scrum“ в производствен контекст в своята бяла книга „Играта за разработване на нов продукт“. публикуван през 1986 г. в Harvard Business Review.
- Джеф Съдърланд, Джон Скумниоталес и Джеф Маккена внедряват Скрам в статив на корпорацията през 1993 г.
- Кен Schwaber използва това, което ще стане Scrum в неговата компания, Advanced Development Methods през 90-те години.
Schwaber и Sutherland си сътрудничат през 90-те години, за да разработят и усъвършенстват рамката в контекста на разработката на софтуер, като изказват на различни конференции. Schwaber работи с Майк Бийдъл, за да опише метода в книгата „Agile Software Development with Scrum“ през 2001 г.
Schwaber продължи да създава и двата основни органа за сертифициране на Scrum:
- Scrum Alliance : създаден през 2001 г. Създайте Сертифициран Scrum серия за акредитация.
- Scrum.org : създаден през 2009 г., след като Schwaber напусна Scrum Alliance. Настройте паралела Професионален скрам серия за акредитация.
С течение на времето бяха създадени няколко рамки / сертифициращи органи, насочени към мащабиране на рамката на Scrum към по-големи екипи и проекти, тъй като Scrum първоначално беше проектиран за малки екипи (7 плюс или минус 2 члена):
- БЕЗОПАСНО : Scaled Agile Framework
- По-малко : Голям мащаб
- [имейл защитен] д: Scrum в мащаб, създаден от Джеф Съдърланд
Scrum Стойности
Според Scrum Alliance:
Scrum е прост, но невероятно мощен набор от принципи и практики, които помагат на екипите да доставят продукти за кратки цикли, позволявайки бърза обратна връзка, непрекъснато усъвършенстване и бърза адаптация към промяната.
Scrum е предписателна, постепенна и итеративна рамка за разработване на софтуер, който прилага Agile принципите. Scrum стойностите и принципите са очертани в диаграмите по-долу и имат значително съответствие с Lean и Agile ценности и принципи.
Преглед на Scrum
Работата е разделена на кратки итерации, наречени спринтове, които обикновено са 1-3 седмици. Това е в пълен контраст с задълбоченото планиране на водопада. Планираната работа за текущия спринт се избира от горната част на приоритизирано изоставане на работни елементи, наречено Product Backlog (Pull System, Heijunka), и се фиксира след стартиране на спринта. Целта е в края на всеки спринт да има работещ софтуер, който позволява бърза обратна връзка.
В края на спринта екипът се среща, за да прегледа завършената свършена работа, как е преминал спринтът и да планира следващия спринт. Дължината на спринта, както и ритуалите и ритъма на спринта са фиксирани за всеки спринт.
Спринтовете се изпълняват от междуфункционални екипи, съдържащи всички умения, необходими за завършване на работата в спринта. Ежедневното планиране и проследяване на напредъка се извършва с помощта на визуални артефакти като scrum board и sprint burndown charts.
Работата в спринт е изтеглена от приоритизирано изоставане. Следването на тези методи дава възможност за промяна на изискванията във времето и насърчава постоянната обратна връзка от крайните потребители.
Диаграмата на умствената карта по-долу очертава някои от основните концепции на Scum, които ще бъдат обсъдени в следващите раздели.
Scrum роли
Scrum има три роли:
- Scrum Master : Scrum Master е служител ръководител на Scrum екипа. Те са треньорът на екипа, който помага за улесняване на сътрудничеството, премахва пречките, налага и защитава Scrum процеса и защитава екипа. Това обикновено означава, че те организират и улесняват ритуалите на спринта, гарантират, че собственикът на продукта има правилно приоритизирани и поддържани изоставания, гарантира, че екипът не е притиснат да се ангажира със спринт, гарантира, че обхватът не се добавя към спринт, гарантира спазването на Определението за Готово. Те не възлагат задачи на членовете на екипа (Genchi Genbutsu) и не носят отговорност за изпълнението на проект
- Собственик на продукта : собственикът на продукта е „единичната извиваема врата“, отговорна за доставката на продукта. Собственикът на продукта определя визията на това, което иска да изгради, и предава тази визия на екипа и организацията. Собственикът на продукта притежава бизнес и пазарните изисквания и дава приоритет на цялата работа, която трябва да бъде извършена чрез създаване и управление на изоставането на продукта. Те решават кои характеристики да бъдат изпратени кога. Те работят с екипа и други заинтересовани страни, за да се уверят, че всички разбират елементите в изоставането на продуктите. Те приемат или отхвърлят работата, завършена в спринт в демонстрацията на спринт.
- Член на екипа : Екипът на Scrum е самоорганизиращ се, многофункционален екип, който обикновено се състои от пет до седем членове. Всички по проекта работят заедно и си помагат и не е задължително да имат различни роли като архитект, програмист, дизайнер или тестер. Всички завършват работата заедно. Екипът на Scrum планира колко работа може да завърши всеки спринт и притежава плана (Genchi Genbutsu).
Scrum поток, дейности и церемонии
Както беше обсъдено по-горе, Scrum има определен поток и набор от ритуали и дейности. Потокът на спринт е както следва.
Планиране на спринта:
Преди да започне спринт, Scrum Master улеснява среща с екипа на scrum и собственика на продукта, наречена среща за планиране на спринта, където собственикът на продукта идентифицира целите на предстоящия спринт, а след това екипът планира работата си според целите.
Това обикновено се прави със следните дейности:
- Капацитет на спринта: екипът определя капацитета за спринта, като взема предвид броя на дните, броя на членовете на отбора, празниците и т.н.
- Цели на спринта: собственикът на продукта определя какви са целите на спринта. От решаващо значение е натрупването на продукти да бъде приоритизирано в съответствие с целите (т.е. съответните истории са най-отгоре) и да се поддържа.
- Избор на работа: истории или задачи се изтеглят от горната част на изоставането в спринта, докато се достигне прогнозният капацитет. Докато историите се изтеглят, собственикът на продукта ще обясни историята и ще отговори на въпроси от екипа, като актуализира историята според нуждите, докато собственикът на продукта и екипът на Scrum имат добро, общо разбиране за историята. След като тази дейност приключи, екипът има предложен първоначален обхват на спринта.
- Разбивка на задачите: екипът на Scrum обсъжда подробно всяка история с акцент върху планирането как ще завършат историята и ще отговори на всички критерии за приемане и DoD. Те ще изготвят списък с подзадачи, необходими за завършване на историята. След като списъкът с подзадачи е завършен, оценката на историята се преглежда и актуализира, ако е необходимо.
- Ангажимент за спринт: след като всички истории са разбити и оценките са актуализирани, предложеният първоначален обхват на спринта се преразглежда. Историите могат да бъдат премахнати от спринта и да бъдат върнати в изоставането и / или могат да бъдат добавени допълнителни истории. След като това бъде направено, САМО екипът на Scrum (а не Scrum Master или собственикът на продукта) се ангажира да завърши работата в спринта и спринтът започва.
Общият обем на работата или обхвата, поети за спринта, се измерва в сюжетни точки.
Изпълнение на спринт
По време на спринта членовете на екипа изтеглят работни елементи (потребителски истории, задачи и т.н.) от горната част на списъка със задачи на спринта, за да работят. Различни членове на екипа ще работят по различните работни елементи или техните подзадачи. Те ще актуализират състоянието на елемент, когато е подходящо, като го преместят от една колона в следващата (обикновено За да направите> В процес> Тестване> Готово или някакъв негов вариант) на Scrum Board, докато не приключи.
Напредъкът се проследява с помощта на изгорена диаграма, която показва обема на завършената работа и оставащите измерени в сюжетни точки. Останалите точки са показани на оста Y, а оставащото време е показано на оста X. Графиката за изгаряне се актуализира, когато историите са готови.
Ежедневно Scrum Master се фокусира върху:
- Улеснява ежедневното заседание за планиране на деня и преглед на напредъка (виж по-долу)
- Гарантира, че екипът има план за деня
- Премахва пътните блокади
- Предпазва обхвата на спринта и екипа от разсейване
- Помага на екипа да поддържа своята изгорена диаграма и други статистически данни за Scrum
Ежедневен 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:
- Всеки член на екипа / оценител има набор от карти.
- Елементите на изоставането се обсъждат един по един, както е описано по-горе.
- След като елементът е обсъден изцяло, всеки оценител избира частна карта, която да представя тяхната оценка.
- Когато всички оценители направят своите оценки, те разкриват картите си едновременно.
- Ако всички оценки съвпадат, оценителите избират друг елемент на изоставане и повтарят същия процес.
- Когато оценките се различават, оценителите обсъждат въпроса, за да стигнат до консенсус.
Предимствата на оценката на историята са:
- Бързо: приблизителните оценки са спрямо вече попълнени елементи на изоставане на продукти.
- Достатъчно точно: достатъчно точен, за да даде преглед на обхвата, да планира бъдеща работа, да даде приоритет и да управлява очакванията.
- Обхваща несигурността: Точките на историята посочват неизвестен времеви диапазон. Изборът от конкретна подобна на Фибоначи поредица от сюжетни точки позволява улавяне на несигурност.
- Отборен спорт: Включва всички (разработчици, дизайнери, QA, продуктови мениджъри). Използва множество перспективи за определяне на размера на работата, но само членовете на екипа, които извършват работата, могат да оценят
- Измерва скоростта на екипа: измерва колко работа върши екипът в спринт спрямо количеството време, прекарано в работата. Тъй като екипът се подобрява, те ще завършват истории със същия размер по-бързо, което води до по-висока скорост на точката на историята с течение на времето.
Публикуване на оценка и проследяване
Оценката на точката на сюжета също се използва в контекста на планирането на изданието, като се използва следната техника:
- Избройте всички истории, които трябва да бъдат оразмерени
- Поставете ги в ред от най-малките до най-големите
- Вземете първата и втората потребителска история.
- Решете кое е по-голямо и сложете по-голямото отдолу
- След това вземете следващия и решете къде се побира спрямо другите два
- Повторете процеса, докато всички истории вече не са в списъка (в последователност от най-малката до най-голямата)
- Оразмерете историите
Оценките на историята за всички истории в дадено издание, комбинирани със скоростта на екипа, ще ви позволят да прецените кога дадено издание ще бъде завършено и да проследите напредъка му. Това често е показано в таблица за изгаряне на издание.
Архитектите и условията на Scrum
- Натрупване на продукти: Списък с изоставане на всички работни елементи за даден продукт, който може да включва функции (истории), технически задачи, скокове и дефекти
- Освобождаване от изгаряне: Графична диаграма, използвана за показване на напредъка на ниво на издание и за предсказване кога дадено издание ще бъде завършено, използвайки Sprint Velocity. Изпълнените сюжетни точки са показани на оста Y, а спринтовете - на оста X.
- Спиране на спринта: Списък на изоставането на всички работни елементи, които трябва да бъдат завършени в даден спринт. Съдържанието на изоставането в спринта се договаря по време на срещата за планиране на спринта.
- Scrum съвет: Таблица в стил маса, която проследява напредъка на работата, извършена за спринта. Статусите се показват отгоре във вертикални колони и работните елементи се преместват през всяко състояние, докато приключат. Scrum дъската се попълва по време на срещата за планиране на спринта и се нулира в края на спринта.
- Sprint Burndown: Графична диаграма, която показва обема на завършената работа и оставащите измерени в сюжетни точки по дължината на спринта. Останалите точки са показани на оста Y, а оставащото време е показано на оста X.
- Скорост на спринта: Броят сюжетни точки, които екип на Scrum попълва в спринт.
- Натрупване на пречки: Списък на пречките, които трябва да бъдат отстранени от Scrum Master, за да може екипът да продължи да работи. Когато член на екип бъде блокиран, той ще добави елемент към изоставането на пречките, за да осигури видимост на екипа и Scrum Master.
- Епичен: Епопеята е обширно произведение, състоящо се от множество свързани потребителски истории.
- Потребителска история: Потребителска история е описание на софтуерна функция от гледна точка на крайния потребител. Историята на потребителя описва типа потребител, какво иска и защо. Потребителска история помага да се създаде опростено описание на изискване и включва критерии за приемане. Потребителските истории се създават и поддържат от собственика на продукта.
- Задача: Задачата е работа, която е въведена от Scrum Master или член на екипа, която може да бъде пряко или косвено свързана с потребителски истории. Те обикновено имат технически характер и ще включват критерии за приемане.
- Спайк: Спайк е специален тип задача, която се използва, когато трябва да проучите, прототип и / или архитект по някое време, преди да можете да решите как да внедрите или изчислите потребителска история.
- Подзадача: Подзадача е задача, която се въвежда като стъпка за изпълнение към завършване на потребителска история или задача. Те обикновено се въвеждат от екипа по време на среща за планиране на спринт.
- Оценки на Story Point: Относителна скала за оценка на размера, която се основава на скалата на Фибоначи (1, 2, 3, 5, 8, 13, 21 ...)
- Критерии за приемане: Списъкът със специфични за историята, подлежащи на проверка елементи, включени във всяка история, която трябва да бъде попълнена, преди собственикът на продукта да приеме дадена история като завършена.
- Определение на Done (DoD): Списък на често срещаните стъпки или критерии, които трябва да бъдат изпълнени, преди дадена история може да се счита за завършена. Екипът се съгласява по този въпрос и го документира, така че да не е необходимо да бъде изброен във всяка история.
Предимства и недостатъци на Scrum
Основното предимство на Scrum е приложението на Agile ценности и принципи, както и на Lean концепции като Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System и Iterations. Прилагането на тези принципи позволява на екипите на проекта да получават непрекъсната обратна връзка, бързо да се адаптират към променящите се изисквания и несигурност, да намаляват отпадъците, да увеличават видимостта и прозрачността и да се стремят към непрекъснато подобряване. Винаги като се фокусира върху най-важните елементи в изоставането на продуктите и работи само на кратки итерации, които винаги произвеждат работещ софтуер, Scrum е по-фокусиран върху клиентите и позволява на клиентите да видят какво им харесва (и не им харесва) и да правят промени при нужда. Режийните разходи по отношение на процеса и управлението са по-малки, което води до по-бързи и по-евтини резултати.
Scrum е чудесна методология за проекти с изисквания, които не са ясно известни и / или се очаква да се променят. Това се отнася за повечето проекти. Scrum също е чудесен за опитни, мотивирани екипи, тъй като позволява на екипите сами да организират работата си и осигурява видимост, прозрачност и отчетност както за напредъка, така и за проблемите. Всичко това ще доведе до това екипите да се подобрят и да станат по-продуктивни с времето.
Scrum има някои недостатъци и не е най-добрата методология в някои ситуации:
- Прозрачност: Scrum увеличава прозрачността и отчетността, което е едновременно предимство и недостатък, тъй като проблемите и лошото представяне в и извън екипа са изложени. Това може да бъде неудобно и може да доведе до съпротива, ако не се работи правилно в рамките на Scrum в рамките на непрекъснатото усъвършенстване.
- Екипен опит и ангажираност: Неопитните и / или необвързани Scrum екипи или Scrum Masters могат да причинят сериозни проблеми поради неправилно прилагане на Scrum методологията. Няма определени роли в Scrum екипа, тъй като всеки прави всичко, така че изисква ангажирани членове на екипа с технически опит да следват Scrum процеса и да се усъвършенстват с течение на времето. Също така може да бъде много вредно, ако други части на организацията са устойчиви на Scrum.
- Обхват пълзене: Съществува риск от пълзене на обхвата, особено ако няма определена крайна дата, тъй като заинтересованите страни имат право да добавят към обхвата. Възможността за промяна на обхвата и приоритетите е едно от основните предимства на Scrum, но може да бъде и недостатък, ако не се използва дисциплина.
- Лошо дефинирана работа: Лошо дефинираните и разбрани потребителски истории или задачи могат да доведат до преработка, неточни оценки и пълзене на обхвата. Въпреки че Scrum е фокусиран върху работещия софтуер върху документацията, собственикът на продукта трябва да е наясно какво иска и да може ясно да съобщава това в разговори и в потребителските истории.
- Мащабиране: Приемането на рамката на Scrum в големи екипи е предизвикателство, тъй като Scrum е предназначен за по-малки екипи.
Канбан
Какво е Канбан?
Kanban е по-лек процес, който прилага много от стойностите на Lean и Agile, както и подмножество на Scrum стойностите и принципите, но има и някои основни разлики. Kanban се фокусира върху визуализацията, потока и ограничаването на текущата работа.
Kanban е японски за „табела“ или „билборд“. Линейните работници на Toyota използваха канбан (т.е. действителен борд), за да сигнализират за допълнителен капацитет в различни стъпки от производствения си процес. В софтуера това се прави с дъска Kanban, която много прилича на платката Scrum. Има приоритизирани изоставания от задачи и вертикални колони за всеки статус, който може да има работен елемент. Подобно на Scrum, работните елементи се преместват от един статус в друг; в Kanban обаче количеството незавършена работа е строго ограничено до максимален брой елементи във всеки статус въз основа на капацитета на екипа. Нова работа не може да бъде изтеглена, докато съществуващата не бъде преместена към следващата стъпка в процеса. В Scrum, незавършената работа е косвено ограничена чрез контролиране на обема на работата, планирана за спринт.
В Kanban няма фиксирани итерации или спринтове, просто постоянен поток, при който работните елементи се изтеглят от един етап на следващия. Това означава, че дъската Kanban никога не се нулира. Това също означава, че много от Scrum ритуалите не се използват. Екипите на Kanban често имат ежедневни срещи за изправяне, но те не са предписани. Няма редовно планирани срещи за планиране на спринт, демонстрации на спринт или ретроспективи на спринта, така че процесът е по-лек. Някои от дейностите в тези ритуали могат или не могат да се извършват на неформално ниво. Непрекъснатото усъвършенстване се постига чрез проследяване и анализ на потока от елементи от едно състояние в друго и извършване на постоянни допълнителни подобрения въз основа на разкритите проблеми.
Kanban също не предписва ролите, които Scrum изпълнява. Единствената необходима роля е ролята на член на екипа, но често има Ръководител проект който управлява екипа и изоставането. Често една дъска на Kanban може да обслужва множество функции и / или екипи, базирани на функции, които работят само върху елементи в определен статус. Например, екип за разработка може да изтегли елементи от „Завършване“ към „В процес“ и да ги премести в „Тестване“, а тестовият екип може да тества елементи в „Тестване“ и да ги премести в „Готово“.
Много от дейностите по управление на изоставането за определяне на приоритети и поддържане на работни елементи все още трябва да бъдат извършени, за да се гарантира, че даден работен елемент е добре разбран и готов за работа, но оценката на работните елементи се предписва като незадължителна.
Kanban срещу Scrum
Следващата таблица сравнява Scrum и Agile:
| Канбан | Scrum |
|---|---|
| Непрекъсната доставка | Спринтове с времева кутия |
| По-малко процес и режийни разходи | Предписал е ритуали и роли на Спринт |
| Фокусира се върху бързото попълване на отделни елементи | Фокусира се върху бързото изпълнение на една партида работа |
| Измерва времето на цикъла | Измерва скоростта на спринта |
| Фокусира се върху ефективния поток | Фокусира се върху предсказуемостта |
| Ограничава WIP за отделни артикули | Ограничава WIP на ниво спринт |
| Изтеглят се отделни работни предмети | Работата се извършва на партиди в Sprint Planning |
| Няма предписани роли | Има предписани роли (Scrum Master, собственик на продукт, член на екипа) |
| Kanban Board може да бъде организиран около един многофункционален екип или множество специализирани екипи | Scrum Board е организиран от единен многофункционален екип |
| Промените могат да се правят по всяко време -> по-гъвкави | Промените са разрешени само в изоставането на продукта. Не се допускат промени в спринта |
| Изисква по-малко обучение | Изисква повече обучение |
| Добре за екипи, където са необходими само допълнителни подобрения | Добре за екипи, където са необходими фундаментални промени |
Резюме: Краят на част 1
В тази част разгледахме няколко от най-популярните методологии, използвани за разработване на софтуер. Досега трябва да разбирате добре Lean, Agile, Scrum и Kanban и техните исторически корени в Lean Manufacturing и TPS. В следващата част от поредицата ще продължим да преглеждаме и сравняваме други методологии за разработване на софтуер като Водопад , JTBD , и БЕЗОПАСНО (и други рамки за мащабиране), както и хибридни методологии, така че всички те са удобно обяснени на едно място.
Разбиране на основите
Какво е Agile?
Agile е рамка, която се прилага за всеки процес, който прилага Agile набор от ценности и принципи. Някои от примерите са: Екстремно програмиране, Scrum и Kanban.
Какво е Scrum?
Scrum е прост, но невероятно мощен набор от принципи и практики, които помагат на екипите да доставят продукти за кратки цикли. Scrum е рамка, която прилага Agile принципи, която е измислена отделно от множество хора, няколко от които подписаха Agile Manifesto.
Какво е Kanban?
Kanban е по-лек процес, който прилага много от стойностите на Lean и Agile, както и подмножество на Scrum стойностите и принципите, но има и някои основни разлики. Kanban се фокусира върху визуализацията, потока и ограничаването на текущата работа.
