Organisatioun vum Workflow an engem Team op engem IT-Projet

Moien Frënn. Ganz oft, besonnesch am Outsourcing, gesinn ech datselwecht Bild. Mangel un engem klore Workflow an Teams op verschiddene Projeten.

Déi wichtegst Saach ass datt d'Programméierer net verstinn wéi se mat dem Client a matenee kommunizéieren. Wéi bauen ech e kontinuéierleche Prozess fir e Qualitéitsprodukt z'entwéckelen. Wéi plangt Äre Aarbechtsdag a Sprints.

An dat alles resultéiert schlussendlech a verpasst Deadlines, Iwwerstonnen, konstante Showdowns iwwer wien Schold ass, a Client Onzefriddenheet mat wou a wéi alles sech beweegt. Ganz dacks féiert dat alles zu enger Verännerung vun de Programméierer, oder souguer ganz Teams. Verloscht vun engem Client, Verschlechterung vum Ruff, a sou weider.

Eng Kéier sinn ech just op esou e Projet ukomm, wou et all dës Freed war.

Keen wollt Verantwortung fir de Projet iwwerhuelen (e grousse Servicemaart), den Ëmsaz war schrecklech, de Client war einfach zerräissen a frustréiert. De CEO ass eng Kéier bei mech komm a sot, Dir hutt déi néideg Erfahrung, also hei sinn d'Kaarten an Ären Hänn. Huelt de Projet fir Iech selwer. Wann Dir schrauwen, wäerte mir de Projet zoumaachen a jidderee schloen. Et wäert klappen, et wäert cool sinn, da féiert et an entwéckelt et wéi Dir passt. Als Resultat sinn ech Teamleader fir de Projet ginn an alles ass op meng Schëlleren gefall.

Déi éischt Saach, déi ech gemaach hunn, war e Workflow vun Null z'entwéckelen, dee mat menger Visioun deemools ausgeriicht war, an eng Aarbechtsbeschreiwung fir d'Team geschriwwen huet. Ëmsetzung et war net einfach. Awer bannent engem Mount oder sou huet sech alles niddergelooss, d'Entwéckler an de Client hunn et gewinnt, an alles ass roueg a gemittlech gaangen. Fir d'Equipe ze weisen datt dëst net nëmmen e "Stuerm an engem Teacup" war, mee e richtege Wee aus der Situatioun, hunn ech déi maximal Verantwortung iwwerholl, déi onsympathesch Routine aus der Équipe ewechgeholl.

An en halleft Joer ass scho vergaang, an de Projet entwéckelt sech ouni Iwwerstonnen, ouni "Rattenrennen" an all Zorte vu Stress. Verschidde Leit aus der aler Equipe wollten net esou schaffen an si sinn fortgaang, anerer ware ganz frou, am Géigendeel, datt transparent Reegelen entstane sinn. Awer am Endeffekt ass jiddereen am Team ganz motivéiert a kennt dee grousse Projet voll, souwuel de Front-End wéi och de Back-End. Inklusiv souwuel de Code Basis wéi och all Geschäftslogik. Et ass souguer op de Punkt komm, wou mir net nëmmen "Rouere" sinn, mä mir selwer kommen mat ville Geschäftsprozesser an nei Features, déi d'Geschäft erauskënnt.

Dank dëser Approche vun eiser Säit huet de Client decidéiert eng aner Maartplaz vun eiser Firma ze bestellen, wat gutt Neiegkeet ass.

Well dëst op mengem Projet funktionnéiert, hëlleft et vläicht och engem. Also, de Prozess selwer deen eis gehollef huet de Projet ze retten:

De Prozess vun der Teamaarbecht um Projet "My Favorite Project"

