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

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

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

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

План без план

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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