Mad Marmot A blog about programming, ruby, rails.

Agile Programming

Agile - What does it mean?

  • There are several recognized agile development methodologies, including XP (Extreme Programming), Scrum, Crystal, DSDM, and Lean. These approaches have much in common and share the following themes, which are the root of any agile methodology:

"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more."

- from http://www.agilemanifesto.org

  • A common myth is that agile programming is about creating software faster. This is NOT true! Agile programming is about creating better software to increase business value. It may happen that agile programmers create software faster, but this is not a focus of agile development. Often a hard deadline is chosen for the completion of a project well before the team has any idea how long it will take to complete. Agile programming is about delivering better software on time, within budget, in such a way that maximizes business value.
  • Agile methods embrace change. They are structured with the knowledge that the requirements will change as the project progresses.

Common Agile Techniques

Overall

Direct involvement of customer(s) during development

  • Extremely important to deliver what the customer needs and to obtain feedback from the customer throughout the development process. More valuable than a requirements document or spec.

ContinualProcessImprovement

  • Important to recognize that choosing one of the established agile methodolgies such as XP and trying to use it exactly isn't always a good idea. The makeup of the team and the constraints of a project may not be a suitable matchup for XP. It is more important to continually reflect and improve a team's process.

Requirements

User Stories

  • Software requirements is a *communication problem.*
  • The best way to solve this *communication problem* is for the programmers to work directly with the user/customer who sets the requirements and to involve the user/customer as much as possible. Nothing is more valuable in creating software than demonstrating the software to the user/customer well before the deadline is due.
  • User stories are an excellent way to represent requirements.
  • Traditionally written on a 3x5 note card.
  • Ex.
    • As a crew member, I want to upload ammunition so that the vehicle can be resupplied.
  • Template
    • As a USER ROLE, I want to GOAL so that REASON.

Planning

Focus on Features and Business Value

  • Agile teams focus on separating a project into features, ordering them by customer priority (business value), and implementing the features in order of priority. A useful technique is to keep a *backlog* of features ordered by priority that have yet to be completed.
  • Ron Jeffries, one of the founders of XP, said that a sign of an agile team is the ability to work on features in any order. Of course this is not always possible as sometimes one feature will absolutely depend on another.

Short Iterations with Releasable Code after each iteration.

  • Short means 1 to 2 week iterations. New features are completed (and tested) with each iteration, and at the end of every iteration the code is in a releasable state. Programmers are confident the code is in a releasable state since they are doing Test Driven Development. It may actually take more work to do a release, such as user manual documentation.
  • Showing the customer the product as soon as possible and getting feedback after each iteration is extremely valuable.
  • A release is composed of several iterations, however with short releasable iterations the manager has the flexibility to choose to release at any time.

