Utilizarea MS Project pentru managementul de proiect pentru dezvoltarea

Vreau să împărtășesc experiența mea de a folosi MS Project pentru managementul de proiect în dezvoltarea de software. Sunt deja 10 ani implicat în managementul proiectelor,
și, ca urmare m-am născut într-o anumită metodologie de utilizare MS Project, care vă permite să scape de multe beneficii și, astfel, mai puțin dependente de neajunsurile sale.

scurtă introducere

Întreaga metodologie - este doar un set de tehnici simple și utilizarea recomandărilor MS Project manager de proiect pentru aplicatii. Imediat vă spun, că metodologia nu este universală, și poate fi utilizat numai cu anumite restricții, pe care le voi menționa în cursul narațiunii.

Pentru a începe, să ne amintim că, de obicei, necesare unui manager de proiect. Pentru manageri cu experiență este, evident, un novice (sau doar pe cale de a deveni lideri) va fi util să se amintească încă o dată. Astfel, un proiect de dezvoltare de software - este de a crea un produs unic. La diferite etape ale ciclului de viață al proiectului, din Republica Polonă este necesară pentru a rezolva diverse probleme.

Înainte de proiect

Înainte de începerea proiectului de către managerul de proiect este de obicei necesară pentru a răspunde la două întrebări:

1. cât de mult proiectul va lua timp
2. cât de mult proiectul va costa

Este important să înțelegem că nimeni nu este interesat în formă de răspuns „nu mai devreme de șase luni.“ Este nevoie de doar o limită superioară.

Notă. N-am avut de a face cu evaluarea monetară evidentă a proiectului, și, după cum am înțeles acum, aceasta este o omisiune gravă. Toate proiectele pe care am condus, efectuate de angajați. Echipa de proiect a fost format pe tot timpul proiectului, unii experți au fost implicați de ceva timp. De fapt, eu sunt necesare pentru a estima numărul de interpreți necesari, precum și calendarul de implicare a acestora. Cred că aceasta este o situație destul de tipic pentru companiile implicate în dezvoltarea de software. În cele din urmă, totul se reduce la efortul de evaluare, care, cu utilizarea unor formule empirice, se transformă într-o estimare a costurilor proiectului. După cum puteți vedea, există o corelație directă din costul proiectului din termenii săi.

Pe parcursul proiectului

În contextul restricțiilor menționate, sarcina principală a managerului de proiect este acela de a asigura punerea în aplicare a proiectului în termenul stabilit, și că este direct
Ea afectează costul său. Cheltuieli neprevăzute care însoțesc în mod necesar orice proiect poate duce la termene ratate. Strict vorbind, termenele de proiect sunt în mod neașteptat a scăzut, dar sincer, nu am mai văzut nimic. Din capul este necesară pentru a reacționa la astfel de evenimente, în scopul de a reduce efectele negative. Singurul mod știu de a rezolva această problemă - este o planificare atentă, monitorizarea regulată a problemelor iminente și a planurilor de adaptare.

La finalizarea proiectului

La finalizarea managerul de proiect, de obicei, se uită înapoi și rezumă rezultatele. Cel mai adesea are nevoie pentru a evalua modul în care proiectul se ridică de la programele planificate și de ce sa întâmplat.

Ce poate MS Project

În ciuda complexității aparente, MS Project este foarte simplu conceptual. El își desfășoară activitatea trei entități - sarcini, resurse, calendar și legături între ele. De fapt, - aceasta este baza de date, interfața cu utilizatorul pentru crearea și editarea entitatilor, iar minimul este de automatizare destul de simplu (de exemplu, că proiectul se face, ca răspuns la datele de intrare).

Să ne examinăm pe scurt proprietățile entităților.

Sarcina are o durată, suma alocată resursei și un alt iad de o mulțime de proprietăți diferite. În cazul în care proprietățile built-in nu este suficient, puteți adăuga propria - pe care le folosim mai târziu. Sarcinile pot fi legate între ele în diferite rapoarte (precursori adepți, etc.).

