Skip to content

Latest commit

 

History

History
270 lines (174 loc) · 13.4 KB

README_BOILERPLATE.md

File metadata and controls

270 lines (174 loc) · 13.4 KB
Raw

Welcome to Blue Ocean

Congratulations and welcome to your first day at Blue Ocean!

At Blue Ocean we believe in the Agile software development process. You will be placed on a brand new project where we'll be using Agile tools to design, develop and deploy a finished product.

Let's begin our tour (don't blink!)...

Objectives

  • Apply Modern Agile Practices
  • Use Modern Github Workflows
  • Use Modern Development and Deployment Workflows

Your Agile Process

Expect this project to push you outside of your comfort zone. Welcome to your first day of life as a professional developer with a professional workflow.

You will be interacting with and playing various roles consistent with an agile work enviroment. We expect you to build software meeting each of our standards over the next week.

Minimum requirements

  • Build an application around an idea from an external end-user

  • Create a backlog of tickets to work through during the week

  • Participate in a Sprint Planning and a Sprint Retrospective

  • Attend Daily Standup Meetings

  • Meet Acceptance Criteria determined by the user

  • Minimum of 60% test coverage. Tests include unit and integration tests.

  • Use contiuous integration and continous delivery practices

    • Deploy early, and often
    • Always have a working application in master

  • Create a professional quality Github repo including a Readme, Test Coverage, and Clean Code.

  • At least 50% of the tickets you worked on should be done with a pair. (Include co-authors in your commits)

We're here to help guide you through this process...and potentially throw some wrenches in as well ;)

Meetings and Expectations

DAY 1 - Kickoff and Problem Exploration

ideation

This is our meeting to discuss and plan the projects as a whole, and to lay out the process for the remaining days worth of work.

Everyone plays the role of full-stack developer in this agile enviroment, some folks will have additional roles:

(see Roles for additional information)

  • Product Manager (Elected by team)
  • User (If your idea is used by a team)
  • Architecture Owner (Elected by team)
  • UI Owner (Elected by team)
  • Developer (everyone)

You cannot work on an idea of your own. Instead, if a team is working on your idea, you will have an additional role in that team as an end user.

DAY 1 - Meet the end user!

Deliverables:

  • Project proposal
    • Description of the project
    • Project Name
    • What problem does it solve?
    • User Inputs/Outputs

Submit this form

DAY 1 - Sprint Planning and Proposal for Approval

Deliverables:

  • Team roles
  • Starting technology stack and deployment strategy
  • Trello board with initial tickets assigned to team members
  • MVP Components and wireframes

During this meeting, each person will share with their team:

  • What you feel you can help others with
  • What you feel you need to work on
  • What you enjoy doing the most
  • What additional role you would like to take on in addition to 'developer'

Then you will elect roles, and discuss the project to flesh out your technology choices.

By the end of this meeting, you will have MVP components that are broken down in to user-story tickets, with some setup and starter code tickets. The team will have a clearly defined scope of work, wireframes, and initial tickets chosen.

The process looks like this:

Idea -> MVP Components -> Wireframes(Facilitated by UI owner) -> User Story Tickets -> Conversation Section (for later review with user) -> Acceptance Criteria

After the starting tickets are in, your team will work with instructional staff to assign points to each ticket. It is everyone's responsibility to ensure that we meet this goal together!

MVP Components will involve the outside user who came up with the idea to join this meeting.

There should be no more than 3-5 primary features that constitute MVP for the project.

Do this as a team!

DAY 1 Follow Up with End user

Deliverables:

  • Validated user stories and wireframes
  • Acceptance Criteria for each user story

During this meeting, your product manager and UI owner will need to ensure with the user that each user story ticket, and wireframe is consistent with the MVP.

This is also the time to get specific user story questions answered and documented under a 'conversations' section of the ticket.

Once all questions are answered, create user acceptance criteria.

Daily Standup

These will happen at 10AM daily. As a group you will sort any tickets added to the inbox and move them to "To Do" if approved, then...

Each person will go in order, and tell the group:

  1. What they worked on the previous day and if they have work that needs review
  2. What they intend to work on today
  3. If they are blocked by anything
  4. If they need to have a breakout with any individuals after standup for a specific question, blocker, or decision

DAY 4: User Testing & Acceptance

During this meeting, your user will test your app to find bugs and areas where the work doesn't meet expectations. From there, users will work with the team to create some new tickets and point out areas for improvement.

