Гъвкавото разработване на софтуер е метод, който в крайна сметка спестява пари на потребителските организации. За да бъде този метод успешен, прозрачността е от фундаментално значение. Липсата на прозрачност обичайно е сигнал за проблем и може да доведе един потенциално отличен проект до несполучлив край.
Гъвкавостта срещу „водопада“
Добил известност повече като „Agile”, гъвкавият метод за разработване на софтуер предполага създаване на малки части от цялостна софтуерна система на кратки интервали от време. Тези кратки „спринтове“ на софтуерния екип обичайно завършват със срещи с потребителя и представяне на постигнатия напредък.
Методът се явява контрапункт на традиционния подход в създаването на софтуер, при който на софтуерния екип се възлага задание, работата протича в продължение на много месеци, а накрая се предава „готов продукт“. Този подход в софтуерния бранш наричат „водопаден“.
Agile като танц
След всеки завършен малък етап, софтуерният екип се среща с потребителската организация – в лицето на неин представител или екип – и представя разработените функции, работещите такива, откритите бъгове, направените промени. Подобни срещи обичайно се случват през 2-3 седмици. На такъв етап потребителят може незабавно да прецени дали дадена функция ще му върши работа или не. Ако тя не е „правилна“, той може да преосмисли очакванията си и да промени изискванията към софтуера.
Взаимодействието между двете организации изцяло излиза от познатия стереотип „възложител-изпълнител“. То се явява по-скоро танц между двама равностойни партньори, които са в постоянна връзка един с друг и взаимно следват движенията си.
„Точно така трябва да се разглежда процесът на взаимодействие, а трудността в неговото възприемане сред потребителските организации е много ясно видима от компании, които за първи път прилагат Agile методи“, казва Мартин Кулов, председател на Асоциация на софтуерните инженери (АСЕ), която организира обучение за гъвкави техники за разработка в СТЦ Интерпред. „Клиентите, които не са свикнали с Agile практиките, нямат увереност, че компанията може да им свърши работа. Те очакват, по традиционния метод, дадената функционалност да е готова на дадената дата срещу даден бюджет“.
Доверието като функция на прозрачността
Подобно доверие се изгражда трудно, с течение на времето, признават софтуерните експерти. „Потребителят следва да си даде сметка, че всъщност той ще спести пари чрез Agile методологията, защото при възникване на проблем или нужда от промяна, това може да стане много бързо и лесно – и няма да му излезе солено, както би се случило, ако получи всичко накуп в края на софтуерния проект и чак тогава установи, че нещо не е както би искал да бъде“, казва Кулов.
Подобно доверие трудно се гласува от клиентите у нас, но пък е „по подразбиране“ при потребителските организации, работещи в добре развити пазари като американския и западноевропейския, смята Никола Богданов, старши Scrum ръководител във „Fourth“ и лектор на форума 2DoIT Agile Decoded. Според него, западните клиенти са склонни да подхождат с доверие в партньорите си, защото самият факт, че са седнали на една маса да се договарят, е достатъчно показателен, че всички искат да вършат смислена работа и никой не желае да се компрометира.
Но независимо от първоначалната степен на доверие към софтуерния разработчик, ключова роля в комуникацията и решаваща за доверието към него е прозрачността. Откритото общуване помага на потребителската организация да добие увереност в доброто развитие на проекта. Това означава с всеки „спринт“ разработчикът да представя на клиента новосъздадените компоненти и избраните за следващата итерация от работата, както и да бъде пределно откровен за откритите дефекти, възникналите трудности, а в случаите на забавяне – за причините. Подобна откритост създава у потребителя доверие. Това на свой ред се отплаща на развойния екип: той може да очаква все по-голямо „овластяване“ да взема решения за бъдещите итерации от проекта.
Кипеж под капака
„Има един труден психологически ефект. Някои аутсорсинг компании не могат да приемат този начин на комуникация. Те са категорични: „моят клиент никога няма да види тези неща!“ и подробностите се запазват в тайна, а подобен подход не постила с доверие отношенията с потребителя“, предупреждава Кулов. Въпросната потайност обаче е типична за фирми, чиито екипи работят едновременно по няколко проекта. А това, от своя страна, означава риск. Екипите, въвлечени в няколко проекта едновременно, неизбежно се натъкват на проблем с „прегаряне“ на хората. Претоварването ги изтощава.
„Трябва да е ясно, че ако няма прозрачност в отношенията между софтуерния разработчик и неговия клиент, то значи нещо се случва „под капака“ и това е сигнал за риск“, предупреждава Кулов.
по-добре всяка фирма да има собствен екип от IT специалисти и програмисти. това ще олекути и безработицата. иначе всичко друго е глупости, главоболи и далавери