敏捷软件开发笔记(一) 敏捷开发

一，敏捷软件宣言

我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。
通过这项工作，我们认为：
人和交互         重于  过程和工具
可以工作的软件   重于  面面俱到的文档
客户合作         重于  合同谈判
随时应对变化     重于   遵循计划

虽然右项也有其价值，但我们认为左项更加重要

敏捷宣言遵循的原则

我们遵循以下原则：
（1）我们最优先要做的是通过尽早地，持续地交付有价值的软件来满足客户需要。
（2）我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭，为客户创造
竞争优势。
（3）经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。
（4）在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。
（5）围绕斗志高昂的人构建项目。给他们提供所需的环境和支持，并且信任他们
能够完成任务。
（6）在团队内部，最有效率也最有效果的信息传递方式，就是面对面的交谈。
（7）可以工作的软件是进度主要的度量标准。
（8）敏捷工程提倡可持续开发。出资人，开发者和用户应该总是保持稳定的开发速度。
（9）对卓越技术和良好设计的不断最求有助于提高敏捷性。
（10）简单--尽量减少工作量的艺术是至关重要的。
（11）最好的架构，需求和设计都源自自我组织的团队。
（12）每隔一段时间，团队都要总结如何更有效率，然后相应地调整自己的行为。


二，本书的内容结构
    本书由四个部分和两个附录组成。
    第一部分：Agile Development。本部分描述了敏捷开发的概念。首先介绍了敏捷联盟
宣言，然后提供了对极限编程的概述，接着讨论了许多阐明个别极限编程实践的小案例，特别是那些影响设计和编写代码方式的实践。
   第二部分：Agile Disign. 本部分中的章节谈论了面向对象软件设计：什么是面向对象软件设计，管理复杂性的问题以及技术，面向对象类设计的一些原则。本部分以几个讲述UML实用子集的章节结束。
   第三部分：The Payroll Case Study。它描述了一个简单的批量处理薪水支付系统的面向对象设计和C#实现。本部分的前几章描述了该案例研究会用到的一些设计模式。最后一章包含了完整的案例研究，这也是本书中最大和最完整的一个案例。
    第四部分：Packaging the Payroll System.本部分以描述面向对象包设计的一些原则开始。接着通过增量地打包上一部分中的类来继续阐明这些原则。


Section I
Agile Development
Chapter 1
Agile Practices

The Prectices of Extreme Programming 极限编程实践
Whole Team 完整团队

User Stories 用户故事

Short Cycles 短交付周期

Acceptance Tests 验收测试

Pair Programming 结对编程

Test-Driven Development(TDD) 测试驱动开发

Collective Ownership 集体所有权

Continuous Integration 持续集成

Sustainable Pace 可持续的开发速度

Open workspace 开放的工作空间

Simple Design 简单设计

Refactoring 重构

Metaphor 隐喻



Chapter 3
计划
Planning

Initial Exploration 初始探索
1.At the start of the project, the developers and customers have conversation about the new system in order to identify all the significant features that they can.
2. As a feature is indentified ,it is broken down into one or more user stories , which are written onto index or their equivalent.
3. the developers work together to estimate the stories, the estimates are relative,not absolute.

Spiking, Splitting, and Velocity 探究，分解和速度
Any story that is too big should be split into pieces that aren't too big. Any story that is too small should be merged with other small stories.


Releasing Planning 发布计划
Given a velocity, the customers can get an idea of the cost of each of the stories, as well as its business value and priority. this allows the customers to choose the stories they want done first. this
choice is not purely a matter of priority. sometimes that is important but also expensive may be delayed in favor of something is less important but much less expensive. choices like this are bussiness decissions. the bussiness folks decide which stories give them the most bang for the buck.

Iteration Planning 迭代计划
(1)The order of the stories within the iteration is a technical decision.the developers implement the stories in the order that makes the most technical sense.
(2) the customers cannot change the stories in the iteration once it has begun.
(3) the iteration ends on the specified date. even if all the stories aren't done. the estimates for all the completed stories are totaled, and the velocity for that iteration is calculated. this measure of velocity is then used to plan the next iteration. the rule is very sample: the planned valocity for each iteration is the messured velocity of the previous iteration. if the team get 31 story points done last iteration, it should plan to get 31 story points done in the next.the team's velocity is 31 points per iteration.
(4) this feedback of velocity help to keep the planning in sync with the team. if the team gains in expertise and skill, the velocity will rise commensurately. if someone is lost from the team , the velocity will fall. if an architecture evolves that facilitates development. the velocity will rising.


Defining "Done" 定义“完成”

A story is not done until all its acceptance tests pass.

Task Planning 任务计划
The developers break the stories down into development tasks. A task is something that one developer can implement in 4~16 hours. the stories are analyzed, withe customers help, and the tasks are enumerated as completely as possible.
A list of tasks if created on a flip chart, whiteboard, or some other conveninent medium.

Iterating 迭代

Every 2 weeks, the current iteration ends and the next begins. At the end of each iteration, the current running executable is demonstrated to the customers. the customers are asked to evaluate the look, feel and performance of the project.they will provide their feedback in terms of new user stories.

Tracking 跟踪
Celocity Chart
  this chart shows how many story points were completed--passed their automated acceptance tests - at the end of each week.

Burn-down chart
  On a week-by-week basis, how many points remain to be completed for the next major milestone or release.

Conclusion 结论
略



Chapter 4

Testing 测试

Test-Driven Development 测试驱动开发
Suppose that we followed three simple rules
1.Don't write any production code utail you have written a failing unit test.
2.Don't write more of a unit test than is sufficient to fail to compile.
3. Don't write any more production code than is sufficient to pass the failing test.

(1)the first and most obvious effect is that every single function of the program has tests that verify its operation.
(2) A more important but less obvious effect is that the act of writing the test first forces us into a different point of view.
by writing the test first,we design the software to be conveniently callable.
(3) the act of writing test first forces us to decouple the software!
(4) the test act as an invaluable form of documentation. if you want to know how to call a function or create an object, there is a test that shows you.

Test Isolation 测试促使模块之间隔离
The act of writing test before

Serendipitous Decoupling 意外获得的解耦合

TTD forces us to decouple in ways that are beneficial to the overall structure of the program. Writing tests before code improve our designs.

Acceptance Test 验收测试
1)what is Acceptance
Unit tests are neccessary but insufficient as verification tools.
Unit tests are white box tests that verify the individual mechanisms of the system. Acceptance tests are black box tests that verify that the customer requirement are being met.
2)Acceptance Tests are written by folks who do not know the internal mechanisms of the system.
3)Acceptance tests are the ultimate documentation of a feature.the acceptance test become the true requirements document.
4) ..

Serrendipitous Architecture 意外获得的架构




Chapter 5

Refactoring 重构