本文目录导航：
Scrum矫捷开发那些会议 之一 「站会」
Scrum作为矫捷开发的一种较为盛行的框架，引入了一些活期召开的团队会议，本意是增进团队的沟通以及提高上班效率。
本系列将会引见一些会议的通常技巧，防止让这些会议对团队形成困扰（尤其是防止程序员感觉散会好多好烦...）。
本文作为系列的开局，会引见Scrum最关键的、以及最被人熟知的通常之一，站会（Daily Stand-up）。
站会听下来很便捷，就是让团队成员都站在一同、每天例行召开、相互沟通上班状况。
但在实践操作环节中，很多团队往往没能提高效率，步入误区。
站会——Daily Stand-up meeting，作为一个每日召开的例会，它最基本的目标还是在于提高团队的顺应性。
站会中团队应用10-15分钟的期间，轮番替换上班进展及上班中遇到的阻碍。
经过这样固定的沟通，提高上班的透明度，来保障Sprint（冲刺）的反常交付，防止团队成员之间消息不平等的状况，也能缩小其余不用要的会议。
高效的站会不只能增强团队协作的才干，而且可以应用团队的配合，使之极速应变，可以说是到达“矫捷”的必修之路。
由于站久了容易累，就这么便捷。
为了保障例会的高效性、不糜费期间在闲谈上，例会就要站着开。
而且是一切人都站着，最好找一间没有椅子的会议室或许一块空地，靠墙、靠桌子站也不行，别偷懒。
站着也能协助优化专一力，而更快的会议节拍也能防止开小差的状况。
站会的时刻其实每个成员只要要讲分明三个疑问即可：
确保你所说的内容对一切与会人员都有价值，这很关键，由于假设只对一两团体有价值，那这些内容齐全可以私底下交流。
每个疑问只要要一两句话概括，可以说一下目前在做什么义务，以及义务的进展状况。
不须要讲到十分细的细节，假设有必要，那就在站会之后再拉上关系人员深化探讨。
有的团队习气在黄昏开站会，而有的习气在早晨上班开局前，这都不要紧，关键的是养成 习气 。
把站会固定在每天的同一个期间点召开，象征着每个成员都须要在心里预留出这一段期间。
而不至于没有提早做预备或是忘了加入，那不只耽误了自己的期间，也耽误了整个团队的期间。
最后要强调一点，站会不是在汇报上班。
很多团队或许是间断传统形式的汇报习气，站会时，一切人都是对着Scrum Master或小组长启动上班汇报，这就与站会的初衷南辕北辙了。
站会是一个相互交流、替换消息的环节，假设变成汇报上班，一切的消息最终还是集中在一团体或少数人身上，这关于提高效率和透明度齐全没有协助。
一朝一夕也没有人关心他人在说什么，由于反正那不是对着自己说的。
矫捷开发强调 自组织 的团队，介绍扁平化治理。
消息集中化会造成的决策集中化，这都不是矫捷开发想要的结果。
不只矫捷开发是一种继续改良的环节，始终尝试更好的治理形式也是。
成熟的团队的站会不只高效，有些甚至会很无心思，这在于团队间始终的磨合和生长，也依赖于Scrum Master能否能在期间的推移中继续地开掘团队的后劲。
欢迎留言谈谈你们团队的站会是怎样开的，有没有什么感觉可以改良的中央呢？
矫捷开发之LESS
LeSS是一个轻量级的矫捷框架，用于将Scrum裁减到多个团队。
“LeSS is Scrum applied to many teams working together on one product.”便捷说LeSS依然是Scrum，依然是那三个角色，三个工件，五个会议。
LeSS框架想要处置的疑问是如何将Scrum的准则，元素尽或许便捷够用的经常使用到多个团队，协作开发一个产品的场景里去。
LeSS建设在 阅历主义 ， 跨职能自我治理团队 等 Scrum准则 之上，并提供了一个大规模运行该框架的框架。
它提供了无关如何在大规模产品开发环境中驳回Scrum的便捷结构规定，指南和试验。
LeSS只要几个规定和两个框架：LeSS和LeSS Huge。
LeSS框架开发团队的数量从两个到八个不等。
一个产品担任人最多担任八个团队，每个Scrum治理员最多可以服务三个团队 LeSS倡导每一个矫捷团队由8名团队成组成，而后由多个矫捷团队组成一个大型的矫捷名目。
。
在LeSS中，冲刺开局时有2个冲刺方案会，第一个冲刺方案会中由各团队派人加入探讨和治理彼此间的依赖及协作上班。
第二个冲刺是Scrum矫捷团队的冲刺。
在冲刺完结时有2个回忆会，一个是矫捷团队外部的回忆会，一个是整个大型矫捷名目标回忆会。
另外LeSS引入了域产品担任人（APO， area product owner）来治理跨团队的用户需求。
矫捷开发流程中测试上班各阶段的内容有哪些
1、story廓清会议（即需求廓清），介入人员：开发人员、资料开发人员、测试人员、TSE、需求接口人等。
目标望文生义就是让一切介入名目标人员更深化的了解需求，会议上马何介入者都可以宣布不懂，对不了解的中央要及时问分明，通常证实这个会议能尽早的发现开发人员遗漏掉的配置点以及配置成功的形式对其余模块的影响等。
这个阶段开发输入的文档有：story验收规范。
普通状况下关于配置复杂的模块，为了让大家跟直观的了解配置点，普通开发人员会预备demo展示，这样也更无利于测试人员测试用例的输入。
2、测试人员依据需求廓清时了解的需求点编写测试方案，而后输入用例，成功后发给开发人员、TSE对用例启动评审，编写人员依据检视意见修正用例，直到大家都认可了，再导入用例治理工具TMSS。
3、迭代story转测试之前，测试人员须要向开发人员分一局部基本配置的用例验证，用例经事先才可以转测试。
转测试附带的文档包含：代码检视确认报告、测试部提供用例的口头结果报告、开发自测用例样例参考等。
4、测试人员口头测试，口头用例---提交bug---回归疑问---story评估---封锁story 5、迭代完结，回归会议，开发测试人员一同启动此次迭代版本的优缺陷剖析等。