Resursa are o mulțime de caracteristici descriptive, dar cel mai important - pentru ea poate
cere în disponibilitatea de timp, este utilizat pentru acest calendar. O resursă poate fi
atribuit sarcina.

Pe baza acestor date de proiect este capabil de a face puncte de vedere diferite, folosind
grupe filtre, sortarea, etc. În plus, el este capabil pentru unele algoritm
pentru a calcula datele de început și de sfârșit de sarcini, având în vedere disponibilitatea resurselor alocate
și relațiile dintre sarcini. Aici, de fapt, aproape tot ceea ce el poate.
Să vedem ce beneficiile pe care le poate obține în urma acestui

Cum să-l folosească

Notă: Pentru a face mai clar, voi clarifica unele dintre cele mai comune proprietati ale proiectelor,
Am lucrat cu. Deci, vorbim despre proiecte de dezvoltare a software-ului,
care constau din mai multe etape. La sfârșitul fiecărei etape, avem nevoie pentru a obține unele
rezultate concrete, care vor fi prezentate clientului, de aceea este important pentru noi pentru a evalua
viața nu numai a proiectului în ansamblul său, dar, de asemenea, fiecare etapă. Repet, singurul tip de resurse
vrei - este de oameni, iar noi nu angajează profesioniști din exterior și utilizarea
capacitățile personalului existent.

pregătirea planului

Deci, înainte de a ne afla termenii de referință, și este necesar să se răspundă la trei întrebări:

1. Cât timp va acest proiect?
2. Cât de mulți (și care) specialiști va dura?
3. Care sunt costurile forței de muncă sunt de așteptat pentru acest proiect?

În acest scop, ne pregătim planul prikidochny al proiectului în MS Project. Ie doar scrie secvential sarcinile pe care trebuie să le efectuați. Metode de cerințele caietului de sarcini de transformare într-un set de sarcini - este o altă poveste, nu voi locui pe ea.
Pregătirea planului se desfășoară în mai multe etape:

1. Se prepară o listă de sarcini
2. Noi expune dependențe între sarcini
   (Rezultatul unei sarcini trebuie să meargă la următorul?).
3. Interpreții atribuie sarcini
4. Alinierea de încărcare a resurselor
5. Echilibrarea ce sa întâmplat

recomandări generale

În pregătirea planului, urmați aceste linii directoare:

1. Noi nu folosim sarcinile rezumative pentru descompunere.
   Toate sarcinile sunt puse într-o listă liniară. La început, acest lucru poate părea incomod,
   dar elimină multe probleme în viitor. Pentru a controla problemele structurii
   Noi folosim câmpuri personalizate (vezi mai jos).
2. Foarte des, pentru sarcinile de management de dependență folosind DragDrop. Atunci când sarcina este o mulțime devine rapid inconfortabil. Vă recomandăm, în acest caz, nu folosiți drag and drop, și numere clare indică sarcina predecesor. Acest lucru poate fi adăugat la coloană de tabel „predecesorii“ și introduceți numărul de sarcini manuale.
3. Termenul limită pentru fiecare sarcină nu trebuie să depășească două săptămâni.
   Dacă perioada depășește sarcina de o săptămână - aceasta este o ocazie de a reflecta asupra descompunerii acesteia. Am ramas la o metodologie de evaluare foarte simplu: o sarcină primitivă - 2 zile, media
   Dificultate - 1 săptămâni, o sarcină dificilă - 2 săptămâni. La aceleași provocări nu ar trebui să fie mult. Această abordare face posibilă pregătirea unui plan de evaluare destul de repede.
   Pe de o parte, estimarea obținută, desigur, nu va fi exact, dar, pe de altă parte - și care unul este corectă? Încercările prin aplicarea practică, pot spune că
   proiecte mari estimări de eroare ale sarcinilor individuale, de obicei, nivelat și piese mici pot (și ar trebui!) utilizează și estimări mai exacte.
4. Prin toate mijloacele să evite problemele care au mai mulți interpreți. Pentru fiecare sarcină trebuie să fie atribuită numai un singur interpret. Doi jucători are sens pentru a atribui
   Numai în cazul în care lucrează într-adevăr împreună (de exemplu, practicați pereche de programare). În alte cazuri, este mai bine să se descompună problema.
