Десислава Ташева е Lead Change and Release Analyst във Fourth – водещият световен доставчик на облачни решения в сферата на хотелиерството и ресторантьорството. Десислава сподели с нас повече за своята позиция и ролята ѝ в цикъла на софтуерната разработка.
Позицията „Change and Release Analyst” е по-малко позната. Как бихте я описали?
Действително позицията “Change and Release Analyst” не е толкова позната сред софтуерните компании, но пък от своя страна играе ключова роля в цикъла на разработка на софтуер, както и процесът на управление, планиране и контролиране на неговите нови, или обновени версии. Всичко това се случва през различните етапи на софтуерна разработка, в различни среди, преди да достигне до крайния потребител – клиентът.
Как избрахте да се развивате в тази сфера и роля?
При мен това се случи спонтанно. Тъй като имах дълъг опит в Change and Release процеса в Waterfall методологията, достигането на следващ етап от моето развитие стана съвсем естествено. Видях, че мога да работя с Change and Release не само в Waterfall, но и в Agile моделите, използвани днес от повечето софтуерни компании. Това беше една кариерна стъпка, която разшири моите знания и ми даде възможност да се усъвършенствам.
А каква всъщност е разликата между двата модела – Waterfall и Agile?
Waterfall (от англиийски „Каскаден модел”) работи по фиксиран ред и екипът не отива на следващ етап от разработка или тестване, докато предишната стъпка не е завършена успешно.
Днес актуален е гъвкавият модел за разработка на софтуер „Agile”, чрез който компаниите целят да доставят на клиентите си качествен софтуер, бързо и навременно. Непрекъснатото повторение на етапите в процеса на софтуерна разработка е част от Agile методологията. Тук разработката и тестването се извършват едновременно, за разлика от Waterfall. Това води до повече общуване между клиенти, разработчици, мениджъри и специалисти по тестване.
Как бихте описали един Ваш работен ден?
Един мой работен ден, естествено, започва с чаша кафе. След това продължавам със задачките за деня. Всеки ден е различен – може да бъде както по-динамичен, така и по-спокоен. По принцип стартирам работата с преглед на всички release-и и промени, направени предишния ден. Продължавам с преглед на e-mail-ите си, анализ на предстоящото за деня и всички release-и за текущия ден или седмица. Следва комуникация със съответните екипи с цел идентификация и оценка на рискове, както и информиране на клиентите какво предстои да получат като обновление и промени по софтуера.
С кои екипи работи един Change and Release Analyst?
Главно работим със софтуерни екипи, състоящи се от програмисти и QA специалисти, а също и с Cloud Ops екипи. Мога да кажа, че връзката между Change and Release Анализатора, софтуерните и Cloud Ops екипите е водеща за целия успешен release, преди той да стигне до потребителя.
Кое е най-предизвикателното в работата Ви със софтуерните екипи?
Работата със софтуерните екипи действително може да бъде доста предизвикателна. Предизвикателството не е едно, особено когато говорим за екипи от хора, свикнали да работят на пълни обороти, да следват срокове, да бъдат проактивни. Едно от предизвикателствата, които аз имах в самото начало на своята работа, бе свързано с изграждане на процеса ни. Тогава целта ни бе да създадем общ Change and Release процес, който да е ясен и бърз за екипите, без да ги затруднява да подготвят внедряването на софтуера и достигането му до крайния клиент.
Бихте ли споделили добри практики в Change and Release процеса?
На първо място слагам автоматизацията. Тя е доста нашумяла и има защо, тъй като спестява време и намалява риска от човешка грешка. Следете за всяка възможност за автоматизиране на тестовете и внедряването на софтуера. Друг важен момент е самият Change and Release процес да бъде изграден с ясни и точни критерии, роли и отговорности. Той трябва да бъде добре дефиниран и всички екипи в него да могат да го използват възможно най-ефективно.
Какво представлява Release процесът в DevOps контекст?
Както вече споменах, този процес е част от целия цикъл на софтуерната разработка. Освен това е и последната стъпка преди софтуерът да достигне до клиента. Процесът съдържа критерии, на които софтуерът да отговаря, преди да бъде финализиран. Така се създава последователност и прозрачност на информацията какво и кога се предоставя на клиента, какви промени и функционалности включва и кой го внедрява. След като цялата информация бъде записана и представена, вече е възможно да се направят анализи и подобрения.
Крайната ни цел е да подпомогнем екипите, да избегнем проблеми, да минимизираме рискове, които могат да засегнат клиентите и да доставяме непрекъснато софтуер с високо качество.
Откъде се информирате за новостите във Вашата професия? Какъв източник на информация предпочитате?
Главно от интернет. Следя различни форуми и статии, както в LinkedIn, така и в различни IT сайтове.
Какъв опит и образование трябва да има човек, за да стане успешен Release Analyst?
Аз имам техническо образование от ТУ, но конкретно в тази сфера смятам, че ключово е допълнителното сертифициране. Мога да дам за пример ITIL сертификата, който представлява набор от правила и принципи, спомагащи за изграждането на систематичен подход за изпълнение на IT процеси.
Друг важен сертификат е Scaled Agile Framework (SAFe). Той също предоставя набор от организационни и работни модели за насърчаване на компаниите към мащабни и гъвкави практики. SAFe помага за подобрение на структурата на софтуерните компании, които искат да се разрастват и да усъвършенстват своите вътрешни процеси.
С какво Fourth Ви спечели като работодател?
Главно с това, че компанията притежава наистина отлична политика към своите служители. За мен е много ценно, че Fourth всеки ден полага грижи и инвестира в нас. Корпоративната култура, отношенията между колегите и общите ценности, различните възможности за развитие – те са движещата сила, която мотивира екипите ни и ги кара да се чувстват оценени. Гордея се да бъда част от екип от изключителни професионалисти, стремящи се към постоянно подобрение.
Интервюто проведе Вяра Стефчева.
