读书:敏捷软件开发 Agile Software Development

读书:敏捷软件开发 Agile Software Development

English name	Agile Software Development (Amazon.com)
Chinese name	敏捷软件开发 中文介绍
Publisher	中文版由人民邮电出版社出版
Publish Date	English version at 2001, Chinese version at 2003
Author	Alistair Cockburn

这本书整体感觉内容比较抽象,更多的讨论的一些方法论,可能更适合一些管理人员阅读.对于具体做技术开发的人员来说,这本书里没有具体的如何做的介绍. 想了解具体如何做的人,可能更合适去看另外一本书: <Agile Software Development, Principles, Patterns, and Practices>(Amazon.com) 我是主要看了Chap 4: Methodologies ,重点在于如何建立一个适合自己的methodology.有些中文版感觉翻译不到位的地方,对照着看了英文版.下面是个人的一些读书摘要.

Why methodology

方法论主要说明"How we work around here", 同时,还有一些其他的用途:

Introducing new people to the processs

Substituting people

Delineating responsibilities

Impressing the sponsors

Demonstrating visible progress

Curriculum for education

How to Evaluating a Methodology

Ask why the methodology exist.

Ask what you need to do , then

How rapidly you can substitute or train people

How much freedom it gives people (or how constraining it is)

How fast it allows people to respond to changing situations

How well it protects your organization from lawsuits or other damage

2. Structural Terms of methodology
Roles

Skills: The skills needed for roles

Teams: The roles that work together under various circumstances.For example,maybe only one team for small project, multiple team for larger project.

Techniques

Activities

Process: How activities fit together over time, often with pre- and post-conditions for the activities (for example, a design review is held two days after the material is sent out to participants and produces a list of recommendations for improvement).Process-intensive methodologies focus on the flow of work among the team members.

Work products: Deliverable to mean "a special work product that gets passed across an organizational boundary."

Milestones: Events marking progress or completion.

Standards: The conventions the team adopts for particular tools, work products, and decision policies.(Coding standard, language standard, management standard,etc)

Quality:Quality may refer to the activities or the work products.

Team Values: For example, An aggressive team working on quick-to-market values will work very differently than a group that values families and goes home at a regular time every night.

 

3. Scope of methodology
The scope of a methodology consists of the range of roles and activities that it attempts to cover.
The scope of a methodology can be characterized along three axes:
lifecycle coverage : In project lifecycle,when to use/not use this methodology

role coverage: which roles fall into the domain of discussion.

activity coverage: which activities of those roles fall into the domain of discussion.


4. Conceptual Terms of methodology
To discuss the design of a methodology, we need different terms:
Methodology Size: The number of control elements in the methodology.Each deliverable, standard,activity, quality measure, and technique description is an element of control.

Ceremony(正规度):The amount of precision and the tightness of tolerance in the methodology. Greater ceremony corresponds to tighter controls.

Methodology Weight:

Problem Size: The number of elements in the problem and their inherent cross-complexity.

Project Size: The number of people whose efforts need to be coordinated: staff size.

System Criticality The damage from undetected defects.

Precision: How much you care to say about a particular topic.

Accuracy: How correct you are when you speak about a topic.

Relevance: Whether or not to speak about a topic. For example,user interface prototypes do not discuss the domain model.

Tolerance: How much variation is permitted.

Visibility: How easily an outsider can tell if the methodology is being followed.Because achieving visibility creates overhead (cost in time, money, or both), agile methodologies as a group lower the emphasis on such visibility.

Scale: How many items are rolled together to be presented as a single item.Scale interacts somewhat with precision.

Stability: How likely it is to change. I use only three stability levels:
wildly fluctuating, as when a team is just getting started;

varying, as when some development activity is in mid-stride;

relatively stable, as just before a requirements /design / code review or product shipment.One way to find the stability state is to ask: "If I were to ask the same questions today and in two weeks, how likely would I be to get the same answers?"

5. Methodology Design Principles
Pay more attention to four things
Variations in people.

Variations across projects.

Long debug cycles. The test and debug cycle for a methodology is on the order of months and years.

