Hermes

1
Hermes

• EOSP Summer 2007

2
Agenda
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
?

• Introductions
• The Project
• Main Goals for the Semester
• Proposals and Reflection
• Conclusions
• Demo

2
3
IntroductionsClients Mentors
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• The Client Bosch (Research Technology Center,
  North America)
• Dr. Michael Höynck
• Dr. Charles Shelton
• Mentors
• Grace Lewis
• Dave Root

3
4
Introductions The Team
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
4
5
Agenda
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• Introductions
• The Project
• Main Goals for the Semester
• Proposals and Reflection
• Conclusion
• Demo

?
5
6
Agenda
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• Introductions
• The Project
• Main Goals for the Semester
• Proposals and Reflection
• Conclusion
• Demo

?
6
7
Agenda
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• Introductions
• The Project
• Main Goals for the Semester
• Proposals and Reflection
• Conclusion
• Demo

?
7
8
Summer Plan (1)
XXXX
XXXX
XXXX
XXXX
Sprint 1
Sprint 2
XXXX
Legend
XXXX
Task
Week
XXXX
Reached
Delayed
XXXX
9
Summer Plan (2)
XXXX
XXXX
XXXX
XXXX
Sprint 3
XXXX
Sprint 4
XXXX
Low priority requirements
Legend
Bug fixing
Task
Week
User manual
New Requirements
Reached
Delayed
EOSP Preparation
10
Planning Tracking
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• What we did
• Had estimation for requirements at the beginning
  of the summer
• Refined estimations for tasks at the beginning of
  the sprint
• Used data gathered to adjust planning for
  upcoming sprints
• Used big picture charts to track overall
  progress

10
11
Planned vs. Actual Time
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
11
Planned
Actual
12
Time Spent Per Activity
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
Development
Detailed design
QA Fixing
QA Appraisal
13
Burn Down Chart Sprint 1
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
13
14
Burn Down Chart Sprints 23
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
14
15
Burn Down Chart Sprint 4
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
15
16
How We Monitored The Big PicturePicture At
Beginning Of Sprint 4
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
The Prioritized Picture
The Big Picture
High-Level Requirements
HIGH
MEDIUM
LOW
Hours remaining
lt 1 hour
lt 15 hours
gt 15 hours
TBD in next sprint
16
17
Problem Definition
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
Demo 2 Backlog negotiation
Demo 3 Backlog negotiation
Demo 1 Backlog negotiation
AT 1
AT 2
1 2
3
4
Change Management
Summer semester
4 out of 4 for customer scorecard
AT
Acceptance testing
18
Problem Definition Requirements Achieved
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• Original 79
• Added 11
• High 3
• Medium 5
• Low 3
• Removed 4
• Low 4

18
19
Problem DefinitionReflection
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• Iterative development helped us to fill the gap
  in ideas between our clients and us
• Checking whether each requirement was useful from
  the clients perspective, helped us to build
  trust with the client and enhance client
  satisfaction
• Providing the client with big picture information
  helped us communicate the status of the project
  and gain his confidence when negotiating
  requirements

19
20
Operations
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• Common hours
• Scrum-style management
• Risk management

20
21
OperationsCommon Hours
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• What we did
• Disciplined common hours 9 to 4/5 on weekdays
  and ½ day Saturdays
• Reflection
• Increased our productivity
• Reduced effort spent solving problems
• Helped to share domain knowledge, which is useful
  for reviews
• Provided motivation for team members, and reduced
  procrastination

21
22
OperationsHow We Tailored Scrum (1)
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
Sprint/Product backlog Burn-down charts Stand up
meetings Frequent client interaction
Scrum-style management
Implementation based on QA plan
Bug tracking chart
Task switching
Big Picture
Management of prioritized requirements
TSP-inspired retrospective
Aspects of scrum
22
22
Aspects customized/added to scrum
23
OperationsHow We Tailored Scrum (2)
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• Reflection
• Better communication
• Less planning/tracking overhead
• Overall status provided by the burn down chart
  and the big picture

