Skip to content

notes.md

Latest commit

 

History

History
112 lines (100 loc) · 6.69 KB

notes.md

File metadata and controls

112 lines (100 loc) · 6.69 KB

Agile Programming using Test & Behavioral Driven Programming Techniques

Overview

In this class, we will cover:

  • What is the Agile development process
  • How does it differ from other technologies
  • Implementing Agile using Scrum
  • Using Behavioral Driven Programming to write a simple customer facing application
  • Using Test Driven Programming to write back end systems

This class will do some simple (very much beginner level) programming. The emphasis will be on the overall process of Agile to produce a simple, but working program. Lunch is included in the cost, and you will be provided a USB key with a working environment with all code working and all lecture materials. You are encouraged to come early, and get set up to follow along on your own laptop.

Agenda

  • 9:30 - 10:00 Setting up a working environment so you can work along with the class
  • 10:00 - 12:30 Morning Session. This will be most of the project management content
  • 12:30 - 1:30 Lunch
  • 1:30 - 4:00 Afternoon Session. This will be implementing what we learned in the morning
  • 4:00 - 4:30 Question

Definitions

  • Scums (Agile isn’t Scum, but one of the tools that can use the boiler plate of
    • Roles
    • Meeting
    • Artifacts
    • Reports
  • Principles of Good Project Management
    • What “Project Management” is not
    • PM is NOT about tools
    • Principles of good project management
    • There are no technical projects
    • Get involved early
    • 1 hour of planning today will sea you at least 2 hours of work tomorrow
    • if it’s not written down it didn’t happen
    • Don’t kill the messenger!
    • Address all issues, do it quickly and don’t stop until a resolution has been found
    • Don’t be afraid to replace bad people
    • Lead by example
    • Don’t compartmentalize your staff
    • Don’t lose your focus
  • Setting Expectations
    • Understanding what you are asking for
    • promise what you can deliver and deliver what you are promised

Agile Methodology

  • Overview
    • Some of these techniques trace back to late 1950s (1957, written in 1970s)
    • Has gone through many forms over the years
    • Described as lightweight vs heavy process of Waterfall —> process is still heavy, but it allow flexibility. Process of a 1000s steps
    • Stresses many smaller iterations vs one large one
    • Really narrowing down my scope
  • Process (Agile = PM counter part)
    • Discover = Requirements
    • Modeling
    • Implementation
    • Test = Test
  • Manifesto:
    • Individuals and interactions over Responding to change
    • Working software over Comprehensive documentation
    • Customer collaboration over Contract negotiation
    • Responding to change over Following a plan
  • Principles behind the agile manifesto
    • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
    • Welcome changing requirements, even late in development. Agile process harness change for the customer’s competitive advantage
    • Deliver working software frequently, from a couple of weeks to a couple weeks to couple of months, with a preference to the short timescale
    • Business people and IT need to work often
    • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
    • The most efficient and effective method of converting information to and within a development team is face-to-face conversation (Video Conf, IM,)
    • Working software is primary measure of progress
    • Agile process promote sustainable development.
    • Continuous attention to technical excellence and good design enhances agility
    • The best architecture, requirements, and designs emerge from self-organizing teams.
    • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior

SCRUM

  • Roles
    • External Stakeholders —> Anyone who has a stake in the outcome!
    • Product owner —> Ring Leader!
    • Scrummaster (or facilitator)
    • Development Team
  • Backlog refinement meeting
    • Attendees: Everyone
    • Takes place at the beginning of the project, then approximately a few days before each sprint Planning Meeting. All Stakeowners are welcome at this meeting to review and have input on the task items, and their relative priority. The result is the product backlog list.
  • Sprint Planning Meeting
    • Attendees: Product Owners, SCRUM Master, Dev Team
    • Takes place at the start of each sprint. The team meet with the product owner and discuss the next set of highest priority items from the product backlog. The result of this meeting is sprint backlog which contains the stories broken down into tasks with estimates for each task. The team also agree with the product owner the commitment for the sprint and the sprint goals. This commitment is generally based teams know velocity.
  • Daily Scrum
    • Attendees: Product Owners, SCRUM Master, Dev Team
    • the team meet for a max of 15 mins per day with the scrum master around the team task board. Team members update the task board, align with each other on tasks and answer 3 questions. What have you done in the last 24 hours, what will you do in the next 24 hours and what is getting in your way.
  • Sprint review meeting
    • Attendees: Everyone
    • Takes place at the end of each sprint. The team meet with the product owner and demonstrate the working software produced during the sprint. this allows the team and product owner to inspect and adapt the product.
  • Sprint retrospective meeting
    • Attendees: SCRUM Master, Dev Team
    • Occurs at the end of the sprint.
  • Vision Statement
    • Everyone needs to be on the same page
  • Product Backlog
    • this is the list of the all the requirement know about for the system whether they be functional or non-functional. this list must be prioritized and it describes the what of the system. Requirements are often described using a technique called user stories. the product back log is always in flux and can be changed and re-priotized
  • Sprint Goal
    • The vision of the current sprint. This is an agreement between the team and the product owners and helps the team to meet the objectives for the sprint. Sprint Backlog — The team break the product backlog items down into the tasks they need to do to complete the backlog item. This is the how of the system.
  • Sprint BurnDown
    • A visual representation of the teams progress for the sprint. this allows the team, scrum master and the other interested parties to see the current progress.
  • Task Board
    • Not technically a scrum artifact but I believe that is vital. It allows the team to be transparent with its progress. It creates a focal point for the team; daily scrums can be held around it and it aides and focuses communication. You can also expand it with your impediments and sprint rundown charts