Mo Li@2022

Software Project Estimation And Biases

2022-01-21T23:13:00.022-08:00

(originally written on 1/27/2014 for Prof. Fox’s class assignment, revision 1/22/2022)

As a software project manager, one of the job responsibilities is to estimate the effort and time for the project delivery, typically before the project starts. Management uses this information to estimate the cost and plan for the roadmap of the product. However, estimation accuracy has always been a problem in many of my past experiences. Cognitive biases have influenced estimation accuracy quite significantly and a manager needs to have awareness.

The Estimation Process

The approach we commonly use for the estimation is Planning Poker, a structural and commonly accepted method in the industry.

The business requirements are broken down into smaller pieces, or “stories”.
A group of 3–4 developers, including the tech lead, sit in a room with the project manager and business requirement analyst to discuss and estimate each story.
Every developer receives a set of “t-shirt size” cards that has “S”, “M”, “L”, or “XL” letters on them (sometimes Fibonacci numbers).
The analyst presents each story and all developers think about it and ask questions.
Once all the questions are cleared, the project manager will ask every developer to present their cards at the same time to get an estimate.
If they vary, they will discuss and reconcile the difference to an agreed letter/number. Each story may take an average of 2 to 5 minutes to estimate depending on its complexity.
The end result of this estimation exercise is a list of relative and comparable t-shirt size letters on each story.

After all the estimates are done, the project manager will ask the developers to estimate a letter-to-dev-days conversion ratio so that we can relate the t-shirt sizes to the real person-days for planning purposes. The whole estimation process happens in a day or two to get a fast forecast of the project, as digging down into details will require significant efforts of the already busy team.

This approach considers some degree of the psychological aspects of human behaviors. For example, it takes the group decision principles into account. Instead of only asking the tech lead for a guess, it seeks input from multiple developers to make better group decisions. The estimation process is essentially a judgemental process of future probabilities, so the “consistency” principle applies in order to make a better outcome. It is best if developers make consistent and relative comparisons among the stories instead of using absolute days/hours on each story.

Cognitive Biases Impact Estimation

However, there are a few issues with this approach that could lead to a biased outcome. To start with, as there is always a time constraint, to get a result in a short time frame, it somewhat forces the developers to use their intuition to make the estimation other than to use their system 2 thinking (Kahneman, 2011). Prior to walking to a meeting room, the developers usually do not have any knowledge of the details of the business requirements they were about to estimate. Although they can ask questions, in 2 to 5 minutes it is hard to gain an in-depth understanding, and they have to make decisions based on what the analyst presented to them. If there is a push to get smaller estimates, which is usually expected by the project stakeholders, the team may take the expectation as an anchor and create underestimated results.

The availability biases and especially biases of imaginability (Tversky & Kahneman, 1974) could impact people’s ability to estimate. The estimation process will predict the risks and feasibilities of the future project. Developers base on both technical knowledge and their past experience to make the prediction. However, normal humans cannot accurately remember all details of past situations. The most vivid memory and most available information will be naturally recalled. People are programmed to call to mind easy-to-imagine risks and often overlook hard-to-imagine risks.

Poorly executed group decision also impacts the estimation process. The group polarization effect could happen when an influential person is in the room during the estimation. For example, the tech lead is usually the most senior person. Other developers who have a much different perspective but junior may just give up their idea due to authority bias.

Furthermore, the positive illusion could impact the team’s estimates (Kahneman, 2011, ch 19). People tend to be optimistic about the challenges and overconfident about their skills. Although via the user stories we can break down a large project into smaller pieces, when estimating each piece, people tend to neglect the other factors during the project execution, e.g. testing effort, integration, dependencies, communication, and collaboration with other teams. They tend to overestimate their ability to complete plans in a timely manner due to overconfidence.

Estimating the conversion ratio between the letter size and the actual days is the vaguest and most inaccurate part. The current 4 letters scale has introduced an anchoring effect (Tversky & Kahneman, 1974), where for some stories its size may be an XXXL but just because there is no such a category, the team will set it to the XL as it anchors on this range.

The conversion ratio will apply to the whole team and project, ignoring that they may be changing over time. The developers estimating the project use their self-confidence as the belief of the team’s average skills level, which is also usually not true. The estimators are generally more experienced as we selected experienced developers to estimate. Using themselves as anchors will overestimate the team’s average ability.

In this step, relying on historical data may introduce another anchor to the prediction because the new project is different. It could be much different from the previous ones or be riskier.

Approaches To Reduce The Biases

Simple Approaches

The estimation process has a built-in philosophy, “Consistency” and “Comparable” principles, to reduce the biases. To ensure them, at the end of the estimation, the project manager should list all estimated stories and group them by their estimated categories. They can ask the team to do a sanity check to evaluate if all the stories within the same “estimated bucket” are roughly the same size and have similar risks. Outliers should be discussed and reestimated.

Another simple approach a lot of managers use is padding. Sometimes adding 20% to 50% buffer to the estimated result is a wise choice to not go over budget and schedule. In Microsoft Project, adding a project buffer will simply add padding on top of the project schedule. Nowadays, many companies discourage managers to add any buffer as every dollar you didn’t spend at the end is a value trade-off from other teams’ projects.

Linear Regression Bootstrapping

To improve the estimation accuracy, a linear regression bootstrapping approach could be applied. Developers have some criteria in mind when they estimated the sizes of stories. We can reveal these criteria as variables and use them to find the predicted values based on a regression model.

For example, a team can rate the following aspects as part of their estimation factors:

development effort
whether the story involves third-party integration
testing complexity
communication
collaboration needs with another team
and the team’s familiarity with the technology.

These factors can be evaluated and rated by numeric values. The estimated result (either a Fibonacci number or a T-shirt size category) could be seen as the dependent variable. Then we can build a multiple linear regression model to find the expected estimates of each story. This is called bootstrapping (Fox, 2014, session 2) and it normalized the parameters and their correlations and reduced the inconsistency of personal estimates.

Monte Carlo Simulation

Monte Carlo simulation is another effective approach to estimating uncertainties and reducing biases. (I will write details in another article). Monte Carlo simulates the estimation with random sampling from the historical estimates, and with the large sample size, the estimated size of the project will form a bell curve. Then the managers can choose a confidence level to manage or accept the risk.

Even with advanced approaches like the improved bootstrapping approach and Monte Carlo simulations, however, we should admit that we couldn’t completely eliminate inaccuracies. After all, our future always has uncertainties and can not be predictable at all.

REFERENCE

Fox, C. (2014). Managerial Decision Making, Anderson School of Business
Kahneman, D. (2011). Thinking, Fast & Slow (TF&S)
Lovallo, D. & Kahneman, D. (2003) Delusions of Success: How Optimism Undermines Executives’ Decisions. Harvard Business Review, 56–63
Tversky, A., & Kahneman, D. (1974). Judgment under uncertainty: Heuristics and biases. science, 185(4157), 1124–1131.

The FANCY Approach for User Story Analysis

2016-10-14T23:19:00.003-07:00

https://www.linkedin.com/pulse/fancy-approach-user-story-analysis-mo-li/

Analysis – the missing step

From Agile textbooks, we have learned to use the “User Story” for capturing and managing requirements. We know stories have 3Cs, ie. Card, Conversation, and Confirmations, we know a story should follow INVEST principles, and we know the Acceptance Criteria should be SMART. However, the one thing I found missing in most of the books is the HOW TO: from the Conversation to the Confirmation ie. how to elaborate on the details for the stories.

In User Stories Applied, Cohn said that the detail was done by “Conversation”. In that, the analyst fleshes out the details behind the stories by having conversations with onsite customers and making notes on the back of the story card. He said, “Ideally, the conversation can be resumed easily whether or not the same developer was involved in both halves of the discussion…” and “…details that have already been determined through conversations become tests.”

In Agile Software Requirements, Leffingwell mentioned “details (come from) discussion between PO and team” and “if more details are needed about the story, they can be provided in the form of an attachment (mock-up, spreadsheet, algorithm, or whatever), which is attached to the user story…” and “…In that case, the user story serves as the token that also carries the more specific behavior to the team.”

These are all good ideal cases, but they won’t work automatically in practice without certain capabilities. The on-site customers, the product managers, the product owners, or the business analysts need a clear and structured way to analyze the stories and to capture the details.

I often see new analysts confused on using the User Story approach. They have read the textbook and understand the method but they either can’t write good user stories or sometimes missing acceptance criteria, e.g. a bad smell of this would be “oh I’ve never thought about that path”.

The lacking capability here is the “analytical capability” or it is the guidance of how to have such conversation or "the norm" of a requirement that all parties agreed upon. A friend once commented to a business analyst at ThoughtWorks that “he doesn’t know the business nor the analysis”. Many junior analyst don’t know how to perform proper analysis. They need the “Analysis 101” class.

The Analysis 101 – the FANCY approach

Here is my innovative approach to performing “analysis”, the FANCY way.

Functional requirements
Assumptions
Non-functional requirements
Constraints
Y-wireframes

Analysis is to break down the story into details, or sub-stories or tasks, you name it. To analyze a story, we, as an analyst, have to follow a structured thinking process in order to come up with all the details and to make sure that we won’t miss any aspects of the story, so we can produce consistent high quality user stories.

F - Functional requirements

The first and most common aspect is the functional part. “Functional” refers to the business logic or flows. The analyst has to break down a story into smaller pieces of details. The pieces could be acceptance criteria or separate stories. To come up with comprehensive and exhaustive details, we’ll need to follow 5W1H to drill down.

At this stage, analyst should have already known about who and why this story is for:
who – the user roles or persona
why – business value and user goals

One should also consider the following aspects:

when – the precondition or prerequisites steps
where – the entrance on the UI
what – the input data
what – the business rules or logic in this function
what – the output
how – the happy path
how – the sad paths and edge cases
how – the impact to other functions

A - Assumptions

It is important to capture the basic assumptions that the story is based on and developed on. These assumptions are usually made at the beginning of the product idea experimentation or in the early stage of requirement analysis. Some technical or architectural assumptions are made when the team estimating the stories. At the point when the team aren’t able to get a answer immediately for a question, they have to move on with an assumption.

For example, a story may assume that the database tables are already built, or that an API exists at the time of development. Note:
If an assumption is made, the assumption needs to be continuously monitored and verified. A spike task may be scheduled to verify the assumption.
If the assumption breaks, the story will need to be re-estimated, and the plan will need to be changed accordingly.

The common areas for assumptions are:

The fundamental technical architecture or framework
The availability of external/3rd party API or applications
The uncertain parts of the input or the output

N - Non-functional requirements

Non-functional requirements are usually cross-cutting concerns for all of the stories. Here is a list of non-functional requirements on Wikipedia. Typically, one should consider the following aspects:

Performance and Scalability – Responsive time? Concurrent Users? Cloud? Sharding?
Maintainability and Extensibility – refactoring needed? Impact to legacy systems?
Compliance – Company standards? Industry Standards? Privacy? SOX?
Supportability – Logging? google analytics? Ops need? Admin UIs?
Documents – User manual? Release notes? Marketing messages?
Security – User permissions? SSH Keys? SQL Injections?
Localization – i18n? editorial reviewed texts?
Measurement - Pageviews? Monthly active user? CTR? Conversion Rate?
DevOps – Deployment scripts? Database migration? Configuration difference between servers? Automated functional tests organization?

We can develop a comprehensive non-functional requirement list as a checklist. Some of these can be split into new stories and plan in a separate iteration. But to have them in mind in the beginning of story writing is much better than to realize the need of them at the later iterations.

C - Constraints

The Constraint is the limitation and the boundary of a story. It is what the story won’t do or can’t do. E.g. we may agree to not do some function in this story and to develop them as separeate stories, or this story won’t fix an existing production issue in the same area. This give QAs and other audiences a guidance on what’s in scope and what’s not in each specific story.

Typically the constraints need to cover the following areas:
Internal constraints – functions that the story should cover but due to other reasons it will never be implemented. Users will have to operate with this limitation.
External constraints – functions that the story should cover but split to other stories. Users could have a workaround until the delivery of the later stories.

Y - Wireframes

Although it is called wireframe, I would use it to indicate the UI/UX aspect of the story.

This broader concept covers the following aspects:
User interaction flow – how the user interacts with the system
User Experience Design – whether the layout, the business flow, the information architecture, and the navigation make sense
Mobility – should this web app also support iPhone, Android, iPad etc?
Accessibility – to what degree does the story need to support accessibility?
Browser capability – does it really need to support IE8? are you sure? why?!!
UI design – the actual color scheme and visual designs

A typical form of the wireframe could be a paper prototype or a lo-fi prototype in PowerPoint or other tools like Axure or Invision. It helps to visualize the function for audiences to reach to a shared understanding. To better illustrate the user interaction flow for developers to understand what do build visually, and to verify the usability by final users, a wireframe is necessary to add to the stories.

The actual visual design aspect may or may not be part of the story details depends on if the team has the design comps ready in early stage of the development. An Agile iterative UX design approach is expected in order to incorporate the UI/UX design into each iterations.

Summary

The purpose of FANCY approach is to help BAs and Product Managers to better understand and structurally analyze the requirements. When there is need to elaborate the details of a story, follow these 5 methods to break down the epics and to organize the communication. Some of them would finally appear in story descriptions, e.g. on Mingle or JIRA, or other form. But please be cautious that these are neither supposed to generate comprehensive documents nor to replace the conversation. Great communication between cross-functional roles is one of the key elements for a successful Agile team.

I want to share the FANCY approach with all the Agile business analysts, product managers, or product owners. It has worked well for me in my organization, and I have used them in my mentoring of junior BAs and it is proven to be useful for them to better understand the analysis process.

In fact, many years ago, some people also created another framework called “FURPS“, which is essentially trying to achieve the same goals as I do. I think its acronym doesn’t lend itself too well for people to remember the attributes it represents.

Have fun in the business analysis world. Contact me if your team needs coaching.

(repost - originally posted on April 6, 2012 at my blog)

敏捷转型实施方法框架

2012-06-17T06:41:00.001-07:00

本论文题为《软件组织敏捷转型过程的研究与改进》，原文发表于2009年6月，有删节。

（三）敏捷转型实施方法框架

从上一章对于敏捷方法价值观体系和实践体系的论述，可以得出以下结论：

敏捷中人的方面：人的自我实现性和复杂性使得管理方式必须重视人，以人为本，且给人足够的激励和尊重。
敏捷价值观方面：注重价值和质量、消除浪费、交流、反馈、拥抱变化和适应性使得敏捷转型过程必须能够自主的适应、自我反馈、自我改进。
敏捷实践方面：实践之间的相互依赖使得在向敏捷方法转型的过程必须从过程到技术到团队文化全方面进行。

然而在敏捷转型实施中，很少有组织系统全面的考虑上述因素对于其转型过程的影响。因此，作者认为，一个预定义的过程方法框架可能有助于组织在进行敏捷转型的过程中进行参考和依照。

3.1 敏捷转型实施方法框架的阶段模型

为了能够有效的跟踪和控制敏捷转型实施的效果，在实施之前，需要明确实施的步骤和方式。在建立实施步骤的中，应当遵循敏捷方法的一贯原则，注重真正的实施效果，将交流反馈的流程纳入到各个阶段中以便持续改进，并且以迭代的方式来执行各个步骤。

3.1.1 IDEAL模型

尽管敏捷方法被认为是反CMM或其他重型方法，但敏捷方法中特有的适应性和灵活性，使得敏捷方法成为一种能够自我发展的方法论。凡是可以用来提高软件开发过程效果的手段，无论是来自CMM模型或是RUP方法，都应当采用。当然，这一切的适应性和灵活性都必须建立于遵循敏捷的价值观体系的基础上。

本文所推荐的实施过程阶段参考了SEI的IDEAL模型[[i]]。IDEAL模型是SEI为组织改进而建立的路线图模型。其名称来自于其定义的五个阶段，分别是：Initiating(初始化)、Diagnosing （诊断）Establishing（建立）、Acting（行动）、Learning（学习）。

初始化阶段是对整个过程的准备，为整个过程改进提供了基础和共识。
诊断阶段是对于当前项目情况的检查，并通过了解当前的情况，制定未来的改进目标。
建立阶段主要用来确定具体的实施和实践细则。
行动阶段就是整个改进的开始，具体的工作开始展开。
学习阶段是指从行动的过程和结果中汲取经验，并将其应用于未来的步骤。

另外，IDEAL模型特别指出从诊断到学习的四个阶段是不断周而复始的迭代进行的。当第一个试点取得了成功，这些经验应当继续向更多的试点来扩展，而这个扩展的过程也应该按照IDEAL模型的方式来进行。参见图3-1。

图 3‑1 IDEAL模型示意图

IDEAL模型虽然详尽的描述了在组织中推行新技术或新方法的一般过程，但一方面未能体现将交流反馈的流程纳入到各个阶段中的过程，另一方面没能表明从点到面的扩展过程。因此应当一套改进的过程模型是必要的。

3.1.2 改进的实施过程阶段

作者对IDEAL模型进行了改进。如图3-2所示。从过程阶段上看，主要分为四大阶段和两个辅助的过程：

初始阶段(Inception)是对整个过程的准备阶段，在这个过程中负责过程改进的人员需要获得高层支持并使其改进的步骤达成共识。
规划阶段(Vision)包括对于当前情况的评估和对于愿景的规划。
实施阶段(Implementation)包括建立适应性实施计划，开始执行实施计划并在整个行动中不断的通过交流和反馈来改进实施的效果，并允许改进实施计划本身。
扩展阶段(Expansion)，在行动阶段进行到一定程度时，如果时机成熟则可以进行扩展。扩展过程包括对于已获得足够知识的“种子”成员的重新部署，以及从现状分析开始对于新参加到改进过程中的团队和人员进行新的一个周期迭代。具体的扩展方法在下文将进一步阐述。
培训和学习过程(Training & Learning) 应当始终贯穿在整个的改进过程中。组织周期的课程和讨论活动，以便对于员工的知识体系和价值观进行更新。
持续的跟踪和指导过程(Supporting)也应当贯穿整个过程。在任何的时候，一旦执行过程出现问题，咨询团队可以快速的跟进并帮助解决。

图 3‑2 改进的敏捷转型实施过程阶段

下面就每一阶段的具体活动进行详细的描述。对于下面每一阶段的描述将会包括三个方面：该阶段要达成的目标，该阶段所应当遵循的原则，该阶段可进行的活动或实践。

3.2 初始阶段

初始阶段的主要目标是帮助敏捷组织转型铺平道路。当一个组织想要进行敏捷转型时，其真正动机往往来源于中底层的员工。

由于敏捷方法多数起源于小的开发团队，且敏捷方法着重强调了开发技术实践，因此对于中小团队的吸引力比较高。当一个团队在项目经理的授权下，私下里进行了一些敏捷实践后，往往其结果都是不错的。然而，问题也随之暴露出来。当这些中小团队面临和公司其他部门或人员进行沟通时，他们的所作所为不能为对方所支持。例如需要和其他部门协作开发，或者需要HR部门支持某种绩效考评外的活动时。这些情况使得团队的敏捷实践效果大打折扣。

因此，中小团队往往是敏捷转型的大力推动这种变革的倡导者。他们需要一些方法来得到公司高层的支持。

初始阶段的时间长度取决于公司高层对于敏捷转型的认可。一旦公司高层认可敏捷，决议进行敏捷转型实施，从初始到开始规划的时间不应当超过2周。

3.2.1 向公司高层展示成果和问题

该实践的目的是让公司高层认可敏捷方法并支持敏捷转型，扫清敏捷转型的障碍。实践原则包括：用事实和证据说话，用令人信服的数字说话，用投资回报来打动高管。

要获得高层的支持，就需要首先展示出敏捷方法所带来的成果。为了这样一个可以展示的成果，项目经理必须要收集足够的证据。然而软件开发中的数字度量一直是困扰软件开发团队的事情，收集证据并不容易。

一种可以考虑的手段是通过设计调查问卷来调查团队成员以及团队之外协作人员的感受。例如可以从以下几个方面来调查：

使用某种敏捷实践之后你认为你自己的开发效率是否有提高？
使用某种敏捷实践之后你认为你和同事的交流比以前多还是少？
使用某种敏捷实践之后你认为对你最大的改变是什么？
使用某种敏捷实践之后你认为你得到的好处是什么？
你认为过程上还有什么值得改进的地方？

以上只是简短的例子，这个问卷可以无限长的增加下去。事实上，后文中对于敏捷转型实施本身的证据证明也是通过建立调查文卷来完成。当项目经理获得了足够的答卷，就可以着手建立一份报告给高管，展示敏捷所带来的好处。

敏捷转型所带来的收益可以通过产品上线周期、之后的缺陷率、用户反馈、响应用户反馈的速度来度量。从传统的财务分析报表上可以明显的看出开发效率增高、交付频繁之后所带来的收益曲线的变化。

敏捷转型的主要成本在于咨询费用和内部的一些运营费用。其中咨询费用可能比率会比较高。至于内部的运营费用则并不会明显的增高。

3.2.2 获得第三方咨询公司的支持

该实践的目的是让公司高层认可敏捷方法，提高公司对敏捷的重视程度，促使试点项目的开展。其原则包括：寻找口碑良好的咨询公司，避免用工具和培训来代替实施本身。

第三方的咨询公司在两种情况下值得公司引入。一种是组织缺乏敏捷经验时。这时候如果没有有经验的咨询师的带领，敏捷实践往往会花费过高的成本，如图2-2所示的曲线将发挥作用，导致团队在一定时间内效率低下。而这样的阶段对于试点团队则是生死攸关的。

另一种情况是团队的经理或公司的成员认为自己不适合出面来主导变革，需要第三方咨询公司的支持来协调各方面利益。中小企业中的人事关系和组织关系相对简单，咨询公司只需要帮助获得CEO或CIO的支持即可。而更复杂的情况出现于大型企业，当一个公司的组织机构非常多的时候，进行组织变革往往不是一个部门或个人能够推动的。咨询公司在这时候就必须起到协调人和推动人的作用，由上至下的打通关节，从而推动公司各个部门都支持敏捷的转型。

敏捷方法出现多年以来，帮助客户实施敏捷的公司为数不少，且呈越来越多的趋势。在选择第三方咨询公司的过程中，最关键的是要看到咨询公司的现有案例以及其咨询的口碑。有的咨询公司通过工具或培训认证的方式来进行咨询，认为工具或培训可以帮助其立即转变为敏捷，而这样的方式本身就违反了敏捷思想，不从人开始转变无疑是本末倒置。

需要注意的是，由于所需咨询师的人数取决于试点团队和转型规划的规模，因此咨询师的成本在项目开始无法完全确定。

3.2.3 明确的建立敏捷方法转型的愿景

该实践的目的是设立敏捷转型所要达到的目标，为全面推行敏捷转型指明方向。实践原则包括：不可急功近利。往往一个组织的敏捷转型需要6个月到2年的时间。

管理层往往不会同意以全面铺开的方式来进行敏捷的转型。一般的通过试点的方式可能获得管理层的认可。一旦获得确认，一个良好的期望管理过程将会是对于整个转型实施至关重要的。通常一个组织的转型需要6个月到2年的时间才能完成，具体时间大小要视组织的大小而定。

愿景实际上是由多方所达成共识。内容包括：

实施敏捷转型要解决什么问题？（WHY）——这些问题的影响是什么？背后的原因是什么？为什么敏捷转型可以解决这些问题？
实施敏捷转型要达到什么目标？（WHAT）——实施敏捷转型的目标是什么？例如增加交付周期，提高销售收入。减少开发成本，提高开发效率。
实施敏捷转型需要哪些人的参与？（WHO）——敏捷转型需要一个整体协调的负责人，需要知会涉及到的业务部门和人力部门，需要提前选定初步试点团队及项目，以及需要所有的IT团队经理都得到知会。
实施敏捷转型需要多长的时间？（WHEN）——时间的规划一般按照每个团队和项目3-6个月为一个转型周期来计算。按照作者的经验，一个团队没有3个月的磨合根本无法产生最大化的效率。试点项目后期可以考虑同步进行多个扩展试点团队和项目。
实施敏捷转型选型的方案是什么？（HOW）——敏捷转型应当采取试点的方式进行。试点项目不可以过大或过小，因为过大的项目会导致迟迟难以看到效果，过小的项目容易被人质疑敏捷方法的效果。试点项目的首要目的是交付一个敏捷化的“种子”团队。

3.2.4 选定初步试点团队成员

该实践的目的是从部分团队做试点，培养敏捷“种子”，用回报来影响决定。实践原则包括：尽量选择技能基础良好且乐于成为一位敏捷教练的员工来参与试点团队。试点团队的人数决定了下一步试点的规模。

敏捷方法最注重于人。实施敏捷的时候，如果实施人的价值观不符合敏捷价值观体系，那么就会存在很多的冲突和误解。因此，敏捷试点团队的人员，应当是符合敏捷价值观的人或者乐于向敏捷价值观转变的人。这些人应当符合“自动人”的假设。因此在挑选第一批敏捷试点团队的时候，应当尽量挑选符合以下要求的人：

乐于学习和接受新的知识，愿意尝试新的机会。
愿意对工作负责，寻求发挥能力的机会。
具备一定的技术素养，对于开发技术不需要从头培养。
乐于和人交流且愿意分享自己的知识给同事。

一个常见的误解就是有人认为敏捷方法对人的要求过高，认为他们的团队不具备足够多技术水平好的人才，因此不能实施敏捷。而事实上，实施敏捷对人的要求并不在于技能，而在于人的价值观。

