Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Development Process

Source: Confluence - Development Process

Overview

The development process for the Engineering team is dynamic and in place to help the team get work done in the easiest and most productive fashion.

There is no standard or general process that meets the needs of the team. This is true of any team; however, most companies are looking for a process to solve their problems, a silver bullet.

That’s not how a process works. A process evolves out of a current team’s way of doing things. It is an evolution of how things are done, leveraging what works, fixing what doesn’t, and guiding the team (and new members).

This page will familiarize the Engineering Team with the tools, people, and processes related to development at Caveance and Path2Response.

Communication

For information on company communication tools, please refer to: Communications

Software Development Process

This is not a guide to Agile, Scrum, etc. If you don’t know these terms, methodologies, and approaches, learn them!

Resources:

Agile

Agile software development refers to a set of software development methodologies based on iterative development. Requirements and solutions evolve through tight collaboration between self-organizing, cross-functional (engineering, business, and customer) teams. Agile processes promote:

  1. Frequent inspection and adaptation
  2. Top-to-bottom leadership philosophy that encourages teamwork, self-organization, and accountability
  3. Set of engineering best practices intended to allow for rapid delivery of high-quality software
  4. A business approach that aligns development with customer needs and company goals

At Path2Response, we embrace Agile software development and look for ways to continuously improve our communications, tools, and ability to deliver value to our customers.

Path2Response Philosophy:

  • “Tools over processes” and “Tools support people and interactions”
  • Tools are critical and should always be improved to support the people and processes
  • Processes should be something that individuals fall back to and believe in

Scrum

Scrum is a subset of Agile, a lightweight process framework for agile development. “Lightweight” means that the process’s overhead is kept as small as possible to maximize the amount of productive time available for actually getting useful work done.

Key characteristics:

  • Time is divided into short work cadences (sprints) - typically one or two weeks
  • Product is kept in a potentially shippable state at all times
  • End of each sprint: stakeholders and team members meet to see demonstrated work, discuss the sprint, and plan next steps

Accountabilities - The Hats Worn by Members of a Scrum Team

Product Owner(s)

  • Karin Eisenmenger — business product owner
  • John Malone — technical product owner
  • Michael Pelikan — strategic product owner

Scrum Facilitator

  • David Fuller

Developers

Engineering (John Malone)

  • Jason Smith
  • Carroll Houk
  • David Fuller
  • Wes Hofmann
  • Michael Pelikan

Data Science (Igor Oliynyk)

  • Morgan Ford
  • Erica Yang

Kanban

Kanban is a method for managing work with an emphasis on “just-in-time” (JIT) delivery while not overloading the team members.

Business and client projects use Kanban. Engineering uses Scrum for all work.

Path2Response Specifics

Jira

For the Engineering team, if it isn’t in Jira, it doesn’t exist. The team shall not perform work without a Jira issue.

All members of the Path2Response team may create an issue (Epic, Story, Task, Bug, etc.). Typically, anything above a Task is put on the backlog for prioritization. Tasks (and Subtasks) and Bugs can be created and worked on by team members immediately, given that the team agrees upon the impact on the current sprint.

Primary Communication Tool

Jira is the primary communication tool for the Engineering team. Jira should be the first place you think of communicating, asking questions, providing information, etc.

Projects

The Engineering Team will perform most of its work on the Path2Response Development Board, part of the PATH Jira project.

Components

All issues for Development should include a component when the issue is created. Issues are automatically assigned to the Component Lead when submitted.

Fix Version

“Where you plan to fix it / where it has been fixed”

For the PATH project, the sprint for which it is intended to be fixed or was fixed should be used. If unknown, then the version may be left empty. When an issue is closed, the fix version becomes the sprint in which the issue was resolved and closed.

Sprints

Path2Response has two-week sprints.

Please see Sprint Process Schedule for specifics on the timing of the Sprint Review, Retrospective, Planning, and other key Sprint meetings.

Sprint Pre-Planning

Prior to the sprint planning meeting, there needs to be individual and team preparation for the sprint commitments. Engineering needs to understand the next sprint, dig into the requests, and ensure that the high-level details and acceptance criteria is understood.

Every developer is expected to go through their backlog and understand what is being requested, recommended, etc. The backlog report in Dashboards is used as a guide for this process.

  • Jira tickets are the best place to discuss specific issues
  • Prioritization discussions spanning several issues should use Slack #sprint-planning

Sprint Review

The intent of the Sprint Review meeting in Agile is to demonstrate stories, bugs, etc., that were completed in a sprint to external stakeholders.

Recommendation: Stakeholders should read the release notes and drill into individual Jira issues. For questions or demos, join the “Engineering Office Hour” on Monday following the sprint.

Sprint Retrospective

A chance for all team members to state what worked and what didn’t work during the past sprint. Action items are immediately created and assigned for resolution.

The Sprint Retrospective pages are available for the entire sprint and should be updated as issues, ideas, concerns, changes, etc., arise.

Sprint Planning

During the planning meeting, the Scrum Facilitator works with the team to refine estimates (story points) and determine which items can be brought into the next sprint.

Story Point Estimates

SizePointsGuidance
X-Small1Quick change, configurations, etc.
Small2
Medium4
Large8Consider breaking down the work effort
X-Large16Strongly consider an Epic designation

