Organizacinis Lankstūs projektai
Greitai judantys žibintai
Judrus projektų valdymas yra apie kuriant sėkmingas sprendimus greitai besikeičiančioje aplinkoje .
© iStockphoto / aluxum
Paveikslėlis paleidimo technologijų verslu , kuriame steigėjai bando išskirti tvaraus verslo nišą.
Sektorius sparčiai keičiasi , ir jie turi greitai plėtoti paslaugas , kad vartotojai yra pasirengę mokėti.
Tai sudėtinga!
Jie gali tik sužinoti tiek daug per rinkos tyrimus , todėl jiems reikia eksperimentuoti . Tai reiškia, bando įvairių aukos įvairovė. Žingsnis po žingsnio , jie turi išmokti iš jų ir pabandyti geresnius pasiūlymus , kol jie sukurti sprendimą, kuris tikrai veikia.
Galite tikriausiai rasite , kad daug darbu susijusius projektus - ypač tie, kurie paremti sudėtingais , greitai judančius situacijas - panašūs šis scenarijus . Galite dirbti į vieną rezultatą ar sprendžiant vieną problemą , bet tada reikia keisti kursą ir pakeisti savo planus .
Jei naudojate tradicinį projektų valdymo metodą , šie pakeitimai bus praleistus terminus, išpūstų kainų , padidėjo darbo krūvis . Ir, blogiausiu atveju , galite rasti, kadsituacija pasikeitė tiek daug per projekto metu , kad jūsų galutinis produktas, kai jis galiausiai pristatyti, nebėra aktualus.
Judrus projektų valdymas yrametodas, kuris padeda jums susidoroti su šiais iššūkiais . Šiame straipsnyje mes aprašysime , kas yra Agile , ir mes paaiškinti, kodėl tai naudinga .
Kas yra Judrus projektų valdymas?
Judrus projektų valdymas yra pastatytas aplink lankstesnio požiūrio . Komandos nariai dirba trumpais blyksniais ant mažo masto , bet veikiantis spaudai produkto . Tada jie tikrina kiekvieną nuo klientų poreikius spaudai , o ne siekti vieno galutinio rezultato , kad tik išleistas į projekto pabaigos .
Galutinis produktas judrus projekto gali būti labai skiriasi nuo to , kuris buvo numatyta iš pat pradžių. Tačiau dėl tikrinimo procesą, komandos nariai gali būti tikri, kadproduktas yra vienas, kad klientai nori .
Tai daro Agile Project Management ypač tinka naujiems arba greitai judančius įmonių , tiems, greitai kintančioje aplinkoje , ar labai sudėtingose situacijose , kai vadovai yra " jausmas savo kelią į priekį" rasti optimalų verslo modelį. Taip pat naudinga skubius projektus, kurie negali laukti visą , tradicinio projekto, kurį ketinama įsteigti.
Iš Agile Ištakos
Iš Agile projektų valdymo elementai buvo maždaug dešimtmečius. Tačiau šie du įvykiai padėjo pamatus požiūrio .
Pirma, 1986 metais, Hirotaka Takeuchi ir Ikujiro Nonaka išspausdino straipsnį, pavadintą "Naujiena Produktų plėtros Žaidimas" į "Harvard Business Review . Be to, autoriai pristatė naują būdą kurti produktus, kurie priminė regbio rungtynes .
Jie įsivaizdavo projektų valdymo metodą, kuris , kaip aikštelėje , komandos nariai būtų pasiekti savo tikslą , nuolat iš naujo įvertinti situaciją ir reaguoti atitinkamai . Projektai todėl vystytis, bet leistų produktus , atitinkančius klientų poreikius labiau kaip rezultatas.
Antrasis įvykis įvyko 2001 metais, kaiprograminės įrangos ir projektų ekspertų grupė susirinko aptarti, ką jų sėkmingiausi projektai turėjo bendro . Jie sukūrė Agile Project manifestą , kuriame išdėstė vertybes ir principus, pagrįstus Agile Project Management.
Judrus projektų valdymas remiasi produkto kūrimo metodą Takeuchi ir Nonaka , ir apima vertybes ir principus, išdėstytus Agile Project manifeste .
Judrus versus tradicinė Projektų valdymas
Leiskite palyginti Agile Project Management su tradicinių projektų valdymo parodyti, kaip požiūriai skiriasi .
Agile projektų valdymo Tradicinė Projektų valdymas
Komandos savinukreipia ir gali laisvai atlikti siektinus rezultatus , nes jie pasirinkti , kiek jie laikosi sutartų taisyklių. Komandos paprastai griežtai kontroliuojama projektų vadovu . Jie dirba išsamius grafikus susitarta nuo pat pradžių .
Projekto reikalavimai yra sukurtas pagal proceso poreikius ir panaudojimas atsirasti. Tai galėtų reikšti , kadgalutinis rezultatas skiriasi nuo tos, kuri numatyta iš pat pradžių. Projekto reikalavimai nustatyti prieš prasidedant projektui . Kartais tai gali sukelti "Taikymo sritis slinkti ", nes suinteresuotosios šalys dažnai prašo daugiau nei jiems reikia, " tik tuo atveju ".
Vartotojas bandymai ir klientų atsiliepimus atsitikti nuolat. Tai lengva mokytis iš klaidų , įgyvendinti atsiliepimus ir vystytis rezultatus. Tačiau nuolatinis bandymas būtinas , nes tai yra darbo jėgos, ir ji gali būti sunku valdyti , jei vartotojai neužsiima . Vartotojas bandymai ir klientų atsiliepimus vyksiantį projekto pabaigoje , kai viskas buvo sukurta ir įgyvendinta. Tai gali reikšti , kad problemų gali kilti po išleidimo : kartais brangiai pataisymai ir net viešosios primena .
Komandos nuolat vertinti mastą ir kryptį savo produkto ar projekto . Tai reiškia, kad jie gali pakeisti kryptį bet kuriuo proceso metu , įsitikinkite, kad jų produktas bus patenkinti kintančius poreikius . Dėl šios priežasties , tačiau gali būti sunku parašyti verslo atvejį iš karto , nesgalutinis rezultatas nėra visiškai žinomas .
Komandos dirbti galutinio produkto , kuris gali būti pristatyta šiek tiek laiko - dažnai kelis mėnesius ar metus - nuo projekto pradžios. Kartaisgalutinis produktas ar projektas nebėra svarbus, nes verslo ar klientų poreikiai pasikeitė.
Galų gale, tradicinis projektų valdymas dažnai yra geriausias stabilioje aplinkoje , kurapibrėžta siekinys reikia už fiksuotą biudžetą. Agile yra dažnai geriausia , jeigalutinis produktas yra neaiški arba jeiaplinka sparčiai keičiasi.
Apie procesą
Judrus projektų valdymas taip pat skiriasi nuo kitų projektų valdymo metodų vaidmuo ir renginius , kuriuos ji naudoja . Mes sukūrėme tai žemiau.
" Scrums " ir " Sprintas "
Agile Project Management širdis" Scrum " sistema . Tai naudoja specialias funkcijas , renginius , susitikimus ir padidinimas pristatyti naudojamą produktą tam tikrą laikotarpį - pavyzdžiui, per 30 dienų.
Sistema apima tris pagrindines funkcijas:
1 . Produkto savininkas yraant gaminio kuriamas ekspertas. Jis arba ji atstovauja pagrindines suinteresuotąsias šalis , vartotojus ir galutinius vartotojus , ir yra atsakingas už prioritetų projektą ir gauti finansavimą.
Produkto savininkas apibūdina tai, kaip žmonės naudoja galutinį produktą , bendrauja klientų poreikius ir padedakomanda plėtoti tinkamą produktą. Jo arba jos kompetencija taip pat padeda kovoti apimtis slinkti .
2 . Scrum meistras yra atsakingas už procesą. Šis asmuo sprendžia problemas , kadprodukto savininkas gali vairuoti plėtrą ir padidinti investicijų grąžą. Scrum meistras užtikrina, kad kiekvienas sprinto yra savarankiški, ir kad ji neturi imtis papildomų tikslų .
Scrum meistras prižiūri bendravimą , kad suinteresuotosios šalys ir komandos nariai galėtų lengvai suprasti , kokia pažanga buvo padaryta .
3 . Komandaspecialistų , atsakingų už posūkio reikalavimus į funkcionalumą grupė .
Komanda dirbs apie kiekvieną projektą per " įsibėgėja ", - trumpas etapus darbo , kuri užtikrina baigtas, išbandyta , įforminti dokumentais ir veikia produktus jų sudarymo .
Kiekvienas sprintas prasideda sprinto planavimo posėdyje. Čia komandos nariai nuspręsti, ką jie gali pateikti per sutartą laikotarpį . Jos apibrėžia tikslą ir priskirti užduotis pareigas.
Per sprinto , komandos nariai sutelkti dėmesį tik pasiekti savo apibrėžtą tikslą . Jie bus patenkinti kasdien 15 minučių susitikimo pranešti apie pažangą , aptarti, ką jie dirbs tą dieną , ir kalbėti per visas problemas , kad jie susiduria. ( Pasitarimų dalyviai skatinami atsistoti taip, kad posėdžiai yra greitas ir efektyvus . ) Šie susitikimai yraesminė kasdienio tikrinimo procese.
Komandos gali keisti savo požiūrį, remiantis tuo, kas tinka konkrečiam projektui .
Ataskaitiniai
Agile projektų valdymo , yra reguliariai galimybės pranešti apie pažangą.
Taip pat kasdieniniai Scrum susirinkimai , komandos nariai susitinka produkto savininkas ir pagrindinių suinteresuotųjų šalių po kiekvieno sprinto pateiktisprinto siekinys . Šiame susitikime grupė nusprendžia kartu , ką jie turėtų pakeisti į kitą sprinto .
Po to,Scrum meistras (o kartais irprodukto savininkas ) turi retrospektyviai susitikimą , kuriame jie žiūri į šį procesą , kad jie naudojami per paskutinį sprinto ir nuspręsti, ką jie gali pagerinti už kitą.
Patarimas:
Jei dirbate su virtualios komandos, įsitikinkite, kad visi naudoja tą patį momentinių pranešimų (MP ) programinę įrangą, siekiant paspartinti komunikacijos. Virtualus susitikimas programinė įranga yra būtina kasdien Scrum susirinkimuose.
Socialinė žiniasklaida taip pat gali būti naudinga padėti komandos nariai bendradarbiauti tarp susitikimų .
svarbiausi dalykai
Judrus projektų valdymas siekiama pristatyti pilnai darbo atnaujinimus gaminio ar proceso reguliariai - paprastai , kas 30 dienų.
Jis idealiai tinka programinės įrangos kūrimo ir kitiems projektams , kai reikalavimai yra linkę keisti projekto metu - pavyzdžiui, naujų ar sparčiai auganti įmonių arba Sparčiai kintančioje verslo aplinkoje .
Komandos yra visiškai savarankiškai tvarko ir turi laisvę keisti savo požiūrį , kai reikia. Šis lankstumas gali sutaupyti lėšų ir užtikrinti, kadgalutinis produktas atitinka klientų poreikius.
Ar radote šiame straipsnyje buvo naudingi? Spauskite balsuoti noNoClick balsuoti YesYes
Kur eiti nuo čia: Kitas straipsnis
Peržiūrėti Tinka spausdinti
Užduoti klausimus , arba pasidalinti savo patirtimi
Kokias prisijungę pasakyti ...
SimonICT rašė
Tiesiog maniau aš pasidalinti savo patirtimi po mano departamentų 1 -osios judrus peržiūros sesijos.
Pirma , taigeriausia priemonė Aš naudojamas greito tempo projektus. Tačiau plotas keletą sričių , mes koreguoti ar jau išmoko. Mūsų aplinkoje jų yra 9 darbuotojai dirba įvairiais projektais ar veikla vienu metu daug.
1)stiprus Scrum meistras / projekto vadovas yra raktas. Mes praleido projekto terminų , kaikomandos narys nepretenduoja būti blokuojami jų pažangą, bet nėra baigti savo veiklą laiko. Scrum meistras turi pasirinkti tai padaryti.
2 ) Pasiteiraukite yraklausimas , jauna nepatyrusi rinktinės kova su bet kokia abstrakti sąvoka , todėl jums reikia naudoti žmogaus darbo valandų kaip paprastas vadovas.
3 ) stebėti laikas, praleistas vs sąmatą. Mes niekada tai padarė , bet pradės . Iš esmės, kailabai techninis darbas yra maždaug 20 valandų, tačiau trunka 4 savaites , jums reikia apmąstyti , kodėl taip yra ir turi įrodymų .
4)komanda turi būti įsipareigojusi padaryti jį dirbti. Kai jūs gaunate požiūris ar prastų rezultatų įsibėgėja žlugti ir Scrum meistras yralabai įtemptas darbas.
5) metrikos . Negaliu pasakyti, tai apšviesti , kad mūsų didžiausia klaida buvo mūsų nesugebėjimas surinkti pakankamai metrikas arba gaminti burndown diagramas . Kuo daugiau metrikos turigeriau galite planuoti . Be to, Multi- projekto aplinkos jums reikia pamatyti blokų ir nustatinėjama poveikį užbaigimo datas.
6) naudoti tinkamus įrankius , yra daug gerų programinės įrangos įrankius valdyti judrus projektų ir jums reikia įsitikinti, kad jūs naudojate vieną, kuris tinka jūsų poreikius.
Tikiuosi, kad yra naudinga žmonėms
Simonas
, 2013 birželis 2
Agile Project Management
Organizing Flexible Projects
Agile Project Management is about developing successful solutions in a fast-moving environment.
© iStockphoto/aluxum
Picture a start-up technology business, where the founders are trying to carve out a sustainable business niche.
The sector is changing fast, and they must quickly develop a service that users are prepared to pay for.
This is tricky!
They can only find out so much through market research, so they need to experiment. This means trying a variety of different offerings. Step-by-step, they need to learn from these and try improved offerings until they develop a solution that really works.
You can probably see that many work-related projects – particularly those involving complex, fast-moving situations – resemble this scenario. You can be working towards one deliverable or solving one problem, but then need to change course and revise your plans.
If you're using a traditional project management approach, these revisions will lead to missed deadlines, inflated costs, and increased workloads. And, in a worst-case scenario, you can find that the situation has changed so much during the course of the project that your final product, when it is eventually delivered, is no longer relevant.
Agile Project Management is an approach that helps you deal with these challenges. In this article, we'll describe what Agile is, and we'll explain why it's beneficial.
What is Agile Project Management?
Agile Project Management is built around a flexible approach. Team members work in short bursts on small-scale but functioning releases of a product. They then test each release against customers' needs, instead of aiming for a single final result that is only released at the end of the project.
The end product of an agile project may be very different from the one that was envisaged at the outset. However, because of the checking process, team members can be sure that the product is one that customers want.
This makes Agile Project Management particularly appropriate for new or fast-moving businesses, for those in a fast-changing environment, or for highly complex situations, where managers are "feeling their way forward" to find the optimum business model. It's also helpful with urgent projects that can't wait for a full, traditional project to be set up.
The Origins of Agile
The elements of Agile Project Management have been around for decades. However, two events helped to lay the foundations for the approach.
First, in 1986, Hirotaka Takeuchi and Ikujiro Nonaka published an article called "The New New Product Development Game" in the Harvard Business Review. In it, the authors outlined a new way of developing products that resembled a rugby match.
They imagined a project management approach in which, just as on the pitch, team members would achieve their goal by constantly re-evaluating the situation and responding accordingly. Projects would therefore evolve, but would lead to products that met customers' needs more fully as a result.
The second event occurred in 2001, when a group of software and project experts met to discuss what their most successful projects had in common. They created the Agile Project Manifesto, which outlined the values and principles that underpinned Agile Project Management.
Agile Project Management is built on the product development approach of Takeuchi and Nonaka, and incorporates the values and principles outlined in the Agile Project Manifesto.
Agile Versus Traditional Project Management
Let's compare Agile Project Management with traditional project management to show how the approaches differ.
| Agile Project Management | Traditional Project Management |
|---|---|
| Teams are self-directed and are free to accomplish deliverables as they choose, as long as they follow agreed rules. | Teams are typically tightly controlled by a project manager. They work to detailed schedules agreed at the outset. |
| Project requirements are developed within the process as needs and uses emerge. This could mean that the final outcome is different from the one envisaged at the outset. | Project requirements are identified before the project begins. This can sometimes lead to "scope creep," because stakeholders often ask for more than they need, "just in case." |
| User testing and customer feedback happen constantly. It's easy to learn from mistakes, implement feedback, and evolve deliverables. However, the constant testing needed for this is labor-intensive, and it can be difficult to manage if users are not engaged. | User testing and customer feedback take place towards the end of the project, when everything has been designed and implemented. This can mean that problems can emerge after the release, sometimes leading to expensive fixes and even public recalls. |
| Teams constantly assess the scope and direction of their product or project. This means that they can change direction at any time in the process to make sure that their product will meet changing needs. Because of this, however, it can be difficult to write a business case at the outset, because the final outcome is not fully known. | Teams work on a final product that can be delivered some time – often months or years – after the project begins. Sometimes, the end product or project is no longer relevant, because business or customer needs have changed. |
Ultimately, traditional project management is often best in a stable environment, where a defined deliverable is needed for a fixed budget. Agile is often best where the end-product is uncertain, or where the environment is changing fast.
About the Process
Agile Project Management is also different from other project management techniques in the roles and events it uses. We've outlined these below.
"Scrums" and "Sprints"
The heart of Agile Project Management is the "scrum" framework. This uses specific roles, events, meetings, and increments to deliver a usable product in a specific time frame – for example, within 30 days.
The framework involves three key roles:
1. The product owner is an expert on the product being developed. He or she represents key stakeholders, customers, and end users, and is responsible for prioritizing the project and getting funding.
The product owner describes how people will use the final product, communicates customer needs, and helps the team develop the right product. His or her expertise also helps combat scope creep.
2. The scrum master is responsible for managing the process. This person solves problems, so that the product owner can drive development, and maximize return on investment. The scrum master ensures that each sprint is self-contained, and that it doesn't take on additional objectives.
The scrum master oversees communication, so that stakeholders and team members can easily understand what progress has been made.
3. The team is the group of professionals responsible for turning requirements into functionality.
The team will work on each project via "sprints" – short phases of work which deliver completed, tested, documented, and functioning products at their conclusion.
Each sprint begins with a sprint planning meeting. Here, team members decide what they can deliver within the agreed timeframe. They define the goal and assign task responsibilities.
During the sprint, team members focus solely on achieving their defined goal. They will meet every day for a 15-minute meeting to report on progress, to discuss what they will work on that day, and to talk through any challenges that they're facing. (Meeting participants are encouraged to stand up so that meetings are quick and efficient.) These meetings are an essential part of the daily inspection process.
Teams are free to change their approach, based on what works for the specific project.
Reporting
In Agile Project Management, there are regular opportunities for reporting on progress.
As well as daily scrum meetings, team members meet the product owner and key stakeholders after each sprint to present the sprint deliverable. In this meeting, the group decides together what they should change for the next sprint.
After this, the scrum master (and sometimes the product owner) holds a retrospective meeting, in which they look at the process that they used in the last sprint and decide what they can improve for the next one.
Tip:
If you're working with a virtual team, make sure that everyone is using the same instant messaging (IM) software to speed communication. Virtual meeting software is essential for daily scrum meetings.
Social media can also be useful for helping team members collaborate between meetings.
Key Points
Agile Project Management aims to deliver fully working upgrades of a product or process on a regular basis – typically, every 30 days.
It's ideal for software development and other projects where requirements are likely to change during the project – for example, in new or fast-growing businesses or in fast-changing business environments.
Teams are entirely self-managed and have the freedom to change their approach when needed. This flexibility can save costs and ensure that the final product meets customers' needs.
Did you find this article helpful?
No
Yes
 |
