Vývoj software na zakázku

Čím obtižnější zadání, tím větší je naše nadšení. Tohle opravdu umíme :-)
Napsal(a) 
Zveřejněno v Software na zakázku

Jak děláme v OG Soft vývoj...

Před mnoha lety jsem sám psal první kódy našeho software. Vzpomínám na to rád, byla to tehdy pro mne "ta pravá" vývojářská práce.

Práce na projektech

Doba se posunula a dnes máme v týmu minimálně 15 lidí, kteří mají na starosti vývoj a podporu našich sw produktů, ať jde o "pouhé" webové stránky nebo o komplexní informační systémy.

Navíc jsme schopni vlastními silami pokrýt kompletní proces vývoje, včetně návrhů, analýz, nebo dokumentace či dlouhodobé podpory. Dokonce umíme navrhnout pro námi vyvíjený software i infrastrukturu od hardware přes virtualizaci až po návrh a konfiguraci operačních systémů a systémových aplikací třetích stran.

Pracujeme tak často paralelně na několika projektech s různými prioritami a s projektovými týmy, jejichž složení se během životního cyklu projektů mění.

Proto jsme se před několika lety začali intenzivně zabývat tím, jak efektivně naše projektové týmy řídit.

Víme jak na to už ze školy

Ve škole nás totiž učili nejrůznější metodiky vývoje, od klasického vodopádu až po flexibilní agilní metody.

Vypadalo to dost jednoduše. Prostě vybereme nějakou, která se nám bude líbit, použijeme ji, a je to. No, nebylo to tak…

Jak to bývá, na úplném počátku jsme vyvíjeli metodou, která by se dala nazvat jako NADŠENÍ. Troufnu si napsat, že pro velmi malý tým, například jednočlenný je to vysoce efektivní metoda. Nadšení si udržujeme stále, ale pro jen o malinko větší týmy, a pro tak komplexní produkty, jako jsou ty naše, to už nestačí.

Takže jsme si prošli určitou zjednodušenou formou plánovacího vodopádu, inkrementálního přístupu, proběhly samozřejmě pokusy o Scrum a další agilní metody. Postupem let jsme zkrátka vyzkoušeli kde co, aby se nakonec se ukázalo, že v našich podmínkách nic dokonale nefungovalo. Možná přijatelně, ale to je málo.

Proč to nefunguje?

Není to zas takový objev, kdo má zkušenosti, většinou potvrdí, že nelze vybrat jednu metodu a tu beze změny využívat a ještě plošně na cokoliv.

PŘÍKLADY METODIK VÝVOJE
  • Vodopádový model - sekvenční vývojový proces, neustále se svažující tok fázemi analýzy požadavků, návrhu, implementace, testování , ...
  • Spirálový model - plánování –> stanovení cílů –> analýza rizik –> vývoj a testování –> Plánování … a takto dokola nejprve pro koncept, pak pro specifikaci, pak pro návrh a architekturu, pak pro design, implementaci, …
  • SCRUM - vlastník produktu vytváří seznam žádaných funkčností, v rámci každé iterace (1-4 týdny), tým vyvine funkčnosti tak, aby byly reálně vyvinuté a nasazené, pokrok je sledován na denních poradách, sprinty se pak opakují, ...
  • ... a další

Zdroje: JAB, Wiki

Týmová práce je totiž také hlavně o sociálním inženýrství. Zkuste dát kreativnímu vývojáři za úkol naprogramovat přesně danou klasickou funkcionalitu skladového hospodářství. V lepším případě to udělá za dvojnásobek projektovaného času a v tom horším vás pošle někam.

Nebo metodicky a precizně založenému programátorovi dát jednověté zadání pro cloudovou službu, pravděpodobně vznikne něco úplně jiného, než jste chtěli.

Zvítězil Crystal?

Takže nyní je to tak, že pro každý projekt se zvolí metodika, která je velmi často metodikou Crystal. Nejedná se o jednu školní přesnou metodiku a přístup, ale většinou o nějakou kombinaci modifikovaných metodik pro naše účely.

Záleží na projektu, na jeho manažerovi, na zákazníkovi (nejde-li o interní vývoj) a na složení projektového týmu. Například Scrum je velmi produktivní metoda, ale musí být plně zapojen a připraven i zákazník, jinak nelze aplikovat.

Agilní metody jsme většinou schopni využívat zejména při vývoji vlastních sw produktů, méně často pak u software na zakázku.

Pořád se to mění

Člověk je tvor pohodlný a asi by se nám líbilo, kdyby proces vývoje byl jednou daný a nijak se neměnil. Pracujeme ale v odvětví, které je samo jednou velikou změnou a naopak změny generuje.

Takže realita je taková, že naše metody i návazné mechanismy, jako je třeba řízení lidí a času či odměňování pracovníků, neustále upravujeme a vylepšujeme. A jsme si vědomí toho, že to nikdy neskončí.

Ono je to nakonec dobře, protože jen tak se dá udržet to zmiňované nadšení i u kolegů, kteří jsou u nás řadu let. Při příchodu posily do našeho týmu se snažíme každého nováčka motivovat, ať nám do metodik co nejvíce mluví a upozorní nás na naši případnou provozní slepotu v kterékoliv části procesu nebo přijde s neotřelým nápadem, který nám naše postupy vylepší.

Je PM sprosté slovo?

Nakonec nemohu vynechat určitou glorifikaci projektových manažerů. Pracujeme tak, že každý, i sebemenší projekt, musí mít jmenovaného projektového manažera, nebo-li PM. A to skutečně není žádná nadávka.

Právě naopak, jedná se nejlépe o nejschopnější a nejoceňovanější členy našeho týmu. Jejich úloha je v projektu klíčová. Jsou jeho hybatelé a členové týmů se na ně spoléhají, že udrží požadované koncepce, zajistí směřování k cílům projektu a nastaví strukturu týmu i používané metody.

Práce PM je tak u nás naprosto klíčová a vyžaduje často nejen odborné znalosti, ale i tzv. měkké schopnosti a zkušenosti, které nelze získat jen ve škole. PM tak mají vysokou odpovědnost a mohou si u nás zasloužit velmi slušné finanční ohodnocení.

Co nám to přináší?

Nejsme obrovská firma a to, k čemu jsme došli, se jistě dalo zjistit cestou časově méně náročnou. Ani to nepovažuji za něco zcela výjimečného. Naopak mi to dnes přijde poměrně samozřejmé.

Jsem hrdý zejména na to, že v každém okamžiku zachováváme otevřenost pro provádění změn. Dává nám to dobrou výchozí pozici pro realizaci libovolného projektu. A každý nový projekt je pro nás výzva pro ověření funkčnosti našich metodik, případně pro jejich vylepšení.

Označeno v :
2196 Naposledy změněno pondělí, 04 březen 2019
Kontaktujte našeho obchodníka
Jaroslav Kopecký
Jaroslav Kopecký
Jednatel společnosti
 kopecky@ogsoft.cz   +420 603 162 675
Přihlašte se k odběru novinek pro firmy