OASHI: Netusim, "jak se to ma delat, kdyz se zacina" a neznam zadne oficialni, univerzalni a vseresici postupy (ani nikoho, kdo je zna), ale jsem osobne presvedceny o tom, ze slepe dodrzovani jakekoliv metodiky neni tou nejlepsi cestou.
Co firma, to original. Me soucasne zamestnani je mym 3 setkanim s QA nebo alespon testovanim a vzdycky to bylo jine. Potreby jsou jine, priority jsou jine, lidi jsou ruzni...
Mam za to, ze firma ktera uzna, ze potrebuje metodika, ktery bude sjednocovat praci na projektech, aby si lide rozumeli a zbytecne si nelezli do zeli, a aby "to hezky slapalo", potrebuje cloveka, ktery se o tu metodiku bude starat, hledat jeji slabiny a vylepsovat ji.
Vsude, kde "se uz neco dela", dela se to podle stanovene metodiky nebo alespon nejakeho domluveneho postupu (coz je vlastne pouze pisemne nevydana metodika :) ). Nebyl jsem a aktivne se nepodilim na vyvijeni/nasazovani metodiky uplne od nuly, ale vzdy uz existovaly nejake vice ci mene domluvene definovane a funkcni rocesy. Na vsech realnych projektech je mozne si vsimnout nedostatku a komplikaci, ktere by bylo dobre optimalizovat, aby nezabiraly tolik casu, vystupy obsahovaly mensi mnozstvi chyb, informace byly pokud mozno uplne jednoznacne...
Kdyz se zacina, urcite neni spatne projit si par znamych metodickych postupu a analyzovat si v cem jsou jejich vyhody, nicmene pachani merge ruznych metodik, pokud by to bylo vubec mozne ;), bych se radsi vyhnul... :)