Съдържание на статията
Планиране на времето при софтуерни и ИТ проекти
стр.2 - SDLC и RUP - методологията в развитие
стр.3 - Философията Agile - новите ценности
стр.4 - Agile организациите
Всички страници

От 60-те години на миналия век насам се полагат систематични усилия ИТ да се превърне от „свободно изкуство“ в индустриална дисциплина със съответните формални процедури и процеси. Но борбата с постоянните промени си остава най-важният проблем при ИТ проектите. Необходим е радикално различен способ за управление на проекти в силно нестабилна среда.

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

Оттам следва последователността на изпълнение на задачите във времето. За онагледяване най-често се използва диаграма на Гант. Голямото предимство на този метод е неговата универсалност – независимо дали проектът е в областта на строителството, енергетиката или ИТ, разполагаме с еднаква методология. Въпреки това, всяка област има своите специфични особености и натрупаната практика води до създаване на специфични стандарти за тях. Области като строителство, енергетика, различните производства, логистика, администрация отдавна имат установени общоприети работни схеми, които се прилагат с малки вариации от всички в бранша.

Спецификата на ИТ – водопадният VS итеративният модел

Теорията и практиката свързани с управлението на ИТ проектите също се развиват в посока на изграждане на свои специфични стандарти. От 60-те години на миналия век насам се полагат систематични усилия ИТ да се превърне от „свободно изкуство“ в индустриална дисциплина със съответните формални процедури и процеси. Първият опит за стандартизиране на разработването на софтуер прави У. Ройс (W. Royce) през 1970 г. с въвеждането на т.нар. водопаден модел (waterfall model). В него се дефинират основните фази, през които преминава една софтуерна разработка:

  • дефиниране на изисквания
  • дизайн на системата
  • реализация
  • интеграция
  • тестване и коригиране на грешки
  • инсталация
  • поддръжка

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

Този модел стриктно следва предписанията на класическата наука за управление на проекти. В това е неговата привлекателност - неслучайно моделът бързо се възприема и прилага в софтуерните проекти за държавните сектори на САЩ: администрация, армия, НАСА. Най-неочаквано обаче, с малки изключения, този модел се проваля.
Основна причина за неуспеха е, че практически не е възможно да се приключат фазите на дефиниране на изискванията и дизайна на системата, преди да се започне реализацията. Някои от изискванията изкристализират на по-късен етап. Някои решения по дизайна се оказват неизпълними на фазата на реализация и трябва да се преосмислят, и т.н. Съседните фази на разработката естествено се припокриват и в някаква степен че по-ранните фази зависят от по-късните. Така основната идея на модела за строга етапност се проваля.
Този проблем е забелязан от самото начало от автора на модела и той сам предлага първата модификация – итеративният модел на разработка.

При итеративният модел фазите са следните:

1. Първоначални изисквания
2. Начален дизайн
3. Цикъл
  • Детайлен дизайн
  • Кодиране
  • Тестване
  • Инсталация
  • Допълнителни изисквания и корекции
4.Окончателна инсталация
5. Поддръжка

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

Последният етап е събиране на обратна информация от клиента (допълнителни изисквания и необходими модификации), след което цикълът се повтаря, докато клиентът прецени, че системата го задоволява. Тогава следва окончателната инсталация и системата влиза в действие. Този модел избягва повечето недостатъци на сляпото следване на класическите методи за управление на проекти. В него за първи път се акцентира на активното участие на крайния потребител на системата в нейното разработване. Въпреки, че е предложен в същата статия, в която се описва и водопадния модел през 1970 г., той остава вън от полезрението на ИТ индустрията за цели 20 години.


SDLC и RUP - методологията в развитие

Годините между 1980 и 2000 се характеризират с утвърждаването на обектно-ориентираната методология за разработване на софтуер. През същия период върви усилено „индустриализиране“ на ИТ сектора – имайки развито инженерно средство за програмиране (обектно-ориентираният подход) възниква необходимостта от дефиниране и методика за управление на производствените процеси.

Първата цялостна система за управление на софтуерни проекти е Systems Development Life Cycle (SDLC). Тя е разработена от Американското Министерство на правосъдието. Това е подробна методология за разработване и внедряване на информационни системи. Работният процес следва фазите на класическия водопаден модел, но вече има разработена система за водене на документация, за следене на развитието на процеса и за управление на рисковете.
По-късно системата е възприета във Великобритания под името SLC. Добавени са още правила и подробности, например как да процедираме при разработване със собствен екип и как – при аутсорсинг. Цялата система изглежда „супер“ в очите на всеки администратор или класически ръководител на проект. За съжаление, тя страда от проблемите, от които страда и предшестващият я водопаден модел с неговата изолация на отделните фази на разработката. Методът е подходящ за големи държавни проекти, при които изискванията се знаят от години напред и промяната е малко вероятна. Във всички останали случаи обаче, този метод се проваля.

