🥇Organizo de la laborfluo en teamo pri IT-projekto

Saluton, amikoj. Sufiĉe ofte, precipe en subkontraktado, mi vidas la saman bildon. La manko de klara laborfluo en teamoj pri diversaj projektoj.

La plej grava afero estas, ke programistoj ne komprenas kiel komuniki kun la kliento kaj inter si. Kiel konstrui kontinuan procezon de evoluigado de kvalita produkto. Kiel plani vian labortagon kaj sprintojn.

Kaj ĉio ĉi finfine rezultigas rompitajn limdatojn, kromlaborojn, konstantajn konfliktojn pri kiu kulpas, kaj klientan malkontenton - kien kaj kiel ĉio moviĝas. Tre ofte, ĉio ĉi kondukas al ŝanĝo de programistoj, kaj eĉ tutaj teamoj. Perdo de kliento, difekto de reputacio ktp.

Iam mi ĵus ekhavis tian projekton, kie estis ĉiuj ĉi tiuj ĝojoj.

Neniu volis preni respondecon pri la projekto (granda servomerkato), la spezo estis terura, la kliento nur ŝiris kaj ĵetis. La CEO iel aliris min kaj diris, ke vi havas la necesan sperton, do vi havas la kartojn en viaj manoj. Prenu la projekton por vi mem. Se vi fuŝas, ni fermos la projekton kaj forpelos ĉiujn. Ĝi rezultos, ĝi estos malvarmeta, tiam gvidu ĝin kaj disvolvos ĝin kiel vi konvenas. Kiel rezulto, mi fariĝis teamestro pri la projekto kaj ĉio falis sur miajn ŝultrojn.

La unua afero, kiun mi faris, estis desegni laborfluon de nulo, kiu kongruis kun mia vizio tiutempe kaj skribis laborpriskribon por la teamo. Efektivigi ĝin ne estis facila. Sed ie ene de unu monato ĉio trankviliĝis, la programistoj kaj la kliento alkutimiĝis, kaj ĉio iris trankvile kaj komforte. Por montri al la teamo, ke tio ne estas nur ŝtormo en glaso, sed vera elirejo de la situacio, mi prenis sur sin la maksimuman kvanton da respondecoj, forigante la malagrablan rutinon de la teamo.

Jaro kaj duono jam pasis, kaj la projekto disvolviĝas sen kromlaboro, sen "ratkuroj" kaj ĉiaj streĉoj. Iu en la malnova teamo ne volis labori tiel kaj foriris, male, iu vere eniris, ke aperis travideblaj reguloj. Sed kiel rezulto, ĉiuj en la teamo estas tre motivitaj kaj konas la grandegan projekton plene, kun ambaŭ front-end kaj back-end. Inkluzive kaj la kodbazo kaj la tuta komerca logiko. Ĝi eĉ venis al la punkto, ke ni ne estas nur "remistoj", sed ni mem elpensas multajn komercajn procezojn kaj novajn funkciojn, kiujn la komerco ŝatas.

Danke al ĉi tiu aliro niaflanke, la kliento decidis mendi alian vendoplacon de nia kompanio, kio estas bona novaĵo.

Ĉar ĉi tio funkcias ĉe mia projekto, eble ĝi ankaŭ helpos iun. Do, la procezo mem, kiu helpis nin savi la projekton:

La procezo de teama laboro en la projekto "Mia plej ŝatata projekto"

a) Ene de teamprocezo (inter programistoj)

