Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 31 Current »

DSD-Marine Support Process

This is an overview of the DSD-Marine triage and support process.  Please review this process to familiarize yourself with how to properly manage application support for the Marine Safety and Security (MSS) application portfolio.If you have any questions or concerns, your Scrum Master can provide additional information or guidance.

Service Manager (SMGS)

The Service Manager (SMGS) can be reached at http://smgs:30201/sm/index.do.  To login to the system, use your TC userid and password.

If you are unable to login to SMGS, please contact your scrum master.

Support: New SMGS Ticket - List

  • Assigned field will be blank
  • Status will be Open

Support: New SMGS Ticket - Details

  • Status is Open
  • Assignee is blank
  • Reference number is blank

 

Support: SMGS Ticket Referred

Support: New DevOps Ticket

  • Title follows the format: <English App Acronym> - <IM Number> - <SMGS ticket Title>
  • DevOps ticket is Unassigned
  • One tag created and set to <English App Acronym> (e.g. CPSCS).
  • Second tag created and set to TRIAGE.
  • State is set to “New” (default).
  • Area is set to the appropriate Work Area within the “MSS Portfolio” project. The Area selected should match the application/system identified in the title.
  • Iteration Path is changed to "MSS-Portfolio".  
  • Repro Steps is set to the Description as seen in Support: New SMGS Ticket Details
  • If there are any attachments in the associated SMGS ticket, they are attached to the DevOps ticket via the Attachments tab (not shown).
  • If there are any additional materials related to this issue (i.e. e-mails sent to scrum team to further clarify the reported bug), they are attached to the DevOps ticket via the Attachments tab (not shown).


Support Triage

It is important that TRIAGE tickets in DevOps are reviewed regularly by all DSD-Marine scrum teams.  Marine Safety and Security stakeholders have access to dashboards showing the current state of MSS Application support by DSD-Marine.  Large numbers of tickets waiting for triage may give MSS stakeholders a negative impression of DSD-Marine's current efforts to support the MSS application portfolio.  Please take the time to triage tickets every day.

Support: DATA Triage

  • State is New
  • TRIAGE tag is replaced with DATA tag. DATA bug fixes can be handled without the need for application code updates and/or releases to TC's production environment.   These fixes generally involved database manipulation or client instruction to correct or workaround the reported bug.
  • Iteration changed to match the default Iteration of the scrum team that triaged the bug ticket (e.g. "MSS-Portfolio\Team Kraken")
  • ConversationID is set to the name of the Scrum Team that triaged the Bug:
    • KRAKEN
    • NARWHALS
    • TURTLES
  • Ticket can be added to current or future sprint backlogs where effort and acceptance criteria will be established by the scrum team and business/product owner for the identified application
  • Discussion notes, attachments, and links to related tickets should be used to further clarify the issue.

Support: URGENT DATA Triage

  • State is New
  • TRIAGE tag is replaced with DATA tag. DATA bug fixes can be handled without the need for application code updates and/or releases to TC's production environment.   These fixes generally involved database manipulation or client instruction to correct or workaround the reported bug.
  • URGENT tag is added to the ticket. Client has identified a bug as urgently requiring a fix: these fixes should be resolved within 1-2 business days due to the potential for severe impact on clients and/or the external stakeholders without the possibility of workarounds.
  • Iteration changed to match the default Iteration of the scrum team that triaged the bug ticket (e.g. "MSS-Portfolio\Team Kraken")
  • ConversationID is set to the name of the Scrum Team that triaged the Bug:
    • KRAKEN
    • NARWHALS
    • TURTLES
  • Ticket can be added to current or future sprint backlogs where effort and acceptance criteria will be established by the scrum team and business/product owner for the identified application
  • Discussion notes, attachments, and links to related tickets should be used to further clarify the issue.

Support: REPORT Triage

  • State is New
  • TRIAGE tag is replaced with REPORT tag. The Business Intelligence (BI) team should be involved with all REPORT requests.  The BI team may have a solution in place for use by the stakeholder requesting the report. Alternatively, we may be able to work with the BI team to make sure that similar report requests in the future can be handled via a BI solution.  BI team can be contacted at DL OTT Information Management DMI (cc Jeff Annable).
  • ConversationID is set to the name of the Scrum Team that triaged the Bug:
    • KRAKEN
    • NARWHALS
    • TURTLES
  • Discussion notes, attachments, and links to related tickets should be used to further clarify the report requirements.


