敏捷开发之初接触

2019独角兽企业重金招聘Python工程师标准>>>

什么是敏捷开发？

     敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程（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

转载于:https://my.oschina.net/myrainspace/blog/792801