Ĉiuj taskoj estas kreitaj en la Jira-sistemo
Ĉiu tasko devus esti priskribita kiel eble plej multe, kaj plenumi strikte unu agon.
Ajna funkcio, se ĝi estas sufiĉe kompleksa, estas dividita en multajn malgrandajn taskojn
La teamo laboras pri funkcioj kiel ununura tasko. Unue, ni faras unu funkcion kune, donas ĝin por testado, poste prenu la sekvan.
Ĉiu tasko estas etikedita por backend aŭ fasado
Estas specoj de taskoj kaj cimoj. Vi devas specifi ilin ĝuste.
Post kiam la tasko estas finita, ĝi estas transdonita al la koda revizia statuso (tiro-peto estas kreita por sia kolego)
Tiu, kiu plenumis la taskon, tuj spuras sian tempon por ĉi tiu tasko
Post kontrolado de la kodo, la PR estas aprobita kaj post tio, tiu, kiu plenumis ĉi tiun taskon sendepende, kunfandas ĝin en la majstran branĉon, post kio ĝi ŝanĝas sian statuson al preta por deplojo al la dev-servilo.
Ĉiuj taskoj pretaj por esti deplojitaj al la dev-servilo estas deplojitaj fare de la teamgvidanto (lia areo de respondeco), foje teamano, se io urĝas. Post deplojo, ĉiuj taskoj de preta por deplojo al dev estas transdonitaj al la statuso - preta por testado sur dev
Ĉiuj taskoj estas provitaj de la kliento
Kiam la kliento testis la taskon sur la dev, li transdonas ĝin al la statuso preta por deplojo al produktado.
Por deplojo al produktado, ni havas apartan branĉon, kie ni kunfandas la majstron ĵus antaŭ la deplojo
Se dum testado la kliento trovas cimojn, tiam li resendas la taskon por revizio, fiksante ĝian staton resenditan por revizio. Tiel ni apartigas novajn taskojn de tiuj, kiuj ne estis provitaj.
Kiel rezulto, ĉiuj taskoj iras de kreado ĝis kompletigo: Fari → En Disvolviĝo → Kodo-Revizio → Preta deploji al dev → QA sur dev → (Revenu al dev) → Preta deploji al prod → QA sur prod → Farita
Ĉiu programisto testas sian kodon sendepende, inkluzive kiel uzanto de la retejo. Ne rajtas kunfandi branĉon kun la ĉefa, krom se oni certe scias, ke la kodo funkcias.
Ĉiu tasko havas prioritatojn. Prioritatoj estas fiksitaj aŭ fare de la kliento aŭ la teamgvidanto.
Programistoj unue faras prioritatajn taskojn.
Programistoj povas asigni taskojn unu al la alia se malsamaj cimoj estis trovitaj en la sistemo aŭ unu tasko konsistas el la laboro de pluraj specialistoj.
Ĉiuj taskoj kiujn la kliento kreas estas senditaj al la teamgvidanto, kiu taksas ilin kaj aŭ petas al la kliento finpretigi ilin aŭ asignas ilin al unu el la teamanoj.
Ĉiuj taskoj, kiuj estas pretaj por esti deplojitaj al dev aŭ prod, ankaŭ atingas la teamgvidanton, kiu sendepende determinas kiam kaj kiel deploji. Post ĉiu deplojo, la teamgvidanto (aŭ teamano) devas sciigi la klienton pri tio. Kaj ankaŭ ŝanĝu la statusojn por taskoj al pretaj por testado ĉe dev / prod.
Ĉiutage samtempe (ni havas ĝin je la 12.00) ni okazigas mitingon inter ĉiuj teamanoj
Ĉiuj ĉe la amaskunveno raportas, inkluzive de la teamgvidanto, kion li faris hieraŭ, kion li planas fari hodiaŭ. Kio ne funkcias kaj kial. Tiel, la tuta teamo konscias pri kiu faras kion kaj en kiu stadio estas la projekto. Ĉi tio donas al ni la ŝancon antaŭdiri kaj ĝustigi, se necese, niajn taksojn kaj limdatojn.
Ĉe la renkontiĝo, la teamgvidanto ankaŭ anoncas ĉiujn ŝanĝojn en la projekto kaj la nivelon de nunaj cimoj, kiuj ne estis trovitaj de la kliento. Ĉiuj cimoj estas ordigitaj kaj asignitaj al ĉiu grupano por solvi ilin.
Ĉe la amaskunveno, la teamgvidanto asignas taskojn por ĉiu, konsiderante la nunan laborŝarĝon de programistoj, ilian nivelon de profesia trejnado, kaj ankaŭ konsiderante la proksimecon de aparta tasko al tio, kion la programisto nuntempe faras.
Ĉe la renkontiĝo, la teamgvidanto disvolvas ĝeneralan strategion por arkitekturo kaj komerca logiko. Post tio, la tuta teamo diskutas tion kaj decidas ĉu fari ĝustigojn aŭ adopti ĉi tiun strategion.
Ĉiu programisto skribas kodon kaj konstruas algoritmojn sendepende ene de ununura arkitekturo kaj komerca logiko. Ĉiu povas esprimi sian vizion pri efektivigo, sed neniu devigas iun fari ĝin tiel kaj ne alie. Ĉiu decido estas pravigita. Se estas pli bona solvo, sed nun ne estas tempo por ĝi, tiam tasko estas kreita en graso, por estonta refaktorado de certa parto de la kodo.
Kiam programisto prenas taskon, li movas ĝin al evolua stato. Ĉiu komunikado pri la klarigo de la tasko kun la kliento falas sur la ŝultrojn de la programisto. Teknikaj demandoj povas esti demanditaj al la teamgvidanto aŭ kolegoj.
Se la programisto ne komprenas la esencon de la tasko, kaj la kliento ne povis prudente klarigi ĝin, tiam li daŭrigas la sekvan taskon. Kaj la teamestro prenas la nunan kaj diskutas ĝin kun la kliento.
Ĉiutage, la programisto devas skribi en la babilejo de la kliento pri kiaj taskoj li laboris hieraŭ kaj pri kiuj taskoj li laboros hodiaŭ.
La laborfluo baziĝas sur Scrum. Ĉio estas dividita en spurtojn. Ĉiu spurto daŭras du semajnojn.
Spurtoj estas kreitaj, plenigitaj kaj fermitaj fare de la teamgvidanto.
Se la projekto havas striktajn limdatojn, tiam ni provas proksimume taksi ĉiujn taskojn. Kaj ni kolektas de ili spurton. Se la kliento provas aldoni pli da taskoj al la sprinto, tiam ni fiksas prioritatojn, kaj transdonas iujn aliajn taskojn al la sekva sprinto.