24
OperationsTop 4 Risks Of The Semester
Hermes EOSP (Summer 2007)
24
24
25
Design
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• What we did
• Followed our architecture for creating design
• Modified the architecture as we learned more
  about
• The generation requirement
• Existing CA
• Graphical Editing Framework (GEF)
• Identified the need for refactoring designs at
  formal inspections
• Reflection
• Design reviews would have reduced the need for
  refactoring

25
26
Quality AssuranceQuality Goals
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
15
1.2
70
79
26
192
All except for GUI code
All
26
27
Metrics Size (from SVN)
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
Sprint1
Sprint2
Sprint3
(LOC Touched)
LOC
LOC Touched
Date
27
Lines touched
Lines of Code
28
Metrics Cost Of Quality
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
hours
defects/hr
28
29
Metrics Defect Priority
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
defects
29
30
Quality AssuranceReflection
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• Peer review process was the most effective
• We found that this was because the peer has
  domain knowledge
• Formal inspection was expensive
• Less efficient because
• Logic was complex
• Demanded deep domain knowledge.
• E.g. graphical framework or geometry algorithms

30
31
Agenda
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• Introductions
• The Project
• Main Goals for the Semester
• Proposals and Reflection
• Conclusion
• Demo

?
31
32
Techniques Used From Core Courses
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
Hermes EOSP (Summer 2007)
32
32
33
Fall Agreement
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• We have agreed on an SOW for Fall
• 6 hours per week per team member
• Team members will spend this time on the
  following activities, in this order of priority
• Complete user documentation
• Fix bugs
• Extend features
• Clarify documentation
• Update technical documentation

33
34
Teams Threshold Of Success
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
34
35
Conclusion
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion

• The team met
• The Clients Picture of Success
• Our Threshold of Success
• 100 of our Quality Goals
• Tailored Scrum proved to be effective for us,
  through a consistent process of metrics and
  reflection
• We achieved all that we set out to do (and more!)
  by having disciplined common hours, many
  re-estimations, and constantly monitoring
  progress

35
36
Client Feedback
Introductions
The Project
Main Goals for Semester
Proposals Reflection
Conclusion
I am really amazed by the teams time
management ability that they were able to meet
almost all of their goals and scheduled time for
a full acceptance test before their final
presentation. The teams planning and
execution has been the best Ive seen from any
MSE student team in all the years Ive worked
with the program.
36
37
Demo
38
Thank you
39
Hours Per Week
40
How We Monitored The Big PictureFinal Picture Of
Project
The Big Picture
The Prioritized Picture
High-Level Requirements
Hours remaining
HIGH
MEDIUM
LOW
lt 1 hour
lt 15 hours
gt 15 hours
TBD in next sprint
41
Stand-Up Meetings
42
Quality slides
42
43
Metrics Defect Tracking
43
44
Final QA Status By Modules
CBOTcovered by other techniques
44
45
Metrics Defect Source
(defects)
Code
Design
Legacy
Requirements
45
46
Metrics Size
46
47
Metrics Defect Yield
47
48
Bug Tracking Chart
48
49
Implementation Life Cycle

• Architecture (from Spring semester)
• Detailed Design
• Peer reviews
• Coding
• Unit testing
• Peer reviews
• Inspections for selected modules
• Testing
• Integration testing
• Acceptance test for each sprint

49
50
The Very Big Picture (10 min)
51
Client management(5 min)

• Requirement clarification
• Exchange emails to clarify requirements
• Change management
• Clarify priorities and negotiate what should be
  done in this sprint
• SOW for fall
• Acceptance test
• Aug. 3rd 3pm-430pm
• Aug. 8th 930am-1100am

52
Status of proposals(5 min)
53
Status of proposals (2)
54
Open Action Items(5 min)
55
Top Risk(5 min)

• We planned acceptance testing at the very end of
  this semester If some tests fail, we wont have
  enough time to fix these bugs.

56
Current topics(5 min)

• Acceptance testing How/when will we decide what
  to test on each day?
• Last status meeting
• EOSP preparation status