XMind

Agile Development (Extreme Programming)

Study note of the book Agile Principles, Patterns, and Practices in C#, Section I by 弱菜逆铭

1. Values

   1. Individuals + Interactions > Processes + Tools

      1. Working Well With Others + Communicating + Interacting > Raw Programming Talent

   2. Working Software > Comprehensive Documentation

      1. Documentation

         1. Short Rationale

         2. Structure Document

            1. Short: One or two dozen pages at most

            2. Salient

               1. Overall Design Rationale

               2. Only the Highest-level Structures in System

      2. Code & Team - Best "Documents" to New Comers

      3. No Document Unless Its Need Immediate & Significant

   3. Responding to Change > Following a Plan

      1. Ability to Respond to Change - Decisive!

      2. Better Planning Strategy

         1. Next Week: Detailed Plans

         2. Next 3 Months: Rough Plans

         3. Beyond: Extreme Crude Plans

2. Principles

   1. Highest Priority: Satisfy the Customer Through Early & Continuous Delivery of Valuable Software.

      1. Less Functional in Initial → Higher Quality in Final

   2. Welcome Changing Requirements - Even Late in Development.

   3. Deliver Working Software Frequently.

   4. Businesspeople and Developers Must Work Together Daily Throughout the Project.

   5. Build Projects Around Motivated Individuals. People are the most important success factor.

   6. Convey Information Through Face-to-face Conversation - Most Efficient & Effective.

   7. Working Software is the Primary Measure of Progress.

      1. Not documents or infrastructure code

   8. Sustainable Development: Be Able to Maintain Constant Pace Indefinitely.

   9. Continuous Attention to Technical Excellence & Good Design Enhances Agility.

   10. Simplicity is Essential: Take the Simplest Path Consistent with the Goals.

   11. Self-organizing Teams → Best Architectures, Requirements & Designs.

       1. Responsibilities communicated to the team as a whole.

       2. Team determines the best way to fulfill those responsibilities.

   12. Reflect on How to Become More Effective at Regular Intervals, Then Tune & Adjust Behavior Accordingly.

