Задачи срещу отговорности (Agile vs Waterfall)

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

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

Защо “културата на организацията” е толкова често обсъждана точка на пречупване и толкова ли е сложно да се намери правилното партньорско сечение между хората, изпълняващи различни задачи в една система? Бих желал да хвърля малко по-различен поглед върху тази перспектива, сравнявайки Agile и Waterfall процесите на доставяне на продукти.

В добре финансирана “Waterfall” среда, отговорностите на работещите са по-скоро технологични, отколкото бизнес ориентирани. От тях се очаква да работят по отредените им във времеви прозорец задачи, да ги изпълняват добре, да интегрират добре един компонент с друг, да доставят качество на кода, TDD и т.н. Комфортът на заданията в един Waterfall проект е привидно осигурен от анализационна мрежа от задачи и роли, действали доста преди етапа на разработка. И Waterfall моделът работи добре, стига да виреем в богата флора с не особено взискателна фауна.

Agile променя скъпата парадигма и поставя видимостта, резултатите и финансовата оптимизация пред спокойствието на процеса. Очакванията към “старшинството”, както обичаме да го наричаме, се трансформират (но не изключват) от технологични към комуникационни и анализаторски – с голяма лична отговорност към успеха на продукта. Предварителното планиране включва дефиниции на високо ниво под формата на Epics, User Stories, като единственият помощник в изпълнението е нашият Scrum Master. Все още на екипно и управленско ниво съществува разбирането, че Scrum Master представлява магическа комбинация между бизнес анализатор, собственик на продукта, управляващ проекта и всичко необходимо, за да направи нашият живот Waterfall. Уви, ролята на това митично създание е единствено да разбира нашите проблеми и да ни свързва с най-подходящите хора, способни да ги решат.

Къде тогава остава решението колко време ще отнеме изпълнението на User Story, което така нагло сме оценили с точки, а не с дни? А ако не мога да се справя с нещо в списъка си със задачи? Кой трябва да се притеснява дали ще завършим навреме? Но аз съм програмист, пиша добре код, защо трябва да се грижа за такива неща?

Отговорът е в “старшинството” или иначе казано – зрелостта на разработчика. Време е да приемем, че започвайки работа, ние не се наемаме да вършим върволица от задачи, а поемаме отговорност към проекти.

В симбиоза с всички в организацията ние трябва да предоставяме качество, да общуваме, да споделяме и да доставяме резултат. Scrum Master е нашият прозорец към хората, които имат отговори и решения на нашите въпроси, но ангажиментът за крайния резултат е наш. И това имат предвид работодателите, поставяйки английската думичка “senior” в своите обяви.

В заключение ще кажа, че технологиите се научават, качеството на кода се налага със съответните инструменти, задачите преминават от един спринт в друг, когато не можем да се справим с тях. Отговорността, обаче, е факторът, който се цени и ни гарантира съвместимостта, с която и да е успешна организация. Отговорността така, както е определена oт Agile.

Споделете вашия опит в трансформацията – имали ли сте “методологични различия”, как сте ги преодолявали?

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close