Controlled chaos - Producing trustworthy embedded systems ... Controlled chaos - Producing trustworthy

  • View
    2

  • Download
    0

Embed Size (px)

Text of Controlled chaos - Producing trustworthy embedded systems ... Controlled chaos - Producing...

  • Controlled chaos - Producing trustworthy embedded systems using Agile methods

    Ko Dooms (Philips Applied Technologies)

    Contents

    Short introduction speaker SPI (top-down approach)has come to its end? Agile documentation Agile Experiences from Philips

    Benchmark Agile Tooling

    Q&A

  • Meet Ko Dooms

    Age: 51 Married with children One grandchild Sports: Golf, Darts, Baseball

    Work: 26 year Philips Now:

    Resource Competence manager at Philips Applied Technologies

    Then: Software engineer, project leader, group leader, development mgr., project mgr., groups mgr.

    Our role within Philips

    G.J. Kleisterlee

    G. Dutiné P.J. Sivignon S. Rusckowski A. Ragnetti R. Provoost Th. van Deursen

    Board of Management

    Corporate Technologies

    R. Harwig

    Philips IP&S R. Peters

    Philips Research R. Harwig

    Philips Applied Technologies

    C. van Uijen

    Lighting DAPConsumer Electronics

    Medical Systems

    Corporate

  • Key figures

    A global, leading technology center • Founded in 1968

    A multinational highly qualified workforce of more than 1100 people (+ 150 temporary employees) • University degree ± 700 • 6 professors, 135 PhD. • Bachelors & Engineers ± 400 • Other type of education ± 100

    Sales 2005 • EUR 144 million • 80 % internal sales; 20 % external sales

    Worldwide representation • 6 Locations spread over North America, Asia Pacific

    and Europe

    Eindhoven San José Pittsburgh Singapore Bangalore Redhill

    Contents

    Short introduction speaker SPI (top-down approach)has come to its end? Agile documentation Agile Experiences from Philips

    Benchmark Agile Tooling

    Q&A

  • Agile silver bullet?

    DVD development

    Never 45%

    Rarely 19%

    Sometimes 16%

    Often 13%

    Always 7%

    Are all the requirements used?

    Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002

    ALL CODE CR/PR's of DXC / Nurnberg / Redhill

    0

    500

    1000

    1500

    2000

    2500

    31 7

    31 9

    32 1

    32 3

    32 5

    32 7

    32 9

    33 1

    33 3

    33 5

    33 7

    33 9

    34 1

    34 3

    34 5

    34 7

    34 9

    35 1

    40 1

    40 3

    40 5

    40 7

    40 9

    41 1

    41 3

    41 5

    41 7

    Weeks

    O pe

    n/ C

    lo se

    0

    20

    40

    60

    80

    100

    120

    140

    160PMIOpen Closed PMI Wish PMI

    Lots of PR’s/CR’s to handle

    Teamwork, Achievement and Hazards

  • KEY MESSAGES

    Software Process Improvement (SPI) as we know it today has come to its end Need of courage to rethink 1) Drill down to the context - "Think it all" 2) Improvement-in-the-small - "Keep thinking"

    This leads to a so called "Innovative Leap" 1) 8x faster, 3.5x better, 4.9/5 customer satisfaction 2) Lots of process optimitizations during the project

    and not only after

    LIFE IN THE 1990's

    Come on, let' s show you something interesting !

    Sorry, got no time. I've got to work!

    Software Process Improvement

    Fact corner: A good process will result in good products

  • BENEFITS OF SOFTWARE PROCESS IMPROVEMENT RETHOUGHT

    Still, SPI is fairly expensive $11000-$53000/ single engineer (Jones,1997)

    1000+ studies in the IEEE database alone 0.21% of these

    studies show Some concrete ROI Figures (van Solingen, 2004)

    Moreover, 70% of the process improvement projects fail (SEMA, 2002)

    IMPROVEMENT MODELS

    Source: http://www.software.org/quagmire/, Aug-2005

    Fact corner: If you know which one to take?

  • Source: Software Engineering Institute, March 2005

    SW-CMM 2000-2004, 60% are Non-USA companies

    IMPROVEMENT IN CALENDAR TIME

    20 months (1-->2)

    19 months (2-->3)

    25 months (3-->4)

    Software Engineering Institute's data shows that process capability improvement takes

    6.5 years (level 5) or 3.25 years (level 3)

    No data on capability levels vs. Business success

    13 months (4-->5)

    Business success?

    Source: Software Engineering Institute, March 2005

  • The semi market for iDTV products

    iDTV: emerging market, many players trying to get in

    Fast changing Specs, Fast TTM, Every 12 months new System

    High SW re-use, High productivity needed

    Lower SW dev. budget & move to ISVs

    Highly optimized SW (very expensive)

    Software continues to grow exponentially (Like # transistors in ICs !)

    iDTV: yet low market volumes, Market doesn’t pay (much) for SW (It’s the square mm that counts!)

    Low cost prices for ICs (limited CPU power, limited memory)

    Fact corner: We don’t have 5 years

    Mgt view on Software

    What are all these

    Software guys Doing?

    SW is always on the critical path

    So inflexible! I was told that

    software is easy to change

    I don’t want large platforms, I need

    products

    They are only costing money and

    don’t bring any !

    Software is an immature discipline

    Let us simply outsource software

    Fact corner: Huge need for faster Improvement – How? see next slides

  • 0

    5

    10

    15

    20

    25

    30

    35

    40

    45

    1 2 3 4

    Project 1 Project 2 Project 3 Project 4 Project 5

    What is working in the process? 342 positive remarks in the process..

    # two-week work cycles

    Fact corner: SPI people seldom know what is going well!

    # of positive issues

    What is working in the process? This document is a report of the reflection on the SmartInstall project until 8/11/2006. The

    idea is to gather what is going well, what needs improvement and what steps to take.

    Keep this • Flexible purchasing.

    The team requires various hardware items and we directly ordered and bought the items we need.

    • Experienced team It is an experienced team in the area of Motiva, java en Linux. Especially Linux knowledge is essential in this

    project.

    • Planning via PAT tool The PAT tool provides a good mechanism to plan, track and manage all tasks to be executed.

    • Weekly team meeting The weekly team meeting is useful to discuss progress, plan next week and problems we hit.

    • Flexible with requirements Team is flexible in changes to requirements from Nicoline’s team.

    • Good understanding between disciplines Good communication between development team and HCS team resulting in a good cooperation.

    • Concept definition is clear The extensive architecture document and the user scenarios have resulted into a clear starting point of the trial

    implementation.

    • Expert consultancy Use of external consultancy, like David, Rob and Peter.

    • Multiple IPs generated Using a problem solving approach

  • What is not working in the process?

    282 problems in the development process…

    # two-week work cycles

    0

    5

    10

    15

    20

    25

    30

    35

    40

    45

    1 2 3 4

    Project 1 Project 2 Project 3 Project 4 Project 5

    Fact corner: 5 projects: 8 week development cycles w/ 10 person months effort

    # of negative issues

    What is not working in the process?

    Ongoing problems

    • Purchase process not suitable for agile projects -> Escalate To many people involved requires additional communication/effort takes to long

    • No transparency on delivery Actual products not cheaper (although additional hours are spend).

    • When bypassing purchase (by direct purchase by team members), the team members have to pay personal the purchase

    • Projects tracking features missing in PAT. Features like good prints of overview, written hours per week for overall project

    • IP responsiveness to low

    • Improve progress reporting

    • Availability program management.

  • 0

    5

    10

    15

    20

    25

    1 2 3 4

    Project 1 Project 2 Project 3 Project 4 Project 5

    Concrete actions taken 158 improvement actions, 70 "pure" spi actions

    # two-week work cycles

    Fact corner: Without actions-in- the-small things will not "really" improve

    # of improvement actions

    Try this • Inventory equipment needs done sooner

    The ordering and delivery task much more (lead)time than expected. Solution was to get going earlier already in the

    concept phase • Buy assembled and working products instead of the components

    The hours spend to assembly the computers highly exceeds the actual hardware coast, because various unexpected

    problems were hit. Solution is to buy assembled and working computers. • Daily standup team -> ALE

    Introduce daily standup meeting with team members (including HCS members) to discuss progress last day and plan

    coming days. • Set clear goals task/stories/deliveries -> ALE

    With current plan it is not clear who is responsible for integration and finalizing the implements to be ready on a milestone.

    • Organize