La « story point » fariĝis « main stream » kun ĉiuj ekscesoj, kiuj tion akompanas. Ni kune vidu, kiel piedbati en la formikejon, sen, tamen, ke ni mem estu forpelitaj el la planumaj kaj taksaj kunsidoj.

Reveno al la tempo de la antaŭagilaj taksoj

Homtago / Hommonato

En la mondo de komputilprojekta administrado, troviĝas la klasika « homtago ». Tiu magia mezurunuo, kiu ebligas juĝi la efikecon de teamo, kaj precipe de ĝiaj membroj, kaj tio individue! Kia komforto! Sufiĉas diligente plenigi vian plej karan tabelon Excel, aŭ ajnan alian projekt-administrilon, por vidi viajn grafikaĵojn ĝisdatiĝi kaj, se bezono, la averton pri la « malfruo » de la teamo/membro.

La buĝeta kaj planara sekvado ne estas malbono, tre male se oni volas eviti al si malagrablajn surprizojn. Sed ĝia fincelo estis perversita por fari el ĝi ilon de mikro-administrado kaj riproĉado.

La sekvaĵo de ĉi tiu « homtago » estas la « hommonato », unuo uzata en makro-administrado por taksi la tutan laborŝarĝon de projekto. Kun finodato de la projekto decidita antaŭe, simpla divido ebligas dimensii la grandecon de la teamo dungota por respekti la tempolimojn ... teorie. Tie la tre fama libro The Mythical Man-Month klarigas laŭlonge, laŭlarĝe kaj krure, ke ĉi tiu praktiko ne estas realisma. La leĝo de Brooks devenas de ĉi tiu libro, kaj substanke diras :

• « Aldoni homojn al malfruiĝinta projekto pligrandigas ĝian malfruon »

La metaforoj por eĉ pli bone klarigi ĉi tiun empirian leĝon estas ofte la jenaj :

• « Naŭ virinoj ne faras infanon en unu monato. »
• « Estante 300 en kuirejo por fritigi ovon, ne eblos servi la manĝaĵon 300 fojojn pli rapide. »

Konfuzo inter ŝarĝo kaj tempolimo

• Ŝarĝo : Tempo bezonata por la efektiva realigo
• Tempolimo : Tempo bezonata antaŭ ol havi la kapablon fari

Taksi en homtagoj ege favoras la eraron pensi, ke la ŝarĝo kaj la tempolimo estos identaj.

(Estro)-Kiom da tempo por ĉi tiu tasko?
(Plenumanto)-Ĝej, 2 tagoj?
(E) -Ne, tro multe! Mi donas al vi 1! Ĝis morgaŭ
(P) -Sed ... ( E eliras sen atendi la respondon) kaj la aliajn 5 taskojn, kiujn mi nun plenumas, kion mi faru el ili?

Ĉia simileco kun realaj eventoj estus nur tute intenca.

Ĉi tiu konfuzo estas avantaĝo, se oni volas konservi artan nebulecon ĉirkaŭ la rilato inter la laborŝarĝo kaj ĝia liverado. Oni miksas 2 necertecojn, kiuj nur multobliĝas, kio instigas enmeti eraromarĝenon sufiĉe grandan por kovri ajnan neatenditaĵon.

ETP

La «ETP» (plentempa ekvivalento) , estas alia mezurunuo, precipe furoranta en la medio de la projektestroj aŭ projektestraroj. Ĝi tre oportunas, ĉar ĝi ebligas rapide taksi la entutan koston de projekto, kaj ĝian dimensiigon.

Estas fierindaĵo havi «multajn ETP» sub viaj ordonoj (ĉia simileco kun la ludo « kiu havas la plej grandan » estus nur hazarda). La ETP ankaŭ povas ebligi fiksi celojn al la kunlaborantoj. Ekzemple, projektestro, laŭ sia grado, devas havi inter X kaj Y ETP sub sia kontrolo ; projektestraro inter A kaj B, alie tiu kunlaboranto ne estas « enspezporta ».

Ĉi tiu unuo ankaŭ havas alian tre interesan avantaĝon por tiu popolgrupo. Ĝi ebligas kaŝi la dispecigitan dividon de la tempo dediĉita al la projekto, distribuita inter diversaj personoj : 1 arkitekto je 10% + 2 disvolvistoj je 60% + 2 staĝistoj (100%) + 1 lernanto (50%) = 3,8 ETP ! Mi lasas al vi diveni la staton de la projekto post 6 monatoj da V-ciklo.

Mallonge

Ĉio ĉi ebligas :

