Agile & Scrum

Какво е Agile

Agile е рамкиран, итеративен (етапен) подход, за разработка на software (и не само), при който изграждането на software-a се извършва по етапно и към клиентите се предоставя на база тези етапи, вместо да цели извеждането на финализиран продукт, в края на процеса за разработка.

Целта на Agile е да раздели проекта и процеса на разработка на няколко етапа, така че да покрие необходимата потребителска функционалност, като ги разделя на по-малки части с цел запазване на Single Responsibility принципа, задаването на приоритети и предоставяйки ги в рамките на двуседмични цикли наречени итерации.

Никога не забравяйте, че

Agile is a Mindset!

Agile Definition

Agile процесът за разработка на software се отнася към група методологии за разработка на software базирани на итеративен процес, където изискванията и решенията еволюират чрез взаимодействието (взаимоработата) между себе-организирани многофункционални екипи. Agile методите / процесите основно насочват процеса да бъде дисциплиниран за управление на продукта, който насърчава честа инспекция и адаптивност, философия на лидера – чиято цел е да окуражи работата в екип, себе-организираността и поемането на отговорности, набор от best practices с цел рязко разработване на висококачествен software и бизнес подход, който приравнява процеса на разработване с нуждите на клиента и целите на компанията. Agile development се отнася за всеки един процес на разработка, който следва концепцията на Agile манифеста.

Agile манифест

Link

Манифестът е разделен на четири стъпки, които са повече нагласи. Всяка една е разделена на две, като основният фокус е върху лявата, но дясната не се отрича:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

Individuals and interactions – най-важното тук е, да се обособи факта, че в един процес (спринт, обсъждане, планиране и т.н.) трябва да има непрекъсната комуникация.

Working software – идеята е в края на всеки Sprint, да има работещ, лесен software, отколкото купища документация без покритие.

Customer collaboration – отношение към клиентите и желанията им.

Responding to change – гъвкавост относно промяната в нуждите на проекта.

Разликата между класическия “Waterfall” модел (водопаден) и Agile е, в последния аспект на манифеста. При водопада нещата са линейни, един след друг процесите имат своето начало и край, и при него няма гъвкавост относно момента на постъпване на ново изискване от страна на клиент, stakeholder и т.н.

Принципи на Agile манифеста:

  1. Най-високият приоритет е да се задоволи клиента (нужди, мнение) чрез ранен, по етапен, непрестанен процес на предоставяне на продукт (software).
  2. Да се поемат позитивно промените в изискванията, дори и в края на работния процес. Agile приема промяната лесно, така че то е в полза на конкурентоспособността на клиента.
  3. Предоставяйте често работещ software, в рамките на няколко седмици до няколко месеца, като се старайте да
    приоритизирате по-краткия период;
  4. Бизнесът и разработчиците трябва да работят дневно по време на целият проект;
  5. Изграждайте проектите около мотивирани индивиди. Предоставете им среда и поддържайте това от което имат нужда,
    като доверете им се, за изпълнението на това, за което са назначени.
  6. Най-ефикасният и най-ефективният метод за прехвърляне на информация към и в един разработващ екип е face-to-face
    комуникацията;
  7. Работещият software е основната мярка за прогрес;
  8. Agile процеса, промотира устойчивост на разработката. Спонсорите, разработчиците и потребителите, трябва да могат да поддържат постоянни темпове за неопределено време;
  9. Непрекъснатото внимание върху техническо превъзходство и добър дизайн подобрява гъвкавостта;
  10. Простотата е от съществено значение; (Изкуството да се максимизира количеството несвършена работа);
  11. Най-добрите архитектури, изисквания и дизайн възникват от самоорганизирани екипи;
  12. На постоянни интервали, екипът отразява как да повишат ефективността си, след това настройва и поведението си.

Ползите от AGILE

Ползите за клиента (customer)

Клиентите разбират, че доставчика (vendor) е доста по-отзивчив към нови изисквания по време на разработката. По-ценни функционалности се предоставят доста по-бързо чрез кратки цикли, отколкото при дългите “waterfall” процеси.

Ползите за доставчиците

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

Ползи за отборите по разработка

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

Ползите за продуктовите мениджъри

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

Ползите за ръководителите на проектите

Ръководителите на проекта (и другите), които попълват ролята на ScrumMaster разбират, че планирането и следването са доста по-лесни и доста по-здрави, в сравнение с “waterfall” процеса. Фокусът върху task-level проследяването, използването на Burndown Charts с цел извеждането на дневния прогрес и дневните Scrum срещи предоставят на Ръководителя на проекта огромно знание върху това на какво ниво и в какво състояние е проекта, по всяко едно време. Това знание е ключово от гледна точка на това кои проблеми трябва да бъдат приоритетно разрешени.

Ползите за PMO и C-Level ръководителите

Scrum предоставя висока видимост по отношение на състоянието на проекта, на дневни бази. Външните страни (stakeholder), например като ръководителите (директори, CEO, COO, персонала на офиса на ръководителите на проекта), могат да използват тази видимост, така че да планират доста по-ефективно и да определят стратегиите си на база на твърди данни, а не на спекулации.

