Недавно сам присуствовао ДевОпсФорум 2019, чији је домаћин био Логроцон. На овој конференцији учесници су покушали да пронађу решења и нове алате за ефикасну интеракцију између бизниса и стручњака за развој и услуге информационих технологија.
Конференција је успела: било је заиста много корисних извештаја, занимљивих формата презентације и доста комуникације са говорницима. А посебно је важно што нико ништа није покушао да ми прода, за шта су у последње време криви говорници на великим конференцијама.
Одломак из говора Раиффеисенбанк, Алфастракхование, искуства Манго Телецома у имплементацији аутоматизације и други детаљи испод реза.
Зовем се Иана, радим као тестер, бавим се аутоматизацијом, као и ДевОпс-ом, и волим да идем на конференције и састанке. Током протекле две године био сам на конференцијама Олега Бунина (ХигхЛоад++, ТеамЛеад Цонф), Југ догађајима (Хеисенбуг, ЈПоинт), ТестЦон Москва, ДевОпс Про Москва, Биг Дата Москва.
Пре свега скрећем пажњу на програм конференције. Мање гледам о чему ће извештај бити, а више на говорника. Чак и ако се извештај покаже веома технолошким и занимљивим, није чињеница да ћете неке од најбољих пракси из извештаја моћи да примените у својој компанији. А онда вам треба звучник.
Светло на крају гасовода у Раиффеисенбанк
Обично по страни тражим звучнике који ме занимају. На ДевОпсФорум-у 2019, говорник из Раиффеисенбанке, Микхаил Бизхан, ме је заинтересовао. Током свог говора, говорио је о томе како постепено навлаче своје тимове на ДевОпс, зашто им је то потребно и како да продају идеју ДевОпс трансформације бизнису. Па, генерално, причао сам о томе како видети светло на крају цевовода.
Микхаил Бизхан, директор аутоматизације у Раиффеисенбанк
Сада немају „ДевОпс“ у својој компанији. Односно, ради, али не у свим тимовима. Приликом имплементације ДевОпс-а ослањају се на спремност тимова, како у погледу конкретних инжењера, тако и у погледу потребе производа и зрелости платформе на којој је овај производ изграђен. Миша је рекао како да објасни бизнису зашто је ДевОпс потребан.
Банкарски сегмент има неколико покретача раста: цене услуга и ширење базе клијената. Повећање цене услуга није баш добар покретач, али повећање базе клијената је супротно. Ако конкуренти издају објективно кул производ, сви купци оду тамо, а онда се временом тржиште изједначи. Стога је увођење нових производа на тржиште и брзина њиховог увођења главна ствар на коју се банке фокусирају. ДевОпс је управо за то и предузећа то разумеју.
Следећа важна напомена: ДевОпс не смањује увек време изласка на тржиште. ДевОпс не може да ради сам, то је само део процеса креирања и довођења производа на тржиште од развоја до производње (од кода до купца). Али све пре кода није директно повезано са ДевОпс-ом. То јест, трговци могу годинама проучавати тржиште и провести цео живот сустижући конкуренте. Неопходно је брзо схватити шта клијенту треба и планирати имплементацију ове или оне функције - често је то оно што ДевОпс-у није довољно да ради и да компанија постигне свој циљ. Стога се, пре свега, Рајфајзенбанка сложила са бизнисом да је неопходно научити како да користи ДевОпс. Аутоматизација зарад аутоматизације неће много помоћи у борби за нове купце.
Генерално, Миша верује да ДевОпс треба имплементирати, али мудро. И морамо бити спремни на чињеницу да ће на почетку трансформације продуктивност тима пасти, зарађивати мање новца, али ће онда бити оправдано.
Аутоматизација тестирања у Манго Телекому
Још један занимљив извештај за мене као тестера дао је Егор Маслов из Манго Телекома. Презентација се звала „Аутоматизација пуног циклуса тестирања у СЦРУМ тиму“. Егор верује да је ДевОпс креиран посебно за СЦРУМ, али је у исто време увођење ДевОпс-а у СЦРУМ тим прилично проблематично. Ово се дешава зато што СЦРУМ тим увек негде трчи, нема времена да се ометају иновацијама и поново изгради процес. Проблем је и у томе што СЦРУМ не подразумева раздвајање подтимова у тиму (тестирајући тим, развојни тим и тако даље). Па, осим тога, за аутоматизацију постојећег процеса потребна је документација, а у СЦРУМ-у најчешће нема комплетне документације – „производ је важнији од неке врсте писања“.
Након преласка на СЦРУМ, тестери су почели да се консултују са програмерима о томе како да тестирају функције. Постепено се повећавао обим функционалности, није било документације, а почели су да хватају много грешака у функционалности која није била покривена тестовима и уопште више није било јасно ко ју је и када тестирао. Укратко - збуњеност и колебање. Одлучили смо да пређемо на аутоматизацију тестирања. Али и тада је дошло до потпуног неуспеха. Ангажовали су спољне стручњаке за аутоматизацију који су писали на стеку непознатом интерним тестерима. Оквир за аутотестове је, наравно, функционисао, али је након одласка спољних сарадника трајао две недеље. Следећи је био покушај да се уведе аутотестирање број два. Почело је са чињеницом да све треба да се изгради унутар компаније, самостално (прави вектор: интерно изградити експертизу), у оквиру СЦРУМ-а и креирати документацију у процесу. Стек за аутоматизацију треба да буде једнак стеку производа (овде га додајем, немојте тестирати свој ЈаваСцрипт пројекат ни са чим другим). На крају спринта, направили су демо како аутотест ради са целим тимом (корисно). Тиме се повећала укљученост свих чланова тима у процес аутоматизације, поверење у аутотестове и шанса да се овај аутотест дефинитивно искористи (и да се неће коментарисати за месец дана због сталних кварова).
Иначе, на ДевОпсФоруму 2019 био је отворен микрофон - одавно познат и, по мом мишљењу, користан формат говора. Овако се шетате, слушате извештаје, а затим одлучујете да на конференцији вреди разговарати о одређеној теми или проблему, поделити релевантно искуство у решавању проблема.
Такође сам приметио да су организатори направили низ кратких извештаја. Сваки извештај траје не више од 10 минута, а затим следе питања. На овај начин можете истовремено да покријете више тема и постављате питања говорницима који вас занимају.
Између презентација, шетао сам по штандовима партнера на конференцији и украо/освојио много ствари. Ох, свиђа ми се материјал!
Округли сто и питања ДевОпс-а са директором развоја у Алфастракхование
Шлаг на торти ДевОпсФорум 2019 за мене је била једносатна пленарна сесија са стручњацима за ДевОпс. Четири учесника сесије су позвана да погледају ДевОпс из различитих углова: Антон Исанин (Алфастракхование, директор развоја), Наилиа Замасхкина (Финтецх Лаб, оперативни директор), Олег Егоркин (Ростелецом, Агиле тренер) и Антон Мартианов (независни стручњак, погледао је ДевОпс). са пословног становишта).
Стручњаци су сели ближе људима и онда су ствари почеле да се дешавају: цео сат су учесници из публике постављали своја питања, а стручњаци су писали. Понекад је било правих дебата. Питања су била веома различита, на пример: да ли су ДевОпс инжењери уопште потребни, зашто не могу да буду обучени за систем администраторе, да ли ДевОпс треба понудити свима, која је његова вредност и тако даље.
Затим сам лично разговарао са Антоном Исанином. Разговарали смо о потреби да се ДевОпс култура донесе у сваки дом и открили мрачну страну ДевОпс трансформације.
Замислимо да су се сви окупили и одлучили да је ДевОпс потребан и производу и послу и тиму. Хајде да га применимо. Све је успело. Издахнули смо. ДевОпс нас је приближио клијенту, сада можемо брзо испунити све његове жеље. Као резултат тога, имамо велико оперативно одељење са строгим прописима и захтевима, које стално проналази недостатке у производу и ствара гомилу захтева. Штавише, свим недостацима се додељује статус „хитно“, чак и ако је клијент неочекивано желео да дугме обоји жутом уместо зеленом. Пројекат расте, број издања расте и, сходно томе, број недостатака и неспоразума нове функционалности од стране клијената. Опс упошљава још 10 људи да буду у току са пријављивањем недостатака, а развојни сектор ангажује још 15 да би био у току са њиховим затварањем. И уместо да уводи нове функције, тим ради са бескрајним СД-овима, објашњавајући функционалност кориснику и подршку истовремено. Као резултат тога, и операције и развој су у послу, али клијент и посао су незадовољни: нове функције се заглављују. Испоставило се да ДевОпс изгледа да постоји, али изгледа да не постоји.
Што се тиче потребе за имплементацијом ДевОпс-а, Антон је јасно рекао да то директно зависи од обима пословања. Ако сервисирање једног клијента годишње компанији донесе милијарду, ДевОпс није потребан (под условом да не морате редовно да уводите нове промене овом клијенту). Све је преливено чоколадом. Али ако посао расте и појави се више клијената, онда се морате придржавати. По правилу, у компанији у почетку нема цоол Опс. Прво исечемо производ, па тек онда схватимо да је потребно да пазимо на сервере и пратимо залихе како би производ функционисао. Тада настаје Опс. Остаје да се разуме да ће Опс, као посебна дивизија, почети да поставља гомилу препрека развоју и да ће све испоруке почети да застоје. То јест, у овом случају, ДевОпс култура је већ релевантна, али не смемо заборавити на њену тамну страну.
Извор: ввв.хабр.цом