Месечни архиви: март 2017

Как „планът без план“ пести пари

„Бягането на къси разстояния“ при разработката на софтуер дава възможност за навременно откриване на грешки

Може ли да има план без предварително планиране? Оказва се, че не само може, но и че това може да спестява пари.

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

План без план

Трудна е за възприемане идеята, че може да има проект, в който не са предварително ясни всички етапи и не е твърдо дефинирано какъв ще е крайният резултат. За повечето мениджъри подобно поведение изглежда немислимо. „Agile” разработването на софтуер обаче се гордее именно с това. При него планирането става на итерации – къси интервали от време за усилна развойна работа, след всеки от които на потребителя се представят готовите компоненти. Тогава именно се решава каква ще е следващата стъпка: кои елементи ще се разработват при следващата итерация.

Въпросното „бягане на къси разстояния“ дава възможност за навременното откриване на грешки. Самият клиент може навреме да прецени дали предварително заложените от него изисквания са адекватни. Ако не са, или пък просто с течение на времето се налага да се променят – той може да ги коригира в хода на работата.

„Ние приветстваме променящите се изисквания, даже и в напреднал стадий на разработка. Agile процесите прегръщат промяната в името на конкурентното предимство на клиента“, казва Огнян Дренски, директор Продажби и Маркетинг в School of Business Competences, който беше лектор на форума 2DoIT Agile Decoded, организиран от Асоциацията на софтуерните инженери.

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

Намаляване на ефекта на грешката

„Когато работим на къси итерации, по-лесно можем да планираме какво ще предадем на потребителя, а ефектът от грешката е много малък“, обяснява Мартин Кулов, председател на АСИ. „С други думи, ако се окаже, че има проблем, и се наложи да „изхвърлим“ работа за две седмици, това ще е много по-малка щета от това да „изхвърлим“ работа, свършена за два месеца“.

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

„Когато работим на къси итерации, по-лесно можем да планираме какво ще предадем на потребителя, а ефектът от грешката е много малък“, посочи Мартин Кулов

„Имали сме такъв проект: разработихме софтуер с 850 функционалности, но след време се оказа, че от тях реално се използват едва 250“, разказа по време на форума Огнян Дренски. Казусът не е единствен и, уви, класически пример за загуба на ресурси, време и пари, благодарение на „водопадния“ подход на разработване.

Безапелационна мотивация

Най-трудният момент от работата с Agile развоен екип е да се гласува доверие на тима да поеме планирането – итерация по итерация. Не всеки приема лесно идеята, че ще се работи без предварителен план „от край до край“.

Доверяването на развойния екип обаче силно мотивира софтуерните разработчици, посочват от АСЕ. „Когато в екипа има висок морал и мотивация, специалистите в тима искат да продължат да работят. Те не искат да спират. Не са склонни да напускат, дори да им се предлагат много по-изгодни условия на работа другаде,“ казва Мартин Кулов.

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

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

Подобно на взаимоотношението между двама партньори, това взаимно доверие следва да не се влияе от моментни флуктуации в темпото. „Понякога на края на един спринт потребителят може да получи по-малко от очакваното, например три функции, но следващият път навярно ще получи осем“, казва още Кулов.

От решаващо значение за запазването на доверието на потребителя остава прозрачността в работата по Аgile методологията.

<!–

–>

Прозрачността е в основата на Agile практиките

„Трябва да е ясно, че ако няма прозрачност в отношенията между софтуерния разработчик и неговия клиент, то значи нещо се случва „под капака“ и това е сигнал за риск“, заяви Мартин Кулов, председател на АСИ, пред аудиторията на 2DoIT Agile Decoded

Гъвкавото разработване на софтуер е метод, който в крайна сметка спестява пари на потребителските организации. За да бъде този метод успешен, прозрачността е от фундаментално значение. Липсата на прозрачност обичайно е сигнал за проблем и може да доведе един потенциално отличен проект до несполучлив край.

Гъвкавостта срещу „водопада“

Добил известност повече като „Agile”, гъвкавият метод за разработване на софтуер предполага създаване на малки части от цялостна софтуерна система на кратки интервали от време. Тези кратки „спринтове“ на софтуерния екип обичайно завършват със срещи с потребителя и представяне на постигнатия напредък.

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

Agile като танц

След всеки завършен малък етап, софтуерният екип се среща с потребителската организация – в лицето на неин представител или екип – и представя разработените функции, работещите такива, откритите бъгове, направените промени. Подобни срещи обичайно се случват през 2-3 седмици. На такъв етап потребителят може незабавно да прецени дали дадена функция ще му върши работа или не. Ако тя не е „правилна“, той може да преосмисли очакванията си и да промени изискванията към софтуера.

Взаимодействието между двете организации изцяло излиза от познатия стереотип „възложител-изпълнител“. То се явява по-скоро танц между двама равностойни партньори, които са в постоянна връзка един с друг и взаимно следват движенията си.

„Точно така трябва да се разглежда процесът на взаимодействие, а трудността в неговото възприемане сред потребителските организации е много ясно видима от компании, които за първи път прилагат Agile методи“, казва Мартин Кулов, председател на Асоциация на софтуерните инженери (АСЕ), която организира обучение за гъвкави техники за разработка в СТЦ Интерпред. „Клиентите, които не са свикнали с Agile практиките, нямат увереност, че компанията може да им свърши работа. Те очакват, по традиционния метод, дадената функционалност да е готова на дадената дата срещу даден бюджет“.

Доверието като функция на прозрачността

Подобно доверие се изгражда трудно, с течение на времето, признават софтуерните експерти. „Потребителят следва да си даде сметка, че всъщност той ще спести пари чрез Agile методологията, защото при възникване на проблем или нужда от промяна, това може да стане много бързо и лесно – и няма да му излезе солено, както би се случило, ако получи всичко накуп в края на софтуерния проект и чак тогава установи, че нещо не е както би искал да бъде“, казва Кулов.

Западните клиенти са склонни да подхождат с доверие в партньорите си, посочи Никола Богданов, старши Scrum ръководител във „Fourth“

Подобно доверие трудно се гласува от клиентите у нас, но пък е „по подразбиране“ при потребителските организации, работещи в добре развити пазари като американския и западноевропейския, смята Никола Богданов, старши Scrum ръководител във „Fourth“ и лектор на форума 2DoIT Agile Decoded. Според него, западните клиенти са склонни да подхождат с доверие в партньорите си, защото самият факт, че са седнали на една маса да се договарят, е достатъчно показателен, че всички искат да вършат смислена работа и никой не желае да се компрометира.

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

Кипеж под капака

„Има един труден психологически ефект. Някои аутсорсинг компании не могат да приемат този начин на комуникация. Те са категорични: „моят клиент никога няма да види тези неща!“ и подробностите се запазват в тайна, а подобен подход не постила с доверие отношенията с потребителя“, предупреждава Кулов. Въпросната потайност обаче е типична за фирми, чиито екипи работят едновременно по няколко проекта. А това, от своя страна, означава риск. Екипите, въвлечени в няколко проекта едновременно, неизбежно се натъкват на проблем с „прегаряне“ на хората. Претоварването ги изтощава.

„Трябва да е ясно, че ако няма прозрачност в отношенията между софтуерния разработчик и неговия клиент, то значи нещо се случва „под капака“ и това е сигнал за риск“, предупреждава Кулов.

<!–

–>