b) La procezo labori kun la kliento

Ĉiu programisto povas kaj devas komuniki kun la kliento
Vi ne povas permesi al la kliento trudi siajn proprajn regulojn de la ludo. Necesas en ĝentila kaj amikeca maniero klarigi al la kliento, ke ni estas specialistoj en nia kampo, kaj nur ni devas konstrui laborprocezojn kaj impliki la klienton en ili.
Necesas, ideale, antaŭ ol daŭrigi kun la efektivigo de iu ajn funkcio, krei fluodiagramon de la tuta logika procezo por trajto (laborfluo). Kaj sendu ĝin al la kliento por konfirmo. Ĉi tio validas nur por kompleksaj kaj ne evidentaj funkcioj, ekzemple, pagsistemo, sciiga sistemo ktp. Ĉi tio permesos al vi pli precize kompreni, kion precize bezonas la kliento, konservi la dokumentaron por la funkcio, kaj ankaŭ certigi vin kontraŭ la fakto, ke la kliento eble diros estonte, ke ni ne faris tion, kion li petis.
Ĉiuj diagramoj/fludiagramoj/logiko ktp. ni savas en Confluence/Fat, kie ni petas la klienton en la komentoj konfirmi la ĝustecon de la estonta efektivigo.
Ni provas ne ŝarĝi la klienton per teknikaj detaloj. Se ni bezonas komprenon pri kiel volas la kliento, tiam ni desegnas primitivajn algoritmojn en formo de fludiagramo, kiun la kliento povas kompreni kaj ripari / modifi ĉion mem.
Se la kliento trovas cimon en la projekto, tiam ni petas vin priskribi ĝin tre detale en Fat. Sub kiaj cirkonstancoj ĝi okazis, kiam, kia sekvenco de agoj estis efektivigita de la kliento dum testado. Bonvolu alfiksi ekrankopiojn.
Ni provas ĉiutage, maksimume ĉiun duan tagon, deploji al la dev-servilo. La kliento tiam komencas testi la funkciecon kaj la projekto ne estas neaktiva. Samtempe, ĉi tio estas signo por la kliento, ke la projekto estas en plena disvolviĝo kaj neniu rakontas al li fabelojn.
Ofte okazas, ke la kliento tute ne komprenas, kion li bezonas. Ĉar li kreas novan komercon por si, kun procezoj kiuj ankoraŭ ne estis elpurigitaj. Sekve, tre ofta kazo estas kiam ni ĵetas tutajn pecojn de kodo en la rubujon kaj reformas la aplikan logikon. El tio sekvas, ke ne necesas kovri absolute ĉion per provoj. Estas senco kovri nur kritikan funkciecon per testoj, kaj poste per rezervoj.
Estas situacioj, kiam la teamo rimarkas, ke ni ne konvenas al limdatoj. Tiam ni faras rapidan revizion de la taskoj, kaj tuj informas la klienton pri tio. Kiel elirejo de la situacio, ni sugestas lanĉi gravajn kaj kritikajn funkciojn ĝustatempe, kaj lasi la reston por post-eldono.
Se la kliento komencas elpensi malsamajn taskojn de sia kapo, komencas fantazi kaj klarigi per siaj fingroj, tiam ni petas lin provizi al ni paĝan aranĝon kaj flui kun logiko, kiu devus plene priskribi la konduton de la tuta aranĝo kaj ĝia elementoj.
Antaŭ ol ni preni ajnan taskon, ni devas certigi, ke ĉi tiu funkcio estis inkluzivita en la kondiĉoj de nia interkonsento / kontrakto. Se ĉi tio estas nova funkcio, kiu superas niajn komencajn interkonsentojn, tiam ni nepre devas taksi ĉi tiun funkcion ((proksimuma plumbotempo + 30%) x 2) kaj indiki al la kliento, ke ni bezonos tiom da tempo por kompletigi ĝin, plus la limdato estas ŝanĝita por la taksa tempo multiplikita per du. Ni rapidigu la taskon - bonege, ĉiuj nur profitos el tio. Se ne, tiam ni estas asekuritaj.