a) Interne Teamprozess (tëscht Entwéckler)

  • All Themen ginn am Jira System erstallt
  • All Aufgab soll sou vill wéi méiglech beschriwwe ginn a strikt eng Aktioun ausféieren
  • All Feature, wann et komplex genuch ass, ass a vill kleng Aufgaben opgedeelt
  • D'Team schafft op Funktiounen als eng eenzeg Aufgab. Als éischt schaffen mir all zesummen un enger Feature, schéckt se fir ze testen, huelt dann déi nächst.
  • All Aufgab ass markéiert, fir de Backend oder Frontend et
  • Et ginn Zorte vun Aufgaben a Käfere. Dir musst se richteg uginn.
  • Nom Ofschloss vun enger Aufgab gëtt se op de Code review Status transferéiert (an dësem Fall gëtt eng Pull Ufro fir e Kolleg erstallt)
  • Déi Persoun, déi d'Aufgab ofgeschloss huet, verfolgt direkt seng Zäit fir dës Aufgab.
  • Nodeems Dir de Code iwwerpréift hutt, stëmmt de PR an duerno deejéinegen, deen dës Aufgab gemaach huet, fusionéiert se onofhängeg an d'Meeschterzweig, duerno ännert hien säi Status op prett fir den Deployment op den Dev Server.
  • All Aufgaben, déi prett sinn fir den Détachement op den Dev-Server, ginn vum Teamleader (säi Verantwortungsberäich) ofgesat, heiansdo vun engem Teammember, wann eppes dréngend ass. Nom Détachement ginn all Aufgabe vu prett fir den Deployment bis Dev op de Status transferéiert - prett fir ze testen op Dev
  • All Aufgabe gi vum Client getest
  • Wann de Client d'Aufgab op der Dev getest huet, transferéiert hien et op de Status prett fir d'Deployment an d'Produktioun
  • Fir den Ofbau op d'Produktioun hu mir eng getrennte Branche, wou mir de Master nëmme virum Ofbau fusionéieren
  • Wann während dem Test de Client Bugs fënnt, gëtt hien d'Aufgab fir d'Revisioun zréck, a setzt säi Status als zréck fir d'Revisioun. Op dës Manéier trennen mir nei Aufgaben vun deenen déi den Test net passéiert hunn.
  • Als Resultat ginn all Aufgabe vu Kreatioun bis Fäerdegstellung: Ze maachen → An der Entwécklung → Code Review → Ready deploy to dev → QA on dev → (Zréck op dev) → Ready deploy to prod → QA on prod → fäerdeg
  • All Entwéckler testt säi Code onofhängeg, och als Site Benotzer. Et ass net erlaabt eng Branche an den Haapt ze fusionéieren ausser et ass sécher bekannt datt de Code funktionnéiert.
  • All Aufgab huet Prioritéite. Prioritéite ginn entweder vum Client oder vum Teamleader gesat.
  • Entwéckler komplett Prioritéit Aufgaben éischt.
  • D'Entwéckler kënnen Aufgaben uneneen zouginn wann verschidde Bugs am System fonnt goufen oder eng Aufgab aus der Aarbecht vu verschiddene Spezialisten besteet.
  • All Aufgaben, déi de Client erstellt, ginn un den Teamleader, deen se evaluéiert an entweder de Client freet se z'änneren oder se un ee vun den Teammemberen zouginn.
  • All Aufgaben, déi prett sinn fir den Deployment ze Dev oder Prod, ginn och un den Teamleader, deen onofhängeg bestëmmt wéini a wéi d'Deployment duerchgefouert gëtt. No all Détachement muss den Teamleader (oder Teammember) de Client doriwwer informéieren. An och d'Status fir Aufgaben änneren fir prett ze testen fir Dev / Cont.
  • All Dag zur selwechter Zäit (fir eis ass et um 12.00 Auer) hale mir eng Versammlung tëscht allen Teammemberen
  • Jiddereen op der Versammlung bericht, och den Teamleader, iwwer wat se gëschter gemaach hunn a wat se haut plangen. Wat net funktionnéiert a firwat. Sou ass d'ganz Team bewosst wien wat mécht a wéi eng Etapp de Projet ass. Dëst gëtt eis d'Méiglechkeet eis Schätzungen an Terminë virauszesoen an unzepassen, wann néideg.
  • Op der Versammlung schwätzt de Teamleader och iwwer all Ännerungen am Projet an den Niveau vun den aktuellen Bugs, déi net vum Client fonnt goufen. All Käfere ginn zortéiert an all Teammember zougewisen fir se ze léisen.
  • Op der Versammlung gëtt den Teamleader Aufgaben un all Persoun zou, andeems d'aktuell Aarbechtslaascht vun den Entwéckler berücksichtegt gëtt, hiren Niveau vun der professioneller Ausbildung, an och d'Proximitéit vun enger bestëmmter Aufgab berécksiichtegt zu deem wat den Entwéckler am Moment mécht.
  • Op der Versammlung entwéckelt den Teamleader eng allgemeng Strategie fir Architektur a Geschäftslogik. Duerno diskutéiert d'ganz Equipe dëst an decidéiert Upassungen ze maachen oder dës Strategie unzehuelen.
  • All Entwéckler schreift Code a baut Algorithmen onofhängeg am Kader vun enger eenzeger Architektur a Geschäftslogik. Jidderee kann seng Visioun vun der Ëmsetzung ausdrécken, awer keen forcéiert iergendeen dat esou ze maachen an net anescht. All Entscheedung ass gerechtfäerdegt. Wann et eng besser Léisung gëtt, awer et gëtt keng Zäit dofir elo, da gëtt eng Aufgab am Fett geschaf fir d'Zukunft Refactoring vun engem bestëmmten Deel vum Code.
  • Wann en Entwéckler eng Aufgab iwwerhëlt, iwwerdréit hien et op Entwécklungsstatus. All Kommunikatioun iwwer d'Klärung vun der Aufgab mam Client fällt op d'Schëllere vum Entwéckler. Technesch Froen kënnen un den Teamleader oder Kollegen gestallt ginn.
  • Wann den Entwéckler d'Essenz vun der Aufgab net versteet, an de Client konnt et net kloer erklären, da geet hien op déi nächst Aufgab. An den Teamleader hëlt déi aktuell an diskutéiert et mam Client.
  • All Dag soll den Entwéckler am Chat vum Client schreiwen iwwer wéi eng Aufgaben hien gëschter geschafft huet a wéi eng Aufgaben hien haut schafft
  • Den Aarbechtsprozess fënnt no Scrum statt. Alles ass a Sprint opgedeelt. All Sprint dauert zwou Wochen.
  • Sprints ginn erstallt, gefëllt a vum Teamleader zougemaach.
  • Wann de Projet strikt Frist huet, da probéieren mir all d'Aufgaben ongeféier ze schätzen. A mir setzen se zesummen an e Sprint. Wann de Client probéiert méi Aufgaben op de Sprint ze addéieren, da setzen mir Prioritéite a transferéieren e puer aner Aufgaben op den nächste Sprint.