• apartigi la grenon de la pajlo, la bonan plenumanton de la malbona, la bonan programiston de la malbona,
• konstrui « dream team », tiujn teamojn vendatajn pro ora prezo, kies ĉiu membro pruvis en siaj antaŭaj projektoj rendimentojn multe pli altajn ol tiuj de siaj samranganoj,
• elstarigi la plej bonajn administrantojn kun iliaj plej belaj grafikaĵoj, iliaj plej kompleksaj kalkultabeloj por detekti la plej malgrandan varion de produktiveco de ĉiu koncernita plenumanto.

La revolucio de la (story) point

Kun la novaj projekt-metodoj, aperis la takso per «story point».

(Respondeculo) Kia hororo, oni forigas la ĉefan ilon por mezuri la produktivecon!
(Plenumanto) Kia komforto, oni forigas la premion de la malbona takso respektota!

En la optiko responsumigi la teamojn kaj malpezigi la mikro-administradon, la story point estis sufiĉe rapide adoptita en ĉiuj organizaĵoj volantaj fari agile. Fine, la transiro ne estis tiel malfacila. Oni nur anstataŭas la unuon, de « ht » al « punkto », kaj, kulmino de feliĉo, oni povas havi korespondon 1 por 1 (aŭ ajnan alian facile konverteblan proporcion) .

La avantaĝoj de ĉi tiu nova mezurunuo estis klare rompi ajnan ligon inter la farita takso kaj ebla liverodato.

La punkto ankaŭ ebligas pli facile valorigi la kompleksecon de la realigo. Pasi 2 tagojn je realigo absolute ne signifas, ke la kvanto de produktita kodo estos la sama kiel por la antaŭa realigo, samgranda. Sed anonci 2 punktojn faras la konfuzon ŝarĝo /tempolimo multe pli malfacila, eĉ neebla.

La fokusfaktoro

Ĉi tiun nocion prezentas, inter aliaj, la tre konata Scrum and XP from the Trenches. Substancke, la aŭtoro klarigas, ke la punkto devas reprezenti « idealan homtagon », tio estas labortagon sen ripozo nek interrompo! Poste fari rapidan komparon kun la reala rapideco de la teamo por havi % da fokuso. Oni tre logike konkludas, ke ju pli alta estas ĉi tiu %, des pli la teamo troviĝas en idealaj laborkondiĉoj. Do, granda parto de la plibonigaj klopodoj de la teamo (larĝasence) estas ofte orientitaj al la plibonigo de ĉi tiu cifero.

Ĉu vi vidas veni la eblajn ekscesojn?

Nuntempe, ĉi tiu nocio apenaŭ plu estas uzata kaj tio danke al la laboro de la trejnistoj, kiuj martele martelas, ke la korespondo « punkto <=> tago » estas malbona praktiko ... tute prave.

Eliri el sia komfortozono

Nun, kiam la punkto estas regata, kutima, perversita, estus eble tempo transiri al io alia. Sed ni ne iru tro rapide aŭ tro malproksime, ne konvenus, ke la malfortaj antaŭeniroj kaj la pliboniga elano komencita kun la punktoj estu nuligitaj pro rifuzo de la estrado/informadika sekcio/estro, kiu sentus sin ankoraŭ pli perdita.

La personumita unuo

Ni alvenas al la kerno de ĉi tiu blogafiŝo.

La ideo estas fari simplan semantikan ŝanĝon, oni forlasas la vorton « punkto » por… (tamburfrapo) … kion ajn vi volas!

Jes, personumu la terminon! Posedigu ĝin! Ludu per ĝi! Ĵonglu per ĝi!

Konkrete, projekto kies ĉefa objekto estas la loĝejasekuro povus preni la vorton « briko ». Tiu, kiu administras la fabrikadon de aŭtoj, povas tre logike preni « aŭto ». Do, vi ne plu parolas en abstrakta unuo, malproksime de ĉio, sed per termino pli proksima al la metio, signifoplena. Sciante, ke projektoj ofte portas nomojn ne nepre evokantajn, ĝi estas elemento, kiu ebligos pli bone situi la kuntekston de la projekto.

Kial ĉi tiu (simpla) semantika ŝanĝo?

Vi eble respondos al mi, ke ĉi tiu bagatela ŝanĝo ne havos influon, ke ĝi estas « nur » semantiko. Eble vi pravas en kelkaj kazoj, sed por la aliaj, ĝi povas ŝanĝi ĉion. Tion oni nomas « nudge », « ŝoveto ». La celoj malantaŭ ĉi tiu ideo estas multnombraj :