Support: URGENT REPORT Triage

  • State is New
  • TRIAGE tag is replaced with REPORT tag. The Business Intelligence (BI) team should be involved with all REPORT requests.  The BI team may have a solution in place for use by the stakeholder requesting the report. Alternatively, we may be able to work with the BI team to make sure that similar report requests in the future can be handled via a BI solution.  BI team can be contacted at DL OTT Information Management DMI but the urgent nature of this request will require a more immediate hands-on approach unless BI has an existing solution.
  • URGENT tag is added to the ticket. Client has identified the report as urgent (i.e. upper management or Minister's office request). These reports will be needed ASAP: refer to the Repro Steps information or attachments for further information.  
  • ConversationID is set to the name of the Scrum Team that triaged the Bug:
    • KRAKEN
    • NARWHALS
    • TURTLES
  • Discussion notes, attachments, and links to related tickets should be used to further clarify the report requirements.

Support: CODE Triage

  • State is New
  • TRIAGE tag is replaced with CODE tag (see Fig. 1 below)
  • Iteration Path remains unchanged.  This CODE fix may be added to any scrum team's sprint backlog based on MSS priority and team capacities.
  • ConversationID is set to the name of the Scrum Team that triaged the Bug (ConversationID will be changed if another team fixes this bug):
    • KRAKEN
    • NARWHALS
    • TURTLES
  • Ticket can be added to current or future sprint backlogs where effort and acceptance criteria will be established by the scrum team and business/product owner for the identified application.  
  • If this bug is preventing clients from using the application/system and/or if the client has identified this fix as urgently required, add the URGENT tag procedure to initiate an emergency release should be followed. Contact your team lead/scrum master for further detail.
  • Discussion note added with the following text: "Triaged and SMGS ticket closed."
  • Ticket is closed in SMGS (see Fig. 2 below).  A note must be added to the SMGS ticket's Solution text that reads: "Issue being tracked in DevOps: <link>. Issue will be fixed in a future release." where <link> will direct client to the triaged DevOps ticket.  


Figure 1: DevOps CODE ticket is triaged



Fig. 2: SMGS ticket closed following CODE ticket triage

Support: URGENT CODE Triage

  • TRIAGE tag is replaced with CODE tag (see Fig. 1 below)
  • URGENT tag is added to the ticket.  The first step to is to confirm that this issue is urgent: if so, an URGENT CODE fix must be remedied immediately.  Scrum Team and Product Owners should be contacted to have the issue and effort assessed and placed on the current Sprint Backlog.
  • Appropriate Acceptance criteria are determined by the product owners and scrum team.
  • Iteration Path is changed to the responsible Scrum team's current Sprint iteration after the team and product owners have assessed the issue and effort has been estimated.
  • ConversationID is set to the name of the Scrum Team that triaged the Bug:
    • KRAKEN
    • NARWHALS
    • TURTLES
  • State is Committed.
  • If this bug fix is an emergency (e.g. production site is down, data is being corrupted, etc.), scrum master or team should being emergency release procedure.
  • Discussion note added with the following text: "Triaged and SMGS ticket closed."
  • Ticket is closed in SMGS (see Fig. 2 below).  A note must be added to the SMGS ticket's Solution text that reads: "Issue being tracked in DevOps: <link>. Issue will be fixed in a future release." where <link> will direct client to the triaged DevOps ticket.  


Figure 1: DevOps URGENT CODE ticket is triaged



Fig. 2: SMGS ticket closed following URGENT CODE ticket triage

Support Effort and Resolution

Support: Tracking Effort

  • State is Committed.
  • Effort for all bug fixes - DATA, CODE, or REPORT - should be recorded in the Bug's Effort field using the Fibonacci number. 
  • Unlike standard bugs or PBI's committed during the refinement or planning scrum events, any estimated Effort should be updated with the actual effort once work is finished.  We would like to determine the actual percentage of effort is spent support stakeholder bug requests/tickets by DSD-Marine's scrum teams. 
  • If there are two or more people working on a single bug, please be sure to update the Effort accordingly.  Child tasks can also be created to help coordinate the fix across the development team.

Support: Bug Resolved

  • State is Done.
  • Effort (i.e. Fibonacci number) reflects the actual effort spent by the the scrum team to resolve the issue.
  • Acceptance criteria and definition of done have been met by the team.
  • ConversationID is set to the name of the Scrum Team that resolved the Bug:
    • KRAKEN
    • NARWHALS
    • TURTLES
  • All notes, correspondence and details of the work performed are recorded directly in the DevOps bug ticket and via any attachments to the ticket.
  • A brief discussion of this issue and a link to the bug ticket are placed in an appropriate section in Confluence. Each MSS application has a page in Confluence that includes a section devoted recording common support issues and how these issues were resolved. See CPSCS-SCEPC page's "How-To and Fixes" section for examples.
  • In the Discussion, add the following note: "Details of this ticket discussed and linked in <link>", where <link> is the MSS application's Confluence page (e.g. CPSCS-SCEPC).

Support: Close SMGS Ticket

  • Ticket Status is set to Resolved (not shown).
  • Close button has been clicked (setting Status to Closed).
  • Appropriate Closure Code has been selected. "Solved by Action on Software" is a good one to use for many of the bugs we handle but there are many other valid options.  Discuss with your scrum master when in doubt.
  • A brief description of the solution has been entered into the Solution field.  For example, "Issue fixed via database update. Client confirmed fix." or "Report generated and sent to client via BI platform."

Identify and Eliminate Recurring DATA Support

Every effort should be made to identify and eliminate recurring DATA tickets.  If you or your teammates find yourselves constantly resolving the same bugs for an application, it may be best to identify the root cause of the issue and take steps to fix the issue permanently.  To handle cases such as these, please refer the following suggested course of action:

  1. Prior to Sprint Planning, refer to master priority list for bugs to identify the highest priority MSS applications (see MSS Portfolio Bugs by Business Value list on the DSD-Marine: Support Overview page). This is a list of active bugs sorted by the MSS-assigned business value.
  2. Take the application/area highest on the list being handled by your scrum team as shown on the Second-Level Support on the DSD-Marine: Overview page).
  3. Review the applications's backlog, including open and closed tickets, to identify groups of bugs with high re-occurrence rates.
  4. For each group of bugs, create a new single Bug ticket:
    1. Add the CODE tag to the Bug (since development work will be needed to resolve)
    2. Add the RBF (Recurring Bugs Fix) tag to the Bug - this will allow us to track fixes made to eliminate recurring bug tickets as suggested by DSD-Marine.
    3. Add the application tag to the Bug  (e.g. CPSCS, SVCP, SRCS, etc.). 
    4. Set the Bug's Area to match that of the grouped recurring bugs
    5. Link all of the related bugs (as Related) to the Bug. This will allow the development team to review all of the past, present and future Bug tickets that have been created related to the CODE fix.
    6. Fill out the Repro Steps for the Bug with enough detail to describe the issue and allow for the development team to reproduce.
    7. Add an estimated Effort to fix the Bug permanently.
    8. Iteration should be set to your scrum team's base iteration (MSS-Portfolio/<Team Name>).
  5. Repeat Step 4 for as many groupings of bugs as needed.  It may be best to address a handful of CODE fixes to an application at once to optimize the cost of planning and releasing new code to product.
  6. Set up a meeting with the dev team and all product owners for your current project and those related to the recurring Bug(s) created. For each of the recurring Bugs identified:
    1. Show the product owners the cost (in Effort) that is being spent repeatedly fixing the same DATA fixes.
    2. Define Acceptance Criteria for the Bug.
    3. Have the Product Owner(s) assign a business value to the Bug.
    4. Set the State to Approved.  The product owners will need to prioritize this bug for a future sprint so that it can be committed to a sprint backlog by the development team. 
  7. ConversationID is set to the name of the Scrum Team that will resolve the RBF bug:
    • KRAKEN
    • NARWHALS
    • TURTLES