b) Prozess fir mam Client ze schaffen

  • All Entwéckler kann a soll mam Client kommunizéieren
  • De Client kann net erlaabt sinn seng eege Spillregelen opzesetzen. Et ass néideg dem Client op eng héiflech a frëndlech Manéier kloer ze maachen, datt mir Spezialisten an eisem Beräich sinn, an nëmmen mir mussen Aarbechtsprozesser bauen an de Client an hinnen involvéieren
  • Et ass néideg, am Idealfall, ier Dir ufänkt all Funktionalitéit ëmzesetzen, e Flowchart vum ganze logesche Prozess fir d'Feature (Workflow) ze kreéieren. A schéckt et un de Client fir Confirmatioun. Dëst gëllt nëmme fir komplex an net offensichtlech Funktionalitéit, zum Beispill e Bezuelsystem, Notifikatiounssystem, etc. Dëst erlaabt eis méi präziist ze verstoen wat genau de Client brauch, d'Dokumentatioun fir d'Feature späicheren an eis och géint d'Tatsaach versécheren datt de Client an der Zukunft kann soen datt mir net gemaach hunn wat hie gefrot huet.
  • All Diagrammer / Flowcharts / Logik etc. Mir späicheren et am Confluence / Fat, wou mir de Client froen d'Korrektheet vun der zukünfteg Ëmsetzung an de Kommentaren ze bestätegen.
  • Mir probéieren de Client net mat techneschen Detailer ze belaaschten. Wa mir e Verständnis brauchen wéi de Client et wëllt, da zéie mir primitiv Algorithmen a Form vun engem Flowchart, deen de Client alles selwer kann verstoen an korrigéieren / änneren.
  • Wann de Client e Feeler am Projet fënnt, da froe mir Iech et am Detail an Zhira ze beschreiwen. Ënner wéi enge Ëmstänn ass et geschitt, wéini, wéi eng Sequenz vun Aktiounen gouf vum Client wärend dem Test duerchgefouert. Befestegt w.e.g. Screenshots.
  • Mir probéieren all Dag, héchstens all aneren Dag, op den Dev Server z'installéieren. De Client fänkt dann un d'Funktionalitéit ze testen an de Projet steet net idle. Zur selwechter Zäit ass dëst e Marker fir de Client datt de Projet a voller Entwécklung ass a kee seet him Mäerchen.
  • Et geschitt dacks datt de Client net ganz versteet wat hien brauch. Well hien schaaft en neit Geschäft fir sech, mat Prozesser déi nach net etabléiert sinn. Dofir ass eng ganz heefeg Situatioun wa mir ganz Stéck Code an den Dreck geheien an d'Applikatiounslogik nei designen. Et geet dovun aus, datt een net absolut alles mat Tester ofdeckt. Et mécht Sënn nëmme kritesch Funktionalitéit mat Tester ze decken, an dann nëmme mat Reservatiounen.
  • Et gi Situatiounen wann d'Team realiséiert datt mir d'Deadline net treffen. Da maache mir e séieren Audit vun den Aufgaben an informéieren de Client direkt doriwwer. Als Auswee aus der Situatioun proposéiere mir wichteg a kritesch Funktionalitéit op Zäit ze lancéieren, an de Rescht fir Post-Release ze loossen.
  • Wann de Client ufänkt mat verschiddenen Aufgaben aus dem Kapp ze kommen, fänkt un ze fantaséieren an z'erklären mat de Fanger, da froe mir him eis e Säitelayout a Flow mat Logik ze bidden, déi d'Behuele vum ganze Layout komplett beschreiwen an seng Elementer.
  • Ier mir eng Aufgab iwwerhuelen, musse mir sécher sinn datt dës Feature an de Bedéngungen vun eisem Vertrag / Kontrakt abegraff ass. Wann dëst eng nei Feature ass déi iwwer eis initial Ofkommes geet, da musse mir dës Feature Präis ((geschätzte Fäerdegstellungszäit + 30%) x 2) an de Client uginn datt et eis sou vill Zäit dauert fir se ofzeschléissen, plus de Frist gëtt mat der Schätzungszäit multiplizéiert mat zwee verréckelt. Loosst eis d'Aufgab méi séier maachen - super, jidderee profitéiert dovun. Wann net, dann hu mir Iech ofgedeckt.