Where to go from here:
What members say...
SimonICT wrote Just thought I'd share my experiences after my departments 1st anniversary of agile review session. Firstly, it's the best tool I've used for fast paced projects. However, there area a few areas we are adjusting or have learnt. In our environment their are 9 staff working on a multitude of different projects or activities simultaneously. 1) a strong scrum master / project manager is key. We have missed project deadlines when a team member doesn't claim to be blocked on their progress but doesn't complete their activities in time. Scrum master needs to pick this up. 2) Estimating is an issue, young inexperienced teams struggle with any abstract concept, so you need to use man hours as a simple guide. 3) track time spent vs. the estimate. We have never done this but will start to. Basically when a very technical piece of work is estimated at 20 hours but takes 4 weeks, you need to reflect on why that is and have evidence. 4) The team must be committed to make it work. When you get attitude or poor performance sprints fail and scrum master is a very stressful job. 5) metrics. Can't say this enlighten that our biggest mistake was our failure to capture enough metrics or produce burndown charts. The more metrics you have the better you can plan. Also, in a multi-project environment you need to see the impact of blocks and under estimation on completion dates. 6) use the right tools, there are lots of good software tools to manage agile projects and you need to make sure you use one that fits your purpose. Hope that's of use to people Simon June 2, 2013 |
No comments:
Post a Comment