Agile Method for Software Development

1

• Agile Method for Software Development

2
Key points

• Objectives for the method
• Method description
• Lessons learnt
• Empirical results

3
Project Objectives

• To define a light approach for e-business and
  e-commerce software development
• To try it out to 7 pilot projects
• To collect and disseminate lessons learnt
• To develop and disseminate a Best Practice
  Toolkit eXPERT method, Case studies,
  Experiments analysis

4
Business Objectives

• To increase the productivity of small teams by
  20
• To reduce defect rates by 30
• To decrease project costs by 15
• To eliminate schedule delays and over costs

5
Target Projects e-Projects

• Must be delivered rapidly
• have critical time constraints
• Requirements evolve constantly
• due to e.g. turbulence in the market, changing
  technologies, etc.
• Mission critical
• if unsuccessful, the business loses new
  opportunities
• Have to be managed flexibly
• and in a result-oriented manner
• Example e-commerce and e-business projects

6
e-Project Success Factors

• Easy and quick integration of people in a team
• Abilities to quickly respond to required changes
• Facilities to maintain good software quality
• Practices easy to adopt and execute

7
eXPERT Development Approach

• Reports from the field
• productivity and software quality increase by
  applying XP principles
• even projects that have adopted several or all XP
  practices meet project management problems,
  related to estimating and planning
• gt focus on XP and PSP practices

8
eXPERT Development Approach

• Develop Faster-Better-Cheaper

9
eXPERT Development Approach

• Based on processes for easier compatibility with
  other models like CMM(I) and ISO
• Maintain the method
• comprehensible,
• motivating and
• easy to apply,
• but provide means for
• good estimations,
• project planning and
• management activities.

10
Key points

• Objectives for the method

?

• Objectives productivity, defects, schedule,
  costs
• Target projects e-projects
• XPPSP lightweight and manageable

Method description Lessons learnt Empirical
results
11
XP Practices

• Planning game quickly determine the scope of the
  next release, combining business priorities and
  technical estimates
• Small releases put a simple system into
  production quickly, release new versions on a
  very short cycle
• Metaphor guide all development with a simple,
  shared story of how the whole system works
• Simple design design as simply as possible at
  any given moment

12
XP Practices

• Coding standards rules emphasizing communication
  throughout the code
• Testing continually write unit tests which must
  run flawlessly customers write tests to
  demonstrate functions are finished
• Pair programming all production code written by
  two programmers at one computer
• Refactoring restructure the system without
  changing behaviour to remove duplication, improve
  communication, simplify, or add flexibility

13
XP Practices

• Collective ownership anyone can change any code
  anywhere in the system at any time
• Continuous integration integrate and build the
  system many times a day, every time a task is
  finished
• 40-hour week work no more than 40 hours per week
  as a rule never work overtime two weeks in a row
• On-site customer real, live user on the team
  full-time to answer questions

14
Personal Software Process

• The PSP is a technique that engineers can apply
  to most structured personal tasks to improve
  their
• Predictability
• Quality
• Productivity
• It is designed for individuals and can be
  extended to team development of large-scale
  software systems.

15
PSP Evolution
PSP3 Cyclic development
Team Software Process
PSP2 Code reviews Design reviews
defect management
PSP1 Size estimating Test report
size, resource, and schedule plans
PSP0 Time recording Defect recording Defect type
standard
establishing a measured performance baseline
16
PSP Practices in eXPERT

• PSP0 The baseline process The process
  currently used to write software, but enhanced to
  provide measurements
• PSP0.1 Enhances PSP0 by adding coding standard,
  size measurement and process improvement proposal
• PSP1 The personal planning process The initial
  increment adds test report and size and resource
  estimation

17
PSP Practices in eXPERT

• PSP0 The baseline process
• Time recording
• Defect recording
• PSP0.1
• Coding standard
• Software size measurement
• Process improvement proposal
• PSP1 The personal planning process
• Size estimating with PROBE

18
PROBE method used in eXPERT

• Objective estimate the time necessary to
  implement each Customer Requirement (CR)
• Steps
• Gather historical data (CR type, complexity,
  implementation time)
• For CR type calculate Average implementation time
  and Standard deviation
• Calculate Range for implementing CR of particular
  type and complexity
• Estimate new CR exp(Range) for the respective
  type and complexity

19
Estimation with PROBE example
20
Software Process

• Source CMM

21
eXPERT Architecture
Customer Requirements Management
22
eXPERT Process Components

• Overview (objectives)
• Inputs
• Activities
• Process outputs
• Completion criteria
• Measurements