c) Kion ni ne akceptas en la teamo:

Nekonsekvenco, nekohereco, forgeso
" Matenmanĝo Manĝigo " . Se vi ne povas plenumi la taskon, vi ne scias kiel, tiam vi devas tuj informi la teamgvidanton pri tio, kaj ne atendi ĝis la lasta.
Brovadas kaj fanfaronas de viro, kiu ankoraŭ ne pruvis siajn kapablojn kaj profesiecon per faro. Se pruvite, tiam ĝi eblas, ene de la limoj de deco 🙂
Fraŭdo en ĉiuj ĝiaj manifestiĝoj. Se la tasko ne estas finita, tiam vi ne ŝanĝu ĝian staton al finita kaj skribu en la babilejo de la kliento, ke ĝi estas preta. La komputilo kraŝis, la sistemo kraŝis, la hundo maĉis sur la tekkomputilo - ĉio ĉi estas neakceptebla. Se reala forto-maĵoro okazas, tiam la teamestro devas esti tuj sciigita.
Kiam specialisto estas eksterrete la tutan tempon kaj estas malfacile atingi lin dum laborhoroj.
Tokseco en la teamo ne estas permesita! Se iu malkonsentas pri io, tiam ĉiuj kunvenas por mitingo kaj diskutas kaj decidas.

