eXPERT Best practices30 June - 2 July 2003
eXPERT in Rila Solution
30 June - 2 July 2003
Contents
30 June - 2 July 2003
Adopting Expert
Modifying current process
eXPERT Best practices
30 June - 2 July 2003
Phases
30 June - 2 July 2003
Diagnose Phase
Goals - find out the major factors influencing most the project management activities according to the already completed company projects
Outcomes - questionnaire for the Rila employees
eXPERT Best practices
30 June - 2 July 2003
Analysis Phase
Goals - to understand the changes needed in the Rila process and impact of the eXPERT in the company structure
Outcomes - differences between established processes and procedures and the eXPERT approach
eXPERT Best practices
30 June - 2 July 2003
Design Phase
Entirely based on the Gap Analysis from the previous phase
eXPERT Best practices
30 June - 2 July 2003
Implementation Phase
Applying all the changes in the Rila process
Outcomes – tailoring guide for all of the staff members on the new development process
eXPERT Best practices
30 June - 2 July 2003
Pilot Project
30 June - 2 July 2003
Starting the Pilot Project
30 June - 2 July 2003
Pilot Project Overview
30 June - 2 July 2003
Training the Staff
30 June - 2 July 2003
Evaluating Customer Stories
Extracting customer requirements
eXPERT Best practices
30 June - 2 July 2003
Planning the Game
30 June - 2 July 2003
Development
30 June - 2 July 2003
XP Practices
Small Releases
Simple Design
System Metaphor
Continuous Integration
30 June - 2 July 2003
Pair Programming
30 June - 2 July 2003
Refactoring
eXPERT Best practices
30 June - 2 July 2003
PROBE Results
very small
very small
30 June - 2 July 2003
Effort Results
276
238
348
312
284
254
Effort
Date
Start
Stop
Zdravko &Dobri
Acceptance Testing
20/01/2003
14:30
15:05
0:00
0:35
Code
3
Implementation
Penko Ivanov
Effort recording log. There is no place to enter the number of CR that we are working on.
The CR# must be in a separate column, not on the top of the list. This reducess the paper work.
2
23/01/2003
Penko Ivanov
Defect recording log. There is no place to enter the number of CR that we are reporting defect
The CR# must be in a separate column, not on the top of the list. This reducess the paper work.
3
23/01/2003
Penko Ivanov
Working in pairs from the XP methodology. When both from the pair goes to "deadlock"
It is better the two developers to work separately on the problem. The time for solving the problem is equal to the the time the first one solves it.
4
23/01/2003
Dobromir Zahariev
A new template for describing the additional tool used during development should be introduced
PROBE 1
CR ID
CR TYPE
0
0
0
0
0
0
Productivity
0
0
0
30 June - 2 July 2003
Effort Deviation
Zdravko &Dobri
Acceptance Testing
20/01/2003
14:30
15:05
0:00
0:35
Code
3
Implementation
Penko Ivanov
Effort recording log. There is no place to enter the number of CR that we are working on.
The CR# must be in a separate column, not on the top of the list. This reducess the paper work.
2
23/01/2003
Penko Ivanov
Defect recording log. There is no place to enter the number of CR that we are reporting defect
The CR# must be in a separate column, not on the top of the list. This reducess the paper work.
3
23/01/2003
Penko Ivanov
Working in pairs from the XP methodology. When both from the pair goes to "deadlock"
It is better the two developers to work separately on the problem. The time for solving the problem is equal to the the time the first one solves it.
4
23/01/2003
Dobromir Zahariev
A new template for describing the additional tool used during development should be introduced
PROBE 1
CR ID
CR TYPE
Productivity
0
0
0
30 June - 2 July 2003
Productivity
Zdravko &Dobri
Acceptance Testing
20/01/2003
14:30
15:05
0:00
0:35
Code
3
Implementation
Penko Ivanov
Effort recording log. There is no place to enter the number of CR that we are working on.
The CR# must be in a separate column, not on the top of the list. This reducess the paper work.
2
23/01/2003
Penko Ivanov
Defect recording log. There is no place to enter the number of CR that we are reporting defect
The CR# must be in a separate column, not on the top of the list. This reducess the paper work.
3
23/01/2003
Penko Ivanov
Working in pairs from the XP methodology. When both from the pair goes to "deadlock"
It is better the two developers to work separately on the problem. The time for solving the problem is equal to the the time the first one solves it.
4
23/01/2003
Dobromir Zahariev
A new template for describing the additional tool used during development should be introduced
PROBE 1
CR ID
CR TYPE
Productivity
0
0
0
0
30 June - 2 July 2003
Defects Rate
Zdravko &Dobri
Acceptance Testing
20/01/2003
14:30
15:05
0:00
0:35
Code
3
Implementation
Penko Ivanov
Effort recording log. There is no place to enter the number of CR that we are working on.
The CR# must be in a separate column, not on the top of the list. This reducess the paper work.
2
23/01/2003
Penko Ivanov
Defect recording log. There is no place to enter the number of CR that we are reporting defect
The CR# must be in a separate column, not on the top of the list. This reducess the paper work.
3
23/01/2003
Penko Ivanov
Working in pairs from the XP methodology. When both from the pair goes to "deadlock"
It is better the two developers to work separately on the problem. The time for solving the problem is equal to the the time the first one solves it.
4
23/01/2003
Dobromir Zahariev
A new template for describing the additional tool used during development should be introduced
PROBE 1
CR ID
CR TYPE
0
0
0
0
0
0
Productivity
0
0
0
30 June - 2 July 2003
Release Indexes
Date
Version
Description
Author(s)
Reviewers
17.1.2003
0.1
Creation
- Not applied
- Partly applied
- Totally applied
When they are not applied or partly applied an explanation is needed telling the reason for it
Baseline Metrics
Only to be filled when these metrics were collected by the companies in the baseline project
These 2 columns are only for graph purposes. The values have to be the same as in the first column.
Type of Metric
months
1
1
1
0%
0%
0%
0%
0%
0%
Pilot Metrics
For explanations of the metrics, please refer to the document WP10 planning. Doc
ETSA
CBT
Divisa
Freiheit
Megatel
Nemetschek
Rila
Metric
1.517
6.1
6
Total: Effort 4 man months / 24.1 KLOC; For the iteration 2 man months 11.9 KLOC
4
Total: Effort 6 man months / 32 KLOC; For the iteration 2 man months 8 KLOC
Defect Rate
16
-10.3%
-10.5%
Relative project cost change
0
0
0
13.1
Baseline cost 13566 Euro, effort 6 Manmonths. Release 1 cost 13869, effort factor = 0.85
13.2
13.7%
10.3%
10.5%
Customer satisfaction
Developer satisfaction
Leire Orue-Echevarria: These values are only for example purposes
Leire Orue-Echevarria: These values are only for example purposes
Leire Orue-Echevarria: These values are only for example purposes
Leire Orue-Echevarria: Reading again the EC Review I have come up to this comment the reviewers wrote in the report (point number (16)): "... it has also to provide with a benchmarking analysis to compare benefits of Expert vis a vis current methods and tools. " and also (to be found under "SUMMARY OF REVIEWERS' RECOMMENDATIONS AND CONCLUSIONS") "...Make sure that the eXPERT approach can be easily implemented by SMEs in outlining the "easy to use", the low cost of entry, the value of the investment on the long run "
Graphs
Graphs
1
1
2
2
3
3
1
0
2
0
3
0
Not applied
The user stories are not collected as such from the customer. Divisa collects the customer Requirements that are written in a document that the customer agrees on. The project at Divisa is divided into Tasks. It could be considered that one Task equals on
Not rated
Partly applied
Developers capture user requirements and describe them into the Word document which provide to the customer to approve his own wishes.
Customer on Site
Not applied
The customer is not at Divisa. Monthly, there is a meeting between Divisa and the customer where the customer sees the progress of the project.
Partly applied
The customer is not present at the team office during the development. Evidence is that despite the permanent access to the recent version of the product, provided by the developer, customer never used the possibility to initiate a comment or recommendati
Partly applied
Simple Design
Fully applied
Not rated
Fully applied
Coding Standards
Fully applied
The coding standards are used by means of the tool JavaDoc
Fully applied
The coding standards were developed before the eXPERT project, but formalized within its application.
Fully applied
Fully applied
Rila has its own document of Coding standards as suggested by the ISO 9001
Collective Code Ownership
Partly applied
The code to the core system is now open to every member of the team. Before it was restricted to the two people that initially developed it.To keep track of the versions and the modifications, a Configuration Management Tool is used, and exactly CVS.
Fully applied
Fully applied
Pair programming
Partly applied
This is only applied in 10% of the whole project. Prior to the pilot project, this practice was applied only in certain tasks to improve the performance of a certain function. However, now it is only used if they want to promote a junior or less qualifie
Fully applied
Partly applied
Pair programming was applied in part of the time, mainly during the design phase, while in performing the main programming tasks developers mainly work alone
Partly applied
Pair programming was applied in part of the time, mainly during the design phase, while in performing the main programming tasks developers mainly work alone.
Refactoring
Partly applied
Refactoring is only applied when the customer’s specification was misunderstood or to optimize the performance.
Fully applied
Fully applied
Fully applied
In order to facilitate the refactoring process developers' team use tool C# refactoring.
Open Workspace
Not applied
Fully applied
Fully applied
Team consider that because of the availability of the open workspace there is no need of the special stand-up meeting.
40 hour/week
Not applied
Fully applied
Partly applied
In order to finish development on tasks on time from time to time that practice is not applied.
Unit Test
Partly applied
The unit tests are performed but not in an automated way. They do not keep a checklist of all the unit tests performed, although during the integration of the code, all the unit tests that the programmer remembers are performed.Their testing ranges from G
Fully applied
Partly applied
NUnit is used for performing the unit tests. The tests are performed regularly, but in case of the multilevel architecture of the component, because they are very slow, developers prefer to run them ones per day. In case of errors they are using the hist
Fully applied
NUnit is used for performing the unit tests. The tests are performed regularly, but in case of the multilevel architecture of the component, because they are very slow, developers prefer to run them ones per day. In case of errors they are using the histo
Acceptance Test
Partly applied
The acceptance tests are designed by Divisa themselves. The customer does not participate on designing them.
Fully applied
Partly applied
Partly applied
Describe acceptance tests respective to all customer requirements, but does not implement test cases corresponding to the described acceptance tests and not check product functionality through them.
Metaphor
Not applied
Not rated
Fully applied
Team declare that use it but it is difficult reviewers' team to confirm.
Small Releases
Fully adopted
Monthly a released is out and shown to the customer
Fully applied
The team develops the product in small releases but seams not to measure and to use effectively enough the data gathered through these releases.
Fully applied
Continuous Integration
Partly adopted
The code is integrated monthly, prior to the release date.
Applied
Partly applied
The integration is done once or more times per day. There is one computer on which the integration of the product is performed, and where the latest integrated and working version of the application can be found. Visual Studio and Source Safe are used int
Fully applied
PSP Principles
Applied
Not estimated as described in the eXPERT approach. the staff applies other means to record time measures, which are simpler – time spend per person on development was recorded each day on the MS Project file plan, as well as each developer wrote time spen
Fully applied
PROBE method is already applied. Measures are done in form different from described in eXPERT approach – time spend per person on development was recorded each day on the MS Project file plan, as well as each developer wrote time spend on working over ea
Effort estimating
Not applied
Coding Standards
Not applied
Fully applied
Fully applied
Defect logs
Fully applied
Not logged
Partly applied
Team uses bugzila for producing defect logs and does not use defect logs sheets (proposed in eXPERT approach).
LESSONS LEARNT
Review 1
Review 2
Review 3
Review 1
Review 2
Review 3
Review 1
Review 2
Review 3
Review 1
Review 2
Review 3
Review 1
Review 2
Review 3
Review 1
Review 2
Review 3
Review 1
Review 2
Review 3
The staff seems to accept the eXPERT processes and to apply them. The main exception is logs, even in the form they are suggested by eXPERT approach. They are considered by the staff as cumbersome and controversial to the general ideas of XP. The reviewer
The application of eXPERT approach leads to closer collaboration between developers, which leads them to see the whole picture better. That makes them feel better about the project success chance and makes the feel better about eXPERT approach creating p
In SME’s with processes comparable with Rila process other eXPERT approach expected benefits are the reduced number of documents and the time for feedback. At least because of the latter, the time for the whole project development is expected to be reduce
The customer is motivated, but not prepared for a really active participation, as recommended by XP. Evidence is that despite the permanent access to the recent version of the product, provided by the developer, he has never used the possibility to initia
Collecting the data for effort spend and the application of the PROBE method provide good results for estimation of time and effort. Metrics and measurements are most difficult part of the application of the eXPERT approach, but as the team notice give th
The project documentation is kept to a reasonable minimum. Automatic generation features are actively used. In this case the documentation is always perfectly updated. Where automatic generation is not possible two versions of the documentation are planne
Applying the eXPERT approach decrease time and effort spend on design. The defect logs showed that applying eXPERT approach lead to reduction of the errors in later project phases and finally to reduction of the total time of the development. The defect r
The SMEs, who plan to apply eXPERT approach, could remind some of the steps in Rila experiment as example. They could repeat at least two of them: · to identify whether they really need the eXPERT approach (could use similar or the same as Rila’s question
The staff members appreciate the advantages of pair programming but applying them for small and simple tasks make these advantages under question. Similar is the situation with writing and performing unit tests – are they in all cases necessary or there a
Changes/improvements to eXPERT approach: 1. In any case logs show be done not on the paper. 2. Design inspection could be skipped
It is not easy to apply all recommended practices at once without transitional phase where a mixture of old and new ones exists.
If some part the team is already trained then training of the new developer(s) to be add/include to that team could be done on the way.
Orientative questions for overall lessons learnt and future improvements
Management aspect:
- Which metrics are the most important for your company?
- What good practices measurements would facilitate the adoption of the eXPERT approach by managers and customers?
- How much training is needed? How much does it approx. Cost? ROI at long, medium or short term?
- What impact does eXPERT have for management?
- eXPERT in a long-term context
- Which have been tangible gains within your company by the result of applying eXPERT?
Customer related aspect:
- How can be achieved the customer involvement throughout the development process?
- Is necessary an on-site customer or can a remote customer still have good communication with the developers as if he were an on-site one?
Technical issues:
- Which tool supporting the eXPERT approach would be (has been) the most suitable one?
- Which documents that are obviated with the eXPERT approach are essential, useful or necessary?
- Which are the negative aspects and positive aspects that eXPERT has brought to your company?
- What should be improved within the eXPERT approach for a successful application of it in other companies/developments?
- Is the product more reliable and efficient than if it were developed with the traditional approach?
- What are the advantages of applying eXPERT with respect to traditional methodologies?
- How good is the eXPERT approach for the kind of project, object of review?
Organizational issues
- How agile should an organization be to successfully adopt eXPERT?
People related issues:
- What impact has eXPERT for the personal development of the software engineers?
Critical Success Factors for the project, deployment of usage and implementation of eXPERT
Leire Orue-Echevarria: Question that appears in the EC review report
ETSA
CBT
Divisa
Freiheit
Megatel
Nemetschek
Rila
Relevance
What
High
The companies do not have the measurement of productivity in the baseline project, therefore the calculation of one of the project goals cannot be performed and cannot be determined whether the company succeeded or not
MBD0013FBF3.bin
Sofia
Bulgaria
30 June - 2 July 2003
Tools
30 June - 2 July 2003
Time Tracking System
Company adopted system
Track All Activities preformed by the team members and for all projects
Produce reports
eXPERT Best practices
30 June - 2 July 2003
Business Benefits
Better Discipline
eXPERT Best practices
30 June - 2 July 2003
Skill and Cultural Benefits
Reduced overall effort
30 June - 2 July 2003
Questions
276
348
284
238
312
254
0
50
100
150
200
250
300
350
400
1
2
3
Iteration