2012-11-28：
今天晚上下班回家后，用3个小时系统的把一些对敏捷持正反两方面的博文看了一遍，零零碎碎的整理了一些自己的想法。
客观的说，我在一个敏捷团队里呆过半年的时间。当时的教练也是从TW中国请来的，算是对敏捷有一个相对比较全面的认识了。但是由于当时主要做QA工作，TDD以及结对等开发实践并不是很充分，总体认识上对于敏捷提升开发效率的观点是有很大的质疑的。
主要原因：
- 团队在使用了敏捷开发过程后，在每7个工作日一个迭代过程中依然有持续不断的有很多低级的错误；
- 单元测试用例爆炸式增长，随之而来维护的负担非常大，结果可想而知。
敏捷的很多思想我是非常认同的，但是具体的实践方法是否应该教条化，就需要严格的区分了？业界最多的问题是：真敏捷还是假敏捷？
这个问题很难求同存异，但毋庸置疑的是如何高效的做出高质量的产品是我们共同的目标。
本周末准备花时间把自己的思路整理下，写一篇博文，太晚了，休息啦。希望做一个夜猫子程序员，但是身体还很重要的。
问题和思考列表：
1.
应理解每日立会、计划会、评审会、反思会这些会议，都只是沟通过程的仪式化的补充，若沟通本身不畅，而只是指望这些会议完成沟通，肯定会陷入两难的境地。
6.
最佳的软件开发团队应该是什么氛围？
（1）管理者角色弱化，成员共同成长，共同实现团体价值和自我价值
（2）良性的竞争机制
（3）成员具有高度责任感和成就感
7.
敏捷团队中弱化开发和测试的角色方法？
（1）无差别Title， 统一称呼：软件开发工程师，软件测试也是开发的重要组成部分；
（2）角色互换：周期性更换角色，增强开发和测试双方面的技能；
（3）鼓励角色间结对和讨论：开发和测试角色之间共同完成一项任务。
8.
角色互换是否会给项目增加风险？
在一个团队合作融洽和目标统一的团队这个问题应该不会存在，而且项目中多能型人才的培养对于团队的健康度非常重要。
角色互换的另一个时机是：各人完成高质量完成自己的任务，然后拼命的去帮助别人。
9.
敏捷实践中如何减少时间浪费？
不成熟的敏捷团队效率低下的一个重要原因是受限于规则而浪费大量的时间，而这些浪费的时间竟然是为了所谓的沟通。
敏捷中真正的沟通不是在开会中完成的，诸如以下注意事项：
（1）诸如每日例会、回顾会、计划会必须有明确的议题和目标，培养在规定时间内完成沟通的习惯。
（2）技术问题应该小组内讨论并明确问题后，再作为议题在相关人员范围内开会讨论，避免浪费非相关人员的时间。
（3）故事描述必须清晰，避免不必要的混淆。
（4）不要把所有得讨论机会都安排在会议内，真正的讨论和沟通时在会议以外完成的。
（5）培养沟通和讨论技巧，提高工作相关的沟通效率。
10.
影响力是将有价值的思想传递给团队、客户，更多人乃至社会。
将影响力作为一个重要的指标考虑团队成员:
- 能够被正确的思想影响？（这个洗脑式的培训是完全不同的，现在很多敏捷推广搞的像传销一样，敏捷的推广要根据不同行业和产品的差异性，用实际的工程实践证明其有效性。）
- 主动学习新技术？
- 经常向团队提供本职工作外的帮助？
- 愿意向团队分享新技术新思想？
- Session 能力很强？
11.
认同的价值和作用？
敏捷团队的成功取决于大家对于敏捷的认同，即对敏捷价值观的认同。
如果团队大多数人没有接受敏捷思想的价值观，仅仅是在过程和实践上实行敏捷，团队注定正走在一条失败的路上。
12.
敏捷团队欢迎女性：
有数据表明女性在沟通能力、人际交往、耐心、细心等方面明显高于男性，而这些特质在以敏捷为代表的现代软件开发中直观重要。
13.
无私的团队能够培养无私的员工，能够吸引更多优秀的员工，而且成功的概率更高。
14.
在中国实行敏捷，首先必须克服中国传统的官本位思想。
15.
鼓励团队成员读书并分享，分享是激发创新的最佳途径。
16.
鼓励辩论且不仅限于技术。辩论是正向刺激大脑思考和锻炼思维的好方法。
每周开始第一天往往精力不是太集中，可以通过安排一场技术辩论的将大家的思维调动起来。
每周最后一个小时可以组队安排一个非技术议题辩论，不但可以增强团队建设，还可以放松一周工作的紧张情绪。
17.
注意信任的重要性：
团队凝聚力不是体现在融洽度上，而是在相互对彼此的信任度上。
团队成员之间的信任并非在于个人情感上，而是体现在工作上彼此之间的理解和无条件的支持。
（理想状态下，既是两个人之间个人情感上有冲突，但是对于工作上仍然百分百的信任和支持）
在培养并形成团队充分信任之前，必须由大家一起制定团队的行为准则和价值基础。
例如：在共同目标（高质量的软件和客户价值）的前提下，鼓励善意的提醒，不提倡奉承，不允许团队内部的小利益体等。
18.
测试人员和开发人员的关系处理：
测试人员方面，对于一个表象问题，即使只有50%的可能性是研发问题，不成熟的测试人员一般也会100%的确认是问题，并且在情感上和沟通语言上处于上风。
研发人员方面，对于同样的疑似bug，研发人员往往以代码最近未改动或者前一个版本没问题为借口，先排除自己的责任，然后自然和测试人员之间开始例行的拉锯。
对于这样的问题，必须消除各自的考核机制对于双方抵触情绪的影响，如果条件允许，组建测试开发融合的团队，以交付的质量作为对团队的考核。
其次，建议首先从测试人员角度改善沟通，对于非确定性问题，应该以温和的方式确定其原因，减少由于误报导致彼此之间信任度问题。
最好，开发必须建立完善的构建流程，及质量保证机制，确保每天新增代码的质量。
19.
敏捷测试中自动化测试应该和探索性测试结合。
并且任务划分时必须考虑测试需要的时间和节奏，如果特殊情况下迭代内不能完成本迭代故事的验证，可以推迟到下个迭代，但是需要在本迭代明确测试用例准备及计划完成时间点。在进行了必要功能和部分探索性测试情况下，也可以提交演示，但是未充分测试的故事不应视为完成。
20.
盖洛普优势识别器
推荐使用这个心理学上普遍任何的一种测试方法，测试团队内个人的优势，根据优势来安排工作。亦或者在选择团队的时候也可以采用这个测试作为一个非决定性的参考。
21.
22.
代码走查
代码走查的必要性不必讲，这里只说明一下代码走查的时机。
新代码：每天下午下班前，必须把当天完成的代码进行必要的走查，最好是结合了测试程序。当然功能不完整的代码，开发人员一般不太愿意让别人走查，毕竟容易出丑。但是这里我要说一下，对功能未完善的代码走查，更有必要，结合了结对编程和头脑风暴的功效，对开发效率和错误率有重要的作用。
对于每天下午的代码走查，没有人是完美的，是时候放下面子的时候了，呵呵
此外，代码走查不应该是一锤子买卖，应该像复习单词一样，周期性的走查。根据个人经验，百行新代码一周内走查两次，半个月后再结合其所属模块再走查1-2次。
代码走查如果掌握正确的方法，找到乐趣，不仅可以提高代码质量，对于团队建设是有非常有利的作用。
24.
团队人员构成：
1434
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
