Софтуерната действителност в световен мащаб изисква все повече, по-широкоспектърни и “по-старши” разработчици, а кариерните пазари се стремят към задоволяването на тези потребности, излъчвайки добре подготвени в различните образователни институции кадри. Нивото на технологична завършеност на новите и постоянно инвестиращи в себе си кандидати за парченце работа в гигантския софтуерен сектор е изключително експертно, благодарение на сериозните софтуерни университети, академии и компании, предлагащи обучение от задължително практикуващи доказани експерти в своята област.
Въпреки това се забелязва изключителна подборна предпазливост от страна на компаниите, предлагащи свободни позиции. Главната причина за тази боязливост е често финансова – цената на кандидатите се повишава постоянно заради високите разходи за себеподобряване, което прави реинвестицията в нови служители скъпа и може да доведе един бюджет до и отвъд неговите граници.
Защо “културата на организацията” е толкова често обсъждана точка на пречупване и толкова ли е сложно да се намери правилното партньорско сечение между хората, изпълняващи различни задачи в една система? Бих желал да хвърля малко по-различен поглед върху тази перспектива, сравнявайки Agile и Waterfall процесите на доставяне на продукти.
В добре финансирана “Waterfall” среда, отговорностите на работещите са по-скоро технологични, отколкото бизнес ориентирани. От тях се очаква да работят по отредените им във времеви прозорец задачи, да ги изпълняват добре, да интегрират добре един компонент с друг, да доставят качество на кода, TDD и т.н. Комфортът на заданията в един Waterfall проект е привидно осигурен от анализационна мрежа от задачи и роли, действали доста преди етапа на разработка. И Waterfall моделът работи добре, стига да виреем в богата флора с не особено взискателна фауна.
Agile променя скъпата парадигма и поставя видимостта, резултатите и финансовата оптимизация пред спокойствието на процеса. Очакванията към “старшинството”, както обичаме да го наричаме, се трансформират (но не изключват) от технологични към комуникационни и анализаторски – с голяма лична отговорност към успеха на продукта. Предварителното планиране включва дефиниции на високо ниво под формата на Epics, User Stories, като единственият помощник в изпълнението е нашият Scrum Master. Все още на екипно и управленско ниво съществува разбирането, че Scrum Master представлява магическа комбинация между бизнес анализатор, собственик на продукта, управляващ проекта и всичко необходимо, за да направи нашият живот Waterfall. Уви, ролята на това митично създание е единствено да разбира нашите проблеми и да ни свързва с най-подходящите хора, способни да ги решат.
Къде тогава остава решението колко време ще отнеме изпълнението на User Story, което така нагло сме оценили с точки, а не с дни? А ако не мога да се справя с нещо в списъка си със задачи? Кой трябва да се притеснява дали ще завършим навреме? Но аз съм програмист, пиша добре код, защо трябва да се грижа за такива неща?
Отговорът е в “старшинството” или иначе казано – зрелостта на разработчика. Време е да приемем, че започвайки работа, ние не се наемаме да вършим върволица от задачи, а поемаме отговорност към проекти.
В симбиоза с всички в организацията ние трябва да предоставяме качество, да общуваме, да споделяме и да доставяме резултат. Scrum Master е нашият прозорец към хората, които имат отговори и решения на нашите въпроси, но ангажиментът за крайния резултат е наш. И това имат предвид работодателите, поставяйки английската думичка “senior” в своите обяви.
В заключение ще кажа, че технологиите се научават, качеството на кода се налага със съответните инструменти, задачите преминават от един спринт в друг, когато не можем да се справим с тях. Отговорността, обаче, е факторът, който се цени и ни гарантира съвместимостта, с която и да е успешна организация. Отговорността така, както е определена oт Agile.
Споделете вашия опит в трансформацията – имали ли сте “методологични различия”, как сте ги преодолявали?
