Jak se udržet naživu při řízení projektů

...kdo myslíte ze je "JS"? ...jeho názory mi už začínají připadat tak absurdní, že se vůbec odmítám obracet přímo na něho …“člověk“, který přirovnává programátory k metařům (p.s. pokud vím, metaře může dělat každý, programátora určitě ne) …“člověk“ který mluví o MFC …já si tipuji na 50 letého předrevolučního bývalého zaměstnance kancelářských strojů který dnes kvůli tomu že prostě již nestihá má nastudováno mnoho teorie(neb se odvažuje tvrdit že žádný projekt na světě u firem na levelu 4 a 5 …blablabla – musí být hodně sečtělý když ví o každém projektu těchto firem) a denně udělá alespoň 3 výkazy o své denní činnosti – pravděpodobně má na navštívence SW analytik …varianta dvě …je to metař ..tipuji na 50 letého metaře, co vy?
 
JS nesnaž se odpovídatJ …opravdu si směšný již dostatečně …debata je zajímavá i bez tvých naprosto mimo připomínek

Dobrý den.

Myslím, že je třeba všechny metodiky číst především jako koncentrát zkušeností jejich autorů, nikoliv jako návod "takto to musí být". Každá z výše diskutovaných metodik má svoje zaměření - uspokojení potřeb zákazníka, kvalita výsledného projektu, hladký průběh projektu - a je třeba si z toho vzít co potřebuji. To co si z toho vezmu si pak nechám certifikovat podle jedné z těchto norem .
A co se týče projektů. Je podle mě opravdu velice důležité zajistit hlavně opakovatelnost projektů. A jsem vděčný lidem, kteří své znelosti sepíší a notabene zdarma je zveřejní.

Aleš

Dobrý den,

Váš názor se mi líbí a je velmi blízko mému. Metodologie samozřejmně není samospasitelná, ale to není žádný nástroj. Metodologie je "pouze" nástrojem. To že si koupíte kartáček na zuby a naučíte se s ním pracovat automaticky neznamená, že se Vám nebudou kazit. Obzvláště pokud ho nebudete používat .

CMM bývá velmi dobře hodnoceno právě proto, že není direktivní ve smyslu, že pokud chcete certifikaci, tak musíte toto a tamto používat, jinak certifikaci nemáte. CMM by se právě mělo implementovat tím způsobem, že si z něj vyberete to co potřebujete a případně si to i modifikujete tak, aby to splňovalo Vaše potřeby.

Pokud máte dobrého project managera, který se řídí pouze intucí a rozumem a všechno zvládá na 1*, tak máte poklad. Já osobně nikoho takového neznám, znám "pouze" velmi šikovné lidi, kteří kombinují intuici, rozum a zkušenosti. Jenže ty zkušenosti každý musel někde získat. A jak kdysi kdesi kdosi pravil: "Zkušenost je dobrá škola, jen školné je příliš vysoké". A o tom to je. Málokterá firma si může dovolit ztrácet projekty proto, že se "učí". Proč se tedy nepoučit od těch, kteří tuto zkušenost často zaplatili velmi draze (resp. jejich firmy, zakaznici, ...)?

Bylo tu zmíněno i extrémní programování. CMM a XP se v mnohém doplňují a není problém čerpat z obou. CMM certifikace sama o sobě neříká nutně, že certifikovaná firma neudělá chybu a to i když dodržuje vše co má, ale spíš říká to, že by těch chyb nemělo být moc a hlavně, že nikdy neudělá tu samo chybu 2x. BTW: ještě k tomu certifikátu - nejvíce napadány bývají certifikace L4 a L5 v Indii, protože se mluvilo o tom, že tyto certifikáty byly "zaplaceny", tj. daná firma obdržela pouze papír bez zavedení potřebných změn. O tom mluvilo nejvíc článků, které CMM kritizovaly.

Dobromil Podpěra

Metodiky se kterými jsem se setkal mi většinou připadly jako (špatný) kompromis mezi rovinou abstraktní (t.j. tím, co se zrovna autoři metodologie pokusili zobecnit, resp. věřili tomu, že by to mohli zobecnit) a konkrétní (co se autoři zobecnit nepokusili, neboť to neuměli, nebo uměli, ale kdyby to udělali, tak by svoji metodiku těžko prodali).

