slide1
Download
Skip this Video
Download Presentation
Jak Microsoft d ělá software?

Loading in 2 Seconds...

play fullscreen
1 / 49

Jak Microsoft d ělá software? - PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Jak Microsoft d ělá software?' - rafer


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ů
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, ...
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
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
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
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í)
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
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

ad