Jak Microsoft dělá software? Michael Juřek Software Architect Microsoft s.r.o.

Agenda V čem je MS stejný a v čem jiný? Prostředí, firemní kultura,... TýmyProcesyNástroje

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

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ů

Historická čísla

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

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

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

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

Agenda V čem je MS stejný a v čem jiný? Prostředí, firemní kultura,... TýmyProcesyNástroje

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,...

Redmond, WA, USA

Firemní kultura Každý vývojář má nárok na svoji místnost Rozměry neřešme 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ý...

Agenda V čem je MS stejný a v čem jiný? Prostředí, firemní kultura,... TýmyProcesyNástroje

(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

Organizace týmu Produkty vytváří produktové jednotky “Product Units” Obsahují 3 hlavní disciplíny (Dev, Test, PM) Řídí je “Product Unit Manager” Velikost cca 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

Organizační struktura Product Line Manager Core Engineering Manager Development Manager Test Manager Group Program Manager PU Manager #1 Development Manager Test Manager Group Program Manager PU Manager #2 Development Manager Test Manager Group Program Manager PU Manager #3 Development Manager Test Manager Group Program Manager

Agenda V čem je MS stejný a v čem jiný? Prostředí, firemní kultura,... TýmyProcesyNástroje

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ónyScénářeTermíny

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ářů)

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ů

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 Plánování milníků

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

Klíčové milníky v projektech Milník/FázeDefinice Spec Complete Scénáře a rysy jsou definovány a prošly revizí Feature Coding Typicky 8-9 týdnů – implementační práce Code Complete (CC) Všechny rysy pro daný milník jsou implementovány Test Plan Complete Testovací plány pro všechny rysy jsou hotové a prošly revizí Test Case Code Complete Všechny testy jsou hotové ZBB Test Pass (ZBB TP) Všechny funkční testy běží na současném buildu Zero Bug Bounce (ZBB) # chyb pro danou iteraci starších než 48 hodin = 0 Zero Resolved Bugs (ZRB) # počet vyřešených, ale neuzavřených chyb = 0 Test Sign-Off Finální verifikace a uvolnění kódu širšímu publiku

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 Jména iterací

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ů

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 sumarizující provedené změny a opravené chyby

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

Virtual Build Lab – pohyb kódu

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ý

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 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í

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

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 1. Uzamčení množiny rysů, zákaz jakýchkoliv změn 2. Kompletní otestování k odhalení chyb 3. Snaha o dosažení nula známých chyb (ZBB) 4. Opakuje se, dokud množství nově odhalovaných chyb není dostatečně nízké 5. Zpřísnění klasifikace chyb pro opravu v dané iteraci (pouze bezpečnostní a kritické chyby)

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í

Agenda V čem je MS stejný a v čem jiný? Prostředí, firemní kultura,... TýmyProcesyNástroje

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

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

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

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

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í)

Product Studio: Bug Queries

Product Studio: Bug Detail

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

“Mad-dog” Test Automation System

Monitorování kvality – sběr dat

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

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

Otázky Michael Juřek,