Agile терминологии и определения

Изпитване за приемане

Проведено официално тестване, за да се определи дали системата отговаря на нейните критерии за приемане и да позволи на клиента да определи дали да приеме системата или не.

Методология за гъвкаво разработване на софтуер

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

Важен гъвкав принцип е да се доставя (потенциално) освобождаем софтуер след всяка итерация.

Подреждане на изоставането

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

Разбиване на изграждането

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

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

Компилацията е счупена, ако процесът на компилация не може да бъде завършен успешно поради редица причини, включително (но не само) неуспешно компилиране, компилиране с неприемливи предупреждения или неуспех на произволен брой автоматизирани тестове.

Процес на изграждане / изграждане на тръбопровод

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

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

Chartdown Chart

Графика, която показва общия брой часове на задачата, останали на ден. Това показва къде е отборът по отношение на изпълнението на задачите, които са били ангажирани в спринта. Оста X представлява дните в спринта, докато оста Y остава усилие.

Пиле

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

Непрекъсната интеграция

Непрекъснатата интеграция (CI) е практика за екстремно програмиране (XP), при която членовете на екип за доставка често интегрират работата си (например на час или поне веднъж дневно).

Всяка интеграция се проверява чрез автоматизирана компилация, която също извършва тестване, за да открие всички интеграционни грешки бързо и автоматично. Основната цел на CI е да се избегне това, което обикновено се нарича интеграция или сливане на ада.

Междуфункционален екип

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

Клиент

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

Вътрешните клиенти понякога се наричат ​​„Бизнес“.

Ежедневен Standup

Ежедневната среща на екипа обикновено се провежда първото нещо сутрин, за да се осигури актуализация на състоянието на членовете на екипа. Обикновено срещите са с времеви интервал от 5 до 15 минути и се провеждат изправени, за да напомнят на хората да държат срещата кратка и по същество.

Определение на Done (DoD)

Критериите за приемане на работата като завършена. Посочването на тези критерии е отговорност на целия екип, включително и на бизнеса. Като цяло има три нива на „Готово“ (известни също като Готово-Готово-Готово):

• Готово: Разработено, работи в кутията на разработчика
• Готово: Проверено чрез стартиране на модулни тестове, преглед на код и др.
• Готово: Удостоверено като доставящо качество с функционални тестове, рецензии и др.

Точните критерии за това какво представлява „Готово“ варират, за да отговорят на специфичните нужди на различните организации и инициативи.

Епичен

Много голяма потребителска история, която в крайна сметка се разделя на по-малки истории. Epics често се използват като заместители за нови идеи и свързани истории, които да бъдат разработени в следващите спринтове.

Епичните истории помагат на екипите за разработка на Agile ефективно да управляват и поддържат изоставането на своите продукти.

Оценка

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

Екстремно програмиране

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

XP се застъпва за чести „освобождавания“ в кратки цикли на разработка, което има за цел да подобри производителността и да въведе контролно-пропускателни пунктове, на които могат да бъдат приети нови изисквания на клиентите.

Други елементи на екстремното програмиране включват: програмиране по двойки, обширни прегледи на кодове, модулно тестване, непрекъсната интеграция, за да назовем само няколко.

Особеност

Кохерентна бизнес функция или атрибут на софтуерен продукт или система. Функциите обикновено включват много подробни (единични) изисквания. Една функция обикновено се реализира чрез много истории.

Функциите могат да бъдат функционални или нефункционални; те осигуряват основата за организиране на истории.

Последователност на Фибоначи

Последователност от числа, в която следващото число се извлича чрез събиране на предишните две (напр. 1, 2, 3, 5, 8, 13, 21, 34 ...). Последователността се използва за оразмеряване на истории в Agile техники за оценка, като планиране на покер.

Пречка

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

Работата на ScrumMaster е да гарантира, че пречките се отстраняват възможно най-скоро, за да може екипът да продължи да бъде продуктивен.

Повторение

Период (от 1 седмица до 2 месеца), през който екипът за разработка на Agile произвежда нарастване на завършен софтуер. Цялата система фази на жизнения цикъл (изисквания, дизайн, код и тест) трябва да бъдат завършени по време на итерацията и след това да бъдат демонстрирани, за да бъде итерацията приета за успешно завършена.

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

Канбан

Kanban е инструмент, получен от постно производство и е свързан с клона на гъвкавите практики, свободно наричани Lean Software Development. Kanban ограничава колко незавършена работа е разрешено да се извършва по едно и също време.

