D#007 - Development Process Handbook

Size: px

Start display at page:

Download "D#007 - Development Process Handbook"

Charity Rice
5 years ago
Views:

1 Last Updated: 04/30/2018 Status: Live D#007 - Development Process Handbook Purpose: Clarify how we handle an incoming or internal request for a feature or enhancement all the way through shipping the feature or enhancement. This is a living, breathing document. If you have any questions, please feel free to annotate the document with a comment. Please keep this document open on your computer for reference while working on a feature or enhancement. Pre-Sprint Planning Meeting Activities Step 1: Determine a need for a feature or enhancement. Step 2: Prioritize a task on a scale of Step 3: Determine if we have enough information to implement the task. Step 4: Create a task in Trello. Step 5: Estimate how long this feature will take. Sprint Planning Meeting Activities Step 6: Prioritize Backlog items in Trello. Step 7: Determine Sprint Length and Move Items from Product Backlog to Sprint Backlog. Post Sprint Planning Meeting Activities Step 8: Select Task and Write Code. Step 9: Developer Tests Implementation. Step 10: Request a Code Review. Step 11: Send out Test Build (Internally) Step 12: Send out Test Build (Externally - Client) Step 13: Ship it live!

2 Pre-Sprint Planning Meeting Activities Step 1: Determine a need for a feature or enhancement. What is a feature? A feature is new functionality for the user. It is a user story, path, or implementation that cannot be performed in the current application. What is an enhancement? An enhancement involves improving a pre-existing feature/function or adding new functionality in a way that is not significant enough to be considered a new feature. For the purpose of this document, we ll include refactoring and rewriting code as an enhancement. How is a need for a feature or enhancement determined? An idea from a client or our team. Feedback from the client or our team. Operating system and/or library updates that require new implementation of an existing feature or that require an enhancement to a current feature. Operating system improvements and/or new API that allow a new feature or enhancement to be possible. Step 2: Prioritize a task on a scale of Determining priority of a feature or enhancement allows us to determine which tasks are highly urgent and which ones can be put off until we accomplish more high profile tasks. We use 1 as lowest priority and 10 as highest priority. If the request is from a client, we should get their perceived priority of the enhancement on a 1-10 scale. Often a client will give feedback in one of the following ways: 1. Hey, I was thinking about the app and think X would be a really good feature to add down the road. 2. Hey, I was playing with the new feature and we were thinking that it should do X instead of Y. That would make more sense to our end user. 3. Hey, I was testing the new app and noticed X issue when I went to this screen. (see bug reporting on how to handle this feature.

3 If a client does not provide a priority of a feature, it s important to ask them. Hi <Client>, We ve noted that feature and will move it to our backlog. Do you mind giving me an idea for how important this feature is to your team on a scale of 1-10? 10 being highest priority. Thanks! Sometimes we might need to take matters into our own hands and prioritize a feature or enhancement for the client. We should do this when there is a major security risk that could make the client or Broadway Lab liable for damages, or there might be other required work (i.e. refactor/rewrite, other implementation, software update, etc.) before we can implement the feature or enhancement. Step 3: Determine if we have enough information to implement the task. Have you received enough information to implement the task per the client s requirements and requirements from us internally? If so, move to step 4. If not, ask questions! We would rather over-communicate to make sure we re building the right thing as opposed to having to redo work because we did not fully understand the requirements. If you need more information about a feature or enhancement you can do one of the following: the client or team with questions. Chat with the client or team over the phone. Communicate with the team internally via Slack. Communicate with the team internally via Trello comments. Tip: If you re not receiving a response from a team member and it s blocking you from doing more work, you should attempt to contact them via phone or skype. In general, urgent communication should be completed over the phone. Once you ve received enough information to complete the feature or enhancement, move to step 4.

4 Step 4: Create a task in Trello. All tasks in Trello should correspond to a feature or enhancement. When creating a task, a Trello card should have the following information: The title of the card. A unique identifier for the card (used for git branches and commit messages) See how we use Git here An estimated duration for how long that task should take. A description of the card if there is not enough information in the title to determine the acceptance criteria for the task. Relevant attachments and screenshots that would be helpful during development or QA. The most important question you can ask yourself when creating a task in Trello is, Can a reasonable person who has no prior experience of this feature easily know how to test it? You ll be doing our QA team a huge favor and making sure you clearly understand the feature or enhancement requirements. Here is an example of what a task in Trello would look like: #PROJ-1: Convert the main navigation hamburger menu on the home page to a tab bar. Estimate: 5-7 hours New features and enhancements should be created in new trello cards and be added to the Product Backlog list. A bug or enhancement that is required to be completed before that feature can be shipped should be added to the current card. I.e., no new card should be created. Step 5: Estimate how long this feature will take. Estimating helps us ensure we re not biting off more than we can chew. It allows us to set a cost for a feature. As priority on a 1-10 scale is the benefit, the time to complete is the theoretical cost of development. When estimating a task, we would rather over-estimate how long a task is going to take as opposed to underestimating. This is in-line with the under promise; over deliver philosophy and ensures our clients are getting value from the software we re producing based on what they re paying for our services.

When estimating, using a range is appropriate. Feel free to estimate a range in any of the following units: Hours Days Weeks Months/Unsure (not a closed bound problem).

5 When estimating, using a range is appropriate. Feel free to estimate a range in any of the following units: Hours Days Weeks Months/Unsure (not a closed bound problem). Note: If the estimate is taking months or you are unsure how long it s going to take, that s probably a red flag that this task is not narrowly defined enough, and it should probably be broken down into smaller pieces. Break down the card into smaller tasks and/or consult your manager on the best way to proceed. This article from Karl Wiegers provides some useful tips when estimating a feature or enhancement: Sprint Planning Meeting Activities Step 6: Prioritize Backlog items in Trello. In order to know what is most important to work on, we have to be able to prioritize the tasks accordingly in the backlog according to our feature/enhancement prioritization matrix. The matrix below determines a score for prioritizing what to work on. Each row is numbered and colored to give you a better idea of how value and investment (time) are weighted. High value/low investment tasks (#1) are the top priorities and low value/high investment tasks (#9) are the lowest priority. It s important to note, we should avoid working on any feature in a red cell because these are of low value to our client and will require a high investment. Feature/Enhancement Prioritization Matrix

6 Step 7: Determine Sprint Length and Move Items from Product Backlog to Sprint Backlog. Once the entire backlog is prioritized, determine which items to include in the sprint. Typically, you should start at the top of the Product Backlog and work your way down when selecting a task. Occasionally, you may choose a shorter investment task to squeeze into a sprint for time purposes. Ensure the selected tasks can be completed within the sprint. It s generally a good idea to leave a few days as a buffer for bug fixing, testing, and requirement changes.

7 Post Sprint Planning Meeting Activities Step 8: Select Task and Write Code. When selecting a task, perform the following actions: Move the card from Sprint Backlog to In Development. Assign yourself to the card. Double check the estimate and requirements. Make sure the estimate is still reasonable and the requirements are clear. Follow our proper git protocol and create a new branch. Find a quiet, productive place to work (TODO: Insert blog post about effective remote work environments.) Put on some great music (I love the Brain Food playlist on Spotify) and start coding! As a side note, if you find yourself blocked on a task, determine what information you need to continue. As you wait to receive the needed info to proceed, label the card as blocked and move on to a new card. If you need to, select a card from the backlog. Step 9: Developer Tests Implementation. Once code is complete, then the developer writing the feature needs to test the implementation. This is just the developer testing on their machine in the development environment. The card is still in In Development on our Trello board. This is the first line of defense for catching bugs. As always, it s a good idea to check your own work before sending it over to a teammate for review. If the feature is implemented without apparent issue, attach a pull request and request a code review. Step 10: Request a Code Review. Have another team member perform a code review. Attach a pull request to the Trello card. Request a code review in GitHub: If pull request is approved, Move the Trello card for the task from In Development to Finished Development. If the pull request is not approved, address issue and go back to step 8.

8 Step 11: Send out Test Build (Internally) QA tests a feature as it is done, so you ll need to attach the branch to the Trello card so they can access the build. Read, Distributing Internal Builds on Mobile and Web for full details. Step 12: Send out Test Build (Externally - Client) Step 13: Ship it live!