Vaido Adomausko paskaitos Judrus (Agile) projektų valdymas skaidrės. Ši kviestinė paskaita buvo skaitoma universitetų studentams. Kviestinės paskaitos buvo Adform bendradarbiavimo su Universtitetais projekto dalis.

1. Judrus (Agile) projektų
valdymas
VISIT OUR BLOG: adform.com Vaidas Adomauskas
TWITTER: adforminsider
2011-11-22

2. Vaidas Adomauskas
www.agile.lt, #agilelietuva
Blog: http://scrum.agile.lt www.facebook.com/agilelietuva
Twitter: @adomauskas www.slideshare.net/agilelietuva
www.slideshare.net/vaidasa www.agileturas.lt, #agileturas
www.linkedin.com/in/vaidas www.agilediena.lt, #agilediena
2

3. https://www.adform.com/site/company/careers/
3

4. 4

5. Visi mato reklaminius skydelius
5

6. Planavimas
6

7. Optimizavimas
7

8. Ataskaitos
8

9. Publisher Web Advertiser Web Search Engine
Banner Page Searched keyword
Click Click
Landing Page
……. Banner Text Ad
Page
Browsing
Tracking
Transactions
Internet
IN: Request or Event OUT: Content
Ad Serving and Web Analytics Front End
Middleware, Databases, DataWarehouses, BI Back End
Management and Planning Tools, Reporting, BI Tools
Agencies Advertisers Publishers Creative Agencies Operators Partners

10. Adform
 125+ darbuotojai
 Biurai
Danijoje, Švedijoje, Norvegijoj
e, Jungtinėje
Karalystėje, Vokietijoje, Čekijoj
e, Lietuvoje, Lenkijoje, Ispanijo
je ir Italijoje
10

11. Adform Lietuvoje
 100+ darbuotojų
 60+ gamybos skyriuje
 Architektai
 Analitikai
 Programuotojai
 Testuotojai
 Produkto valdymas
 Klientų aptarnavimas
 Buhalterija
 Marketingas
 HR
 ...
11

12. Scrum Adforme
Scrum pradžia
• 1 komanda 2010-03 • >60 žmonių
• 1 projetas • >40 žmonių • 9 Scrum
• 6 Scrum komandos
komandos • Tyrėjų komanda
Scrum pilotas Scrum dabar
2009-12 2011-11
12

13. Kas yra girdėję apie Agile?
13

14. Ką žinote apie greitį?
14

15. Boeing 737 surinkimas
 K: Kiek laiko užtrunka galutinai surinkti
Boeing 737? (pridėti
sparnus, kylį, ratus, variklius, kėdes, laidus, lakū
nų kabiną)
1. 1-3 savaites
2. 4-7 savaites
3. 8-11 savaites
4. 12-15 savaites
5. 15+ savaites
 A: #1 -- 3 dienas… jų pralaidumas – 1 lėktuvas
per dieną
15

16. Empire State pastatas
 K: Kiek laiko reikėjo pastatyti Empire State
pastatą (1930)?
1. < 1 metus
2. 1 – 2 metus
3. 3 – 4 metus
4. 4 – 5 metus
5. 5+ metus
 A: #2--410 dienų…
1 metai, 65 dienos
(1930 -03-17 – 1931-05-01)
16

17. Southwest avialinijos
 1993m. rinkos vidurkis apsukti lėktuvą buvo
55min.
 K: Per kiek laiko lėktuvus apsukdavo Southwest?
1. 10-20 minučių
2. 20-30 minučių
3. 30-40 minučių
4. 40-50 minučių
5. 60+ minučių
 A: #1--17 minučių
(69% greičiau!)
17

19. TDD
XP
Continuous
Integration
Lean
RUP Agile

20. Kaip esame pripratę
dirbti?
20

22. Reikalavimai > dizainas > programavimas
22

23. Integravimas ir testavimas
?
23

