【进击的CMMI】程序员不仅仅是打代码的！软件工程过程，码农其实做了啥？

摘要: 工程过程？程序媛or程序猿的你知多少呢。开发时effort花在(=@__@=)哪里？

1新年倒计时le......年味浓之随处可感知。

又周一了，也是农历新年前倒数第二周，这样想着好像一周工作日也没有辣么漫长了呢。年底了，看到很多小伙伴们说最后一周了，没什么工作，就在公司看看书，拉住要飞的心，哈哈。呀，好巧，我也是众多小伙伴们中的一个，是时候总结一下2016于我而言十分重要的一年了。当然，紧扣主题，我自然是会主要focus到软件开发这一部分。

当还是一枚前端开发的时候，起初单纯认为我们最重要的就是打代码，多么肤浅啊（作为一枚电商专业的曾被说不就是开淘宝店的？这种伤害类似吧，只是变成了自我伤害~以为技术牛逼就好了，但码农确实码代码，却绝不是单纯的搬砖！！！）~现在回过头来想一想，代码固然重要，但最重要的实际在于沟通-从弄清需求，确认需求，编程，测试到最终交付，28定律亦适用于此。

说了半天，程序员们在工程过程中该如何有效的让自己少rework呢？相信很多码农的痛苦也在于此。

无论是Agile还是Stage或Waterfall项目，回归本源还是基于Waterfall的SDLC，以最基本的Waterfall开发项目来说，项目有了，说明项目前期research和可行性分析都已做好，小板凳也已准备好，接下来就到程序员们施展拳脚了！

对于不同的项目来说，项目的配置也不同，程序员们扮演的角色自然也相同，相信大家都有类似的体会。现假设项目组人员配置也齐全了，项目经理带领着UI射击狮，开发人员（前端&后台），DBA，BA，测试人员进入到咱们伟大的创造之路。

作为一枚普通的搬砖工人，从BA那里拿到需求文档之后，肯定不是直接按照文档开始开发，而是首先读需求文档，标识与自己理解有差异的点，再和BA（这个时候BA即相当于开发人员的客户，但BA已经将信息过滤好）确认，这时也可能有新的疑问出现，所以一定要等BA给你确认回答（需求开发的过程是将客户的需求开发成产品需求，再将产品需求转化为模块需求，一个不断分析需求并与客户反复确认的过程），给到你自己没有疑问之后再才开始开发，因为这时你才弄清出需求是属于哪个模块，知道如何调用接口来实现对应的功能模块，减少后面因为前期需求没理解清楚而造成自己的rework。可见沟通是十分重要的。

将需求文档化也是为了可追踪客户需求，也为测试人员测试提供原材料，保证产品功能和需求的一致性。而因为需求变动造成项目延期时也有据可依，所以对于需求文档的管理也是十分重要的。开发人员在理解需求时，和BA当面沟通交流确认后，也一般在需求管理工具中留下文字性描述进行二次确认，所以需求管理不仅仅是PM和BA的工作，开发人员在开发时对于需求理解的comments也要有效记录下来，毕竟对Change Request的管理也可以有效的区分开发时导致的defects。

需求清楚了，是不是就已经花费了很多时间，当然，前期你的effort其实已经体现出来了，所以在拿到需求时leader让你预估时间时请一定不要忘记了这段时间~ 功能点*复杂度只是开发的预估，加上你分析测试确认等等交流的时间之后才能完整匹配每天工作的时间。（论如何保证管理工具中的时间和公司工作时间的一致。）

功能点*复杂度，程序员们是不是要来装逼了，那些技术难题总有资深技术大牛能分分钟给你答案。炫酷的功能，技术帮你来实现，无论是拿项目时架构师给出客户满意的技术解决方案，让一切成为可能，还是后期功能模块在技术上的实现，都是最佳技术方案的角逐，以及可reuse库的搭建。技术大神们实时关注的点，也是技术上更新迭代，新技术新语言的开发或使用等等，如何更简单的实现一个功能，这些本质上都是技术方案的角逐。而作为一个产品，细分到功能模块来实现，实现之后又集成为一个完整的产品，考虑到模块间的耦合性，就涉及到接口的调用问题，这也是开发团队需要在一起工作的原因，方便及时沟通。

前面也已经说过了28定律一直适用，功能实现之后是不是就不管了呢？当然不是的，在你接下来自己做单元测试的时候，也是不断的对需求进行验证确认的过程，这个时候又可能引发一些理解上的差异，页面上效果继续和设计人员与需求进行确认，这个过程也是必不可少的。review的过程是十分重要的，无论是一对一table review还是团队一起peer review！！！

在交付出去之前，通过测试人员的测试来保证开发人员需保证自己是正确的做事情（Verification-You build it right），而整个项目软件开发生命周期之中，项目经理就需要不断保证项目组做了正确的事情，也就是在客户验证时接受通过（Validation- You build the right thing），所以交流review反复确认在开发过程中是十分重要的。

--番外

过程管理中cover了6个过程域，Requirement Development，Requirement Management，Technical Solution，Product Integration，Validation，Verification. 相信大家都很熟悉这些，也就是开发人员的工作范畴，但很少开发人员能够在平时这样细分出来这些工作吧。要知道程序员不仅仅是打代码这么简单的！

你有没有同样的感受，大多时间你不是在打代码而是在和BA弄清出客户的需求，和测试撕逼这是需求，不是bug，和BA撕逼这是CR，不是bug，一直到客户接受为止，而这些都是一个不断更新迭代的过程，因为客户起初给你需求的时候基本不知道Ta真正想要的是什么！只要你实现出来给客户看到Demo之后，Ta会告诉你其实Ta想要的是那样（需求变动为十大项目风险之一），这又涉及到合同初期定义的工作Scope和项目管理时PM对整个项目的控制方式和方法，多方沟通合作才能保证项目及时高质的交付出去。

篇幅有限，本章也是大轮廓的说了一下工程过程域中几个PA的concepts，具体就PA展开来讲，其实码农实际和应该做的事情更多，等之后我也会分开来总结学习之路，希望这篇文章对开发人员的实际工作有一个清楚的大纲阐述。总的来说，开发的最终目的是实现客户需求，无论多炫酷的效果和功能，最重要的弄清客户需求，做正确的事情，并高效的正确执行，需要开发人员，BA，DBA，UI设计，PM整个项目之间内部不断沟通review确认和整个项目组与客户的有效沟通确认！！！

欢迎交流沟通。邮箱：guineverelemon@gmail.com