„И така, искам да ви разкажа за Agile и Scrum .“
„В началото на 21 век начинът, по който хората мислеха за програмирането, се обърна с главата надолу.“
„Всички бяха убедени, че дългосрочното планиране не работи, така че решиха да го изоставят напълно.“
— Как го направиха?
"Ето How."
„Те изобретиха възможно най-гъвкавия подход за управление на проекти.“
Ето основните идеи зад гъвкавото развитие :"
- хората и комуникацията са по-важни от процесите и инструментите;
- работещият продукт е по-важен от изчерпателната documentация;
- сътрудничеството с клиента е по-важно от спазването на условията на договор;
- желанието за промяна е по-важно от придържането към първоначалния план.
Ето принципите за бързо развитие:
- задоволяване на клиента чрез предоставяне на ценен софтуер навреме и непрекъснато;
- добре дошли промени в изискванията дори в края на разработката (това може да повиши конкурентоспособността на крайния продукт);
- доставяйте работещ софтуер често (всеки месец or седмица or по-често);
- тясна ежедневна комуникация между клиента и разработчиците по време на целия проект;
- по проекта работят мотивирани личности, на които са осигурени необходимите условия за работа, подкрепа и доверие;
- предпочитаният метод за предаване на информация е личен (очи в очи) разговор;
- работещият софтуер е най-добрата мярка за напредък;
- спонсори, разработчици и потребители трябва да могат да поддържат постоянно темпо за неопределен период от време;
- постоянен фокус върху подобряването на техническите постижения и удобния за потребителя дизайн;
- простотата е изкуството да не вършиш излишна работа;
- най-добрите технически изисквания, дизайн и архитектура идват от самоорганизиран екип;
- постоянно адаптиране към променящите се обстоятелства.
„Основният проблем при разработването на софтуер беше, че на нито един етап никой от участниците нямаше пълна информация Howво да прави.“
„Клиентът може да ви каже How си представя програмата, но ще пропусне нещо or ще приеме нещо за даденост.“
„Мениджърът обикновено трябва да превежда изискванията от програмен жаргон на езика на клиента и обратно.“
„Има твърде много несигурност.“
„Често изискванията на клиента са такива: направете го по няHowъв начин, след това ми покажете - ако не ми харесва, тогава можете да го повторите.“
— Ъъъ... това е ужасно.
„Според новата парадигма програмистите вече не разработват продукт or програма. Вместо това те внедряват функционалността, от която клиентът се нуждае.“
"Каква е разликата?"
„Е, да предположим, че разработването на програмата отнемаше една година. И трябваше да минат шест месеца, преди да има Howво да се гледа. Това е като да построиш голяма къща: първо копаеш яма за основата, след това изливаш основата, изграждане на стени, покрив, облицовка и т.н."
„Но сега програмистите се опитват да пуснат необходимата функционалност възможно най-скоро. Това би било като първо да построите хижа, след това мобилен дом, след това малка къща и едва след това голяма къща - на вноски.“
„Като се има предвид , че клиентът вероятно не знае точно Howво иска, тогава това е много разумен подход.“
„Да предположим, че клиентът иска голяма ловна хижа.“
„Разработчиците му правят малко. Той живее в него за една зима. После решава, че не харесва дървени къщи. Нека направим една тухлена.“
„Той живее едно лято близо до езерото, но комарите го изяждат жив. Беше чул някъде, че езерата са готини, и затова му се прииска да има едно. Но сега не иска езеро. И ще бъде по-лесно да се построи къщата по този начин: липсата на езеро означава липса на заплаха от наводнения и можете да построите къщата на земята instead of на кокor, което ще бъде с 25% по-бързо."
„Интересна аналогия. Клиентите наистина ли променят изискванията си толкова често?“
— Да, но проблемът не е в клиента.
„Първо, много е трудно да си представим How ще се развият нещата в бъдеще. Мениджъри, тестери и програмисти също правят това. Те също променят мнението си в зависимост от това How се развиват нещата.“
„Второ, изискванията на клиента не са ли най-важни? В края на краищата смисълът на цялата тази работа е да се създаде това, от което клиентът се нуждае , а не това, което първоначално е казал да създаде .“
„Наистина, работеше по следния начин: бизнес анализаторите правеха списък с всички изисквания. Те включваха този списък в договор, подписваха го и работеха само според списъка.“
„Ако в списъка липсваше нещо, от което клиентът наистина се нуждаеше , но беше забравил, никой нямаше да направи нищо по въпроса.“
"Разбирам. По-лесно е да следваш план, но не всичко може да се направи по план!"
"Точно."
„Ето защо бяха изобретени гъвкавите методи за разработка.“
„И днес ще ви разкажа за Scrum – най-популярният сред тях.
„Основната характеристика на Scrum е разделянето на разработването на проекта на малки итерации – обикновено с продължителност 2-4 седмици. Всяка итерация се нарича спринт.“
"В началото на спринта се провежда среща за планиране на спринта. Тя продължава 3-4 часа."
„Накрая има демонстрация на всички напълно изпълнени задачи.“
„Ето How обикновено работи всичко:“
„Преди първия спринт клиентът (or представител на клиента) формира списък с изисквания, т.е. наборът от неща, които програмата трябва да може да прави. Тези изисквания обикновено се наричат потребителски истории, а клиентът обикновено е наречен собственик на продукта ."
„Той се нарича собственик на продукта , защото продуктът е написан за него. Той и само той определя списъка с изисквания – Howво, кога и в Howъв ред.“
„Освен това собственикът на продукта обикновено задава приоритети на задачите. Задачите с най-висок приоритет ще бъдат изпълнени първи. Целият списък с изисквания също се нарича продуктов изоставане .“
„Когато започне спринт, всички се събират на среща. Скръм майсторът , обикновено член на екипа, обикновено води срещата. Целта на срещата е да се изберат задачите ( потребителска история ) за текущия спринт (итерация на разработката). "
„Първо, екипът присвоява на всяка задача груба оценка в абстрактни човеcodeни, известни също като исторически точки. След това екипът решава колко задачи ще имат време да изпълнят по време на спринта.“
„Отново, самият отбор решава колко задачи ще имат време да изпълнят по време на спринта.“
„Да кажем, че собственикът на продукта очаква екипът да избере първите 7 задачи, но той избра само 5, след което задачи 6 и 7 се отлагат за следващия спринт. Ако това не отговаря на собственика на продукта , той може да повиши приоритета на задачите 6 и 7, за да сте сигурни, че са избрани, но тогава някои от другите задачи ще отпаднат от спринта."
„ Скръм майсторът може също да предложи да раздели някои от задачите на по-малки и да им зададе различни приоритети, за да направи собственика на продукта възможно най-щастлив.“
„Това е смисълът на срещата: задачите могат да се променят и разделят, приоритетите могат да се променят и т.н. Това е работата, която не беше видима в началото, но носи много стойност.“
„Разбрах. Това е като да караш кола. Дори първоначално да смяташ, че просто трябва да вървиш направо, реалността е, че трябва постоянно да избягваш дупките, да завиваш надясно и наляво и да задминаваш другите or да ги оставяш да те задминават.“
— Да, нещо такова.
„Списъкът със задачи, избрани за спринта, се нарича неизпълнена задача за спринт .“
„Програмистите решават кой Howво ще направи и едва тогава се захващат за работа. „За да се подобри ефективността, Scrum предлага всеки ден да се провежда 5-15 minutesна среща, на която всеки може да си каже Howво е правил вчера и Howви са ще направя днес."
„Работа в екип. Мога да го уважавам!“
„За да направите нещата по-лесни за визуализиране, обикновено се препоръчва текущото състояние на спринта да се показва на специално табло:“
„Забележете трите колони отляво.“
„Съкратените имена на задачите са написани на лепящи се бележки. И лепящите бележки се поставят в различни колони в зависимост от техния статус (планирани, в ход, готови).“
„Вдясно можете да видите диаграма за изгаряне . За всеки ден тази диаграма изброява задачите, които все още остават неизпълнени. В идеалния случай броят на незавършените задачи пада до нула по време на спринта.“
„Когато спринтът приключи, scrum-master-ът дава демонстрация , за да покаже списъка с всичко, което е напълно завършено.“
„След това той провежда спринтова ретроспективна среща , която също продължава няколко часа. По време на тази среща участниците обикновено се опитват да разберат Howво е минало добре и кои (и How) нещата биха могли да бъдат напequalsи по-добре.“
„Обикновено след 2-3 спринта можете да идентифицирате и елиминирате основните проблеми, които пречат на екипа да работи по-ефективно. Това води до по-голяма производителност, без да увеличава натоварването на екипа. Това не беше възможно преди ерата на гъвкавите методологии. “
„Понякога среща за подготвяне също се провежда по време на спринта. Целта е да се планира следващият спринт. Участниците обикновено изясняват приоритетите на задачите в тази среща. Те могат също така да разделят някои задачи на части и/or да добавят нови задачи към натрупания продукт . “
„Е, това е общо взето всичко, което имам. Това е само общ преглед. Невъзможно е да обясня всичко само с няколко думи, но можете да прочетете добра статия по темата тук:“
GO TO FULL VERSION