Agile in Automotive: Find the right balance. Method Park Consulting

Agile in Automotive: Find the right balance [email protected] [email protected] Method Park Consulting Agile Seminars and Works...
Author: Howard Simmons
12 downloads 1 Views 2MB Size
Agile in Automotive: Find the right balance [email protected] [email protected] Method Park Consulting

Agile Seminars and Workshops

Agile Development in regulated Environment: 13.04.2016 01.07.2016 11.11.2016

Erlangen Stuttgart Munich

German German English

Introduction to Agile Methods 12.04.2016 30.06.2016 10.11.2016

Erlangen Stuttgart Munich

German German English

Expert Workshop: Agile in regulated Environment 09.06.2016

Munich

2

Overview 2-5 to 2-7

Management of functional safety

3-5

SPICE

Production planning

3-8

Functional safety concept

4

Product development: system level

5

HW level

6

SW level

4-9

Safety validation

4-10

Functional safety assessment

4-11

Release for production

7-5

Production

7-6

Operation, service and decommissioning

Concept phase

3-7

Allocation to other technologies

External measures

Controllability

In the case of a modification, back to the appropriate lifecycle phase

ISO26262



Top Management Sales, Marketing,… Product Management

Development

System Development

7-5

Initiation of the safety lifecycle Hazard analysis and risk assessment

Remote Development

Research

what else? 3

Product development

Operation planning

3-6

After the release for production

7-6

Item definition

Automotive SPICE®

„We can‘t be agile. We are bound to SPICE compliance!“

SPICE!

Agile!

5

Evaluation: ASPICE 3.0 – Agile methods

6

Example 1: Process and product quality assurance in agile projects Process and Quality Requirements

QA

Definition of Done for the Release

Peer reviews

Work Product Quality

Process Quality

+ Sprint Acceptance Backlog criteria (Team 1)

Retrospective Sprint Review/Demo

Product Backlog

+ Sprint Acceptance Backlog criteria (Team n)

Sprint Review/Demo Retrospective

7

Example 2: Term „Process“ - 3 levels of abstraction (ASPICE 3.0)

Models for Process Assessment Abstraction from

Methods Abstraction from

Team

The “WHAT” (the goals): [what is to be done, why, and what are the technical dependencies] The “HOW” (the way to reach the goals): [methods, tools, templates, metrics, roles & skill definitions, when to do all this on logical timeline to form specific workflows including process tailoring guidance etc.] The “DOING”: [tailoring, set-up and project performance according to the tailored method] 8

Source: “Clarifying Myths with Process Maturity Models vs. Agile”, Intacs 2014

Example 2: ASPICE Level 3 Standard Process Agile

Traditional

WHAT Quality and Process Department

WHAT Method Database

Standards, Policies, Regulations

VS Adopt

Quality and Process Department

Enforced Time Structure

Fixed roles HOW

Try Inspect Sprint Work Agreement HOW

Team

Sprint Retrospective DOING

Team

DOING

9

“…SPICE and Agile complement each other so practical solutions should combine and exploit both sources” [intacs,2014] Source: “Clarifying Myths with Process Maturity Models vs. Agile”, intacs 2014

SPICE 

Agile 

Wrong Understanding: „Agile means quick and dirty“ „Don´t think, just follow the process“ 10

Functional Safety (ISO 26262)

„I won‘t use agile methods if I can get in jail for doings so! "

ISO26262!

Agile!

12

Safety Lifecycle Overview Defined Role(s) Upfront (Safety) Architecture Defined Tools and Methods

Development

7-6

Operation planning

7-5

Production planning

Documentation Requirements

Production Late Changes are not welcomed

3-5

Item definition

3-6

Initiation of the safety lifecycle

3-7

Hazard analysis and risk assessment

3-8

Functional safety concept

4

Product development: system level

5

HW level

6

SW level

4-9

Safety validation

4-10

Functional safety assessment

4-11

Release for production

7-5

Production

7-6

Operation, service and decommissioning

Upfront Planning

V-Model Development

Allocation to other technologies

Controllability

External measures

Separate Validation

Concept phase

Management of functional safety

Product development

Concept

2-5 to 2-7

Process Assessments In the case of a modification, back to the appropriate lifecycle phase

After the release for production

Predefined Phases