Estimating with Story Points and PlanningPoker

  • Ideal time vs. elapsed time
    • An ideal day assumes the programmer can work for 8 hours without interruption whereas a normal day assumes interruptions, email, and other various tasks.
  • Estimates should not be done in elapsed time. It is too hard to estimate in elapsed time since you have to consider all the factors that affect elapsed time (ie. other projects to work on, #emails received per day, meetings, phone calls, donuts, sick days, vacation, hangovers, etc.)
  • Story Points
    • An alternative and highly recommended approach to estimation is to estimate the relative size of features (user stories) using story points. *Relative size is all that is important, not the length of time to complete a feature*.
    • An effective and fun way to accomplish this in a group is to play *PlanningPoker*. Everyone estimates a story at the same time by laying down a card with a number on it. Each person discusses and backs up their estimate and then another round is done until the estimates converge.
    • The end result does not include how long each feature will take... this is determined using Velocity-Driven Iteration Planning.
    • There is considerable value in the discussions that take place amongst the team during PlanningPoker.
    • People can agree on relative size, but not time (since different skill levels develop at different speeds).
  • Ideal time vs. Story Points
    • story points are a pure measure of size
    • can estimate faster with story points
    • Joe's ideal time can not be added to Bob's ideal time (ideal time is not normalized between people)
    • people can agree on size, but not time
    • ideal time can force manager's to confront time wasting activities
    • story points avoid the question of who is implementing the feature and arguments on why Joe can do something faster than Bob
    • neither can be used directly to determine when the project or features will be complete for scheduling purposes!

    Velocity-Driven Iteration Planning

    • The team's current velocity is how many story points they finished in the previous iteration. To estimate the length of the project the team monitors their current and average iteration velocity to predict when the project will be completed (ie or how many of the features will be done by the release deadline).
    • The focus is on the team's velocity, not an individual's. This encourages pair programming, collective code ownership, and team cohesion.

Burndown Charts

  • Visually shows the progress of the team in completed story points.

Coding

Test Driven Development (TDD)

  • This means writing tests first and *treating test code to be just as important as non test code*.
  • Having a large suite of tests that can be ran quickly in a regression manner is extremely valuable. It gives the programmer confidence that their code works as expected the first time it is written as well as with each change/refactoring that is done to the code. Writing tests also help the programmer to consider unexpected possibilities.
  • Unit tests serve as documentation on how the coder intends a module to be used.
  • Writing code that is testable via TDD causes code to be designed well (low coupling, high cohesion, understandable interfaces).
    • Bob Martin says it well “The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function”.
  • A good analogy comes from accounting. With a software program, if 1 bit is wrong it can wreck the entire 2-million bit program. Accounting must be just as accurate. To do this accountants use a technique where they add up totals in two columns, one from a credit perspective and one from a debit perspective. When they are finished if the result of the two columns do not sum to zero then they know they made a mistake.
  • TDD emphasizes small steps. Example:
    • Big refactorings can be chaotic, get out of hand quickly, and affect dozens of files in intricate ways. With TDD the programmer does this loop about once every 10 minutes which encourages steady controlled progress:
      • Update existing test or add a new test
      • Run test to verify that it *fails*
      • Refactor 1 method in business code
      • Run test to verify that it *passes*
  • TDD is like rock climbing while wearing a harness and attached to a rope... it catches you when you fall. Not doing TDD is like free-climbing...

Automatic Build and Test

  • The project code is checked out, built, and all the tests are ran several times a day.

Continuous Integration

  • Waiting to "integrate" is a horrible practice. Through the use of a version control tool such as cvs or svn, teams regularly practice continuous integration

Pair Programming

  • An excellent idea from XP that has huge benefits, yet very few teams actually use this technique. Side-by-side programming, or smaller doses of pair programming are possibly more realistic for many teams. See Pair Programming.

How do Peer Reviews fit in to an agile process?

  • In Crystal Clear, Alistair Cockburn mentions that the best teams work closely together (same room is best), often doing side-by-side programming or pair-programming. The best teams are reviewing each other's code continuously as a matter of normal development and there is no need for a formal peer review. Instead they like calling it *peer code peering*. Time is better spent *working together* and writing automated tests to catch defects than formally going through code line by line with a group.
  • Jens Norin, an agile coach, Scrum Master and, agile contractor claims that agile teams do not need peer reviews in his article | Peer Reviews - a bad bad thing.
  • The | Extreme Programming viewpoint is that peer reviews cause harm by creating a stressful situation in which people's work is formally critiqued. Conducting peer reviews continuously throughout normal development via pair programming, side-by-side programming, or simply *working together* accomplishes the same thing without hurting people's feelings and thus creating a negative environment.
  • This | .NET link on peer reviews points out that keeping peer reviews as informal as possible is very important. (This contrasts with the very formal approach of Fagan Inspections).
  • Ron Radice wrote a book on peer reviews and | this article summarizes his book. From reading through it he clearly assumes that the team is following a waterfall approach.
  • My opinion? Peer reviews are usually a waste of time. You may find a few defects with the code, but there the value stops. Code changes frequently, and when it does are you going to hold another peer review? With tests you will find the same defects and the test lives on, continuously verifying that your code is doing what you want it to. Formal Fagan inspections simply take too much time for the one-day that they provide value. A good test suite will provide value throughout the life of the code.

Scrum Meetings

  • Scrum has only 3 types of meetings. No peer reviews, inspections, inception reviews, etc. I summarize the meetings below. A more detailed description can be found at http://www.scrumalliance.org/index.php/scrum_alliance/for_everyone/what_is_scrum/scrum_ceremonies
  • Sprint Planning Meeting
    • The Product Owner (customer representative or customer proxy with vision of product) organizes a meeting. Purpose is to turn requirements into features, prioritized on the backlog, with team members committed to developing features in the timespan alotted by the sprint length.
  • Daily Scrum meeting
    • 15 minute meeting daily to clarify the state of the project. Each person says what they did yesterday, what they are doing today, and any impediments in their way.
  • Sprint Review
    • 1st half of meeting: At the end of each sprint (iteration) the potentially shippable code is demonstrated to the Product Owner.
    • 2nd half of meeting: A retrospective -> how can team/process improve. What worked well and what didn't.
Comments (0) Trackbacks (0)

No comments yet.


Leave a comment


No trackbacks yet.

Tags