Безспорно върхът в групата методики, базирани на водопадния модел е всеизвестният Rational Unified Process (RUP). Това е най-мащабният подход, който за пръв път обединява техники от традиционното управление на проекти със специфичните за ИТ индустрията елементи. Разработен е специален език – UML, за моделиране на системата на различни нива. За пръв път в моделирането се включват потребителите и техните начини на взаимодействие със системата.

RUP представя системата като серия от модели. На всеки етап се изгражда нов модел, който се извежда от предходния: модел на сценариите (use case), статичен и динамичен обектен модел, код, тест модел и т.н. Отчитайки, че фазите не могат да бъдат напълно завършени поотделно, се предполага те да се застъпват и да си взаимодействат. Въпреки това управлението на промените се свежда до синхронизирането им във вече направените модели. RUP въвежда и множество „дисциплини“ (правила за работа), които допълнително структуризират и формализират процеса: например дисциплина на моделиране, на кодиране, на тестване и т.н. В процеса се дефинират и итерации, но те обикновено се извършват само в рамките на една фаза, например проектирането минава през няколко итерации.

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

RUP има няколко производни методики, например OPEN, които се опитват да премахнат някои недостатъци, свързани с езика UML и с цялостния подход към управлението на проекта.

Всички методологии, базирани на класическата теория за управление на проекти се опират на философията „Big Design Up Front“ (BDUF) – т.е. много усилия за планиране и дизайн на ранните етапи на проекта, преди да започне реалното кодиране. Това звучи много разумно – колкото по-добре е обмислена системата, толкова по-лесно ще се напише реалният код; поправянето на един пропуск, открит на фазата на кодирането струва 100 пъти повече, отколкото корекция във фазата на планирането. Всичко това е вярно. Въпреки това BDUF, приложена в чистия й вид е крайно неуспешна стратегия - просто, защото не адресира главния проблем – изключителната динамика на ИТ сектора. Голяма част от изискванията, дефинирани преди 2-3 месеца днес вече са остарели. Съответният дизайн вече е неадекватен.

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

Самият аз бях голям привърженик на RUP допреди 7 години, когато ми се наложи да го прилагам на практика за сравнително сложен проект за телекомуникационен софтуер. Тогава изпитах „тъмната страна на силата“. Проектът се разработваше за германския пазар в условията на постоянна промяна в изискванията на клиента, съчетани с промени в нормативната уредба (правилата за изграждане на радио комуникационни мрежи). От един момент нататък осъзнахме, че отделяме по-голямата част от времето си за поддържане на промените в различните модели (use case model, object model, interaction model и т.н.), отколкото да пишем код. Клиентът обаче искаше работеща система, а не набор от синхронизирани теоретични модели. В крайна сметка изоставихме синхронизирането на моделите.


Философията Agile - новите ценности

През 2001 г. група от водещи специалисти начело с Кент Бек предизвикаха истински бум, с публикуването на прочутия Manifesto for Agile Software Development (www.agilemanifesto.org ). Това е документ от една страничка, в който се прокламират новите ценности:

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

 

Agile е повече философия, отколкото методология (конкретните методики, базирани на нея се развиват по-късно). Четирите цитирани принципа крият дълбоко рационална идея:

 

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

Тези, които наистина печелят от реализирането на концепцията Agile са клиентите защото получават „правилната“ система. Печеливши са и разработчиците. Губещи (в известен смисъл) са ръководителите и администраторите на проектите.


Agile организациите

