迷失之敏捷
传统的“需求-设计-编码-测试”这种一步一步的瀑布模型暴露了越来越多的弱点；大量的项目实践都证明这种模式存在...
传统的“需求-设计-编码-测试”这种一步一步的瀑布模型暴露了越来越多的弱点；大量的项目实践都证明这种模式存在着资源浪费、低效与不可取；越来越多的开发团队都走向了从传统瀑布转向了敏捷；也包括我们。
敏捷带来了超短的响应周期；
实际中，每个Sprint从接收需求、制定SBL、开发测试、发布版本整个过程周期也就是4~6周；
敏捷带来精准的实现，与质量保障；
2015年，NM和DCS两个平台共经历14个Sprint周期，完成447个用户故事，发版后的用户故事变更数为6，流出Bug数为5，变更率与缺陷率仅仅1%左右；
在经历了数不清的Sprint迭代周期后，我们的团队越发适应了这种快速迭代的开发模式，关于敏捷，我给大家分享一下我们组在敏捷之路上曾经的迷失与坎坷。
迷失1：“可以工作的软件高于面面俱到的文档”
首先，从始至终，我都认可这句话。然而实际中，我们经常过分的聚焦于更有价值的“左项”而忽略了“右项”；
以前，文档不好，没有权威性，大家就更不愿意看，不愿意维护，然后文档就更弱，更没权威性，于是一个怪圈就产生了，文档越来越不好，我们越来越依赖于代码。
功能做多了，靠脑袋就记不住每个细节了，导致了漏洞、分析不足、流出问题。
后来，我们意识到这个问题，开始遇到问题就补，就改；对问题分析报告整理归档；分析一些模型升级呀之类的分析表格，避免分析时光靠拍脑袋；再后来ASPICE、TS介入，逼着我们把文档做的就更加完善。
简单举个例子，之前我们每开发一个功能，测试就要开发一套用例来测试，后来我们把整个平台功能Map到一个个UC，每个UC与测试用例建立追溯，当需要测试哪个功能时直接调出历史的测试用例执行即可。文档的最大好处就是把你的智慧火花存起来，可以分享给别人或以后复用，就像开发一个可复用的模块一样。如果没有文档，智慧的火花早晚都要熄灭。
总之，敏捷中建立一套极其简约而又有效的文档体系作为支撑是必要的，但它一定及其简约并与实际情况及其贴合。（和ASPICE要求的体系比，敏捷的文档体系应该像一套随身的运动装；ASPICE要求的就是一套体面的西服）
迷失2：“响应变化高于遵循计划”
相信大部分开发人员都非常讨厌做到半截变需求，我也讨厌，变更总是带来风险、工作量、成本、不确定性不说，最不能接受的是它对前面的付出是一种极大的浪费。
实际中，为了避免变化发生，我们会尽可能的在前期把需求说清楚，一定要叫上全部的有利害关系的人或部门。因为两个部们的出发点不同，可能要求是有冲突的，尤其是新要素的增加，要考虑生产与工艺是否冲突。另外，也要考虑用户的后续计划的，要与他们的节拍一致，例如，我们的程序加密发布时间、提取、导入都要与用户步调高度一致，尤其处于模型升级的时候，一个地方考虑欠缺就可能导致后面的修改、变更。
因此，我认为敏捷中，我们仍要极力避免变化，但是，由于客观原因变化来临之时，我们要通盘考虑实现变化的价值与项目的风险进行权衡，并对计划进行调整；我们不能因为是敏捷就放任变化，也不能拘泥于既有计划，将其当成一定要遵循的铁律。
迷失3 “个体交互高于过程与工具”
敏捷强调“面对面沟通”非常重要，我也是非常推崇面对面沟通的。因为我认为写的再好的邮件、文档都会有偏差，面对面的交流正好弥补了邮件、文档的不足。
但如果光有面对面的交流，就会导致交流的信息缺少一个载体，不便于分享与继承，而且很容易遗失、忘记；讨论的时候大家都很明白，可过后细节谁也说不清楚的情况太多、太多了。
外部沟通上，我们做的是比较到位的，每次需求评审都会维护相应的文档；每个Sprint阶段与用户除了面对面的沟通，都会有PBL的发布、确认。每次产品发布都有Demo演示与验收签字。这就避免了程序发下去后的不认账、扯皮现象。
内部沟通上，还有欠缺，尤其是技术上的沟通基本都是两个人的火花，后面我希望组织更多的有文档介质支撑的技术交流与分享；组织大家把自己的擅长的技能讲出来、写出来。在分享的同时还能提高大家的听、说、读、写能力。
因此，我认为，交互，沟通是以最高效的方式分享最有价值的信息为目标的，面对面沟通的内容，对有价值的信息增加一些邮件或文档之类的载体，便可以更方便的分享、传播、继承与积累会让沟通变得更加有效，更有价值。
迷失4 “客户合作高于合同谈判”
我认为，和用户保持良好的合作关系、以及沟通交流是必要的，在项目中我们不仅要与用户仅仅建立合同中的甲方与乙方的关系，而是要成为利益共同体。我们会站在用户的立场去审视用户遇到的问题，用我们的专业去帮助用户解决问题。
但与用户的合作，沟通保留必要的证据与契约是必要的，因为现实中，有时候并不是谁有意刁难谁，而是有时用户自己也忘记了当初的约定，而在后面形成分歧、扯皮的情况，这种情况一旦发生就会伤及双方的利益。因此必要的契约（不限于合同）是非常必要的（尤其是在关键的节点上），不能因为关系好，交流顺畅就忽略了。
实际中，我们面对的都是内部客户，不涉及到合同，但我们主要将邮件作为与用户的契约；前面已经说过，我们会在每个Sprint都会发布PBL，并且组织Demo演示与用户各个功能的验收签字，这些都是确保双方利益的措施。
总结：我认为敏捷的核心价值观就是追求要以最简单的方式、最低的代价，并且以最快的速度实现最大的价值！可以说敏捷就是以人、以价值为核心的实用主义。
最后，就以著名的敏捷宣言的12条原则作为结束语，与君共勉！
我们遵循以下原则：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
关注 四维研发Family
微信扫一扫关注公众号
