Change Process

From GEANT2-JRA1 Wiki

Work in progress

This process is to be used to assess, authorise and schedule a change within the developments.

• Input: a request for change is received (where? and by whom?).
• Output: The specification of the change, its prioritisation, its authorisation and its schedule in the Priority Action Plan and in a release.

Contents 1 Initiate a Change 2 Filter 3 Prioritise a Change 4 Categorise the change 5 Change Assessment - Authorisation - Scheduling 5.1 Standard change 5.2 Low Impact change 5.3 Medium Impact 5.4 High Impact 5.5 text

Initiate a Change

• Who can initiate a change?
  • Anybody (end-users, MDM participants, developers, Service Desk, etc).
• What is a change?
  • A Request for Enhancement, a new tool, a bug fix, a schema extension, etc. Anything that implies a change into the code.
• Where can a change be initiated?
  • Investigate if they can be initiated via bugzilla, or from a form, or as an idea posted on a mailing list and relayed by an observer (JRA1 - who is observing AH?, MDM - NS, perfsonar-dev - ST?, perfsonar-user - LK?)

Filter

• Who Filters?
  • The observer (in charge of the mailing list where the change was raised) or WIL (in charge of the product if change initially raised on bugzilla). They must ensure there is a high level information about the change and explains the rational behind the reques. This will provides sufficient information for the change to progress.

1. The observer must iterate with the requester to clarify the following points.
   • The name of the Initiator (the person who asked or mentioned about the change)
     • The initiator email address
     • The initiator affiliation
     • Indicates if the request is done on behalves of someone else or based on someone else's suggestion.
   • The change name
     • Choose between one of the followin angles to introduce the feature:
       • Problem Statement : Describe what the problem is or what is missing or
       • Feature Description : Describe what the feature does. You can also point to best practices or examples of what you would like to get (give the specific URL).
     • Benefits to the users: Describe the expected benefit for the user(s) (or the benefit for the developers, testes in case this is related to a procedure or an internal change e.g. to the protocol)
2. The observer must also indicates the following information
   • Product(s) : list the products impacted by the changes
     • Optional at this stage: specification and drawing
   • Priority assessment : priority for the change based on the user point of view or the benefit for the project overal (e.g. if this can save some ressources, etc)
     • High : it is vital for the MDM service, for the service adoption or for the user utilisation, breakthrough feature that will increase the utilisation of the service, major flaw to address
     • Medium : it is an important change for the user, for the service or for the serivce adoption, will make the life easier to the user
     • Low : Nice to have

Prioritise a Change

• Who prioritises?
  • The prioritisation of the User visible changes is done via an User Steering Committee (USC) (PERT, NOC, administrator around 5-6 people)
    • Suggestions: NOC: ??, PERT: ??, deployer: ??, Service Desk: ??, NREN: ??
  • The prioritisation of bugs is done by ???
  • User non-visible changes is done between the WILs
  • MDM service change is done by the MDM participants
• When?
  • User visible changes - Every four weeks, the list of changes with their description will be sent by the AL. A vote is organised via a doodle pool. The class having the majority is selected. A phone call is organised within the week for the changes not having a majority. Ultimately, if no concensus is found, the AL will assign a priority.
• Prioritisation
  • The decision is taken based on the business impact of the change to the MDM service (i.e. NOCs utilisation, PERT utilisation, SD support, system administrator maintenance). It is also linked to time at which the change should be happening.
  • Emergency: Very serious impact on the MDM service : large number of user impacted, major security thread on the service (or other service), or critical system. The service cannot work properly or safely and immediate action are required.
  • High: Serious impact on the service: important enhancements required to the service to be deployed/used, security risk to be addressed, several user impacted, bug preventing the service to work with the given quality. Should appear in a MDM pS #.x release (no time to wait for a major release).
  • Medium: No severe impact, but can wait for the next major release MDM pS x.0 occuring every 6-9 months. Improvements.
  • Low: change justified and necessary, but can wait.
  • Rejected: the change is rejected and not taken into account because not relevant to the service.

Feature: we need from the change system a way of extracting the latest

Categorise the change

• The change manager categorise the change by evaluating the amount of work (rough estiamtes) and the number of components involved on which modification is required.
• Categories:
  • Standard Change: a single tool involved and less than a day of work (one WI AND . <= 1d)
  • Low impact : no cross WI coordination involved and less than ten days of work (one WI AND 1d< . < 10d)
  • Medium impact: cross WI coordination involved and less than a month of work (several WI OR 1d < . < 20d)
  • High impact: cross WI coordination or less than two months of work (several WI, 20d < . < 40 d)

Change Assessment - Authorisation - Scheduling

• The objective is to assess further the change: time to make the changes, impact on other tools, ressource required, impact on service, to have it approved (authorised) and schedule the development and its release.

Standard change

The standard change is pre-authorised. The developer can schedule it based on the priority (priority action plans updated), liaise with the release team (to update the release specification document and to check in which release the change is added), send an update to the WIL and update the documentation. Alternatively, the developer can reject the change and explain the rejection reasons.

Low Impact change

• Based on the discussion with the developer, the Work-Item leader authorises (or not) and schedule (update PaP) the change.
• The change Manager updates the WILs.
• If authorised, the Change Manager send to the release management team the text to update the release specification document and liaise for the scheduling in a release.

Medium Impact

• The Change Manager circulate the RFC to the other involved work-Item leaders and developers involved to further assess the change (ressources, time, feasibility).
• Based on the assessment, the WILs decide to authorise it or not.
• The change manager updates all the WILs
• If authorised, the development is scheduled based on the priority (priority action plans updated). The Change Manager send to the release management team the text to update the release specification document and liaise for the scheduling in a release.

High Impact

• The work-Item leaders and the Activity Leader assess the change with the developers, the time, the feasibility, the impact on the service, the impact of not doing it, the impact on other changes.
• Based on the assessment, the WILs decide to authorise it or not.
• If authorised, the development is scheduled based on the priority (priority action plans updated). The Change Manager send to the release management team the text to update the release specification document and liaise for the scheduling in a release.

Actions:

1. the process must be checked against what LK is producing for the SD to align terminology and practices.
2. Investigate if bugzilla can accomodate RFC
3. Set-up an user steeting committee, who is on it, defines how it works.
   • Steering committee to review the prioritisation rules
4. The main issue is the tracking and the articulation between different steps. A software that does an automation of such functionalities would be welcome.

text

The change manager iterate with the developers involved

• 1. • • one person coordinate the evaluation with the relevant developer(s) : time and ressource estimates
       • should the outcome be a text suitable for a release specification document (or is it too early in the process)?

• 1. Authorise the feature: based on the amount of ressources required, the JRA1 objectives and the priority, the features are pre-autorised (less than 1? day), authorised by the WIL (1 < . <= 5 days of work and no cross WIL coordination), authorised by the AL (5 < . < 20 days), the project if additional ressources or major plan changes are involved.
  2. schedule the feature in a given release (updates developers Priority Action Plans accordingly).
  3. Update release specification document
  4. Follow-up and coordinate the feature development
• Investigate if bugzilla can be used to track the request. Investigate the RFE page
• Investigate with project from how much ressources the approval from the project is required.
• The process requires to have someone tracking what is being said on the perfsonar-user mailing list and on the MDM/SD list.
• How to avoid having 15 days taken by 15 time one day features developments? The priority!