敏捷开发笔记整理

敏捷开发宣言：
1.个体和交互胜过过程和工具
2.可工作的软件胜过面面俱到的文档
3.客户协作胜过合同谈判
4. 响应变化胜过遵循计划,从上面的宣言可以看出，敏捷开发的核心是人 、协作、时刻可运行的软件、变化。
敏捷宣言》背后的12准则
我们遵循以下准则：
1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4、项目过程中，业务人员与开发人员必须在一起工作。
5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7、可用的软件是衡量进度的主要指标。
8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9、对技术的精益求精以及对设计的不断完善将提升敏捷性。
10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11、最佳的架构、需求和设计出自于自组织的团队。
12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
如果用一段话来简单明了的描述一下SCRUM，应该是这样的：
1、我们需要把人进行分割，所以我们建议会组建一些小的团队，人数最好是在3-7人。
2、我们需要把任务切小，拆分成故事卡。
3、团队在一个sprint周期内权利冲刺去完成计划的故事卡。
4、做持续集成去从整体上把握任务的完成情况和风险。
相比较而言，看板的具体实践就没有那么多的限制，看板主要强调以下几个方面：
1、流程的可视化。
2、限制并发。（在制品的数量）
3、优化交互时间。
相对于一个需要转型的团队来讲，SCRUM是相对比较激进一些的，因为这个框架告诉了你说SCRUM需要在迭代周期内开几个会，且时间盒（迭代周期）内完成的故事卡尽可能在开了计划会承诺交互会，就在迭代周期内完成（否则团队响应变化的能力就会变弱），且迭代周期内要完成的事，在这一个迭代周期就尽可能保持不变，以免引发一起不必要的浪费。而看板是一个比较渐进式的变革，它一开始的时候可能没有那么多的条条框框，是一个更加轻量级的方法，但真正在现实的应用中，想要把看板方法实践得很好，反而是比SCRUM更加困难的一件事情。
下面就着重的讲一下SCRUM相关的一些知识：
从整体上来讲，SCRUM这个框架里面包含了这几个核心的要素：
1、3个角色：SM、PO、开发团队（自然包括了我们的开发人员和QA）。
2、3个产出物：Product Backlog、Sprint Backlog、交互的可用软件工件。
3、5个活动：计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理（发生在整个SCRUM周期的任何时间）。每一个会议都有自己的时间盒，其长短在SCRUM中都有比较明确的建议。当你召开某一个会议的时候，超出了这个时间盒或者召开某个会议的时候出现一些问题，也是一种有问题的信号。一个团队在冲刺的周期内，去充分的暴露问题，然后在回顾会上去分析问题，再进行改进。在每日立会上比较强调的是，根据昨天完成的情况来做出新的调整，我们每日立会上所描述的，一定是对有助于完成当前sprint目标的事情。同时，特别需要强调的是，在sprint评审会上，团队除了对当前sprint完成的故事进行show case还需要对剩余的任务卡进行梳理，可以让团队有机会去回顾和识别版本发布的风险。
4、5个价值观：公开、专注、勇气、承诺、尊重。
另外，还讲到了SCRUM最重要的时间盒，这个是我之前所理解的SCRUM里面，没有发现它竟然是如此重要的。还学到一个新的理论：番茄工作法是一个人的SCRUM，SCRUM是一群人的番茄工作法；理解到跨职能是团队层面的概念，而一专多能是每个团队成员层面的概念。现在回过头来看，发现曾经团队在尝试SCRUM的过程中，对有些方面是理解得不够的，包括为什么最终团队放弃了SCRUM转向看板，其缘由也不完全是曾经以为的迭代周期的问题，需要系统的来看待这个问题。不管一套理论是如何的完善，结合到实际的工作中的时候总会遇到这样和那样的问题，但抓住最本质的东西才是最重要的，抓住其精髓的部分，然后再加以灵活应用，以问题为出发点，能够真正的解决实际的问题才能给大家带来信心。
最后，分享一下SM的一些相关知识：
一、SM应该在团队承担的几种角色：
1、引导者，就像一个出租车司机，需要去哪儿，是由团队来决定的，作为引导者，带领团队到达他们想去的地方。引导团队建立团队规则，维护团队和指导团队外部成员遵守团队的规则。作为引导者需要特别注意的是，不能把自己的价值观强加于团队，让团队成员尽量表述自己的意见。
相信大众智慧—得到“最佳方案”
相信大众参与—得到“最佳执行力”
2、教练：指导团队和PO遵循SCRUM的价值观。教练作为一面镜子，在每日立会和回顾会等会议上，只陈述事实，在日常工作中尽量多去收集一些数据，通过陈述事实和提问让团队去思考，通过这种方式让问题的解决达成一致。（如果当前的陈述让团队意识不到问题的存在，那么建议继续守望，继续收集数据，再陈述事实，通过反射让团队去发现问题）
3、移除团队障碍。
二、SM的几个发展方向：
1、敏捷/教练：推荐《敏捷开发的艺术》和《用户故事与敏捷方法》。
2、技术（CI、TDD、重构等）：最重要是去做周计划，去与别人结对或者做练习。
3、业务（PO）：帮助团队的PO去切分故事，推荐《精益创业》和《用户故事与敏捷方法》。同时，建议QQ邮箱PO的千百十工作法：得到1千个用户反馈，选一百客户进行沟通，再从中选择10个沟通结果作为下一个迭代的故事。这样做，既有广度也有深度，能够持续不断地保证团队做对用户最后价值的事情。
4、转型：从A----B点，往往SM需要考虑，不止一种方法，需要多种方法，灵活运用。
5、教练：推荐《敏捷教练》，这一项要坚持实践PDCA，做周计划，比如：回顾会、心情曲线、跨团队指导等实践活动。
6、导师。
7、引导。
8、演讲。
后三者都是属于纯实践型的活动，需要多演练。大家可以基于目前的现状对上述8个维度进行一个打分，形成当前的雷达图，然后再做短中期计划，三个月后再去绘制新的雷达图，每一个短周期内，建议是集中精力对某一项进行实践和提高。做周计划是一个非常好的实践技巧，比如：阅读一本书，可以精细到每周阅读多少页。这样比起做月度计划，会让你的可操作性和跟踪性，能有更短的一个反馈周期，更容易实践下来。
如何让敏捷落到实处，下面是我理解的敏捷。
小功能点代码设计，以及小的功能点的代码开发，开发自测。
小的功能点测试设计，测试开发，测试执行。
敏捷包含结对编程，结对测试，结对工作。
包括测试设计时交叉执行，交叉设计，交叉评审。
保证分组开发过程中，各组工作对接上，所以各小组一起开发，统一意见。
持续部署。
测试驱动开发。先写测试用例，在开发功能代码之前。
鼓励项目开发着，QA，非技术人员之间的协作，包括验收测试和客户测试驱动。
持续集成。