1 / 49

Jak Microsoft d ělá software?

Jak Microsoft d ělá software?. Michael Juřek Software Architect Microsoft s.r.o. mjurek @microsoft.com. Agenda. V čem je MS stejný a v čem jiný? Prostředí, firemní kultura, ... Týmy Procesy Nástroje. V čem je MS stejný? Stejné problémy. Predikce postupu

rafer
Download Presentation

Jak Microsoft d ělá software?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

  4. 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ů

  5. Historická čísla

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

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

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

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

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

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

  12. Redmond, WA, USA

  13. 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ý • ...

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

  15. (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

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

  17. Organizační struktura

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

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

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

  21. 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ů

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

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

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

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

  26. 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ů

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

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

  29. Virtual Build Lab – pohyb kódu

  30. 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ý

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

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

  33. 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)

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

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

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

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

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

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

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

  41. Product Studio: Bug Queries

  42. Product Studio: Bug Detail

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

  44. “Mad-dog” Test Automation System

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

  46. 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?

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

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

More Related