Buna ziua,

Am postat slide-urile prezentarii de metodologii (MSF for Agile Software Development si MSF for CMMI Process Improvement) la adresa

http://www.techready.tv/presentations/Metodologii_proiecte_IT.mht

Va rog sa faceti comentarii si sugestii pentru imbunatatirea ei.

 

Prezentarea va face parte dintr-un seminar la care lucrez acum despre MSF si Visual Studio Team System

 

Multumesc mult,

---

Adrian Stoian
Please visit TechReady.TV

Cred ca ce ar prinde foarte bine este un mic exemplu practic de utilizare. Pentru un proiect mic. De exemplu folosirea MSF pentru dezvoltarea continutului seminarului

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Un comentariu legat: PM traditional vs MSF

Şi dacă nu ştii ce trebuie să construieşti, cum poţi planifica şi urmări proiectul.
In PM traditional, la nivel de WBS nu trebuie sa stii totul de la inceput. Intr-un WBS nu descrii ierarhic doar produsul, poti sa pui si faze, sau subproiecte si pe parcurs acestea pot fi rafinate.

PM tradiţional urmăreşte proiectul din perspectiva muncii depuse şi nu din cea a valorii aduse clientului.
Este relativ. Vezi EV (Earned Value) analysis.

 

Parerea mea este ca MSF nu vine ca o alternativa la PM traditional, ci este una din optiunile pe care le avem la dispozitie. Nu vad de ce nu ar merge PM traditional in cazul unui proiect de support pentru un produs?

Revin si cu alte comentarii.

As vrea, Adi sa dezvolt ceea ce am discutat impreuna dupa prezentarea ta. Este necesar sa indici povesti de succes pe langa marturii ale personalitatilor din domeniu convinse de aceste tendinte toate cu linkuri catre astfel de surse, pentru ca sunt persoane foarte legate de PM traditional si trebuie sa ai argumente forte pentru a sustine ceva impotriva a ceea ce inseamna clasic in PM.

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

As vrea sa ridic o problema care atinge problematica discutata aici:

Sa zicem ca ai de construit o aplicatie software si o faci prin "Agile".

Cineva iti cere sa faci documentatia si planificarea proiectului prin metode clasice.

O intrebare care pare idioata dar , asta e :

Cum poti face aceasta adaptare ? Este posibila ?

Care ar fi , pe scurt, documentatia de facut pentru "Agile" chia daca stiu de principiul "Working software over comprehensive documentation "

si ca se prefera ca insasi "codul" sa fie singura documentatie palpabila (spune cineva angrenat in aceasta miscare).

 

 

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

MihaiBejenariu:

Un comentariu legat: PM traditional vs MSF

Şi dacă nu ştii ce trebuie să construieşti, cum poţi planifica şi urmări proiectul.
In PM traditional, la nivel de WBS nu trebuie sa stii totul de la inceput. Intr-un WBS nu descrii ierarhic doar produsul, poti sa pui si faze, sau subproiecte si pe parcurs acestea pot fi rafinate.

PM tradiţional urmăreşte proiectul din perspectiva muncii depuse şi nu din cea a valorii aduse clientului.
Este relativ. Vezi EV (Earned Value) analysis.

 

Parerea mea este ca MSF nu vine ca o alternativa la PM traditional, ci este una din optiunile pe care le avem la dispozitie. Nu vad de ce nu ar merge PM traditional in cazul unui proiect de support pentru un produs?

Revin si cu alte comentarii.

Salut Mihai,

Comentariul meu cu privire la WBS era ca urmareste proiectul din perspectiva muncii depuse si nu din perspectiva valorii aduse beneficiarului. Project Managementul traditional masoara foarte bine cat ai muncit (task-uri), cat a costat, si cat timp a trecut, dar masoara prea putin ccare au fost functionalitatile livrate si care e valoarea acestora, asa cum e perceputa de client. 

Asa cum stiu eu Earned Value Analysis e o metoda de estimare a incadrarii in constrangeri (timp si costuri in principal) pana la finalul proiectului avind in vedere evolutia de pana in prezent (actuals vs baseline). Din nou, EVA nu masoara valoarea adusa beneficiarului, ci sansele ca proiectul sa se incadreze in constrangeri pana la final.

De acord, MSF e doar una din optiuni. Spectrul de metodologii e foarte larg, incepand cu XP, Agile si Scrum si terminand cu cele formale gen CMMI sau PMI.

MSF, cu cele doua instante (MSF for Agile Software Development si MSF for CMMI Process Improvement) a fost ales ca "metodologia built-in" din Visual Studio Team System. Asta il face foarte la indemana pentru a fi folosit de echipele care au deja Team System.

Si daca nu ne place MSF, exista intotdeauna alternative. Deja a aparut Scrum pentru Team System si e in lucru o varianta light de RUP, numita Essentials Unified Process, facuta de Ivar Jacobson, cel care a fost si in spatele RUP.