当一个人乐于自我学习和接受新的知识的时候，他对于敏捷方法，或者任何其他的他乐于接受的方法的适应速度都会非常高；反之，一个人不乐于改变时，他能够适应一个新方法的速度会相对较慢。而对于新方法的适应速度，则决定了一个团队实施敏捷的成功率。参照图2-2，如果该低谷区因为人不愿意改变而延长，那么敏捷方法的实施将很难成功。

3.2.5 建立敏捷转型管理团队

该实践的目的是提高转型中解决问题的效率，提高做决定的效率。实践原则包括：第三方咨询师带领，并逐步的交由组织内部成员来运行。

敏捷转型管理团队一开始应当由第三方咨询师带领来执行，随着项目的进展，可以逐渐的引入转型过程顾问团队的参与。其责任包括：

跟踪每个试点团队的转型实施情况，了解团队成员的反馈
根据反馈调整实施计划，协调组织内部各方面的关系。
跟踪团队成员的能力提高情况，跟踪项目的转型实施效果
和管理团队紧密沟通，随时交流敏捷转型的进展情况
负责决定何时启动转型扩展阶段
向非技术团队和其他协作部门引荐和宣传敏捷理念

3.2.6 选择合适的试点项目

对于试点项目的选择需要慎重。既不能规模过大或过于复杂，导致实施时间过长，又不能过于简单或低价值，使得试点的结果被人忽视。考虑以下大小的因素

项目团队：从小团队开始，6-10人左右事宜
项目规模：正常交付应在3-6个月左右
项目优先级：不是最紧要的项目
项目的性质：以正常的功能性项目为佳，尽量避免研发、新技术探索等难以估算的项目
项目的代码库：以成熟技术、新代码库为宜，避免
项目的基础设施：考虑搭建项目的基础设施、持续集成等所消耗的时间

值得说明的是，上述的各种因素在各种敏捷项目中很常见，采用合适的敏捷实践可以很好的解决。但不建议敏捷成熟度低的团队从一开始就面临复杂问题，而忽视了对敏捷实践本身的提高。

3.3 规划阶段

准备工作需要在敏捷转型实施过程启动之前仔细完成。敏捷转型并不是一个大而空的口号，不是振臂一呼就可以开动的。为了能够达到更好的效果，必须要在实施启动之前了解组织目前情况并制定相应的计划和目标。这个阶段可以被称为规划阶段。

规划阶段的时间长度应当尽量缩短。2周到4周的过程应当足够任何的企业完成规划。

3.3.1 评估组织目前的情况

该实践的目的是对当前情况作出正确的了解，以便于有的放矢的进行规划，合理的设置转型的效果和期望。

实践原则包括：分不同的维度对组织情况作出正确的描述，并将描述的维度标准和了解结果记录下来以便转型过程中随时和初始情况对比。

任何的改进，都应当建立于对于当前情况的了解的基础上。正确的评估目前的情况，才可能在未来的敏捷转型实施中跟踪实施效果。因此在一开始对于初始情况的调查必须要经过仔细的思考。

对于一个组织的评估，应当从人的技术能力、开发过程、团队文化、组织结构四个维度来考察。评估的内容可以根据具体情况来具体定制。作者在此列出了一些可以方面进行参考。

人的技能方面：
- 开发团队的人力配比：是否适合当前的项目规模和技术；
- 现有成员的技术能力：是否符合当前项目的需求，是否符合未来市场的需求；对解敏捷方法有多少了解？
- 人力招聘计划和招聘条件：人力部门的招聘条件从何而来？是否满足开发团队的真正需求。
开发过程方面：
- 软件开发过程中的配置管理：是否采用了乐观式的配置管理；是否有人专门负责配置管理？开发人员对于配置管理的重视度如何？
- 开发过程中的测试：谁来编写测试？测试团队和开发团队是否分为两部分？现在的交流情况如何？
- 开发过程中的交流：开发团队和外部团队的交流是否通畅；开发团队和需求团队或市场部门如何协作？
- 开发团队管理：项目经理的在开发团队和团队之外所花费的时间如何分配？项目经理管理开发团队哪些指标？项目经理如何控制项目风险？项目经理对待开发团队的错误如何处理？
- 客户管理：开发团队是否能够接触到客户？用户能否在开发完成之前看到产品？客户的需求和用户的意见如何反馈到开发团队？开发团队如何对待客户需求？
团队文化方面：
- 团队责任制：开发任务由专人负责还是集体负责？出现延误如何处理？
- 团队自我建设：团队是否有定期的活动？团队中如何进行知识的传递？团队中如何进行技术的交流？团队是否鼓励采用新技术？
组织方面：
- 管理层：管理层对于开发团队所看重的是什么指标？管理层和开发团队多久能够沟通一次？
- 绩效和考核：软件团队的绩效考评指标是什么？人力部门为什么定义这样的指标？现有团队的成员如何看待这种指标？
- 公司组织结构：开发团队需要和其他什么部门打交道？用什么方式和其他部门沟通？谁可以和其他部门沟通？其他部门对于开发团队的态度如何？
- IT部门的结构：公司的项目或产品组按照何种方式组织？部门之间或团队之间是否存在依赖？

以上的这些评估维度每一项可以单独按照权重记分，当分数体系被建立起来之后，就可以对进行敏捷转型的试点团队先进行评估。评估的方式可以采用问卷调查、访谈、讨论等多种形式来完成。在进行访谈或问卷时，只有安全的环境才能够获得足够准确的情况。所以在评估之前，管理层应当向全体参与评估的人员宣讲评估的意义和目的，以便消除参与人员的顾虑。

如图3-3所示，作者对于每一种项目的结果按照三级标准来进行评价：良好、存在问题、危险，分别用绿黄红三色在评估结果上显示。此评估的结果，可以作为报告提交给管理层，也可以作为下一步制定实施计划的参考，以便排出优先顺序进行逐步的改进。

图 3‑3 评估结果示例

3.3.2 制定转型实施计划

该实践的目的是制定一份让参与转型的各组织都能认可的实施方案。实践原则包括：在制定过程中必须不断的获得各个涉众的反馈，才能制定出合理的方案。

敏捷转型实施计划包括两方面的内容，一方面是执行步骤和方法，另一方面是时间点和所期望的效果。如图3-4所示。敏捷实施计划可以根据具体的公司需要，从小规模试点到全面转型逐步开展。

图 3‑4敏捷转型实施阶段计划

短期、中期、长期阶段的阶段计划。

短期效果是指6个月以内。这个阶段中主要是试点项目的转型。到6个月时，试点项目应当已经完成或接近完成，试点项目的效果已经显现出来。试点项目中的成员应当已经理解敏捷并可以顺利的使用敏捷进行实施。试点项目成员可能有部分已经轮换出团队去指导下一阶段的转型，或者试点项目结束后，所有人将会分组到具体团队去带领转型实施。
中期效果是指6个月至1年半。6个月至1年半之中，组织内部应当已经有部分的团队进行了敏捷转型。在这个过程中，持续的跟踪、支持和改进是达到最终成功的重点。组织文化发生改变，对于人的重视得到极大的提高。
长期效果是指1年半到3年。1年半到3年间，敏捷团队和敏捷文化应当已经深入人心。多数团队都在实用敏捷，并能够根据具体的情况来改善自已实行的效果。公司的组织效率都随之得到改进。

计划中应关注的结果

组织的敏捷化团队比率及员工对于采用敏捷方法的满意度
敏捷方法所交付项目的客户满意度的提升
敏捷团队所交付的产品或项目带来的业务价值

具体的实施方法在后面文中会进行阐述。

3.3.3 进行知识的储备

该实践的目的是使团队提前了解一些敏捷的知识，以便在开始敏捷转型实施的时候，缩小图2-2所示的谷底长度。实践原则包括：采用体验式培训（体验式学习）并鼓励自学和讨论。

在制定计划的同时，试点团队的人员可能已经选出。如果团队成员之间不曾一起工作过，则最佳的处理方式是让这些人员聚集到一起，提前进行磨合和熟悉。对于团队的敏捷培训也是一个很好的方式来提前准备所需的知识和技能，同时加深试点团队成员之间的关系和协作效率。

在开展敏捷培训的时候，最佳的方式是组织体验式培训[[ii]]。体验式学习课程的特点是有活动的、多样化的、和有方向性的。体验式培训应当具有以下的方面：

内容程度适中。体验式学习课程拥有精简的课程。集中在重要的学习领域—其中的元素是未来所要建设的重要基础，当内容的水平维持在适中程度，讲师便有时间设计活动，去介绍、呈现、运用及反映出当下学员所学的。
在情感、行为和认知的学习上取得平衡。体验式学习包括三个方面： 1. 培养态度； 2. 发展和练习技巧； 3. 促进对主题概念及模式的了解；体验式学习的讲师要参与者不只是知道某些事，并且能够去实践它。讲师会要求参与者检视他们自己和正在教导之事之间的关系，并去体察这在参与者身上是如何运作的。
参与团队的机会。在任何体验式学习课程里，参与团队都有很大的益处，参与团队会将训练课程从被动的位置移为主动。团队活动促进参与者投入在学习的过程中，并让他们和讲师成为伙伴。讲授的部分减到最少，高度参与是最大特色，如游戏、角色扮演、模拟练习、和案例讨论等。
运用参与者的专业知识，每个参与者在体验式课程中都带来相关的经验，有些经验可直接应用，有些可能从之前的工作状况或遭遇牵涉到类似的经验。大多数的学习是来自于同学，学员可以建立自己的计划，提供很多机会让参与者彼此学习。
实际问题的解决。体验式学习着重在现实世界。课程会安排机会并让参与者运用课程内容解决其正经历到的实际问题。运用课程内容，不只是发生在训练之后，而且是在课程进行时的主要焦点。当参与者将所学运用在解决自己的状况和案例上时，是他们学习得最好的时候。这给予直接的实用信息，并赋予参与者在问题点上运用的能力。

3.4 实施阶段

敏捷转型的实施需要从多个方面共同努力。由图2-1可以知道，许多敏捷的实践和价值观依赖于其他实践或价值观，因此在开始敏捷实施的时候，从什么实践开始是一个需要探讨的问题。

在2-1的基础上，图3-5圈出了所有的不被别的方法依赖的实践。这些实践可以作为敏捷实施方法的起始点。根据具体的项目情况，实施者可以考虑选取不同的起点。

图 3‑5 敏捷转型实施的起点图

可以看到，在图3-5圈出的实践中，可以简单的分类为四类实践，这四个方面的实践是敏捷转型实施的基础：自动化测试和持续集成，需求管理，迭代和可视化管理，人的价值观和团队观的建立。

另外可以从图3-5观察到一个有趣的现象，就是SCRUM方法倡导的实践，例如每日Scrum会议（站立会议）, Sprint（迭代）, Retrospective（回顾与总结），产品Backlog（用户故事）在上述四类基础实践中已经被涵盖。

SCRUM得到了极大的赞美和广泛的实施的原因，是因为SCRUM所涉及的敏捷转型实施成本最低，而且其实践的互相依赖性较低，即适用性较强。因此越来越多的团队实施敏捷是从SCRUM开始。然而，可以预料的是，当团队的敏捷实施进入到一定的阶段，更多的敏捷价值观需要得到体现的时候，仅仅依靠SCRUM所倡导的管理实践无法完全的达到，必须依靠引入更多其它的实践来完成，例如XP所提到的部分实践。

下面将按照前文进行当前情况评估时所建立的四个维度来分别介绍在每个维度中如何具体进行转型实施的方法。

3.4.1 针对个人技能层次的敏捷转型实施方法

针对个人和技能层次的敏捷转型实施方法主要关注在提升个人的能力的同时，也提高个人对交流和学习的意愿和能动性。

3.4.1.1 培养使用持续集成环境和自动功能测试的习惯

该实践的目的是建立敏捷实践的基础设施，增强团队成员对于持续集成结果的关注。实践原则包括：将基础集成环境的意义深入人心，提高集成结果的可视度。

持续集成环境和自动功能测试是敏捷方法所有实践的基础。如果没有持续的集成，所有的被提交的自动测试都无法被验证，因而开发人员也无法知道这次修改的代码是否破坏了原有系统的功能。

持续集成的环境应当从简单做起。一个团队首先从一台服务器开始，当系统达到一定的复杂度时，再增加服务器以提高运行速度或改进集成方式。一个团队应当从第一次提交代码就开始使用持续集成。

自动功能测试是从系统外部进行测试的黑盒测试，对于代码的内部结构不需要了解即可编写。在团队开始实施敏捷之初，可以考虑让测试人员先负责自动功能测试的编写，并在持续集成环境来执行。所有的测试都应当尽量做到自动化。

持续集成环境最容易被忽视的一个原因，是不可见的集成结果导致了无人无人问津，或者过多的集成失败导致了无人乐于进行修复。在实施此实践的时候，团队应当强调该实践的纪律，即谁破坏谁修复，而没有修复之前禁止提交新的代码。

另一方面，该实践可能会导致开发人员倾向于减少提交代码次数以防止提交失败，这种情况的出现需要提前预防，需要介绍频繁提交的好处和鼓励提交。将集成失败用一种比较轻松的惩罚方式来带给团队，比追求提交成功率更有效。有的敏捷团队使用一个帽子，当集成失败的时候，导致集成失败的带上帽子修复，而带上帽子这种小惩罚，并不会引起开发人员的反感，反而会促使他尽快的修复。

3.4.1.2 由资深敏捷教练带领采用相对复杂的技术实践

该实践的目的是让团队理解敏捷方法的基础技术原理，提高代码的适应性。实践原则包括：由有经验的教练带领进行，并在带领的过程中手把手的教练。

为了保证良好的适应性以适应未来的变化，测试驱动开发和重构是在敏捷实践中的两块基石。而这两种实践需要开发人员在开发的过程中进行很大的工作习惯改变。因此，由有经验的敏捷教练带领来完成效果会相对较好。

敏捷教练的职责是和团队中的开发人员进行结对开发，将其技能手把手的传递给团队成员。当团队成员遇到问题时，可以随时向敏捷教练咨询。敏捷教练应当在结对开发之外，花费一些时间给开发团队进行集体的技术培训或讨论。

实施结对编程是另一种良好的方法来促进个人的能力提高。当敏捷教练教会给团队成员一些初步知识的时候，两个团队成员可以在一起结对的完成工作，按照严格的测试驱动和重构的步骤来共同协商完成。在开发过程中，两个人的互相交流和探讨，能够发现技巧上的问题，而这些问题可以由敏捷教练帮助解决。

3.4.1.3 采用合适的需求划分方式

该实践的目的是划分需求到适当的粒度以便开发任务的完成。实践原则包括：需求的划分需要遵循INVEST原则。

当测试驱动开发和重构开始实施的时候，如果需求的管理无法跟上，那么开发人员有可能无法顺利的写出测试代码。测试驱动开发中所指的测试一般是单元测试，而实质上，测试代码应当完备的描述需求的验收条件。因此，如果需求的划分不能够达到一定的粒度，测试代码的编写就会陷入非常复杂的地步。

需求的划分技术一般分为横向划分和纵向划分两种，有时会混合使用。团队应当根据具体的项目情况选择合适的划分手段。一般的，纵向划分会比较适合团队对于需求的理解，每一个需求都代表了一项用户的操作，这个操作可以为用户带来业务价值。这种划分方式就是用户故事方法。在《用户故事应用》一书中，Mike Cohn提出了划分用户故事的INVEST原则[20]，即：独立的（Independent）,可协商的（Negotiable）, 有价值的（Valuable）, 可估算的（Estimable）, 粒度小的（Small）, 可测试的（Testable）。

需求的管理应当由专门的人来负责，这个人一般被称为业务分析师或Product Owner。业务分析师的职责是负责在需求到达开发团队之前，将其划分并进行需求的细化。细化工作应当关注与未来1-2个迭代的需求，而不应该过于超前的考虑。当需求过于复杂师，应该由多个业务分析师来负责需求。

需求的划分对于大规模的项目来说，有可能涉及到和其他团队或部门的交涉。业务分析师应主动和其他团队协调开发过程，当协调中遇到问题时，应当寻求项目经理或更高层管理人员的支持。

3.4.1.4 建立日常的技术交流和学习机制

该实践的目的是降低团队的交流阈值，提高开发的效率，培养学习的氛围。实践原则包括：鼓励交流、鼓励分享，将学习和提高养成一种习惯。

在开发团队中，快速提高新手的技术水平和开发效率能够极大的增强开发团队的效率。同时，有经验的人其经验也各不相同，如果能够互通有无，则可以提高团队的总体技术能力。

团队中进行技术交流的方法包括：

结对编程。结对编程是效果最好的知识传递手段，在《结对编程》一书中，作者列举了很多结对的模式[[iii]]。最好的两种模式则是：老手和新手结对以及两个有经验的人但知识互补的结对。
每日15分钟的技术演讲。由团队中的人轮流在每天花一点时间对项目中的中采用的实践或技术做讲解，在提高个人能力的同时，团队对于某项技术的掌握也可以得到提高。
每周定期的交流午餐会。每周约定一个中午，由团队经理组织午餐会，将午餐送入到会议室，一边享用午餐一边由一个人负责讲解一个技术话题。这个时段将会是开发团队对团队最期待的时段之一。
公司组织的敏捷培训。公司组织的敏捷培训应当持续的开展。并可以考虑请已经开始实践敏捷的项目成员来担任助教，来培训尚未开展敏捷实施的其他团队。

3.4.1.5 鼓励员工参与技术和敏捷社区的交流

该实践的目的是培养团队不断学习和交流的态度。实践原则包括：鼓励员工学习和采用新技术，鼓励员工参与社区活动。

敏捷方法本身诞生自技术社区，最活跃的技术和敏捷实践都在社区中传播。因此，鼓励员工去参与社区的活动，一方面可以提高员工自身的能力，另一方面，员工也可以带回一些其他公司的实践经验来进行参考。

参与社区交流的方式主要有：参加网上讨论组或论坛、参与技术书籍的翻译或编写、参加本地的兴趣小组或技术聚会。参与这些活动对于扩展员工的眼界、提高员工的自信会有很大帮助。公司应当提供相应的支持，例如将参与一些脱产的技术大会机会作为奖励提供给为团队贡献多的员工等等。

有的公司甚至把参与技术活动或技术会议当作是招聘、市场宣传、员工培训的机会来利用。这都是可行的。

3.4.2 针对过程层次的敏捷实施转型方法

针对过程层次的敏捷转型实施方法主要应关注提升过程中的交流和反馈。交流应当包括和管理者、协作者、其他部门、客户以及团队内部的交流。

3.4.2.1 采用一切可以提高效率的交流和反馈手段

该实践的目的是提高交流的频度和效果，通过反馈来改进质量。实践原则包括：鼓励员工采用高效交流手段，鼓励员工创新交流手段。

很多问题都源于交流不充分，敏捷的项目经理应当致力于提高交流效率。在团队中，交流发生于实体的边界。可以采用的交流方式包括：

每日站立会议。每天专门的一个时段，聚集团队所有成员，将发生的事情、计划、以及遇到的问题和别人交流。尽可能简短的让所有人都理解这个团队正在发生什么。
结对编程。前文已经介绍过，结对编程是非常高效的交流手段。
需求讲解会议。用于将新的需求批量的介绍给团队成员。可以作为迭代的启动来进行。

对于客户、用户或业务部门，则可以定期的邀请到团队开发现场来交流。

用户测试。邀请用户来进行早期的测试，以便尽早的发现需求问题。
演示。每个迭代结束后进行演示，获得客户和用户的初步认同。
定期的报告。每个迭代或每周发送进度报告给相关的人员，以便他们了解项目的情况

对于分布在不同地理位置的团队，更是要创新的实施更多的交流手段，例如：

定期的交换人员。交换人员到异地进行开发和交流，以建立私人关系。见过面的交流比没有见过面的人的交流会有效的多。
每日情况报告。每天将相关的进度和问题通过邮件或视频等方式，发送到其他地方的团队。以便协调进度和快速解决问题。
用最快捷的方式来交流。遇到紧急的问题，不能等待邮件的联系，必须要鼓励团队成员采用电话或IM进行更快捷的交流。
为了交流调整工作时间。如果能够做到异地的团队共有一段工作时间则更理想。例如中国和英国之间会有1-2个小时的工作时间重叠可以用来开会或交流，而和美国之间可能正好相差12个小时。如果可能，可以考虑调整团队的上下班时间来和另外的团队协作。
记录关键决策。对于影响架构或需求等方面的决策和重要交流，应记录在合适的地方，这些知识往往散布在邮件中或在某些会议内，这些往往是异地团队不能获得的重要知识。考虑采用Google Wave，Barcamp之类的协作管理软件

3.4.2.2 用规律的开发流程开始第一个项目

该实践的目的是利用成熟的实施经验，避免修改过程不当带来的损耗。实践原则包括：在自己定制团队的过程之前，先采用标准的过程来开始敏捷实施。

团队进行的第一个项目最好能够按照标准的迭代过程来进行。建议团队采用2周的迭代长度来实施。过长的迭代可能导致需求不能得到响应，过短的周期对于团队的压力又比较大。因此2周对新采用敏捷的团队是一个合适的长度。

敏捷转型开始的时候应当遵循完善过程，例如进行迭代启动会议、每日例会、演示会议、迭代的回顾会议等活动。这些活动能够使团队理解敏捷方法和度过初期的适应性阶段。对于新加入敏捷团队的成员来说，在实施第一个迭代的过程中，可以从书本上找到这些陌生的概念的解释，会对他们实施敏捷带来足够的信心。

每个公司可以考虑定制自己的推荐敏捷流程，作为推广敏捷实践的起点。然而，这种标准的定义必须要小心谨慎，不可以将其作为一种衡量一个团队是否敏捷的尺度，更不能不允许改进。因为每个团队的情况不可能一致，而必须符合一个标准的过程，则只能为团队带来约束和限制。

3.4.2.3 采用可视化管理

该实践的目的是将项目的进展展示给所有人，提高大家对过程的关注度。实践原则包括：用图表或任何可视的形式，将过程中的信息展出来。

可视化管理是敏捷项目管理的第一步。当团队将他们的工作展示出来的时候，首先团队内部对于过程和进度会有更多的注意力，有助于改进过程或发现问题。当其他人员，例如管理人员或客户看到这些可视的图表或进度时，他们也会对团队的成果表现出兴趣，从而可以对项目提出反馈。

可视化管理可以有许多种，每个团队也可以创新的做出新的可视化报告。此处列举一些如下：

持续集成的结果指示灯。将持续集成的结果用一个指示灯连接起来，当出现问题时灯量，用以提醒开发团队注意代码的质量。
卡片墙。将所有的需求书写在卡片上，在墙壁上移动以表示进度状态。可以用来做任务分配和进度跟踪使用。团队中有多少任务在开发，有多少任务等待测试在墙壁上一幕了然
迭代进度燃尽图。将迭代的进度绘制成燃尽图，在墙壁上展示出来。
愿景图。制定团队本迭代的目标，将目标贴在墙壁上，时刻提醒团队在这个迭代中要实现的目标。
风险分布图。将项目风险按照严重程度在分不同的色彩画出图，贴在墙壁上以提醒团队关注最大的风险。
团队日程表。将团队中有人请假或缺席的日子标记出来，以便其他人提前安排日程或相关的事宜。同时对于每周重要的日子，例如交流午餐会等活动在日程表上标记出来。
缺陷分布图。记录每日发现和修复的缺陷，以跟踪产品的质量。一旦发现缺陷几天未能修复，则可以立即知道开发出现了问题。

将过程中的需要管理和交流的信息贴在墙壁上，是借鉴自FDD（特征驱动开发）的一种实践，该实践在精益生产中被称为看板管理[[iv]]（Kanban Management）。该实践被认为能够极大的提高生产效率。

3.4.2.4 尽早引入数据库管理员(DBA)和系统支持人员(DevOps)

该实践的目的是提高数据库和系统方面的敏捷性。实践原则包括：尽早引入数据库管理员或信息系统人员等人的参与，在团队中为他们留下一席之地。

随着敏捷方法的发展，一些实践人员也开始注意到，如果一个系统的基础设施和数据库部分不采用敏捷方法，那么整个项目的敏捷过程将会受到限制。例如当产品发布了却因为系统基础设施问题无法上线运营，或者因为基础设施的欠缺导致集成测试或系统测试无法进行等等。

因此，一个随之而来的改进，就是在系统开发初期就引入数据库设计及系统管理人员的参与。

环境的建立。一些团队在开发机建立了数据库环境，以提高开发速度。而当需要测试时，则在某个服务器上来进行集成或系统测试。
演进式数据库设计。迭代式开发导致了数据的演进问题。当迭代一做好的数据库设计在迭代二需要修改时，数据库管理员需要专门的数据库演进方法和迭代过程保持一致[19]。
系统管理人员的早期介入构建的优化。系统管理人员对于系统的了解可以帮助开发团队进行构建的优化以及持续集成环境的优化。一旦出现资源不足的情况，系统管理员可以立即帮助开发团队增加或改善持续集成系统的部署。

然而，很多公司的系统管理人员和数据库管理员都处于另外的部门，因此在需要他们介入的时候会涉及部门之间的协调。这就涉及到组织层面的敏捷转型实施，后文会提到。

3.4.2.5 拉动客户与用户的参与

该实践的目的是尽早得到反馈，并因此改善产品质量。实践原则包括：按照一定的周期来拉动客户和用户的参与，提高用户和客户的兴趣。

反馈是改善质量的必经途径。建立良好的反馈机制是敏捷团队项目经理应当重点考虑的问题之一。在敏捷开发过程中，客户和用户应当来参加演示或测试活动。

用户测试。研究用户的使用习惯和场景，让用户试用系统或系统原型，找到最佳的操作方式。理想状况下每个发布应当至少有一次用户测试。
客户演示。客户应当至少每个迭代来参加系统展示会议。如果客户能够持续的关注开发，即作为现场客户参与到开发过程中则是最理想的状态。
客户确认需求。敏捷团队的需求来源于客户。客户可以是第三方的甲方也可以是公司内部的市场部门。