5. La numirea executorilor sunt ghidate de profesie și calificările lor, în timp ce nu fi nevoie să vă faceți griji cu privire la uniformitatea de descărcare.
6. Noi folosim sarcini sumar pentru a separa sarcinile în etape. Am pus relația dintre etapele, pe care le-ar putea merge în ordine. Împărțirea în etape încă destul de dur.

proiect de echilibrare

Cel mai important în procedura este exact echilibrată. Scopul acestui proces - pentru a pregăti un plan care funcționează împărțite în mod echitabil în mod egal între interpreți peste tot.

Notă. Teoretic, pentru a evalua sarcina se presupune a folosi elemente grafice
utilizatorii descarcă. Aceste grafice sunt bune (probabil) autorităților atunci când acestea
evaluează proiectul finit. Dar ele nu sunt adecvate pe scena planului, așa cum arată
că totul este rău, dar nu a dat nici o informație de ce este așa și ce se poate face.

Apoi magia începe de echilibrare. Vrei să reducă la minimum, pentru fiecare etapă, oferind o sarcină mai mult sau mai puțin uniform pe toți participanții la proiect. Pentru a face acest lucru, efectuați următorii pași:

1. Înapoi la interpret de sarcini.

Face toate acestea, din păcate, trebuie să realizeze manual de nivelare a resurselor după fiecare modificare. În ciuda complexității aparente, procesul durează de obicei un timp finit. Proiectul pentru anul de 8 participanți, împărțiți în 4 etape, am pus în ordine în mai puțin de o oră.

Acum, din nou, uita-te cu atenție la proiect, asigurați-vă că legătura dintre plasat corect, că nimic nu este uitat, iar artiștii destinație se potrivesc specialitățile și calificările acestora.

risc de contabilitate

Acum - aspectul final: luând în considerare riscurile. Sincer, nu am fost implicat într-un management serios de risc, dar permite posibilitatea de apariție a anumitor forță majoră (cum ar fi bolile de muncă sau executanți neglijate, etc.). La aceasta am adăuga în fiecare etapă a unei sarcini fictive cu prioritatea minimă, numită „alte activități“ pentru fiecare resursă. După alinierea resurselor acestor sarcini sunt în fazele tardive. Durata acestor sarcini depinde de probabilitatea de apariție și amploarea riscurilor vlyaniya, aceasta depinde de metoda de determinare a duratei estimărilor de activitate, membrii echipei de sanatate si gradul de manager de proiect paranoia. Am expus, de obicei, durata de „altă muncă“ aproximativ o treime la un sfert din lungimea scenei.

Ca rezultat al tuturor acestor manipulări obținem un plan pentru punerea în aplicare a proiectului cu care se poate lucra.

Cu acest plan, putem:

1. Numit calendarul proiectului și fazele sale. Argumente și extrem
   fiabilitate.
2. Rata de efort exemplar al proiectului

Notă. Se întâmplă adesea că termenul limită pentru punerea în aplicare devine destul de mare, și există o întrebare rezonabilă dacă acesta poate fi redus prin interpreți suplimentari. Pentru a răspunde la această întrebare, am echilibrat noul plan, folosind același set de probleme, dar schimbarea compoziției interpreților. Răspunsul nu se obține imediat, dar nu a durat mult.

planul de lucru

În cazul în care proiectul a început în locuri de muncă, planul original, care a fost utilizat pentru evaluarea poate fi utilizată pentru a urmări performanța proiectului. Din managerul de proiect este necesar pentru a efectua următoarele acțiuni în mod regulat:

1. Pentru a elibera sarcinile de punere în aplicare
2. Marca de referință formulată în termeni
3. Ajustați planul în cazul unor abateri semnificative

