Versions Compared

Old Version 8

changes.mady.by.user Sara Lambert

Saved on

compared with

New Version 9

changes.mady.by.user Sara Lambert

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Introducing new business logic or new uses for existing logic into the product

Deliverables:

  • New tickets describing the next steps necessary to enable the feature described

When a Wish or New Feature ticket is in the Active Sprint:

  1. The ticket is marked IN PROGRESS and assigned to a developer, who conducts the meeting
  2. The feature is broken down into a digestable number of enumerated use cases
  3. If one or more use cases require more detail, a Requirement ticket is filed
  4. The use cases are filed as Story tickets and associated to an Epic
  5. The resulting Story tickets are then discussed at the next Sprint Planning meeting

Deliverables:

  • New tickets describing the next steps necessary to enable the feature described

Outstanding questions:

  • When do I use a wish over a new feature?
    • Are Wish tickets requested by people external to NCSA?
    • Does a New Feature have less detail than a Wish? Perhaps more detail?

...

  • Discussion and creation of new Story / Epic tickets describing new product features at a technical level

Deliverables:

  • A Confluence wiki page detailing the discussion held and the use cases generated from that discussion
  • New Epic / Story tickets describing the steps necessary to enable the use cases described

When a Requirement ticket is in the Active Sprint:

  1. The ticket is marked IN PROGRESS and assigned to a developer, who conducts the meeting
  2. A meeting is created in Outlook to contact interested parties (i.e. NDS Labs Dev team, Nebula team, other NDS-affiliated software teams, etc.)
    1. The requirements are discussed with the development team and any interested parties
    2. Any information resulting from the discussion is filed into a Confluence wiki page
    3. The information from the Confluence page generates use cases
    4. If applicable, a new Epic is created to encompass the use cases presented
  3. The use cases are filed as Story tickets and associated to an Epic
  4. The ticket is marked IN REVIEW and assigned to another team member for review
  5. The reviewer may make any changes or comments that they desire and discuss with the team
  6. The ticket is marked RESOLVED or CLOSED
  7. The resulting Epic / Story tickets are then discussed at the next Sprint Planning meeting

Deliverables:

...

Story Workflow

Reporter:

  • Developer

...

  • Introducing new Use Cases into the product
  • Progress toward a particular Epic (i.e. a new technical feature consisting of multiple Use Cases)

Deliverables:

  • GitHub: Pull Request(s)
  • DockerHub: New Image(s) / Tag(s)
  • Confluence: Documentation describing the technical aspects of how the platform fulfills the Use Case
  • ???: Test Case(s) demonstrating the use case fulfilled by the story
    • TODO: discover software for writing test plans

When a Story ticket is in the Active Sprint:

  1. The ticket is marked IN PROGRESS and assigned to a developer (referred to hereafter as "the developer")
  2. The developer does the work necessary to enable the use case described in the ticket
    1. Follow the general development workflows defined above
    2. Comment on the Story with links / updates to any deliverables that need to be reviewed / tested:
      1. Pull Requests
      2. Docker Images
      3. Documentation
      4. New JIRA Tickets
  3. The ticket is marked IN REVIEW and assigned to a tester (referred to hereafter as "the tester")
  4. The tester reviews the deliverables of the Story:
    1. Review any related Pull Requests
    2. Review any Test Cases / Documentation provided
    3. Review any new JIRA tickets resulting from the work done
    4. Pull and run any new Docker images against the Test Cases provided
  5. The tester needs to Accept, Reject, or Abort the review based on the results
    1. If the ticket does not contain sufficient information to decide whether or not the deliverables are acceptable, then the tester selects Review Aborted
      1.  The ticket is marked as OPEN and work is stopped on the ticket
      2. The developer adds more detail to the ticket before continuing, for example:
        1. Test Case
        2. Passing Conditions
      3. The developer then returns to #2 above and refines their deliverables
    2. If the the deliverables are missing, incomplete, or in an untestable state, then the tester selects Review Rejected

      1. The ticket is marked as IN PROGRESS and should then be assigned back to the developer

      2. The developer then returns to #2 above and refines their deliverables
    3. If the deliverables are tested and in an acceptable form, then the tester selects Review Accepted
      1. The ticket is marked as RESOLVED
      2. The tester continues the workflow below
  6. The tester merges any outstanding Pull Requests related to this ticket
  7. The developer switches back to master and syncs with upstream (to pull the new changes into their master branch)
  8. If applicable, the developer builds and pushes a new "latest" Docker image for the API / UI incorporating the new changes
  9. The developer selects CLOSE TICKET and the ticket is marked as CLOSED