Scrum определение

Scrum е част от Agile, негово подмножество. Той е опростен framework на процесите за Agile development и е най-широко използвания:

– Framework на процесите представлява точно зададен набор от практики, които трябва да бъдат следвани по определен ред, така
че да бъдат консистентни с framework-a. (Пример, SCRUM използва цикли на разработка наречени Sprints, XP Framework-a
изисква програмиране по двойки /pair-programming/ и т.н.);

– Опростен – означава че самият процес е опростен до максимално (право и точно) с цел максимизиране на количеството време за продуктивност, за да се свърши полезната работа;

Един Scrum процес е разграничен от останалите agile процеси от специфични за него концепции и практики, разделени на
три категории: Roles, Artefacts и Time Boxes.

Scrum най-често се използва за разработка и управление на комплексни решения при разработка на software и продукти, чрез итеративни и инкрементиращи процеси и практики. Scrum значително увеличава продуктивността и намаля времето в сравнение с класическия “waterfall” процес. Процесите при Scrum помагат организирането и разработването на продукта да минава гладко при стресови (и неочаквани) състояния и помага на продукта да еволюира на база бизнес целите. Един Agile Scrum процес помага на организацията с:

  • Повишаване на качеството на крайните (предоставени) продукти;
  • Справяне с промените (очакването им, като нещо съвсем нормално);
  • Предоставяне на по-точни предвиждания (estimates), за сметка на по-малко време за създаването им;
  • По-голям контрол на състоянието на проекта и неговия график;

На следващият link, ще видите как се извършва един Scrum процес:

https://fast.wistia.com/embed/iframe/p7novk9lc6

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

Scrum не определя точно изискванията, които трябва да се вземат, просто казва, че те трябва да се съберат в един Product Backlog и се определят като Product Backlog Items (PBIs). Тук е важно да се отбележи, че природата на един Scrum Sprint извежда, че един набор (продукт, разработка) трябва да изисква по-малко време за имплементация, отколкото е самата продължителност на Sprint-a. Повечето Scrum проекти взимат т.нар. XP (Extreme Programming) практика с цел имплементирането на заявка, като User Story. Тук описваме три стандартни артефакта намерени в Product Backlog

User Story

Едно User Story описва една желана функционалност в разказвателна форма. User Story-тата обикновено са написани от
Product Owner-a и те са негова отговорност. Форматът не е стандартизиран, но обикновено има име, описание, референции
към външна документация, как тази имплементация ще бъде тествана. Една история може да изглежда по следния начин:

Name: Създаване на нов Контакт в Адресната книга, така че да може след това да се свърже с него по пощенски или
електронен mail;
———
Description: Добавяне на стандартна контактна информация (Име и Фамилия, два адреса на улици, град, държава, п.к.) в
един екран за добавяне на контактна информация. Той натиска “Запази” с цел запазване на данните и “Откажи” с цел
отхвърляне на информацията и да се върне на предходния екран.
———
Screens and External Documents: http://myserver/screens/contact-entry.html
———
How to test: Тестващия добавя и запазва данните, намира името в Адресната книга и го избира. Вижда един RO изглед
на записа на контакта, с вече добавената дата.

Елементите на един User Story са:

Name: Описателна фраза или изречение.

Description: Описание от високо ниво, което трябва да бъде спазено. За функционалност по изискване на краен потребител
описанието трябва да е в разказвателна форма. За не-функционално изискване описанието може да е написано така, че да е лесно за разбиране. И в двата случая ключа тук е, че детайлите са само повърхностни, защото настройките се извършват по време на фазата за имплементиране по време на дискусията между членовете на отбора, product owner-ите и всички останали, които са включени в този процес (Един от основните концепции на Scrum: Изискванията са зададени на такова ниво, което позволява груба естимация на процеса за имплементирането им, а не на детайла).

Screens and External Documents: Ако Story-то изисква UI промени (които не са тривиални), Story-то трябва да съдържа или има препратка към прототип на промените. Всеки един външен документ изискващ имплементиране на Story-то също би трябвало да бъде изведен.

How to test: Имплементацията на Story е определена като завършена, тогава и само тогава, ако премине всичките acceptance тестове разработени за нея. Тази секция предоставя кратко описание на това как едно Story ще бъде тествано. За самата функционалност описанието на методите за тестване е кратко, съдържащо детайли за изчистване по време на имплементирането, но ние се нуждаем и от резюме на естимацията.

Има две основни причини за включване на информацията с цел тестване на Story-то. Едната е очевадна – да насочи разработването на тестовете. А другата, доста важна, Team-a ще има нужда от тази информация с цел естимация колко работа трябва да извършат с цел имплементирането на Story-то.

Defect

Един Defect или bug е описание на грешка, така че продукта да не се държи по начина по който се очаква. Те са запазени
в една система следваща бъговете, която може да не е въпросния Product Backlog. Ако не, някой (обикновенно PO) трябва
да добави всеки един Defect в ProductBacklog-а с цел включването му в следващия Sprint.

SCRUM Roles