Pokus použít takovou metodiku v praxi pak většinou znamená, provést dodatečnou abstrakci tam, kde to neudělali autoři a naopak, promítnout výsledný abstraktní model do reálné situace. Není se tedy čemu divit, že se na tom uživí dost firem .

Znám jen jeden případ metodiky, která je v zásadě tak abstraktní, že nemá formální ani logické chyby, bohužel z tohoto důvodu není pro velkou většinu lidí použitelná.

Tohle platí pro metodiky řízení obecně. Vývoj software, pokud to autor měl hlavně na mysli, ovšem představuje, v rovině týmové, určité specifikum v tom, že se v zásadě jedná, z menší nebo větší míry (nemluvme o tvorbě webových stránek) o tvůrčí práci. Už někdo někdy publikoval metodiku na řízení týmu výtvarníků, nebo dramatiků? Základní otázky, jak dlouho to bude trvat, kolik to bude stát a kolik lidí na to bude potřeba, totiž žádná metodika nemůže v tvůrčí oblasti zajistit. Bohužel, zrovna od tohoto (resp. schopnosti tyto věci určit) se odvíjí úspěch softwarových projektů.

Pro zájemce bych uvedl, že zajímavé pojetí např. představuje Jim McCarthy ve svých knihách "Dynamics of Software Development" (česky Softwarové projekty), a "Software for Your Head", který nebere řízení jako pojem, který lze měřit, ale jako rozvoj odborných ale hlavně mezilidských vztahů všech zúčastněných.

Pro špatného vedoucího je jakákoliv metodika zbytečná, pro dobrého je těžké najít vhodnou tak, aby ho místo rozvoje spíš neomezovala, případně nenutila k něčemu, co je proti jeho přesvědčení.

Ach jo....lidi lidi, copak tu neni nekdo aspon trochu vzdelany a s par lety praxe v IT? Jak tohle muze nekdo napsat?

Rizeni projektu ma jasne vysledky, po jejich aplikaci jsou meritelne vysledky a to PRIMARNE financni. Sice jsou ruzne casove horizonty (cim vetsi uspora radove v miliardach), tim delsi je nutny casovy interval a to kvuli zabehnuti one metodiky. Ale cisla jsou jasna.

A srovnavat umelce s programatory :o)) Prosim vas programoval jste nekdy? Zkuste mi tedy rici, proc jsou ruzne frameworky jako MFC, OWL, SAP kit atd., ktere v postate resi procesy, co se opakuji. A co de programator? Stale opakuje jeden a tentyz proces. A pokud mi reknete, ze ne, pak musite souhlasit s tim, ze i treba metar na ulici je super tvurci prace, ptz kazdy den zameta jine vajgly a jinak mrska tim kostetem ;o)

Prectete si nejdrive neco o projektovem rizeni, metodologiich, zkuste projekt chvilku ridit (aspon tak 5 let) a pak sem neco piste ;o)

Ach, tak na tento názor jsem již narazil. "Programování není kvalifikovaná práce", to jsem už slyšel od mnoha manageru, kteří si programování či analýzu nikdy ani nezkusili (jednomu bylo 27 a měl celé 2 roky praxe v IT). Ideální programátor je pak cyklicky najímaná/propouštěná námezdná síla, nejlépe levný student. Všechnu kvalitu zajišťuje management a geniální metodiky.
Bohužel viděl jsem už několikrát,  jak realizace této managerské "ideologie" dopadá. Řídím už pěkných pár let menší analyticko/programátorské týmy a několikrát jsem marně managementu vysvětloval, že se nedá postavit programátorsko/analytický tým tak, že se 3 dny před začátkem projektu začnou hledat lidé (metaři ?) na ulici.
Co se týče různých metodik používal jsem jich během minulosti X, sám jsem několik pracoval na konkretizaci různých metodik. Obecná metodika je obvykle totiž asi tak stejně platná jako globus pro orientaci v Krkonoších.
Pracoval jsem také ve firmě (sídlo v USA), kde metodika sestávala z 53 knih, které měli v průměru 200 stran, tato metodika byla kouzelná i tím, že neměla určený žádný začátek ani konec. Takže v metodikách jsem honěný dost.
Přínos většiny obecných metodik, které jsem viděl aplikovat byl ale viditelně sporný ! Píšu je ovšem rád. Odpočívám si při tom od nekvalifikovaných prací jako je:  jednání se zákazníky, vedení týmů, analýza, programování a hlavně zodpovědnosti za vývoj skutečných aplikací.
S pozdravem Váš pobavený
F.P.
 
 

