Dev Process (as of 8/31/21)

The objective of our Dev process is to create an environment where the Dev team can consistently get important tasks done at a predictable pace week after week while regularly communicating their progress and blockers. We'll be using a light version of Scrum to accomplish this.

πŸƒβ€β™‚οΈ TLDR

Below is a quick summary of the various parts of our process.

♻️ Workflow
  • Ward/Ryan will add tasks to the πŸ“‹ Backlog in priority order, each task should be under a week of work.
  • We'll meet Mondays to do a retrospective of the last week. We'll then review the πŸ“‹ Backlog and pick tasks for the week by adding them to 🏁 Selected for Dev. We'll meet Wednesdays to go over progress & blockers.
  • When starting on a task, move it from 🏁 Selected for Dev to πŸ§‘β€πŸ’» In Progress. Move it back to 🏁 Selected for Dev during the week if you're uncertain it will get done.
⛏ Task Breakdown
  • Add a task breakdown label to any issue over a week in scope and create a milestone.
  • The end result should be a list of tasks added to the πŸ“‹ Backlog.
  • βœ‹ If the overall scope becomes larger than anticipated, ping Ryan/Ward.
⚠️ Support Issues
  • If there is an emergency, we'll let the Dev team know. But in most cases Ward/Ryan will add the issue to the πŸ“‹ Backlog for consideration in the current or next sprint.
‴️ Pull Requests
  • Link the PR to the corresponding task issue OR remember to close the corresponding issue after the PR is merged into Staging OR put "closes #<issue-num>" in the PR description to auto-close the issue when merging (more options).
  • Request a PR review from msupdatebot - this will automatically trigger a ping in the Dev campfire to get reviews from the team.
  • Fully test your changes in Staging and reach out to Support (by replying to an existing thread or creating a new one) to have them test as well (your call).