Три са основните роли: ScrumMaster, ProductOwner и Team (отбора). Хората изпълняващи тези роли работят заедно, всекидневно, с цел подсигуряване на постоянен поток на информация и бързото решаване на проблемите.

ScrumMaster – той е пазителя на процеса. Целта му е да остави процеса да работи гладко, като премахва пречките които
влияят на продуктивността и да организира и управлява критичните срещи. Неговите отговорности са:

  • Премахване на бариерите между Dev Team-a и PO-то, така че PO-то да може директно да управлява разработката;
  • Да запознае РО-то как да увеличи максимално възвръщаемостта и да достигне до целите си чрез Scrum;
  • Да подобри живота на Dev Team-a чрез подхранване на креативността и да ги мотивира;
  • Да подобри продуктивността на Dev Team-a по какъвто и да е начин;
  • Да подобри практиките и инструментите, които инкрементират функционалността, за по-ранната доставка.
  • Да пази информация относно прогресът на Team-a и нейната отвореност към всички участници на процеса.

Практически ScrumMaster-a трябва да разбира Scrum достатъчно добре, така че да обучава и да наставлява всички останали роли, както и да образова и помага на останалите страни (stakeholder-ите), които са включени в процеса. Той трябва да е непрекъснато осведомен за статуса на проекта, така че да се спази очаквания срок, да следи за правилната резолюция и трябва да е достатъчно гъвкав, така че да идентифицира и да се справя с всеки един проблем, който би изскочил. Той трябва да опази Team-a от каквито и да било други смущения от други хора, като той действа като интерфейс между тях. ScrumMaster-a не назначава задачи към отбора – задачите са отговорност на Team-a. Неговият подход към отбора е с цел окуражаване и подхранване на взимането на самостоятелно решение и разрешаването на проблемите, така че те да работят с повишена ефективност и с намалена нужда от надзор. Целта му е да направи Team, който не само е способен да взима важни решения, но да ги възприема като рутина.

Product Owner – той е човека назначаващ изискванията. Той предоставя т.нар. “single source of truth” за отбора, независимо изискванията и техния планиран ред на имплементация. На практика PO-то е интерфейса между бизнеса, клиентите и техните нужди по отношение на продукта от една страна, и Team-a от друга. Той е буфера между Team-a и всичките заявки за нови функционалности и bug-fix-ове идващи от много източници и е единственият контакт за въпроси относно изискванията към продукта. Работи близко с team-a, за да документира процеса и да определи процесът на имплементацията. Той поддържа Product Backlog-a, с цел детайлна информация необходима на Team-a. PO-то наглася разписанието, кога да се предостави информация към клиентите и той е последната инстанция дали имплементацията покрива нужните критерии за нейното пускане.

Team-a – е себе-организираната, крос-функционална група от хора, които извършват целият физически DEV и тест върху
продукта. Тъй като Team-а е отговорен за изработката на продукта, той има правомощието да прецени как да извърши
работата. По този начин Теам-а e себе-организиращ се: членовете на екипа си разпределят работата по време на Sprint
сесията. Бройката на Team-а трябва да е между 5 и 9 човека (По-голям от това прави комуникацията трудна, докато по-
ниска води до слаба производителност и чупливост).

ScrumTeam – е Team-a плюс ScrumMaster-a и PO-то.

Scrum Framework в 30 секунди

  • PO създава приоритизирания wish list, който се казва Product Backlog;
  • По време на планирането на Sprint-a, отбора изтегля малко парче от най-горе на този списък и преценяват как да имплементират тази част;
  • Отбора имат определено количество време – a sprint (обикновено две до четири седмици) – за приключване на работа, но се срещат всеки ден, за да обсъдят прогреса (daily Scrum);
  • През целият процес, ScrumMaster-а поддържа фокуса на отбора върху целта;
  • В края на Sprint-a, изработката трябва да е потенциално готова за доставка: да се даде на клиента, да се остави на
    витрината или да се покаже на stakeholder.
  • Sprint-a приключва с review и retrospective;
  • На започването на следващия sprint, отбора избира друго парче от Product Backlog-a и започва работа по него.

Отвъд Sprint

Процесът се повтаря n на брой пъти, докато достатъчно елементи в Product Backlog-a са завършени, бюджета е изчерпан или дойде deadline-a. Кой от тези milestone-и ще прекрати процеса изцяло зависи от проекта.

Scrum Grooming (Backlog Grooming)

Това е когато PO и част (или всички) от отбора преглеждат елементите на този backlog с цел подсигуряване дали този log съдържа правилните елементи, те са правилно приоритизирани и елементите на върха са готови за доставка.
Няколко от тези дейности, които са често срещани по време на рафинирането на backlog-a, са:

  • премахване на User Stories, които вече не са релевантни;
  • създаване на нови User Stories, на база нови нужди;
  • преподреждане на приоритета;
  • задаване на естимации към Story-та, които нямат такъв;
  • корекция на естимации на новопостъпила информация;
  • разделяне на User Story-тата, които са с висок приоритет, но не са изчистени детайлите по тях, така че да влезнат в следващата итерация.
Advertisements

Give your opinion

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s