Манифест за гъвкаво разработване на софтуер (The Manifesto for Agile Software Development)

Седемнадесет анархисти приемат:

Разкриваме по-добри начини за разработване на софтуер, като го правим и помагаме на други да го правят. Тази работа ни научи да ценим:

Процес за управление на проекти TenStep

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

Съвместната работа с клиента повече от преговорите за сключване на договори.

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

Ето защо ние ценим изложеното отдясно, но повече ценим посоченото отляво.

Ние се придържаме към следните принципи:

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

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

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

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

При Agile разработките изискванията могат да бъдат променяни по всяко време. Идеята е, че клиентът може да продължи да прави промени, при условие че приоритизира тези промени в подходящата итерация. Например, ако клиентът поиска три доклада, а по-късно поиска четвърти, четвъртият доклад може без проблем да бъде добавен към списъка с изискванията. В даден момент клиентът ще трябва да приоритизира този нов доклад и когато направи това, докладът ще бъде написан. Ако бюджетът на клиента не е ограничен, няма и формален процес за промяна в обхвата – всичко, което клиентът поиска и приоритизира, ще бъде направено. Ако клиентът разполага с фиксиран бюджет, тогава приоритизирането на дадена промяна по същество означава, че друга част от работата няма да бъде извършена. При този сценарий клиентът прилага промяна в обхвата чрез приоритизиране само на онези промени, които са от най-голяма важност.

Според TenStep при настъпване на промени в бизнес изискванията, екипът на проекта трябва да има готовност да реагира. И все пак промените в изискванията водят до промени в бюджета и сроковете за изпълнение, които трябва да се съгласуват и одобрят от спонсора. Ако екипът прави това, това означава, че той упражнява управление на промените.

Доставяйте работещ софтуер често, в рамките на две седмици до два месеца, като отдавате предпочитание на по-късия срок.

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

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

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

Това е най-добрият начин за запознаване с нуждите на клиента.

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

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

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

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

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

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

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

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

Непрестанният стремеж към техническо съвършенство и добър дизайн спомага за постигането на гъвкавост.

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

Простотата – изкуството да се максимализира все още несвършената работата – е от съществена важност.

Приема се. Разработчиците и потребителите трябва да насочат усилията си на първо място към реализирането на ключовите изисквания. Това води до "максимализиране на несвършената работа" и позволява по-бързо създаване на софтуера.

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

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

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

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

— Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
www.agileAlliance.org