Planning Meeting Flow

  1. Product Owner(s) should have prioritized the backlog
  2. Scrum Facilitator defines the next sprint
  3. Scrum Facilitator closes the current sprint at the beginning of the meeting
  4. Incomplete items automatically roll into next sprint (unless explicitly removed)
  5. Team agrees that issues are understood and “do-able”
  6. Scrum Facilitator starts the next sprint

Sprint Naming: Sprint ### (incrementing number) Sprint Duration: ~3:00 PM MT Friday through ~2:00 PM MT Friday (two weeks later)

Sprint Deployment

There should be an issue created for every sprint for merging into main and deploying to production. This should be the first task for each sprint.

Daily Standup

Path2Response has daily stand-up meetings with teams.

Status Guidelines

  • Status should be a proper communication, not copy-paste from previous day
  • Intentional thought should be given to your status
  • “Highlights / Impacts” section should contain enough detail for all team members
  • Post status on #dev-scrum before 9:00 AM MT every workday

Daily Expectations

SCM (Source Code Management)

All source code generated by the Engineering Team will be placed in SCM, specifically under Git control, and pushed to the corporate repository on a routine basis.

Failure to have source code under SCM and routinely pushed to corporate repository is a terminable offense.

Main Branch

The main branch is the primary branch and shall be continuously in a potentially “shippable” state.

Branching Strategy

See Branching Strategy for the complete branching workflow.

Acceptance Criteria

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements. They constitute our “Definition of Done”.

Guidelines:

  • Prior to bringing a story into the sprint, developer, product owner, and stakeholder(s) should agree upon specific, testable Acceptance Criteria
  • If Acceptance Criteria need to change after sprint start:
    • If developer is not the stakeholder: renegotiate with stakeholder
    • If developer is the stakeholder: can evolve as needed

For “researchy” stories:

  • Ideally, start with a smaller “Research” ticket to define follow-up stories
  • If work must be done in same sprint, use a larger story point story and split mechanism

Branch Workflow

See Git Feature Branches for detailed instructions.

For Each Epic, User Story, or Bug:

  1. Create branch for each user story (named after Jira issue, e.g., PATH-1045)
  2. Put issue into In Progress when working on it
  3. Commit and push until acceptance criteria are achieved
  4. Write automated tests for any new or changed functionality
  5. Resolve the story to the stakeholder for QC
  6. Have another team member perform code review via pull request
  7. If issues found, story may be Reopened
  8. When satisfied, reviewer selects Accept Issue
  9. Once you have both Jira acceptance and PR approval, merge to main
  10. Close the Jira issue

Test Plans

Definition

The Test Plan should indicate what was done and how to verify that it meets the Acceptance Criteria. Write it so it’s useful in the future, not just right now.

Procedure

  1. Populate Test Plan field with details on how and when the story/bug should be tested
  2. On sprint release day, test plans are exported to a Google sheet
  3. Monday Test Plan Review meeting reviews the test plans
  4. Test on staging after deployment, plan for production testing
  5. For testing activities likely to be repeated, write well-defined testing scripts
  6. Before deployment to production Tuesday morning, need:
    • All applicable tests checked off
    • Approval from Engineering Lead, Scrum Facilitator, and Production Team
    • Completed by 5:00 PM the day before deployment

Code Reviews

Another set of eyes helps spot problems and provides knowledge transfer.

When is a Formal Meeting Needed?

The severity/impact should drive the magnitude. Large, complicated, or revenue-impacting changes warrant a meeting.

Formal Process

  1. Complete code and do developer-level testing
  2. Resolve Jira story to stakeholder
  3. Create Pull Request in Bitbucket, assign to reviewer(s)
  4. Schedule meeting if severity justifies it
  5. Code Reviewers comment on the pull request
  6. Code Reviewer either Rejects (with recommendations) or Accepts
  7. Stakeholder either Reopens (if not as expected) or Accepts

Commits

All commits to Git should be in the format: XXXX-###: Description

  • XXXX-### is the Jira issue
  • Multiple issues: XXXX-###, XXXX-###: Description
  • Description is detailed description of the specific commit

Releases

At the beginning of each sprint, a release of the previous sprint will be performed.

Code Release

  1. Everyone does their last few merges back to main
  2. Tag the main of each project:
cd ~/workspace/devtools/sprintRelease/
node lib/actions/tagReleases.js --tag-name "188.0.0" --from-branch-name "main" --commit-message "PATH-14914 Sprint Release 188.0.0"

Jira Release

  1. Add correct sprint name to Fix Version of each issue
  2. Administrator releases the Version from Versions Administration page
  3. Jira provides release notes based on Fix Version

Post Release Cleanup

  1. Cleanup old branches after the release of the following sprint
  2. Quarterly recurring tasks for cleanup
  3. Criteria for cleanup:
    • User story closed
    • Branch merged to main
    • One sprint later than the release sprint
# Fetch which prunes upstream deleted branches
git fetch -p

# Remove the branch locally
git branch -d PATH-XXXX

# Remove the branch on BitBucket
git push origin :PATH-XXXX

Git Config

Example ~/.gitconfig:

[user]
    name = username
    email = email@path2response.com
[push]
    default = simple
    autoSetupRemote = true
[merge]
    tool = vscode
[diff]
    tool = opendiff
[pull]
    rebase = false
[mergetool "vscode"]
    cmd = code --wait --merge $REMOTE $LOCAL $BASE $MERGED
[difftool "vscode"]
    cmd = code --wait --diff $LOCAL $REMOTE