项目团队应当考虑吸引用户和客户的参与。客户和用户都有自己的工作，很少有可能长期处在开发现场。因此，一个良好的定期沟通机制需要由项目经理或业务分析师来维持。定期去拜访客户，坚持邀请客户或用户来参加团队的活动，帮客户或用户养成关注开发团队和开发进度的习惯。客户和用户一但建立了关注开发的习惯，那么参与度会大大的提高。

敏捷需求管理的重点，在于让多方客户达成共识。由团队负责开发的成本估算，让客户来负责开发优先级的排序。其前提是需要对客户进行一定的敏捷开发的知识介绍，使其了解开发团队的节奏和能够配合开发团队的进度要求。

3.4.2.6 鼓起勇气和管理人员报告

该实践的目的是和管理者建立良好的互动关系，获得管理者更大的支持。实践原则包括：报喜也报忧。建立周期性的报告机制。

管理人员所关注的方面在于项目是否按期、保质完成。而管理人员不希望在最后一刻才知道一个坏消息。因此开发团队应当把进度定期的报告给管理人员。用昨天的天气预测今天的天气。让管理层始终了解开发团队的最新进展。

项目经理应当和管理人员沟通，建立好一个（至少）按照迭代的交流制度。如果没有异常情况，则每个迭代必然要报告进度。最理想的情况是一切按照计划完成。在迭代燃尽图上应当能够看到平滑的曲线。

项目经理应当在报告中提出项目的风险列表，并在每个迭代更新风险的数据。这样高管人员会对项目中有所变化的风险进行关注。一旦风险系数变大，项目经理需要高管的协调和支持的时候，不会出现突兀的感觉。

管理人员应当也了解敏捷的过程和管理方式。项目经理在向高管汇报的过程中，应当也逐步的向他介绍敏捷的实践方法，并邀请高管人员到团队开发现场参观。

3.4.2.7 持续的改进开发过程

该实践的目的是改进开发过程，提高生产效率。实践原则包括：关注于软件开发中的浪费，鼓励全体团队成员的共同关注。

开发过程的改进是无止境的。项目团队应当把持续的改进，不断的追求更好作为团队的目标之一。在每个迭代结束的时候，应当回顾上一个迭代的得失，并在后面的迭代中改进。

敏捷方法提倡采用回顾会议的形式来帮助团队来提高效率：

回顾会议的形式：回顾会议可以有很多种形式。常见的包括：五星图、好坏图，时间线等方式。这方面可以参见相关资料[[v]]。不同方式的目的是相同的，即找出什么做的好，什么做的不好，好的继续发扬，不好的想法改进。开发团队可以考虑每次采用不同的方式来进行以增加团队成员的参与度。
回顾会议的召开时机：回顾会议应当在每个迭代结束或开始时进行。每个版本发布时也应当做一个针对于版本的回顾。对于大型多团队协作项目，团队之间的回顾也是必须的，应该保持一定的周期来举行。
回顾会议的注意事项：回顾会议的目的是为了提高开发团队的效率，并不是为了找出团队的责任人。因此，在进行回顾会议的时候，团队集体责任制文化的建立相当的重要。

3.4.3 针对团队文化的敏捷转型方法

针对团队文化的敏捷转型实施方法主要应关注提升过团队的价值观。这些价值观包括：平等、集体责任制、乐于学习、拥抱变化等等。

3.4.3.1 对团队成员进行领导力训练

该实践的目的是提高成员的责任心，发掘未来的领导者，建立自组织的团队。实践原则包括：每一个团队成员都可以成为领导。

敏捷方法认为人是“自动人”，认为人是需要实现自我价值的，人是具有主动性的。这样特质的人需要经过一定的训练来激发出来，而“领导力”训练是可以选择的一种方式。

领导力（Leadership）[[vi]]可以被形容为一系列行为的组合，而这些行为将会激励人们跟随领导去要去的地方，不是简单的服从。领导不是职务地位，也不是少数人具有的特权专利，而是一种积极互动的目的明确的动力。通俗地讲，领导就是引导团队成员去实现目标的过程，主要包括以下几个方面：

引导：涉及到领导者的领导技巧，包括授权和管理下属等。
团队成员：在团队中员工的人际关系、沟通、冲突管理以及团队建设和维持。
目标：涉及到企业的战略目标的制定和决策。
实现过程：涉及到战略实施中的执行，以目标为导向的组织变革和组织创新。

敏捷方法中对于自组织自适应的团队，其基本的思想建立在领导力的基础上。（参见2.2.2.5）。团队成员具备了领导力能力，可以使得项目经理的管理风格得到改变，从命令型进展到支持型或委任型，从而达到自组织的境界。敏捷转型中需要培养足够的领导者以便进行大规模的转型时，去带领团队。

领导者有六项特质不同于非领导者──进取心、领导愿望、诚实与正直、自信、智慧、工作相关的知识[43]。管理人员应当以领导者来要求自己，事实上，敏捷团队需要的是领导者而不是管理者。在《敏捷迭代开发》一书中[[vii]]，作者这样定义项目管理者角色：教练式的指导、服务性的领导、提供资源、维护远景、扫除障碍、倡导敏捷原则。这就是领导者。

3.4.3.2 建立宽松和人性化的环境

该实践的目的是提高工作舒适度，提高团队的士气和归属感。实践原则包括：对工作环境进行部分改善，关注开发团队的切身体验。

对于开发环境的关注早在1987年《人件》一书中就有所阐述[27]。敏捷转型过程中，对于开发团队所处的环境也应当予以关注。

技术人员的要求实际上很简单：一个能够不断学到新知识和新技能的职位，一个融洽的团队，一个舒适宽松的开发环境，一份成长的空间。而这些简单的需要，恰恰是许多公司所忽视的地方。

有的公司认为开发团队是成本中心，所以给他们买最便宜的桌椅——而恰恰是开发人员们一天都依赖于这样的桌椅为公司创造价值；有的公司要求开发人员必须上班打卡——与之相对的，开发人员绝对不会晚下班一分钟。有的公司认为封闭训练可以提高开发效率，而开发人员也有自己的生活要过。这些问题长期存在于中国现在的软件公司中。

改造公司的开发环境，可以先从下面的项目做起[[viii]]，如：

在办公室的一角开辟一处饮食区，提供免费的饮料和食品。
增加白板数量，以便随时有人记录和讨论一些东西。允许在墙壁上贴项目进度。
改进公司办公家具，用宽敞的利于交流的桌子并为员工提供更舒适的座椅。提供一个可以暂时休息的场所。
在室内摆放花草，经常开窗通风。
换用大显示器和高性能的开发用机。（这一项立竿见影的提高效率）
停用打卡系统，允许团队自主决定上下班时间。但团队每个人都需要遵守。
每迭代免费提供一次午餐以进行交流午餐会

这些项目成本不高，但其收效是明显的。不论是技术部门还是其他部门，都会为公司这一点人性化的举动感到高兴。有了高昂的士气，做事情也会更加积极高效。

3.4.3.3 建立安全畅通的交流环境

该实践的目的是提高生产效率，获得更真实的反馈。实践原则包括：以平等为基础，不指责个人的错误，团队集体承担责任。

在3.4.2.7提到总结与回顾会议的有效性依赖于团队文化。这种团队文化就是平等、集体承担责任的文化。正是由于人的“自动性”和“复杂性”，当个人受到批评的时候，其自我主动性就会受到挫折，从而会产生消极的情绪。在敏捷的团队中，如果不能够建立一种允许错误和团队承担责任的文化，那么将不会有人乐于说出自己的看法，更不可能提出改进建议。

《敏捷回顾》[42]一书中，提到了建立安全环境的一种方法：安全度测试法。每当进行敏捷回顾实践之前，由主持人进行调查。将参与人对于是否敢于说真话的分为5个级别，如果是1则代表什么都不说，如果是5则代表什么都说。当平均调查结果低于4的时候，那么就请在场的领导或项目经理离场，重新再调查。

这种方式在一定程度上改进了敏捷回顾方法的施行效果。然而，这样的施行依然不能从根本上改变团队的价值观。团队的价值观必须要通过长久的适应才能逐步改变过来。每一次进行敏捷回顾之前，都必须要宣读敏捷回顾的“最高指令”(prime directive)：“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴”[[ix]]。

3.4.3.4 培训交流技巧和反馈技巧

该实践的目的是提高交流的效率和效果，获得更有效的反馈。实践原则包括：鼓励交流，鼓励反馈。让团队人员都了解提出意见和建议的方法。

团队的顺利交流和反馈还依赖于团队成员的交流和反馈技巧。如果团队成员技巧不足，很多原本可以很快解决的问题将会被放大和被复杂化。例如，两个技能相差不多的人在结对编程的时候很容易想到不同的技术方案，而又坚持己见争执不下。而如果他们接受过交流训练，通过理性的分析，很快就能达成一致。

交流和反馈技巧主要包括以下的内容[[x]]：

交流的唯一目的是达成共识。
交流的基础是尊重，不要以反对的词开始一段交流
交流是双向的。要用心听，认真反馈。
提意见建议之前，先赞扬好的一面
提意见建议的目的是提高效率和增强信心
提意见建议要针对行为，要具体。

当团队成员都熟悉了交流和反馈的技巧，那么开发过程中的交流和反馈效率会得到很大的提升。当团队聚集在一起进行反馈的时候，这个就是敏捷回顾实践。同样的这样的回顾实践也依赖于团队成员了解并熟悉交流和反馈的技巧。

3.4.3.5 鼓励员工的主动性

该实践的目的是提升开发效率，长期培养员工的能力。实践原则包括：鼓励或奖励团队成员的主动行为。

敏捷方法对于“自动人”的重视使得项目经理不得不考虑对于人的激励和培养。针对“自动人”的激励方法是：扩大工作范围；尽可能把职工工作安排得富有意义，并具挑战性；工作之后引起自豪，满足其自尊和自我实现的需要；使职工达到自己激励。Douglas Gregorj主张："管理的任务只是在于创造一个适当的工作环境，一个可以允许和鼓励每一位职工都能从工作中得到'内在奖励'的环境"。

按照Chris Argyris教授的理论[[xi]]，“自我实现人”的管理应当注重如下的方面：

管理重点的改变。“经济人”的假设只重视物质因素，重视工作任务，轻视人的作用和人际关系。社会人的假设正相反，重视人的作用和人与人的关系，而把物质因素放在次要地位。“自我实现人”的假设又把注意的重点从人的身上转移到工作环境上，但重视环境因素与“经济人”假设的重视工作任务不同，重点不是放在计划、组织、指导、监督、控制上，而是要创造一种适宜的工作环境、工作条件，使人们能在这种环境下充分挖掘自己的潜力，充分发挥自己的才能，也就是说能够充分地自我实现。
管理人员职能的改变。从“自我实现人”的假设出发，管理者的主要职能既不是生产的指导者，也不是人际关系的调节者，而只是一个采访者。他们的主要任务在于如何为发挥人的智力创造适宜的条件，减少和消除职工自我实现过程中所遇到的障碍。
奖励方式的灵活多变。“经济人”假设依靠物质刺激调动职工的积极性，“社会人”假设依靠搞好人际关系来调动职工的积极性，这都是从外部来满足人的需要，而且主要满足人的生理、安全和归属（交往）需要。“自我实现人”认为，对人的奖励可划分为两大类，一类是外在奖励，如工资、提升、良好的人际关系；另一类是内在的奖励，内在奖励是指人们在工作中能获得知识，增长才干，充分发挥自己的潜力等。只有内在奖励才能满足人们的自尊和自我实现的需要，从而极大地调动起职工的积极性。
制定灵活适应于个体的激励方式。要重视个体的情况，认为每一个人都有其自身的需要。不能因为敏捷方法重视“自动人”或“社会人”就认为所有的人都期许内在奖励。
管理制度的改变。从“自我实现人”的假设来看，管理制度也要作相应的改变。总的来说，管理制度应保证职工能充分地表露自己的才能，达到自己所希望的成就。

3.4.4 针对组织级别的敏捷转型方法

针对组织级别的敏捷转型实施方法主要应关注改进组织的交流效率。包括：提高办事效率、改进考核体制等。

3.4.4.1 建立敏捷转型过程顾问团队

该实践的目的是用顾问团来帮助加快组织的敏捷转型。实践原则包括：采用随时可以找到的内部顾问形式，作为敏捷教练来帮助团队接受敏捷。

在第一个试点团队敏捷转型完成之后，可以建立一个公司内部的敏捷转型顾问团队，将第一个试点团队的成员的知识作为公司内共享的资源来按需发放。当试点项目完成的越来越多后，这个顾问团的人数也应该逐步增加。顾问团将逐步替代第三方咨询公司的职能，在第三方公司离开后，将完全取代咨询公司的职责，包括：

组织内部的敏捷培训，并培训新的敏捷教练
作为敏捷教练帮助团队进行技术实践
作为项目跟踪团队，负责推动敏捷转型实施的进展
改进现有的敏捷过程

敏捷转型过程顾问团的成员不宜过多，应当以能够引导正在转型过程中的团队人数为准。另外，顾问团的成员应当及时轮换，让一些新进的成员去帮助实施敏捷以积累经验，让有经验的成员回到开发团队中发挥更多的职责。

3.4.4.2 修订团队考核方法

该实践的目的是改进开发团队的工作效率和工作动机。实践原则包括：避免按照代码量或工作时间来考核，应按照团队工作情况考核。

敏捷团队的考核以及绩效评估必须要加以改变。有的采用工作记录法，即记录完成的代码量或工作时间。有的软件团队多采用目标管理法，即制定个人所要完成的目标，并加以跟踪。这两种方法在敏捷团队中都不适合采用。因为敏捷团队主张团队的责任，因此，凡是记录个人的工作量或工作目标的考核方式都会和敏捷方法本身产生冲突。

一种有效的考核方式是360度考核法。在一个敏捷团队中，让某个团队成员周围的人来评价该成员的成就和不足，通过定性而非定量的分析一个人的能力。值得注意的是，这里的评价即上文3.4.3.4中所说的反馈，考核的过程对团队成员来讲，就是对一个人提出反馈的过程，因此要遵循反馈的两个目标，即提高效率和增强信心。而提反馈的技巧也需要在考核发生之前培训。

值得考虑的是对于考核目标的制定。由于目标需要量化才能得到达成，而敏捷团队的构成使得目标很难量化。另一方面，敏捷方法对于人的主动性的期望，实际上淡化了对于目标的要求，即如果设立了目标，则人将会被目标所限制，而无法真正的发挥主动性。因此对于360度考核的体系来说，是否要设定一个具体的目标，是值得考虑的。一个可行的方法，是设定团队的价值观作为目标，而不规定某个人具体的行为目标，只考察一个人是否在价值观维度上做出了成就或贡献。

对于项目经理的考核方式应当以团队的成就为准。团队的气氛是否活跃；团队的技术能力和学习能力如何；项目是否按期保值交付；项目的敏捷过程实施是否顺利；客户是否满意；团队成员是否满意。这些维度应当体现在项目经理的考核当中。具体到不同的公司，维度可能会不同。

改进考核方法需要人力资源团队的配合。这也需要公司管理层的支持。相信通过试点的执行，管理层应当会对考核结果满意。

3.4.4.3 部门重组，建立多角色团队

该实践的目的是提升协作效率。实践原则包括：建立多角色协作团队

软件开发过程是一个多角色协作的过程。为了提升协作效率，将涉及到的角色集中到一个位置，减少移动和等待的浪费是进行敏捷转型实施应当考虑的方面。

具体到IT部门来说，传统团队经常把部门按照直线职能划分，每个人只属于一个部门，并且只向一个经理来汇报。而当需要团队协作时，人员常常跨部门来工作。例如建立了需求部门、开发部门、测试部门、质量保证部门等等。这样的分割实际上从物理上割裂了软件开发过程，导致了开发过程中的多种浪费的出现。更好的部门组织方式是按照项目或产品来组织团队，采用矩阵式管理。

矩阵制组织是为了改进直线职能制横向联系差，缺乏弹性的缺点而形成的一种组织形式[[xii]]。它的特点表现在围绕某项专门任务成立跨职能部门的专门机构上，例如组成一个专门的产品（项目）小组去从事新产品开发工作，在研究、设计、试验、制造各个不同阶段，由有关部门派人参加，力图做到条块结合，以协调有关部门的活动，保证任务的完成。这种组织结构形式是固定的，人员却是变动的，需要谁，谁就来，任务完成后就可以离开。项目小组和负责人也是临时组织和委任的。任务完成后就解散。因此，这种组织结构非常适用于横向协作和攻关项目。如图3-6所示。

图 3‑6 矩阵式组织结构

矩阵式管理削弱了组织层次对于项目的影响，提高了开发效率。但如果员工长期的做同样的事情，那么他的主动性将会极大的削弱。因此，应当鼓励员工更换和尝试新的职位或在不同的项目之间轮换。公司的人力资源部门应当主动的将员工的意向纳入到员工管理的范畴，定期更换员工的角色和所作的工作以对其进行激励。

然而，矩阵式的管理可能会对员工带来不安定的感受。因为团队的生命周期仅限于项目或产品的周期，一旦项目完成，员工的归属感就会丧失。这种情况则应当通过调整团队经理和功能经理的职权来解决。更进一步的，可以考虑将团队组织成为固定的结构，将项目或产品作为可变的维度来分派给团队。

3.5 扩展阶段

当试点团队执行敏捷转型实施达到一定的效果，得到敏捷转型实施管理团队的认可之后，可以考虑将敏捷转型扩展到更大范围来实行。

3.5.1 扩展阶段依赖于人的成熟

该实践的目的是提高扩展阶段的成功率。实践原则包括：致力于培养“离”阶段的人，多培养敏捷的领导者。

对于试点效果的验证主要应考察试点团队的团队成员的能力成熟度。通常的，对于参与敏捷转型的个人，其学习的阶段将会经历“守-破-离”(shu-ha-ri)[30]，换用国文来说，这三重境界就是：看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水。

守的阶段，主要是学习技能。参与者以学生的身份跟随老师教导的一切，循规蹈矩，不敢突破。在这个阶段正是试点团队一开始所面临的阶段。
破阶段，突破框架阶段。当实践进展了一段时间，学生的身份转变为了实践者，他们发现了正在使用方法的局限性，开始学习不同的实践和方法，了解不同的方法适用在什么场合，以及其背后的深层次原因。
离阶段，融会贯通阶段。实践者的身份转变为领导者。他在不同的环境下，可以根据具体情况找到或创造适合的实践出来。是否遵循标准的过程方法已不重要。

因此，当进行试点项目的时候，必须要通过持续的关注来培训和考察团队中的人，帮助他们快速的成长。当有人可以达到“破”阶段的时候，可以考虑进行扩展试点。参见图3-4。此时这些达到“破”阶段的人，在咨询师或敏捷教练的带领下，可以在新的团队和项目中来继续锻炼。

当团队中出现了“离”阶段的人，就可以考虑开始大规模的推广敏捷转型实施。而这些达到“离”阶段的人，就是新的转型实施团队中的敏捷教练。

3.5.2 扩展的方式

该实践的目的是提高扩展阶段的成功率和转型速度。实践原则包括：根据人力和不同的项目情况，配备不同数目的“种子”来带领扩展。

当需要进行敏捷转型扩展实施的时候，有多种实施策略可以帮助“种子”进入到新的团队中。

分拆方法。按照一定比率的人数将种子团队拆散到待实施敏捷的团队中。这样可以达到指数增加的效果。例如一个10人的试点团队，每2个人去加入到一个8人的新团队，则可以带动50人的新转型团队。这样做的好处是简单易行，但每个新团队需要足够的支持和帮助，并且10个“种子”有时并不都达到“离”的阶段。

轮换方法。每当有人达到了成为敏捷教练的水准，则将这个人轮换出去。一直保持一个试点团队的运行，将其视作训练营团队。例如10个人的试点团队有2个人可以毕业，则选取2个新人加入试点团队，2个毕业生则去开展实施新的敏捷转型团队。只有毕业的“种子”可以出来帮助新的团队进行实施。这种做法的好处是可以保障新团队实施的效果，但速度因人而异，可能会比较缓慢。

根据项目和组织的情况，敏捷转型管理团队应当因地制宜，采取适当的方式来进行扩展实施。

3.6 持续的跟踪和持续的培训

在图3-2中，除了起始，规划，执行，扩展四大阶段之外，另外两项重要的活动是持续的对敏捷转型进行跟踪和指导，以及持续的对团队进行培训。这两项活动应当贯穿在整个敏捷转型的过程中，不可有丝毫的放松。

持续的跟踪、支持、反馈、改进的过程应当由敏捷转型管理团队和过程顾问团队来负责。他们应当采用和敏捷方法相同的方式，迭代式的获取反馈，通过组织回顾会议来提高执行效率和改进不足；与各方面紧密交流，减少误解；并通过可视化的宣传方式向所有人公布敏捷转型方法的进展和成果。

持续的培训则由过程顾问团队来负责。他们采用体验式培训方式，定期举办培训活动。未曾参加过活动的员工，包括非技术部门的员工，都应当参与敏捷训练营，以理解敏捷的做事方式和价值观，以便更好地支持组织转型的过程。

（完）

第四章为实际应用和分析，第五章为总结。此处从略。

[[i]] SEI, “The IDEAL Model” [EB/OL], http://www.sei.cmu.edu/ideal, Software Engineering Institute of Carnegie Mellon University, 1997, 2009-04-20

[[ii]] Hobbs, T. “Experiential Training: Practical Guidelines” [M], Routledge, 1992

[[iii]] Williams, Laurie and Kessler, Robert. “Pair Programming Illuminated” [M], Addison-Wesley Professional, 2002.

[[iv]] Berkley, B. J. “A review of the Kanban production control research literature”. [C], Production and Operations Management, 1992, vol.1, no.4, pp.393–411

[[v]] Derby, Esther. Larsen,Diana and Schwaber, Ken. "Agile Retrospectives: Making Good Teams Great" [M],Pragmatic Bookshelf, 2006

[[vi]] “领导力” [EB/OL], http://wiki.mbalib.com/wiki/领导力, 2009-04-20

[[vii]] Larman, Craig. "Agile and Iterative Development: A Manager's Guide" [M], Addison-Wesley Professional, 2003

[[viii]] 李默，“敏捷团队建设” [EB/OL], http://blog.nona.name/200704244.html，《软件世界》, 2007.04, 2009-4-20

[[ix]] Rising, Linda. 郑柯（译），“敏捷回顾活动‘最高指导原则’答疑解惑” [EB/OL], http://www.infoq.com/cn/articles/retrospective-prime-directive, InfoQ, 2008, 2009-4-20

[[x]] 李默，“关于交流和反馈”，[EB/OL], http://blog.nona.name/200904281.html, 2009, 2009-4-20

[[xi]] “自我实现人假设” [EB/OL], http://wiki.mbalib.com/wiki/自动人，MBALib, 2009-4-20

[[xii]] Organizational Structure [EB/OL], http://en.wikipedia.org/wiki/Organizational_structure，Wikipedia, 2009-4-20

敏捷方法的价值观体系

2012-06-17T06:41:00.000-07:00

本论文题为《软件组织敏捷转型过程的研究与改进》，原文发表于2009年6月，有删节。

（二）敏捷方法转型中的常见问题及原因分析

2.1 敏捷方法的价值观体系

敏捷方法之所以在被提出之后由于效果显著而被广泛的推崇和传播，其根本原因在于它的价值观体系和新世纪的业务环境、组织环境的需要相一致。敏捷方法的价值观体系包括对于人的重视以及人应当具有的价值观点。

2.1.1 敏捷方法注重人的价值

“人和交互胜过过程和工具”是敏捷宣言的第一条。也是整个敏捷价值观体系中最重要的一条。人的重要性在敏捷方法中得到了突出强调。对人的管理，在管理学的发展史上存在一系列的不同看法。

2.1.1.1 经济人假设

“经济人”（Economic man）又称“理性经济人”(Rational-economic Man)、“实利人”或“唯利人”。这种假设最早由英国经济学家Adam Smith提出。他认为人的行为动机根源于经济诱因，人都要争取最大的经济利益，工作就是为了取得经济报酬。为此，需要用金钱与权力、组织机构的操纵和控制，使员工服从与为此效力。这种假设在管理学上是Edgar H．Schein在《组织心理学》[[i]]中提出。

此假设认为，人的一切行为都是为了最大限度地满足自己的利益，工作动是为了获得经济报酬。“经济人”假设及其相应的X理论曾风行于20世纪初到30年代的欧美企业管理界。这种理论改变了当时放任自流的管理状态；加强了社会上对消除浪费和提高效率的关心，促进了科学管理体制的建立。

2.1.1.2 社会人假设

早在20世纪30年代，George Elton Mayo教授就曾经通过霍桑效应 (Hawthorne Effect)[[ii]] 证明了人的社会性。从而提出了管理学中“社会人”假设[[iii]]。

“社会人”（Social man）的基本假设包括以下几方面内容：

从根本上说，人是由社会需求而引起工作的动机的，并且通过同事的关系而获得认同感。
工业革命与工业合理化的结果，使工作本身失去了意义，因此能从工作上的社会关系去寻求意义。
员工对同事们的社会影响力，更比对管理者所给予的经济诱因控制更为重视。
员工的工作效率随着上司能满足他们社会需求的程度而改变。

此假设得出的管理方式与根据“经济人”的假设得出的管理方式完全不同。从“社会人”的假设出发，采取不同于"经济人"假设的管理措施，主要有以下几点：

