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

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

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

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

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

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

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