Здраво пријатели. Доста често, особено во аутсорсингот, ја гледам истата слика. Недостаток на јасен тек на работа во тимовите на различни проекти.
Најважно е што програмерите не разбираат како да комуницираат со клиентот и едни со други. Како да се изгради континуиран процес на развој на квалитетен производ. Како да го испланирате работниот ден и спринтовите.
И сето ова на крајот резултира со пробиени рокови, прекувремена работа, постојани пресметки за тоа кој е виновен и незадоволство на клиентите - каде и како се движи. Доста често, сето ова води до промена на програмери, па дури и цели тимови. Губење на клиент, влошување на угледот и така натаму.
Едно време, штотуку влегов во еден таков проект, каде што имаше сите овие задоволства.
Никој не сакаше да преземе одговорност за проектот (голем пазар за услуги), прометот беше страшен, клиентот само искина и фрли. Извршниот директор некако ми пријде и ми рече дека го имаш потребното искуство, па ги имаш картите во ваши раце. Земете го проектот за себе. Ако заебете, ќе го затвориме проектот и ќе ги избркаме сите. Ќе испадне, ќе биде кул, потоа водете го и развијте го како што ви одговара. Како резултат на тоа, станав лидер на тимот на проектот и сè падна на моите раменици.
Првото нешто што го направив беше дизајнирање на работен тек од нула што одговараше на мојата визија во тоа време и напишав опис на работата за тимот. Не беше лесно да се спроведе. Но, некаде во рок од еден месец сè се среди, програмерите и клиентот се навикнаа на тоа и сè помина тивко и удобно. За да му покажам на тимот дека ова не е само бура во чаша, туку вистински излез од ситуацијата, презедов максимални обврски, отстранувајќи ја непријатната рутина од тимот.
Веќе помина една и пол година, а проектот се развива без прекувремена работа, без „трки на стаорци“ и секакви стресови. Некој од стариот тим не сакаше да работи така и си замина, напротив, некој навистина влезе во тоа што се појавија транспарентни правила. Но, како резултат на тоа, сите во тимот се многу мотивирани и го знаат огромниот проект во целост, и со преден и со заден дел. Вклучувајќи ја и основата на кодот и целата деловна логика. Дури е дојдено до точка дека не сме само „веслачи“, туку самите смислуваме многу деловни процеси и нови функции што му се допаѓаат на бизнисот.
Благодарение на овој пристап од наша страна, клиентот реши да нарача друг пазар од нашата компанија, што е добра вест.
Бидејќи ова функционира на мојот проект, можеби и ќе помогне некому. Значи, самиот процес, кој ни помогна да го спасиме проектот:
Процесот на тимска работа на проектот „Мојот омилен проект“
а) Во тимски процес (помеѓу развивачите)
- Сите задачи се креирани во системот Jira
- Секоја задача треба да се опише колку што е можно повеќе и да се изврши строго една акција.
- Секоја карактеристика, ако е доволно сложена, е поделена на многу мали задачи
- Тимот работи на функции како единствена задача. Прво, правиме една карактеристика заедно, ја даваме на тестирање, а потоа ја земаме следната.
- Секоја задача е означена како заднински или преден дел
- Постојат типови на задачи и грешки. Треба правилно да ги наведете.
- По завршувањето на задачата, таа се пренесува во статусот на преглед на кодот (се креира барање за повлекување за неговиот колега)
- Оној што ја завршил задачата веднаш го следи своето време за оваа задача
- По проверка на кодот, ПР се одобрува и после тоа, оној што ја извршил оваа задача самостојно ја спојува во главната гранка, по што го менува статусот во подготвен за распоредување на серверот за развој.
- Сите задачи што се подготвени да се распоредат на серверот за развој се распоредени од лидерот на тимот (неговото подрачје на одговорност), понекогаш член на тимот, доколку нешто е итно. По распоредувањето, сите задачи од подготвени за распоредување до dev се префрлени на статус - подготвени за тестирање на dev
- Сите задачи се тестирани од клиентот
- Кога клиентот ќе ја тестира задачата на dev, тој ја пренесува во статус подготвен за распоредување во производство.
- За распоредување во производство, имаме посебна гранка каде што го спојуваме главниот непосредно пред распоредувањето
- Ако за време на тестирањето клиентот најде грешки, тогаш тој ја враќа задачата за ревизија, поставувајќи го нејзиниот статус вратен на ревизија. Така ги одвојуваме новите задачи од оние кои не се тестирани.
- Како резултат на тоа, сите задачи одат од креирање до завршување: Да се направи → Во развој → Преглед на кодот → Подготвен распоред за развој → QA на dev → (Враќање на dev) → Подготвен распоред за производство → QA на прод → Готово
- Секој развивач го тестира својот код независно, вклучително и како корисник на страницата. Не е дозволено спојување на гранка со главната, освен ако не се знае со сигурност дека кодот работи.
- Секоја задача има приоритети. Приоритетите ги поставува или клиентот или лидерот на тимот.
- Програмерите прво ги извршуваат приоритетните задачи.
- Програмерите можат да си доделат задачи едни на други ако се пронајдени различни грешки во системот или една задача се состои од работа на неколку специјалисти.
- Сите задачи што ги создава клиентот се испраќаат до лидерот на тимот, кој ги оценува и или бара од клиентот да ги финализира или ги доделува на некој од членовите на тимот.
- Сите задачи што се подготвени да бидат распоредени на dev или prod, исто така, доаѓаат до лидерот на тимот, кој независно одредува кога и како да се распореди. По секое распоредување, лидерот на тимот (или член на тимот) мора да го извести клиентот за ова. И, исто така, променете ги статусите за задачите во подготвени за тестирање на dev / prod.
- Секој ден во исто време (го имаме во 12.00 часот) одржуваме митинг помеѓу сите членови на тимот
- Сите на релито известуваат, вклучително и лидерот на тимот, што направи вчера, што планира да направи денес. Што не функционира и зошто. Така, целиот тим е свесен кој што прави и во која фаза е проектот. Ова ни дава можност да ги предвидиме и прилагодиме, доколку е потребно, нашите проценки и рокови.
- На состанокот, лидерот на тимот, исто така, ги објавува сите промени во проектот и нивото на тековните багови кои не беа пронајдени од клиентот. Сите грешки се средени и доделени на секој член на тимот да ги реши.
- На митингот, лидерот на тимот доделува задачи за секој, земајќи го предвид моменталниот обем на работа на програмерите, нивното ниво на професионална обука, а исто така земајќи ја предвид близината на одредена задача до она што развивачот моментално го работи.
- На состанокот, лидерот на тимот развива општа стратегија за архитектура и деловна логика. После тоа, целиот тим разговара за ова и одлучува дали да направи прилагодувања или да ја усвои оваа стратегија.
- Секој развивач пишува код и самостојно гради алгоритми во рамките на една архитектура и деловна логика. Секој може да ја изрази својата визија за имплементација, но никој не присилува никого да го прави тоа на овој начин, а не поинаку. Секоја одлука е оправдана. Ако има подобро решение, но сега нема време за тоа, тогаш се создава задача во масти, за идно рефакторирање на одреден дел од кодот.
- Кога развивачот презема задача, тој ја преместува во развојен статус. Целата комуникација во врска со разјаснувањето на задачата со клиентот паѓа на рамениците на инвеститорот. Може да се постават технички прашања до лидерот на тимот или до колегите.
- Ако инвеститорот не ја разбира суштината на задачата, а клиентот не може разумно да ја објасни, тогаш тој продолжува на следната задача. И лидерот на тимот го зема сегашниот и го дискутира со клиентот.
- Секој ден, развивачот треба да пишува во разговорот на клиентот за тоа кои задачи работел вчера и кои задачи ќе работи денес
- Работниот тек се базира на Scrum. Сè е поделено на спринтови. Секој спринт трае две недели.
- Спринтовите ги креира, пополнува и затвора лидерот на тимот.
- Ако проектот има строги рокови, тогаш се обидуваме грубо да ги процениме сите задачи. И ние собираме од нив спринт. Ако клиентот се обиде да додаде повеќе задачи на спринтот, тогаш поставуваме приоритети и префрламе некои други задачи на следниот спринт.
б) Процесот на работа со клиентот
- Секој развивач може и треба да комуницира со клиентот
- Не можете да му дозволите на клиентот да наметне свои правила на игра. Неопходно е на љубезен и пријателски начин да му ставиме до знаење на клиентот дека ние сме специјалисти во нашата област и само ние треба да градиме работни процеси и да го вклучиме клиентот во нив.
- Потребно е, идеално, пред да се продолжи со имплементација на која било функционалност, да се креира дијаграм на тек на целиот логички процес за карактеристика (работен тек). И испратете го на клиентот за потврда. Ова се однесува само на сложена и неочигледна функционалност, на пример, систем за плаќање, систем за известување итн. Ова ќе ви овозможи попрецизно да разберете што точно му треба на клиентот, да ја зачувате документацијата за функцијата, а исто така да се осигурате од фактот дека клиентот во иднина може да каже дека не го направивме тоа што го побара.
- Сите дијаграми/дијаграми на текови/логика итн. заштедуваме во Confluence/Fat, каде што бараме од клиентот во коментарите да ја потврди исправноста на идната имплементација.
- Се трудиме да не го оптоваруваме клиентот со технички детали. Ако ни треба разбирање за тоа како сака клиентот, тогаш цртаме примитивни алгоритми во форма на дијаграм на текови што клиентот може да го разбере и да поправи / модифицира сè сам.
- Ако клиентот најде бубачка во проектот, тогаш ве замолуваме да го опишете детално во Fat. Под кои околности се случило, кога, каков редослед на дејства ги извршил клиентот за време на тестирањето. Ве молиме прикачете слики од екранот.
- Се обидуваме секој ден, максимум секој втор ден, да се распоредиме на серверот за развој. Клиентот потоа започнува со тестирање на функционалноста и проектот не е неактивен. Во исто време, ова е маркер за клиентот дека проектот е во полн развој и никој не му кажува бајки.
- Често се случува клиентот да не разбере целосно што воопшто му треба. Бидејќи тој создава нов бизнис за себе, со процеси кои сè уште не се дебагирани. Затоа, многу честа ситуација е кога фрламе цели парчиња код во ѓубре и ја преобликуваме логиката на апликацијата. Од ова произлегува дека не е неопходно да се покрие апсолутно сè со тестови. Има смисла да се покрие само критичната функционалност со тестови, а потоа и со резервации.
- Има ситуации кога тимот сфаќа дека не се вклопуваме во рокови. Потоа спроведуваме брза ревизија на задачите и веднаш го известуваме клиентот за тоа. Како излез од ситуацијата, предлагаме да ја стартувате важната и критична функционалност на време, а остатокот да го оставите за пост-издавање.
- Ако клиентот почне да смислува различни задачи од неговата глава, почне да фантазира и објаснува на прсти, тогаш бараме од него да ни обезбеди распоред на страницата и да тече со логика што треба целосно да го опише однесувањето на целиот распоред и неговиот елементи.
- Пред да преземеме каква било задача, мора да се увериме дека оваа функција е вклучена во условите на нашиот договор/договор. Ако ова е нова карактеристика што оди подалеку од нашите првични договори, тогаш дефинитивно мора да ја процениме оваа карактеристика ((приближно време на испорака + 30%) x 2) и да му укажеме на клиентот дека ќе ни треба толку многу време да ја завршиме, плус рокот се поместува за проценетото време помножено со два. Да ја направиме задачата побрза - одлично, сите ќе имаат само корист од ова. Ако не, тогаш сме осигурени.
в) Што не прифаќаме во тимот:
- Недоследност, некохерентност, заборавеност
- „Хранење за појадок“. Ако не можете да ја завршите задачата, не знаете како, тогаш треба веднаш да го известите лидерот на тимот за ова, а не да чекате до последното.
- Бровада и фалење од човек кој уште на дело не ги докажал своите можности и професионалност. Ако се докаже, тогаш тоа е можно, во границите на пристојноста 🙂
- Измама во сите нејзини манифестации. Ако задачата не е завршена, тогаш не треба да го менувате нејзиниот статус во завршена и да пишувате во разговорот на клиентот дека е подготвена. Компјутерот падна, системот падна, кучето џвакаше на лаптопот - сето ова е неприфатливо. Доколку дојде до вистинска виша сила, тогаш лидерот на тимот треба веднаш да биде известен.
- Кога специјалист е постојано офлајн и тешко е да се дојде до него во работно време.
- Не е дозволена токсичност во тимот! Ако некој не се согласува со нешто, тогаш сите се собираат на митинг и дискутираат и одлучуваат.
И голем број прашања/тези кои понекогаш ги прашувам од мојот клиент да ги отстранат сите недоразбирања:
- Кои се вашите критериуми за квалитет?
- Како да утврдите дали проектот има проблеми или не?
- Прекршувајќи ги сите наши препораки и совети за промена/подобрување на системот, сите ризици ги сносите само вие
- Секоја голема промена на проектот (на пример, секаков вид дополнителен проток) ќе доведе до можна појава на грешки (кои, се разбира, ќе ги поправиме)
- Невозможно е да се разбере во рок од неколку минути каков проблем се појавил на проектот, а уште повеќе да се поправи токму таму
- Работиме на специфичен проток на производи (Задачи во Жира - Развој - Тестирање - Распоредување). Тоа значи дека не можеме да одговориме на целиот тек на барања и поплаки во разговорот.
- Програмерите се само програмери, а не професионални тестери и не можат да обезбедат соодветен квалитет на тестирањето на проектите
- Одговорноста за финалното тестирање и прифаќањето на задачите при продажба е целосно на вас
- Ако веќе сме преземале некоја задача, тогаш не можеме веднаш да се префрлиме на други додека не ја завршиме тековната (во спротивно ова води до уште повеќе грешки и зголемување на времето за развој)
- Има помалку луѓе во тимот (поради одмори или болести), а има повеќе работа и нема да имаме физички време да одговориме на се што сакате
- Барањето од вас да се распоредите во производство без тестирани задачи на dev е само ваш ризик, а не на развивачот
- Кога поставувате нејасни задачи, без правилен тек, без дизајн распоред, ова бара многу повеќе напор и време за имплементација од нас, бидејќи ние треба да направиме дополнителна количина на работа наместо вас
- Сите задачи за грешки, без детален опис на нивното појавување и слики од екранот, не ни даваат можност да разбереме што тргнало наопаку и како можеме да ја емитуваме оваа грешка
- Проектот бара постојано префинетост и подобрувања за да се подобрат перформансите и безбедноста. Затоа, тимот троши дел од своето време на овие подобрувања.
- Поради тоа што имаме прекувремени часови (итни поправки), мора да ги надоместиме во другите денови
Како по правило, клиентот веднаш разбира дека сè не е толку едноставно во развојот на софтвер, а желбата сама по себе очигледно не е доволна.
Во принцип, ова е сè. Зад сцената, оставам многу преговори и првично дебагирање на сите процеси, но како резултат на тоа, сè успеа. Можам да кажам дека овој процес за нас стана еден вид „сребрен куршум“. Новите луѓе кои дојдоа на проектот веќе можеа веднаш да се впрегнат на работа од првиот ден, бидејќи сите процеси се опишани, а документацијата и архитектурата во форма на дијаграми веднаш дадоа идеја за тоа што сите правиме овде.
П.С. Сакам да појаснам дека од наша страна нема проект менаџер. Тоа е на страната на клиентот. Воопшто не е техничар. европски проект. Целата комуникација е само на англиски јазик.
Среќно на сите во проектите. Не изгорувајте и обидете се да ги подобрите вашите процеси.
извор во мојот .
Извор: www.habr.com