Kaj kelkaj demandoj/tezoj, kiujn mi foje petas al mia kliento forigi ĉiujn miskomprenojn:

Kiuj estas viaj kvalitkriterioj?
Kiel vi determini ĉu projekto havas problemojn aŭ ne?
Malobservante ĉiujn niajn rekomendojn kaj konsilojn pri ŝanĝo/plibonigo de la sistemo, ĉiuj riskoj estas portataj nur de vi
Ajnaj gravaj projektŝanĝoj (ekzemple, ĉiaj ekstra fluo) kondukos al la ebla apero de cimoj (kiujn ni kompreneble riparos)
Estas neeble kompreni ene de kelkaj minutoj, kia problemo okazis en la projekto, kaj eĉ pli ripari ĝin ĝuste tie.
Ni laboras pri specifa produkta fluo (Taskoj en Zhira - Disvolviĝo - Testado - Deploji). Ĉi tio signifas, ke ni ne povas respondi al la tuta fluo de petoj kaj plendoj en la babilejo.
Programistoj estas nur programistoj, ne profesiaj testistoj, kaj ne povas certigi la taŭgan kvaliton de projekttestado
Respondeco pri fina testado kaj akcepto de taskoj sur la vendo kuŝas tute sur vi
Se ni jam prenis taskon, tiam ni ne povas tuj ŝanĝi al aliaj ĝis ni kompletigos la nunan (alie tio kondukas al eĉ pli da eraroj kaj pliiĝo de la tempo de disvolviĝo)
Estas malpli da homoj en la teamo (pro ferioj aŭ malsanoj), kaj estas pli da laboro kaj ni fizike ne havos tempon por respondi ĉion, kion vi volas.
Peti vin deploji al produktado sen testitaj taskoj sur dev estas nur via risko, ne la ellaboranto
Kiam vi agordas neklarajn taskojn, sen ĝusta fluo, sen dezajnaj aranĝoj, tio postulas de ni multe pli da penado kaj efektivigotempo, ĉar ni devas fari plian kvanton da laboro anstataŭ vi.
Ajnaj taskoj pri cimoj, sen detala priskribo de ilia okazo kaj ekrankopioj, ne donas al ni la ŝancon kompreni kio misfunkciis kaj kiel ni povas elsendi ĉi tiun cimon.
La projekto postulas konstantan rafinadon kaj plibonigojn por plibonigi rendimenton kaj sekurecon. Tial, la teamo pasigas iom da sia tempo por ĉi tiuj plibonigoj.
Pro la fakto, ke ni havas kromlaborhorojn (urĝajn korektojn), ni devas kompensi ilin en aliaj tagoj

Kiel regulo, la kliento tuj komprenas, ke ĉio ne estas tiel simpla en programaro, kaj nur deziro klare ne sufiĉas.

Ĝenerale, ĉi tio estas ĉio. Malantaŭ la kulisoj, mi lasas multajn intertraktadojn kaj la komencan elpurigon de ĉiuj procezoj, sed kiel rezulto, ĉio funkciis. Mi povas diri, ke ĉi tiu procezo fariĝis speco de "Arĝenta Kuglo" por ni. Novaj homoj, kiuj venis al la projekto, povis tuj utiligi sin por labori ekde la unua tago, ĉar ĉiuj procezoj estas priskribitaj, kaj la dokumentado kaj arkitekturo en formo de diagramoj tuj donis ideon pri tio, kion ni ĉiuj faras. ĉi tie.

PS Mi volas klarigi, ke ne estas projektestro nianflanke. Ĝi estas flanke de la kliento. Tute ne teknikisto. eŭropa projekto. Ĉiu komunikado estas nur en la angla.

Bonŝancon al ĉiuj en viaj projektoj. Ne forbruliĝu kaj provu plibonigi viajn procezojn.

fonto en mia blogo.

fonto: www.habr.com