Hola amics. Molt sovint, sobretot en l'externalització, veig la mateixa imatge. Manca d'un flux de treball clar en equips en diferents projectes.
El més important és que els programadors no entenguin com comunicar-se amb el client i entre ells. Com construir un procés continu de desenvolupament d'un producte de qualitat. Com planificar la jornada laboral i els sprints.
I tot això, en última instància, es tradueix en terminis perduts, hores extres, enfrontaments constants sobre qui té la culpa i insatisfacció dels clients amb on i com es mou tot. Molt sovint, tot això comporta un canvi de programadors, o fins i tot d'equips sencers. Pèrdua d'un client, deteriorament de la reputació, etc.
En un moment, vaig acabar en un projecte així, on hi havia totes aquestes delícies.
Ningú volia assumir la responsabilitat del projecte (un gran mercat de serveis), la facturació va ser terrible, el client simplement estava esquinçat i frustrat. El CEO una vegada es va acostar a mi i em va dir que tens l'experiència necessària, així que aquí tens les cartes a les teves mans. Agafa el projecte per tu mateix. Si ho fa mal, tancarem el projecte i expulsarem tothom. Funcionarà, serà genial, després lidereu-lo i desenvolupeu-lo com us convingui. Com a resultat, em vaig convertir en el líder de l'equip del projecte i tot va caure sobre les meves espatlles.
El primer que vaig fer va ser desenvolupar un flux de treball des de zero que s'alineava amb la meva visió en aquell moment i va escriure una descripció de la feina per a l'equip. No va ser fàcil d'implementar. Però al cap d'un mes aproximadament tot es va assentar, els desenvolupadors i el client s'hi van acostumar i tot va anar tranquil·lament i còmodament. Per demostrar a l'equip que això no era només una "tempesta en una tassa de te", sinó una sortida real a la situació, vaig assumir el màxim de responsabilitats, eliminant la rutina desagradable de l'equip.
Ja ha passat un any i mig, i el projecte es desenvolupa sense hores extres, sense “curses de rates” i tota mena d'estrès. Algunes persones de l'antic equip no volien treballar així i se'n van anar; d'altres, al contrari, estaven molt contents que haguessin aparegut unes regles transparents. Però al final, tots els membres de l'equip estan molt motivats i coneixen l'enorme projecte al complet, tant del front-end com del back-end. Inclou tant el codi base com tota la lògica empresarial. Fins i tot s'ha arribat al punt que no som només “remers”, sinó que nosaltres mateixos aconseguim molts processos empresarials i noves característiques que van resultar agradar al negoci.
Gràcies a aquest plantejament per part nostra, el client va decidir demanar un altre marketplace a la nostra empresa, la qual cosa és una bona notícia.
Com que això funciona en el meu projecte, potser també ajudarà a algú. Així doncs, el procés en si que ens va ajudar a salvar el projecte:
El procés de treball en equip en el projecte "El meu projecte preferit"
a) Procés intern d'equip (entre desenvolupadors)
- Tots els problemes es creen al sistema Jira
- Cada tasca s'ha de descriure tant com sigui possible i realitzar estrictament una acció
- Qualsevol característica, si és prou complexa, es divideix en moltes tasques petites
- L'equip treballa en funcions com una única tasca. Primer, treballem tots junts en una funció, l'enviem a prova i després fem la següent.
- Cada tasca està marcada, per al backend o el frontend
- Hi ha tipus de tasques i errors. Cal indicar-los correctament.
- Després de completar una tasca, es transfereix a l'estat de revisió de codi (en aquest cas, es crea una sol·licitud d'extracció per a un col·lega)
- La persona que ha completat la tasca fa un seguiment immediatament del seu temps per a aquesta tasca.
- Després de comprovar el codi, el PR l'aprovarà i, després d'això, el que ha realitzat aquesta tasca de forma independent la fusiona a la branca mestra, després de la qual cosa canvia el seu estat a llest per al desplegament al servidor de desenvolupament.
- Totes les tasques preparades per al desplegament al servidor de desenvolupament són desplegades pel cap de l'equip (la seva àrea de responsabilitat), de vegades per un membre de l'equip, si alguna cosa és urgent. Després del desplegament, totes les tasques des de llestes per al desplegament fins al desenvolupador es transfereixen a l'estat: llestes per a la prova al desenvolupament
- Totes les tasques són provades pel client
- Quan el client ha provat la tasca al desenvolupador, la transfereix a l'estat llest per al desplegament a producció
- Per al desplegament a producció, tenim una branca separada, on fusionem el mestre només abans del desplegament
- Si durant la prova, el client troba errors, retorna la tasca per a la revisió, establint-ne l'estat com a retornat per a la revisió. D'aquesta manera separem les tasques noves de les que no han superat les proves.
- Com a resultat, totes les tasques van des de la creació fins a la finalització: Per fer → En desenvolupament → Revisió del codi → Desplegament a punt per al desenvolupador → Control de qualitat al desenvolupador → (Tornar al desenvolupador) → Desplegar a punt per a la producció → QA en producte → Fet
- Cada desenvolupador prova el seu codi de manera independent, inclòs com a usuari del lloc. No està permès fusionar una branca amb la principal tret que se sàpiga amb certesa que el codi funciona.
- Cada tasca té prioritats. Les prioritats les estableix el client o el líder de l'equip.
- Els desenvolupadors completen primer les tasques prioritàries.
- Els desenvolupadors poden assignar-se tasques entre ells si s'han trobat diferents errors al sistema o una tasca consisteix en el treball de diversos especialistes.
- Totes les tasques que crea el client van al cap de l'equip, que les avalua i demana al client que les modifiqui o les assigna a un dels membres de l'equip.
- Totes les tasques que estan preparades per al desplegament per a desenvolupament o producció també van al cap de l'equip, que determina de manera independent quan i com dur a terme el desplegament. Després de cada desplegament, el cap de l'equip (o membre de l'equip) ha de notificar-ho al client. I també canvieu els estats de les tasques a llest per a la prova per a desenvolupament/cont.
- Cada dia a la mateixa hora (per nosaltres és a les 12.00) fem una reunió entre tots els membres de l'equip
- Tothom a la reunió informa, inclòs el líder de l'equip, del que van fer ahir i del que pensen fer avui. Què no funciona i per què. D'aquesta manera, tot l'equip és conscient de qui està fent què i en quina fase es troba el projecte. Això ens dóna l'oportunitat de predir i ajustar, si cal, les nostres estimacions i terminis.
- A la reunió, el responsable de l'equip també parla de tots els canvis en el projecte i del nivell d'errors actuals que el client no ha trobat. Tots els errors es resolen i s'assignen a cada membre de l'equip per resoldre'ls.
- En la reunió, el cap de l'equip assigna tasques a cada persona, tenint en compte la càrrega de treball actual dels desenvolupadors, el seu nivell de formació professional, i també tenint en compte la proximitat d'una determinada tasca amb allò que el desenvolupador està fent actualment.
- A la reunió, el cap de l'equip desenvolupa una estratègia general d'arquitectura i lògica empresarial. Després d'això, tot l'equip ho discuteix i decideix fer ajustos o adoptar aquesta estratègia.
- Cada desenvolupador escriu codi i crea algorismes de manera independent en el marc d'una única arquitectura i lògica empresarial. Tothom pot expressar la seva visió de la implementació, però ningú no obliga ningú a fer-ho d'aquesta manera i no d'una altra manera. Tota decisió està justificada. Si hi ha una solució millor, però ara no hi ha temps, es crea una tasca en greix per a la futura refactorització d'una determinada part del codi.
- Quan un desenvolupador assumeix una tasca, la transfereix a l'estat de desenvolupament. Tota la comunicació relativa a l'aclariment de la tasca amb el client recau sobre les espatlles del desenvolupador. Es poden fer preguntes tècniques al cap de l'equip o als companys.
- Si el desenvolupador no entén l'essència de la tasca i el client no ha pogut explicar-la clarament, passa a la següent tasca. I el responsable de l'equip agafa l'actual i ho discuteix amb el client.
- Cada dia, el desenvolupador hauria d'escriure al xat del client sobre quines tasques va treballar ahir i quines tasques treballarà avui.
- El procés de treball es desenvolupa segons Scrum. Tot es divideix en sprints. Cada sprint dura dues setmanes.
- Els sprints són creats, omplerts i tancats pel líder de l'equip.
- Si el projecte té uns terminis estrictes, intentem estimar aproximadament totes les tasques. I els ajuntem en un sprint. Si el client intenta afegir més tasques a l'sprint, establim prioritats i transferim algunes altres tasques al següent sprint.
b) Procés de treball amb el client
- Cada desenvolupador pot i ha de comunicar-se amb el client
- El client no pot imposar les seves pròpies regles de joc. Cal deixar clar al client d'una manera educada i amable que som especialistes en el nostre àmbit, i només nosaltres hem de construir processos de treball i implicar-hi el client.
- És necessari, idealment, abans de començar a implementar qualsevol funcionalitat, crear un diagrama de flux de tot el procés lògic de la característica (flux de treball). I enviar-lo al client per a la seva confirmació. Això només s'aplica a una funcionalitat complexa i no òbvia, per exemple, un sistema de pagament, un sistema de notificació, etc. Això ens permetrà entendre amb més precisió què necessita exactament el client, guardar la documentació de la funció i també assegurar-nos que el client pugui dir en el futur que no vam fer el que va demanar.
- Tots els diagrames/diagrames de flux/lògica, etc. El guardem a Confluence/Fat, on demanem al client que confirmi la correcció de la futura implementació als comentaris.
- Intentem no carregar el client amb detalls tècnics. Si necessitem entendre com ho vol el client, dibuixem algorismes primitius en forma de diagrama de flux que el client pot entendre i corregir/modificar-ho tot ell mateix.
- Si el client troba un error al projecte, us demanem que el descrigueu amb gran detall a Zhira. En quines circumstàncies es va produir, quan, quina seqüència d'accions va dur a terme el client durant les proves. Adjunteu captures de pantalla.
- Intentem cada dia, com a màxim cada dos dies, desplegar-nos al servidor de desenvolupament. Aleshores, el client comença a provar la funcionalitat i el projecte no es manté inactiu. Al mateix temps, això és un indicador per al client que el projecte està en ple desenvolupament i ningú li explica contes de fades.
- Sovint passa que el client no entén del tot el que necessita. Perquè s'està creant un nou negoci, amb processos que encara no s'han establert. Per tant, una situació molt habitual és quan llencem peces senceres de codi a la paperera i redissenyem la lògica de l'aplicació. D'això es dedueix que no hauríeu de cobrir absolutament tot amb proves. Té sentit cobrir només la funcionalitat crítica amb proves, i després només amb reserves.
- Hi ha situacions en què l'equip s'adona que no estem complint els terminis. A continuació, realitzem una auditoria ràpida de les tasques i en informem immediatament al client. Com a manera de sortir de la situació, us suggerim llançar funcionalitats importants i crítiques a temps i deixar la resta per al llançament posterior.
- Si el client comença a plantejar-se diferents tasques del seu cap, comença a fantasejar i explicar amb els dits, aleshores li demanem que ens proporcioni un disseny de pàgina i un flux amb una lògica que hauria de descriure completament el comportament de tot el disseny i els seus elements.
- Abans d'assumir qualsevol tasca, ens hem d'assegurar que aquesta característica està inclosa en els termes del nostre acord/contracte. Si es tracta d'una característica nova que va més enllà dels nostres acords inicials, hem de valorar aquesta funció ((temps de finalització estimat + 30%) x 2) i indicar al client que ens trigarà tant de temps a completar-la, més el el termini es desplaça pel temps estimat multiplicat per dos. Anem a fer la tasca més ràpid: genial, tothom se'n beneficiarà. Si no és així, us tenim cobert.
c) El que no acceptem en un equip:
- Descompromís, falta de compostura, oblit
- "Alimentant l'esmorzar." Si no podeu completar una tasca i no sabeu com, heu de notificar-ho immediatament al responsable de l'equip i no esperar fins a l'últim minut.
- Ceges i presumptes d'una persona que encara no ha demostrat les seves capacitats i professionalitat. Si està demostrat, llavors és possible, dins dels límits de la decència :)
- L'engany en totes les seves formes. Si una tasca no s'ha completat, no hauríeu de canviar el seu estat a completada i escriure al xat del client que està llesta. L'ordinador es va avariar, el sistema es va estavellar, el gos va mastegar l'ordinador portàtil: tot això és inacceptable. Si es produeix un esdeveniment de força major real, s'ha de notificar immediatament al cap de l'equip.
- Quan un especialista està fora de línia tot el temps i és difícil arribar-hi durant l'horari laboral.
- No es permet la toxicitat a l'equip! Si algú no està d'acord amb alguna cosa, llavors tothom es reuneix per a una reunió i discuteix i decideix sobre això.
I una sèrie de preguntes/tesis que de vegades faig al meu client per aclarir tots els malentesos:
- Quins són els vostres criteris de qualitat?
- Com es determina si un projecte té problemes o no?
- En violar totes les nostres recomanacions i consells per canviar/millorar el sistema, tots els riscos els assumeixes només tu
- Qualsevol canvi important al projecte (per exemple, tot tipus de flux addicional) provocarà la possible aparició d'errors (que, per descomptat, solucionarem)
- És impossible entendre en un parell de minuts quin tipus de problema s'ha produït al projecte, i molt menys solucionar-lo immediatament
- Treballem en un flux de producte específic (Tasques a Zhira - Desenvolupament - Proves - Desplegament). Això vol dir que no podem respondre a tot el flux de sol·licituds i queixes al xat.
- Els programadors són programadors, no provadors professionals, i no poden garantir la qualitat adequada de les proves del projecte
- La responsabilitat de les proves finals i l'acceptació de les tasques de producció recau completament en vostè
- Si ja hem assumit una tasca, no podem canviar immediatament a altres fins que finalitzem l'actual (en cas contrari això comporta encara més errors i un augment del temps de desenvolupament)
- Hi ha menys gent a l'equip (per vacances o malalties), però hi ha més feina i físicament no tindrem temps per respondre tot el que vulguis
- Us demanem que feu un desplegament a la producció sense tasques provades al desenvolupament; aquest és només el vostre risc, no els desenvolupadors.
- Quan configureu tasques poc clares, sense un flux correcte, sense dissenys de disseny, això requereix molt més esforç i temps d'implementació per part nostra, ja que hem de fer una quantitat addicional de treball en comptes de vosaltres.
- Qualsevol tasca sobre errors, sense una descripció detallada de la seva aparició i captures de pantalla, no ens dóna l'oportunitat d'entendre què ha fallat i com podem solucionar aquest error.
- El projecte requereix un perfeccionament i millores constants per millorar el rendiment i la seguretat. Per tant, l'equip dedica part del seu temps a aquestes millores
- Pel fet de tenir hores extraordinàries per hores (correccions urgents), les hem de compensar els altres dies
Per regla general, el client entén immediatament que tot no és tan senzill en el desenvolupament de programari, i el desig per si sol és clarament insuficient.
En general, això és tot. Deixo darrere de les escenes moltes negociacions i la depuració inicial de tots els processos, però com a resultat, tot va funcionar. Puc dir que aquest procés es va convertir en una mena de "bala de plata" per a nosaltres. La gent nova que va venir al projecte es va poder implicar immediatament en el treball des del primer dia, ja que es van descriure tots els processos, i la documentació i l'arquitectura en forma de diagrames van donar de seguida una idea del que estàvem fent aquí.
PD M'agradaria aclarir que no hi ha cap director de projecte al nostre costat. És del costat del client. No és gens un tècnic. projecte europeu. Tota la comunicació és només en anglès.
Molta sort a tots en els projectes. No us esgoteu i intenteu millorar els vostres processos.
Font a la meva .
Font: www.habr.com