管理人员不应只注意完成生产任务，而应把注意的重点放在关心人和满足人的需要上。
管理人员不能只注意指挥、监督、计划、控制和组织等，而更应重视职工之间的关系，培养和形成职工的归属感和整体感。
在实际奖励时，提倡集体的奖励制度，而不主张个人奖励制度。
管理人员的职能也应有所改变，他们不应只限于制定计划、组织工序、检验产品，而应在职工与上级之间起联络人的作用。一方面，要倾听职工的意见和了解职工的思想感情，另一方面，要向上级呼吁、反映。
提出"参与管理"的新型管理方式，即让职工和下级不同程度地参加企业决策的研究和讨论

2.1.1.3 自动人假设

X理论和Y理论(Theory X and Theory Y)是管理学中关于人们工作源动力的理论，由美国心理学家Douglas McGregor 1960年在其所著《企业中人的方面》[[iv]]一书中提出来的。这是一对完全基于两种完全相反假设的理论，X理论认为人们有消极的工作源动力，而Y理论则认为人们有积极的工作源动力。

X理论是McGregor对把人的工作动机视为获得经济报酬的“经济人”的人性假设理论的命名。其主要观点是：

人类本性懒惰，厌恶工作，尽可能逃避；绝大多数人没有雄心壮志，怕负责任，宁可被领导骂；
多数人必须用强制办法乃至惩罚、威胁，使他们为达到组织目标而努力；
激励只在生理和安全需要层次上起作用；
绝大多数人只有极少的创造力。

Y理论即假设人是“自我实现”的，其主要观点是：

一般人本性不是厌恶工作，如果给予适当机会，人们喜欢工作，并渴望发挥其才能；
多数人愿意对工作负责，寻求发挥能力的机会；
能力的限制和惩罚不是使人去为组织目标而努力的唯一办法；
激励在需要的各个层次上都起作用；
想象力和创造力是人类广泛具有的。

因此，人是“自我实现人”（Self-actualizing man），也叫"自动人"。该理论认为，人类需要的最高层次就是自我实现，每个人都必须成为自己所希望的那种人，“能力要求被运用，只有潜力发挥出来，才会停止吵闹。”这种自我实现的需要就是“人希望越变越完美的欲望，人要实现他所能实现的一切欲望。”具有这种强烈的自我实现需要的人，就叫“自我实现人”，或者说最理想的人就是“自我实现人”。

2.1.1.4 复杂人假设

复杂人假设是60年代末至70年代初由Edgar H．Schein提出的[23]。根据这一假设，提出了一种新的管理理论，与之相应的是超Y理论。该理论认为，X理论并非一无用处，Y理论也不是普遍适用，应该针对不同的情况，选择或交替使用X、Y理论，这就是超Y理论。

这种理论是要求将工作、组织、个人三者作最佳的配合，其基本观点可概述如下：

人怀着各种不同的需要和动机加入工作组织，但最主要的需要乃是实现其胜任感。
胜任感人人都有，它可能被不同的人用不同的方法去满足。
当工作性质和组织形态适当配合时，胜任感是能被满足（工作、组织和人员间最好配合能引发个人强烈的胜任动机）。
当一个目标达到时，胜任感可以继续被激励起来，目标已达到，新的更高的目标就又产生。

根据超Y理论分析企业中职工需要的复杂性，可分为以下五点：

人的需要是多种多样的，而且这些需要随着人的发展和生活条件的变化而发生变化。每个人的需要都各不相同，需要的层次也因人而异。
人在同一时间内有各种需要和动机，它们会发生相互作用并结合为统一整体，形成错综复杂的动机模式。例如，两个人都想得到高额奖金，但他们的动机可能很不相同。一个可能是要改善家庭的生活条件，另一个可能把高额奖金看成是达到技术熟练的标志。
人在组织中的工作和生活条件是不断变化的，因此会不断产生新的需要和动机。这就是说，在人生活的某一特定时期，动机模式的形式是内部需要与外界环境相互作用的结果。
一个人在不同单位或同一单位的不同部门工作，会产生不同的需要。例如，一个人在工作单位可能落落寡合，但在业余活动或非正式群体中却可使交往的需要得以满足。
由于人的需要不同，能力各异，对于不同的管理方式会有不同的反应。因此，没有一套适合于任何时代、任何组织和任何个人的普遍行之有效的管理方法。

2.1.1.5 软件开发中的人

从管理学的发展过程，可以看到管理学对于人的看法在不断的改变和发展，在软件开发过程中对人的重视也存在不同的阶段。在20世纪六十年代的软件危机和随后提出的软件工程中，人的作用被忽视了。

为了解决当年的软件危机，人们认为可以用正式的稳定的过程来解决复杂多变的需求。正如工业化大生产中的生产线一样，一旦过程固定下来，风险就会被降低，产出的软件就能够提高质量。

软件的工程化带来了一定的好处，例如正式的文档、有据可依的标准。软件工程的出现使得软件开发摆脱了混乱的方式，初步确立了软件过程管理的科学。然而，软件工程化带来的一个最大的后果，就是管理人员认为软件工程是解决问题的银弹。这样的工程化方法忽视了软件开发最重要的因素，就是开发软件的是人，不是机器或流水线。人是有自己的需求和动机的，不能简单的把人看作是机器。

从20世纪80年代末期开始，软件领域的科学家们开始重新思考人在软件过程中的作用。1986年《人月神话》[6]一书中就曾经明确的提出，卓越的设计需要卓越的人才,而卓越的人才不是通过培训就能获得的，这就是软件业效率提升很慢的原因。1987年出版的《人件》[[v]]提出对于开发团队所处环境的关注。

2000年左右出版的《人件集》[[vi]]收集了在20世纪90年代发表的若干关于软件开发中人的文章，其中Larry Constantine写道：“人件，是第三次计算机革命的真正起源地”“我们经历了硬件危机、软件危机，有了优秀的编程语言和工具，为什么仍然不得不修改工作计划和追加预算？原因就是我们自己”“人，才是问题症结所在”。后来的《软件工艺》[[vii]]从另一个角度论述了软件开发离不开人的技能，只有人的技术才是保证软件开发成功的基础。

正是在这样的思潮下，在20世纪90年代出现的各种轻量级方法，都开始重视人的作用。

2.1.1.6 敏捷开发方法中的人

最初的科学管理认为，人是生产线上的一颗螺丝钉，是可以替换的和可以被忽视的。该理论在福特汽车生产线上获得了很大成功。然而，1950年后，日本丰田建立的生产方式采纳了“自动人”假设。后来这种生产方式被人称为精益生产，发挥了极高的生产效率。最终超越了福特和通用，成为世界上最大的汽车制造商。和精益方法关系深厚的敏捷方法同样也采纳了“自动人”假设。

敏捷方法论继承了自动人管理思想，认为必须要对人进行重视和激励，人与人之间的交流是解决许多问题的基本办法。敏捷软件开发方法的核心，就是注重人的作用，鼓励人和人的交流。敏捷宣言所附带的敏捷十二原则中提出：

在整个项目开发期间，商务人员和开发人员必须天天都工作在一起。
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
最好的架构、软件、设计来自于自组织的团队。

另一方面，敏捷方法也认为人是“复杂的”，因此需要对于不同的情况进行不同的考量。

Alistair CockBurn在《敏捷软件开发》中指出[[viii]]，要用纪律和宽容来应对人们的共同弱点：在方法论中设立机制来保证严格的行为标准被执行；设计能够容忍个体变化的方法论。

XP极限编程中对于技术实践的要求恐怕是所有方法论中最严格的。TDD和重构都有类似“军规”一样的守则。

由此可见，敏捷方法对于人的看法是采纳了“自动人”和“复杂人”的看法。认为人是需要实现自我价值的，人的主动性是生产效率的源泉。而为了提高生产效率，就必须给人宽松的环境，给人可以进步和学习的空间，并且允许人犯错误。然而，敏捷方法并不是宽松到给人任意发挥不顾大局的地步，而是有一定的纪律来约束人的行动，并且对于不够主动的人，要求他们按照一定的纪律来行为，这套纪律就是敏捷的价值观体系和实践体系。

2.1.2 敏捷方法的价值观

敏捷宣言体现了敏捷方法的价值观。敏捷宣言中提到的人和交流、交付价值、协作、适应变化是敏捷方法最基本的思想。除此之外，敏捷方法还继承了丰田生产即精益制造的管理思想。

Mary Poppendieck和Tom Poppendieck在其著作《精益软件开发》[22]中提出“精益原则已经在精益制造、物流和建筑领域取得成功。这些原则最终以敏捷软件开发的形式在软件业出现”。精益原则中对于价值、质量、消除浪费的重视也同样被继承到敏捷的价值观中。

2.2.2.1 注重交流和协作

软件开发最大的问题，实际上是交流问题。从20世纪60年代的软件危机，到近期CHAOS所做的软件行业调查报告中[[ix]]，可以看到软件开发的最大问题一直都是类似的，即客户需求不能得到满足，软件无法预期完成，客户不满意等等。而造成这一切的根本原因，是交流不够充分，这些交流包括：客户与开发团队之间的交流，开发团队内部的交流以及开发团队和公司其他部门交流等等。

Alistair Cockburn在其著作《敏捷软件开发中》[30]论证了交流方式和交流效率的关系，随着不同交流方式的采用，其交流效果可能递减。

根据Albert Mehrabian教授的研究成果[[x]], 交流由文字、声音和肢体语言三部分组成，而三部分所能够承载的沟通信息量百分比分别为7%、38%和55%。面对面的交流效果最好，其次是电话、邮件、最差的是用文档来交流。人的写作能力有限，阅读能力更是参差不齐，因而写出来的文字可能存在表达误差，阅读的人也可能存在理解误差。因此在软件过程中，交流越是低效，其开发效果也越差。

因此在敏捷实施方法中，项目经理应该采取一切可能的方法来提高团队内部交流和协作的效率。交流和协作效率的提高能够同时提高软件开发效率，提高团队对软件系统及需求的理解程度，降低误解率。与此同时，开发团队应当尽力提高和公司其他部门或管理人员的交流。只有足够的交流才能化解误会和矛盾，从而使得开发团队的敏捷过程得到理解和支持。而只有整个公司从上到下都对敏捷方法达成共识，敏捷的转型实施才能得以顺利的进行。

交流不仅仅是团队或公司内部问题，与客户的交流和协作更是对于敏捷开发有重要的影响。

软件开发的最终目的是要给用户交付价值，要达到客户的商业目标，从而完成公司目标。而为了实现客户和公司的双赢，软件公司必须加深客户协作的方式来达成目标。需求人员需要和客户一起工作，了解和认识客户，提出针对性的建议，帮助客户发现和识别业务价值，改进目前的系统。开发团队需要站在和客户同一方的阵营，和客户一起思考、学习和成长。

客户希望用低廉的价格买到他希望的功能，或者说，在一定价格内实现更多的功能。而公司希望提高价格，降低成本。两方需要进行博弈。而如果与客户不能良好协作，其博弈结果，就是双方都不能达到最好的情况，反而进入了著名的囚徒困境，即纳什均衡(Nash equilibrium)，或非合作均衡[[xi]]。

这种博弈的后果，就是不充分交流和协作导致的。而敏捷思想强调交流，目的是为了达到软件公司和客户的双赢（Win-Win）。

2.2.2.2 业务价值驱动

早期的软件过程方法都极端强调文档的重要性。例如RUP等方法，对于过程和过程中人的产出物极其重视，以至于开发团队常常陷入一种为了赶制各种工件以符合过程标准的境地而忽视了软件开发本身最重要的产出物－－源代码本身。

敏捷方法认为，文档虽然具有一定的作用，但真正能给客户带来价值的是可以工作的软件。只有将软件成功的交付，才能在此基础上再谈文档的价值。因此敏捷方法建议用户更多的关注于对于业务价值的交付，按照业务价值最大化的原则，对需求进行优先级的划分和对开发进行先后顺序的调整。

根据价值理论，现在的钱比未来的钱更有价值。因此敏捷的价值观提倡尽早的频繁的交付。在《价值驱动的软件开发》一书中[[xii]]，作者从财务的角度来分析软件项目和软件过程的投资回报ROI(Return Of Investment)，从而判断一个项目是否值得投资开发，如何选择特性的优先级，以及怎样发布才最大化ROI。

软件项目发布周期不同会造成ROI不同。迭代交付的项目所创造的价值比一次交付所创造的价值更多。

对于一个项目，假设初期投入是50，回报将会是100，项目开发期为1年，年利率是5%（可计算出半年利率2.47%，季利率1.23%），假设项目可以分为理想的3种：1次交付，2次交付，和4次交付。假设每次交付所获得的价值均等，那么可以做出如下的简单计算。

表格 2‑1 对于一个理想项目的现金流分析和现值计算[[xiii]]

	初始投资		第一季		第二季		第三季		第四季		合计
	收入	现值	收入	现值	收入	现值	收入	现值	收入	现值	净现值
A项目分1期交付	-50	-50	0	0	0	0	0	0	100	95．238	45.238
B 项目分2期交付	-50	-50	0	0	50	48.795	0	0	50	47.619	46.414
C 项目分4期交付	-50	-50	25	24.696	25	24.397	25	24.108	25	23.810	47.011

上述对理想情况的简单的计算，可以证明一个结论：项目交付的越频繁，项目可获得的实际价值就越高。并且如果项目规模更大，利率更高，这结果越明显。这是敏捷方法注重价值和频繁交付的最好证明。

2.2.2.3 识别和消除浪费

从字面上看，浪费(Waste)是相当明确的术语。但是精益原则为浪费赋予了新的定义：任何不能为客户创造价值的事务都是一种浪费。在软件开发中，应当根据团队和组织的具体情况来识别和消除浪费。

Mary & Tom Poppendieck列举了软件开发中的7种浪费：部分完成的工作；额外的过程；额外的特性；任务的调换；等待；移动；缺陷。

敏捷和精益方法永远在寻找那些能被节约的时间和能被减少的步骤，缩短产品交付期。敏捷方法应当鼓励对开发过程进行检查，调整，再检查，再调整。这个过程不能停止，不能给过程贴上“最优化”或者“最终版”的标签，使得对它的调整停滞下来。为了找出在开发中发生的浪费，首先必须了解开发过程，并且了解开发过程背后的价值观，才能改进过程。

2.2.2.4 注重质量和反馈

Deming质量观点认为，质量必须从客户的观点出发加以考虑。Deming对质量德定义是：质量是从客户的观点出发加强到产品上的东西。Dr. Genichi Taguchi是戴明奖获得者，他对质量的定义被世界工商界广泛应用 “质量是客户感受到的东西。

软件开发的交付物必须具备相当的质量，要满足客户的需求。只有获得了客户的满意才可以说软件开发的成功。而为了提高质量，交流之外的反馈则是必须的手段。

精益方法提倡关注反馈周期，提倡最小化事物从生产到被使用的时间最小化。在二十世纪七、八十年代（特别在美国），丰田汽车的质量之所以相对其它品牌有了一个彻底的飞跃，就直接是因为对反馈周期的关注。在软件开发中，对设计进行评审不是高效的反馈，用代码实现设计并展示给客户来反馈才是真正的反馈。

敏捷方法中的反馈包括多种层次。团队成员需要得到反馈以提高个人效能。所开发的软件需要得到反馈以提高质量：开发前需求需要获得用户的不断反馈，开发中的特性需要在团队内部通过测试进行反馈，开发完成的功能需要尽早得到客户的反馈。软件开发过程需要得到反馈以得到改进。

2.2.2.5 团队责任

敏捷开发对于人的重视必须得到团队和组织的认可才可能实行。一个团队必须从文化和组织两方面来适应敏捷方法的需要才能顺利的进行敏捷方法的实施。

团队建立一种团队协作的文化。敏捷方法将人视作是自动人和复杂人，认为人需要激励、需要受到尊重、需要获得机会以自我实现。因此，一个敏捷的团队应当建立一种互助、互相尊重、鼓励成功、允许犯错的文化。在这样的一种团队文化下，团队的个人才能够发挥最大的个人能动性。当因为种种原因导致项目出现问题时，这样的团队不应当指责个人的失误，而应该认为是团队的责任。同样，当团队顺利交付了产品并获得了成功时，成就应当属于团队而不是某个英雄的个人。

敏捷团队应当把建立一种自组织自适应的团队作为团队建设的目标。自组织团队的特性是：团队的每一个人都主动承担责任，每个人都为团队的成就而自豪，每个人都努力去改进团队的过程。在这样的团队中，项目经理或团队经理的管理风格是与传统团队截然不同的。

管理目的是帮助组织顺利地完成工作。Hersey和Blanchard将领导风格分为四种[[xiv]]：1）命令型；2）教练型；3）支持型；4）委任型。在传统团队最常见的是命令型的管理方式，而敏捷团队希望一个团队的领导能够向委任的方向发展，更进一步的，敏捷方法要求领导者不是按照职位的高低来决定，而是期望每个人都能发挥一定的领导和管理能力。

在这样的一种团队组织下，敏捷项目经理必须具备足够的领导力。敏捷项目经理的一项重要任务是培养更多具有领导力的人才。在软件行业以及其他更需要创造性的行业里，让每一个参与项目的人都具有一定的管理职能非常重要。

2.2.2.6 适应性

敏捷开发和传统开发方法最大的区别在于适应性。以往的软件工程方法都希望能够定制一种标准的方法，所有的团队根据该方法来进行实践，统一所有的制品格式或开发实践，他们认为这样能够保证把最优秀的实践完全传递到整个组织。

然而，这种工作被证明是低效的。根据复杂人的假设，不同团队和不同个人所追求的价值是不一样的。有的团队可行的实践在另一个团队可能不行。因此，敏捷方法的观点是对于具体的情况应当有具体的措施。每个团队所施行的敏捷方法都允许不同。

敏捷方法中的回顾总结实践（Retrospective）就是这样的一个团队自省的过程。团队定期举办这样的回顾，对于自己的行为提出反馈，通过反馈来改进自身过程的质量。这种不停的完善也正是精益思想所认同的。只有不停的改善，才能够获得更好的成果和更多的价值。

因此凡是在实施敏捷过程中，某个经理希望得到一种“标准化”且“不需要再优化”的敏捷过程的时候，他就已经违反了敏捷的价值观。

2.2.2.7 拥抱变化和创新

20 世纪90年代以来，随着知识经济的崛起和信息技术的迅猛发展，使世界进入了以知识为基础的经济时代。近20年来，没有任何一个人能够提前预测到技术和商业模式的发展。只有在不停的适应和拥抱新的变化的过程中进行创新才能够在新的经济中占据领先的地位。因此敏捷方法对于变化的适应和对于创新的支持也是适应了当前商业发展的需要。

传统软件开发方法尝试预测用户需求，而这种预测几乎从未准确过。敏捷方法的拥抱变化的能力来源于三个方面：客户协作、适应性计划的实施和完备的测试。客户的紧密协作能够使客户对变化作出响应和决策。适应性计划可以对决策作出及时的调整。而完备的测试则使得开发团队有足够的信心来对需求变更作出代码更改。

软件开发从诞生起始，就是由一群科学家和高学历的精英人士所建立的。其本质是依靠人才的知识和创新来完成工作。软件开发所需要的逻辑能力、学习能力、分析能力使得这种情况直到21世纪也仍然未曾有重大改变。对于知识人才的管理，在管理模式上需要有所改变。

知识经济时代呼唤知识管理，而知识管理又需要管理的知识。因此对人性的假设又有了新的发展，即提出了“创新人”（或称“学习人”）的假设[[xv]]。

持“创新人”假设的人认为，由于组织环境的变化非常迅速，管理要改变被动适应的状况，必须进行全面、彻底的变革，其中，人的不断学习和创新是最重要的内容。因此其相应的管理方式应该是“学习创新型”管理方式。

即把对“人”的管理从简单的“资源管理”转向复杂的“资本管理”，加大人力资本的投资，通过培训和教育等手段来培养弥漫于整个组织的学习气氛，提高员工的整体素质。使员工不但能勤奋工作，而且能充分发挥其潜力和创造性的思维能力，从而为企业创造更多的价值。

2.2 敏捷实践的相互关系

在上述敏捷价值观体系的基础上，许多团队对来自于多种方法论体系的多种实践通常融合使用。

以作者所在的公司为例，其敏捷方法主要基于XP，同时容纳了SCRUM的管理实践和来自于FDD的可视化管理实践。同时，理解了敏捷价值观体系的员工也在每个项目中进行不同的创新。一个不容忽视的事实，是敏捷方法的许多实践都依赖于其他实践的实施，如图2-1所示。

图 2‑1 敏捷开发实践和价值观依赖关系图

以敏捷价值观体系，特别是以注重人为基础的价值观体系中，各种价值观之间的实施存在一定的依赖关系。只有注重了人，把人放在第一位，才可以促进交流和协作，才能鼓励团队承担责任，才能发挥人的聪明才智来发现和消除浪费，从而达到对过程本身的不断完善和改进。

敏捷价值观体系之外，XP等方法中所提到的实践许多都依赖于一定的价值观的存在。例如结对编程，必须是依赖于统一的代码标准和团队的紧密交流合作，而代码标准的统一又必须依赖于集体责任制的建立。测试驱动开发实践也依赖于持续集成环境的建立、重构的技术、简单的设计、以及合适的用户故事。持续集成的建立又需要建立自动化的测试环境。重构和持续集成又依赖于简单设计原则的实施。

敏捷实施中最常出现的错误，就是单独实施某些本不能单独实施的敏捷实践。例如有的团队在没有持续集成环境和足够的自动化测试的情况下进行重构，而没有足够的保障，不可能能够成功的对大量的代码进行改变。结果可想而知。

从图2-1可以看到，为了实现频繁的发布以实现交付价值的目标，必须要建立统一的愿景，保证管理的可视性，保证客户的交流和验收，保证使用适应性计划进行变更管理，进行短迭代开发周期，采用简单设计并坚持采用重构。而这些被依赖的实践，又依赖于其他一系列的实践。因此，如果要达成快速交付频繁发布的目标，必须要完整的全套的敏捷实践和价值观。

因此，敏捷转型和实施不可以仅从实践列表中选择一些来实施，而是必须要尽可能全部使用。尽管根据实际情况，制定一步一步的可行的转变过程才能够逐步实现，但这种制定计划一步步进行的过程，必须要考虑所实施实践的互相依赖特性。

与此相反，有的软件开发团队一窝蜂的把所有的实践都列出来实践，而不顾自己团队的能力和经验程度。这种一拥而上的实施方法对于成熟的敏捷团队没有问题，但对于那些不够熟悉敏捷的团队来说，无疑是一种快速的毒药。

人们接受新技术和新事物存在一个学习曲线。如果一下子引入过多的敏捷实践，团队很可能无法很快度过适应期，项目在这个阶段中将会遇到极大的风险。如图2-2。采用新的工具或新的技术，将会有一段时间导致团队效率下降。这是使用任何新工具都会带来的问题。而敏捷转型研究的目标，就是要减少这个低谷的深度和长度。

图 2‑2 采用新工具或新方法对效率的影响曲线

作者曾经见到过一个例子，就是在团队采用结对编程的初期，由于团队成员接受这种方式需要转变的时间，导致一段时期的开发效率大幅降低，而项目经理却无法等待团队的转变，为了赶项目进度，只好取消了结对编程实践。

[[i]] Schein, Edgar H. “Organizational Culture and Leadership” [M], 3rd edition, Jossey-Bass, 2004

[[ii]] J.Campbell, V.Maxey, W.Watson, “Hawthorne Effect: Implications for Prehospital Research” [J], Annals of Emergency Medicine, 1995, vol.26, no.5, pp.590-594

[[iii]] Mayo, George E. “The Human Problems of an Industrialized Civilization” [M], reprint edition, Routledge, 1933

[[iv]] McGregor, Douglas. “The Human Side of Enterprise: 25th Anniversary Printing” [M], McGraw-Hill/Irwin, 1985

[[v]] Demarco, Tom & Lister, Timothy. “Peopleware: Productive projects and teams” [M], Dorset House Publishing Co., Inc. 1987

[[vi]] Constantine, Larry. “The peopleware papers” [M], Prentice Hall, 2001

[[vii]] McBreen, Pete. “Software Craftsmanship: The New Imperative” [M], Addison-Wesley, 2002.

[[viii]] Cockburn, Alistair. “Agile Software Development” [M], Addison-Wesley, 2002

[[ix]] Hartmann, Deborah. "Interview: Jim Johnson of the Standish Group" [EB/OL], http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS, InfoQ.com, 2006, 2009-04-20

[[x]] Mehrabian, Albert. “Nonverbal communication” [M], Aldine-Atherton, 1972.

[[xi]] Nash, John, “NON-COOPERATIVE GAMES” [C], Annals op Mathematics, Sept 1951,vol.54, no.2,

[[xii]] Denne, Mark and Cleland, Jane. “Software by Numbers: Low-Risk, High-Return Development” [M], Prentice Hall PTR, 2003

[[xiii]] 李默，“Software by Numbers读后感” [EB/OL], http://blog.nona.name/200703239.html, 2007, 2009-4-20.

[[xiv]] Hersey, P., Blanchard, K., & Johnson, D. “Management of Organizational Behavior: Leading Human Resources” [M], 9th edition. Pearson Education, 2008

[[xv]] Drucker, Peter F. “Innovation and Entrepreneurship” [M], Reissue edition , HarperCollins, 2002.

组织或团队进行敏捷实施的常见问题

2012-06-17T06:03:00.000-07:00

本论文题为《软件组织敏捷转型过程的研究与改进》，有删节。

（二）敏捷方法转型中的常见问题及原因分析