Mam znameho podnikatele, jehoz firma vyrabi elektronicke merici pristroje. Aby mohl vubec prodavat, tak musi byt certifikovan - ta firma nema CMM certifikat ale ISO9...Vypravel mi, kdyz jsem se ho ptal, zda se v jeho vlastni firme kvalita zlepsila po zavedeni metodologie rizeni kvality, ze nikoliv - a take podotkl, ze u dodovatelu , kteri take certifikat maji naridil vstupni kontrolu 2 x zprisnit. Ukazalo se totiz, ze certifikovane firmy se patrne domnivaji, ze pote co uzivaji ISO9... se kvalita produktu nastavi sama od sebe automaticky a prestaly provadet kontrolu tak jak to delaly drive.
Z toho plyne: POZOR na produkty firem, ktere maji CMM nebo ISO certifikat!!!

Jeste jedna poznamka: Jiste maji mnozi v pameti ten nedavny prusvih s Fujitsu - harddiskama. Defekt zpusobil dodavatel, ktery byl samozrejme certifikovan zrovna tak jako Fujitsu.

Rízeni projektu, certifikace ISO a vysledná jakost vyrobku - to jsou odlisne veci, prosim neslucujte.

A proc to smi slucovat autor clanku - hovori o metodologii jak trénovat hráce a o uspesich takto trenovaneho tymu jako cil.
Krome jineho si jeste presne vzpominam jak to cele zacalo. Velke koncerny se snazily snizit naklady u prejimky zbozi a par chytrejm napadlo, ze by se ty naklady daly vtipne prehodit na dodavatele. Nemajice pristup k technologiim jednotlivych dodavatelu je zapotrebi mit vseobecna kriteria, podle kterych je mozno kvalitu dodavky zajistit (bez toho ji jednotlive testovat). A vznikla nova vira, ze kvalitu dodavky automaticky zajisti auditovatelna kvalita procesu u dodavatele. Ale protoze vse na svete presto probiha podle zdraveho rozumu, nechaji se firmy certifikovat proto , aby byly vubec v sirsim vyberu dodavatelu. 

Aby bylo jasno: ja ty pojmy neslucuji, cini tak autor clanku a vsichni, kteri ve snaze zlepsit kvalitu procesu za timto zlepsenim vidi nejaky cil - ale ten by nam pak meli sdelit. To ze by toto vedlo k zlepseni kvality nemuzeme rici - ja tvrdim ze to k tomu nevede a vy pozadujete abych to neslucoval.
V kazdem pripade konstatuji: puvodni cil tech velkych koncernu se nenaplnil !!!    

Ono se těm velkým koncernům není moc co divit. Nemám přesné podklady, ale předtavte si třeba McDonald/Douglas nebo to byl možná Boeing, který vyvíjel bombardér pro US Air Force. Ten projekt byl zrušen, protože několikanásobně překročil čas a rozpočet. A pointa už asi jasně plyne: největší problém byl s "firmware". Stále se jim divíte, že se chtějí nějak předem pojistit nebo si ověřit, že mají slušnou šanci, že to tak nedopadne?

Jak píši jinde, nepolemizuji s Vámi, že samotná certifikace je zárukou kvality. Kvalita závisí na mnoha faktorech a ty se obvykle nedají úplně snadno popsat ani pro jednu firmu, natož aby se daly generalizovat. Jenže metodologie pomáhá (je-li vybrána a aplikována správně), aby se celý vyrobní/vývojový proces monitoroval a každá chyba či zdržení se odhalilo co nejdříve (ne až když nastane termín předání) a mohly se včas zařídit potřebné korekční kroky. Také by měla podporovat schopnost se poučit z (nejen) vlastních chyb a neopakovat je.

Důležitá věc je, že metodologie pomáhá a ne že řeší sama o sobě.

A ještě k těm velkým koncernům: oni to dobře vědí (aspoň většinou), a přestože máte jakýkoliv certifikát, tak si vás nejdříve vyzkouší. Některé certifikáty se dají získat pouze za to, že si vyškolíte lidi, jiné se dají přímo koupit. Nemyslím si, že kdy může existovat certifikát, který Vám na 100 % zaručí, že daná firma/člověk dělá vše správně a nedopustí se chyby. Ale jako vodítko to zřejmě použitelné je, protože jinak by už to dávno zmizelo v historii.

