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