2001年以来，敏捷软件开发方法在软件行业的知名度和使用程度越来越高。据2008年VersionOne公司所进行的第三次敏捷方法年度调查显示[[i]]，其参与调查的2300多敏捷实践者分布于80个国家，其中80%有敏捷项目经验。相对于2006年来自47个国家的722个参与者有大幅的增加[[ii]]。敏捷方法在应对多变的业务需求、竞争剧烈的市场、以及越来越复杂的软件架构时所展现的高效率、低成本、快速的反应速度等优势越来越得到IT公司和团队的认可。93％的参与者认为敏捷方法使他们团队拥抱变化的能力得到了增强，74%的人认为其生产效率得到了提升。

据amsoft公司2008年所做的另一项敏捷使用情况调查显示[[iii]]，82%的参与者认为使用敏捷方法之后其生产效率得到了提高，77%认为系统质量得到提升，72%认为系统开发成本较之前降低，78%认为其客户满意度得到提升。与此同时，敏捷软件开发方法的使用比率从2006年的41%上升到2008年的69%。

中国IT业采用敏捷开发方法的情形有所不同。相比之下，中国IT公司对敏捷方法的接受度落后于国外平均水平。作者所在的公司专门从事敏捷方法实施咨询业务，据了解，在2005年及以前，在国内实施敏捷方法的开发团队屈指可数。从2005年起，逐渐有一批人意识到敏捷开发的好处并开始实践。自从2005年作者所在的公司ThoughtWorks在中国开设业务以来，明显的感觉到敏捷方法的接受程度以及传统团队对于向敏捷转型的意愿越来越强烈。到2008年，敏捷开发方法已经被很多团队所采用。从2008年起，国内一些大型IT公司陆续向开发者社区表示了对敏捷开发的兴趣或分享其经验，例如腾讯和华为分别在第三届敏捷中国大会上做主题演讲，报告其开发团队在最近一年实施敏捷的情况。

然而，由于对敏捷理解的不同，不同团队的实施结果也大相径庭[[iv]]。某些团队宣称其敏捷实施非常成功，而据笔者调查，这些团队所宣称的成功多数是因为政治原因，他们必须告诉高级管理层敏捷是成功的，否则团队的领导，即推行敏捷实践的责任人，将会因此而获得差评。另有一些团队虽然已经部分采用了敏捷实践，但实践效果比较差。这使得管理层认为敏捷方法不过如此，因而放弃了对敏捷方法的关注和支持，最终敏捷实施的尝试以失败告终，又回归到传统的方法。

根据VersionOne的第三次敏捷方法年度调查报告统计[2]，45%的参与者认为改变整个组织的文化是他们将敏捷方法进一步推广的阻碍。23%的参与调查者认为组织的价值观或文化是导致他们项目失败的原因。

随着敏捷理念的传播，一些团队开始认识到，在自己自主的学习和使用敏捷方法的实践的同时，必须开始尝试推动公司向敏捷组织进行转型，不仅要从过程上转型，更要从文化和价值观的方面转型，才能更好的保证团队级别的敏捷方法实施。

国外对于敏捷转型的研究始于2003年左右，Mike Cohn首先研究了将敏捷应用于组织的方法[[v]]，结果发表在《Computer》杂志。Michael Hirsch研究了从计划驱动的企业文化转向敏捷文化的经验[[vi]]并在国际软件工程大会上做了报告。Iva Krasteva, Sylvia Ilieva研究了敏捷实施过程中效果不佳的一些原因[[vii]]；Elke Hochmüller和Roland T. Mittermei对敏捷实施中的一些误解做了研究[[viii]]。

那么组织或团队进行敏捷实施的常见问题和原因是什么呢？

本文涉及到多个过程改进术语，在此特别定义如下，以避免混淆：

敏捷实施（Agile Adoption）：或称敏捷方法实施，指采用敏捷相关资料上所提及的实践，在开发团队内部推行敏捷方法的过程。
敏捷转型（Agile Transformation）：或称敏捷转型实施，指从组织或团队级别上进行敏捷思想和敏捷文化的改变，其涉及范围已经超出开发团队。

2.1 组织或团队进行敏捷实施的常见问题

在作者参与过的敏捷实施过程中，以下的问题和情景经常出现。这些问题是客户接受敏捷的顾虑和阻碍，有时候，这些问题甚至会直接导致敏捷实施的失败。这些问题可以归结为四方面因素：组织、文化、过程、技能。

2.1.1 组织因素：敏捷的转型无法获得高层管理的支持。

管理人员希望看到可以量化的指标，以证明敏捷方法的优势所在。而实施敏捷的团队很难给出具体的可以量化的指标。因而高层对全面采用敏捷会存在顾虑。

敏捷方法中鼓励结对编程等实践，但管理人员会质疑两个人做一个人的工作是在人力成本上的浪费。另一方面这种结对编程的方法使得管理人员无法就某一个人员的工作量进行跟踪。HR部门不支持IT部门的这种变化，认为这样无法衡量每个员工的个人绩效。

管理人员关心在敏捷团队中知识如何积累和传递。许多IT公司的人员流动率高，因此为了维护一个产品的生命，经理们往往希望开发人员多写文档和注释，把所有的信息都固化起来。然而有的项目经理听说敏捷“不写”文档，于是对敏捷方法是否能在其团队实行抱有疑虑。高层管理人员也认为软件的设计文档是公司资产，对于没有专人编写文档无法放心。

有的公司将测试人员和开发人员分为两个部门以便于管理，而敏捷鼓励测试和开发人员一起工作，高层管理人员认为这种混合在一起的工作方式会提高管理成本。因此对实施敏捷犹豫不决。

有的项目管理人员认为敏捷只适合于小型项目，而他们的项目大多是大型项目。因此在未能证实敏捷支持大型项目之前，拒绝尝试敏捷方法转型成为第一个吃螃蟹的人。

2.1.2 技能因素：敏捷实践的技能或经验不足。

有的团队自己开始实施敏捷，在没有任何人懂得的情况下开始尝试测试驱动开发或重构，最终由于种种原因不能坚持下去，于是认为敏捷不适合自己的团队。

有的团队没有专门的人做需求分析，项目经理同时负责需求管理，需求的格式采用纯文本的叙述。需求方法不适宜导致开发的时候觉得实施起来束手束脚，于是被迫放弃敏捷方法。

当出现需求变化导致需要代码重构时，开发团队专门拿出时间进行重构，但重构结果不理想，以至于开发团队开始惧怕重构和拒绝变化。最终导致代码积重难返而使得敏捷实施效果差。

有的项目管理人员希望给团队每个人分配任务。但发现敏捷方法鼓励员工自己选择任务，他们担心员工倾向于偷懒而选择简单的任务，最终导致复杂的任务没人认领。于是认定敏捷在此方面不能帮助他们。

有的团队认为2周的迭代太快太难以管理，于是决定用2个月或3个月进行迭代。等到发现这样的开发结果不理想时，又认为是迭代开发的问题。

有的团队对于需求量的估算精确到小时或代码行，仍然常常会出现估算不准确的问题。对于敏捷方法鼓励用一种更不精确的方式来进行估算表示重重疑虑。

2.1.3 文化因素：团队固有文化和敏捷所需要的交流反馈存在冲突

有的团队成员不愿意和别人交流，一直习惯于独立工作。于是项目经理认为敏捷的结对编程等实践无法执行。在迭代交流会议上由于大家不踊跃发言，最终演变成了向项目经理汇报的报告会。

某些团队成员不愿意进行变化，从内心抵触任何的改变，故意针对项目经理的敏捷实践意图进行抵制，以至于项目敏捷化阻力重重。

有些团队不能坚持做回顾总结，每次的回顾总结都成为批斗大会。大家纷纷指责某些人的错误，导致团队中矛盾重重。最终总结回顾会议暂停实施。

有的团队成员认为某些工作不在他的工作范围，于是也不理睬，也不碰别人的代码，专心的在自己的代码范围内耕耘。使得别人不懂得他写的代码，他也不懂得别人写的部分。

有的公司鼓励加班，认为加班的员工才是为公司奉献的好员工。于是团队成员纷纷效仿，哪怕没有事情也要在公司待到九点才会回家。有的公司为了赶工期，更是长期的加班加点。

2.1.4 过程因素：外部原因使得团队无法正常实施敏捷

有的开发团队无法得到客户及时反馈。有的根本见不到客户的人影。他们只好蒙着头继续开发，直到交付的那一刻客户才说开发的不符合要求。

有个开发团队和测试团队分开在两地，或其他的团队无法直接配合。他们的工作被空间分割为多个阶段。因此下个阶段要等待很久才能得到上一个阶段的产物。等出现问题反馈回去的时候，又是几个月过去了。另外分开的团队导致两边交流存在障碍，以至于团队倾向于用邮件交流，导致降低效率。

有的公司进行产品开发，需求到达开发团队的时候已经按照一定格式写好了。编写需求的产品经理忙着做其他的工作，开发团队按照这样的需求盲目的开发下去。

有的公司的技术架构需要和其他系统集成，而其他系统由不同的团队或公司开发，想要找到技术支持需要很久的等候。于是一个需求就被拖延了多个迭代导致开发效率大大降低。

2.1.5 敏捷实施中问题的原因分析

上述的这些问题都是发生于真实项目中的问题，这些问题的出现阻碍了开发团队和组织进行敏捷实施或转型的努力。为什么客户会有如此多的问题呢？原因可以归纳为两种。

一、忽视了敏捷实践之间的关系。敏捷实践不是孤立而成的，它们之间存在非常强的依赖关系。例如没有持续集成，测试驱动开发和重构根本无从谈起。很多组织以为可以简单的采用一种或几种实践，就可以开始敏捷，或者认为只要管理实践敏捷化，具体技术实践可以不敏捷。这样的误解导致了敏捷实践从一开始就阻力重重。

二、忽视了向敏捷价值观的转变。敏捷开发不仅仅是一系列实践，它同时还是一套价值观体系。而实施敏捷的团队和组织，往往忽视了敏捷实践背后的价值观，一味的按照教课书上的实践来应用，不考虑人的思想转变过程，导致的结果往往是从文化和根本上的不适应。

REFERENCE

[[i]] VersionOne, “3rd Annual Survey: 2008, The State of Agile Development Full Data Report” [EB/OL] , http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf, June-July, 2008, 2009-04-20

[[ii]] Sims, Chris, “State of Agile Survey Shows Wider Agile Adoption” [EB/OL], InfoQ, http://www.infoq.com/news/2008/09/state-of-agile-results, 2008, 2009-04-20

[[iii]] Agile Adoption Rate Survey: February 2008 [EB/OL], Ambsoft, 2008

[[iv]] 李剑，Scrum在中国——企业实施情况调查实录，[EB/OL]，http://www.infoq.com/cn/articles/scrum_china_2008_investigate，InfoQ，2008, 2009-04-20

[[v]] Cohn, Mike and Ford, Doris. “Introducing an Agile Process to an Organization” [J], Computer, June 2003, vol.36, no.6, pp.74-78

[[vi]] Hirsch, Michael. “Moving from a plan driven culture to agile development” [J], ICSE '05, May, 2005, pp.38-38

[[vii]] Krasteva, Iva and Ilieva, Sylvia. “Adopting an agile methodology: why it did not work” [J], APOS '08, ISBN:978-1-60558-021-0, Leipzig, Germany, 2008, pp.33-36

[[viii]] Hochmüller, Elke and Mittermei, Roland T. “Agile rrocess myths” [J], APOS, 2008, pp.5-8

敏捷软件开发方法的历史和现状

2012-06-17T04:42:00.000-07:00

序：我在准备一个敏捷初级知识的ppt的时候，忽然觉得我写的东西很眼熟，再一想，这不就是我论文么。忽然想起这论文写了有3年了都忘记发在博客上。干脆拆散了发出来好了。

本论文题为《软件组织敏捷转型过程的研究与改进》，有删节。

（一）敏捷软件开发方法的历史和现状

敏捷方法作为软件工程的一种，其起源和发展都和软件行业和软件技术本身的发展息息相关。软件工程的诞生是为了解决当时软件开发的问题。几十年过去了，许多问题却依然存在。

1.1.1 软件工程的诞生

计算机软件诞生于20世纪50年代。早期的编程工作量大，但逻辑并不复杂，因为计算机的应用还仅限于一些数学计算等领域。一个好的程序员就能设计和编写整个程序。

从60年代中期到70年代中期是计算机系统发展的第二个时期，在这一时期软件开始作为一种产品被广泛使用，第三代计算机出现，过程化程序设计，多用户系统，人机交互，数据库，使得软件从分钟级变成了毫秒。从那时起，计算机的软件开始陡然复杂起来。当程序变得越来越大时，就需要越来越多的程序员一起来开发程序。这种更大一些的程序的交付变得非常的难以预料。

这时期软件开发的方法基本上仍然沿用早期的个体化软件开发方式，但软件的数量急剧膨胀，软件需求日趋复杂，维护的难度越来越大，开发成本急剧增高，而失败的软件开发项目却屡见不鲜。

OS 360操作系统被认为是一个典型的案例[[i]]。到现在为止，它仍然被使用在IBM360系列主机中。这个经历了数十年，极度复杂的软件项目甚至产生了一套不包括在原始设计方案之中的工作系统。OS 360是第一个超大型的软件项目，它使用了1000人左右的程序员。 Fred Brooks在随后他的著作《人月神话》（The Mythical Man-Month）中曾经承认，在他管理这个项目的时候，他犯了一个价值数百万美元的错误。很多的软件项目开发时间大大超出了规划的时间表，一些项目导致了财产的流失，甚至某些软件导致了人员伤亡[[ii]]。同时软件开发人员也发现软件开发的难度越来越大。

这种情况使得人们开始对软件及其特性进行更深一步的研究。1968年北大西洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了“软件危机”(Software Crisis)这个名词。软件危机包含如下的含义：

· 项目超出预算

· 项目延期交付

· 软件效率低

· 软件质量差

· 软件常常无法满足业务需求

· 项目难以维护，代码难以修改

· 软件无法交付

人们意识到，或许一种更加正式化的流程能够改变软件开发的现状。于是北大西洋公约组织的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（Software Engineering）这个概念。

软件工程是一门研究如何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和维护的学科。软件工程包括两方面内容：软件开发技术和软件项目管理。软件开发技术包括软件开发方法学、软件工具和软件工程环境。软件项目管理包括软件度量、项目估算、进度控制、人员组织、配置管理、项目计划等。

“软件工程”这个词的提出，使得用工程化方法研究软件开发的思路在软件研究中广泛传播，因而产生了一系列的软件过程方法。

1.1.2 软件过程方法的演变

软件工程发展的一个方面，是依靠对于过程的精确掌控和管理，来达到提高软件开发效率和交付质量的要求。

“像架桥一样架设软件”。具有机械和土木工程背景的开发执行人提出了解决方案。他们建议使用工程学的原则来构建软件，并因此催生了软件工程的“瀑布式”方法。

图表 1‑1瀑布模型示意图

瀑布式开发方法，也称线性顺序模型，源自Winston W. Royce在1970年最初提出的软体开发模型，是严格按照软件开发的步骤进行实施的软件开发方法。瀑布式方法将开发过程分为需求分析和定义、系统设计、开发和单元测试、系统集成测试、运行维护等多个阶段，整个过程都以线性方式进行。

然而，瀑布式开发流程依赖于一个重要的假设，就是所有的需求在开发之前就已经被明确定义。也就是说，从一开始的程序确认之后，就一次完成每一步骤的开发作业，一切都是不可修改的。然而这种假设在商业环境中几乎是不存在的。这导致了许多采用瀑布方法开发出来的软件完全无法适应用户的需求，项目的失败率高居不下。

原型法相对于瀑布式方法具备了对变化需求的响应功能。原型法是在20世纪80年代中期为了快速开发系统而推出的一种开发模式，旨在改进瀑布方法的不足。

这种方法首先建立一个能反映用户需求的原型系统，让用户在计算机上运行，试用这个原型系统，通过实践，了解未来系统的全貌。用户通过实际使用原型系统，提出修改意见。根据这些意见快速修改原型系统，经过对原型系统的反复改进，最终建立完全符合用户需要的系统。原型模型可以在运行中被检查、测试、修改，直到它的性能达到用户需求为止，因而这个工作模型很快就能转换成目标系统。原型法的意义是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。

然而，原型方法的问题在于当时软件开发技术的不成熟。许多团队为了建立原型，采用了一些快速易于实现的技术，等用户确认完毕要进行真正的系统建设的时候，团队将面临一个两难的选择：继续在该原型上开发，使用不成熟的技术，还是采用成熟技术重新开发一个新的系统？两者的风险都极高，况且重新开发时很多团队又采用了瀑布式过程。

增量模型和螺旋模型方法融合了线性顺序模型的基本成分和原型的迭代特征，由Barry Boehm在1988年提出[[iii]]。在理想增量螺旋模型中，开发周期一直很短。开发团队有机会停下来，调整项目代码，然后继续开发下去。螺旋模型被认为是后期所有基于迭代模型的鼻祖。

图 1‑2 螺旋模型示意图

不幸的是，由于当时的软件技术正处于面向对象技术的初期阶段，开发团队该技术的掌握不熟练导致采用螺旋模型时交付问题并没有消失。模型的第一周期的会进行得不错。当下一部分需求被考虑的时候，开发小组发现自己已经身陷困境。第二阶段新的需求并不适合第一阶段对系统的设计，尤其是尚未成熟的面向对象设计。虽然很不情愿，大多数螺旋模型的倡导者和支持者还是被迫回到了瀑布式过程。

几乎与此同时，在20世纪80年代中后期，美国卡内基梅隆大学(Carnegie-Mellon University)的软件工程学院(Software Engineering Institute)通过对几个采用瀑布式方法的美国空军项目的研究，对软件开发过程模型本身进行提出了软件成熟度模型(CMM)，其结果发布在1989出版的《管理软件过程》[[iv]]一书。

值得注意的是，CMM并不是一种实际的软件工程方法，而是一个描述软件工程方法的元模型，其目的是为了进行过程的改进。

1.1.3 需求分析和设计方法以及重量级方法的产生

软件工程发展的另一个方面，是侧重于对软件开发过程中分析、设计的方法的研究。这方面的重要成果就是在70年代出现的面向过程的开发方法，以及结构化的分析、设计和相应的测试方法。这些方法被用于瀑布模型中，取得了一定的效果。

这方面的成果，使人们认识到了文档的标准以及开发者之间、开发者与用户之间的交流方式的重要性。一些重要文档格式的标准被确定下来，包括变量、符号的命名规则以及原代码的规范式。

20世纪80年代末期开始，面向对象的分析、设计方法（OOA和OOD）的出现使传统的开发方法发生了翻天覆地的变化。随之而来的是面向对象建模语言（以UML为代表）、软件复用、基于组件的软件开发等新的方法和领域。

软件项目居高不下的失败率孕育出了新的产业。他们致力于对瀑布流程提供严格的控制，CASE（计算机辅助软件工程，Computer-Aided Software Engineering)工具应运而生。这些工具基于以下前提：更加严格的获得流程中每一个阶段的信息；通过审查这些时期产生的文档来保证准确度；只有当缺陷被解决时才继续进行开发。CASE工具很昂贵，很多开价高达每个程序员数千美元。其中流传最广的是产生于20世纪90年代中期的Rational工具及其所支持的RUP方法。

Rational统一过程（RUP）参考了瀑布模型、螺旋模型的特点，是由IBM Rational公司开发并投向市场的一种过程产品，该工具为项目的执行提供了必需的细节：包括指南、模板以及辅助工具。

图 1‑3 RUP中的软件生命周期[[v]]

RUP将整个开发生命周期分为4个阶段：初始阶段、精化阶段、构建阶段、产品化阶段。RUP的每个阶段又可分为一到多个迭代周期。采用迭代式开发，目的是尽早降低风险[[vi]]。

然而，许多使用RUP方法的人发现，很多“软件危机”中所提到的问题并没有被减轻。RUP中规定了许多需要开发团队制作的“工件”,这些工件常常以文档出现，例如需求规格说明书等等。有的开发团队为了节省时间而忽略了这些“工件”，这成了被人诟病之处，认为团队忽视了工件才导致了软件交付失败。

在20世纪90年代，另一些人提出了对软件过程进行标准化的方法。1995年发布的ISO/IEC 12207[[vii]]标准，对软件开发生命周期做了详细的规定，包括投标、签署合同到开发过程中的文档以及后期的维护支持。然而该标准是按照瀑布模型定制的标准，并且在定制的过程中忽视了软件需求的多样性。

由于开发过程标准的出现，许多美国的政府机构开始认为，只有符合标准的软件公司才是最佳的选择，因此导致了本来被定义为迭代过程的RUP过程被迫简化为标准中的线性过程[[viii]]，而关注于过程改进的CMM被认为是要检查开发过程中的工件即文档[[ix]]。在90年代后期，上述的RUP方法，CMM模型和ISO标准开始常常被人一起提及。这三种不同的东西被绑定在一起的后果，就是被称为“重量级方法”(Heavyweight Method)。

它们过多的关注了过程本身，它们认为保证过程正确执行的方式是通过文档记录，这使得文档工作占用了相当大的时间。而为了弥补时间的损失，软件公司只好依靠增加专门的文档编写人员来提高生产效率，用成本换效率的结果，就是软件开发依然无法跳出超预算、超期的怪圈。

1.1.4 轻量级方法－－敏捷方法的前身

20世纪90年代，除了软件技术中面向对象开发方法的兴起之外，软件领域另一项令人激动的技术是互联网技术的兴起。尤其是90年代末期，随着互联网的发展，越来越多的传统企业开始意识到，他们获得了另一个商机。这时候，软件快速的交付投入使用成为决定一个企业生死存亡的必要条件。而重型软件开发过程的繁重与拖沓，使得许多开发团队决定放弃标准，尝试新的软件开发过程和方法。这些注重快速交付，减少文档的方法被人称为轻量级方法。

轻量级方法一般意义上包括： XP（极限编程），SCRUM，Crystal Clear(水晶方法族)，Context Driven Testing，Lean Software Development（精益软件开发），DSDM以及Adaptive Software Development等。这些方法分别由不同的人基于软件开发不同的角度提出。以下将对其中几个影响比较大的方法做简单介绍。