Toate cele bune,

Adi

---

Adrian Stoian
Please visit TechReady.TV

ggciubuc:

Sa zicem ca ai de construit o aplicatie software si o faci prin "Agile".

Cineva iti cere sa faci documentatia si planificarea proiectului prin metode clasice.

O intrebare care pare idioata dar , asta e :

Cum poti face aceasta adaptare ? Este posibila ?

Care ar fi , pe scurt, documentatia de facut pentru "Agile" chia daca stiu de principiul "Working software over comprehensive documentation "

si ca se prefera ca insasi "codul" sa fie singura documentatie palpabila (spune cineva angrenat in aceasta miscare).

Agile nu exclude planificarea si documentatia.

Din punctul de vedere al planificarii, poti imparti proiectul pe faze si iteratii. Agile presupune ca in fiecare iteratie adaugi un numar de functionalitati la produs, dar lista functionalitatilor alese pentru a fi implementate este decisa inainte de fiecare iteratie in parte si este bazata pe rezultatele iteratiei anterioare si pe feedback-ul clientului. In Agile e mai putin important sa te incadrezi in constrangeri (cum ar fi timpul) ci sa raspunzi cat mai bine la cerintele beneficiarului.

Legat de documentatie, aceasta poate fi considerata un livrabil al proiectului, la fel ca si codul. Daca clientul solicita acest lucru si pentru el inseamna valoare, atunci trebuie inclusa in proiect ca livrabil.

Toate cele bune,

Adi

---

Adrian Stoian
Please visit TechReady.TV

Si o veste noua. Seminarul de MSF v4 si VSTS este aproape gata. Prezentarea de la SQL Server Day este de fapt primul modul din seminar.

Daca doriti sa participati la seria pilot in perioada urmatoare, va rog sa-mi dati un semn pe adresa astoian@techready.ro

Managementul proiectelor de dezvoltare software cu Microsoft Solutions Framework şi Visual Studio Team System

Agenda seminarului:

• Metodologii pentru proiecte IT – Prezentarea metodologiilor actuale folosite la dezvoltarea software: Agile, XP, Scrum, CMMI. Accentul pe valoarea adusă beneficiarului (value-up). De câte procese avem nevoie. Prezentarea metodologiilor MSF for Agile Software Development şi MSF for CMMI Process Improvement.
• Modelul de echipă – Prezentarea modelului de echipă propus de MSF, descrierea rolurilor şi a responsabilităţilor fiecăruia: Program Management, Architecture, Development, Test, Release/Operations, User Experience, Product Management. Cele mai bune practici pentru organizarea echipelor de dezvoltare software.
• Analiza cerinţelor – Colectarea şi prioritizarea cerinţelor preliminare. Exciters, Satisfiers şi Dissatisfiers. Designul arhitecturii soluţiei. Funcţionalităţi şi Qualities of Service.
• Descriere Team System – Descrierea arhitecturii Visual Studio Team System şi a componentelor şi versiunilor individuale.
• Project Management - Descrierea rolului de Project Manager. Atribuţii: Organizarea echipei, iniţierea proiectului, managementul proiectului. Demonstraţii cu Visual Studio Team System.
• Design Arhitectură – Descrierea rolului de Arhitect al soluţiei. Arhitect de infrastructura versus arhitect de aplicaţii. DSI, SDM şi DSL. Distributed Systems Designer: Logical Datacenter Designer, Application Designer, System Designer, Deployment Designer. Demonstraţii cu Visual Studio Team System.
• Dezvoltare - Descrierea rolului de Dezvoltator. Utilizare Class Designer. Version Control. Test Driven Development. Team Foundation Build. Demonstraţii cu Visual Studio Team System.
• Testare – Descrierea rolului de Tester. Managementul testării. Tipuri de teste în Visual Studio Team System. Rapoarte de testare şi urmărirea bug-urilor. Demonstraţii cu Visual Studio Team System.
• Design Baze de Date – Descrierea rolului de Database Professional. Designul bazelor de date folosind Visual Studio Team Edition for Database Professionals. Demonstraţii cu Visual Studio Team System.
• Troubleshooting - Cum putem utiliza Visual Studio Team System pentru a identifica probleme tipice în derularea proiectelor.
• Team Foundation Server – Descrierea componentelor şi serviciilor din cadrul Team Foundation Server: Services (Core), Version Control, MSBuild, Data Warehouse, Reporting Services, Work Item Tracking.
• Extindere Team System – cum putem implementa propria metodologie în VSTS prin modificarea template-urilor existente. Alte metodologii disponibile: Scrum de la Conchango şi Essential Unified Process (EssUP).

Toate cele bune,

Adi

---

Adrian Stoian
Please visit TechReady.TV