Jak Microsoft d ělá software?

2. Jak Microsoft dělá software? Michael Juřek Software Architect Microsoft s.r.o. mjurek@microsoft.com

3. Agenda • V čem je MS stejný a v čem jiný? • Prostředí, firemní kultura, ... • Týmy • Procesy • Nástroje

4. V čem je MS stejný?Stejné problémy • Predikce postupu • Odhad (a dodržení) nákladů a termínů • (Ne)koordinovanost lidí • Vnitřní boje a rivalita skupin • Špatná komunikace • Neodhalení rizik včas

5. V čem je MS jiný?Jiná dimenze • Množství lidí • Množství produktů (-> závislostí) • Velikost spravovaného kódu • Větší specializace lidí • Množství jazyků a nástrojů

6. Historická čísla

7. Velikost týmů • IBM DOS 1981 Omluvte prosím nekvalitní reprodukci z knihy.

8. Velikost týmů • Windows 3.0 a Windows 95 Omluvte prosím nekvalitní reprodukci z knihy.

9. Velikost týmů • Windows 2000 Omluvte prosím nekvalitní reprodukci z knihy.

10. ... a ještě druhá polovina • Windows 2000 – 5325 lidí Omluvte prosím nekvalitní reprodukci z knihy.

11. Agenda • V čem je MS stejný a v čem jiný? • Prostředí, firemní kultura, ... • Týmy • Procesy • Nástroje

12. Multinárodní firma • Vývoj silně koncentrován: • Redmond Campus poblíž Seattlu • Vývoj některých technologií i v jiných lokalitách: • Různá místa v USA (často pozůstatky akvizic) • Indie, Čína– levná pracovní síla • Dánsko – ex-Navision • Izrael – některé bezpečnostní technologie • MS Research – Cambridge, Japonsko, ...

13. Redmond, WA, USA

14. Firemní kultura • Každý vývojář má nárok na svoji místnost • Rozměry neřešme  • Cola & pop-corn • Tisíce třípísmenných zkratek • Slang: • Dog fooding – sám používám nehotový produkt • Death march – dokončování produktu • War room – tým rozhodující o prohlášení produktu za hotový • ...

15. Agenda • V čem je MS stejný a v čem jiný? • Prostředí, firemní kultura, ... • Týmy • Procesy • Nástroje

16. (De)centralizace • Rozdělení do 4 velkých divizí • Produktové týmy uvnitř divizí jsou relativně nezávislé • Koordinace/spolupráce je úkolem týmů, senior management ji kontroluje, ale neřídí • Principy MSF a infrastruktura ve vývojovém procesu jsou povinné: • V jejich implementaci je značná míra volnosti

17. Organizace týmu • Produkty vytváří produktové jednotky “Product Units” • Obsahují 3 hlavní disciplíny (Dev, Test, PM) • Řídí je “Product Unit Manager” • Velikost cca 30-200 lidí • Program Management (PM) • Zodpovědnost za definici produktu, její dodržení a koordinaci • Development (Dev) • Zodpovědnost za implementaci produktu • Test • Zodpovědný za testování a zajištění kvality

18. Organizační struktura

19. Agenda • V čem je MS stejný a v čem jiný? • Prostředí, firemní kultura, ... • Týmy • Procesy • Nástroje

20. První kroky • Shromáždění požadavků (marketing, Product Manager) • Definice vize – schválena senior vedením • Široký tým upřesní vizi a definuje hlavní témata produktu, stanoví rámcová data. • Produktová jednotka pak provede detailní plánování produktu: • Persóny • Scénáře • Termíny

21. Persóny (personas) • V kontextu vývoje zastupuje uživatele anebo jejich skupinu (podobné „actor“) • Persona není abstraktní a neosobní „actor“, je to fiktivní, ale konkrétní osoba • Popisuje se její chování, návyky, motivace apod., je možné ji ztotožnit s konkrétním člověkem • Používá se ke stanovení cílů (a z nich pak scénářů)

22. Scénáře • Persónám se přiřadí konkrétní scénáře na základě analýzy zpětné vazby od vybraných zákazníků, vývoje trhu, ... • Scénář se rozpadá na menší části – rysy („features“) • Jednotlivé rysy se ohodnotí: • Např. pracnost, složitost, důležitost, míra rizika na tříbodové stupnici • Tyto údaje slouží k upřesnění termínů a v případě termínových tlaků jsou rozhodující o případné redukci rysů

23. Plánování milníků • Milník = jednotka postupu v projektu • Cíl: Flexibilní plánování, sledování, stabilizace a zpětná vazba • Typický postup milníků: M0, M1, M2, Mx…, Beta1, Beta2, RTM • Umožňují měření postupu a zbývající vzdálenosti • Rysy jsou přiřazeny jednotlivým milníkům podle definovaných pravidel (priorita, složitost, ...) • Umožňuje flexibilní plánování mezi jednotlivými milníky, eventuální redukci rozsahu rysů • Milník je dosažen, pokud jsou splněna jeho kvantitativní i kvalitativní kritéria • Zaručuje, že se nepostupuje vpřed příliš rychle bez koordinace • Zaručuje relativně stabilní produkt na konci milníku • Dosažení milníku je vždy explicitně ohlášeno a spojeno s verzí produktu