1.1.4.1 eXtreme Programming(极限编程）

XP根源于Smalltalk圈子，特别是Kent Beck和Ward Cunningham在20世纪80年代末的密切合作。90年代初，他们在一系列项目上的实践深化扩展了他们关于软件开发应是适应性的、应以人为中心思想。

Kent Beck在其后的项目咨询实践中继续发展了他的思想，特别是在1996年春Chrysler C3 项目。该项目后来成了广为人知的XP的创生项目。他在 1997年左右开始使用“extreme programming”这个名称。Kent Beck和一些初始的实践者在世纪之交出版了多本书，对XP方法的种种方面加以了详细阐述。

XP始于五条基本价值观（values）：交流，反馈，简洁，勇气和尊重（Communication, Feedback, Simplicity, Courage, and Respect）。在此基础上细化出了十四条原则（principles）和二十四条实践方法（practices）。其基本思想是：实践是项目组的日常的具体活动，而价值观是根本性的知识和理念，其构成了该方法基石。没有实践法的价值观是难于应用的，或失之于过于宽泛而不知从何着手。没有价值观的实践法则是一堆杂乱无章的活动。价值观和实践法都是需要的，但中间还有一个空档－－而原则正是用来连接价值观和实践的。许多XP的实践法都是以前就存在的并经过实践检验的，而常常被许多过程，包括那些计划型过程，给忽略了。XP重新建立了这些准则，并把它们编织成了一个和谐的整体，使得每一项准则都能在其他准则里得以强化[[x]]。

XP最具独创性的是它对测试的极端重视。虽然所有的过程都提到测试，但一般都不强调。XP将测试作为开发的基础，要求每个程序员写一段源码时都得写相应的测试码。这些测试片段不断地积累并被整合到系统中。这样的过程会产生一个高度可靠的建造平台，为进一步开发提供了良好的基础。这种方法常被描述成Test Driven Development(TDD)（测试驱动开发），它对许多不是完全采用XP的方法都有很大的影响。

XP及其注重软件开发实践的风格使得XP在后来的敏捷方法家族处于基石的地位。其他的轻量级方法对于开发实践的重视均不如XP。

1.1.4.2 SCRUM方法

SCRUM是在20世纪80和90年代从面向对象圈子里发展出来的一种高度迭代性的方法。 SCRUM的主要开发者有Ken Schwaber, Jeff Sutherland和Mike Beedle。

SCRUM的着重点是在软件开发的管理方面。它把一个项目分成若干个为期三十天的迭代阶段，每一阶段称之为一个Sprint。每天有一个短会，称之为一个Scrum。这样管理者能对项目有近距离的观察与控制。SCRUM对工程实践方面强调比较少。

1.1.4.3 水晶（Crystal）方法族

Alistair Cockburn提出了一系列的水晶（Crystal）开发方法，它们可以在不同的项目中加以裁剪。Alistair相信不同类型的项目需要不同的方法，这与两个因素有关：项目参与人数和出错的严重性。

所有水晶方法都有三个需考虑的优先因素（priorities）：项目的结果（safety），效率（efficiency），和习惯性（habitability）（即开发人员多大程度上愿意使用水晶方法）。其他的特征有：频繁发布，反思改进，紧密交流等。

习惯性（habitability）这个优先因素是水晶方法心理基础中的一个重要组成部分。Alistair希望使用最少的纪律性而依然能使项目成功，其基本假设是人的无纪律性是不可避免的。因此，Alistair 把水晶方法视为较XP的纪律性要低的方法，是用较低的效率以期获得更大的习惯性而减少项目失败的可能。

1.1.5 敏捷方法的提出和发展

20世纪最后的几年，许多不同的社群都在发展着持相似的软件开发理念[1]。大部分的工作都是出自那些在面向对象软件开发圈内拥护迭代开发的人士。那时这些方法还没有一个共同的名称，以“轻量级”（lightweight）来称呼这些方法的人越来越多。

2001年，一些轻量级方法的代表人物们在一次聚会中达成共识，他们发表了一份敏捷软件开发宣言（Manifesto for Agile Software Development）。 “敏捷”（agile）一词被提出，作为所有轻量级方法的统称。

敏捷软件开发宣言中这样写到：“我们通过亲身实践和帮助其他人实践，揭示更好的软件开发方法，通过这项工作，我们认为：人和交流胜过过程和工具；可工作的软件胜过面面俱到的文档；客户协作胜过合同谈判；响应变化胜过遵循计划。虽然右项也有价值，但是我们认为左项更重要。”[[xi]]

敏捷方法提出之后，随即得到了广泛的宣传。一批以敏捷开发为名的著作得以出版，许多软件方法研究机构也开始转而研究敏捷方法。从2001年开始，不停的有新的基于敏捷的开发方法和实践被提出。敏捷开发的概念被扩展到了建模[[xii]]、测试[[xiii]]、数据库方法[[xiv]]、需求分析[[xv]]、项目管理[[xvi]]等软件开发的各个方面。

Mary Poppendieck和Tom Poppendieck将敏捷方法和他们曾经经历过的精益生产做了对比[[xvii]]，发现二者之间的共通之处。因此也为敏捷方法找到了管理模型。

采用敏捷方法的团队在客户满意度、软件交付期、代码质量、软件成本、团队个人能力等方面都得到了很大的改善[3]。成功的案例越来越多。敏捷方法的成功开始吸引越来越多的公司和组织来向敏捷转型。大型的软件公司如微软，IBM，Google也曾在公开场合发表过对于敏捷实践的经验。

2006年之后，由于大量公司开始从SCRUM方法进行尝试敏捷，SCRUM隐然成为敏捷方法的领头羊。近期的技术社区讨论最多的话题是，一些许多公司忽视了敏捷的技术实践（XP等），仅采用SCRUM的管理实践，使得开发得不到有效的保障，导致了项目的失败或延期，最终将原因归罪于敏捷。

另外有的公司按照各种书籍和文档上关于敏捷的描述来进行实践，由于没有足够的经验，其效果并不理想。更有部分产品公司，为了销售自己的产品，硬是把产品贴上了敏捷的标签，以此来获取开发团队的注意。这些都是在敏捷实施和向敏捷组织转型中常常出现的情况。

近两年来，一些大型的软件公司开始进行敏捷的尝试。IBM、微软、华为等开发团队超过万人的大型公司都或多或少的考虑实施敏捷转型。然而，大型公司本身庞大的组织结构导致了敏捷方法在推广的过程中障碍重重。起源于小团队的敏捷方法实践者尚未积累出足够的经验来进行大型公司的转型。关于敏捷转型和敏捷实施的话题这两年开始在敏捷大会（Agile Conference）上特别得到重视。

国外对于敏捷转型的研究始于2003年左右，如前文所述，Mike Cohn首先研究了将敏捷应用于组织的方法。Michael Hirsch研究了从计划驱动的企业文化转向敏捷文化的经验。Iva Krasteva, Sylvia Ilieva研究了敏捷实施过程中效果不佳的一些原因；Elke Hochmüller和Roland T. Mittermei对敏捷实施中的一些误解做了研究。

1.1.6 敏捷方法在中国

在中国，由于政府强制规定只有通过CMM3级认证的软件企业才有资质能够承接政府项目，导致了向印度IT业学习、通过CMM认证的潮流在世纪之交兴起。中国的软件行业发展时间过短，他们只看到了国外的推荐标准和印度的成功，而没能经过类似“软件危机”的痛苦和洗礼，在实行了几年CMM改进或ISO标准之后，国内的IT企业终于认识到了沉重过程所带来的高昂成本和代价。

2002年开始，一些极限编程的书籍被翻译成中文版，然而却并没有引起软件公司的注意。2003年初，一些技术杂志发表了对敏捷方法的介绍开始引起人们的注意，大量的敏捷著作随后被一一翻译。2004到2005年，受Kent Beck, Martin Fowler等人的影响，Java技术社区最早开始讨论敏捷，中国第一批实践敏捷的团队在无人带领中开始自己的摸索。

2006年开始，敏捷中国大会以一年一次的频率召开，成为中国敏捷方法的旗帜。到了2008年，以华为、腾讯、阿里巴巴为代表的中国本土软件企业开始了敏捷的尝试，标志着敏捷方法在中国已经开始步入主流行列。然而敏捷转型过程本身的复杂性和艰巨性，使得各大公司都仅仅止步于小团队的试点，真正敢于进行全面敏捷的组织屈指可数。

1.1.7 精益思想与持续交付

2009-2012年，这几年间精益思想被不断的深化，将持续改善自动化的思想做到极致，就是持续交付。持续交付是许多企业进行敏捷实践所追求的机制。这段是2012年在写了论文3年之后应该补充的部分。但是目前先不写啦。以后再单独写。

[[i]] Brooks, Frederick. The Mythical Man-Month [M], Addison-Wesley, 1995.

[[ii]] Leveson, Nancy, University of Washington. Turner, Clark S., University of California, Irvine. “An Investigation of the Therac-25 Accidents” [J], IEEE Computer, July 1993, vol.26,no.7, pp. 18-41.

[[iii]] Boehm, Barry, “A Spiral Model for Software Development and Enhancemant” [J], Computer, May 1988, vol.21, no.5, pp. 61-72

[[iv]] Humphrey, WS, “Managing the Software Process” [M], Addison-Wesley, 1989

[[v]] Sinan Si Alhir, sunyanjia译，领会统一过程，[EB/OL]，http://www.uml.org.cn/softwareprocess/200510311.htm，2006, 2009-04-20

[[vi]] P Kruchten, The rational unified process: an introduction [M], Addison-Wesley, 2000

[[vii]] ISO 12207, Information technology-Software life cycle processes [S], 1995/ISO, IEC

[[viii]] Kruchten, Philippe, “How the Rational Unified Process Supports ISO 12207” [EB/OL], http://www.yoopeedoo.org/upedu/references/papers/iso12207.htm，Rational Canada, 2002, 2009-04-20

[[ix]] Machado, C.F.; De Oliveira, L.C.; Fernandes, R.A., “Experience report-restructure of processes based on ISO/IEC 12207and SW-CMM in CELEPAR”， [J], Software Engineering Standards, 1999. Proceedings. Fourth IEEE International Symposium and Forum, 1999, pp.82 – 87.

[[x]] Beck, Kent. “Extreme programming explained: embrace change” [M], Addison-Wesley,2004

[[xi]] Agile Alliance. “Manifesto for Agile Software Development”. [EB/OL],

http://www.agilealliance.org, October 2001, 2009-04-20

[[xii]] Ambler, Scott. "Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process" [M], Wiley, 2002

[[xiii]] Crispin, Lisa & Gregory, Janet, “Agile Testing: A Practical Guide for Testers and Agile Teams” [M], Addison-Wesley, 2009

[[xiv]] Ambler, Scott W. and Sadalage, Pramodkumar J."Refactoring Databases: Evolutionary Database Design" [M], Addison-Wesley, 2006

[[xv]] Cohn, Mike. "User Stories Applied: For Agile Software Development" [M], Addison-Wesley, 2004

[[xvi]] Highsmith, Jim. "Agile Project Management: Creating Innovative Products" [M], Addison-Wesley, 2004

[[xvii]] Poppendieck, Mary & Poppendieck, Tom. "Lean Software Development: An Agile Toolkit" [M], Addison-Wesley, 2003

the FANCY Approach for User Story Analysis

2012-04-06T10:49:00.000-07:00

Analysis - the missing step

From agile textbooks, we have learned to use the "User Story" for capturing and managing requirements. We know stories have 3Cs, ie. Card, Conversation, and Confirmations, we know a story should follow INVEST principles, and we know an AC should be SMART. However, the one thing I found missing in most of the books is the HOW TO: from the Conversation to the Confirmation ie. how to elaborate on the details for the stories.

In User Stories Applied, Cohn said that the detail was done by "Conversation". In that, the analyst flushes out the details behind the stories by conversing with customers, and makes notes on the back of the story card. He said, "Ideally, the conversation can be resumed easily whether or not the same developer was involved in both halves of the discussion..." and "...details that have already been determined through conversations become tests."

In Agile Software Requirements, Leffingwell mentioned "details (come from) discussion between PO and team" and "if more details are needed about the story, they can be provided in the form of an attachment (mock-up, spreadsheet, algorithm, or whatever), which is attached to the user story..." and "...In that case, the user story serves as the token that also carries the more specific behavior to the team."

These are all good ideal cases, but they won't work automatically in practice without certain capability. The on-site customer, the PO or the anlyst need a clear way to analyze the stories and to capture the details.

I often see new analysts confused on using the User Story approach. They have read the book and understood the method but they either can't write good user stories or skip stories, e.g. a bad smell of this would be "oh I've never thought about it".

The lacking capability here is the "analytical capability". A friend once commented to a business analyst that "he doesn't know the business nor the analysis". Many people don't know how to perform proper analysis. They need the "Analysis 101" class.

The Analysis 101 - the FANCY approach

Here is my secret approach to performing "analysis", the FANCY way.

Functional requirements

Assumptions

Non-functional requirements

Constraints

Y-wireframes

Analysis is to break down the story into details, or sub-stories. To analyze a story, you, as an analyst, have to follow a structured thinking process in order to come up with all the details and to make sure that you won't miss any aspects of the story, so you can produce consistent high quality deliverables.

Functional requirements

The first and most common aspect is the functional part. "Functional" refers to the business logic or flows. The analyst has to break down a story into smaller pieces of details. The pieces could be acceptance criteria or separate stories. To come up with comprehensive and exhaustive details, you'll need to follow 5W1H to drill down.

At this stage, you should have already known about who and why this story is for:

who - the user roles or persona

why - business value and user goals

You should also consider the following aspects:

when - the precondition or prerequisites steps

where - the entrance on the UI

what - the input data

what - the business rules or logic in this function

what - the output

how - the happy path

how - the sad paths and edge cases

how - the impact to other functions

Assumptions

It is important to capture the basic hypothesis that the story is based and developed on. These assumptions are usually made at the beginning of the project or in the early stage of requirement analysis. Sometimes assumptions are made when the team is estimating the stories. At the stage when they aren't able to get the answer for a question to complete the estimation, they have to make an assumption to move on.

For example, a story may assume that the database tables are already built, or that an API exists at the time of development. Note:

If an assumption is made, the assumption needs to be continuously monitored and verified. A spike task may be scheduled to verify the assumption.

If the assumption breaks, the story will need to be re-estimated, and the plan will need to be changed accordingly.

The common areas for assumptions are:

The fundamental technical architecture or framework

The availability of external API or applications

The uncertain parts of the input or the output

Non-functional requirements

Non-functional requirements are usually cross-cutting concerns for all of the stories. Your can refer to a list of non-functional requirements on Wikipedia.. Typically, you should consider the following aspects:

Performance and Scalability - Responsive time? Concurrent Users? Cloud? Sharding?

Maintainability and Extensibility - refactoring needed? Impact to legacy systems?

Compliance - Company standards? Industry Standards? Privacy? SOX?

Supportability - logging? google analytics? Ops need? Admin UIs?

Documents - User manual? Release notes? Marketing messages?

Security - User permissions? SSH Keys? SQL Injections?

Localization - i18n? editorial review texts?

DevOps - Deployment scripts? Database migration? Configuration difference between servers? Automated functional tests organization?

You can develop a comprehensive non-functional requirement list as a checklist. Some of these can be split into new stories and some of them can't. But to have them in mind in the beginning is much better than to realize the need of them at the later iterations.

Constraints

Constraint is the limitation of a story. It is what the story won't do or can't do. E.g. you may agree on not to do some function in this story and to develop them as separeate stories, or this story won't fix an existing production issue in the same area. This give QAs and other audiences a guidance on what's in scope and what's not in each specific story.

Typically the constraints need to cover the following areas:

Internal constraints - functions that the story should cover but due to other reasons it will never be implemented. Users will have to operate with this limitation.

External constraints - functions that the story should cover but split to other stories. Users could have a workaround until the delivery of the later stories.

Wireframes

Although it calls wireframe, I would use it to indicates the UI/Usability aspect of the story.

This broader concept covers the following aspects:

User interaction flow - how the system interacts with user

User Experience Design - whether the layout, the business flow, the information architecture, the navigation etc make sense

Mobility - should this web app also support iPhone, Android, iPad etc?

Accessibility - to what degree does the story need to support accessibility?

Browser capability - does it really need to support IE? are you sure? why?!!

UI design - the actual color scheme and visual designs

A typical form of the wireframe could be a paper prototype or a lo-fi prototype in ppt or other tools. It helps to visualize the function for audiences to reach a shared understanding. To better illustrate the user interaction flow and to verify the usability by final users, a wireframe is necessary to add to the stories.

The actual visual design aspect is usually not part of the story details. However, an iterative design approach is also necessary in order to incorporate the UI design into each iterations.

Summary

The purpose of FANCY is to help you as BAs to better understand and thoroughly analyze the requirements. When there is need to elaborate the details of a story, you can follow these 5 methods to break down the epics and to organize your communication. Some of them would finally appear in story descriptions e.g. on Mingle or other form of story formats. But please, be cautious that these are neither supposed to generate documents nor to replace the conversation. Great communication between different roles is one of the key elements for a successful agile team.

These 5 aspects proposed make up the FANCY approach which I want to share with the agile business analysts or POs. It has worked well for me in my organization, I have used them in my mentoring new BAs and if proves to be useful for them to better understand analysis.

In fact, many years ago, some people also created another framework called "FURPS", which is essentially trying to achieve the same goals as I do now, but its acronym doesn't lend itself to well in my memory of the attributes it represents.

Have fun in the business analysis world.

Online Whiteboard Tool

2012-03-10T17:31:00.000-08:00

Recently I've found a very useful tool awwapp.com, a great whiteboard collaboration tool that uses works on all browsers including iPad.

The cool part of it is it can be used on iPad smoothly, just like an native drawing app. This makes it a very different tool than all other online whiteboard tools -- it has the input device than all other tools. With a stylus I can draw basic arrows, shapes and texts that I normally draw on the real whiteboard in meetings.

It is definitely a killer app for most of the drawing/paper apps on the ipad and those online whiteboard tools using flash. Where I would use it immediately would be for our current distributed project. We have team members in China and the US, this tool would be very helpful for technical knowledge sharing, e.g. drawing a class diagram etc.

I really wish to see this kind of tool to envolve to the following direction:

Be able to record the presentation and replay, it will turn to be an great online knowledge creation tool, so I can reduce the number of ppt slides

Be able to store each screen, when I click clear, to some where automatically, e.g. flickr or picasa, so I can save them for future use, that's to replace the current "Take a picture" step after the use of the real whiteboard

Be able to convert the series presentations in to ppts, so I don't need to rely much on the powerpoint to creat slide

Be able to record voices, and combine the presentation, into a video, so I can share it to more audience.

The trend of utilizing the tablet or smartphone as the input device for online apps, becomes more and more popular for startups. I can think about some usage scenarios, in fact, in one conferecne I saw people embed surveys in the ppt slide. The speaker paused at some time during the presentation and ask people to vote to test if they follow the topic, amazing idea.

Anyway, as it is just an startup now, I hope it can survive, last long time, and be funded by some VC, and finally gets bigger.

Millet congee soup

2012-01-14T13:29:00.000-08:00

My family's traditional soup. It is good for your stomach.

Recipe: 1/2 cup millet, 5.5 cup water (1:11), boil using high heat and turn to low heat for a total 30 - 40 minutes.

关于思考能力与解决问题的能力

2012-01-12T16:10:00.000-08:00

2010年写的，在草稿箱待了很久

工作了好多年了，一个非常非常深刻的体会就是我在最近几年中才学会怎样思考，具备了思考能力，换一个词说，就是Critical Thinking。中国缺乏Critical thinking的教育。

中国的学生从小接受的教育就是解题。而并没有被告知为什么解题，解题的过程是什么，思考的过程是什么。对于一道题，从一开始只掌握一种方法来解，到后来学奥数之类的学到更多的方法，到做题库学会很多的方法。这样的一种填鸭式教学效果可想而知。除非学生能够忽然开窍，明白这些解题之后的逻辑推理过程，才能够真正的理解。估计大多数的学生都只能依靠记忆，记下解题方法来通过考试。这种问题一方面是教育制度使然，一方面也归咎于教师的教育不得法。

而国外的教育更重视过程的思考以及解决问题能力的教导。有人经常引用说美国的小学生数学成绩不如中国学生，这正因为他们培养的是思考和研究的方法。等这些方法在高中阶段变得纯熟，美国高中生在数学研究能力上超过中国学生是再正常不过了。(当然，这段是我根据阅读一些别人的见闻猜测。)

我对于思考和逻辑的启蒙始于我读到一本叫做“系统思考”的书。在这之前，无论是写文章还是论文，天生的逻辑感使得我写的都还通顺，起码在逻辑性上读的通。然而许多人，在没有这方面的启蒙的情况下，他的无论谈吐、写作、思考还是工作的能力，都会非常低。大学生中能够有这方面意识的人更是寥寥。

后来我读了更多的书籍和资料之后更加认识到了逻辑的重要作用。在商业环境中，各种决策错综复杂，一个商业领袖在具有领导能力外，必须具有逻辑的洞察力。我所见过的一些非常优秀的企业管理人员都能够很敏锐的指出问题，并通过逻辑的思考和判断来提出解决方案。而优秀的管理人员多数有高水平教育的背景。尤其是在国外学校教育的背景。这可能从另一方面证明了，外国教育重视能力培养所带来的效果。

事实上，中国教育的这种轻逻辑的传统自古即有。一个很典型的例子是从中国的历史研究来看，中国的史书都是记事，描写当时的情景，有时会加上一些自己的臆测。而外国人写的史书，满篇都是证据和推理。而中国直到清朝才建立了义理、考据、辞章的说法，逻辑思考从来都不是中国人历来所教授的。

许多现在的生活问题也都源自于此。例如一些法规政策的制定，前后充满了矛盾，没能经过仔细的推敲。另如一些日常的争执，都是源自不够理性的进行思考和判断。因此在教育的过程中，培养研究和思考能力是最重要的一环，其重要性甚至超过了成绩和学位本身。如果我国的教育方法不改变，超过美国只能是一种奢望。

有人说中国的教育是让大多数人失败的教育，我深以为然。

2011年总结

2012-01-12T16:06:00.000-08:00

2011年的总结来的迟了，不过总比2010年的好，去年跟本就没写。那这次就包括2010和2011两年好了。。两年才写一篇blog的人真不多吧。。

九年冬，适风城，开始了新的旅程

十年春，遭遇Culture Shock，第一次管理老美

十年夏，出差费城，体验美国乡村生活

十年秋，徙居LA，新的挑战

十年冬，家有喜事

十一年春，安适的家庭生活，繁忙的工作

十一年夏，搬家，阳光，海滩，美食

十一年秋，娃诞生，家事娃事

十一年冬，离开服务6年的ThoughtWorks，迷惘

十二年春，灿烂的南加州，又开始新的征程

每次写这东西的时候，总是思绪延绵，不忍落笔，今年尤甚。去年发生了太多的悲欢离合喜怒哀乐。

但愿人长久，千里共婵娟。

Blog搬家

2012-01-12T14:40:00.000-08:00

由于长期没更新blog。。加上没管理备案，结果万网把我的blog直接屏蔽了域名解析。我还纳闷怎么是Error 324 (net::ERR_EMPTY_RESPONSE)。万恶的万网。结论就是再也不要在万网买域名了。

在老曹的帮助下重新设置了域名备份了数据，搬到了posterous。以后posterous就是主站，同时同步到wordpress和tumblr，由于tumblr不支持wordpress导入，因此tumblr将只有新post。

之所以选择posterous，是因为仔细研究了这几个blog网站，理解到其定位有所不同。传统的如wordpress之类的侧重于文本内容，因此你没啥可写的时候就真的得发呆空着。而twitter微博之类的又太短不能表达太多的信息。于是所谓的轻博客就出现了，例如tumblr或posterous之类的，既可以发文字，又可以发图片音乐视频，还自动同步各种其他网站。正好符合我的可长可短伸缩自如的要求。

而一个最重要的原因就是posterous重点定位于长期不写blog的人群。与其荒废一个曾经内容丰富的blog，不如都导入到这里来。这样能吸引到的人群绝对是大多数。坚持写blog的毕竟还是少数。

网站地址：http://icecloud.posterous.com

RSS永久连接不变：http://feeds.feedburner.com/icecloud

南加州的灿烂阳光

2012-01-12T13:11:00.000-08:00

新的2012年，在南加州，灿烂的阳光里，加油！

《博客三人行》25期:敏捷中国2009大会

2009-08-26T18:41:00.000-07:00

贴一个我参加的视频节目，呵呵。关于敏捷大会2009的介绍，这次敏捷大会我在参与组织。不知道为啥，视频里我的声音比较小。。估计主持人李宁没给我挂好话筒！！

由在敏捷领域最具有影响力的技术社区InfoQ中文站、敏捷方法论的领导厂商ThoughtWorks共同主办的敏捷中国大会（AgileChina 2009），将于9月11日~12日（周五、周六）在北京举行。届时将有超过400位来自电信、金融、互联网、教育等行业在内的高级软件开发人员、项目管理人员等参加。本次大会已特别邀请软件开发方法学的泰斗、极限编程XP的创始人、敏捷宣言的创始人之一Kent Beck，敏捷开发权威人士、敏捷宣言的创始人之一Dave Thomas，超过30多年IT从业经历的敏捷实践者Dave Nicolette，敏捷领域大师级专家、咨询师、有近40年行业经验的Fred George等国际敏捷领域专家，以及在团队中成功应用敏捷的上海贝尔、赛门铁克、诺基亚-西门子、eBay、腾讯等公司的项目负责人参与此次大会并分享他们的心得。

敏捷中国大会是国内敏捷技术领域最高水平的大会。今年的敏捷中国大会（AgileChina 2009），以Pragmatic Agile为主题，将一改往年的风格，参会者以高端开发者和技术管理者为主，融合管理和工程实践，推广全面敏捷之路。

http://player.youku.com/player.php/sid/XMTE1MTg0NzQw/v.swf

http://player.youku.com/player.php/sid/XMTE1NDExMzA0/v.swf

http://player.youku.com/player.php/sid/XMTE1NDU2ODQ0/v.swf

Agile Methods - From knowing why to knowing how

2009-05-06T17:10:00.000-07:00

我今天出差讲的ppt，第一次在一个舞台上演讲。。聚光灯照的我完全看不见台下人表情，烤的我一头汗。

Agile Methods - from why to how [slideshare id=1392283&w=425&h=355&sc=no]

View more presentations from icecloud

总结：
Well：观点来自我的论文；时间刚好1小时；图像比较符合；
Less Well：互动不足；乐趣不足，图片找的太匆忙；history部分讲的感觉有点简略；自己画的图貌似有点小错；时间太短，一些观点没法讲透彻。

也谈电话银行的交互设计

2009-05-03T17:04:00.000-07:00

电话银行的可用性研究

（本文是俺2005年6月写的作业，注重内容的同学请忽视此文，偶然翻出来贴上，引用链接好多都已经不存在了。）

随着网络和通讯行业的发展，电话银行、网上银行、手机银行作为低成本终端，得到各大银行的亲睐。目前我国各大银行均开设了电话银行业务，不少银行也同时开设了网上银行和手机银行。

据国外资料统计[1]，实体银行网点每处理一笔交易所需的费用为1.07美元，电话银行为0.45美元，ATM机为0.27元美元，而网上银行每笔交易的成本是0.01元。

电话银行[2]也称为电话银行服务中心，是现代银行业日益走向无纸化办公或线上服务和提高服务效率的必然产物。电话银行业务中，客户无需通过柜台而只通过电话完成所需银行服务，银行通过“人机”（即电话自动语音回答客户咨询、查账等）或“人与人”（即坐席员按照客户要求提供金融服务）对话的方式满足客户的要求。

网上银行[3]又称网络银行、在线银行，是指银行利用Internet技术，通过Internet向客户提供开户、销户、查询、对帐、行内转帐、跨行转帐、信贷、网上证券、投资理财等传统服务项目，使客户可以足不出户就能够安全便捷地管理活期和定期存款、支票、信用卡及个人投资等。可以说，网上银行是在Internet上的虚拟银行柜台。

手机银行[4]又称移动银行，是利用移动电话办理银行有关业务的简称，是移动运营商与银行部门合作，联合向社会推出的一个新服务项目，它是移动通信网络上的一项电子商务。手机银行业务的开通大大加强了移动通信公司和银行的竞争实力。

我国《2004年新银行业消费调查调查报告[5]》的数据显示，大约有14.8%的人使用网上银行，8.74%的被调查者使用电话银行服务。拥有电话的人数显然比拥有电脑的人数多，同样是新银行业务，为何其使用人数差别将近一倍？

造成这个问题的重要原因，是软件可用性的低劣。

衡量一个软件质量的好坏，人们的第一感觉往往是功能的多少。实际上，软件的质量体现在许多种方面。IBM公司曾提出用CUPRIMDSO作为衡量所有产品各方面的指标[6]，即下述单词的首字母：Capability Functionality (功能)，Usability(可用性)，Performance(性能)，Reliability(可靠性)，Installability(可安装性)，Maintainability(可维护性)，Documentation/Information(文档信息)，Service(服务), Overall Satisfaction(综合满意度)。类似的，HP也提出FURPS (Functionality, Usability, Reliability, Performance, and Service)作为衡量指标。可用性是评测软件质量的一个非常重要的标准。

可用性的定义来自于ISO-9241-11标准[7]，是指产品在特定使用环境下为特定用户用于特定用途时所具有的有效性(effectiveness)、效率(efficiency)和用户主观满意度(satisfaction)。

CRM软件发展到今天，大体功能已经基本确定。不同的软件之间，功能差别有限。因此，对CRM软件或系统的评测，主要决定因素之一就是可用性测试。

可用性测试可以应用在不同的范畴（包括软件、网页、硬件）从而针对不同客户的需求而能够更有效率及准确地达到他们的目标动作。

2002年，CRMDaily[8]网站发布了一篇文章[9]，批评了多数CRM软件的可用性。认为它们都没有通过可用性测试。

一个极端的例子是美国某公司花费了400万美金购买了一个著名CRM厂商的产品，但从来没有用它。因为随着实施的开始，他们很快发现，软件的操作方式对于员工来说实在是太难了。

CRM中的客户可分为内涵客户和外延客户。常见CRM系统中的CRM软件和呼叫中心，分别为一般员工代内涵客户使用和普通消费者作为外延客户使用。上述美国公司的例子是员工使用软件，而电话银行是由消费者亲自使用。

电话银行是呼叫中心的一种应用。但随着银行业务的增加，银行方面企图将所有业务都通过电话服务提供。

我国某著名银行，诞生比较晚，历史负担较轻，在早期的网络银行发展中，圈地较早，并且取得了很大成功。然而在电话银行系统的推广中，它却犯了很大的错误，让我们看一个简单查询帐户余额的例子：

拨号：欢迎使用XX银行电话银行系统

1 自动语音服务 2 人工服务

1 个人银行服务 2 公司银行服务 3 银证通功能 4 个人外汇买卖服务 5 基金服务 6 银行卡发卡消费中奖查询 8 财富帐户 0 退出

关于某基金的促销广告

1 存折户 2 一卡通 3 个人信用卡 4 新旧卡号查询 8 国际卡换卡查询 0 退出

请输入卡号，以#结束，请输入密码，以#结束

1 帐务查询 2 转帐 3 修改密码及挂失 4 互动足彩一卡通 5 通信业务 6 自助贷款 7 自助缴费 8 神州行充值服务 9 凭证式国债 0 退出

10 人民币 21 港币 32 美元 35 欧元 ……

1 活期 2 整存整取 3 零存整取 4 整存零取 5 存本取息 6 定活两便 7 大额定期 8 通知存款 9 教育储蓄 0 退出

1 余额 2 当天交易 3 历史交易 0 退出

您的余额是： 100.68元

电话银行的设计，和网络银行的菜单有根本性的区别。在网站上这样设计，用简单的菜单来呈现非常方便，一目了然。只要简单浏览一下菜单，就可以很快找到需要的功能。而在电话中，如果不是对银行业务特别了解，谁知道使用一个功能要到哪里呢？绝大多数人都没有足够的耐心去使用这样一个系统。

更甚的是，当我没有耐心，需要得到人工服务的时候，居然还会出现选择提示：

拨号：欢迎使用XX银行电话银行系统

1 自动语音服务 2 人工服务

1 个人银行业务 2 公司银行业务

1 快意理财业务 2 财富帐户服务 3 金葵花理财服务 4 网上银行服务 5 证券外汇及贷款咨询 6 普通个人银行服务 7 企业年金服务

请输入一卡通卡号或存折号，尚未开通帐号或遗忘密码，请直接按*#进入

我只是一个普通的客户，我很着急的想知道如何找到最近的一处ATM取款机或营业网点。而这需要我输入这么多东西吗？好吧，语音系统，告诉我投诉选项在哪里？我要投诉。

我国另一家著名的银行的电话银行查询余额过程如下，比起上一家，已经好了不知多少倍。

1 注册客户 2 非注册客户 4 存折代理交费 6 国际卡服务 8 异地漫游 9 人工服务

请输入开户卡号或客户编号，以#结束

1 帐户服务 2 外汇买卖 3 证券业务 4 代理交费 6 国际卡还款 7 个人住房贷款 8 客户服务 9 人工服务

1 快捷查询 2 查询余额及明细 3 转帐 4 查询帐户代码 5 挂失 6 查询货币代码 7 修改帐户密码 8 通知存款 9 人工服务

1 查询余额 2 查询当日明细 3 查询历史明细 9 人工服务

这家银行的网上银行，虽然开发较晚，但后来居上，以良好的界面和方便的功能，一举圈地成功。从上一家银行挖走了不少的客户。但它的电话银行业仍然存在难以使用的问题。

从业务功能上看，或许网上银行和电话银行差不多，然而，电话银行或呼叫中心的一个很大的作用，是获得客户的意见、建议、投诉、抱怨，通过人与人直接对话，处理客户的请求，取得客户的信任，建立客户的信心和忠诚度。这是网上银行、手机银行所不能替代的重要功能。

可用性低下就是电话银行使用人数大大低于网上银行使用人数的原因。银行为交流设置了人为的障碍，阻断了客户的热情。

可用性问题的产生原因，主要是由于软件开发人员对于客户心理和使用习惯不了解，按照自以为是的方式来编写用户界面(User Interface)。在软件发布之前，甚至没有经过客户的真正使用。在软件上线实施后，又舍不得花大力气返工和修整。

而一般的消费者，学历未必高，又没有经过专业培训，愿意花费的学习软件使用的时间也比较少。要想使客户能够很快上手使用，就必须在设计期对软件进行能够全面地、细致的、以用户为中心(User-centric)的交互设计。让软件变成傻瓜式的软件，任何人都可以轻松愉快的使用，真正的让客户满意。

从上世纪末开始，电子设备、电子产品、互联网等一些高新技术大量进入人们的生活。任何新产品和新设备都诉说着这样一个事实：当电脑和传统的设备结合(如电话，照相机，汽车等等)，它会变成另一个难用的电脑。人类使用这些杂交电脑时会产生“软件的种族隔离”[10]，即无法掌握新电子技术的人将无法得到工作，无法融入年轻人的生活，甚至会被社会所抛弃。技术人员努力工作，却漫不经心的构建了新的、更大的阻碍。

当开发人员仔细考虑过用户需求，认真设计了用户操作界面时。事情会变的更美妙。利用电脑的强大功能，我们仍然可以把事情变得简单。之所以以前没有这样做，完全是惯性使然。高技术、高学历的人员认为：这已经足够好了，至少我能使用。

如何解决这样的问题呢？首要办法是，化繁为简，去芜存菁，善用20-80原则，用20%的功能满足80%的客户的需求，不能追求大而全。

据调查[11]在2004年上半年的一次某银行电话银行签约客户回访调查中发现，有近1/3的客户从来没有使用过电话银行。当初签约只是一时好奇，或是营业柜员积极推荐，事后并没有重视。而使用过电话银行的签约客户中，又有2/3的客户只是查查余额，没试过或使用过缴费、转账、外汇卖买、银证通等业务。还有极小部分客户，虽然签约，但是思想保守，不能接受新兴事物，对电话银行的安全保障持怀疑态度。

从上述分析可知，在目前的电话银行中，最常用的业务是客户查余额，偶然使用转帐、交费等功能。以上述电话银行为例，可以改进如下：

1 输入卡号密码，自动判断是企业还是个人用户，自动进入下一级系统。或按*进入人工服务。

2 立即提示余额，再提示可进行的操作，如转账，查询历史明细等，更多功能请按9

既然必须要输入卡号密码，那我们先输入。用技术手段判断是什么类型。至于是否签约，难道银行还不知道吗？为什么要让客户去了解？

进入后，先把最常用的余额提示出来。不需要了解哪个子帐户，只要最近用的。我们只提供最基本最常用的功能。如果需要更多的其他的业务，请再继续选择。但根据调查，大多数的用户都不会继续选择更多的功能。

电话银行的价值，不在于它提供了所有的银行功能。中国人还是最喜欢到营业厅去办理业务。因此，电话银行的设计，应当针对常用的情景来设计。更多的时候，电话的作用，是人与人直接的语言交流。这是任何文字都无法替代的。

在客户关系的管理中，因为电话银行的难于使用而造成的客户的流失，忠诚度的下降，甚至对银行的抵触心理，最终导致客户意见建议难以反馈到银行。银行没有反馈，无法知道自己的错误，或可能认为投诉率的下降或许是由于电话银行的便捷，最后只能恶性循环。

在国外各大CRM软件公司纷纷增强其产品可用性的时候[12]，国内CRM软件的可用性也应当做一些改进。竞争日渐激烈，利润越来越低，但软件使用效果却不佳。提高可用性和交互设计或许是软件企业翻身打胜仗的新法宝。

---------------

后记：本文借鉴了Windy姐的电话银行交互设计的例子，不过这篇是从交互设计的角度讨论CRM，呵呵

---------------

参考书目

Alan Cooper，刘瑞挺等译，《The Inmates Are Running The Asylum》，《软件创新之路》，电子工业出版，2000年。

王广宇，《客户关系管理方法论》，清华大学出版社，2004年

董建明等，《人机交互：以用户为中心的设计和评估》，清华大学出版社，2003年

参考资料

1 钟伟 - 中国网上银行发展回眸 http://www.doctor-cafe.com/detail1.asp?id=269 2005.06.02

2 金融信息化系列专题(三)：电话银行 http://www.cfn.cn/Statics_pub/Dissertation/ztzj/zt_jrxxh_dhyh.asp 2005.06.02

3 中国银行网上银行 http://supermart.stockstar.com/supermarket/chinabank/wsyh.htm 2005.06.02

4 被寄予厚望的手机银行 http://www.cnii.com.cn/20040423/ca258514.htm 2005.06.02

5 2004年新银行业消费调查调查报告 http://www.ciweekly.com/A20040329298365.html 2005.06.02

6 Software Quality Metrics Overview http://www.awprofessional.com/articles/article.asp?p=30306&rl=1 2005.06.02

7 ISO 9241-11:1998 Ed. 1 Current stage 90.93 TC 159/SC 4

Ergonomic requirements for office work with visual display terminals (VDTs) -- Part 11: Guidance on usability

ISO 9241是关于办公室环境下交互式计算机系统的人类工效学国际标准，它由17个部分组成，根据人类工效学和可用性原理，分别对各种硬件交互设备属性和软件用户界面设计问题作了详细的规定和建议。可以对一个产品设计符合该标准的程度进行评估和认证。

8 CRM Daily http://www.crm-daily.com 2005.06.02

9 CRM Flunks the Usability Test http://www.crm-daily.com/perl/story/18310.html 2005.06.02

10 Alan Cooper，刘瑞挺等译，《The Inmates Are Running The Asylum》，《软件创新之路》，1999年

11 发展呼叫中心的难点及对策 http://www.fcc.com.cn/2005/4-7/10434.html 2005.06.02

12 Usability lifts Siebel CRM http://www.vnunet.com/itweek/news/2085464/usability-lifts-siebel-crm 2005.06.02

PeopleSoft Enterprise CRM 8.9 delivers major usability enhancements
http://www.itweb.co.za/sections/enterprise/2004/0405270752.asp?A=ENS&S=Enterprise 2005.06.02

严重实用技巧：Word2003中修改尾注位置

2009-04-21T19:16:00.000-07:00

这两天一直在写论文，采用了Word 2003（没办法，学校要求格式，不敢用mac的破Word2008），其中一项功能就是添加引用的尾注。然而，这个尾注功能及其的不好用。它存在3个问题。

A 论文要求用[1][2]这样的形式来表示尾注的编号，而word默认的都是(1),(2), i, ii, iii, I,II,III, 子丑寅, ABC,甲乙丙（一）（二）等等不知道谁在用的符号。而且，无法自定义符号！有一个看来貌似叫做自定义符号的按钮，会把所有的数字都替换成统一个符号，例如*。

解决办法是：

1.首先，按照普通方式插入脚尾注
2.CTRL＋H唤出替换窗口
3.前一个替换栏输入^f(此是脚注，尾注用^e)
4. 替换为栏为[^&]
5.完成。

B 尾注一但分页，就会出现一条分隔线。上面写着****我是伟大的分隔线*****

解决办法是：

1. 将当前视图，设为普通视图；
2.选取菜单“视图”——“脚注”，会在下方出现一个下拉框，选择其中“尾注延续分隔符"
3.完成

C 论文要求把尾注区域插在第五章结论和致谢之间。而又限制了每章必须用自己的章节标题作为页眉。这两个需求导致了word的尾注区域不能正常工作。因为尾注只能添加在节的结尾处，或者添加在全文的结尾处，并且不能手动移动位置。而为了每章换用不同标题，必须要每章分节。因此，尾注就只能分散到每节之后，或者全在致谢之后。

解决办法是：（我搜索了很久确信确实没有人提出过解决方案，估计同学们都是手动改的吧。。。）

1. 按照普通方式插入尾注
2. 选择将尾注插入每节之后
3. 正常分节（这时候所有的尾注都在节尾）
4. 到第一节内容中，选择文件->页面设置->版式->取消尾注。这时候第一节的尾注会自动合并到第二节之中！！！！
5. 重复4直到达到参考文献一节
6.完成。

无语了！！Word，你好变态啊～ MS啊，你这样折腾为哪般？

请赞同，而不说“不是” －关于交流和反馈

2009-04-19T17:00:00.000-07:00

关于交流

1. 永远不要以否定词开始你的对话

最近经常听到人说话时候把“不是”这个词放在句首，例如有人说：“我觉得这个设计是符合可用性原则的，你看这用户按钮这么大，多好点击啊！”有人说“不是，按钮大不代表可用性就好啊。。。”我认为这是一种很不好的习惯。他在不经意间，把自己的立场摆在了和讲话的人的对立面。甚至他们观点实际上相同的时候仍然不自觉的用“不是”开头。对方听到“不是”，虽然表面没说，但心中早已掀起滔天巨浪…… 这样说话要花很多功夫才能达成一致。（貌似很多老北京都这么说话，很奇怪。）

作为一个咨询师，当尝试解决用户的问题的时候，或尝试推销解决办法的时候，切忌用否定的句子开始阐述。当一个咨询师说“不是”的时候，无论你后面的论证多么的严谨和完美，客户都已经提前丧失了兴趣。有的时候，赞扬谈判对手能够更快的达成一致。

这时候一定要换一种说法：“你说的很有道理，我帮你改善一点……”，“你说的对，如果……能够再……一点……用户体验就更好了”。

2. 交流的唯一目的是达成共识

交流发生于双方发生分歧的时刻。例如你对工资不满意了要和老板交流，再比如需求搞不清楚了要和客户交流，在家里有矛盾了得和老婆交流等等。总之交流这个事件的产生动机总是因为有些东西搞不清楚，而交流的目的就是把这个东西搞清楚，大家对问题达成一致的理解。

然而，很多时候交流的双方忽视了交流的目的，陷入了盲目的交流漩涡。尤其是看到两个人在pair programming的时候，为了一个设计争得面红耳赤不可开交，这时候他们只是为了说服对方、或者证明自己的权威而交流，目的改变了。

3. 交流的基础是尊重

顺畅的交流是建立在互相尊重的基础上。当你和一个人说话的时候，如果他眼睛望向一边，心不在焉，根本不仔细听，敷衍的和你说，这时候说话的人是什么感觉？如果对方用傲慢的语气粗鲁的对你说，“你这个观点很愚蠢”，“我的一个朋友才是我见过最牛的（言下之意就是你不够牛）”，这时候说的人还有没有动力继续说下去？

交流的时候一定要怀着一颗平等的心。。。无论和你交流的人经验深浅，无论地位高低，无论贵贱。

4. 交流是双向的。要用心听，认真反馈

一个很好的实践叫做“Active Listening”，或者叫“主动倾听”。所谓Active Listening，通俗的说就是指听别人交流的时候，要经常嗯嗯啊啊的赞同，并且不停的问“后来呢？”这个讲故事的人最爱听的短句，以及经常的总结一下对方的观点。这样的主动交流比较能够促进说话的人的积极性，使得话题能够不断的进行。

更重要的，是要对说话的一方提出反馈。工业上说反馈是质量的关键，只有建立了良好的反馈渠道，产品的质量才能达到客户的要求。当然，要区分的是，有时候别人说了一件事情，并不是真的想要听者提供反馈，只是抱怨和发泄一下需要听众而已。

关于反馈和提建议

1. 当你要反对的时候，请同时给出你的建议

在一个风和日丽的中午，你问旁边的同事：咱们中午一起去吃7-11好不好？他回答说：又是7-11啊，不去。或者，你好不容易写了一段感觉良好的代码，给你的同事看，他说：写的不好。（下面没有了）。总有一些人习惯于否定对方的意见建议，又不能给出自己的办法。这样人非常多。

当提出反对的时候，一定要同时给出建议。例如我们做开发过程的回顾会议（Retrospective）的时候，如果光说出不好的地方在哪里而又没有改进建议，那几乎和没说差不多。

2. 提意见建议之前，先赞扬好的一面

意见建议这个词，老外经常会用Feedback。这Feedback是个好词。辞典里说：“If you get feedback on your work or progress, someone tells you how well or badly you are doing, and how you could improve. If you get good feedback you have worked or performed well.”

说起Feedback的时候，隐含的含义就是要告诉你什么做的好，什么做的不好，并且告诉你如何改进。其中更重要的是要发扬好的。而反过来看我国这边，很多情况下我们叫提“意见建议”，意思就是对你做的不好的地方指点一下，在给你提出点改进建议。我国古代曾经有活动叫“批评与自我批评”，更多的是看到了坏的一面，而忽视了对好的一面的坚持和发扬。

有人发明了“建设性意见”这个奇怪的词，难道对应的应该叫“破坏性”意见？貌似从来就没有一个中性的词来指给别人的Feedback。可能是自古以来朝堂上就只有抨击诘责没有正面的Feedback吧，就算有也被归于了阿谀奉承、溜须拍马一类。由于我们的这种传统，在很多情况下，我们给人提Feedback时，都容易倾向于对人进行批评性的评论。而这种评论，是破坏团队关系公司文化的特效药。

3 Feedback的目的是提高效率和增强信心

以前参加过培训，其中一课就专门讲到给人提供Feedback。给人提供Feedback，你只有两个目的：提高对方的效率，或者增强对方的信心。前者，就是针对某些不好的地方提供改进建议，后者，就是对于对方做的好的地方表示支持和鼓励，希望他再接再厉。因此，所有的Feedback，应该都能够达到这两个目标。这两个作用之外的任何其他作用，都不是合适的Feedback。

我们公司内部Feedback的种类有很多，有非正式的Feedback，离开项目的Feedback，半年期的Performance Feedback，面试之后有Feedback等等，但做法都大同小异。首先，想要给人提Feedback，你要先获得对方的允许。反之，你如果想得到别人的Feedback，你要向对方正式提出邀请。

4 提Feedback要针对行为，要具体

人的行为其实都有动机。动机(Motivation)决定了态度(Attitude)，态度决定了行为(Behavior)。例如一个人的动机是想赚大钱，他的态度就会很积极上进寻找机会，他的行为就会表现为愿意参加各种创业俱乐部之类的。

提Feedback的时候，只能针对行为来提，或者说，就事论事，而绝对是不可以针对人的动机或态度提。例如说，提Feedback说这个人太自私，平时总不积极参加活动什么的。这是错误的提法。可以改为：某某最近不经常参加某活动，如果他以后能够参加这个活动，那么他能够在活动中获得什么什么知识等等。如果针对人的动机提Feedback，一来提Feedback的人会先入为主出现偏颇，二来听Feedback的人会听不下去。

另一个提Feedback的时候的常见情况是太空泛。常见的是在提Positive Feedback的时候，有人说：某某非常nice，某某非常容易相处。好话人人爱听，并且这好话都是针对态度的话。然而，这些话纯粹是拍马屁没有实际用途。要用事实说话，举实例。要说某某做了什么让你觉得nice，某某做了什么证明了他容易相处。这些具体的实例对于接受Feedback的人会起到促进的作用。

另外要避免使用我认为，我估计，我猜，可能之类的词。因为这些词不客观。想对一个人进行了解，只能根据客观事实来判断，而不是可以根据别人的判断而判断。

5 给组织提Feedback就是Retrospective

当我们把上述的实践用于组织和过程，就是敏捷方法中常见的Retrospective了。Retrospective的目的是增强团队的效率和提高团队的信心，一个有效的Retrospective也需要：先提出团队过程中好的一面；当提出不好的时候一定要有具体的改进建议；提出的好坏方面都必须具体，对事不对人。

当我们每个团队的个体成员都学会了如何交流，如何提Feedback的时候，那么团队的自组织和自完善也就很好办了。团队建立起完全平等和安全的交流环境，成员们就会逐渐的去进行交流和反馈。

架设一个BLOG需要整合多少东西？

2009-04-16T07:40:00.000-07:00

最近重新升级了我的Blog，BJUG的Blog到Wordpress 2.7.1，以及帮人新安装了Wordpress。期间涉及到了无数其他系统的整合和使用，列举如下。

1 Wordpress本身需要花费功夫的地方不多，比较容易，但Themes要花不少功夫调整，有时还得改CSS。推荐几个Wordpress Themes网站：

- http://themes.performancing.com/
- http://www.blogohblog.com/
- http://www.neoease.com/themes/
- http://www.underone.com/themes/
- http://www.billionstudio.com/
- http://wordpress.org/extend/themes/ - Official

2 访问统计当然要立即搞起来，首选的当然还是Google Analytics，另外加上Analytics Plugin

3 网站要做SEO，要用URL Rewriting，这个需要配置apache修改.htaccess文件的权限，另外要让Google快速索引网站，得用Webmaster服务并加上Sitemap Plugin。

4 网站用了别人的服务器，不能给网站太大压力呀，用Google的搜索代替Wordpress的搜索，用Google Custom Search Engine

5 做网站肯定得想赚钱拉，虽然咱这blog流量这么低估计赚不到什么，不过一分一毛也不能放过。架上Google Adsense 和阿里妈妈 (审核不知道为啥没通过)，再用Adsense Plugin来管理。当然Feed广告也是一个值得设置的事情。

6 写Blog目的当然是为了展示自己，那“自己”包括什么呢？首先是个人的档案，先连上Google Profiles。然后把我在做的(Twitter)，我在读的(Google Reader)(Del.icio.us)，我在看的(Douban)，我的行程(Google Calendar)，我的旅途记录(Flickr)(Picasa)都聚合到我的blog。好在这些服务都支持HTML的Widget，不需要再安装插件了。

7 读Blog当然不能不用RSS订阅，先用Feedburner和Feedsky建立好永久的Feed免得遗忘丢失，然后在里面添加Feedflare以便订阅者再分享和收藏。

8 写Blog当然还要交朋友了。用Google Friend Connect来结识朋友，允许访客通过Google Talk Badge来联系自己，在评论中显示人家的Gravatar头像，安装Gravatars Plugin。让访客只要登录Friend Connect就可以评论吧比较方便，不过垃圾评论一定要避免，好在已经有了默认的Akismet plugin。

9 咱辛苦写好的文章不能被人随便拿走，所以要声明版权。用Creative Commons声明一下咱的文章可以转载，但版权归我且不能商用。

10 还想加其他东西到Blog？试试看Google Gadget的Embed功能。这里面几乎包含了所有的东西了。

11 呃，embed了太多服务blog打开太慢了怎么办。。。那。。只好。。把js代码改成异步读取。。用Google AJAX APIs异步调用JSON或RSS。。复杂了

12 最后，别忘了备案，@diamondtin同学没备案服务器已经被端了。

嘿，自己架设一个博客要干这么多事情，容易吗？这个貌似可以提供一种专门的咨询服务了，专门为人架设博客。

QCon Beijing归来感想及总结

2009-04-09T07:53:00.000-07:00

昨天和前天参加了两天QCon Beijing的会议。有所感想。

关于话题和话题的质量

听了2天的Session，发觉人的演讲水平确实能够很大程度上决定一个Session的好坏。这里说的演讲水平不仅仅是指台上的语音、声调、手势、姿态，还包括他做PPT的能力。

第一天的话题我主要听了敏捷开发部分。

Martin Fowler的Ruby Session特点是组织严谨。不愧是俺公司的科学家。观点的逻辑组织非常的严谨。所有的观点都有证据，满篇都是调查、数字、统计。基本上可以说，这个Ruby的话题可以作为论证Ruby在软件开发中价值的一篇很好的论文。结论是Ruby在ThoughtWorks被认为是Positive的选择。老马底气充足，吐字清晰，一口不标准的伦敦音非常容易懂。美中不足的是两点：1 他图片上的颜色选得很难看，2 PPT中采访的几个人说的话由于音响噪音干扰听不太清楚。

Henrik Kniberg的多团队敏捷胜在图片详实。他用很形象的图表示了团队的组成，又通过很多现场照片具体列出了实践的过程和问题。印象最深的部分是那个IPM的例子，90人的团队IPM/Planning的Session面对面来做，甚至不惜把人从不同的地方飞过来。总之讲的比较务实。一个值得借鉴的做法是他把图片中的人脸模糊化了以避免冒犯客户。

傍晚参加晚宴。晚宴中有位老外讲敏捷Session，明显的犯了几个演讲大忌：1 对听众了解不足。从敏捷历史甚至软件过程的历史讲起，认为下面听众都不了解。整个主题只讲了为什么要敏捷这一个话题。反正我是觉得没有新意。2 演讲的ppt很失败。一页八行句子，他还在照着读。加上现场音响不好，后面的人听不清楚。于是有的人开始私聊，隔一会儿抬头读一下PPT上的字。会场噪音更大。

之后的大师论坛还是很有趣的。几位老外＋Ben Wang在台上论述他们认为的企业开发发展趋势。话题不外乎云计算、动态语言、多语言编程、开源、敏捷/精益等。多数老外的论述比较充分，证据和推论都很清晰。其中唯一令我觉得不靠谱是Rod Johnson同学，他说了一些话让我觉得很费解，例如Opensource is good，because developers have to like it. 还勉强类比Tomcat是精益的软件，Websphere是不Lean的。说的有些不够令人信服。

第二天开始的话题主要是网站架构。

一开始是Rod的话题。他的演讲语速非常慢，慢到一句话都要分3短句来说。上述的Tomcat/Webshpere问题又被抛出。后来才知道SpringSource现在在维护Tomcat，这么做未免太着相了。。总之这个Session很平淡，没有什么出彩的地方，印象不深刻。

之后是EBay的话题。这个Session被讲过好多次了，唯一的问题是PPT字太多而且太小。。我们坐最后一排根本看不清楚第三级的字。强烈建议Randy下次改改PPT。这个Session概括了大规模Web的最佳实践、模式以及问题等等，可以作为这第二天全天话题的一个总结。虽然没有具体的实施例子，但把问题分析的很清楚。在什么情况下，应该采用什么样的策略，好处是什么，坏处可能有什么等等。

上午最后一个是一个讲Agile+CMMi的。这个Session的最大问题不在于演讲技巧了。。而在于他的观点本身，听了一会儿我们就听不下去了，决定提前去吃饭。后来Steven发帖提到：Joke of the day: "Repeatable and Controllable Agile Processes"

下午的话题是重头戏，估计大多数人是冲着这个来的。

首先是来自支付宝的程立带来的SOA治理。这个演讲的PPT可以说是最炫的PPT之一，画了很多的非常华丽的过程、架构等图，如果作为售前用PPT将非常有冲击力。然而，这个话题听的令我一头雾水，到后来基本全部LOST，不知道他在讲什么。归其原因，我认为有3点：1 演讲所提到的架构和我平时所理解的架构不是同一个“架构”。貌似这里提到的架构分很多种层次，例如公司架构、组织架构、业务架构、应用架构，不同层次有不同的关注点。SOA治理这个词更偏向于治理而非SOA，因此对核心名词语义的不同理解导致了从一开始我就没能跟上思路。2 演讲的PPT似乎没有一个清晰的逻辑主线。前后的逻辑关系我没能听清楚。 3 下午第一场，刚吃完饭，未免有些小乏。以上原因导致该话题完全脱离了本人的理解范围。

豆瓣洪强宁的Session在会前被冯大辉狠狠的赞了一次。因此这次被报以的期望很高。该Session按照时间顺序组织。从豆瓣一开始上线的情况、架构选择，到后来不同用户级别时候出现的不同问题，应对措施，解决办法，甚至相关代码。非常完整和清晰的展现了豆瓣架构发展里程和其中所采用的具体策略。这样具体的Topic非常的精彩。强宁的演讲技巧也蛮好，语速发音都很专业，一定是练过。有趣的话题，专业的演讲，加得当的Slide，个人认为本Session可以当之无愧的成为QCon今年最佳Session。

有道的Session是关于日志分析。话题其实可以讲的很有趣，但遗憾的是邓毅同学的PPT做的貌似太过简单。原本可以讲的很详细很有趣的故事被简化到了若干的纯文字中，非常可惜。如果能够多一些图，更好的组织一下故事，可能会是一个非常精彩的演讲。

优酷网邱丹的话题也是关于性能和扩展性。由于优酷和豆瓣本身的区别，其对扩展所采用的策略和方式都非常不同。这个演讲的PPT做的有点山寨，图片看起来太简朴了。邱丹同学的演讲技巧还需要进一步加强才好。优酷和豆瓣的话题加在一起可以看做是对EBay Randy话题的完美诠释。一面是具体实践，一面是总结的模式和最佳实践。

从第二天下午的演讲，可以明显的看出，一份精彩的演讲，其讲师的技巧、PPT编写、话题的组织、以及对听众预期的满足都非常重要。任何方面的欠缺都会导致Session的精彩程度大大降低。

关于活动组织和对下次活动的期望

本次活动是QCon第一次组织国内的大会。能感觉到QCon在组织方面做了很多的努力，但规模貌似还是有些保守了，可能是怕第一次做太大万一失败有压力吧。组织方式上有很多方面值得其他办活动的人借鉴和改进。

组织方面：

路标提示。虽然在网站上写清楚了地址，但现场的标记似乎还不是很清楚。只看到会议厅最前面有个白板上画着地图，这白板应该放外面去。尤其一楼门口应当设置一个大大的广告牌。很多人一开始都找不到这地方。

吃饭时间和方式。目前大家同时放学去吃午饭，结果排长队或者没地方坐，结果导致下午会议延时开始。这是典型学校食堂遇到的问题。。一般学校都靠错开吃饭时间来解决。但显然这会议时间错不开，不妨弄点简单食物，或者延长午休时间。

午休时间如何利用。午休时间大家好像在会场里面没啥事情，于是就有人播放美女视频。。这个时间其实本可以是各个厂商展示的好机会。

茶歇。。有点山寨。。咖啡饮料都装在一个19升的矿泉水桶里面送来。。可以理解这是为了减少成本。不过貌似这方面还是可以改进一下下的。另外吃的和饮料都摆在一个桌子上造成了拥堵。

主持人和课程组织。这次活动主持人的作用没能很好的发挥出来。每个主持人都是该领域的专家，如果他们能够更多的露面和讲话就更好了。例如晚上可以分会场让每个主持人来组织活动。

晚宴的组织。晚宴时候最大的败笔就在于座位的摆放。其实晚宴更多的应该是社交活动，有没有椅子都不重要。重要的是大家应该能四处走动和别人搭话交流。晚上饮料提供的不够哎，喝了点水就没了，再说半天话口干的很。

设施方面（理想会议场馆建设指南）：

讲台布局。这次的场馆讲台中央很宽大，但作者只能站在一个小台子边上做演讲，两边的投影幕布太小了，字小了看不清。如果有场馆能提供TED那种讲台就好了。下回找个舞台或剧院试试看。

会议厅。这次分了两个厅，大厅很宽敞，但是小厅非常的狭小，很窄很长，屏幕又小，又不够通风。因此小厅的效果不好。理想的场馆应该是能有大厅一个，多个50－100人的小厅才够用。

网络和电源。现在越来越多的活动鼓励大家twitter或者上传现场照片，这样网络和电源就成了必需品。这次的无线网络的DHCP不能用，因此很多人都没法上网。电源也是稀缺物品。

存物柜。现在这季节大家都穿个大衣来，进屋又要脱。如果有场馆能够提供一个地方挂衣帽就更好了。如果能临时锁书包就更佳，因为大家很多都带着电脑来，中午又不放心放会场，只能背着去吃饭占用食堂空间。

当然拉这些只是我自己的理想中的场馆。貌似这样场馆真不多。

对于下一届QCon的期望，当然是希望能够像QCon london一样举办5天每天5个track一共近百的Session才好。这才能显示出QCon在技术社区的影响力。

关于参会的目的

从公司角度来讲，公司来参加这样的会议一方面是建立自己的品牌，看是否能有业务机会，一方面也是可以支持公司员工学习交流。

从个人角度讲，参加QCon学习知识只是一方面，其实最大的目的还是来交朋友。这次俺结识了几位新朋友，例如冯大辉、洪强宁，也见到了以前网上聊过很多但一直没过见面的几位，例如林昊、苏锐、Steven Mak麦天志，还见到了好久不见的老朋友吕晋、InfoQ编辑团队一小撮人等等，嘿嘿，非常的高兴。遗憾的是时间有限没能一起去吃饭哎。

有一些参会人，来了之后就光听讲座，听完之后不提问题也不和人交流，这样的参与者回家之后能获得什么呢？公司花几千元买的门票，不是让你来上课的。想听讲座的人在家呆着听视频看文章多好，还省事。

新BA上甲板指南 - New BA on board guidelines

2008-09-27T19:12:00.000-07:00

此指南为我所在的项目引入新BA的参考步骤，并非ThoughtWorks官方指南，仅适用于特定项目的特定情况。

Task 1: 请自己去认识团队的所有人。

BA肩负着交流者的使命，需要和客户和团队都创建一定的关系，主动去认识每一个人，做自我介绍，发放名片，请大家多关照，以后合作愉快。

Task 2: 了解项目背景

BA应该是最了解项目背景的人。项目之后的驱动因素，项目的目标，项目所解决的问题，项目的流程，项目所涉及到的其他系统，项目的范围，项目的涉众，项目的用户，项目的发布蓝图，项目的当前状态。

Task 3: 简单了解敏捷开发过程

在敏捷的过程中，BA处于一个承前启后的角色。BA需要了解项目过程中的各个术语，项目迭代的长短，交流方式和频度，客户如何计划，如何给客户展示，每天何时开始工作，项目状态交流方式，团队的分工，分布团队的工作方式等。

Task 4: 了解BA工作职责

BA的日常工作包括很多事。每个迭代让客户确认需求，与客户沟通，澄清问题，询问细节，电话会议，组织讨论，给开发团队介绍业务，保证开发速度，在mingle上管理需求，确认defect的优先级，回答开发人员的问题。

Task 5: 学习基本BA技能技巧

BA的基本生活技能包括：和业务人员的交流能力，和技术人员的交流能力，足够的展示能力，能够可视化的表现需求，演讲文稿制作，英语交流和写作，商务信函的处理，控制会议的简短和有效，有条理的描述清楚需求，分析复杂的需求和过程，快速发现用户问题，设计良好的用户体验，逻辑的分析和叙述问题。

Task 6: 尝试完成当前项目的工作任务

快速了解系统功能，阅读项目的需求清单，在本机实际运行项目，测试和了解项目的功能，Shadow当前的有经验的BA，接手简单的工作，处理业务邮件，参加需求讨论，阅读以前的相关文档。

Task 7: 了解BA的Career Path

和sponsor坐在一起，了解行业中的BA能做什么，我们公司的BA做什么，BA发展发展方向有哪些，公司提供哪些机会给BA发展，公司提供什么培训，明确自己的兴趣爱好，搞清自己对生活与工作的权衡，找到自己的前进动力，确定自己的发展目标

Task 8: 制定自己的学习计划

确定一个短期计划，确立学习和努力目标，制定近期的实现步骤，阅读参考书或资料，定下review时间，为自己创造压力，然后努力的开始做这份有前途的BA职业吧。

附录：新时代情况下对新BA的四大要求：

要聪明，客户时间紧团队任务重，没有人有空把一个事情解释很多遍。

要谦虚，在没搞清楚问题之前不要自以为全盘了解。

有条理，要能够在毫无头绪的需求中有逻辑的分析出可行的方案。

英语好，不仅仅是读写，听说更加重要，并且要是business english.

敏捷过程中的需求分析实践

2008-09-04T15:17:00.000-07:00

下面链接是我8月30日在Beijing Open Party的Session录像 :D

http://v.ku6.com/special/show_2595040/CPZyfRwmkG6DlsPb.html

http://v.ku6.com/special/show_2595040/SiHN2uI2YAaTPkaI.html

自定义Mac OSX快捷键

2008-05-10T12:17:00.000-07:00

自从用了Macbook pro，那感觉真是一个爽快。。。然而，经过几日的使用，发现以前Windows下面的习惯实在是改不过来，所以做了些定制。

1 采用Option + Up/Down 完成Page Up/Down功能

我阅读文章总是尝试去寻找PageUp和PageDown。系统默认的支持用Fn+Up/Down来实现这个功能，但这俩键离的太远了，我需要一只手能操作的。于是，找到了下面的几篇文章：

http://blog.macromates.com/2005/key-bindings-for-switchers/

http://lifehacker.com/software/keyboard/mac-switchers-tip--remap-the-home-and-end-keys-225873.php

http://www.hcs.harvard.edu/~jrus/Site/cocoa-text.html

http://www.hcs.harvard.edu/~jrus/Site/System%20Bindings.htmlкомпютри

总结了一下后，找到~/Library/KeyBindings/DefaultKeyBinding.dict，增加下面一段

{

/* page up/down */

"~UF700"  = "pageUp:";

"~UF701"  = "pageDown:";

}

意思是Option + UpArrow = PageUp, Option + DownArrow = PageDown。好了，下面就可以一只手使用pageup/pagedown了。

2 自定义FireFox的快捷键

上面那个在TextEdit之类的软件中用着蛮不错的。。。但是在Firefox里面不支持。因为FF用了自己的一套快捷键。于是又安装了个插件叫做keyconfig。在配置选项中添加：

项目名：ScrollPageDown，

功能为：goDoCommand('cmd_scrollPageDown');

然后设置上快捷键即可。

3 在用Windows时候，使用Command代替Ctrl

在Mac里面Command按钮用着太舒服了，以至于在任何Windows里面我都会继续按这个位置。。或者出来的是Start Menu，或者是按了Alt，为了继续保持使用Cmd，我在Parallels desktop的Win里面安装了叫keytweak的软件，把Ctrl和Cmd两键功能互换了。于是，在Windows下面，依然可以Cmd+T开新Tab了，耶！

Beijing Code Jam - 2 days agile development project

2008-04-21T18:48:00.000-07:00

上周末忙忙碌碌的，在公司做了两天的公益项目。具体的过程郑晔说了不少了，我从BA的角度做些补充。

Code Jam是ThoughtWorks特别的活动之一，在很短的时间内为客户交付可用的软件（或原型），团队经过短期高强度的锻炼，可以对开发过程和开发技巧都做一些反思。这次的Code Jam是为乡村教育基金会做一个网站，属于一次公益性质的活动。我们几个人从周五开始就忙碌了起来。

首先，作为BA，先期了解一些需求是必要的。在开发之前，必须要知道Scope和优先级。周五下午我和QQ俩人就和我们的Client，来自（伦敦、香港、墨尔本）的Steven，一起进行了简短的需求分析。由于项目不大，而且总共只有2天时间，我们重点关注于需求的优先级。在搞清楚流程的基础上，把优先级分了7级。听起来好像很多的样子，实际上，从需求完整性考虑的话，前1－3级的需求比较多，后面的都是很小的功能模块。我们保证每一级开发出来都必须是可用的软件。Steven非常聪明，对我们的方式适应极快，很快把握到排序的要点，到后面亲自操刀开始写Story，终于达到了”客户编写用户故事“的极境，令俺窃喜不已。

终于，4个多小时之后，全新的story list出炉了，1-3级story有卡，1-2级的卡背面写有A/C。总结下来，这次需求分析做的比较好的地方有：

要在很短时间内需要搞清楚足够开发的需求，因此我们确定了项目远期目标、用户交互流程、特性的优先级，取消了评估开发时间一项。在下午需求会议开始前，我们制定了：1 项目目标 2 功能范围 3 优先级 4 界面交互原型 5 用户故事 6 细节验收条件等会议步骤，在4个小时内准备好了可以开发的需求。

BA、QA和客户坐在一起交流需求。这是非常理想的情况，很多项目由于种种条件限制使得BA/QA没法从一开始在一起。

需求和界面原型全部采用纸质管理，没有除了照片以外的任何电子存档。不管是开发人员还是BA/QA，都手持卡片和人交流，有任何问题和发现都记录在卡片后面，这节约了很多时间。（当然，由于QQ太过谨慎，怕卡片被打扫卫生的阿姨清走，特地锁在了她的宝箱里，结果晚上胃病第二天没法来……由此可见，项目风险总是不可能全部预测的）

在Story的上面标注了依赖关系。以往做Story经常忽视这点。这次特别标记出来，在开发过程中作为Dev开发的参考。

优先级的制定。没有采用传统的MoSCoW法，而是就用1-9的数字来表示。我们最终将1-3的大多数需求交付，客户很满意。

Hight Level 系统结构图。通过整理此图，我们全面的了解了系统的蓝图，客户也在过程中重新反思了不少的特性。这图不完全是流程，其实更像是Information Architecture+Domain Model，结合了功能+界面两种不同的元素

做的不够好的地方也有

由于对Rails开发的效率无法预估，我错误的假设了两种不同类型的文档在提交时候有很大部分功能可以复用，因此在写第二类的时候，简化了一些Story，最后证明这些还是得写上。此处犯了INVEST中I的错误

有些Story的A/C描述的不够。凡是有可能出错的地方都一定出错定律。。。例如，search结果的list中，通常都有link可以view detail，因此就没写在A/C，果然被遗漏了

周六开始进入正式的开发阶段。由于时间短，我在周六早上主持了很短的kick-off，大致说明了项目情况，读了一遍优先级1的需求，就开始开发了。团队都是非常优秀的人，很容易就形成了自组织的团队。一开始所有的人都开始找BA问问题，有些手忙脚乱。好在过了启动这段后就好多了。

我和其他两位过来帮忙的BA一起，安装了只有ready, in dev, dev done, qa done四个状态的story wall在墙上。公司的推拉白板柜门很好用，需要用哪张墙就推过来，不用的就推走。一共占用了4张白板。Story Wall，流程Wall，界面流程Wall和Wiki Wall各一个。

因为大家采用Textmate，而并不是所有人都用过它，因此一开始team是用过的和没用过的pair，先熟悉工具。中午时候大家switch。

在开发阶段，我们整个团队做的比较好的地方有：

自组织的团队。真正实现了自组织。每个人都尽力将事情向好的方向推进。大家都尽职尽责的完成任务。

在开发优先级1需求的时候准备优先级3的A/C和优先级4-8的卡片，使我们不用在一开始就准备所有的功能。

采用活动墙壁做需求墙，team需要看什么就把那个移动过来近些。

开发团队频繁的轮换pair，可以收到很好的效果。从BA的角度可以很明显的感觉到哪个pair遇到了问题，从而协调team之间的取长补短。

和客户交流频繁，所有一开始由于时间关系无法确认的需求都交由现场客户Steven解答。中间根据进度，我们建议更改2和3级别优先级的顺序，客户也确认了这次更改的必要性，使得我们最终能够交付正确的产品。

一天两次的简短的standup。由于大家平时交流的充分，standup可退化成宣布值得大家知道、比较重要的事项的碰头会，如果没有事情说就不用说话。

简短的retrospective。自组织的团队不需要太多的反省。每一个人都是很好很有能力很有想法的成员，只要列出来我们发现的问题，大家会自觉的去解决。

从一开始就运行的test和build。很大程度上提高了团队的整合度。

8dev团队，一天95次的提交次数，一天18个migrate脚本，一天12张story卡的速度。

做的还不够好的地方或者改进的想法还有

在开发之初的设立UI pair，在开发后期设立专门BUG pair的作用不可忽视

每天的switch pair还是做的不够多。我认为对于rails开发来说，理想情况2个小时就应该进行switch。更频繁的Switch能够使得知识传播的更快，尤其是在团队中不是所有人都对Rails开发熟悉的情况下。由于做的还不够好，出现了有的pair工作在一张卡上太多时间的情况，原因是俩人对这块都不够熟悉，如果早点switch就好了。

由于Rails开发中一些scaffold的存在，几个相关的CRUD的story可能一下子就全好了。这对写Story提出了更多的要求。要精确掌握粒度不太容易

Rails和Textmate的中文支持还有待提高。看哪位神仙有空，给contribute一些plugin啦、月光宝盒什么的。

总之，如何更好的交流和协作是我们这次Code Jam学到的知识之一。Rails开发的效率极高，这对开发过程和开发团队就有了更多交流协作的要求。大家必须要通力协作：多提交和更新才能最快的把代码整合在一起；多交流才能保证不会有架构和数据迁移的冲突；多和BA/QA交流才能不走错路做错功能；多更换pair才能学到更多的技能技巧，保障对系统的了解程度；多和用户交流才能确保需求不会迷失方向。

周六晚上5点半showcase的时候，1优先级的功能差不多都出来了，可以大致预测到第二天的成果。可惜由于周日我下午又赶飞机，没能看到最后交付的场面，非常遗憾。

演讲技巧（下）

2008-03-30T10:47:00.000-07:00

查看：演讲技巧（上）

PPT的制作

多数情况下一个好的PPT能够给听众带来愉悦的心情和清晰的思路。在做PPT的时候，我第一件要考虑的事情是模板的选择。有人说内容第一，最后在做样式。其实不然，如果一开始不选好，中间的配图、字体、高亮颜色等最后还得返工。

选择模板需要考虑使用的场合。一般的黑白深蓝底色都是比较安全的。有人喜欢把屏幕弄亮点让底下观众不会因为背景暗而昏昏欲睡。我最近喜欢用黑色，看起来更酷更时尚一点。如果演示稿是关于公司或者代表公司，公司Logo一定要放在上面（其实一般公司都会有统一的模板）。如果是给客户做演示，客户的Logo也不应该忘掉。

PPT多数时候需要一个Agenda来开头，让用户知道你今天的议程是什么。后面不时的可以重复展示这个Agenda来提示客户你说道了哪里。不过这点并不是必须的。有的时候一场报告只有一个主题，例如我前次做的校园招聘的宣讲，是关于Business Analyst的。我就没用Agenda而口头说明的。

Less is More

最近经常听到Less Is More这句话。当制作PPT时，大忌是把所有的文字都堆在幻灯片中，在演示时读屏幕。这样是最枯燥的。最近流行一种模板，就是多数页只有一句话，放在屏幕中间，据称叫做PPT 2.0模板。这种的模板很有看头，每页一句话，剩下的要靠嘴说。每页一张图片，后面的故事也要娓娓道来。只有演讲者说服了听众，幻灯才能达到效果。让观众读懂算什么。

幻灯片设计中的颜色也不宜太多，而且应保持一致，例如所有的图片边框都是2pt的白色，而不要每页不同。如果使用Office2007，里面会有些color scheme，大概有几种配色供使用，都还不错。

在商业演讲中，幻灯片的字体应当用普通的字体，例如Arial, Tahoma, Calibri等常用字体，这样显得朴实大方。不要用Comic等儿童的、奇幻的、趣味的字体。

要白板还是PPT？

我们有时候常有争论，就是是否要准备PPT还是只用白板就好。我们以前总结过敏捷培训宣言，里面就说白板和卡片胜过幻灯片，但这并不是绝对的。一个准备良好的PPT绝对能够发挥很大作用。

白板的弱点就是字体不好控制，后面容易看不清；无法展示图片；但白板的好处在于可以动态的和递进的讲出问题，可以在白板上留下推理过程和历史记录，并且可以根据听众的反应，随时转换话题或者引出新的内容。

而PPT在准备的时候必须要遵循一个套路，很难跳出。所以讲PPT的时候必须要考虑周全，如果听众问问题打断了讲解思路就非常麻烦了。因此很多讲PPT的人都要求客户最后提问:P

如何缓解紧张情绪？

每个人演讲都不可避免的会紧张。我第一次给公司内部讲东西就紧张的不行。后来在内部习惯了，第一次给客户讲又紧张。再后来客户面前20人不紧张了，到上50-80人的时候又会紧张。不过解决这种紧张情绪很容易，就是多讲。讲多了，见得人和事面多了，自然不会紧张。我现在面对小场面那是相当的不紧张，大场面不敢说啊，要让我上人民大会堂讲，估计还是得腿软。

当紧张袭来时，每个人的反映不同。我以前是可能会有点发抖，现在不发抖了，在开场2-5分钟时候有些喘不上来气，心跳的厉害，思路也不太连贯。这时候最重要的是要镇静，抓住时机吸几口气，把语速降慢，适当增加停顿，让自己缓解过来。

有的人紧张起来比较奇怪。徐昊一直跟我说，他是后紧张类型的：下场后10分钟抖个不停。。。。我说，你这是讲东西发泄后爽的吧。

如何练习演讲

演讲能力的提高主要靠练。练表达能力，练逻辑能力，练在人前说话不怯场，一定要克服自己怕说话怕在公共场合发言的心里。要锻炼演讲，可以先在公司内部搞内部交流时讲，反正都是自己人不怕丢人；然后可以到Beijing Open Party等社区活动来参加技术社区交流，面对陌生人来讲；接下来是在客户现场承受压力的讲；最后就可以考虑到几百人的大会上露脸了。

Mo Li@2022

Software Project Estimation And Biases

The Estimation Process

Cognitive Biases Impact Estimation

Approaches To Reduce The Biases

Simple Approaches

Linear Regression Bootstrapping

Monte Carlo Simulation

REFERENCE

The FANCY Approach for User Story Analysis

Analysis – the missing step

The Analysis 101 – the FANCY approach

F - Functional requirements

A - Assumptions

N - Non-functional requirements

C - Constraints

Y - Wireframes

Summary

敏捷转型实施方法框架

敏捷方法的价值观体系

组织或团队进行敏捷实施的常见问题

敏捷软件开发方法的历史和现状

the FANCY Approach for User Story Analysis

Online Whiteboard Tool

Millet congee soup

关于思考能力与解决问题的能力

2011年总结

Blog搬家

南加州的灿烂阳光

《博客三人行》25期:敏捷中国2009大会

Agile Methods - From knowing why to knowing how

也谈电话银行的交互设计

严重实用技巧：Word2003中修改尾注位置

请赞同，而不说“不是” － 关于交流和反馈

关于交流

关于反馈和提建议

架设一个BLOG需要整合多少东西？

QCon Beijing归来感想及总结

新BA上甲板指南 - New BA on board guidelines

敏捷过程中的需求分析实践

自定义Mac OSX快捷键

Beijing Code Jam - 2 days agile development project

演讲技巧（下）

请赞同，而不说“不是” －关于交流和反馈