Articles

Waterfall vs. Agile: care este metodologia de dezvoltare potrivită pentru proiectul dvs.?,

Posted by admin
Scrisă de Mary Lotzon iulie 5, 2018

Una dintre primele decizii care ne confruntăm pentru fiecare proiect al nostru implementări la Segue este „ceea Ce metodologie de dezvoltare ar trebui să folosim?”Acesta este un subiect care primește multe discuții (și adesea dezbateri aprinse)., Dacă acest lucru nu este ceva cu care ați lucrat înainte, o definiție a metodologiei de dezvoltare este în ordine; pune foarte simplu, este o modalitate de organizare a activității de dezvoltare software. Nu este vorba despre un stil de management de proiect sau o abordare tehnică specifică, deși veți auzi adesea acești Termeni toți aruncați împreună sau folosiți interschimbabil.cele două metodologii de bază, cele mai populare sunt:

  1. Cascada: (ugh, nume teribil!,), care ar putea fi numită mai corect abordarea „tradițională” și
  2. Agile: un tip specific de dezvoltare rapidă a aplicațiilor și mai nou decât Cascada, dar nu atât de nou, care este adesea implementat folosind Scrum.ambele sunt metodologii utilizabile, mature. Fiind implicat în proiecte de dezvoltare software de mult timp, iată gândurile mele despre punctele forte și punctele slabe ale fiecăruia.

    metodologia cascadei

    Cascada este o abordare liniară a dezvoltării de software., În această metodologie, secvența de evenimente este ceva de genul:

    1. a Aduna și documenta cerințele
    2. Design
    3. Codul și unitate de testare
    4. de a Efectua testarea sistemului
    5. de a Efectua testarea de acceptare utilizator (UAT)
    6. a Rezolva orice probleme
    7. livrarea produselor finite

    Într-o adevărată Cascadă de dezvoltare a proiectului, fiecare dintre acestea reprezintă o etapă distinctă de dezvoltare de software, și fiecare etapă, în general, se termină înainte de următoarea poate începe., Există, de asemenea, de obicei o poartă etapă între fiecare; de exemplu, cerințele trebuie să fie revizuite și aprobate de către client înainte de proiectare poate începe.există lucruri bune și rele despre abordarea cascadei. Pe partea pozitivă:

    • dezvoltatorii și clienții sunt de acord cu privire la ceea ce va fi livrat la începutul ciclului de viață al dezvoltării. Acest lucru face planificarea și proiectarea mai simplă.
    • progresul este mai ușor de măsurat, deoarece domeniul complet al lucrării este cunoscut în prealabil.,
    • pe tot parcursul efortului de dezvoltare, este posibil ca diverși membri ai echipei să fie implicați sau să continue cu alte activități, în funcție de faza activă a proiectului. De exemplu, analiștii de afaceri pot afla și documenta ce trebuie făcut, în timp ce dezvoltatorii lucrează la alte proiecte. Testerii pot pregăti scripturi de testare din documentația cerințelor în timp ce codarea este în curs de desfășurare.
    • cu excepția recenziilor, aprobărilor, ședințelor de stare etc., o prezență a Clientului nu este strict necesară după faza cerințelor.,
    • deoarece proiectarea este finalizată la începutul ciclului de viață al dezvoltării, această abordare se pretează proiectelor în care mai multe componente software trebuie proiectate (uneori în paralel) pentru integrarea cu sisteme externe.în cele din urmă, software-ul poate fi proiectat complet și mai atent, bazat pe o înțelegere mai completă a tuturor livrabilelor software., Acest lucru oferă un design software mai bun, cu o probabilitate mai mică de” efect fragmentat”, un fenomen de dezvoltare care poate apărea pe măsură ce bucăți de cod sunt definite și adăugate ulterior la o aplicație unde pot sau nu se potrivesc bine.

    iată câteva probleme pe care le-am întâlnit folosind o abordare cascadă pură:

    • o zonă care aproape întotdeauna se încadrează scurt este eficacitatea cerințelor. Colectarea și documentarea cerințelor într-un mod semnificativ pentru un client este adesea cea mai dificilă parte a dezvoltării de software, în opinia mea., Clienții sunt uneori intimidați de detalii, iar detaliile specifice, furnizate la începutul proiectului, sunt necesare cu această abordare. În plus, clienții nu sunt întotdeauna capabili să vizualizeze o aplicație dintr-un document de cerințe. Wireframe – urile și machetele pot ajuta, dar nu există nicio îndoială că majoritatea utilizatorilor finali au dificultăți în a pune aceste elemente împreună cu cerințele scrise pentru a ajunge la o imagine bună a ceea ce vor primi.,un alt dezavantaj potențial al dezvoltării cascadei pure este posibilitatea ca clientul să fie nemulțumit de Produsul software livrat. Deoarece toate livrabilele se bazează pe cerințe documentate, este posibil ca un client să nu vadă ce va fi livrat până când nu este aproape terminat. În acel moment, schimbările pot fi dificile (și costisitoare) de implementat.

    metodologia Agile

    Agile este o abordare iterativă, bazată pe echipă pentru dezvoltare. Această abordare pune accentul pe livrarea rapidă a unei aplicații în componente funcționale complete., Mai degrabă decât crearea de sarcini și programe, tot timpul este „time-boxed” în faze numite „sprinturi.”Fiecare sprint are o durată definită (de obicei în săptămâni), cu o listă de rezultate, planificată la începutul sprintului. Livrabilele sunt prioritizate în funcție de valoarea afacerii, determinată de client. Dacă toate lucrările planificate pentru sprint nu pot fi finalizate, lucrările sunt reprioritizate și informațiile sunt utilizate pentru planificarea viitoare a sprintului.pe măsură ce lucrarea este finalizată, aceasta poate fi revizuită și evaluată de echipa de proiect și de client, prin versiuni zilnice și demonstrații de sfârșit de sprint., Agile se bazează pe un nivel foarte ridicat de implicare a clienților pe tot parcursul proiectului, dar mai ales în timpul acestor recenzii.unele avantaje ale abordării Agile sunt ușor de văzut: clientul are oportunități frecvente și timpurii de a vedea lucrarea livrată și de a lua decizii și schimbări pe tot parcursul proiectului de dezvoltare.

  3. clientul câștigă un puternic sentiment de proprietate prin lucrul extensiv și direct cu echipa de proiect pe tot parcursul proiectului.,dacă timpul de lansare pe piață pentru o anumită aplicație este o preocupare mai mare decât lansarea unui set complet de caracteristici la lansarea inițială, Agile poate produce mai rapid o versiune de bază a software-ului de lucru care poate fi construit în iterații succesive.
  4. dezvoltarea este adesea mai orientată către utilizator, probabil un rezultat al Direcției din ce în ce mai frecvente din partea clientului.,
  5. Pentru mai Agil beneficii de Dezvoltare, vă rugăm să consultați 8 Beneficii ale Agile de Dezvoltare Software
  6. Și, desigur, există unele dezavantaje:

  • grad foarte ridicat de implicare din partea clientului, în timp ce o mare pentru proiect, poate prezenta probleme pentru unii clienți care pur și simplu nu au timp sau interes pentru acest tip de participare.
  • Agile funcționează cel mai bine atunci când membrii echipei de dezvoltare sunt complet dedicați proiectului.,
  • deoarece Agile se concentrează pe livrarea în cutie în timp și reprioritizarea frecventă, este posibil ca unele articole setate pentru livrare să nu fie finalizate în intervalul de timp alocat. Sprinturi suplimentare (dincolo de cele planificate inițial) pot fi necesare, adăugând costul proiectului. În plus, implicarea clienților duce adesea la caracteristici suplimentare solicitate pe tot parcursul proiectului. Din nou, acest lucru se poate adăuga la timpul și costul total al implementării.,relațiile strânse de lucru într-un proiect agil sunt cel mai ușor de gestionat atunci când membrii echipei se află în același spațiu fizic, ceea ce nu este întotdeauna posibil. Cu toate acestea, există o varietate de moduri de a gestiona această problemă, cum ar fi camere web, instrumente de colaborare etc.
  • natura iterativă a dezvoltării Agile poate duce la o refactorizare frecventă dacă domeniul complet al sistemului nu este luat în considerare în arhitectura și designul inițial. Fără această refactorizare, sistemul poate suferi de o reducere a calității generale., Acest lucru devine mai pronunțat în implementările la scară mai mare sau cu sisteme care includ un nivel ridicat de integrare.