Deliverables:

...

...

Alteration Workflows

Issue Types Used:

...

  • Introducing new technologies or techniques into the underlying platform
  • Increases in performance, usability, or maintainability without adding or changing Use Cases

Deliverables:

  • GitHub: Pull Request(s)
  • DockerHub: New Image(s) / Tag(s)
  • Confluence: Updated technical documentation that reflects any modifications to the platform
  • ???: Test Case(s) exercising the benefit introduced by this improvement
    • TODO: discover software for writing test plans

When an Improvement ticket is in the Active Sprint:

  1. Ticket Status: Start Progress
  2. Developer creates a small prototype instance containing suggested improvement(s)
  3. Developer weighs the pros / cons of this solution over the current one against the time it would take to fully implement and test the change
    1. If not desirable, the developer abandons the branch(es) containing these changes and marks the ticket as CLOSED
    2. If desirable, the developer completes the modifications
  4. Developer creates any necessary deliverables
  5. Ticket Status: Review
  6. Tester reviews / tests any deliverables
    1. GitHub: Review Pull Request(s)
    2. Confluence: Review any relevant documentation or technical details
    3. DockerHub: Release new "latest" stable Docker images of UI / API (if applicable)
    4. ???: New test cases resulting from the modifications
  7. Tester merges any deliverables (if applicable)
    1. GitHub: Merge related Pull Requests (if applicable)
  8. Developer releases other deliverables themselves
    1. Confluence: Migrate any documentation from Personal Space to "National Data Service" public space (if applicable)
    2. GitHub + DockerHub
      1. elease new "latest" stable Docker images of UI / API (if applicable)
  9. Ticket Status: Resolve / Close Ticket

Bug Workflow

Reporter:

  • Developer
  • External Contributor (via GitHub "bug" issue)

Used to track:

  • Divergences between expected Use Cases and product behavior

Deliverables:

  • GitHub: Pull Request(s)
  • DockerHub: New Image(s) / Tag(s)
  • Confluence: Updated technical documentation that reflects any modifications to the platform
  • ???:  Test Updated / new Test Case(s) exercising the benefit introduced by this improvementreflecting the expected behavior of the product
    • TODO: discover software for writing test plans

Bug Workflow

Reporter:

  • Developer
  • External Contributor (via GitHub "bug" issue)

Used to track:

  • Divergences between expected Use Cases and product behavior

When a Bug ticket is in the Active Sprint:

  1. Ticket Status: Start Progress
    1. consider creating a new status for "Verification" stage of Bug tickets?
  2. Developer reviews affected Use Case(s) and verifies behavioral divergence
  3. developer fixes product behavior to match expected Use Case
    1. (Rarely) modify Use Case to match behavior
  4. Developer creates any necessary deliverables
  5. Ticket Status: Review
  6. Tester reviews / tests deliverables
  7. Merge any deliverables (if applicable)
    1. GitHub: Merge related Pull Requests (if applicable)
    2. Confluence: Migrate any documentation from Personal Space to "National Data Service" public space (if applicable)
    3. DockerHub: Release new "latest" stable Docker images of UI / API (if applicable)
    4. ???: New / updated test cases that match expected behavior
  8. Ticket Status: Resolve / Close Ticket

Deliverables:

...

...

  • TODO: discover software for writing test plans

Accounting Workflows

Issue Types Used:

...

  1. A Comment / Processing Request / Task ticket is filed to track work that must be tracked
    1. For these tasks, it is likely that you will not need to make any actual modifications to the code
  2. Larger tickets Larger Task tickets can be broken up into a series of Technical Task and Sub-Task tickets
  3. If necessary, a Requirement ticket is filed to explore the nature and limits of the support granted by this ticket

...