Process
23
Examples
Format
Example
24
Roles

• Customer chooses what will deliver business
  values, prioritises requirements and defines the
  acceptance tests.
• Project manager leads everyday work, resolves
  schedule conflicts, communicates with
  stakeholders, collects data related to the
  project performance and analyses them
• Developer estimates requirements complexity and
  effort to implement them, builds the system, and
  keeps it integrated

25
Customer Requirements Management (CRM)

• Overview This process includes all activities
  related to eliciting, analysing and controlling
  the customer requirements for a software product.
  It builds on the XP practices related to handling
  user stories.
• Input Customer needs and expectation
• Output Prioritised CR with complexity and time
  estimations

26
CRM

• Completion criteria
• Customer requirements are granulated to such an
  extent that each of them is estimated to be
  developed in less than 2 weeks
• The whole team understands well the customer
  requirements
• The CR described on the CRC cards are testable
• Measures Effort spent on CRM

27
CRM

• Activities
• A1. Elicit CR (schedule, document, explain to the
  team)
• A2. Analyse CR (categorise, investigate
  implementation constraints, assess risks,
  estimate complexity)
• A3. Estimate CR (estimate time with PROBE,
  prioritise)
• A4. Measure the process

28
Hints for CRM

• Document only needed information.
• Use tools facilitating CRM (CRC cards could be
  lost)
• Use tools facilitating process measurement
• Good communication with the customer is key for
  the success

29
Tools supporting CRM

• XPlanner www.xplanner.sourceforge.net
• Spreadsheet facilitates PROBE calculations
• Project management tool

30
Project Management

• Overview The project management process
  encompasses activities related to planning,
  tracking and controlling the software
  development. Project management includes
  activities that ensure the delivery of a
  high-quality system on time and within budget.
• Input Documented Customer requirements
• Output Iteration (and release) plans

31
Project Management

• Completion criteria
• Project maintained on track, i.e. iterations
  executed as planned
• Measures
• Effort spent on PM
• Project costs
• Project velocity
• Resource usage

32
Project Management

• Activities
• A1. Define the Project (people and environment)
• A2. Create Iteration and Release plans
• A3. Monitor and control the project (daily
  meeting, track progress and costs, update plan,
  report to management)
• A4. Conclude project
• A5. Measure the process (resources, effort,
  scope, velocity)

33
Hints for PM

• Focus on the requirements for the current
  iteration
• Use tools facilitating planning tracking
  activities and process measurement
• Good communication with the customer is key for
  the success
• Avoid multi-tasking
• Avoid handsoff

34
Tools supporting PM

• XPlanner www.xplanner.sourceforge.net
• Project management tool
• Spreadsheet facilitates resource planning and
  tracking

35
Design

• Overview During the design process the customer
  requirements are decomposed into product
  components.
• The design process is highly interrelated with
  the Code and Test processes.
• Input Documented CR
• Output Coding standard CR with design
  elements Design document

36
Design

• Completion criteria
• simple design well understood by the whole team
• Measures
• Effort spent on overall design

37
Design

• Activities
• A1. Prepare for design (coding standard, etc.)
• A2. Design
• A3. Document design
• A4. Measure the process

38
Hints for Design

• Do simple design
• Focus on the requirements for the current
  iteration (avoid extra features)
• Consider refactoring in the beginning of a next
  iteration.
• Create useful documents and do not spend time on
  making them look more beautiful

39
Code

• Overview The objective of the Code process is to
  produce the code of the software product that
  satisfies the customer requirements. The code is
  permanently maintained in good condition, i.e. in
  reusable, testable and working state.
• The coding process is highly interrelated with
  the Design and Test processes.
• Input Documented CR with design elements
  Coding standard
• Output Software product

40
Code

• Completion criteria
• Customer requirements and acceptance tests
  satisfied
• Measures
• Implementation effort
• Developers productivity
• Pairs productivity

41
Code

• Activities
• A1. Implement product in a test-driven manner.
• A2. Refactor code.
• A3. Integrate often.
• A4. Measure the process (implementation effort)

42
Test Driven Development

• Brainstorm possible test cases
• Implement the test cases using an incremental and
  iterative approach (1 at a time and implement it
  immediately)
• Implement code. Do not write more code than the
  test requires (additions would be unspecified and
  not test-safe)
• Run test cases and improve the code until all
  test cases pass
• The cycle finishes when everything that could
  possibly break is tested.

43
Test Driven Development Problems

• Current test fails although it should pass
• the code just written doesnt satisfy the
  functional requirements
