Upload
horace
View
33
Download
1
Tags:
Embed Size (px)
DESCRIPTION
T-76.4115 Iteration Demo. Neula I1 Iteration 12.12.2008. Agenda. Introduction to the project. We are creating gadgets…. … For which Suunto’s goals are…. … Which means that our key issues are…. Increased u sability Value for customers. - PowerPoint PPT Presentation
Citation preview
T-76.4115 Iteration Demo
NeulaI1 Iteration
12.12.2008
Agenda
2
Introduction - Our key issues
Status of the iterations goals and deliverables
Technical Overview and Demo
Resources and progress
Quality status
Changes to the project
Risks
Other results of the project
Introduction to the project
3
Increased usability
Value for customers
Brand recognition
Enabling external development
… For which Suunto’s goals are…
… Which means that our key issues are…
Understanding the customers – Suunto and its users
Understanding possiblities for sports web 2.0
High level of collaboration – as external developers
We are creating gadgets…
4
Introduction - Our key issues
Status of the iterations goals and deliverables
Technical Overview and Demo
Resources and progress
Quality status
Changes to the project
Risks
Other results of the project
Status of the iteration’s goals and deliverables
5
3 gadgets with working functionality
5 Gadget prototypes
10 more prototype descriptions
Course documents
Implement the quality assurance measures
Implement the project management measures
Learning the platforms
Platform documents
Decisions with Suunto
2 new gadgets
Goals Difficulties and decisions Status
2 Gadgets that will be developed to commercial
Being reviewed by Suunto
Platform documents
2 new gadgets:
1 new platform, 1 new gadget
3 new prototype descriptions
Difficulty of gadgets
Done Progress report
6
Introduction - Our key issues
Status of the iterations goals and deliverables
Technical Overview and Demo
Resources and progress
Quality status
Changes to the project
Risks
Other results of the project
Technical Overview and Demo
A1
Architecture
Demo
A2RelayChallenge Facebook
SimpleMeter iGoogle
1. Functional view
1. Parts and interconnections
2. Development view
1. Class diagram
Architecture
Demo
1. Functional view
1. Parts and interconnections
2. Development view
1. Class diagram
JavaScript source code
External data interface
My Suunto
My Suunto
DB
API
iGoogle Canvas
Application A1:SimpleMeter
Application server
Google DB
User
Brow
ser
Browser
ImagesStyle Sheets
Hosting of
Functional view
LoggingView ViewCommonsSimple Meter View
SimpleMeter
Engine
LanguageUtils
Database Accessors
Google DB
Use
Simplemeter Preferences
APIGoogle
DB
My Suunto
DB
API
My Suunto
Development view
Simple MeteriGoogle
Demo A1
Technical Overview and Demo
A1
Architecture
Demo
A2RelayChallenge Facebook
SimpleMeter iGoogle
1. Functional view
1. Parts and interconnections
2. Development view
1. Class diagram
Architecture
Demo
1. Functional view
1. Parts and interconnections
2. Development view
1. Class diagram
User interface
External data interface
Facebook user data
My Suunto
My Suunto
DB
API
Application server
Application A2:Relay challenge
A PI
Browser
DB
Shown in
User
Browse
r
Functional view
HTTP GET/POST
Mapper
Actions Pages
Permission/logic
Managers
Connectors
Suunto
DBNeula
DB
DB
Databases
Connectors
Managers
Controllers
The Relay ChallengeFacebook
Demo A2
15
Introduction - Our key issues
Status of the iterations goals and deliverables
Technical Overview and Demo
Resources and progress
Quality status
Changes to the project
Risks
Other results of the project
Earned value of development work compared to the initial goals of the project
16
Total hours realized for the whole team (week 49): 825 out of 1494
Total development hours: 322,5 out of 624
Used hours
Team totals
Developers
Tasks
18
The planned total development hours was 567
We have a total of 624 development hours
We have been able to minimize
non-productive work.
Development workPlanned Realized
322,5 / 624 development hours used 2 gadgets of working functionality.
10% decrease in work load 4 working quality gadgets.
3 commercial quality and 1 working functionality?
20
Introduction - Our key issues
Status of the iterations goals and deliverables
Technical Overview and Demo
Resources and progress
Quality status
Changes to the project
Risks
Other results of the project
Development Process and Quality• Simultaneous development of autonomous tiny applications• Three predefined qualitative levels of quality as a custom
framework
Prototype Description
(Level 0)
Prototype(Level 1)
WorkingQuality
(Level 2)
Commercial Quality(Level 3)
RequirementsCycle
Customer Feedback
Delivery
PlatformLearning Coding Testing &
UI finalizingInnovating
Main Focus
Current Quality PaletteQuality Goal vs. Quality Practice(effect 1 - 3)
QG 1Compatibility
QG 2Layout
QG 3Usability
QG 4Localization
QG5Innovativeness
QG 6Exploration
QG 7Variety
Unit testing X 1Test cases X 1 X 1 X 1Explorative testing X 2 X 2 X 2 X 1Coding standards
X 1Side-by-side programming X 3 O 2 O 3 X 3Code reviews X 2 O 2Heuristics X 2 X 1Documentation X 1 X 1 X 2General project management X 3 X 2 X 2Dialogue with the customer X 3 X 3 X 3 X 2
Green = Used frequently Yellow = Used time to time Red = Rarely used
Defect Statistics
RelayChallenge (FB)
SimpleMeter
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
Defect breakdown
14%
50%
7%
29%
Overall statistics
MajorNormalMinorEnhancement
• Defect reporting not considered very important at this phase Side-by-side programming and communication helps fixing
minor errors in practice
Code Statistics
• RelayChallenge 2795 lines• SimpleMeter 908 lines
Selected coding standards too narrow and time consuming vs. opportunity cost (in lost development time)
Value-added?
Quality Summary
• Practices have to be value-adding• Preliminary quality plans altered– Unit testing in minor role (web development
limitations)– Test cases will be executed mostly as acceptance
testing leaving integration and system levels debatable
– Defect reporting mostly academic exercise in I1• Coding standards need reviewing
26
Introduction - Our key issues
Status of the iterations goals and deliverables
Technical Overview and Demo
Resources and progress
Quality status
Changes to the project
Risks
Other results of the project
Changes to the project
• Project planning iteration:
• Iteration 1:
27
Brainstorming
Creation of prototype descriptions in the team
Feedback and refining [Meeting]
Discussion and ranking of prototypes
[Development]
New prototype descriptions
Sprint cycle
Iteration cycle
Requirements cycle
Goal discussion
Learning Insufficient
documentation Platforms
New platforms is a priority
Documenting platforms
Commercial quality is the priority
The priority is to complete the A1 and A2 gadgets to commercial quality and develop A3 and A4 to working functionality.
A3: new gadget for Vista
A4: Same gadget for OpenSocial
28
Introduction - Our key issues
Status of the iterations goals and deliverables
Technical Overview and Demo
Resources and progress
Quality status
Changes to the project
Risks
Other results of the project
Risks
29
Customer satisfaction of designs and working practices risks minimized
Sharing of tacit knowledge started and will be continued
More time has gone to learning the technology platforms
The interfaces from Suunto have not been opened yet.
The technology platforms are not documented as well as expected
According to the contingency plan:
1. Goals have been adjusted
2. Schedule has been adjusted to be more flexible
ID Risk Effect How to avoid Contingency plan Responsible Severity Probability at start of project
Probability
R1 The customer is not satisfied with the prototype descriptions
We run out of time because it is too difficult to innovate good enough gadgets
Concentrate on a pre-defined process and rules for the prototype descriptions and the creation of backlog
Set a deadline for new gadget descriptions, demand input from Suunto, begin to implement after the deadline
Paavo Häppölä 5 4 0
R2 Team cannot find common ground for communications and meeting practices
Time is wasted and we never get to the implementation phase
Start meetings early in the project and discuss the issues
Split team up into smaller parts that have their own meetings. Share responsibility
Riku Seppälä 5 4 0
R3 The documentation is not done properly, the customer is only given source code but no exchange of tacit knowledge is made
The project doesn't benefit Suunto as much as planned
Concentrate on the documentation and ask for feedback from Suunto
Create the documentation after the project is finished.
Riku Seppälä 3 5 2
R4 Communication doesn't work, Suunto doesn't understand what we're doing and we don't know about their requirements
The targets are not met, we deliver an unusable product
Plan enough meetings and send clear descriptions of gadgets to be implemented, not just a description of functions. Engage Suunto in the innovation process
Add meetings to discuss communication issues
Paavo Häppölä 5 5 2
R5 The workload is distributed unevenly
Some members get frustrated and others not engaged. Quality suffers and no one enjoys the project
Have set times for working together and a weekly meeting where everyone has to be present or have a legitimate reason for not being present. Follow up on tasks accomplished and concentrate on scheduling
Remake the teams and delegate more responsibilites
Riku Seppälä 3 4 1
R6 Most of the time is spent for optimizing for the course requirements and not for the actual project outcomes
Customer and project members are dissatisfied
Keep documentation light and let project manager handle the documentation for the course. Everyone doesn't have to be involved, keep everyone up-to-date at meetings instead
Concentrate more on the customer needs.
Riku Seppälä 4 5 4
R7 The needed technologies can not be mastered in time. We are not able to make the prototype descriptons reality
The goals cannot be met Concentrate on what is most important, the important functionalities and leave the most difficult implementations to the end. Don't promise too big.
Go back to the designs and design simpler gadgets. Use more familiar technologies
Eero Palomäki 5 4 5
R8 Important persons from the customer side cannot be reached
Time runs out. The requirements elicitation takes up too much time.
Know when people are present. Use the telephone for communications. Have set practices and deadlines for gathering requirements
Take more control of requirements Riku Seppälä 3 4 1
R9 The technologies and support needed from the client cannot be delivered on time
Time runs out. The development becomes unneccesarily difficult, development effort goes to creating dummy interfaces etc.
Understand the requirements, keep in contact with the IT of Suunto
Lower the goals Eero Palomäki 3 4 5
R10 Used tools and technologies are poorly supported and development becomes difficult
Time runs out. Use well documented and/or familiar tools and technologies
Switch to other tools, lower the goals
Eero Palomäki 5 2 5
R10 Because of implementing the interfaces, we're not able to finish the gadgets
Time runs out. When we get the interfaces, start implementing them right away for the gadgets that have been developed already.
Chnage the goals Eero Palomäki 5 2 3
1 New risk has been identified: Time pressure from implementing the interfaces.
30
Introduction - Our key issues
Status of the iterations goals and deliverables
Technical Overview and Demo
Resources and progress
Quality status
Changes to the project
Risks
Other results of the project
Reflection workshop
• Is there anything that could be done better to help the development work?
• Are the communications working properly?
Key Issues
• A lot of time is spent figuring out how to fit the development to the quality practices
• A lot of time is spent mending the code to the coding standards – but it doesn’t improve readability
Complaints
• To save time for coding, we will not follow the coding standards too rigorously. It doesn’t improve readability of
the code.
• Communications are working very well, the Friday meetings are very good, information flows and everyone
knows what’s going on.
Improvements