技术部周末技术讨论，关于同事对开发过程中问题的反馈

          技术部周末技术讨论

 

昨天晚上雪峰给我留言，发来很好的建议，附上我的解答给大家讨论，如团队一直所做的，团队每个人都提出建议，并分析采纳，才会让我们的团队更强大，包含团队开发过程方法，并经得住考验

 

周雪峰 2010/3/28 9:34:28

通过几天的观察我对我们的开发方式有些不成熟的建议，希望和你沟通一下啊：

 

-好的，很高兴你分享想法

 

周雪峰 2010/3/28 9:37:14

1，页面的开发进行的过早了，在需求并不清晰的情况下过早的进行界面的设计，很可能后期会付出修改的成本，如果想做原型的话，可以简单的实现，不用做的这么详细，因为需求并不是很明确

 

---也许你并没有完全了解我们的程序结构和开发过程

 

1，在正规的软件开发企业（我们公司是一个正规的软件开发企业，绝不是“小贩”，并且是上档次有规模的），需求是一定要明确的界面原型是需求分析文档中最最重要的内容（三大要素之首）

2，雪峰这几天工作比较紧没有参与项目开发没有全部了解到，了解代码结构你会看到我们代码要求是很严谨规范的，特别是接口，这样的好处大家都知道就是可以在某些部分并没有完成的情况下，可以预览开发（好比程序中的异步调用），大家也都喜欢上了这种方式。

3，咱们现在做的不是界面原型，是真真实实的目标程序，详细认真是对的，界面原型的用语和工作时间严格上讲不是在开发阶段作的，而是在需求分析阶段（产品部的界面原型设计能力我看过了，很不错，他们做的才是真正的界面原型），因为我们已经模板化了很多通用复用页面，通过标准化的方式完成页面快速做Alpha测试，早的发现开发问题，来减少修改的成本，并进开发人员的业务理解力。

 

周雪峰 2010/3/28 9:43:04

2，建议把用例拆分成粒度更小的功能点，然后划分优先级，先做优先级高的功能点，防止项目过程中的风险，这样即使项目最后超时，我们也可以留有和客户的余地，因为我们已经把重要的事情都实现了！

 

-你说的问题符合顺序，当前开发并没有违背，在没有产品文档的时候，团队进行了团队技术积累和系统配置模块的开发，产品文档出来一个消灭一个，部门的同事很努力，很强大，这不是每个公司都可以做到的，感谢同事们的努力，团队工作因此变的很开心，心情舒畅，很良性，但是产品部的同事就会很郁闷。

 

周雪峰 2010/3/28 9:48:39

3，延续上一条建议，建议小粒度的小版本迭代，根据我们的情况，我建议3-4天为一个迭代周期，产生一个可运行的小版本，然后和客户沟通，出现需求理解问题，我们马上修改，这样可以尽量降低需求不稳定的风险！

 

-现在我们每天都会出可用的版本，强迫产品人员做Alpha测试（第一次外审过后的第二天就已经开始），实际上3-4天对我们的项目周期来说都是一个比较长的压力，咱们团队已经做到了每天出版本的能力，与客户沟通在开发快速推进的过程中来做不是不可以，即便是做沟通也应该是需求分析师来做，而不是程序员。更清晰的是这属于需求分析阶段的事情，也是稳定快速程序开发的基础，软件研发部根据认真完成需求分析做程序，是顺理成章的。

 

我本人有工作责任引导和梳理并确认这个需求的完整性正确性可行性，通过内审，外审，严格的评审，要求修改完善需求文档内容确保需求文档的质量。如前所说团队对需求理解问题是要立即沟通的！没来咱们公司前管理项目的时候快速软件开发我都会包一个会议室，为的就是更方便沟通。

 

 

周雪峰 2010/3/28 9:51:43

4，目前的团队沟通不顺畅，大家只有零散的沟通，效果也不是很好，从那天的数据库表出现的问题可以看出，沟通不顺畅，建议增加每日的早会，大家说明一下自己昨天的工作，以及今天要做的工作！

 

 

--数据表的规范之前已经出了规范和会议宣布，很明显当前团队缺少测试开发工程师和架构师，而每天大家都说一下工作，这个是时时刻刻我在带动要求的，零散的沟通带动小组沟通，带动团队沟通，带动部门间的沟通协作，我们的沟通压缩的很紧密，由于时间问题抱歉的是我不能时时跟进同事们提供架构及规范性要求，所以你说的对，团队一两天的会诊是必须的，这并不冲突，团队一直在做，如果出现一些不影响大局的小问题，比如上周末的数据库命名规范，我是可以体谅大家的（但是不允许再犯错误了，因为数据库规范已经整理放在了SVN上，再出问题就要惩罚了，敲头三下），团队开发的节奏很紧凑。

 

--周一我们就会到位一个“测试开发工程师” 团队第一个漂亮的女孩（我们部门并不设立纯测试的岗位），来帮助大家一同开发，及时的纠正规范性，完整性，正确性的问题。

 

--架构师需要运气了，我们知道优秀的架构师是如此的奇缺，在没有到位之前，还暂时由我兼任软件研发部架构，潘总（我们的CTO）兼任产品研发总架构师，监督控制整体大局。

 

 

周雪峰 2010/3/28 10:00:37

5，我个人不建议在正式的项目中采用过多的新技术，大家对新技术的了解都比较有限，而且新技术也许并不稳定成熟，这样可能会带来风险。我过去带过的团队，几乎很少使用很新的技术在正式的项目中，这是我的个人建议，你可能无法认同。但是多数团队都是倾向于使用稳定的成熟的技术的。就像你说的，客户不会因为我们使用的技术是新的，就付给我们钱啊！另外，程序员学习新技术也是成本啊！

 

 

--你说的对，我也不建议使用过多的新技术，就像我总在跟大家说“不要玩技术”。大家知道我是新技术的追踪者，并不只局限于微软技术，开发领域。但是绝不是狂热者，我使用的一切东西都考虑到快速开发，并对未来的扩展支持，控制成本，不会那个新就用那个，随便的集成各种开源框架，经历告诉我如此做会出现你说的问题。

当前唯一使用的大家不熟悉的新技术就是Ado.Net EF了，虽然带来了学习成本，同时带来了高效，被同事认可，VS2010中被微软推荐，如果你了解ADO.Net EF 就会知道其实他并不难，同时带来了高效率，跨平台。最后程序员都喜爱学习，如果在一个项目中没有使用到任何一个新技术，会直观的感觉到没有进步了。

 

 

周雪峰  10:50:38

实际上我本来打算帮助你做一些流程的梳理和改进，以及进度的把握等工作的！现在看来没有这个机会了啊！

 

周雪峰  10:55:48

我很佩服你的管理能力，我做PM应该没有你做的好！而且你还兼任架构，很不容易啊！强！

 

--客气了，我们相互学习！我希望咱们团队中可以走出一个又一个优秀的架构师。