alegerea între agil și cascadă

Deci, cum alegem? În primul rând, schimbăm puțin Jocul (ceea ce fac majoritatea organizațiilor de dezvoltare software) definind propriul nostru proces. La Segue, se numește Cadrul nostru de proces și este o variație a metodologiei tradiționale a cascadelor., Modificările noastre includ utilizarea prototipurilor, acolo unde este posibil, pentru a oferi clientului o imagine mai bună a produsului finit la începutul ciclului de proiectare/dezvoltare. Acest lucru ajută la îmbunătățirea înțelegerii de către echipă a cerințelor și a comunicării cu clientul. După ce cadrul primar al aplicației este completat pe cerințele de nivel înalt, vom continua să se dezvolte și, de asemenea, pentru a ajunge la client pentru rafinarea cerințelor. În acest fel, ne străduim să fim cât mai iterativi fără a compromite arhitectura generală a sistemului.,

luăm în considerare următorii factori atunci când analizăm ce metodologie să folosim:

factorii de mai sus nu sunt ponderați în mod egal; fiecare este evaluat în funcție de proiectul individual și de circumstanțe.

Deși începem să vedem adoptarea în masă a diferitelor metodologii Agile în Întreprindere (chiar DoD și agenții Federale), există mai multe organizații care sunt lente pentru a face schimbarea., De asemenea, este foarte comun ca organizația să treacă într-o abordare hibridă agilă care combină aspectul atât agil, cât și Cascada. Ghidul de practici Agile a fost dezvoltat special pentru a ajuta organizația să înțeleagă și să evalueze utilizarea abordărilor Agile și hibride Agile. Project Management Institute (PMI), care a dezvoltat Proiectul de Management Body of Knowledge (PMBOK) Ghid colaborat cu Agile Alliance la pachet cele două ghiduri într-o singură jertfă pentru a ajuta organizațiile, managerii și conducerea crește agilitatea în procesul de dezvoltare.,odată ce am decis ce metodologie de bază să folosim, putem rafina procesul pentru a se potrivi cel mai bine obiectivelor proiectului nostru. În cele din urmă, deși modul în care ne desfășurăm activitatea este important, livrarea unui produs solid și întreținător care satisface clientul nostru este ceea ce contează cu adevărat.

Leave A Comment