24. Matice kompromisů • Počáteční režim: • Fixní zdroje, zvolíme rozsah, přizpůsobíme termín • V dalších fázích projektu: • Fixní zdroje, zvolíme termín, přizpůsobíme rozsah • Pozor na Beta zákazníky • Pouze v mimořádných případech: • Fixní termín, zvolíme rozsah, přizpůsobíme zdroje

25. Klíčové milníky v projektech

26. Jména iterací • M0,M1, ... (Milestone) - prototypování • IDW (Internal Developer Workstation) – k dispozici dalším skupinám uvnitř MS • TAP (Technology Adoption Program) – k dispozici vybraným zákazníkům • Beta, CTP (Community Technology Preview) – k dispozici široké veřejnosti nebo jenom MSDN předplatitelům nebo zaregistrovaným testerům • RC (Release Candidate) – v podstatě hotový produkt, který ještě neprošel finálními testy • Escrow – produkt, který je později prohlášen za finální, pokud se nevyskytne mimořádně závažný problém • RTM (Ready To Manufacturing) – hotový produkt

27. Vývoj – uložení kódu • Cílem je efektivní, čistý, dobře faktorizovaný a udržovatelný kód • Hotový kód musí mít minimální životnost 10 let po dobu garantované podpory • Dokumentace uložena externě mimo zdrojový kód • Aby nedocházelo ke kolizím vývojářů a dokumentaristů • Všechny řetězce jsou zásadně uloženy mimo zdrojový kód • Lokalizace prováděna v Irsku a Japonsku • Např. .NET Framework lokalizován do 34 jazyků, Visual Studio do 8 jazyků

28. Vývoj – větve kódu • Udržuje se jediný strom kódu pro celou produktovou řadu • Např. je možné jedním příkazem provést “build -c” a provést kompletní kompilaci CLR, ASP.NET, .NET FX, Visual Studio a setup programu včetně generování médií (cca 9 hodin) • V libovolném podadresáři je možné dát “build -c” a provést rekompilaci pouze části • Každý tým si udržuje oddělenou privátní větev kódu: • Interní systém SourceDepot optimalizovaný pro branching/merging • Počet check-in operací do hlavního stromu je minimalizován • Každý check-in musí projít revizí jiného vývojáře v týmu před uložením změn do hlavního stromu. • Po provedení check-in dostane každý člen týmu e-mail sumarizující provedené změny a opravené chyby

29. Vývoj - integrace kódu • Virtual Build Lab (VBL) • Interní systém kontroly zdrojového kódu optimalizovaný pro branching/merging • Umožňuje koordinaci vývoje (např. SQL a .NET framework) • Zpětná integrace: • Kód se po dosažení milníku ve skupině přesouvá z privátních větví do veřejnějších větví (eventuálně až do hlavního úložiště kódu) • Dopředná integrace: • Změny v kódu od ostatních skupin se přesouvají „dolů“ do privátnějších větví • Umožňuje integraci doposud nezávislých změn provedených jednotlivými skupinami • Někdy je nutné řešit vzájemné nekompatibility změn

30. Virtual Build Lab – pohyb kódu

31. Denní build • Nový “build” produktu je vytvářen každý den • Vynucuje disciplínu, kritické zejména na konci projektu • Centrální spravované prostředí provádí build pro celou divizi (např. .NET framework+VS 2005 = 2200 lidí) • Nepřetržitý provoz 24x7 • Každý tým má tzv. build facilitation developera (BFD) neustále na telefonu, aby pomohl s případnými problémy • Proces buildu na příkladu .NET frameworku+VS: • Zahájení synchronizace zdrojového kódu (~24:00) • Zahájení vlastního buildu (~4:00) • Build je dokončen (~13:00) • Dokončení BVT (Build Verification Tests) verifikace (~16:00) • Získání případných hotfixů od BFD koordinátora a inkrementální rebuild + BVT • Opakuje se, dokud není build úspěšný

32. Testování 1/2 • V Test týmů jsou vývojáři zodpovědní za navržení testovacího plánu, vývoj automatických testů a provoz testovací infrastruktury • Důraz na kvalitu a obranu před regresními chybami, rychlou analýzu a porovnání buildů • Příklad - .NET framework 2.0 + VS 2005: • 10,339,207 funkčních testů • ~9000 serverů v testovací laboratoři ke spouštění testů • Úplné provedení všech testů trvá 21 dní • Interní systém správy testů dovoluje: • Vytvářet, měnit, analyzovat testovací případy a scénáře • Vzdálený re-imaging počítačů v testovací laboratoři • Vzdálené spuštění sady testů v testovací laboratoři • Vzdálenou analýzu výsledků a jejich publikování