24. Tradiciniai projektai – kaip šaudymas iš patrankos
Prielaidos:
 Klientas žino ko nori
 Programuotojai žino kaip
sukurti
 Niekas pakeliui nepasikeis
24

25. Nuoseklusis (krioklinis) projektas
P V S
Planavimas Vystymas Stabilizavimas
25

26. Nuoseklusis (krioklinis) projektas
 Reikalavimai (SRS)
 “Surašykit VISKĄ ką galite sugalvoti. Bet koks reikalavimų keitimas ateityje jums kainuos
LABAI daug”
 Dokumentacija (artifacts)
 “Apsisaugosim kai ieškos kaltų”
26

27. Mes kuriame nereikalingą funkcionalumą
This graph courtesy of Mary Poppendieck
Didžiausia galimybė padidinti programinės įrangos
kūrimo produktyvumą yra rašyti mažiau kodo!*
*Mary Poppiendieck, “It’s Not About Working Software”, Agileee 2010 conference
27

28. Galbūt tai darome sėkmingai?
28

29. Ar yra viltis?
29

30. Kas veikia?
“Pirminė pagerėjimo priežastis yra ta, jog projektai tapo mažesni.”
“Projektų įgyvendinimas iteratyviais procesais, o ne kaskadiniu
metodu, kuris reikalavo jog visi projekto reikalavimai būtų apibrėžiami
projekto pradžioje, yra didžiulis žingsnis į priekį”
Jim Johnson
Chairman of
Standish Group
“Nėra panacėjos, bet judrūs (Agile)
metodai yra labai arti to.
Sources:
http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-
15/Standish
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
”My Life is Failure”, Jim Johnson’s book
30

31. Agile
www.agilemanifesto.org
We are uncovering better ways of developing
software by doing it and helping others do it.
February 11-13, 2001
Snowbird ski resort, Utah
Kent Beck Ron Jeffries
Mike Beedle Jon Kern
Arie van Bennekum Brian Marick
Alistair Cockburn Robert C. Martin
Ward Cunningham Steve Mellor
Martin Fowler Ken Schwaber
James Grenning Jeff Sutherland
Jim Highsmith Dave Thomas
Andrew Hunt
31

32. Judrumo (Agile) manifestas
...mes vertiname:
Žmones ir jų
bendravimą
labiau nei
procesą ir įrankius
http://agilemanifesto.org/
32

33. Judrumo (Agile) manifestas
...mes vertiname:
Veikiančią
programinę įrangą
labiau nei
išsamią
dokumentaciją
http://agilemanifesto.org/
33

34. Judrumo (Agile) manifestas
...mes vertiname:
Bendradarbiavimą
su klientu
labiau nei
derybas dėl
kontraktų
http://agilemanifesto.org/
34

35. Judrumo (Agile) manifestas
...mes vertiname:
Reagavimą į
pokyčius
labiau nei
plano sekimą
http://agilemanifesto.org/
35

37. Iteracija 1
 Pilnai pabaigtas
(done)
 paleidžiamas (shipable)
 produkto prieaugis
(increment)
37

38. Iteracija 2
38

39. Iteracijos 3 - …
39

40. Agile yra procesas
kurti nuolat priaugantį
produktą!
40

41. Judrūs projektai – kaip valdoma raketa
Prielaidos:
 Klientas atras ko nori
 Programuotojai atras kaip sukurti
 Pokyčių tikrai bus
41

42. Judrus projektas
P P V P V P V P V S
42

