在我们软件设计与实现之前，我们是做过典型用户分析的，博客中也有提到过，并且针对我团队项目做了相关分析。点向用户分析过程中，我们能够从用户的角度去模拟使用的过程，从而去实现对用户需求的分析，还有对不同用户的不同使用需求，目的是搞清楚软件该如何解决用户的需求。个人感觉这个工作在前期去做很有必要。那么在做完了典型用户分析之后，我们是不是应该去对软件进行具体的实现呢，构建之法中讲到了这个内容。
软件的“设计与实现”的目的则是搞清楚软件是怎样解决的用户的这些需求。常见的方法有鸡兔同笼图解法，就是对问题的理解、抽象以及找到合适的数学模型，然后去解决问题。方法还有以文字为主的文档，以数学语言的描述，用类自然语言+代码构造的描述。在图像建模中又有如何表达实体和实体之间的关系、数据之间的流动、表达控制流。掌握了这些方法之后，我们又不能随意的去编程，日常开发中我们又会遇到很多问题，开发中的日常管理又是一门学问。
“闭门造车”也是一种方法，只不过是一种错的方法。当时平常我们又真的会遇到这样的情况。比如：我们团队编程时，可能看到一个bug之后，又想把它整出来，但是思路又不是很明确，就自己坐在电脑前面，无论是发呆，还是在思考，反正时间是保证了8-10个小时的编程，要问成果，几乎为零。这就是所谓的闭门造车。我们应该做的是每日构建，或者每周构建，在冲刺阶段这尤为重要，当我们一天没有进度的时候，为什么不去问问别人或者去探讨一下解决的办法呢。这也是老师叫我们使用Github的最重要的原因吧！在构建过程中，代码规范、单元测试又显得极为重要。我们团队总会出现这样一个角色，当团队成员把某些功能的代码敲出来以后，由一个人负责整合，往往他完成的工作就是构建服务器，调试构建，这样的人成为“构建大师”。
我们在团队开发中，往往需要团队成员之间相互交流，相互合作，避免出现闭门造车的情况。灵位还有一个体会，自己的代码只有自己用起来如鱼得水，往往整合别人代码时候，出来的bug总得去问代码原主人，这其实还是因为代码规范问题。