Enkonduko
Kiu, inter ĉiu sinrespektanta agilisto, ne konas la Agile-manifeston! Se vi legas ĉi tiujn liniojn, tiu dokumento ne estas nekonata al vi. Eble vi konas kelkajn el ĝiaj valoroj, eĉ ĉiujn, kaj por la plej akademiaj el vi, la principojn … parkere.
Sed ĉu vi konas la deklaron de la Agile-rajtoj? Ne? Ne estas mirinde: tiu deklaro evidente ne trovis al si lokon sub la lumprojektiloj kiel faris ĝia kuzo la manifesto. Kial mi diras kuzo? Ĉar parto de la subskribantoj de la manifesto, dum tiu sama kunveno en Snowbird, verkis tiun deklaron. (« sous la plume de Kent Beck, Ward Cunningham, Ron Jeffries et quelques autres »)
Legante la bonegan «Agile Proprement» de Robert C. Martin mi malkovris ĝin. Se vi ankoraŭ ne legis ĝin, mi nur povas instigi vin akiri ekzempleron de tiu libro kaj formanĝi ĝin, kiel kaptilan rakonton, kiun rakontus al vi via aventurema grand-onklo. Mi verŝajne faros specialan artikolon por paroli pri ĝi pli longe, sed por nun mi volas konigi al vi tiun nekonatan trezoraĵon, nome la deklaro de la Agile-rajtoj, malkovrita post la 50 unuaj paĝoj de tiu libro.
Deklaro de la rajtoj
| Rajtoj de la kliento | Rajtoj de la programisto |
|---|---|
| Vi rajtas ricevi tutan planon kaj scii, kio povas esti realigita, kiam kaj je kiu prezo. | Vi rajtas scii, kion oni atendas de vi, kun klara deklaro de la prioritatoj. |
| Vi rajtas ricevi kiom eble plej multan valoron fine de ĉiu iteracio. | Vi rajtas produkti alt-kvalitan kodon ĉiam. |
| Vi rajtas konstati la progreson de funkcianta sistemo, kies kvalito estis pruvita per reprodukteblaj testoj, kiujn vi specifis. | Vi rajtas peti kaj ricevi helpon de viaj kolegoj, viaj manaĝantoj kaj viaj klientoj. |
| Vi rajtas ŝanĝi vian opinion, anstataŭigi trajton per alia kaj modifi la prioritatojn sen suferi troan superkoston. | Vi rajtas fari viajn proprajn taksadojn kaj ĝisdatigi ilin. |
| Vi rajtas esti informita ĉiam pri ŝanĝoj en la tempoplano kaj en la taksadoj, kaj sufiĉe frue por povi decidi malgrandigi la funkcian amplekson, se vi bezonas respekti fiksan daton. Vi devas povi nuligi la projekton iam ajn kaj ricevi funkciantan sistemon proporcie al la jam elspezita buĝeto. | Vi rajtas akcepti la respondecojn anstataŭ ke ili estu altruditaj al vi. |
Mi intence prezentis la rajtojn de la 2 partioj kiel tabelon, ĉar, kiel diras la aŭtoro de la libro, ĉiu rajto respondas unu al la alia kaj venas kompleti la rajton de la alia partio. Mi lasos vin malkovri la detalajn klarigojn de ĉiu rajto en la libro, sed sen parafrazi ĝin, mi permesos al mi doni al vi mian vidon.
Vidpunkto
-
(kliento) Kiel ajn mirige tio povas ŝajni, li komencas dirante al ni, ke oni devas fari taksadojn, kaj pri la tuta projekto! Sed kun ioma nuanco: tiu taksado devas esti kiel eble plej preciza kaj ĝusta, laŭ la nuna stato de la scioj de la teamo. Ĝi ankaŭ ne devas konduki al engaĝiĝo pri dato aŭ amplekso. Li rekomendas provizi probablojn de realigaj tempoj. Kio permesas al la kliento gustan stiradon de siaj aktivecoj
(programisto) Iliaflanke, estas la prioritatizado, kiu estas honorata. Tiu valora scio povus ŝajni kontraŭa al la bonvenigo de la ŝanĝo, kiu estas normala en agilo. Tial ĝi ne povas esti fiksa por la tuta projekto; nur, minimume, por la nuna iteracio, en la plej bona kazo por 2 aŭ 3 iteracioj. -
(kliento) Estas rajto, kiu iom mordas sian propran voston, ĉar la kliento prioritatigas la produktadon, sed estas respondeco de la programistoj respekti ĝin
(programisto) Estas rajto ofte tranĉita, kvankam ĝi estas esenca kaj neprebla. Ĝi tuŝas la ekzistokialon de ĉiu sinrespektanta programisto. Malhonori ĝin kostas multe longtempe. -
(kliento) Ĉiu kliento, kiu faras minimuman sekvadon, devus esti tre postulema pri tiu rajto. Estas lia mono kaj lia tempo, kiujn konsumas la programistoj. Same utilas kontroli, ke ĝi estas bone uzita.
(programisto) La komunikado estas la centro de tiu rajto. Komuniki la sciojn, la postulojn, la prioritatojn. Sen tio, kiel postuli de programistoj taksadojn, kvaliton, valor-produktadon? -
(kliento) Pro la nemateria naturo de programaro, ĉiu ŝanĝo devus esti ebla, akceptante samtempe la kaŭzitajn superkostojn.
(programisto) Estas tiuj, kiuj faras, kiuj scias! Kaj estas per farado, ke oni povas plej bone aprecii la bezonatan laborŝarĝon. Tamen ĝi restas taksado, kiu povas esti malĝusta aŭ malpreciza, do ne firma engaĝiĝo. -
(kliento) La rajto de la kliento ĉi tie estas esti tenata informita; li ne rajtas postuli la respekton de la limdatoj. Tio estas esenca por li por reagi laŭ la eventoj, eĉ ŝanĝante opinion, orientiĝon aŭ rekte nuligante la projekton se necese, sen ke tio povus esti riproĉita al li. Estas fine nur la rajto esti bona administranto
(programisto) Unuflanke, oni povas vidi iom da Lean kun puŝita fluo. Aliflanke, oni povas vidi la aprezon de la programisto. Ĉu li sentas sin rajtigita? Ĉu la peto estas rajtigita? Ĉu ĝi iras kontraŭ liaj konvinkoj? Tiu rajto estas fine sufiĉe grava kaj ŝarĝita per signifo. Neniu devus esti devigata (ruzo aŭ manipulado inkluzive) realigi taskon, kiu iras kontraŭ lia bonstato.
Konkludo
Tiu deklaro de la rajtoj de la klientoj kaj de la programistoj ne estas revolucia. Ĝi venas apogi kaj fortigi tion, kion oni jam trovas en la manifesto. Sed ĝia malsama atakangulo permesas pli bone lumi la rilaton, kiun devus havi la klientoj kaj la programistaj teamoj. Ĝi estis verkita kun tiu celo: « réparer la fracture entre l'entreprise et les développeurs ».