• Old tests start to fail again
• the code just written violates parts of the
  existing functional specification, thus
  introducing unwanted side effects

44
Test Driven Development Problems

• The test passes although it should fail
• the functionality has been realized without a
  test
• the functionality is already tested by another
  unit test
• the test itself is wrong
• the test is in an already tested equivalence class

45
Test Driven Development Problems

• Implementing a test requires new tests
• the chosen increment is too big
• the step takes too long
• an intuitive implementation requires new methods
  and maybe even new objects
• try to prevent a bottom-up implementation, since
  you would be running without feedback for a long
  time

46
Test

• Overview The purpose of the Test process is to
  validate that software product produced meets the
  requirements and satisfy the acceptance criteria
  defined by the customer.
• The Testing process is highly interrelated with
  the Code and Design processes.
• Input Documented CR with design elements
  Coding standard
• Output Code without defects

47
Test

• Completion criteria
• The test cases defined cover all typical,
  boundary, and specific cases described by the
  customer requirements
• Measures
• Defects rate
• Effort spent on acceptance testing
• Defect removal efficiency

48
Test

• Activities
• A1. Prepare for testing.
• A2. Describe and implement acceptance testing.
• A3. Perform unit testing in parallel with coding.
• A4. Perform regression testing when integrating.
• A5. Perform acceptance testing after integration,
  especially before delivery.
• A6. Measure the process (effort, defects)

49
Hints for CodeTest

• Focus on the requirements for the current
  iteration
• Use tools facilitating refactoring and testing
• Integrate often
• Refactor always when necessary, do not postpone
  it.
• Good communication with the customer is key for
  the success

50
Tools supporting CodeTest

• Test case environment
• JUnit/ hhtpUnit/ JWebUnit/ Cactus www.junit.org
• Nunit www.nunit.org
• Test generator JUnitDoclet www.junitdoclet.org
• Refactoring
• CRefactory/ jRefactory- Pretty Printer
• Eclipse www.eclipse.org
• Bug tracking
• Mantis mantisbt.sourceforge.net
• Bugzila www.bugzilla.org

51
Key points

• ? Objectives for the method

• Objectives productivity, defects, schedule,
  costs
• Target projects e-projects
• XPPSP lightweight and manageable

Method description

• Based on XP and PSP principles
• eXPERT architecture
• eXPERT processes

52
Lessons Learnt

• Pair programming
• Is not optimal when the tasks are too small
• It is not util when the experience level of the
  developers is too different
• Recommended for quick integration of new people
  (the integration time decreases with about 30).
• Increases the quality of the code
• Problematic when a buddy works on more than one
  projects.
• Increases the productivity of the team.
• Does not descrease the costs automatically.

53
Lessons Learnt

• Test before code
• Maintains the system in working state.
• Increase the quality of the code and the product.
  
• Takes time to get used to it
• Apart from an common Unit Testing Framework other
  tools are necessary (test case generator, code
  formating)
• Refactoring
• It is difficult to change the manner of thinking
  of the developers.
• Postponing it may result in complete redesign.
• Has to be applied to the unit tests too.

54
Lessons Learnt

• On-site client
• Well accepted by the development team, but it is
  preferable that the client has technical
  background.
• How to prepare the client for his new role?
• The client motivation is not enough.
• Collective code ownership
• Increases the code quality
• Very well accepted by the developers.
• It is an implicit code review

55
Lessons Learnt

• PSP time and effort estimations
• It is difficult to get used to record all the
  data
• The benefits in short term are little.
• Is it better than the experience?
• The method
• Needs a period of adaptation
• It is difficult to adopt all the practices at
  once.

56
Lessons Learnt

• Metrics
• Useful for finding potential improvements of the
  development process.
• Increase the precision of the time and effort
  estimations and reduce the delays.
• Increase developers discipline.
• Collecting data about time and effort facilitate
  the project management
• Collecting data has to be automated
• The PSP strictness contradicts XP

57
Key points

• ? Objectives for the method

• Objectives productivity, defects, schedule,
  costs
• Target projects e-projects
• XPPSP lightweight and manageable

Method description
?
? Lessons learnt

• Based on XP and PSP principles
• eXPERT architecture
• eXPERT processes

Empirical results
58
Empirical results

• If the schedule deviation increases, the cost
  deviation increases increses too.

59
Empirical results

• In the majority of the experiments the defect
  rate increased during the first 1 or 2
  iterations, and decreased significantly
  afterwards.

60
Usage of practices

• Review 1

61
Usage of practices
Review 2
62

• Questions?

63
(No Transcript)