User Stories

• The start of any project or application involves wanting to build something that people use
• Specifying how people will use it is the most common way we kick things off
• This step usually involves the definition of some kind of user "stories"
• A story takes the form of "A user should be able to do xyz"

Where it all begins...

Let's think of a new project and come up with some user stories

• What do we want people to be able to do?
• What stories are essential vs. nice to haves?
• Do some stories depend on other stories?
• Consider the use of simplifying assumptions

Modelling & Mockups

• Modelling an application will help define our database structure and relationships between data
• Mockups start with very low-fidelity sketches or drawings that try to define how the application will flow and what the users will generally see 

Translate stories to tangible "things" we work with

Modelling & Mockups

• Preliminary mockups can sometimes be started at the same time as preliminary modelling
• Front-end teams will tackle the mockups
• Back-end teams tackle the data and architecture

Translate stories to tangible "things" we work with

Modelling

• Some decisions made at this stage may be very difficult to reverse or change later on (think of building a house and needing to modify the foundation as opposed to repainting a room) 
• Think of how data is stored, and how it will be used
• Let's model our sample application! 

Mockups

• The first mockups should be very simple & lacking detail (or low fidelity)
• Lots of good tools around to help with this phase such as inVision or Balsamiq
• Over time, mockups can evolve into higher fidelity versions with much detail and polish
• This phase also considers branding & design ideas
• Let's take a look at some of their features

Methodologies

• When a project starts to be built, teams (or individuals) can adopt many different techniques or methodologies to try to get to the end goal
• The choice of methodology can greatly affect the outcome, timeline, and happiness of all involved

Starting the build (for real)

Methodologies: Waterfall

• Is usually referenced (today) as a development methodology that is flawed and not really "best-practice"
• Involves the creation of a very specific, detail-heavy specifications document that contains every detail of what needs to be built
• Development teams will not start building until specifications are clearly outlined within 

Starting the build (for real)

Methodologies: Waterfall

• Once initial specifications are defined, they cannot be changed or added-to until a following phase, which involves another "specifications" document
• Work flows down from: Requirements, Design/Architecture, Implementation, Testing and Maintenance (like a waterfall)
• Once phase is done we start over

Starting the build (for real)

Methodologies: Waterfall

• This may be a good approach for some projects, but for fast-moving web applications it tends to be very cumbersome
• It usually takes a very long time to get a phase released
• Changes are difficult along the way
• Specifications documents are usually "specifying" way too much (people fear a feature may never get into the application)

Starting the build (for real)

Methodologies: Agile

• More a modern set of values and principles rather than a "methodology" that can take many forms
• Agile development encourages change and quick evolution based on feedback/results/measurement 
• All these things are important in a fast-moving web environment

Starting the build (for real)

Methodologies: Agile

• Individuals and Interactions more than processes and tools
• Working Software more than comprehensive documentation
• Customer Collaboration more than contract negotiation
• Responding to Change more than following a plan

Starting the build (for real)

Methodologies: Agile

• Common Agile frameworks are Scrum and Kanban
• The key concepts of Agile development can be incorporated at various degrees of "compliance"

Starting the build (for real)