Versions Compared

Old Version 6

changes.mady.by.user Sara Lambert

Saved on

compared with

New Version 7

changes.mady.by.user Sara Lambert

Saved on

Key

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

...

Reporter:

  • Management
  • Developer

Used to track:

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

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

...

Requirements Workflow

Reporter:

  • Developer

Used to track:

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

When a Requirement ticket is in the Active Sprint:

...

Story Workflow

Reporter:

  • Developer

Used to track:

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

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
  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 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, 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 their master branch and syncs with the new changes
  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:

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

    Alteration Workflows

    Issue Types Used:

    • Improvement: a suggestion to utilize new techniques or technologies to improve overall performance or maintainability of the platformthat might have a positive impact on the product without introducing new features (i.e. refactoring, rewriting, etc.)

    • Bug: a previously completed use case or edge case that is malfunctioning according to its defined behavior

    ...

    Improvement tickets follow a workflow that resembles that of a Story ticket.

    Reporter:

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

    Used to track:

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

    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 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)
    8. Ticket Status: Resolve / Close Ticket

    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) demonstrating the use case fulfilled by the story
      • 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)
    8. Ticket Status: Resolve / Close Ticket

    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) demonstrating the use case fulfilled by the story
      • TODO: discover software for writing test plans

    Accounting Workflows

    Issue Types Used:

    ...

    Comment Workflow

    Reporter:

    • Management
    • Developer
    • External Contributor

    Used to Track:

    ...

    Request Workflow

    Reporter:

    • Management
    • Developer
    • External Contributor

    Used To Track:

    ...

    Task Workflow

    Reporter:

    • Management
    • Developer

    Used to Track:

    1. events requiring special attention (i.e. hackathon, developer tutorial, etc.)
    2. any other externally-driven tasks that require explicit work to be done

    ...