Changing technologies.

Common Design Errors
One size for all projects

Intolerant: 实际上,方法论是一套紧身衣.它必须和人们愿意使用的习惯和策略紧密吻合.它是人们卫自己选择的大小,形状合适的紧身衣.

Heavy: The heavier-is-safer assumption probably comes from the fear that project managers experience when they can't look at the code and detect the state of the project with their own eyes. Adding weight to the methodology is not likely to improve the team's chance of delivering. If anything, it makes the team less likely to deliver, because people will spend more time filling in reports than making progress. Slower development often translates to loss of a market window, decreased morale, and greater likelihood of losing the project altogether.

Embellished(装饰). 一些方法论中总是有一些"you should to do sth..." 之类的装饰性要求.应该尽量减少此类装饰性要求.The way to catch embellishment is to have the directly affected people review the proposal. Watch their faces closely to discover what they know they won't do but are afraid to say they won't do.

Untried: 不能想当然.Nothing is obvious in methodology design. Many things that look like they should work don't (testing and keeping documentation up to date, for example), and many things that look like they shouldn't work actually do work (pair programming and test-first development,for example).Here's how I work when I am personally involved in a project:
I adjust, tune, and invent whatever is needed to take the project to success.

After the project, I extract those things I would repeat again under similar circumstances and add them to my repertoire of tactics and strategies.

I listen to other project teams when they describe their experiences and the lessons they learned.

Used once: Different projects need different methodologies,and so any one methodology has limited ability to transfer to another project.

Methodologically Successful Projects: have three characteristics:
The project was delivered. I don't ask if it was completed on time and on budget, just that the software went out the door and was used.

The leadership remained intact. They didn't get fired for what they were doing.

The people on the project would work the same way again.

6. Seven principles that are useful in designing and evaluating methodologies
Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information.

Excess methodology weight is costly.

Larger teams need heavier methodologies.

Greater ceremony is appropriate for projects with greater criticality.

Increasing feedback and communication lowers the need for intermediate deliverables.

Discipline, skills, and understanding counter process, formality, and documentation.

Efficiency is expendable in non-bottleneck activities.
Do whatever you can to speed up the work at the bottleneck activity.There are four ways to improve a bottleneck activity. Principle 7 addresses the fourth.
Get better people doing that work.

Get more people to do that work.

Get better tools for the people doing that work.

Get the work that feeds that activity to a more complete and stable state before passing it along.

People at the nonbottleneck activities can work inefficiently without affecting the overall speed of the project! Non-bottleneck 的人员可以多做一些重复性的activity,来提供更好的output,虽然这样他的效率降低了.

Applying the principle of expendable efficiency yields different methodologies in different situations, even keeping the other principles in place.

Consequences of the Principles
Adding people to a project is costly.

Team size increases in large jumps.Team size是一种跳跃式的增长,当把一个Team的output加倍的时候,差不多需要原Team平方数量的人员.

Teams should be improved, not enlarged.Do sth different in team and improve capability of each member.

Different methodologies are needed for different projects.

Lighter methodologies are better,until they run out of steam.

Methodologies should be stretched to fit.尽量选择一个Lighter的methodology,然后加上项目的特别需求;而非选择一个heavier methodology,再删除project不需要的内容.

7.Becoming Self-Adapting(From Chap 5)
A Methodology-Growing Technique: It's a small technique for on-the-fly methodology construction and tuning. I present it as what to do at five different times:
Right now: 通过简短的项目访谈,了解你组织的优势和劣势.Can ask following question:
) 看每个Work product的sample

) 询问项目的历史,包括开始时间,team的变化,team structure,项目中team士气的最高/最低点.

) 询问下次应该改变哪些方法

) 询问下次应该改变哪些方法

) 确认优先级

) Other,try to find out 所有的漏洞.

At the start of the project: Expect to do some tailoring to the corporate methodology standard.

In the middle of the first increment: Run a small interview with the teammembers, individually or in a group meeting,

Between each increment: Hold a team reflection workshop after each increment

In the middle of subsequent increments. Have a review of methodology again.Do improvement if needed.