By following this process (or whatever similar process works best for you team), DSD-Marine can move beyond quick fixes that ultimately do nothing to reduce the steady flow of SMGS bug tickets.  

While every team should attempt to limit support to 1.5 hours per day per development team member, there may be cases where a little more time spent on a fix for recurring DATA bugs could save everyone a lot of time down the road. Scrum teams and product owners must work to identify long-term bug fixes that deliver the most business value and will have the greatest positive impact on DSD-Marine's capacity to handle application development, support, and maintenance.

Appendix I: Additional Support Procedures

Handling Support Calls and E-mails

If you are receive e-mails or phone calls from business clients seeking application support, please let your Scrum Master know as soon as possible.  While we are committed to providing timely support to our clients, we want to minimize any additional impact on our scrum teams' sprints.  Clients should be directed to use the DSD-Marine Support Intake Form to request support for system/applications bugs and enhancements.    

Handling Application/Network Access Requests

From time to time, you may come across an SMGS ticket requesting system or application access for a new user. If you happen to see an SMGS ticket (change, IMAC, IM) asking us to grant user access to a MSS application, please re-assign the ticket from MARINESAFETY to “ACCESS CONTROL – NCR”.

We’re not authorized to grant users access to applications and this responsibility belongs to our clients. ACCESS CONTROL will make sure that our client admins see these requests. If you have any outstanding tickets in SMGS related to this matter, please re-assign them as soon as possible (and close any related DevOps tickets).  

EXCEPTION: We do handle all MSDQT access requests. Create a ticket in DevOps and assign to the appropriate Second-Level Support team (found on the Marine Overview page).

Appendix II: Application Support Resources

DSD-Marine Support Dashboards

The following dashboards/reports have been created to give MSS stakeholders and the DSD-Marine team information about the current state of application development, support, and maintenance of the Marine Safety and Security application portfolio.

DSD-Marine Support Intake Form

The DSD-Marine Support Intake Form can be found in RDIMS:

  • No labels