c) Wat mir net an engem Team akzeptéieren:

  • Unengagement, Mangel u Kompositioun, Vergiessenheet
  • "Frühstück ernähren." Wann Dir eng Aufgab net fäerdeg bréngt a wësst net wéi, da musst Dir d'Team Lead direkt informéieren, an net bis déi lescht Minutt waarden.
  • Brows a boasts vun enger Persoun déi seng Fäegkeeten a Professionalitéit nach net bewisen huet. Wann et bewisen ass, dann ass et méiglech, bannent de Grenze vun der Anstännegkeet :)
  • Täuschung an all senge Formen. Wann eng Aufgab net ofgeschloss ass, da sollt Dir säi Status net op fäerdeg änneren a schreift am Client Chat datt et fäerdeg ass. De Computer ass gebrach, de System ass erofgefall, den Hond kauen um Laptop - all dat ass inakzeptabel. Wann e richtege Force Majeure Event geschitt, muss den Teamleader direkt matgedeelt ginn.
  • Wann e Spezialist déi ganzen Zäit offline ass an et schwéier ass him während der Aarbechtszäit z'erreechen.
  • Toxizitéit am Team ass net erlaabt! Wann een net mat eppes averstanen ass, da sammelt jiddereen sech fir eng Rallye an diskutéiert an decidéiert doriwwer.

