20. srpna 2011

Znáte SPL (Software Product Line)?

SPL je zkratka pro Software Product Line. Jedná se o styl vývoje podobný tomu, jak se vyrábí mobily nebo auta. Není to tedy vhodné pro jednorázové projekty, ale spíše pro produkty - firma má představu, jaký produkt nabízet na trhu, navrhne možné varianty a ty se pak snaží nabízet zákazníkům.

Je to opravdu hodně podobné výrobě aut. Výrobci znají segment cílových zákazníků, ví, že to například směřujeme na střední vrstvu, která si ráda připlatí za navigaci, tempomat, xenony, automatickou převodovku atd. Je tedy nutné navrhnout takový výrobní proces resp. architekturu auta, aby toto všechno šlo zákazníkovi dodat, ale klidně s určitými omezeními, např. pokud tempomat, tak ano, ale pouze s aut. převodovkou. I u aut může chtít někdo něco opravdu speciálního, co v nabídce automobilky není - pak osloví třeba nějaký specializovaný servis, který mu upraví motor dle jeho přání. To už ale je něco opravdu specifického a zákazník musí počítat s tím, že si to také pořádně zaplatí.
Automobilka nevidělá tím, že prodá jedno, dvě auta, ale třeba až tisíc, kdy se ty náklady na vývoj a implementaci vrátí.

Zpět k SPL. My nenavrhujeme auto, ale produkt, o kterým si myslíme, že ho máme komu nabídnout a nabídku opakovat. Musíme vědět možné variace a závislosti mezi nimi, tak abychom nenabízeli jeden uzavřený produkt, ale aby si zákazník mohl vybrat - chcete Oracle nebo MS SQL? Chcete zabezpečení přes HTTP, NTLM nebo OpenID? Chcete systém nasadit na vlastní server nebo na náš server nebo do cloudu? Naopak není třeba nutné, aby zákazník měl mít možnost vybrat jaký DMS systém chce - u auta si také nemůžete vybrat z více podvozků.

Asi nejvíce se mi ze SPL líbí přístup k vytváření interních megalomanských frameworků - budu citovat "Rather than put general software components into a library in the hope that opportunities for reuse will arise, software product lines only call for software artifacts to be created when reuse is predicted in one or more products in a well defined product line."

Pokud si o tom chcete přečíst více, pak doporučuji následující zdroje:


9. srpna 2011

Přenositelnost zkušeností

Konečně jsem si opět našel chvilku a píši na můj blog. Poslední měsíce jsem byl extrémně vytížený, protože se mi stalo, že se mi sešlo několik termínů dokončení projektů a já nevěděl co mám dělat dříve. Samozřejmě jsem to takto vůbec neplánoval, bylo to způsobené standardně tím, jak se všechny projekty protahovaly až se to vše potkalo v jeden termín.

Práci na volné noze mám natolik rád, že to považuji za jednu velkou výhodu, nicméně zde se ukazuje jedna malá nevýhoda - nedokážu říci svým stálým a dlouhodobým zákazníkům NE, protože se bojím o ztrátu zákazníka. A proto se mi to pak někdy takto vyboulí. Sám ale cítím, že je to takto špatně, protože pokud je někdy hodně práce a nevíte co dříve, pak zákonitě musí trpět kvalita, i když si to člověk nepřipouští.

Dnes ale chci psát o něčem jiném - v poslední době stále více dostávám prostor v různých firmách radit s optimálním nastavením vývojového procesu. Musím se přiznat, že mě někdy překvapuje, jak některé zavedené firmy, které jsou maximálně profesionální ke svým zákazníkům, se snaží odpovědět na základní otázky týkající se interního procesu vývoje.

Často jsem se v této souvislosti zamýšlel, jak nejlépe v této oblasti předávat moje zkušenosti nabité z působení v řade firem, vždy by se dalo říci s unikátními a vlastními postupy vývoje aplikací. Pokud někomu předáváte ryze technické informace a zkušenosti, tak to každý většinou vezme a ani nepřemýšlí o tom, že by to mohlo být jinak. U předávání ryze praktických zkušeností to takto nefunguje a mám prostě pocit, když to trochu přeženu, že pokud si na to každý nepřijde sám, tak tomu neuvěří. Jen je potřeba správně určit mantinely, aby člověk znovu neobjevoval kolo.

Celkem se mi zdá rozumné, když si firma na tyto konzultace a rady najímá někoho externího, protože jeho slovo má "větší" váhu, není zasažen interními vztahy, historií firmy a má celkový nadhled nad celým procesem.

Snad v každé firmě, ve které jsem byl, tak byl specifický proces vývoje, nějak specificky upravená metodika. Jsou určitě rozdílné nároky na vývoj jednorázových aplikací nebo produktů, ale proč to musí být všude jinak, když existuje opravdu jen několik rozumných metodik, které má cenu zvažovat a nasadit?

Je také zajímavé vidět, kdo v jaké firmě je ten "nejdůležitější" - jednou to jsou obchodníci, podruhé konzultanti a někdy dokonce vývojáři jsou ti, kteří mají největší hlas v tom, jak se co bude dělat. Myslím, že toto je většinou dáno tím, jak firma vznikala - pokud firma začínala s několika programátory, tak i nyní, když má přes sto lidí, má vývoj největší slovo.