Основните принципи при приложението на философията Agile са 7:

  1. Самоорганизиращ се екип. За разлика от класическите системи, където екипът съдържа различни по квалификация специалисти (дизайнери, архитекти, старши и младши разработчици, тестери), agile екипът е много по-хомогенен. Ролите са по-малко и всички, заети с писането на код са едновременно и дизайнери, и архитекти, и програмисти, и тестери (това е основен аргумент на критиците на Agile). Всичко изброено предполага малък екип от много добри професионалисти, компетентни едновременно в много области. Класическата схема на няколко тим лидери, малко старши и огромен брой младши програмисти е неприложима. Малкият екип от добри професионалисти сам решава какви процедури за комуникация и следене на процесите да прилага.
  2. Чести инсталации на работеща система. Много важно е клиентът да има във всеки момент работеща система, която постоянно се развива и допълва. Всички agile методики предполагат къси итерации на разработка (от 1 седмица до 1 месец), които предварително се договарят с клиента. В края на итерацията клиентът получава коректно работеща система и се договарят функционалностите, които да бъдат реализирани в следващата итерация. Клиентът решава кои функционалности да бъдат включени в следващата итерация. Това има две предимства. Първо клиентът преценява кое е най-важното за него в дадения момент. По този начин се максимизира неговата полза от системата през цялото време на разработката. Второ, дизайнът и реализацията на съответната функционалност става в последния възможен момент, което премахва опасността от разлики между изискванията и реализацията. Фактически това е основната agile практика. Постоянно развиващият се дизайн също е основен аргумент на критиците на agile Според тях динамичният дизайн означава липса на дизайн и цялостна архитектура. Контра аргументът е, че в повечето случаи това означава по-модулна и разширяема архитектура.
  3. Постоянно обучение. Този принцип има два аспекта. Първият е самообучението на екипа как да бъде по-ефективен. Всички конкретни реализации на Agile методологията имат специални практики на анализ в края на всеки цикъл за да се открият начини за подобряване на екипната работа в следващите цикли. Вторият аспект е свързан с конкретния проект, по който се работи. Вече сме наясно, че клиентът на системата не може да представи всички свои изисквания в началото. Те възникват по време на изпълнението. По същия начин разработващият екип не знае всичко за конкретната област на клиента – тези знания трябва да се попълват в движение. За да бъде ефективна комуникацията с клиента трябва както разработващият екип (или негов представител) да е „в час“ с това какво прави клиентът и как точно го прави. Ако в края на поредния цикъл клиентът изведнъж поиска нещо, за което само сме чували, но нямаме представа какво е, комуникацията ще се затрудни. За да избегнем това ние трябва предварително да планираме поетапното запознаване на екипа с областта на клиента и обратно – клиентът е добре да познава предимствата, рисковете и цената на технологиите, които ние използваме. Това взаимно обучение трябва да се планира така, че да не пречи на комуникацията между „двата свята“ и на гладкото развитие на проекта.
  4. Прозрачна и всеобхватна комуникация. Този принцип изисква да няма никакви пречки в комуникацията между хората и всички инструменти за планиране и отчетност да са изложени на видно място. Предпочитат се директни срещи (лице в лице), а не теле-конференции. В много от методиките се изисква целият екип да работи в едно помещение, за да може всеки да говори с всеки по всяко време. За публикуване на целите и резултатите се използват бели дъски, на които има специални секции за отбелязване на текущи задачи, резултати и проблеми. Наред със свободната неформална комуникация има и строго периодични на срещи и обсъждания на целия екип (в някои методики те са ежедневни). Представител на клиента е добре дошъл в залата на екипа и дори може да му се оборудва специално работно място.
  5. Често и всеобхватно тестване. Една от основните цели на Agile е постигане на много по-добро качество на софтуера. Принципно положение е, че „качеството не се обсъжда“ - всяка намерена грешка в софтуера се отстранява с приоритет и това е единственото нещо с приоритет. Ето защо от особен интерес на екипа е грешките да бъдат сведени до минимум и откривани на ранен етап. Оттук идва изискването за постоянно и всеобхватно тестване на всеки етап от цикъла. Това естествено може да стане само с използване на автоматични средства за тестване.
  6. Измерване на стойността. Какво ще се разработва в следващия цикъл се определя от клиента. Във всички методики се приема, че на края на всеки цикъл клиентът прави класация на оставащите задачи по важност и най-важните се включват в следващия цикъл на разработка. По такъв начин екипът постоянно работи върху тези части на системата, които клиентът смята за най-важни. Когато те се завършат, клиентът може да започне да ги използва веднага. По такъв начин през цялото време на разработката се максимизира полезността за клиента. Така се намалява и риска за клиента, ако на даден етап финансирането свърши – той ще е сигурен, че е получил максимална полза за парите си.
  7. Разчистване на пътя. Всеки член на един Agile екип е длъжен да се включва в идентифицирането и преодоляването на проблемите. Няма такова нещо, което да пречи на работата и да не интересува всички. Всички трябва да търсят решение, което да не позволи на проблема да се появи отново.

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

Йордан Николов

Виж оригинала