Emiterea sarcinilor de punere în aplicare pot fi efectuate în diferite moduri. Puteți rupe de execuție pe iterații scurte, pentru a forma un bazin de sarcini pentru fiecare repetare și la sfârșitul iterare pentru a sărbători rezultatele. Putem suna imediat set lnitelyam de sarcini pe o scenă, da fiecare o copie a diagramei Gantt și sondaj periodic progresul. Puteți utiliza integrarea MS Project și TFS și încărca proiectul direct la TFS. Nu e în mass-media. Principalul lucru - este o actualizare regulată a planului. Eu fac acest lucru cu privire la o dată sau de două ori pe săptămână. Acest lucru oferă posibilitatea de a vedea zonele cu probleme de repede.
Pentru a determina zona de problemă este convenabil de a utiliza diferitele facțiuni -. Prin implementarea componentelor, etc pot fi de multe ori că proiectul în ansamblu este chiar înaintea, dar într-o anumită secțiune sunt rămase în urmă, cum ar fi unul dintre dezvoltatorii brusc îngropat într-o problemă sistemică gravă, care a condus la abateri. Folosind doar metrica medie nu arată această problemă - aceasta va apărea doar în stadiile avansate, când să facă orice va fi prea târziu.

Notă. De obicei nu mute sarcinile în calendar, dar numai pentru a nota modul în care acestea sunt făcute. Abaterea de la planul Urmez în abaterea de la obiectivele generale ale proiectului de moment.

Există o altă strategie - schimbări în ceea ce privește obiectivele, „împinge“ în sarcina neîmplinită înainte. Cu această abordare pentru a monitoriza abaterile de la planul, puteți utiliza altă funcție utilă MS Project - planul de bază. Planul de bază - este pur și simplu un instantaneu sarcinile salvate. Se poate face la începutul proiectului. Pentru comparație, planul actual cu baza, deschideți „diagrama Gantt de urmărire“. Pentru un plan dinamic, în cazul în care ordinea sarcinilor se schimbă frecvent, poate fi incomod, asa ca am pus în punctele de control de proiect, reflectând unele dintre cele mai importante rezultate ale proiectului și monitorizarea abaterilor de la linia de bază numai pentru ei.

Managementul cadrului cu ajutorul câmpurilor definite de utilizator

După aceea, suntem capabili de a specifica pentru fiecare componentă a problemei la care se referă, și folosirea sarcinilor de grup pe componente, monitor cum merg lucrurile.

Folosind câmpuri personalizate, precum și built-in de filtrare MS Project, sortarea și gruparea de sarcini permite pentru a obține o varietate de opinii care oferă răspunsuri la multe întrebări care apar din proiect.

Finalizarea proiectului

La finalul proiectului, avem un plan în care sunt îndeplinite toate obiectivele. De obicei încerc să salvați ca planul inițial, cel puțin ca o bază. Sincer, în acest stadiu al MS Project de puțin folos, deoarece interesul nu este planificat valori și actuale. Unele soluții la această problemă oferă MS Project Server, este posibil să se ia în considerare efectiv de lucru, dar acest lucru este dincolo de acest articol.

concluzie

Am încercat să rezume experiența mea de a folosi MS Project pentru soluția practică a problemelor care au apărut în fața mea, atunci când am condus proiectul de dezvoltare. Metoda descrisă nu pretinde că nu universală, dar mi se pare, este destul de simplu și logic, vă permite să rezolve sarcinile practice ale managerului de proiect.
Această abordare a permis să-mi cu succes și în timp util complet mai mult de un proiect.
Cu toate acestea, au existat, de asemenea, eșecuri. Sa întâmplat, de regulă, atunci când partea pregătitoare a proiectului a fost realizat prost - și anume declarația problemă. Ie ca rezultat al proiectului sa dovedit a nu destul de ceea ce era necesar, iar această înțelegere a venit prea târziu.

Cu siguranță am pierdut ceva, nu ezitați să pună întrebări.

articole similare

• 5 trucuri pentru proiect Microsoft, care s-ar putea să nu știți, management de proiect

• Proiectul APS SOUE - elaborarea documentației pentru sisteme de instalare automată a incendiilor

• Introducerea ce metodă este metoda de proiecte de proiecte și utilizarea sa la școală