DP

Zase nekdo, kdo vubec nema ani tuchu, o cem je rec....

Takze opravdu, dejte v pripade SW na SEI-CMM, zadny problem s dodavkou projektu doposud nebyl nikdy zaznamenan (tedy u firem s urovni 4 a 5). ISO9000 a ISO9001 jsou dost rozdilne veci...soustredi se hlavne na komunikaci s klientem a zadavatelem, definovani a rizeni projektu. Prectete si neco o tom a nepiste sem tyhle nesmysly. Jen se ztrapnujete, i kdyz jako anonym asi jen sam pred sebou ;o)

nejdrive jsem si myslel, ze ses od zivy placenej troll, ale pak jsem si vsiml trochu nize, ze hovoris o MFC, tak pak je to jasne - ty nemas o software-engineeringu nejmensi paru.

Problem je v tom, ze pokud chcete zavest CMM vetsi nez 3, tak se mnozstvi byrokracie zacina exponencialne zvysovat a mnozstvi "povolene" invence exponencialne snizovat. Tedy pro softwarove firmy, ktere delaji neco slozitejsiho nez webove stranky neco naprosto kontraproduktivni. No a CMM na urovni mezi 2 a 3 ma kazda firma, ktera dokazala fungovat vice nez 2 roky ...
Zaver je to pouze hodne kecu na kterech se snazi konzultantske firmy vydelat. Ale rozhodne se vyplati si to jen tak zbezne nastudovat aby ste vedeli kudy rozhodne ne. Na Inetu se da najit i dost nehypovskejch (resp. kritizujicich) clanku o CMM dokonce jiz z let kolem 1992.

Abych tady jen tak plane neplacal tak uvedu priklad, pokud chcete dosahnout CMM 4 vase procesy musi byt meritelne, ale jak chcete merit kvalitu programatora napriklad v C++. Podle poctu radku - ja mam radeji programatora co to same napise na mene radku nebo snad podle poctu function pointu - radove rozdilne podle toho, kdo to pocita. Proste neexistuje rozumne mereni procesu programovani programatora.

Je videt, ze jste nikdy neridil zadny velky projekt. ISO-CMM ma jasne opodstatneni a jeho aplikace dost zefektivni beh firmy, tim, ze se minimalizuji rizika, jasne se definuji kroky atd.

A to, ze tu nekdo pise o narustu byrokracie na level 4 a 5 je videt, ze o tom nikde zde nic nevi. Prave, ze tohle tak vubec neni a ze to nikdo zde nikdy nedelal. Naopak, prave tihle chytrolini pisi jen pitomy kod, ale neuvedomuji si, ze mohou byt projekty, kde je nutne provazanost, kde je nutna koordinace, dochazi k reseni problemu nenahraditelnosti jedincu, optimalizace lidskych zdroju atd. Prave 4. uroven se vyznacuje meritelnosti zlepseni a jednim z faktoru je efektivnost. A to znamena i cas a penize. Ale to NENI to hlavni, predevsim je to garance opakovatelnosti projektoveho procesu a TOHLE klienta zajima. NEZAJIMA ho, jestli napisete kod na 2 nebo 3 radky (to resi Software Quality Manager a Eng.), zadavatel se zajima o vystup, o cas, o kvalitu, co garantuje dodavatel a cenu (tzv. trojimperativ).

Prave kvuli lidem jako vy se musi tyto metodologie zavadet, jinak dochazi ke zmatku, nesourodosti a dezintergaci projektu. A v dusledku je to o jedinem - stoji to penize a nebo dokonce krach projektu. U spolecnosti, ktere nemaji CMM certifikaci (ani na uroven 3 - tuhle tu OPRAVDU ma maloktera firma, leda ta, co ma ISO9001) je krach projektu podle statistik na 87% (viz. zdroje na http://www.sei.cmu.edu/). Pokud mate firmu, co je na urovni 4 a nebo dokonce 5, tak doposud u zadne z nich nebyl evidovan krachly projekt. A to jiz mluvi samo za sebe. Byly evidovane pouze zastavene projekty (investor nemel dostatecne cashflow), ale ne krach zpusobeny chybami dodavatele nebo i spatnou komunikaci se zadavatelem. A tohle je DOST padny argument!

Pokud nepovazujete velky projekt 12 lidi v tymu (nepocitam testery, atd.) a 1M+ radku kodu v C++, tak prosim
Kdyz ctu tady vase dalsi prizpevky tak vas bych do tymu jako progamatora nechtel... (bez vlastni invence se proste programovat neda)
Predevsim se tu opravdu bavime o software developmentu a opravdu to je tvurci (research) prace. A ta opravdu nejde naskatulkovat.
To taky plne odpovida tomu, ze jste mi nevyvratil moji domenku o nemeritelnosti prace programatora. To znamena, ze CMM 4 a vyse nelze aplikovat na praci programatora!)
A bohuzel at si rika kdo chce co chce programatori jsou nahraditelni jen velmi obtizne a ti dobri, temer vubec (tedy no v rozumnem casovem horizontu vzhledem k projektu na kterem delaji a za rozumny penize)
Opravdu je lepsi nez nejake CMM se treba podivat vzit si neco z extremniho programovani apod.