43. Judraus projekto planas
• Sistema kuriama funkcijomis / • Funkcijų prioritetus galima keisti jei
moduliais (dydis): pasikeitė svarbumas:
– Funkcija 1 (20) – Funkcija 1 (20)
– Funkcija 2 (40) – Funkcija 2 (40)
– Funkcija 3 (20) – Funkcija 5 (20) – svarbesnė
– Funkcija 4 (40) – Funkcija 3 (20)
– Funkcija 5 (20) – Funkcija 4 (40)
– Funkcija 6 (40) – Funkcija 6 (40)
• Viso (180) • Viso (180)
• Anksti matosi ar teisingai įvertinome: • Funkcijas galima keisti (tokio pat
dydžio funkcija:
– Funkcija 1 (20) – baigėm po 30 
– Funkcija 1 (20)
– Funkcija 2 (40)
– Funkcija 2 (40)
– Funkcija 3 (20)
– Funkcija 3 (20)
– Funkcija 4 (40)
– Funkcija 7 (40) – nauja
– Funkcija 5 (20)
– Funkcija 5 (20)
– Funkcija 6 (40)
• Viso (180) - ar tikrai 180? – Funkcija 6 (40)
• Viso (180)
43

44. 44

45. Kaip judrūs (Agile) projektai įvykdomi?
Source: Dr. Dobb’s Journal 2008 Agile Adoption Survey
45

46. Kas naudoja judrius (Agile) metodus?
Scrum mokymų žemėlapis: http://www.scrumalliance.org/courses/map (2011-06-16)
46

47. Kodėl Agile veikia?
47

48. Multitaskingas ir fokusavimasis
48

49. Multitaskingo žaidimas
 Pirma lentelė:
 Užpildykite stulpelius vertikaliai ( 1…10, I…X, A…C)
 Parašykite pabaigos laiką
 Pradedam!
 Antra lentelė:
 Užpildykite stulpelius iš kairės į dešinę (1, I, A, 2, II, B, 3…)
 Parašykite pabaigos laiką
 Pradedam!
 Komentarai?
49

50. 3 nepriklausomi projektai
Multitaskingas:
P1 P2 P3 P1 P2 P3 P1 P2 P3
Projekto 1 laikas (7 dienos)
Teoriškai:
Project 1 Project 2 Project 3
(3 dienos)
Realybė:
Project 1 Project 2 Project 3
(2 dienos)
Visi projektai (6 dienos)
50

51. Apibrėžtas bei empirinis procesai
51

52. Ar čia apibrėžtas ar empirinis procesas?
IT sistemų kūrimas
Automobilių gamyba
52

53. Startups
IT
projektai
Kėdžių
gamyba

54. Empirinis procesas
54

55. Vadovavimas ir saviorganizacija
55

56. Startups
IT
projektai
Kėdžių
gamyba

57. Stabili komanda
Viktorija Trubačiūtė http://www.slideshare.net/AgileLietuva/vieno-pilotinio-projekto-istorija, Lietuvos Agile Diena 2011
57

58. Sub-optimization vs. Optimize the Whole
58

59. Startups
IT
projektai
Kėdžių
gamyba

60. Tarp-funkcinė komanda
60

61. 61

62. Agile metodai
62

63. Metodai Praktikos
Agile
Continuous
XP Integration
TDD
Lean
... ...
63

64. Visa istorija
 Lean (Toyota)
 Scrum
 Extreme Programming (XP)
 Test Driven Development (TDD)
 Pair programming
Laikas
 Continues integration
 Refactoring
 Planning poker
 …
 Agile
 Kanban
 …
64

65. Scrum
65

66. Ekstremalus programavimas (XP)
 12 praktikų
 The Planning Game
 Small releases
 Metaphor
 Simple design
 Continues Testing
 Refactoring
 Pair programming
 Collective code ownership
 Continuous integration
 40 hour week
 On-site customer
 Coding standards
66

67. Scrum Daily Scrum
Team
XP Sprint
backlog
Whole team
Product Coding Burndown
Collective chart
backlog ownership TDD standard
Customer
tests Pair Refactoring Planning Sprint
Product programming Planning
game
owner meeting
Continuous Simple Sustainable
Integration design Pace
Metaphor
Small
releases
ScrumMaster
Sprint
Review
67

68. Kanban
 Vizualizuok darbo procesą
 Limituok pradėtą darbą (WIP – work in progress)
 Matuok ir optimizuok tėkmę
68

69. Kiti Agile metodai
 Feature Driven Development (FDD)
 Agile Modeling
 Crystal
 Agile Unified Process (AUP)
 Dynamic Systems Development
Method (DSDM)
 …
69

70. Kas čia blogai?
Blogai naudojasi įrankiu Naudoja blogą įrankį
Nei viena iš šių problemų yra sukelta įrankio!!!
70

71. Skirtingi įrankiai
Daugiau aprašantys Daugiau lankstūs
RUP XP Scrum Kanban Do Whatever
(120+) (12) (9) (3) (0)
• Architecture Reviewer • Business use case realization
• Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow
• Business-Model Reviewer • Business vision • Coding standard • Product Owner • Limit WIP
• Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time
• Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning meeting
• Change Control Manager • Configuration management plan • Customer tests • Daily Scrum
• Code Reviewer • Data model • Pair programming • Sprint review
• Configuration Manager • Deployment model • Refactoring • Product backlogt
• Course Developer • Deployment plan • Planning game • Sprint backlog
• Database Designer • Design guidelines • Continuous integration • BUrndown chart
• Deployment Manager • Design model • Simple design
• Design Reviewer • Development case • Sustainable pace
• Designer • Development-organization • Metaphor
• Graphic Artist assessment • Small releases
• Implementer • End-user support mateirla
• Integrator • Glossary
• Process Engineer • Implementation model
• Project Manager • Installation artifacts
• Project Reviewer • Integration build plan
• Requirements Reviewer • Issues list
• Requirements Specifier • Iteration assessment
• Software Architect • Iteration plan
• Stakeholder • Manual styleguide
 Kuris geresnis?
• System Administrator • Programming guidelines
• System Analyst • Quality assurance plan
• Technical Writer • Reference architecture
• Test Analyst • Release notes
• Test Designer • Requirements attributes
• Test Manager • Requirements
• Tester management plan
• Tool Specialist • Review record
• User-Interface Designer • Risk list
• Architectural analysis • Risk management plan
• Assess Viability of architectural proof- • Software architecture
of-concept document
• Capsule design • Software development
• Class design plan
• Construct architectural proof-of- • Software requirements specification
concept • Stakeholder requests
• Database design • Status assessment
 Lyginti
• Describe distribution • Supplementary business specification
• Describe the run-time architecture • Supplementary specification
• Design test packages and classes • Target organization assessment
• Develop design guidelines • Test automation architecture
• Develop programming guidelines • Test cases
• Identify design elements • Test environment configuration
• Identify design mechanisms • Test evaluation summary
• Incorporate design elements • Test guidelines
supratimui, ne
• Prioritize use cases • Test ideas list
• Review the architecture • Test interface specification
• Review the design • Test plan
• Structure the implementation model • Test suite
• Subsystem design • Tool guidelines
• Use-case analysis • Training materials
• Use-case design • Use case model
teisimui!
• Analysis model • Use case package
• Architectural proof-of-concept • Use-case modeling guidelines
• Bill of materials • Use-case realization
• Business architecture document • Use-case storyboard
• Business case • User-interface guidelines
• Business glossary • User-interface prototype
• Business modeling guidelines • Vision
• Business object model • Work order
• Business rules • Workload analysis model
• Business use case
71

72. Agile
Chaos Process
No planning Product Backlog : just in
(no predictability) time and just enough
Just in time and
No documentation
minimal enough
Microsoft, IBM, Amazon,
Small teams
Adform 
72

73. 73

74. Įvertinkite paskaitą, ačiū!
http://www.noop.nl/2011/04/the-feedback-door.html
74

75. Ačiū 
v.adomauskas@gmail.com
00370 600 38860
Blog: http://scrum.agile.lt
Twitter: @adomauskas
www.slideshare.net/vaidasa
www.linkedin.com/in/vaidas
75