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