• Ludema : La fakto elekti sian unuon komence de la projekto kontribuas al la konstruado de la teamo kaj al ĝia kuneco.
• Rompi la kodojn : Oni devas regule eliri el sia komfortozono por esplori novajn vojojn, kiuj, longtempe, povas multe alporti al la teamo/projekto/entrepreno.
• Eviti la komparojn : Havi la punkton kiel mezurunuon en ĉiuj projektoj instigas, intence aŭ ne, fari komparojn inter teamoj, serĉi korelaciojn. Dum estas neeble kompari brasikojn kaj karotojn, brikojn kaj trotinetojn.

Unu paŝo pli?

Sed ni ne haltu dum tiel bona vojo. Ĉu oni ne povus senigi la punktojn kaj nur konservi la unuon? Kial limigi sin al unu sola termino? Kial ne fari al si kompletan valorskalan? Se mi reprenas la antaŭajn ekzemplojn, oni povus ricevi ion tian :

La punktekvivalento estas tie nur por doni ideon, sed nia nova punkta skalo povas tre bone esti tute malkorelaciita de ĝi. Mi havas perfektan ilustraĵon, kiu pruvas, ke ĉi tiu paŝo estas atingebla por ĉiuj! Famkonata konsultfirmao eldonis kartludon por la poker planning, kiu aspektas tiel : Oni tie trovas valorskalan, certe respektanta la klasikajn punktojn, sed la ideo estas tie.

Malavantaĝoj

Kompreneble, ĉi tiu solvo ne estas perfekta, ĝi havas kelkajn difektojn, sed ili ne ŝajnas nesuperigeblaj al mi.

• Malstabileco : Ankoraŭ nova taksa metodo! La punktoj jam ne estis facilaj por adopti kaj ĝuste uzi, tie eĉ la programistoj malfacile alkutimiĝos.

Mi ne estus tiel kategora. Certe, akompano necesos, sed longtempe ĝi devus fariĝi natura. Por sekurigi la transiron kaj la integradon de novaj personoj, apogiĝi je rapida priskribo de tio, kion reprezentas ĉiu unuo, ege helpas. Por ĉio, kio koncernas la problemaron de sekvado kaj antaŭvido, ĉi tio ne estas tiel malproksima de tio, kio estis farata kun la punktoj : uzi la veteron de la antaŭa tago devus ebligi fari raciajn projekciojn, eble ne tre longtempaj, sed sufiĉaj koncerne la agilajn metodojn.

• Provado : Kiel oni faras praktike? Sur kio oni baziĝas? Kiun laborkunsidon oni devas fari?

Demandu vian Scrum Master aŭ vian trejniston, ĉiu recepto devas esti unika. Ĝi ne estas nepre facila praktiko, nek metota en ĉiujn manojn, sed se vi alvenas al ĉi tiu nivelo, vi scios, kion fari.

• Sekvadiloj : Kaj mia projekt-administrilo! Kiel ĝi faros por generi al mi miajn grafikaĵojn? Mia burndown! Mia burnup!

Tio efektive estas pli malfacila problemo. Necesas adapti la ilojn por ke ili povu uzi ĉi tiun ne-numerikan skalon, evitante, ĝuste, klare montri konverton al numerika. Nuntempe mi konas nur unu solan solvon, kiu tion ebligus. La vida administrado! Prenu paperon kaj krajonon kaj faru ĝin mem. Sed mi konsentas, ne facile por malproksimaj teamoj.

Por iri eĉ pli malproksime

Kaj kial ne iri eĉ pli malproksime? Ĉu oni ne povus succombe al la alloga movado de la « No Estimate »? La paŝo estas ankoraŭ tro alta por multaj entreprenoj. Tial unua paŝo kun unuo personumita por ĉiu projekto estas akceptebla opcio kaj iranta en la bonan direkton.

Konkludo

Fari agileco, laŭ la plej bona stato de la tekniko, estas ofte tre komplika kaj nepensebla por multaj strukturoj. Liberigi sin de la « homtagoj/hommonatoj » kaj transiri al la « story point » jam estas bona iniciato, sed oni ne devas fali en la erarojn priskribitajn supre. Kiam la entrepreno akiris ĉi tiun kulturon de agileco kaj volas antaŭenpuŝi la sperton, rompi la eblajn komparojn inter punktoj estas unua atingebla ŝtupo sen tro multe da peno antaŭ ol provi ĵeti sin en la bano de la «No estimate».

PS : Ĉi tiu teksto estis verkita komence en majo 2020, mi intence lasis ĝin tia, ĉar fine, mi ankoraŭ dividas ĉi tiun opinion.