敏捷实践——个人总结

      过去一年的工作主要是特性开发和交付，公司有自己的一套迭代流程，大体上也基本符合敏捷原则，下面以敏捷宣言为大纲分享个人的经历和思考。
个体和交互胜过工程和工具
       ——一个优秀的团队成员可能是一个平均水平的程序员，但是却能够很好地和他人合作。
       在没进入部门前一直认为公司的法宝就是一系列的流程和独立开发并运营的各种工具。确实公司的那几套P流程在业界甚至整个制造业都是大名鼎鼎的，开发中使用的各种工具也是非常强大（尽管天天被大家吐槽，然而并不能否认其非常强大）。一套由知名大牛为公司量身订造的开发流程作为版本迭代的指引，配套对立开发和维护的各种工具和技术，足以保证版本能够顺利地推进（起码我来以前是这样认为的）。然而在参与了三个版本的迭代后，你会发现团队里每一个人都被培养成了讨论（扯淡）高手。特性澄清拉个会议吧，PO验收拉个会议吧，解决方案拉个会议吧，测试找开发看问题也拉个会议吧。别发邮件和留言了，大家不会看的（除非抄送高层，这是大招不要随便用），直接拉个会议把事情说清楚。没有问题是一个电话会议解决不了的，如果有，拉一个面对面的会议！
       在这里，你可能不是一个编程高手，但是你绝对是一个沟通的高手。为此甚至还发明了一种沟通游戏。。。
可以工作的软件胜过面面俱到的文档
       ——知道迫切需要并且意义重大时，才来编制文档。
       我们也写资料，我们最讨厌写资料，因为很有可能（99%的几率）你写了一天的资料在最后一个评审人处被打回修改。所以我们倾向于先把特性写完转测试，提个资料单把资料补上。我们写的资料仅限于用户手册，特性设计文档SE已经写好了（你也别指望能有多详细，顶多就是一个概要设计）。想要细设计文档吗，对不起没有。遇到以前写的特性问题怎么办？看代码啊。代码上面不是有注释吗，代码是按规范编写的，上库前由领域成员检视，代码合入的权限在领域MDE处。写的代码不一定非得多么的优雅，但是一定能被人看懂，否则怎么代替文档（没法上库）？
客户合作胜过合同谈判
       ——让软件的客户和开发团队紧密地在一起工作，并尽量经常地提供反馈。
      这里要明确客户的定义，到底谁是客户。公司明确下一道工序就是客户。所以测试才是开发的大爷！会议纪要只是用来分清责任归属的，测试认同了才是王道！我的工作时间有70%是和测试一起度过的，虽然他们坐在我的楼下，但是我们的通讯工具一直是开着的。测试发现问题首先找开发确认，这也是开发一直以来的槽点，请保证我的核心开发时间！
响应变化胜过遵循计划
       ——较好的计划策略是：为下两周做详细计划，为下三个月做粗略计划，再以后就做极为粗糙的计划。
       这应该是用来欺骗程序员的原则，因为开发会被这个原则折磨死。到了版本的后面两个迭代，一方面大部分的人力已经抽调到了新的版本上去了，留守在本版本到GA的可能只有一两个人。这时候一方面需要有问题接口保证版本顺利过点，一方面还不断地有新的特性涌入，甚至还有各种为下个版本预埋和给维护做试验的大特性和难度特性。时间紧，任务中还要保证顺利过点。当我跟第一版本GA时，我觉得简直是快要被逼疯掉。幸好并不是每个版本都是同一个人留守，然而我提说维护团队要面临的压力是在研团队无法比拟的，而且我们将来也会需要到维护团队去锻炼一番。。。
       本来想总结下经验的，结果变成了吐槽，后面有时间再梳理一下迭代开发的流程吧，虽然都是嘈点，但是还是挺实用的。