Usmevne... Asi budeme ucit prave ty spickove programatory a ony inzenyry, co investovali onech 30 let do definice CMM  Dobre, zrusime CMM a budeme se ridit podle vas, pane kolego

Já mám pocit, že ten problém byrokracie bude maličko jinde. Je to mnohem více o velkosti firmy, o velikosti vývojových teamů a o velikosti projektů. 

Mluvme třeba firmě o 5 lidech, kteří pracují na jednom projektu (řekněme cca půl roku) a sedi "kolem jednoho stolu". Tihle lidé si jsou schpni říci během práce a není třeba nějaké systematické řízení meetingů, toku informací mezi nimi, interní dokumentace, atd. Pro tyto lidi bude toto vše zbytečná buzerace, protože je to bude zbytčně odvádět a zdržovat od projektu, místo toho aby to něco přinášelo.

A na druhé straně vezměme team 100+ lidí, kteří jsou ještě organizováni do subteamů (ostatně jinak by to asi nešlo). Opravdu si myslíte, že bez pravidelných meetingů, velmi dobře řízené interní komunikace, velmi podrobné interní dokumentace, organizace a synchronizace buildů jednotlivých subteamů a hejna managerů, kteří budou toto vše zajišťovat bude možné vyvinout něco víc než "Ahoj světe"? Stále budete mluvit o zbytečné byrokracii?

Já jsem přesvědčen, že je to prostě o používání správných nástrojů na správné věci.

A ještě k té měřitelnosti: můj cíl není měřit kvalitu programátora a už vůbec ne podle řádků kódu. Můj cíl je být na základě předchozích projektů a zkušeností být schopen odhadnout pracnost a termíny nového projektu. A to pokud možno co nejpřesněji. L4 je pro mne zatím příliš daleko, takže se s Vámi nedokážu přít, jakým způsobem "měřitelnost" chápe CMM, ale podle toho co zatím o L4 vím, tak jsem ve své představě blíže. Ostatně podle toho co vím, základní zlepšení do řízení projektů přináší L2 a L3.

DP

Proti CMM L2 a CMM L3 vice mene nic nenamitam. To ze se musi planovat a mit nejake postupy se mi zda natolik jasne, ze to snad musi delat kazdy. (kdyz je na to clovek sam, tak to klidne staci i v hlave, ale najednou mate L2 az L3)
Ja proste mam takovy pocit, ze to s L4 a L5 prehnali v softwaru o kterem se zminim nize jsou kontraproduktivni.
Zopakuji to jeste jednou temer jako dukaz: na L4 musi byt procesy ve firme kvalitativne meritelne. Programovani programatora je process, proto musi byt kvalitativne meritelny. Jak ohodnotite nekoho cislem, tak aby to bylo porovnatelne (nezavisle na tom kdo hodnoti/meri). Dale pokud chcete opakovatelnost uspechu, jak zarucite to, ze programatora ta myslenka jak tu konkretni vec naprogramovat v sibenicnim terminu podle vetsinou protichudnych pozadavku napadne. Mozna buh to muze zarucit, ale ja jsem ateista takze tahle moznost pro mne nepripada v uvahu
Opravdu ja svoji praci programatora/analytika porovnavam s umenim a ne s popelarem.

Je pravda, ze ja hlavne mluvim o tymech programatoru do 20 lidi na jednom projektu (systemove slozitosti (napr. Adobe InDesign, MS Office, SQL Server, apod.)).
Dalsi moznost zvetseni vykonosti tymu vidim az v geneticke manipulaci nebo telepatii (uz aby to tu bylo) To bylo takove odlehceni na zaver ))

