Agile eksperdid vs Agile manifest

Kas arvate, et teie kohalik kohalik asjatundja on Agile manifesti lugenud? Kas sa oled? Noh, see pole probleem ... kui te ei kasuta sõna “Agile” igapäevaselt! Aga kui te räägite (või teie kohalik asjatundja) ... noh - see on midagi sellist, nagu inimesed, kes räägivad usust liiga palju, kuid ei ole oma kirjanduse tundidest alates avanud piiblit (poliitilise korrektsuse hoiatus) ega oma valitud püha raamatut 10 aastat tagasi ... Me ei meeldi neile. Põhjusega.

Olgu, ärgem kommenteerige teisi inimesi ja nende arvamusi. Vaatame selle asemel samm-sammult läbi “Agile Piibli”.

Agile manifesti tsitaadid antakse sisse

selline tekstiplokk

ja meie kommentaarid antakse tavalises taandes. Lähme!

Manifest, üks ja ainus!

Meie peamine prioriteet on kliendi rahuldamine
varase ja pideva sünnituse kaudu
väärtuslikku tarkvara.

See on nii suurepärane idee! Selle valmistamise ajal oli see tõesti revolutsiooniline! Kuid selle idee teostamine on kuidagi raskem, kui need paar rida oleks võinud tajuda.

Põhiprobleem: Kõik, kellel on olnud kliendiga otsene kontakt, teavad, et selle manifesti mõte on vähemalt mõnevõrra keeruline.

Kahjuks pole klient alati kindel, mida ta soovib, või soovib ta korraga liiga palju asju ega oska neid õigesti tähtsustada! Pealegi võib juhtuda, et mõnda neist asjadest, mida klient arvas (id), mida ta tahtis, hiljem ei tahtnud…

Kui me selle kõrvale jätame - manifesti mõte tõestab toote edukusele oma väärtust! Kuid neid erandeid EI tohiks unarusse jätta, kuna need võivad lõppeda surmaga!

Järgmine punkt hõlmab midagi sarnast, jätkakem seda teemat seal.

Tere tulemast muutuvatesse nõuetesse, isegi hilja
areng. Agiilsed protsessid muudavad
kliendi konkurentsieelis.

See on hea. Kuid pidev pöörlemine ja arendusmeeskonna surve avaldamine muudavad toote hapraks. Kiire kodeerimine paljude projekti ümbersuunamistega muudab toote koodikvaliteedi madalaks, seega muutused muutuvad raskemaks. Ratsionaalsem ja rahulikum areng parandab muudatuste tegemise efektiivsust tootearenduse hilisemates etappides. Oleme nõus, et muudatusi tuleks tervitada, kuid proportsionaalselt tuleks muuta ka muid lepingu / lepingu tingimusi! Paljudel juhtudel loodetakse toode kasutusele võtta samal ajal, kui see oleks olnud ilma täiendavate muudatuste nõudeta. Pole lahe.

Agility eesmärk on olla oodatud muutusteks valmis, mitte aga kõike ja alati muuta. Need, kes on akrediteeritud potentsiaalse kliendi / kliendi vaheliseks suhtlemiseks, peaksid algusest peale läbi rääkima realistliku kokkuleppe üle. Sageli säästab 10 minutit pliiatsi ja paberiga õigel ajal (projekti algus) hilisemates etappides päevi, nädalaid ja isegi arengukuid (ümbersuunamine, pööramine, muutmine)! Sellist toodete algust lõtvumist tuleks pidada ebaprofessionaalseks, sest see on ju väga! Mõtteviis „lähme klienti hankima, hiljem mõtleme midagi töö lõpetamiseks välja” ja see on ebaeetiline ning arendajatel tuleb sageli päeva kokku hoida (ületunnid, nädalavahetused, kodused tööd, töökohad) stressirohke ümbritsev)… Pole lahe. Ja tõesti - isegi mitte agar.

Tarnige töötavat tarkvara
sageli, alates a
paar nädalat kuni paar kuud, koos a
lühema ajakava eelistamine.

Mul on selle kohta ainult häid kogemusi. See annab võimaluse varaseks veojõu testimiseks-õppimiseks-parendamiseks tagasiside saamiseks. Suurepärane värk, kui Agile kontseptsioon on kasutatav vajalikku tüüpi toodete tarkvaraarenduses. (Mitte alati, uskuge või mitte.)

Ärimehed ja arendajad peavad töötama
iga päev koos kogu projekti vältel.

Ok, võib-olla mitte iga päev, aga ka - pöidlad üles! Meil (inimestel) pole viimase 15 aasta jooksul seda õnnestunud rikkuda ... Andke meile aega.

Ehitage projekte motiveeritud inimeste ümber.
Andke neile vajalik keskkond ja tugi,
ja usalda neid töö tegemiseks.

See on koht, kus enamik niinimetatud agiliste ei suuda Agile manifesti järgi tegutseda. Neil puudub sageli lugupidamine inimeste vastu, kes on kui mitte eksperdid, siis ikkagi paremad spetsialistid, arvestades nende valdkonda, kui agar projektijuht. See paneb juhi liiga palju teiste inimeste töösse kaasama, mis rikub olulised masinarattad ükshaaval ära. Edasine “masina” paindlikkus ja töökindlus muutuste tegemisel on madalam. Mis on vastupidine.

Kõige tõhusam ja tõhusam meetod
teabe edastamine arenduses ja selle sees
meeskond on näost näkku vestlus.

Noh, me ei saa selle vastu midagi öelda. Vastupidi, hooray selle eest!

Töötav tarkvara on edusammude peamine mõõt.

Jah. Probleem on selles, et ka paljud nn agistid ei austa seda klauslit.

Agiilsed protsessid edendavad säästvat arengut.
Sponsoritel, arendajatel ja kasutajatel peaks olema võimalus
säilitada püsiv tempo määramata aja jooksul.

Raske saavutada, kuid muidugi - suurepärane suunis.

Pidev tähelepanu tehnilisele tipptasemele
ja hea disain suurendab paindlikkust.

Jällegi, kurb, unustavad nn vilgas projektijuhid selle sageli, põhjustades tõsiseid, kui mitte saatuslikke tagajärgi.

Lihtsus - summa maksimeerimise kunst
tegemata töö - on hädavajalik.

Tervitus, lihtsus!

Parimad arhitektuurid, nõuded ja kujundus
tekivad iseorganiseeruvatest meeskondadest.

Ave!

Regulaarsete ajavahemike järel mõtiskleb meeskond kuidas
efektiivsemaks muutmiseks, siis häälestab ja kohandab
selle käitumist vastavalt.

Aamen!