πŸ›³ Merging Into Production
  • Every weekday at 3pm ET, we should merge Staging into Production. You can additionally merge earlier if needed.
  • βœ‹ Do NOT merge into Production after 4pm ET (unless it's an urgent bug fix).
  • After Staging is merged into Production, (if applicable) please let the Support team know about any issues you've fixed by responding in the Basecamp thread.

♻️ Workflow


We will be working in weekly sprints and Dev tasks will be organized and tracked as a Github Project here.

If you want to view the board in a specific view (e.g. only tasks assigned to yourself) just click your picture, then bookmark that filter, and then use that bookmark as your default way to get to the project board:
Screen_Shot_2021-06-22_at_7_41_45_AM.png 469 KB View full-size Download
PS. here's some keyboard shortcuts you may find handy.

Only the stakeholders (
Ward Sandler Ward
&
Ryan Bennick Ryan
) will add various task issues to the πŸ“‹ Backlog.

This list will be in priority order and include customer feature requests, support issues, internal features, infrastructure updates, etc.

Everyone on the team is encouraged to post πŸ’‘ Pitches for new feature ideas/enhancements. This is how you can get your ideas into the product.

Many tasks will start life as a Pitch (i.e. it's been fleshed out in terms of the problem, proposed solution, constraints, and design ideas). All Pitches will be discussed among the entire team. The stakeholders will then determine if the Pitch should be included in the πŸ“‹ Backlog for a future sprint.

Most Pitches are over a week in scope and therefore need to be broken down into smaller tasks. A task should never be more than a week's worth of work and ideally around 2 days.

In other words, a Dev should be able to complete the task (and have it merged into in production if applicable) in less than a week. This breakdown process itself should be a task (more on that later).

A collection of related tasks is called a milestone in Github (aka an epic).

The πŸ“‹ Backlog is made up entirely of smaller tasks (some within milestones) that are ready to be worked on in a future sprint.

Every Morning
Please look over any pending PR reviews first thing when you get in so we're not blocking code getting into Staging: https://github.com/320ny/memberspace_platform/pulls?q=is%3Apr+is%3Aopen+review%3Arequired+draft%3Afalse

Monday @ 1:15pm ET
We'll have a 75 minute (or less) meeting.
  • First, we'll do a 30 minute or less show-and-tell where each Dev presents the work that was πŸŽ‰ Done in the past week. They will also discuss what went well and didn't go well during the last week of work. Each Dev will have about 5 minutes.
    • Let's keep discussion to a minimum, but feel free to ping or start threads after the meeting.
  • Next, we'll discuss the πŸ“‹ Backlog and go over what should be worked on next.
    • We'll start at the top and have each Dev choose which tasks they can work on for the upcoming weekly sprint. This is a good time to double check that tasks have been broken down enough (i.e. under a week in scope) and address any initial questions about the task.
    • When a Dev takes ownership of a task, they are committing to finishing it before the next Monday meeting. These tasks will be manually moved to the 🏁 Selected for Dev column and the Dev should be assigned to it:
      Screen Shot 2021-05-14 at 1.47.32 PM.png 120 KB View full-size Download
    • Each Dev will decide how many tasks they want to take ownership of for the weekly sprint (based on their schedule that week, how certain they are on scope, if they are feeling burned out, etc). The point of the weekly sprint is to work around you and be realistic. So if you're feeling off that week or need a quasi-break just commit to less tasks that week.
      • Please do your best to NOT over-estimate how much you can get done in a week. If you happen to finish all your tasks early, you have a few options:
        • You can reach out to another Dev to see if they need help with testing, blockers, etc.
        • You can use the extra time to think through and create a πŸ’‘ Pitch you feel would be impactful.
        • You can grab any small looking Bugs in the πŸ“‹ Backlog to squash.
        • You can work on any small code refactors you feel are needed.
    • When a Dev actually starts working on a task they should manually move the task from 🏁 Selected for Dev to πŸ§‘β€πŸ’» In Progress.
    • During the week, if a task from πŸ§‘β€πŸ’» In Progress is uncertain to get completed, please move it back toΒ  🏁 Selected for Dev so the rest of the team knows the task won't necessarily be completed before the next Monday meeting and we can all discuss what the blocker was.

Tuesday
Please continue working on your tasks.

Wednesday @ 1:15pm ET
We'll have a 15 minute (or less) meeting.

This will be a quick stand up meeting where every Dev goes around and talks about what progress they've made and what blockers are getting in their way. There should be very little discussion here, just more of a status update. For blockers, we want to strongly encourage all the Devs to actively follow up with anyone who is blocked after the meeting to assist where they can.

Thursday
Please continue working on your tasks.

Friday
Please continue working on your tasks.


⛏ Task Breakdown

  1. When there is a task issue that needs to be broken down, we'll add a task breakdown label to it and create a milestone:
    Screen_Shot_2021-05-14_at_12_30_17_PM.png 164 KB View full-size Download
  2. The end deliverable from a breakdown task is you'll create a number of new task issues within πŸ“‹ Backlog that all have the same milestone attached to them.
  3. When you finish the task breakdown itself, you should mark the original issue as Closed (it will automatically move to πŸŽ‰ Done).
  4. Please select the first broken down task you want to work on and move it to πŸ§‘β€πŸ’» In Progress and start working. βœ‹ If after doing a Task Breakdown the overall scope is much larger than anticipated, please ping
    Ryan Bennick Ryan
    or
    Ward Sandler Ward
    to let us know before you begin working on the tasks. This way we can assess if this milestone is still worth working on.Β 
  5. When creating issues from Task Breakdowns, it's easiest to do that within the πŸ“‹ Backlog so it's automatically added to the project board. Just click the "+" icon:
    Screen_Shot_2021-06-21_at_10_50_24_AM.png 464 KB View full-size Download

⚠️ Support Issues

  • Support posts issues to their message board just like they've been doing. Ryan/Ward will then ping the Dev team if it's an emergency that needs to be worked on ASAP. This should be very rare.
  • If the issue is not an emergency, Ward/Ryan will then add it to the πŸ“‹ Backlog for consideration in the current or next weekly sprint.

‴️ Pull Requests

βœ‹ When creating a PR, here are critical steps to keep in mind:
  1. Either link the PR to the corresponding task issue OR remember to close the corresponding issue after the PR is merged into Staging OR put "closes #<issue-num>" in the PR description to auto-close the issue when merging. Here are more details from Github.
  2. (OPTIONAL) Add other labels to your PR. We have an existing list of labels to use, but feel free to add new labels if you need more. By adding labels it can make it easier to search for your PR in the future πŸ‘€
  3. When your PR is ready for review, if you request a review from msupdatebot, that will automatically trigger a ping in the Dev campfire to get reviews from the team:
    Screen_Shot_2021-06-24_at_11_28_46_AM.png 397 KB View full-size Download
  4. When reviewing code, do NOT comment about styling - leave that for the robots. Remember, this is not your code.
  5. After there are at least two approved reviews, the owner of the task issue should merge the PR into Staging.
  6. When the PR is merged into Staging, the PR and the task will automatically be moved into the πŸŽ‰ Done column. The task will also be marked as closed automatically in Github:
    Screen Shot 2021-05-14 at 1.25.15 PM.png 82.4 KB View full-size Download

    One exception is when you are working on a task that is part of a milestone - the task won't necessarily have a PR into Staging. In these cases, when you finish working on the task, please close it (it will then automatically move to πŸŽ‰ Done).
  7. Please fully test your changes in Staging and also reach out to the Support team (by replying to an existing thread or creating a new one) to have them test as well. If you don't feel they need to test your changes that's your call, but generally the more people testing something the better πŸ‘€

πŸ›³ Merging Into Production

  • Every weekday at 3pm ET, we should merge Staging into Production. There will be an auto-reminder in Basecamp about this. Whoever sees it first, please create the PR and merge into Production.
  • If needed, you can merge Staging into Production earlier as well, but we want to keep up the default of always merging Staging into Production at 3pm ET so that we're not relying on ad-hoc merging.
  • βœ‹ Do NOT merge into Production after 4pm Eastern Time (unless it's an urgent bug fix).
  • After Staging is merged into Production, (if applicable) please let the Support team know about any issues you've fixed by responding in the Basecamp thread.