Myslím, že na L2 a L3 se shodneme. Na tom udržení v hlavě já si tolik jistý nejsem, jakmile projekt a věci s ním i nepřímo související přeroste určitou mez, tak já to v hlavě neudržím ani za nic. A tam mi pomůže CMM a nebo alespoň některé vybrané postupy. O tom jsem celkem přesvědčen.

L4 a výše už hodnotit nedokážu, poněvadž to je zatím pro mne dost daleko. Tady by asi chtělo slyšet hlas někoho, kdo už s tím má nějakou praxi. Rozpor v našich názorech je hlavně ten jak podrobně musí být jednotlivé procesy "měřitelné". Nemyslím si, že by se dalo měřit za jak dlouho napíše programátor daný řádek, ale už o modulu nebo o nějaké komponentě se to plus/mínus říci dá. Musí, poněvadž každý musí být schopen říci "Ano, rozumím definovanému úkolu a na základě svých zkušeností si myslím, že by to mohlo být hotové tehdy a tehdy". Většinou jde o to, jestli výsledný čas je 200, 300 nebo 500 % původního odhadu . Když to vezmu ještě na vyšší úrovni, vždy musíte být schopen říci, kdy daný projekt dokončite. A se vzrůstajícími zkušenostmi vidím i zlepšování tohoto odhadu. Ale jestli mi v tomto pomůže CMM L4 zatím nevím, ale doufám že ano. A podle informací, které zatím mám, tak se mi zdá, že by to tak být mohlo.

Ještě také pro odlehčení: srovnáváte práci s uměním. OK, tak se na to podívejme takhle: jste sochař a dostal jste jako zakázku vytvořit sochu T. G. Masaryka nebo V. I. Lenina (jak je libo ). Má se mu podobat, má být v nadživotní velikosti a má být z mramoru (možná plácám, nevyznám se v sochařství, ale doufám, že mne nebudete za případné nesmysly masírovat). I jako umělec musíte být schopen říci, kdy sochu dodáte (tj. už i zde máme prvek odhadu). Ale co víc, zákazník je řekněmě prudič a chce si zkontrolovat, jestli se mu líbí tvář, její výraz, gesto ruky, .. Myslíte, že i ten umělec nebude muset být schopen říci "Tak se na tu zatracenou hlavu přijďte podívat za měsíc!"?  Akorát ten umělec nebude sochu ještě půl roku bugfixovat, protože jemu se nestane, že mu tady updanul prst, támhle má každou botu jinou a nikdo si toho dřív nevšimnul, ...

Nepodobá se náhodou ta práce "nájemního" umělce a "nájemního" programátora mnohem víc, než se na počátku zdálo?

DP

No jo, ale bohuzel dost casto je zadani na zpusob: do 3 dnu udelejte sochu cloveka, musi se mi libit, musi byt aerodynamicka (dost spatna analogie k rychlemu), musi to byt lepsi nez sochy co jsem videl jinde, ale vy je videt nemuzete (konkurence, copyrighty, zakaz reverse inzenyringu), musi byt masivni (bug free), musi se vejit do kapsy (nenarocna na pamet), musi byt krasna jak ve dne tak v noci (platformova nezavislost) a hlavne me to nesmi moc stat (vic resourcu vam nedam) a uz vubec me neotravujte s nejakejma vysvetlujicima otazkama (dostatecnou specifikaci si napiste sami, ja ji stejne cist nebudu).

To je "real world" ...

Ne rozhodne neni nic cernobile. Je mozne, ze ja mam prehnanou predstavu o L4 a L5. Je pravda, ze jsem cerpam z jinych zdroju nez asi Vy. Jen jsem chtel upozornit, ze zavedenim CMM se razem vykonost nezvedne radove (budete radi kdyz za rok o 10%, ale nebude vedet ani to, jestli tech 10% nebylo proste jen vetsimi zkusenostmi lidi v tymu), jak by se nekomu mohlo zdat z trochu hypovskeho clanku.
Stejne si myslim ze nejvetsimi propagatory ISO9001 a CMM jsou pouze konzultantske firmy co na tom vydelavaji a ti co uz to "maji" aby zvysili svou prestiz.