Основната разлика между Kanban и Scrum е, че Scrum ограничава незавършената работа чрез спринтове, а Kanban ограничава незавършената работа, като ограничава колко работа може да се случи едновременно (напр. N задачи или N истории).

Lean Software Development

Lean разработването на софтуер или просто Lean е фокусирано върху намаляването на отпадъците и оптимизирането на потока от стойност на софтуерното производство.

Минимален жизнеспособен продукт (MVP)

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

Програмиране по двойки

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

Прасе

Някой, който е отговорен за изпълнението на задача в активна итерация. То е обратното на Пилето. Прасетата участват активно в проекта.

Планиране на покер

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

Продукт

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

Собственик на продукта

Собственикът на продукта е една от ключовите роли в Scrum. Отговорностите на Собственика на продукта включват:

• Установяване, подхранване и съобщаване на продуктовата визия
• Създаване и ръководене на екип от разработчици, за да осигури най-добрата стойност за клиента
• Мониторинг на проекта спрямо неговите цели за възвръщаемост на инвестициите и инвестиционна визия
• Вземане на решения относно това кога да се създаде официална версия

Натрупване на продукти

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

Собственикът на продукта поддържа този списък с изоставане на продуктите в съответствие с бизнес приоритетите и нуждите. Елементите в изоставането трябва да отразяват пътната карта на бизнеса.

Рефакторинг

Промяна на съществуващ софтуерен код с цел подобряване на цялостния дизайн. Рефакторингът обикновено не променя видимото поведение на софтуера; подобрява вътрешната си структура.

План за освобождаване

Планът за издаване е график за пускане на софтуер в производство. Типичните планове за пускане включват основните функции, които трябва да бъдат доставени, заедно със съответните дати на пускане.

Ретроспективна

Среща с часово съхранение, проведена в края на спринта, в която екипът изследва своите процеси, за да определи какво е успяло и какво може да се подобри. Ретроспективата е ключова за непрекъснатото усъвършенстване.

Положителен резултат за ретроспектива е да се идентифицират една или две високоприоритетни точки на действие, по които екипът иска да работи в следващата итерация или освобождаване.

Scrum

Scrum е рамка за разработване на сложни софтуерни продукти по итеративен и постепенен начин и е най-широко признатата Agile рамка.

Scrum се състои от поредица от кратки повторения - наречени спринтове - всяка от които завършва с доставката на нарастване на работещия софтуер.

Scrum Team

Scrum екипът е междуфункционална и самоорганизираща се група, която отговаря за доставката на софтуера.

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

Scrum екипът отговаря за всички работни ангажименти и резултати.

ScrumMaster

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

Спайк

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

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

Спринт

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

Sprint Backlog

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

Груминг на истории

По време на сесиите за поддържане на истории подробностите за потребителските истории се уточняват. Критериите за приемане са написани и разработени. На този етап се правят и оценки на историите.

Целта на тази сесия е да гарантира, че всички, които участват в разработването и тестването на историите, споделят общо разбиране за контекста на историите, преди да започне развитието на историите.

Сесиите за подреждане на истории обикновено се провеждат в средата на спринта за следващия спринт, така че екипът да е наясно с натоварването за следващия спринт.

Участници са scrum екипът, scrum master и собственикът на продукта.

Планиране на спринта

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

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

Участниците са scrum master и scrum team.

Потребителска история

Потребителска история (известна още като Story) може да се разглежда като изискване, функция, която има някаква бизнес стойност.

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

Историите се състоят от следните елементи:

• Описание, обикновено в бизнес план
• Размер, за груба оценка, обикновено изразен в сюжетни точки (като 1, 2, 3, 5)
• Един или повече критерии за приемане, давайки кратко описание на начина на валидиране на историята

Задача

Задачите са описания на действителната работа, която човек или двойка върши, за да завърши една история. Те са управляеми, изпълними и проследими работни единици. Обикновено има няколко задачи на история.

Технически дълг

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

Оразмеряване на тениска

Метод за оценка на работата, необходима за завършване на история в размери на тениски, т.е. Малък (S), Среден (M), Голям (L) или X-Голям (XL)

Timebox

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

Скорост

Скоростта измерва колко работа екипът може да завърши в една итерация. Скоростта често се измерва в истории или сюжетни точки. Скоростта може също да измерва задачите в часове или еквивалентна единица.

Скоростта се използва, за да се измери колко време ще отнеме на даден екип да постигне бъдещи резултати чрез екстраполация въз основа на предишното му представяне.

Работа в прогрес

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