3. Practices

   1. Whole Team: Work Closely

      1. Customers

         1. Customer Can't be Close by: find someone else who

            1. can be close by

            2. is willing & able to represent true customer

      2. Managers

      3. Developers

   2. User Stories

      1. A Mnemonic Token

         1. Conversation with Customer: Get Sense of Details of Requirements

            1. No Need to Catch Specific Details

            2. Customer

               1. Write Some Words as Reminder of Conversation on an Index Card

            3. Developer

               1. Write an Estimate on the Card Concurrently

      2. A Planning Tool

         1. Schedule the Implementation of a Requirement

            1. Based on

               1. Priority

               2. Estimated Cost

   3. Short Cycles

      1. Iteration

         1. Usually 2 weeks in length

         2. Plan(see "Planning")

         3. Stories Can't be Changed Once the Iteration Starts (neither description nor priority)

         4. Minor Delivery

            1. Demonstrate to Stakeholders to Get Feedback

            2. May or May Not Be Put into Production

      2. Release

         1. Usually 3 months in length (6± iterations)

         2. Plan(see "Planning")

         3. Stories Can be Changed at Any Time (cancel, add new or change priority)

         4. Major Delivery

            1. Can Usually be Put into Production

   4. Test-Driven Development

      1. White box tests

         1. Knows and depends on internal structure of the module being tested

      2. All Production Code is Written to Make a Failing Unit Test Pass

      3. Simple Rules

         1. Don't write any production code until you have written a failing unit test.

         2. Don't write more of a unit test than is sufficient to fail or fail to compile.

         3. Don't write any more production code than is sufficient to pass the failing test.

      4. Effects

         1. Every single function has tests that verify its operation

            1. Backstop for further development: Help to ensure nothing has broken when making small changes

            2. Greatly Facilitates Refactoring

         2. View the program from the vantage point of a caller

            1. Design the software to be conveniently callable

         3. Design the program to be testable

            1. Decouple the software

         4. Compilable and executable documentation for the internals of the system

      5. Doesn't verify system works properly as a whole (that's what acceptance tests do)

      6. Tool

         1. NUnit

   5. Acceptance Tests

      1. Black box tests

         1. Does not know or depend on the internal structure of the module being tested

      2. Writing the Tests

         1. Written by folks who do not know the internal mechanisms of the system

            1. Business Analysts

            2. Quality Assurance Specialists

            3. Testers

         2. Written Immediately Preceding or Concurrently with the Implementation of the Story

         3. Written in Scripting Language

            1. Readable and writable by relatively nontechnical people

      3. Run Automatically & Repeatedly

      4. Passing Acceptance Tests

         1. Once an Acceptance Test Passes

            1. Add to the Body of Passing Acceptance Tests

            2. Never Allowed to Fail Again

         2. Run Every Time the System is Built (several times a day)

            1. If an Acceptance Test Fails, the Build is Declared a Failure. (thus implemented requirements never break)

            2. System is Never Allowed to go Unworking for Longer than a Few Hours

      5. Effects

         1. Profound effect on the architecture

            1. System has to be decoupled at high architecture level to be testable

         2. Compilable and executable documentation for the features of the system

            1. Specifies the Detailed Operation of Stories to Implement

            2. The Final Authority on Judging the Implementation

      6. Tool

         1. FitNesse

   6. Pair Programming

      1. The Roles

         1. One Member Types on Keyborad

         2. The Other Member Watches, Finding Errors and Improvements

         3. Roles Change Frequently

            1. Resultant Code is Designed and Authored by Both. (neither can take more than half the credit.)

      2. Pair Membership Changes Frequently (at least once per day)

         1. Every programmer works in several different pairs each day

         2. Over the Crouse of an Iteration Every Team Member Should Have:

            1. Worked with Every Other Member of the Team

            2. Worked on Just About Everything in the Iteration

      3. Advantages

         1. Dramatically Increases the Spread of Knowledge throughout the Team

            1. Specialties pair with nearly everyone else to spread the specialty throughout the team Other team members can fill in for the specialists in a pinch

         2. Significantly Reduce the Defect Rate

         3. Does Not Reduce the Efficiency

   7. Collective Ownership

      1. A pair has the right to check out any module and improve it

      2. No programmers are individually responsible for any one particular module or technology.

      3. Doesn't mean that XP denies specialties. You are not confined to your specialty.

   8. Continuous Integration

      1. Programmers check their code in and integrate several times per day.

      2. Rule

         1. The first one to check in wins

         2. Everybody else merges

      3. Nonblocking Source Control

         1. Programmers are allowed to check any module out at any time.

         2. When checking module back in after modifying, programmer must be prepared to merge it with any changes.

         3. To avoid long merge sessions, the members of the team check their modules very frequently.

      4. Check-in Procedure

         1. Make sure all the tests run.

         2. Integrate new code into the existing code base.

            1. If there is a merge to do, do it.

               1. If necessary, consult with the programmers who beat them to the check-in.

         3. Build the new system.

         4. Run every test in the system. (including all currently running acceptance tests)

            1. If anything used to work is broken, fix it.

         5. Once all the tests run, finish the check-in.

   9. Planning Game

      1. The Essence: the Division of Responsibility Between Business & Development

         1. Businesspeople & customers decide how important a feature is

         2. Developers decide how much that feature will cost to implement

      2. Initial Exploration

         1. Developers & customers have conversations to identify all the significant features in mind

            1. Don't try to identify all features. More will be discovered as the project proceeds

         2. Break features into user stories

            1. Write stories on index cards or their equivalent.

            2. Not much is written on the card except the name.

               1. Dont't try to capture details at this stage.

               2. Just reminders of the coversation about the features

         3. Developers estimate the stories

            1. Estimates are relative, not absolute

            2. Write a number of "points" on a story card to represent the relative cost

            3. Oversized/Undersized stories are easily misestimated

               1. Developers tend to underestimate large stories and overestimate small ones.

               2. Split oversized stories Merge undersized stories

                  1. A story should be reestimated after being split or merged (not simply add or subtract the estimate)

               3. Velocity

                  1. The sum of the estimates of the completed stories in a week

                  2. Tracking Velocity: one of the most important management tools

      3. Release Planning

         1. Developers & Customers agree on a date for the 1st release

            1. Usually 24± months in the future

         2. Customers pick stories to implement in the release and the rough order of implementation.

            1. Consider Both Priority & Cost

            2. Can't exceed the current velocity

            3. Since the velocity is initially inaccurate, this selection is crude.

               1. Release plan can be adjusted as velocity becomes more accurate

      4. Iteratrion Plan

         1. Developers & customers choose an iteration size (usu 1 or 2 weeks)

         2. Customers pick stories to implement

            1. Can't exceed the current velocity

            2. Can't change stories in the iteration once it has begun

         3. Developer decide order of implementation

         4. Half way through the iteration, the team holds a meeting.

            1. Half of the stories scheduled for the iteration should be complete

               1. Stories, not tasks

            2. If half the stories aren't complete, the team tries to reapportion tasks and responsibilities

               1. If can't find such reapportionment, customers may pull a task or story from the iteration, or at least name the lowest-priority tasks and stories so that developers avoid working on them

         5. Iteration ends on the specified date, even if all the stories aren't done.

            1. Customers estimate, provide feedback

            2. Defining "Done": A story is not done until all its acceptance tests pass.

            3. Total the estimates of all completed stories to calculate the velocity of the iteration

            4. The planned velocity for each iteration is the measured velocity of the previous iteration

               1. Keeps the planning in sync with the team

      5. Task Planning

         1. Developers break stories into tasks

            1. At the start of a new iteration

            2. A task is sth. one developer can implement in 416 hours

         2. Create Task List (with the customers' help)

            1. Enumerate tasks as completely as possible

         3. Task Selection

            1. Estimate each task in arbitrary task points

               1. "Perfect programming hours" can be used

            2. Each developers sign up for the tasks they want to implement

               1. Developer's budget can't be exceeded

            3. Developers may sign up for any kind of task

               1. Let knowledge of the project to spread throughout the team, irrespective of specialty.

            4. Selection continues until either all tasks are assigned or all developers have used their budgets

               1. If tasks remain, developers negotiate with each other, trading tasks, based on their various skills.

                  1. If this doesn't make enough room to get all the tasks assigned, the developers ask the customers to remove tasks or stories from the iteration.

               2. If all the tasks are signed up and the developers still have room in their budgets for more work, they ask the customers for more stories.

      6. Tracking

         1. Velocity Chart

         2. Burn-down Chart

   10. Sustainable Pace

       1. A team is not allowed to work overtime.

       2. The only exception is that in the last week in a release, a team can work overtime if otherwise they wouldn't finish it.

   11. Open Workspace

       1. Team works together in an open room.

          Tables are set up with 2 or 3 workstations on them. 2 chairs are in front of each workstation. Walls are covered with status charts, task breakdowns, Unified Modeling Language (UML) diagrams, and so on. The sound in this room is a buzz of conversation. Each pair is within earshot of every other pair. Each has the opportunity to hear when another is in trouble. Each knows the state of the other.

       2. Programmers are in a position to communicate intensely.

       3. Increases Productivity

   12. Simple Design

       1. Try to find the simplest possible design option for current stories.

       2. Consider only the current stories.

          1. Don't worrying about stories to come.

          2. Fist of all, get the first stories working in the simplest way possible.

          3. Add the infrastructure only when a story comes along that forces it to.

       3. Don't tolerate duplication of code.

          1. Wherever find duplication, eliminate it.

          2. Ways to Elimate Duplication

             1. Create a Function with Duplication Code in It

             2. Use Base Class

             3. Use Template Method Pattern

             4. Create Abstractions (reduce coupling at the same time)

   13. Refactoring

       1. Three functions of a module

          1. The function it performs while executing

             1. Reason for the module's existence

          2. Afford change

          3. Communicate to its readers

       2. Reserve code degradation through frequent refactoring.

          1. Doesn't alter the external behavior

          2. Make a series of tiny transformations that improve the structure

             1. Each trivial

             2. Together combine into significant

          3. After each tiny transformation, run the unit tests to make sure that system is not broken.

             1. Keep the system working while transforming its design.

          4. Refactoring is done continuously & frequently (every hour or every half hour)

   14. Metaphor

       1. The Vision of the System

          1. Ties the whole system together

          2. Makes the location and shape of all the individual modules obvious

       2. Often Boils Down to a System of Names

          1. Provides a vocabulary for elements in the system

          2. Helps to define the relationships between elements