KNOW INTUIT, Лекция, Agile методи за разработка

„Гъвкавите“ (гъвкави) методи за разработка на софтуер се появиха като алтернатива на формалните и „тежки“ методологии, като CMM и RUP. Талантливите програмисти не искат разработването на софтуер да се превърне в рутина, те искат да имат максимална свобода и обещават висока ефективност в замяна. От друга страна, практиката показва, че "тежките" методики са неефективни в значителен брой случаи. Основните разпоредби на Agile методите, заложени в Agile Manifesto през 2007 г., са следните 1 Не приемайте тези разпоредби на Agile Manifesto буквално, така че всяка гъвкава методология да ги удовлетворява точно. Agile Manifesto само очертава определено пространство, обозначава определено явление. Отделни части от това явление - специфични гъвкави методологии могат да имат различни специфики, могат да бъдат и гранични обекти. :

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

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

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

Най-известният agile метод е Extreme Programming (известен съкращение от XP). Създаден е от талантливия софтуерен инженер Кент Бек в резултат на работата му от 1996-1999 г. върху системата за контрол на плащанията на Chrysler.

Процесен модел на XPизглежда като честа последователност от издания на продукти, възможно най-чести. Но в същото време е наложително изданието да включва нова цялостна функционалност. По-долу са основните принципи за организиране на процеса на XP.

По-практичен "пъргав" метод за разработка е Scrum.

Общо описание. Методът Scrum ви позволява гъвкаво да разработвате проекти в малки екипи (7 души плюс / минус 2) в ситуация на променящи се изисквания. В същото време процесът на разработка е итеративен и предоставя повече свобода на екипа. Освен това методът е много прост – лесен за научаване и прилагане на практика. Схемата му е показана на фиг. 11.1.

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

В рамките на една итерация проектът се управлява изцяло от екипа. Това е плоско, Scrum не дефинира никакви роли. Синхронизирането с ръководството и клиента става след края на итерацията. Итерация може да бъде прекъсната само в специални случаи.

Роли. Има три вида роли в Scrum.

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

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

Scrum-team(Scrum Team) - група, състояща се от пет до девет независими, инициативни програмисти. Първата задача на екипа е да постави реалистично постижими и приоритетни задачи за проекта като цяло за итерацията (на базата на Project Backlog и с активното участие на product owner и Scrum master). Втората задача е изпълнението на тази задача с всички средства, в рамките на определеното време и с декларираното качество. Важно е самият екип да участва в поставянето на задачата и сам да я изпълни. Той съчетава свобода и отговорност, подобно на начина, по който е организиран в MSF. Тук „лъсва” дисциплината на задълженията.

Практики. Scrum дефинира следните практики.

Среща за планиране на спринт. Провежда се в началото на всеки спринт. Първо, собственикът на продукта, Scrum Master, екипът, както и представителите на клиентите и други заинтересовани страни определят кои изисквания от проекта Backlog са с най-висок приоритет и трябва да бъдат изпълнени в рамките на този спринт. Формира се Sprint Backlog. След това Scrum Master и Scrum Team определят как точно ще бъдат постигнати целите, дефинирани по-горе от Sprint Backlog. За всеки Sprint Backlog елементопределя се списък от задачи и се оценява тяхната трудоемкост.

Ежедневната Scrum срещае петнадесетминутна ежедневна среща, която има за цел да разбере какво се е случило след предишната среща, да коригира работния план, за да отразява днешните реалности, и да идентифицира начини за справяне със съществуващи проблеми. Всеки член на Scrum екипа отговаря на три въпроса: какво съм направил от предишната среща, моите проблеми, какво ще правя до следващата среща? Всяко заинтересовано лице може да вземе участие в тази среща, но само членовете на Scrum екипа имат право да вземат решения. Правилото се оправдава с факта, че те са дали задължение за реализиране на целта на итерацията и само това дава увереност, че тя ще бъде постигната. Те носят отговорност за собствените си думи и ако някой отвън се намеси и вземе решения вместо тях, с това той снема отговорността за резултата от членовете на екипа. Такива срещи поддържат scrum екипа дисциплиниран, поддържат фокуса върху целите на итерацията и помагат за решаването на проблемите в зародиш. Обикновено такива срещи се провеждат изправени за 15-20 минути.

Среща за преглед на спринта. Провежда се в края на всеки спринт. Първо, екипът на Scrum демонстрира извършената работа по време на спринта на собственика на продукта, който от своя страна ръководи тази част от ралито и може да покани всички заинтересовани представители на клиента да участват. Собственикът на продукта определя кои изисквания за Sprint Backlog са изпълнени и обсъжда с екипа и клиентите как най-добре да се даде приоритет на Sprint Backlog за следващата итерация. Във втората част на срещата се извършва анализ на изминалия спринт, който се ръководи от Scrum Master. Анализи на Scrum екип в последния спринтположителни и отрицателни аспекти на съвместната работа, прави изводи и взема важни решения за по-нататъшна работа. Екипът на Scrum също търси начини за повишаване на ефективността на по-нататъшната работа. След това цикълът се повтаря.