An eng Rei Froen/Thesen, déi ech mäi Client heiansdo froen fir all Mëssverständnisser opzeklären:

  1. Wat sinn Är Qualitéitskriterien?
  2. Wéi bestëmmen Dir ob e Projet Problemer huet oder net?
  3. Andeems Dir all eis Empfehlungen a Berodung iwwer d'Ännerung/Verbesserung vum System verletzt, ginn all Risiken nëmme vun Iech gedroen
  4. All gréisser Ännerunge vum Projet (zum Beispill all Zorte vun extra Flux) féieren zu der méiglecher Erscheinung vu Bugs (déi mir natierlech fixéieren)
  5. Et ass onméiglech bannent e puer Minutten ze verstoen wéi eng Zort Problem um Projet geschitt ass, vill manner et direkt fixéieren
  6. Mir schaffen un engem spezifesche Produktfloss (Tasks in Zhira - Entwécklung - Testen - Deploy). Dëst bedeit datt mir net op de ganze Floss vun Ufroen a Reklamatiounen am Chat kënnen äntweren.
  7. Programméierer sinn Programméierer, net professionell Tester, a kënnen net déi richteg Qualitéit vum Projet Tester garantéieren
  8. Verantwortung fir endgülteg Testen an Akzeptanz vun Produktiounsaufgaben läit ganz bei Iech
  9. Wa mir schonn eng Aufgab iwwerholl hunn, kënne mir net direkt op anerer wiesselen bis mir déi aktuell fäerdeg maachen (soss féiert dat zu nach méi Bugs a verstäerkter Entwécklungszäit)
  10. Et si manner Leit am Team (wéinst Vakanzen oder Krankheeten), awer et gëtt méi Aarbecht a mir wäerten kierperlech keng Zäit hunn op alles ze reagéieren wat Dir wëllt
  11. Mir froen Iech en Deployment op d'Produktioun ze maachen ouni getest Aufgaben op der Dev - dëst ass nëmmen Äre Risiko, net d'Entwéckler
  12. Wann Dir onkloer Aufgaben setzt, ouni e richtege Flux, ouni Design Layouten, da brauch dat vill méi Effort an Ëmsetzungszäit vun eis, well mir mussen eng zousätzlech Aarbecht maachen amplaz vun Iech
  13. All Aufgaben op Bugs, ouni eng detailléiert Beschreiwung vun hirem Optriede a Screenshots, ginn eis net d'Méiglechkeet ze verstoen wat falsch gaang ass a wéi mir dëse Feeler fixéiere kënnen
  14. De Projet erfuerdert konstant Verfeinerung a Verbesserunge fir d'Performance a Sécherheet ze verbesseren. Dofir verbréngt d'Team en Deel vu senger Zäit un dës Verbesserungen
  15. Wéinst der Tatsaach, datt mir Iwwerstonnen pro Stonn hunn (dréngend Fixer), musse mir se op aneren Deeg kompenséieren

Als Regel, versteet de Client direkt datt alles net sou einfach ass an der Softwareentwécklung, an de Wonsch eleng ass kloer net genuch.

Am Allgemengen, dat ass alles. Ech verloossen hannert d'Kulisse vill Verhandlungen an den initialen Debugging vun alle Prozesser, awer als Resultat huet alles geschafft. Ech kann soen datt dëse Prozess eng Zort "Silver Bullet" fir eis gouf. Nei Leit, déi op de Projet komm sinn, konnten direkt vum éischten Dag un d'Aarbecht involvéieren, well all d'Prozesser beschriwwe goufen, an d'Dokumentatioun an d'Architektur a Form vun Diagrammer hunn direkt eng Iddi ginn, wat mir all hei gemaach hunn.

PS Ech géif gären klären, datt et kee Projet Manager op eiser Säit ass. Et ass op der Säit vum Client. Net en Technesch guer. Europäesche Projet. All Kommunikatioun ass nëmmen op Englesch.

Vill Gléck fir jiddereen op Äre Projeten. Verbrennt net a probéiert Är Prozesser ze verbesseren.

Quell a mengem Blog Post.

Source: will.com