Středa na TechEdu se pro mě nesla ve znamení hledání dobré přednášky. Ukázal se klasický problém, že ne vždy je popis a realita shodná.
První přednáškou, kterou jsem chtěl absolvovat, mělo být téma jak vytvářet „Human workflow“ pomocí WF. Jenže když přednášející ze 75 minut zabil prvních 30 výkladem o tom, co je to vlastně State Machine Workflow a dle slidů ho ještě čekal výklad Persistence a Trace Service z WF, pochopil jsem, že o specialitách Human Workflow moc nestihne říct a odfrčel jsem aspoň na druhou polovinu přednášky o tom, jak využívat ASMX/WCF Service Factory při návrhu projektu. Vizualizace návrhu serviců s grafickým definováním metod a data kontraktů služeb vypadalo velice příjemně ovladatelné a generování kódu včetně spousty atributů značně ulehčilo. Víc o této service factory zde.
Další přednáška se týkala programování ve vláknech a nových možností v souvislosti s LINQ. Těm kdo ještě nenarazili na slůvko PLINQ, doporučuji trochu zagooglit a přečíst si něco o možnostech práce s LINQ ve více vláknech. PLINQ je součástí Parallel Extensions, která nabízí další zajímavé možnosti práce s vlákny. Vše podstatné najdete zde.
Místo oběda jsem navštívil krátkou, 45 minutovou přednášku o tom, jak vlastně fungují lambda výrazy a nutno říct, že to byla velice dobře udělaná přednáška, která bohužel proběhla v tzv. theatre a tyto přednášky se nenahrávají, takže na DVD z konference nebude.
Odpoledne jsem jako nejzajímavější absolvoval debatu s názvem „Agilní rozhovor o agilním programování“. Pro ty, co ještě tápou v tom, co se skrývá za pojmem agilní programování, pár myšlenek z debaty:
Velice zjednodušeně řešeno, agilní programování umožňuje tvorbu kódu tak, že na požadavky klienta, které se objeví v průběhu vývoje, jste v stavu říct ANO. Samozřejmě, sem tam mu musíte říct ANO, ALE …
Základem pro tuto schopnost je krátký interval mezi verzemi aplikace, a to na úrovni 1,5 až 3 měsíce. Po dobu vývoje neustále dochází k vyhodnocení priority požadavků co za features kódovat, takže se klidně může stát, že to co mělo na začátku vysokou prioritu, a bylo naplánováno do verze 1.3, se v okamžiku zahájení práce na 1.3 přesune na později a začne se s jinou feature, která se ukáže na základě nových požadavků klienta důležitější.
Zajímavá myšlenka padla u dotazu, jak tímto způsobem řídit vývoj, když je fixní částka peněz domluvená za projekt. Jedno z doporučení bylo řešit to pomocí rozdělení veliké zakázky na několik menších. Takže např. namísto kontraktu za 15 milionů na 3 roky podepsat kontrakt za 5 milionů na první rok s tím, že pokud budou obě strany spokojené, není problém pokračovat ve vývoji další rok s podpisem pokračující smlouvy. I když na první pohled má tento nápad plno mínusů (hlavně když si nejsem jist spokojeností klienta s mou prací po roce), má i výhody a za jednu z hlavních bych viděl překlenutí klasického problému faktu, že klient často na začátku neví, co vlastně přesně chce a stanovení ceny je takové věštění ze skleněné koule.
Aby šlo takové rozdělení realizovat, je nutno projekt rozdělit na malé funkční prvky, které lze udělat a říct hotovo a z těchto prvků pak skládat vyšší funkčnost. No a na těchto malých prvcích pracují „malé“ týmy, které nemají problém koordinovat svůj postup. TFS server samozřejmě podporuje řízení projektů na principech agilního programování, takže tuto metodologii můžete rychle implementovat, pokud TFS používáte. Neznamená to samozřejmě, že bez TFS to nejde.