敏捷开发之初接触

什么是敏捷开发？

     敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。在全球一百强的企业中，敏捷开发也已大行其道，受到许多资深项目管理者和开发人员的推崇。到2008年，欧美软件企业中，有近半企业已采用敏捷方法进行开发。中国的外企，外包公司和许多知名企业也都开始采用了敏捷方法。例如，腾讯内部几乎全部的开发团队都在实施敏捷。敏捷方法给这些企业也已带来了巨大的收益。

    全部符合敏捷价值观和原则的开发方法都具备如下共同特征：

    1. 迭代式开发。即整个开发过程被分为几个迭代周期，每一个迭代周期是一个定长或不定长的时间块每一个迭代周期持续的时间通常较短，一般为一到六周。

    2. 增量交付。产品是在每一个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是能够被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推进产品开发。敏捷开发方法主张用户可以全程参与到整个开发过程当中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。

    4. 持续集成。新的功能或需求变化老是尽量频繁地被整合到产品中。一些项目是在每一个迭代周期结束的时候集成， 有些项目则天天都在这么作。

    5. 开发团队自我管理。拥有一个积极的、自我管理的、具有自由交流风格的开发团队，是每一个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发老是以人为中心创建开发的过程和机制，而非把过程和机制强加给人。

    2001年2月11日到13日，17位软件开发领域的领军人物汇集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。通过两天的讨论，“敏捷”（Agile）这个词为全体参会者所接受，用以归纳一套全新的软件开发价值观。这套价值观核心是如下几点：个体和交互 重于 过程和工具、可用的软件 重于 完备的文档、客户协做 重于 合同谈判、响应变化 重于 遵循计划。在每对比对中，后者并不是全无价值，但咱们更看重前者。

敏捷开发的十二条宣言

    在敏捷开发中，咱们遵循如下的十二条准则：

1. 咱们的最高目标是，经过尽早和持续地交付有价值的软件来知足客户。
2. 欢迎对需求提出变动——即便是在项目开发后期。要善于利用需求变动，帮助客户得到竞争优点。
3. 要不断交付可用的软件，周期从几周到几个月不等，且较短的周期越好。
4. 项目过程当中，业务人员与开发人员必须相互合做，贯穿项目的每一天工做。
5. 要善于激励项目人员，给他们以所须要的环境和支持，并相信他们可以完成任务。
6. 不管是团队内仍是团队间，最有效的沟通方法是面对面的交谈。
7. 可用的软件是衡量进度的主要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该可以保持恒久稳定的进展速度。
9. 对技术的精益求精以及对设计的不断完善将提高敏捷性。
10. 要作到简洁为本，即尽最大可能减小没必要要的工做。这是一门艺术。
11. 最佳的架构、需求和设计出自于自组织的团队。
12. 团队要按期回顾如何可以作到更有效，并相应地优化和调整团队的行为。

用户故事

    用户故事是从用户的角度来描述用户渴望获得的功能。一个好的用户故事包括三个要素：

        1. 角色：谁要使用这个功能。

        2. 活动：须要完成什么样的功能。

        3. 商业价值：为何须要这个功能，这个功能带来什么样的价值。

    用户故事一般按照以下的格式来表达：

        英文： As a , I want to , so that .

        中文：做为一个<角色>, 我想要<活动>, 以便于<商业价值>。

    举例：做为一个“网站管理员”，我想要“统计天天有多少人访问了个人网站”，以便于“个人赞助商了解个人网站会给他们带来什么收益。”须要注意的是用户故事不可以使用技术语言来描述，要使用用户能够理解的业务语言来描述。（说白了就是不要有技术人员的通病，专业术语一大堆，用大白话或者举一个生活中的例子描述最好。）

    关于用户故事，Ron Jeffries用3个C来阐释它：

• 故事卡（Card） – 用户故事通常写在小的记事卡片上。卡片上可能会写上故事的简短描述，工做量估算等。
• 交谈或者描述（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
• 确认或验收条件（Confirmation）- 经过验收测试确认用户故事被正确完成。

    用户故事的六个特性--INVEST

    INVEST == Independent, Negotiable, Valuable, Estimable, Small, Testable。一个好的用户故事应该遵循INVEST原则。

• 独立性（Independent）— 要尽量的让一个用户故事独立于其余的用户故事。用户故事之间的依赖使得制定计划，肯定优先级，工做量估算都变得很困难。一般咱们能够经过组合用户故事和分解用户故事来减小依赖性。
• 可协商性（Negotiable）— 一个用户故事的内容要是能够协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
• 有价值（Valuable）— 每一个故事必须对客户具备价值（不管是用户仍是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并非一个契约并且能够进行协商的时候，他们将很是乐意写下故事。
• 能够估算性（Estimable）—开发团队须要去估计一个用户故事以便肯定优先级，工做量，安排计划。可是让开发者难以估计故事的问题来自：对于领域知识的缺少（这种状况下须要更多的沟通），或者故事太大了（这时须要把故事切分红小些的）。
• 短小（Small）— 一个好的故事在工做量上要尽可能短小，最好不要超过10个理想人/天的工做量,至少要确保的是在一个迭代或Sprint中可以完成。用户故事越大，在安排计划，工做量估算等方面的风险就会越大。
• 可测试性（Testable）—一个用户故事要是能够测试的，以便于确认它是能够完成的。若是一个用户故事不可以测试，那么你就没法知道它何时能够完成。一个不可测试的用户故事例子：软件应该是易于使用的。

参考资料：

 Scrum中文网

Agile Alliance

Scrum Alliance