敏捷开发及一些个人理解

简单的说下敏捷开发的一些知识：

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

个人理解：敏捷开发在我看来并不是没有缺点，它强调自组织，对人的要求太高，实施起来有点难度。现实中，团队的开发人员水平不一，性格不一，追求不一，而敏捷开发对人的要求又非常高，导致很多团队很难真的做到敏捷，我也是只能用敏捷的一些思想和方法，在原来的开发方法进行改进，提高了团队开发效率和质量，但要说是敏捷，严格上我也没实施过敏捷开发。

价值观：

敏捷建模的价值观包括了XP（极限编程）的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。

个人理解：五个价值观，十个字。说起来容易，做起来不易，让团队都有更为不易。不说在工作中，就说做人，能都做到这五个都不容易。

敏捷开发原则：

一、快速迭代

二、让测试人员与开发者参与研讨

三、编写可测试的需求文档

四、多沟通，尽量减少文档

五、做好产品原型

六、及早考虑测试（早点让代码通过测试，也能够早日对代码进行重构）

个人理解：虽然我的开发方法不是敏捷开发，但是让测试人员参与研讨和编写可测试的需求文档是很有必要的。因为专业角度，开发人员和测试人员考虑的点将会不一样，这样能在研讨中发现更多的问题及解决；测试参与了需求研讨，也能更快的出测试用例，测试用例对需求的覆盖率相对也会更高。但原则四，很多人存在着一些误解，尽量减少文档也会变成没有文档。多沟通是指对问题或需求，要多进行沟通；但是沟通，应该有个记录，也可以说是文档，记录沟通问题及结果，这样，这个问题再次向其他人解答或者忘了的时候，就可以用文档来解释说明了，但这要求有文档更新的习惯，如果没有，会可能会造成信息不同步。但也比同一个问题向不同人解释几次好吧，毕竟大家都那么忙。

建模误区：

一、建模就等于写文档

二、从开始阶段就可以考虑到一切

三、建模就意味着需要一个重量级的软件开发过程

四、建模就是浪费时间

五、数据模型就是一起

（其实还有，但是个人不是很理解，就不写了）

开发宣言：

一、个体和交互胜过过程和工具

二、可以工作的软件胜过面面俱到的文档

三、客户合作胜过合同谈判

四、相应变化胜过遵循变化

遵循原则：

一、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

二、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

三、要不断交付可用的软件，周期从几周到几个月不等，且越短越好

四、项目过程中，业务人员与开发人员必须在一起工作。

五、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

六、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

七、可用的软件是衡量进度的主要指标。

八、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

九、对技术的精益求精以及对设计的不断完善将提升敏捷性。

十、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

十一、 最佳的架构、需求和设计出自于自组织的团队。

十二、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

个人理解：虽然遵循原则不少，我们也要根据条件去改变而不是一味的遵循。我觉得，不管是不是敏捷开发，如果能够遵循五、六、九、十、十二。那么对团队也会有能大的提升。五的话不用多少了，刘邦论三杰。六的话需要注意，面对面交谈也需要技巧，找人沟通的时候要看好时机，如果一有问题不经思考或者不看对方状态就问，会影响工作效率；最好询问下对方状态，因为回答一个没空不会太影响问题思路，但是要思考另一个问题并回答，也许自己原本思考的问题思路就没了。九十十二也不需要多说了，除了需要团队成员自觉上进，还要领队人组织带领。

以下是复制一篇博客中的一些话，觉得挺不错的，构建敏捷团队，哪怕只是某几个方面较原来好些，对整个团队也是很大的提升。

构建敏捷团队：

1.团队好奇心，通过分析技术方式，调动团队成员好奇心。

2.团队惯性，或者叫团队文化，作为一个主管，你要设法建立一种机制，让团队从惯性中挣脱出来，办法就是走在前面，让别人愿意跟随。

3.镜子，当你想要改变团队文化，或者某些自我感觉良好的成员，你所要做的事情，就是找出一面镜子，让对方看到自己。

4.从一开始，就要高标准，对团队设置高期望值，团队才会拥有持续改进的动力和愿景。

5.程序员文化，反思自己职业，只有从过去中反思，才能知道下一步怎么做。

6.程序员与建筑工人，是不同的，编译器才是建筑工人，程序员是设计师。

7.代码重构，团队崇尚代码重构

8.让实践落地，即要不断总结，复习

9.权威，有职业赋予的权威，也有专家权威，前提是，要无私，用于说不知道。

10.点燃程序员的激情，即成就感。

11.排除技术障碍，建立和谐舒适的技术环境。

12.功能，以回报率为主

13.让领域模型解耦，降低模块耦合度。

14.做正确的事，即使再正确的做事，做的事不正确，也失去意义。

15.不要沉迷于解决方案，最终要的是用户问题，如何实现，只是你自己的解决方案，用户压根不在乎。

16.每做一件事情，多问为什么。

17.估算的意义，在于揭示大家的理解和所拥有的知识的不一致，而非估计工作量。

18.有些规则，不懂为什么，就照做，有一天，你会懂，懂了再改进。

19.测试有先

20.建立分享环境。

敏捷，不是一种状态，而是一种持续改进的姿态。