Ano, přesně tak. To je "real word". Akorát že na rozdíl od tohoto příměru, kde je na první pohled vidět uhozenost těch protichůdných požadavků si tohle běžně zákazníci neuvědomují a netluče to tolik do očí. 

Akorát jste ještě zapomněl na jednu věc: "Jak to, že to bude stát tolik peněz a bude to trvat tak dlouho? Včera jsem viděl sochu v supermarketu za 1/10 ceny a vy mi tady tvrdite tohle. Pravda, byla to socha nekoho úplně jiného, byla ze sádry a ne z mramoru a nebyla to socha ale jen busta. Ale to co po vás chci není zas takový rozdíl."  nebo spíš  (jaký ksichtík se hodí na černý humor?)

Jak jsem psal již jinde, článek byl psaný podle literatury. A to podle literatury k CMM. Z čehož plyne, že nezmiňuje problémy a úskalí. Lepší by byl článek z praxe, co pomohlo a co ne, ale tím (doufám, že zatím) sloužit nemůžu.

Největším propagátorem CMM jsou velké západní firmy, které se s vámi nebaví, do chvíle, kdy máte CMM L4 nebo L5. Mezi řečí vám sice přiznají, že jejich vlastní vývojové centrum sice nemá ani L3, ale po vás to prostě chtějí a basta. že z hlediska vývoje projektu není L5 téměř o ničem a L4 je diskutabilní? Nezajímá, my si můžeme dovolit to nejlepší. To je taky "real world".

DP

Opravdu zakaznik s takovou predstavou prijde se svym pozadavkem do megafirmy s 2000 zamestnanci? UZ tu prece zaznelo, ze vyznam CMM se zvysuje s velikosti firmy. 20 lidi vystaci se zakladnimi pravidly, ktera si vytvori behem prvnich mesicu spolecne prace.

Abych tady jen tak plane neplacal tak uvedu priklad, pokud chcete dosahnout CMM 4 vase procesy musi byt meritelne, ale jak chcete merit kvalitu programatora napriklad v C++. Podle poctu radku - ja mam radeji programatora co to same napise na mene radku nebo snad podle poctu function pointu - radove rozdilne podle toho, kdo to pocita. Proste neexistuje rozumne mereni procesu programovani programatora.

Já bych asi právě to, co jste napsal viděl jako plané plácání v této diskuzi. Tvrdit že neexistuje rozumné měření procesů týkajících se programování je holý nesmysl.

No bohuzel ani vy ste neuvedl nic konkretniho... Me staci treba i jen odkaz na Web, proste jakykoliv system mereni ktery nedokazu obejit do 1 minuty ... Ja nerikam ze se neda merit, da, ale vysledky se daji totalne jednoduse zmanipulovat, tak aby to vyslo vzdy dobre a o samotnem stavu vyvoje projektu nerekne zhola nic.

Tento článek představuje skutečně mistrovské dílo v oboru zahalování několka jednoduchýhc myšlenek do kabátu mnoha stran hlodů. Vemte si jen první stranu, tam se neříká nic a má čtyři odstavce a rozsah skoro A4, zbytek dokumentu víceméně pochvalně přizvukuje a semtam přidá informaci nebo myšlenku.... Co to má zde co dělat?

V zásadě máte pravdu, CMM není složitá (ostatně jako spousta jiných věcí). Jen je zajímavé, že zavést CMM na úroveň 4 či 5 trvá běžně několik (i více než 10!) let a živí se na tom ve světě řada konzultačních firem.

To pak vysvetluje, proc teto urovne dosahla temer jen Indie.

Uvital by som aj viacej takychto clankov. Teoria riadenia projektov je jednou z oblasti mojho zaujmu. Mohol by mi niekto odporucit nieake linky s touto problematikou??

Presne tak. Clanek je velice zajimavy a velmi dobry. Chybi mi u nej jen odkazy na dalsi studijni materialy - tutorialy, priklady, klidne placene knihy (zasadni ucebnice), nejdulezitejsi firmy v oboru apod.

No abych jen nebuzeroval. Z Googla vypadlo treba tohle.

Ten web SEI je základ, protože tam CMM vymysleli. Jinak se dá sem tam něco najít po světě, ale je to dost pracné hledání. Provedl jsem to před časem a stáhl pár PDFek, ale linky už bohužel nemám. Příště se polepším. Abych ale uvedl aspoň nějaké zdroje, uvedu literaturu (vše anglicky):

