Căi scurte, decizii rapide

Dezvoltarea software Lean a devenit din ce în ce mai importantă în ultimii ani. Cu toate acestea, nu este suficient să se utilizeze doar dezvoltarea software-ului lean în echipa de dezvoltare; cerințele și procesul de concepție trebuie, de asemenea, să fie organizate „lean”. Dr. În acest articol din două părți, Matthias Eberspächer descrie o structură organizațională încercată și testată care permite un concept de software slab. În prima parte el introduce cele mai importante două organisme ale acestei organizații.

conţinut

Ce este și de unde vine „Lean”?
Organizarea proiectului
Echipa de bază (KT)
Titularii mandatului (MT)
perspectivă
literatură

subiecte

Seria articolelor

Organismele centrale și sarcinile acestora
Roluri și recomandări suplimentare pentru practică

conţinut

Ce este și de unde vine „Lean”?
Organizarea proiectului
Echipa de bază (KT)
Titularii mandatului (MT)
perspectivă
literatură

Toyota a arătat cum este: astăzi, mașinile sunt produse „slabe”. Producția nu se realizează „la depozit”, ci la comandă, doar piesele instalate imediat sunt livrate. Dar poate fi programat programul în același mod în care sunt fabricate mașinile? Da, poti! Scopul dezvoltării software-ului lean este de a reduce la minimum timpul de execuție de la cerere până la punerea în funcțiune a software-ului finit. Cu toate acestea, nu este suficient să folosiți Lean Software Development doar în echipa de dezvoltare: cerințele și procesul de concepție trebuie, de asemenea, să fie organizate „Lean”. Criticul succesului este stabilirea și întreținerea unei „atracții a clienților” uniforme, care să permită dezvoltarea eficientă a software-ului lean.

Acest articol din două părți se concentrează exact pe interfața dintre utilizatori și echipa de dezvoltare. Este arătat modul în care managerii de proiect și clienții înființează în mod ideal echipa de proiect pentru un proiect slab, modul în care cerința și procesul de concepție sunt controlate în mod slab și ceea ce trebuie luat în considerare. Chiar dacă prima experiență cu această abordare a fost câștigată în proiecte de software la producătorii de automobile, nu există nimic în modul de aplicare a conceptelor descrise aici la alte tipuri de proiecte de dezvoltare și industrii.

Prima parte descrie ce se află în spatele managementului lean și ce aplicații ale conceptelor lean există în dezvoltarea de software. Este descrisă o organizare a structurii proiectului care permite o concepție software slabă și cel mai important comitet - echipa de bază - și cel mai important rol - cel al aleșilor - din această organizație sunt descriși în detaliu. A doua parte completează descrierea corpurilor și rolurilor individuale, cum ar fi a managerului de proiect și explică procesul proiectului folosind un exemplu practic. Articolul se încheie cu recomandări care au rezultat din experiența cu această abordare în proiecte.

Am avut experiențe foarte bune cu abordarea și organizarea proiectului prezentate în proiectele mele. Ideea din spatele acestei abordări nu se aplică numai proiectelor care se desfășoară exclusiv conform principiilor slabe, ci și proiectelor în care implementarea ulterioară a conceptelor are loc în conformitate cu alte modele de proces agile sau chiar tradiționale (de exemplu, cascadă) . Motivația pentru o abordare slabă în gestionarea și concepția cerințelor este, desigur, cu atât mai mare cu cât restul implementării proiectului este agil și slab. Metodologia prezentată aici este destinată să servească drept sugestie pentru a utiliza o organizație de proiect slabă pentru dvs. și pentru a o dezvolta în continuare.

Avantajele abordării

Avantajele procedurii prezentate în acest articol intră în joc doar cu un domeniu de aplicare suficient al proiectului: durata ar trebui să fie mai mare de șase luni, iar echipa de proiect ar trebui să includă cel puțin zece angajați cu normă întreagă. În caz contrar, efortul implicat în înființarea și stabilirea organizării proiectului, inclusiv formarea personalului proiectului, depășește beneficiile procedurii.

Pentru a ilustra acest beneficiu, compararea sferei de implementare planificate cu sfera serviciilor procesate efectiv pe interval de planificare (de obicei un an) este informativă: arată că lucrările de dezvoltare efectuate pe an au fost de aproximativ două ori mai mari decât cele planificate inițial. Cu alte cuvinte: Cu capacitățile disponibile pentru concepția tehnică, ar putea fi conceptualizate aproximativ de două ori mai multe subiecte decât au fost planificate. Planificarea acestor proiecte s-a bazat în esență pe valorile empirice din proiectele tradiționale: Câte subiecte pot atinge o maturitate conceptuală tehnică suficientă pentru implementare într-un an? Desigur, nu se poate deduce din acest număr că procedura prezentată aici este de două ori mai bună decât, de exemplu, modelul cascadei; cu toate acestea, este un indiciu clar că lucrul cu concepte slabe poate fi mult mai eficient decât modelele procedurale tradiționale.

Mediul tipic de proiect în care s-a aplicat această abordare au fost proiecte pentru (în continuare) dezvoltarea și/sau consolidarea peisajelor IT existente la producătorii de automobile. Punctele tari ale procedurii s-au arătat în special atunci când cerințele care urmează a fi puse în aplicare nu au fost încă pe deplin pregătite pentru un concept tehnic, ci doar la „nivelul de rubrică”, de ex. au fost cunoscute aproximativ sub forma unei liste de subiecte într-un tabel Excel. Pentru definirea unui buget și a unui interval de timp cu care poate lucra echipa de proiect, obiectivele proiectului/afacerii au fost întotdeauna formulate clar („SMART”) și a fost disponibil un plan de structură a proiectului cu titluri definite pentru pachetul de lucru.

Performanța pachetelor individuale de lucru ar putea fi întotdeauna tăiată în dimensiuni de loturi suficient de mici, independente. Aceasta este o condiție prealabilă importantă, deoarece aceasta este singura modalitate de a realiza un timp scurt și uniform al proiectului. Angajații interni ai departamentelor de specialitate și IT, precum și consultanți externi și furnizori de la furnizorii de servicii IT au fost disponibili pentru implementarea proiectului cu fazele de concepție tehnică, concepție IT, implementare, integrare și teste de acceptare și punere în funcțiune.

Ce este și de unde vine „Lean”?

„Lean” vine de la Toyota Production System (TPS), care se concentrează pe optimizarea proceselor organizaționale. Cel mai cunoscut concept al TPS este producția sincronizată cu cererea („just-in-time”): numai piesele sunt trimise către ...