Source: ISO/FDIS 26262-2 – BL18

13

Example 1: V-Model Development

The system development process is based on the concept of a V-model […] Source: ISO 26262-2:2011(E)



V-Model does not mean Waterfall



Iterations are foreseen in the ISO26262

 No contradiction to agile development here

14

Example 2: Safety roles in agile?

New role

Existing role with new skills (Safety Auditor and Project Safety Manager)

As the term “safety manager” is defined as a role (see ISO 26262-1), its assignment can be split between different persons in a matrix organization. Source: ISO 26262-2:2011(E)

• •

However, the Team role in Scrum will not be sufficient Often used terms in agile: • T-Shaped Engineer

15

Example 3: Upfront Planning

The planning of a safety activity shall include describing: a) the objective; b) the dependencies on other activities or information; c) the resource responsible for performing the activity; d) the required resources for performing the activity; Source: ISO 26262-2:2011(E) e) the starting point in time and duration; and (original not highlighted)  Classic project planning  Maybe mitigated by defined iterations and regular activities within the iterations. But still doesn‘t fit well. BTW: In agile we have persons. Not resources. 16

Agile vs. ISO 26262

ISO26262!

Agile?

Craftsmanship helps to get the balance

17

System Development

„Agile works for software development, but we create systems here!"

System!

Agile!

19

Typical System Topics

Prepare Production

Release Planning

System Validation (e.g. durability tests)

System Integration

HW-SW-Mechanic Interfaces

Development

Supplier Selection -

Purchasing and Supplier Mgmt. 20

Example 1: Supplier Selection Traditional: Technology Evaluation

Technology Selection

Supplier Evaluation

Supplier Selection

 Late interaction with purchasing  Information gets lost between Development and Purchasing  Often time pressure More agile:

Technology Evaluation

Supplier Evaluation

Technology Selection

Supplier Selection

 Purchasing is involved in the earlier phases  Establish working interaction with supplier 21

Example 2: System Validation

• Several types of tests can not be performed iteratively • Durability Tests (lifetime tests) • Test drives on specific tracks • Production tests + Suitable Tools and Processes need to be in place + Good Test Documentation is required Some mitigations:  Early test design „Test first“  High Interaction / communication between development and test  Test simulation and automation where possible

22

Agile and System Development

System?

Agile?

23

What else?

Large Scale Organizations

Top Management Sales, Marketing,… …

Product Management

Development

Remote Development

• Hierarchies, Command and Control • Politics (incl. Budget and Resource Fights)

Research

25

Being a supplier

Fixed Quality?

Fixed Quality „Quality is a standard, not a variable“

vs.

Traditional

Fixed Time

Fixed Functions

Flexible Time

Change requests after the last responsible moment Unpredictable interaction and escalations Short term requests directly to developers

Agile

or

Flexible Functions

Decide at the last responsible moment

vs.

Frequent and early interaction Discipline (e.g. undisturbed sprints, SPOC,..)

26

Culture: Schneider Culture Model „We succeed by working together“

Reality oriented

Diversity

CONTROL Predictability

COLLABORATION

Process Stability Order

People Affiliation People oriented

„We succeed by getting and keeping control“

Partnership

„We succeed by growing people who fulfil our vision“

Hierarchical Standardization Security Power

Company oriented

„We succeed by being the best“

COMPETENCE Dedication

CULTIVATION

Craftsmanship Possibility oriented

Be the Best Expertise

27

Source: http://agilitrix.com

Conclusion

ISO26262 

System 

Agile 

SPICE 

28

Agile im regulatorischen Umfeld Lösungen für komplexe Setups

29

Method Park bietet Ihnen: •

• • • •

Beratung zur Kombination von agilem Vorgehen mit Standards und Normen (ISO 26262, ISO 15504, CMMI oder IEC 62304) Evaluation und GAP-Analysen agiler Prozesse Consulting und Coaching beim Roll-out agiler Praktiken Unterstützung bei der Tool-Auswahl, Anpassung und -Evaluierung Angepasste Trainings und Seminare zur Einführung agiler Methoden in Ihrem Umfeld

30

OUR PHILOSOPHY IS SIMPLE AND SHORT „ENABLER FOR INNOVATIVE SOFTWARE & SYSTEMSENGINEERING.“

31