33. Testování 2/2 • Testovací plány jsou prvním krokem • Detailní dokument popisující všechny aspekty testování a požadavky na výsledky pro každý milník • Cílem je pokrytí alespoň 70% kódu automatizovanými testy • Některé skupiny dosahují až 85% • Cíl se neustále zvyšuje • Stoupá důraz na automatizované testy UI • Snaha odhalovat „díry“ v testování • Když je nalezena chyba, tester vždy musí vytvořit testovací případ, který chybu odhalí a teprve pak se chyba opravuje • Automatické testování pro odhalování regresních chyb • Zhruba dochází k 1 regresi v 3-6% oprav chyb

34. Předposlední kroky • Velké projekty prochází jakýmsi přistávacím manévrem, nejsou ukončeny náhle • Jako tanker, také nemůže přistát zničehonic • Klíčové kroky • Uzamčení množiny rysů, zákaz jakýchkoliv změn • Kompletní otestování k odhalení chyb • Snaha o dosažení nula známých chyb (ZBB) • Opakuje se, dokud množství nově odhalovaných chyb není dostatečně nízké • Zpřísnění klasifikace chyb pro opravu v dané iteraci (pouze bezpečnostní a kritické chyby)

35. Poslední kroky • Snaha o dosažení nulové úrovně změn v kódu (code churn) • Ukončení vývoje přebírá „War Team“ (WT): • Tvoří ho nejzkušenější členové týmu • Zodpovědný za závěrečná rozhodnutí • Setkává se minimálně 1x denně • Tell Mode – tým může opravovat závažné chyby a je povinen oznámit to WT • Ask Mode – tým musí požádat WT o povolení opravy • Neustále se zpřísňují požadavky na na povolení opravy („raising triage bar“) • Produkt je uvolněn, jakmile dostatečně dlouho nebyla povolena oprava chyby („escrow“) a zároveň proběhlo úspěšné poslední testování

36. Agenda • V čem je MS stejný a v čem jiný? • Prostředí, firemní kultura, ... • Týmy • Procesy • Nástroje

37. Kde se používá VSTS ? • VSTS bylo vyvinuto s pomocí VSTS • Beta 2 se vyvíjela pomocí Beta 1 apod. • Nový vývoj podle možností přechází na VSTS • Např. SQL Server „Katmai“ • Stávající projekty se vyvíjí stávajícími nástroji (např. Windows Vista) • Příští verze VSTS by měla nahradit veškeré dosavadní vývojové nástroje používané v MS

38. Modelovací nástroje • Modely UML pouze k vizualizaci a porozumění, ne ke generování kódu • Nejčastějším nástrojem je Visio • Class designer ve VS 2005 pro návrh struktury .NET kódu • Budoucnost – používání DSL jazyků pro specifické úlohy

39. Vývojové nástroje • Vývojáři v MS používají pro vývoj různé nástroje • Visual Studio, Emacs, VI, Source Insight, ... • Nejsou povoleny žádné soubory specifické pro daný nástroj • C++ a C# obsáhnou drtivou většinu vývoje

40. Kvalita kódu • Statická analýza • Interní nástroje – FxCop (managed), PreFix, PreFast (nativní) • Nově zahrnuty ve VS Team Developer • Dynamická analýza • 2 interní profilery – jeden vytvořil SQL tým a druhý Windows tým, jeden na principu instrumentace a druhý samplingu • Nově zahrnuty ve VS Team Developer

41. Bug Tracking • Interní systém pro sledování chyb (Product Studio). • Bohaté reportování a sledování historie každé položky • Povinně využíván všemi týmy v MS (umožňuje prolinkování chyb mezi produkty) • Chyby jsou ohodnoceny (“triaged”)leadery týmů a je jim přiřazena priorita 0-4 • Opravují se pak podle priority • Denní stav chyb se posílá celé divizi • Klíčové metriky: nové/vyřešené/uzavřené chyby (sumárně i podle lidí)

42. Product Studio: Bug Queries

43. Product Studio: Bug Detail

44. Testování • Vlastní testovací systém „Mad Dog“ • V projektech používajících VSTS se přechází na vestavěné testování • Vysoká úroveň automatizace testů nevizuálních částí • Dlouhodobě neuspokojivá automatizace funkčních testů vizuálního rozhraní • Používají se nástroje třetích stran

45. “Mad-dog” Test Automation System

46. Monitorování kvality – sběr dat

47. Monitorování kvality – analýza dat • Rozklad RAM • Chyby v málo využívaných částech • HW problémy Chyby Kde je hranice? A cotohle? Co jetohle?

48. Závěrem • MS má bohaté zkušenosti s vývojem software • Velmi propracovaný proces zaručující vysokou kvalitu, který se stále zdokonaluje • Zkušenosti z 25 let vývoje a z interních nástrojů jsou zúročeny ve Visual Studio Team System • Výhledově budeme používat shodné nástroje jako naši zákazníci a partneři

49. Otázky Michael Juřek, mjurek@microsoft.com http://msdn.microsoft.com/teamsystem