Noi, metodologii, proiectăm sisteme complexe, dar nu ținem cont de caracteristicile de performanță ale componentei active a acestor sisteme, o componentă cunoscută pentru nelinearitatea și variabilitatea ei - persoana. Acest articol listează pe scurt teoriile și proiectele pe care a trebuit să învăț să înțeleagă acest lucru foarte simplu, precum și a determina ce trebuie să fie luate în considerare calități ale minții umane în stabilirea metodologiei și recomandări mai generale legate de procesul de dezvoltare. Pentru aceste calități puteți să faceți cele mai exacte previziuni despre viitorul curs al proiectului și despre aplicabilitatea oricărei metodologii pentru acesta.
Calea greșelilor este dificilă
Orice metodologie poate duce la eșecul proiectului.
Cele patru proprietăți principale
Ființa umană este o ființă comunicativă
Toți oamenii sunt diferiți
Oamenii ca non-liniare și cele mai importante componente în crearea de software
Acest raport se bazează pe experiența mea personală pe care am dobândit-o studiind aproximativ 40 de proiecte în ultimii 20 de ani.
Ideea principală a acestui articol este după cum urmează: metodologii dezvoltă sisteme complexe care au componente foarte volatile și neliniare - oameni. În același timp, reușesc cumva să ignore complet aceste componente și impactul pe care îl au asupra sistemului proiectat. După o anumită reflecție, această stare de lucruri pare absurdă, cu toate acestea, în industria noastră nu există mulți cercetători care să aibă timp să studieze serios influența factorului uman asupra dezvoltării software-ului.
Cele mai notabile excepții de la această regulă sunt Gerald Weinberg (Gerald Weinberg [Wei]) și Tom DeMarco (Tom DeMarco [Dm]), ale cărui cărți sunt publicate astăzi în aniversare (!) Editions. Lucrările lor sunt atât de populare în industria noastră, încât, se pare, ele ar trebui să aibă doar un interes crescut în acest subiect și să provoace intensificarea cercetării în acest domeniu. Acum, un număr tot mai mare de consultanți începe să se refere la oameni ca factor principal în dezvoltarea software-ului [B99] [Bună], dar, în general, comunitatea de dezvoltatori de software continuă să ignore faptul că această persoană ar trebui să fie un subiect central al cercetării. Acest lucru mi se pare o omisiune gravă - este ca și cum nu luați în considerare plafoanele metalice din pereți și vă plângeți de funcționarea precară a radioului.
Anterior, am considerat, de asemenea, că persoanele implicate în proiecte sunt un fel de factor secundar. Acest lucru a continuat până după câțiva ani de muncă ca cercetător și metodolog, nu am observat că recomandările mele ca metodologie nu corespund experienței mele în dezvoltarea de software. Problema nu a fost ceea ce dezvoltatorii mei au făcut (s-au confruntat foarte mult cu treaba). Problema a fost diferită: ceea ce am scris nu corespundea ceea ce am făcut.
În ultimii cinci ani, am încercat dureros să determin (este dificil pentru mine să fac asta chiar acum) "ceea ce este în fața ochilor mei". Treptat, mi-a devenit clar că în ecuația mea (și în orice altă metodologie) nu există o variabilă suficientă - influența asupra metodologiei unui astfel de concept ca "om".
Acum, când am luat în considerare acest parametru, previziunile și concluziile mele metodologice au început să corespundă cu ceea ce văd în viața reală. Acum cred că oamenii sunt principalul lucru. motorul proiectului.
Ce este diferit de ceea ce au scris Demarco și Lister în Peopleware? Ei și-au exprimat opinia că oamenii sunt un factor important și au subliniat o anumită specificitate a problemei. De asemenea, mă interesează modul în care grupul și caracteristicile individuale ale unei persoane afectează proiectarea metodelor de dezvoltare a software-ului (cu alte cuvinte, metodologia), aplicând grupurilor diferite care lucrează pe diferite tipuri de sarcini.
Ideile mele sunt foarte asemănătoare cu cele pe care Weinberg le-a prezentat în capitolul "Teaming" ("Teamwork") al cărții sale "Psihologia programării pe calculator". Mai ales în ceea ce privește opoziția a două stiluri de management - gestionarea sarcinilor și gestionarea întreținerii. Acest lucru este foarte aproape de ceea ce încerc să obțin - unele caracteristici și recomandări care rezultă din ele. Weinberg se bazează pe acele proiecte pe care le-a investigat în anii '60. Cu toate acestea, concluziile sale rămân corecte și utile și acum, 30 de ani mai târziu, ceea ce confirmă încă o dată stabilitatea și importanța factorului uman în dezvoltarea de software. Mi se pare că este timpul să examinați cu atenție astfel de factori și să începeți să tratați următoarele recomandări ca fiind elementele de bază ale dezvoltării software-ului, mai degrabă decât să le deschideți la fiecare 30 de ani.
În acest articol, voi vorbi despre munca pe care am făcut-o pentru a înțelege că oamenii sunt cheia succesului proiectului. În prezent, folosesc factorul uman pentru prognoză. Eu scriu acest articol în prima persoană, pentru că stilul academic, formal, nu este foarte potrivit pentru a descrie căutarea unui lucru care este destul de evident și nu este complet de înțeles. Cel mai bine este să-l prezentați sub forma unei povestiri de prima persoană.
Calea greșelilor este dificilă
Reclamele în 1987, când am fost implicat în dezvoltarea de software formale, au existat următoarea convingere: „Problema de dezvoltare de software constă în faptul că obiectivele și designul pot fi prea multe inexactități va fi bine, dacă putem obține de oameni pentru a lucra cu formalismul matematic .. “. Cu toate acestea, după ce am lucrat puțin în această direcție, am descoperit că ne confruntăm cu:
Problema 1. Persoanele implicate în proiect, este complet neinteresant să ne studiem sistemul.
Problema 2. Ei pot face cu totul fără metodologi și, în același timp, creează cu succes software. Am părăsit dezvoltarea formală, în timp ce colegii mei au prezentat o idee nouă: "Întreaga problemă este în formare, totul va fi bine dacă oferim dezvoltatorilor cunoștințele matematice necesare mult mai devreme, încă în liceu". Cu toate acestea, cunoștințele mele despre oameni au sugerat că o astfel de dorință este impracticabilă. Nu că am pus la îndoială avantajele evidente ale dezvoltării software formale, m-am îndoit de capacitatea noastră de a convinge 10 milioane de oameni să facă matematică. Ar fi corect să punem întrebarea în felul următor: "În ce circumstanțe și pentru ce ar trebui să fie inclus în proiect un specialist în dezvoltarea formală?"
M-am mutat la dezvoltarea instrumentelor și am început să lucrez cât mai etnocentric posibil. În același timp, i-am urmărit pe cei care au proiectat protocoale de comunicare și au discutat cu ei ce probleme au în timpul muncii lor. Colegii mei și am ajuns la aceeași concluzie: „Problema constă în faptul că oamenii încă preferă să se bazeze pe tablă va fi bine dacă le vom oferi un instrument software special, cu care se pot desena direct în .. calculator și să vedem cum vor fi implementate proiectele lor într-un stadiu incipient de lucru ".
Am petrecut câțiva ani pentru a dezvolta un generator special care transformă diagramele secvenței și interacțiunii în arhitectura produsului software și sistemul de reguli [Ci]. Multe companii au lucrat (și lucrează) la sarcini similare, de exemplu, efectuate de mașinile finale ale lui Harel [Ha].
Problema 1. Persoanele implicate în proiect, este complet neinteresant să ne studiem sistemul.
Acele echipe care lucrează cu succes la proiectele lor utilizează procese incrementale de dezvoltare [Co95]
La proiectarea oricărei tehnici, "CRC-cardurile" mai complicate [B87] sunt considerate prea complicate și nu sunt utilizate [Co94].
Cei care sunt implicați în proiectare au întotdeauna posibilitatea de a abandona orice produs software sau tehnologie pe care nu le place. E suficient să-i spuneți șefului: "Acest lucru încetinește munca, dacă o folosesc, nu voi fi la timp", și va permite designerilor să acționeze la propria lor discreție. În acel moment, această observație nu mi sa părut deosebit de importantă, dar, totuși, am scris-o jos și.
Navigare rapidă înapoi: Ctrl + ←, înainte Ctrl + →
Textul cărții este prezentat doar în scop informativ.
Trimiteți-le prietenilor: