Page History

...

If the deployment issue is closed the original linked SD issue will automatically be updated to status: . Reporter and Requested participants can be informed that a fix has been applied and the SD issue can be closed with resolution: Done - Development.

SD

...

Image RemovedIncident:  Reporting a incident or outage. Currently all incoming issues submitted via the Jira Customer portal - YME IT Support  or YME E-Commerce support will have Issue type Incident.

Image RemovedService Request:  Request for information.  (This issue type cannot be selected via the customer portal and is only visible after manual change )

Image RemovedService request with approvals:  Request for application access or AWS workspace, approval option included to request approval from users manager or YME IT management.

Image RemovedAudit: Used for J-sox change requests and IRY issues registered to deliver evidence for auditors.

Image RemovedAuthorization request: Elevate user rights request used for Ympact to request YMXXITS1 access to have command line access and to operate in Ympact (Branch specific) Production environment.

Image RemovedRobotJob Change: Robot Job Change request used for Ympact Job scheduling

Image RemovedDeployment request: Triggered by Development software projects used by B2B teams for Ympact,Ympulse, Yamcom deployments.

Image Removed Onboarding: Issue type used for Onboarding new Users and Admin account request

Image Removed Task: A Task that needs to be done, currently used for Onboarding procedure

Image Removed Sub-task: Smaller task within a larger piece of work, currently used for Onboarding procedure. A sub-task cannot being linked to a Customer portal request type and is only for internal use.

...

Deployment Request issue creation

SD Deployment requests are automatically created by a trigger via a YIS Deployment ticket like a Story when as specific transition is used to move an issue from status Ready for Deployment to Done Deployment, these options are only visible for designated Business Train deployment approvers .
This process is currently only used by the Business Train for BA, OMS deployments (YAMS/YMPACT) and Logistics deployments (SYS2000/YLS) and Docker/JAVA deployments.
See for a more detailed explanation: 

SD Issuetypes 

Image AddedIncident:  Reporting a incident or outage. Currently all incoming issues submitted via the Jira Customer portal - YME IT Support  or YME E-Commerce support will have Issue type Incident.

Image AddedService Request:  Request for information.  (This issue type cannot be selected via the customer portal and is only visible after manual change )

Image AddedService request with approvals:  Request for application access or AWS workspace, approval option included to request approval from users manager or YME IT management.

Image AddedAudit: Used for J-sox change requests and IRY issues registered to deliver evidence for auditors.

Image AddedAuthorization request: Elevate user rights request used for Ympact to request YMXXITS1 access to have command line access and to operate in Ympact (Branch specific) Production environment.

Image AddedRobotJob Change: Robot Job Change request used for Ympact Job scheduling

Image AddedDeployment request: Triggered by Development software projects used by B2B teams for Ympact,Ympulse, Yamcom deployments.

Image Added Onboarding: Issue type used for Onboarding new Users and Admin account request

Image Added Task: A Task that needs to be done, currently used for Onboarding procedure

Image Added Sub-task: Smaller task within a larger piece of work, currently used for Onboarding procedure. A sub-task cannot being linked to a Customer portal request type and is only for internal use.

SD Issue types and Customer request type

Anchor
SD Issue types and Customer request type SD Issue types and Customer request type

Request name is the Customer Request type.

...

Request name is the Customer Request type.

...

• Type: Issue type
• Priority: By default issues are set to Medium
  
  
• Solution group *: Drop down single select list to define which department will be working on the issue.
  This is automatically set/changed when and issue is created via the customer portal or when a Yamaha team field value  is changed.
  
  
• Team Yamaha: Label field, multi select, always starting with team# <team name>. This field is only automatically filled for Special processes like SQL Execution, Robot Job Changes.
  Please do no not use it for team assignment but use  field "Yamaha Team" instead. 
  
• Yamaha Team*: Mandatory Drop down single select list to define which (agile) team will be working on the issue.
  
  
• Application-Module*:  Mandatory Drop down single select list to indicate the involved Application-Module of the reported request (issue).
• Department: Department of the reporter of the issue.
• Company: Company of the reporter of the issue.
• Epic Link: Linked epic issue if a issue is related to a Project.
• SD Classification: Drop down single select list, by default for incoming issues it is set to Business as Usual (BAU)
  
  
• Story Points: used to estimate (in a Fibonacci range) the complexity, effort, and risk inherent to the story. Story Points field available for issue type Change request, Task, Story, Bug, Defect, Spike. 
• Business value:  used to estimate (in a Fibonacci range) the value of that piece of development to the YME business.
• Sprint: Multi select field to link the issue to a sprint.
  
• DOR: DOR is the abbreviation forDefinition of Ready. Scrum teams generally use a Definition of Ready to clarify whether a Jira issue (Product Backlog Item, or PBI) can be taken into sprint.
  Within Jira, this process has been summarized in a field, "DoR", which allows tracking what an issue needs to become ready for development.
  Image Modified
  The generalized DoR steps are:
  1. Issue created
  2. Requirements defined
  3. Prioritized against other work
  4. Refinement & estimation done
  5. Ready for work
  
  N.B. This is an optional feature. Set the field manually in refinement sessions, in case that makes sense for your team.
• Ticket group(s) Multi select field used to group stories and bugs under a YPM Programme/Project
  
  
  
• Type of work:  Field used to track type of work activated for Issue type: Incident
  
  Technical debt: Efforts spent on improving the codebase, enhancing its structure, refactoring, and optimizing it without adding new functionality. 
  New Development: Efforts dedicated to developing new features, functionalities, or significant enhancements. 
  Maintenance: Efforts involved in maintaining the system, which includes activities like routine updates, performance tuning, etcetera. 
  Bug Fixing: Efforts expended to identify and resolve defects or issues reported in the system.
  
  
• Division: (YME Division)
  Multi select field to indicate the YME Division(s) involved/affected. By default empty, value can be entered via the customer portal form or via edit button.
  Field is available for Issue type Incident and Service Request. Based on the value entered in this field stakeholders from the Business Divisions can be contacted by the YME IS teams.
  
  
  
  
• YME Root cause*: Mandatory field to be filled when closing an SD Incident, optional for other SD issue types. 
  Field is used for reporting to check where improvements can be made.
  
  
• Resolution: Resolution can be set when a issue will be closed.

...

SD Default Workflow V6 and SD Incident workflow V6 are similar, only difference is that for Incident YME Root Cause field is mandatory when closing the issue.
This workflow is used for Issue type Incident, Audit, Deployment request, RobotJob Change and Service Request.

Statuses SD Default Workflow

...

• Pending linked ticket execution Temporary status Triggered when a linked ticket is created for Elevated user rights or RobotJob Change request
  Instructions for these procedures can be found on the following pages:
  How-to request Elevated User rights - SQL cluster access 
  How-to request Elevated User rights - YMPACT YMXXITS1 access 
  How-to request a Robotjob change
  
  
  
• Awaiting Development Status set when a linked Sofware Delivery ticket is created, see explanation under Software Delivery BUG/Incident issue creation via SD
  
  
• Awaiting Execution  Used for SQL Process for SQL execution and deployments. 
  
  
• Deployment validation Used by Infra Enable train for AS400 morning check validations.
  
  
• Ready to Close Triggered when a linked Software Delivery issue is closed. see explanation under Software Delivery BUG/Incident issue creation via SD
  
  
• Review Approval  Used by Infra Enable Train for Issue type Audit to have J-sox change reviewed.  How-to create an Infra J-SOX CHANGE issue 
  This process has been replaced by YIS Enable Story creation in Project YIS.
  
  
• Awaiting manager approval Used by Infra to request IT management approval for J-sox changes.  How-to create an Infra J-SOX CHANGE issue

...

1. Awaiting Supplier status can be triggered via the Awaiting Supplier  button .
   
   When selecting this option a pop up frame will be opened:
   
   
   
2. Check Comment selection (see marked in red in the above screenshot).
   Default for comment is set to Internal comment. The Internal comment option can be used for only triggering a status update to Awaiting Supplier 
   Use comment: Respond to customer if your message should be shared with the the reporter and requested participants.  
   1. Optional: Add comment to the comment section.  
      
3.  Select the Awaiting supplier response button.
4. After reply from the Awaiting supplier response button is pressed the comment will be added to the ticket and status will be changed to Awaiting Supplier. Description area is optional.
   Image Removed
   
Response from supplier received:

5. Via issue: Status will automatically changed back to status In Progress.
Manually: Select status In Progress.
Image Removed
6. marked in red in the above screenshot).
   Default for comment is set to Internal comment. The Internal comment option can be used for only triggering a status update to Awaiting Supplier 
   Use comment: Respond to customer if your message should be shared with the the reporter and requested participants.  
   1. Optional: Add comment to the comment section.  
      
7.  Select the Awaiting supplier response button.
8. After reply from the Awaiting supplier response button is pressed the comment will be added to the ticket and status will be changed to Awaiting Supplier. Description area is optional.
   Image Added
   
9. Response from supplier received:
   
   1. Via issue: Status will automatically changed back to status In Progress.
   2. Manually: Select status In Progress.
      Image Added

SD Deployment Request 

Anchor
SD_Deployment_Request SD_Deployment_Request

SD Deployment requests are automatically created by a trigger via a YIS Deployment ticket like a Story when as specific transition is used to move an issue from status Ready for Deployment to Done Deployment, these options are only visible for designated Business Train deployment approvers .
This process is currently only used by the Business Train for BA, OMS deployments (YAMS/YMPACT) and Logistics deployments (SYS2000/YLS) and Docker/JAVA deployments.

See under Generic Development Workflow via which workflow transition the SD Deployment is triggered.

When an Image Addedis created  a  Jira automation will be triggered to set the fields:  Issue Type, Customer request type, Application-Module, Yamaha team and SD Classification and Request participants (from original trigger issue and add stakeholders like B2B deployment Distribution list/ B2C deployment Distribution list) . Also the issue is automatically transitioned through the workflow from status Awaiting assignment > Assigned (To Do) > In Progress > Awaiting Deployment Approval .
An Business Train deployment approver can approve the issue by selecting the appropriate option:

• Docker deployment approval → Will trigger automatically a docker deployment and set issue to status Ready to Close
• Non-Docker deployment approval → Will trigger automatically a Jenkins deployment and set issue to status Ready to Close
• OMS deployment approval→ Will set status to Awaiting Execution, Yamaha Team iSparkle-iSeries will execute the deployment request
• Logistics deployment approval→ Will set status to Awaiting Execution, Yamaha Team same as YIS deployment issue will execute the deployment request

After SD Deployment request is set to Ready to Close or Awaiting Execution the team responsible for the deployment can execute the deployment and can afterwards use transition 'Resolve'  for setting status to Closed
When using this transition select in the pop-up screen resolution Done - Deployment. When closed automatically all in the request participant field are informed.
Image Added  
Image Added

SD: Software Authorization Workflow

...