DAY 7: Sprint Review

The final piece of the puzzle. Each team will discuss what worked well, what didn't, areas for improvement, and where the project currently stands. The goal of this meeting is to leave with action items for the next iteration of the sprint both in terms of process and the product as a whole.

After the sprint review, it will be up to you as a team to make sure that your Github Readme is well-written and your team's code is clean and well-tested. Ultimately, you should feel comfortable and confident sharing this work with any employers who ask to see your recent projects or code.

ROLES

Product Manager (Elected by team)

The product manager helps faciliate work efforts, manages tickets, and tracks progress towards completing all tasks scheduled for the current sprint.

Oversee the ticketing system

Ticketing will be done using Trello. Here is an example board for you to copy for your team: Example Board. When you start, there will be a few high level user stories. You and your team might realize that it needs to break those down into smaller tickets, or that additional tickets will need to spawn for setup and configuration of new systems.

  • Write the user story tickets with the team for Day 1 (it is not normally done with the entire team, but do this so that everyone learns from the experience)
  • Walk your team through all of the tickets for Day 1.
  • You will also collect questions the development team might have for the user on specific user stories. The questions and the answers to those questions will be stored in the ticket under a "conversation" section.
  • Facilitate ticket assignments with the team, ensure tickets are assigned to team members
  • Ensure that team members are following the ticketing system, correctly adding new tickets, and moving tickets to the correct areas.

Meet with user(stakeholder)

The goal here to is get solid clarity on what the user has envisioned and how it should be described in the tickets. This way the development team can look at a ticket and know exactly what to do.

  • Meet with your user to ensure that each user story ticket is consistent with the MVP.
  • Get answers to questions from development team concerning each user story.
  • Adjust user stories accordingly
  • Develop acceptance criteria based on answers from the user.
  • Facilitate between UI owner and user to update any wireframes

Run Daily Standups (see daily standups)

Some tips on creating user stories

Some great advice on creating user stories...

INVEST: The attributes of a solid user story INVEST is an acronym that helps evaluate whether you have a high-quality user story. Here's how the attributes in the acronym apply to the story we’ve been working on.

I = Independent—Can this story be completed by the team? We want the team to be able to complete the whole story rather than be dependent on a different team to do the GUI, for example.

N = Negotiable—The story is not so detailed as to describe exactly how long the fields should be or give specifics about date formats and the like. Most likely there will be common routines or libraries that will allow the development team to implement in the way that makes the most sense for them.

V = Valuable—The product owner describes that the value being sought... This is clear in the "why" of the original statement and re-emphasized in the conversation.

E = Estimable—The team will ask enough questions and gather the details to feel confident in their ability to estimate the story.

S = Small—The team needs to feel confident that they’ll be able to complete the story within a sprint. If they do not, they might split the story. For instance, in our sample story, they may decide to make the ability to gather the student information be a different story and simply display information about the class for this story.

T = Testable—With clear acceptance criteria, both the happy path and error conditions can be tested.

Important concepts

Happy path - What is the ideal path of interaction that a user takes when interacting with a feature, ignoring edge cases. It is helpful to think about this first in order to quickly develop a user story. e.g. in an ideal scenario, when a user does x, y happens

Vertical Slice - User stories should be a vertical slice of the application (full stack)

Stakeholder & User (If your idea is used by a team)

Attend that teams' sprint planning for the first 10-15 minutes

Confirm idea and features that constitute an MVP.

Attend User(stakeholder) Meeting for that team

  • Confirm user stories
  • Answer questions that help project manager derive acceptance criteria
  • Validate wireframes

Architecture Owner (Elected by team)

You will faciliate with the team on agreeing upon the overall tech stack and making sure the team is informed of any system changes.

You will also faciliate and ensure team members are consistent with build tools, linters, workflow, and commits.

UI Owner (Elected by team)

You will develop the initial wireframes that will help generate and ultimatey accompany the user stories.

Design/Wireframe Resources: Figma Figma Design School Example- Chickpeach Design Sheet

Developer (everyone)

If your only role is as a developer remember that you don't live in a box, you will help support all of the roles above as best you can. However, you will defer the decisions and reposibility of the areas concerning those roles with the person in that role.

Follow your team's best practices and be a steward of a clean, readable code base.

You will also naturally find areas that you gravitate towards or find yourself more specialized in. Be sure to make that known and pair accordingly to help others and recieve help. Software development is a team effort!