The Capability Maturity Model - Guidlines for Improving the Software Process, Addison Wesley 1995, ISBN 0-201-54664-7, $59.95
CMM Implementation Guide, Kim Caputo, Addison Wesley 1998, ISBN 0-201-37938-4, $54.99
A Guide to the CMM, Kenneth M. Dymond, Process Transition International 2001, ISBN 0-9646008-0-3
CMM in Practise, Pankaj Jalote, Addison Wesley, ISBN 0-201-61626-2, $59.99

Vše se dá koupit na Amazonu, ale která je nejlepší se mne zatím neptejte, ještě jsem je nestačil přečíst.

Bezva, ty ceny sou trosicku palky, ale mrknu se po knihovnach a uvidim.
Diky !!!
Doufam, ze tu uvidim vice podobnych clanku. Zajimaly by mne ostatni metodiky a taky trochu extremni programovani. Mozna nakej clanek o UML apod.

pracuju jako PM , nase firma , jestli ji tedy neznate (iMachina) dela spoustu projektu najednou, webove stranky, aplikace, flash hry, kampane  apod...a  musim rict ze mi tento clanek prijde hodne podobny tomu co jsem se ucil ve skole...spousta uzasnych teoretickych vyplodu, na ktere clovek v praci muze s klidem zapomenout...pro me osobne to znamenalo casto se takove veci ucit tak trochu nazpamet, nebot mi to nikdy nic nerikalo..Je jasne, ze clovek ridi procesy ve firme na zaklade zkusenosti s obdobnymi projekty v minulosti a priadavaji se k tomu nove technologie, ktere samozrejme obcas prinaseji problemy (prikladem muze byt odlisne chovani IE6 oproti 5.5. v nekterych detailech, ci flash mx a flash 5)

Nasi dobrou zkusenosti je v tomto pripade konzultovat vse predem s klientem, nastinit ruzne scenare pri pouziti ruznych technologii i nejaky faktor rizikovosti pro jednotlive varianty a to treba vcetne varovani pred moznosti pozdrzeni projektu v situaci, ze klient vyzaduje reseni zalozene na technologii se kterou nemame dostatek zkusenosti a vime ze nas odhad muze byt nepresny. Snazime se fungovat tak, ze nasi IT lide tj.odbornici predavaji client servisu informace o novych technologiich vicemene polopaticky, coz nam lepe umoznuje vysvetlovat klientum dusledky pouziti te ci jine technologie. Take jsme pro klienty zalozili specialni web (generovany) , kde je videt prubeh projektu po jednotlivych ukolech, deadlines a % udaj o jejich splneni.

Mozna trochu smele, ale klidne bych nasi malou, cca 15clenou firmu  s prehledem zaradil do 3 urovne mozna 4., alespon podle specifikace v tomto clanku. Vetsinou predpokladam, ze tyto certifikaty ziskavaji velke firmy typu ibm, microsoft, oracle apod..

Na druhou stranu musim priznat ze clanek je zajimavy, mozna ty slibene nasledujici clanky napr o srovnani ISO9001 s SW-CMM, by mohly byt uzitecne.

Máte pravdu v tom, že celý článek je napsán podle literatury a že mnohem zajímavější jsou vlastní zkušenosti z praxe, případně srovnání s dalšími možnostmi, .... Ale článek byl míněn jako představení metodologie CMM a tam je třeba začít od píky a tudíž je to o té teorii, kterou někteří slyšeli ve škole a jiní třeba ne. Je třeba vědět, z jakých myšlenek se vychází, aby se pak daly pochopit postupy a navody čeho a jak je třeba dosáhnout.

A co se týče úrovně dosahované Vaší firmou - to je možné, firma o 15 lidech se řídí jinak, než o 50, 500 nebo 100000. Ale on ten chaos se při takovémto počtu lidí nemusí tolik projevovat.  Podle mojí zkušenosti není příliš velký problém s řízením projektů o pár lidech, ale se stoupajícím počtem lidí na projektu i ve firmě se vše komplikuje. A to je moment, kdy může pomoci CMM nebo i jiná metodologie. BTW: metodologie CMM vznikala např. na základě zkušeností s vedením projektů pro vládu a armádu USA, projekty o stovkách a tisících člověkoroků, ale nejen na ní. I na zkušenostech mimo SW firmy. To ale znamená, že by se z toho nemohly poučit i menší firmy.

DP