Jak microsoft d l software
This presentation is the property of its rightful owner.
Sponsored Links
1 / 49

Jak Microsoft d ělá software? PowerPoint PPT Presentation


  • 67 Views
  • Uploaded on
  • Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Jak microsoft d l software

Jak Microsoft dělá software?

Michael Juřek

Software Architect

Microsoft s.r.o.

[email protected]


Agenda

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

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

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

Historická čísla


Velikost t m

Velikost týmů

  • IBM DOS 1981

Omluvte prosím nekvalitní reprodukci z knihy.


Velikost t m1

Velikost týmů

  • Windows 3.0 a Windows 95

Omluvte prosím nekvalitní reprodukci z knihy.


Velikost t m2

Velikost týmů

  • Windows 2000

Omluvte prosím nekvalitní reprodukci z knihy.


A je t druh polovina

... a ještě druhá polovina

  • Windows 2000 – 5325 lidí

Omluvte prosím nekvalitní reprodukci z knihy.


Agenda1

Agenda

  • V čem je MS stejný a v čem jiný?

  • Prostředí, firemní kultura, ...

  • Týmy

  • Procesy

  • Nástroje


Multin rodn firma

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

Redmond, WA, USA


Firemn kultura

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ý

    • ...


Agenda2

Agenda

  • V čem je MS stejný a v čem jiný?

  • Prostředí, firemní kultura, ...

  • Týmy

  • Procesy

  • Nástroje


De centralizace

(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

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


Organiza n struktura

Organizační struktura


Agenda3

Agenda

  • V čem je MS stejný a v čem jiný?

  • Prostředí, firemní kultura, ...

  • Týmy

  • Procesy

  • Nástroje


Prvn kroky

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


Pers n y personas

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

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ů


Pl nov n miln k

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


Matice kompromis

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

Klíčové milníky v projektech


Jm na iterac

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


V voj ulo en k du

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

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


V voj integrace k du

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

Virtual Build Lab – pohyb kódu


Denn build

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ý


Test ov n 1 2

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í


Test ov n 2 2

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 edp osledn kroky

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)


Posledn kroky

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í


Agenda4

Agenda

  • V čem je MS stejný a v čem jiný?

  • Prostředí, firemní kultura, ...

  • Týmy

  • Procesy

  • Nástroje


Kde se pou v vsts

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

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

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

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 Queries


Product studio bug detail

Product Studio: Bug Detail


Testov n

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

“Mad-dog” Test Automation System


Monitorov n kvality sb r dat

Monitorování kvality – sběr dat


Monitorov n kvality anal za dat

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?


Z v rem

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

Otázky

Michael Juřek, [email protected]

http://msdn.microsoft.com/teamsystem


  • Login