Welcome to Tech Talks. Hoping to have participants present on interesting topics in software development. Goal: Further our programming practice as Software Engineers. Art, Craft, Science, Engineering question -> good topic :)
“Revenge of the Programmers” : Phrase coined by Bertrand Meyer upon learing of Agile methodologies. What are programmers getting revenge against?
Development Methodologies: 1) Lightweight: agile world 2) Heavyweight: RUP, CMM, MILSTD world 3) Ad-hoc: What's a methodology? 4) Tailored: Take the best of all worlds to suit your situation...
Agile is a group of lightweight software development methodolgies. “Agile Alliance” created by representatives from various methodologies in 2001 on a ski trip in Utah. Fancy term for light weight.
attempts to reduce the pain caused by rapidly changing requirements
no more death marches to meet arbitrary deadlines
Communication: Most problems traced to miscommunication between team members.
Simplicity: What's the simplest thing that could possibly work? Feedback: Rapid releases, automated unit testing Courage: Admit failure, to refactor, to pair program
XP defines four project variables that affect the outcome of all software projects. Management can pin down any three of the variables, but not the fourth. Any software project were all four are dictated by management without developer feedback are likely to fail.
Good example: Fred Brooks classic “Mythic Man Month” describing the a death march to release IBM OS/360, added more junior programmers
On-site customer: answer questions, define needs, prioritize features
Small, frequent releases: early, constant feedback, easier to plan
Metaphor: Overall idea of the system, consistent naming scheme
Testing: test first design; automated unit, regression, and acceptance tests
Simple design: design for today, not for the future
Refactoring: goal is to keep design simple
Pair programming: peer review is good so do it all the time
Planning game: determine user stories, priorities, release schedule
Sustainable development: Never more than two weeks of OT in a row
Continous integration: avoids traditional big bang integration problems
Coding standards: Easier for all developers to understand whole system
User stories (requirements) from customer; input for acceptance tests
Spikes: a throw-away test program that addresses major uncertainties
Release planning: Overall project schedule meeting, based on user story estimates, move user story cards around on big table to set releases
Iterations: plan each iteration just before entry; follows from release plan; consider current project velocity (total of story estimates completed in an iteration), generate acceptance tests
Acceptance tests are black box system tests. Customer responsible for verifying correctness.
Roughly 1-3 weeks long
Initial planning meeting:
Choose user stories to complete based on customer priority
Handle failed acceptance tests from last iteration
Estimates for stories must equal project velocity of previous iteration
Break user stories down into programming tasks
- developers choose and estimate their tasks (1-3 days of ideal time)
- total estimates for tasks can't exceed project velocity (snow-plowing)
All estimates are encouraged to be accurate, low-balling doesn't help
May need to re-estimate all user stories and redo release plan every 3-5 iterations depending on requirements flux.
Daily stand up meeting
Short (no chairs)
Communicate problems and solutions
Promote team focus
Encourages communication between whole team
Replaces tedious meetings (can determine if private meetings are necessary, can remove need to even schedule official meetings)
Nearly immediate heads-up if individual is overloaded
Promotes collective understanding of system, sharing
Any developer can add functionality, fix bugs, or refactor
Reduces chance of one person becoming a bottle-neck
- Move people around to promote cross-training
Pair programming (proactive peer review)
- One thinks tactically about method, other strategically about system
Requires unit testing
- drives design; test first design ensures the simplest solution is built
- results in higher quality software, easier to refactor safely
Requires continous integration
- ensures unit tests are passing, catches problems fast!
- only one pair integrates at a time (sequential integration)
Allows constant refactoring to improve system (no more crusty code!)
Class, Responsibilities, Collaboration (CRC) cards are used find simple solutions to complex problems; use cards in informal design meetings
Don't plan with too much detail too far out. Set the right scope.
Feedback is critical to ensure the project is on track.
Most effective for responding to changing requirements and project conditions.
These are not necessarily separate people; can wear multiple hats.
Programmer: code, refactor, unit-test; strive for simplicity, communicate
Customer: domain expert, able to make decisions, write user stories
Tester: liase with customer to write, run, and report functional tests
Tracker: track estimates and schedule, log defects, provide feedback
Coach: responsible for process as a whole, steer the team (hands off)
Consultant: XP doesn't create specialists, hire them to teach team
Big Boss: courage, communication, occasionally oversight
Consultants love it because it leads to higher customer satisfaction by involving customer throughout project.
Same thing with custom software or in-house development.
But shrink wrap software usually has diverse customer base
Already do insane peer review & quality control -> space shuttle coders
Nailing down all four project variables, no place for XP feedback
Most experience indicates 20-30 is upper limit on team size
- Servidium had 30+ , New Architect article two teams of 50+ total
- Can you split up a big team into XP sub-teams? Issues?
Anecdotal evidence indicates that XP requires an experienced group of coders; junior teams don't do as well with XP
What is the affect on traditional architecture and design process?
What is the affect on traditional quality assurance process?
Currently research at the U of C on Distributed XP (Frank Mauer)
Refers to scrum from rugby (team working to common goal)
Originated in Japan in 1987 (Nonaka and Takeuchi)
Mentioned in software context by Degrace and Stahl in 1990
Applied to software by Schwaber and Sutherland in mid-1990's
Undefined (unpredictable, complex, dynamic) processes require different manage & control than defined (which CMM assumes)
Product Backlog: master list of all functionality (tasks and stories)
- in order of priority with time estimates for each
Sprint: an iteration (30 days) in which team has total freedom/responsibility to accomplish the goals
Sprint Backlog: The portion of the Product Backlog the team selected for completion during the Sprint
Tasks: Breakdown of items to complete to finish a sprint backlog item
Note absence of traditional roles like programmer, tester, architect, etc. Leads to discussion of Scrum team in next slide.
Like XP, Scrum uses cross-functional teams whose members have various strengths. All contribute.
Like XP, requires a small team to enhance communication
Inside sprint, team decides who will do which tasks, not dictated from management
Important point: During a sprint, the team has full authority to make any decision to meet sprint goal (within org conventions and budget)
Also have responsibility to meet the goal they have set for themselves.
Scrum doesn't dictate engineering processes that team must use, could do XP, RUP, whatever as long as produce results.
Use metascrums or “scrum of scrums” approach to scaling. Diagram shows 243 people in a number of scrum teams
This approach has be scaled to over 800 people by Jeff Sutherland.
Really two separate meetings... First between team and product owner (and other observers):
Product owner presents high priority items from product backlog
With input from all, the team selects the backlog it can do in next sprint
Identify a “sprint goal”: a short theme for the sprint (like XP's metaphor)
Team publicly commits to completing backlog in coming sprint
Second just the team and scrum master (product owner can observe):
As a whole the team creates a Sprint Backlog of tasks based on the Product Backlog items committed to.
Tasks should 4-16 hours of “ideal work” to accomplish (estimates)
Team self-organizes to assign the tasks to each other
Can modify sprint backlog throughout the sprint
Why daily? Brooks: “How does a project get to be a year late? A day at a time.”
Short (~15 minute) meeting held each morning at same time (stand-up?)
Only “pigs” can speak or ask questions, “chickens” just observe
- Joke: A chicken asks pig to start a restaurant called “Ham 'n Eggs”. Pig says “No thanks. I'd be commited, but you'd only be involved!”
Decisions: team has full authority to make any decision required to convert product backlog into product increment.
Any items requiring further discussion should fork off follow-up meetings of just those involved.
Scrum master plays role of meeting facilitator
Create peer pressure to accomplish what you commit to...
Main project metric is hours remaining to complete in a sprint. This provides a good measure of team progress.
If team finds itself overloaded in a sprint, it can call a meeting with the Product Owner to reduce that amount or scope of product backlog selected (like XP's snow-plowing)
A sprint can be abnormally terminated:
Management can decide sprint goal is no longer necessary
Team can cancel sprint if they face major roadblock or sustained outside pressure to modify sprint goal from external sources
A Sprint Review Meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the Sprint.
Empirical process control: better suited to complexities inherent in software development (more agile than CMM for example) Team controls their destiny: team sinks or swims together, have full authority and responsiblity -> allows good teams to be very productive
Socialization and knowledge transfer: team develops strong ties, open environment and scrum meeting lead to good knowledge transfer, pecking order in team changes minute to minute based on knowledge/expertise
Risk management: reduces risks of poor estimation, low customer satisfaction, not meeting commitments, not resolving issues, contanstly changing requirements
Management: requires management sponsorship and buy-in
Result varies between teams -> assumes you have good people who can work more productively (always hire the best you can get)
XP and Scrum are complementary:
XP is an engineering methodology (propeller heads)
Scrum is a project management methodology (PHBs)
Applied by TransCanada Pipelines on their development projects
- 300 people working on three large projects
Scrum manages project while XP ensures high quality
Evolved from supporting multiple projects which resused components
Can bridge gap caused by splitting up XP teams?
Hired as a consultant to IBM in '90s to determine best methodology:
- found successful teams apologizing for not following the process
- found failed teams thinking they didn't apply process correctly
Devised a family of Agile Methodologies for different projects
Reliance on people, communication, and frequent delivery of running code.
The methodology for 2-6 person projects is Crystal Clear, for 6-20 person projects is Crystal Yellow, for 20-40 person projects is Crystal Orange, then Red, Magenta, Blue, etc.
Does more in the way of documentation (particularly UML) as done by Peter Coad of TogetherSoft.
Three non-linear, overlapping phases in ASD.
Highsmith views planning as a paradox in an adaptive environment. (Draws heavily from chaos theory for his work)
Calgary is hot-bed of Agile development right now both in industry and at the U of C.
November 21 (6 -7 pm )
Agile Methods and Design: is software a big enough town for both of them? Martin Fowler (ThoughtWorks guru)
Agile Software Development Methodologies
Agile Software Development
Revenge of the Programmers?
Guy Davis – Pason Systems
Individuals and interactions over processes and
Working software over comprehensive
Customer collaboration over contract negotiation
Responding to change over following a plan
eXtreme Programming (XP)
Core Values Project Variables
Good for consultants, custom software dev.
What about other types of software dev.?
Misson or life critical systems?
Fixed price, fixed scope contracts?
Scalability of the XP process to large teams?
On-site customer possible for your project?
Team must be co-located? Distributed teams?
Solely controls the product backlog (prioritized)
Arbitrates requests from all customers
Does NOT control the sprint backlog
Enforces the values, practices, and rules of Scrum
Interface between developers and management
Removes impediments for developers
No traditional roles
Size: 7 people ± 2
Scaling Scrum Projects
Can follow any
Each team member answers three questions:
What have you done since the last scrum?
What are you planning to do before the next scrum?
What got in the way of doing your work?
Goals of this short meeting:
Identify impediments slowing progress
Make decisions collectively as a team
Track team progress during the sprint
Sprint Review Meeting
Demonstrate functionality added during sprint
Team, product owner, and customers attend
Product increment is assessed against sprint goal
Discuss successes and failures from last sprint
Short prep time for team (~2 hours; no M$ PP)
Empirical process control
Socialization and knowledge transfer
Team controls their own destiny
Management not used to letting go of the reins
Outcome dependent on the team (variable?)
Crystal Light Methods
Rank projects by # of people & error consequence
Adapt your methodology to your project's need
Use the least disciplined methodology that will still
dX: Hybrid between RUP & XP
An agile RUP-dervived approach (oxymoron?)
Inception: use-case cards, prototypes, velocity
Elaboration: iterative, UML, refactor, test
Construction: indistinguishable from elaboration
Transition: early release, active feedback
Helping drive sales of Rational's tools ($$$)
Deliver frequent, tangible working results
A feature defines a task
Group features into business-related sets
Focus on delivering features every two weeks
Track and report progress through feature
Plan, build, and design by feature
Adaptive Software Development
Deliverable-centric instead of task-centric
Calgary Agile Methods User Group
Monthly meetings at the U of C
Books (tons of these on Agile topics)
eXtreme Programming eXplained by Kent Beck
Agile Soft. Dev. with SCRUM by Schwaber et al.
Articles, discussion, information on the Web