这段时间，老师提到我们即将要进行团队的项目的开发，有点激动，也有一点忐忑。
在继续拜读邹欣老师的《构建之法》之后，我对团队的项目又有更深了解了。
一、团队和团队开发流程
关于团队，有很多种的模式，使用于不同的需求和人员，每一种团队的模式都有它的独特的优点，要成为一个紧密的团队，需要一定的时间，在这个过程中磨合很重要，在书中，邹欣老师介绍了很多的团队模式，这些团队模式在课堂上老师也给我们详细的介绍过，下面将这些团队的模式进行列举。
- 主治医生模式
- 明星模式
- 社区模式
- 业余剧团模式
- 秘密团队
- 特工团队
- 交响乐团模式
- 爵士乐模式
- 功能团队模式
- 官僚模式
说实话，在当前我们所要做的团队任务中，首先在人员方面，我们没有那么多的人员去供我们去成为很庞大的团队，因此上述的大多数团队模式我们都很难去实现。记得老师在课堂上和我们说过，一个好的团队模式会对我们开发有巨大的帮助。可能在我真正的参与到一个团队项目里面的时候才会体会到这个吧。
二、开发流程
记得老师在第一章就提到：我们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中，叫“软件开发流程”，软件开发流程的目的是为了提高软件开发、运营和维护的效率，以及提升用户满意度、软件的可靠性和可维护性。所以，我们的开发流程一定是在建立在完成一个项目上的，在书中，作者提到这样几点有关开发流程的现象：
- 写了再改模式（Code-and-Fix）
- 瀑布模型（Waterfall Model）
- Rational统一流程（RUP）
- 老板驱动地流程（Boss-Driven Process）
在这些模式中，也是各有优劣，相信在具体的团队项目中都会有多体现。
三、需求分析（NABCD模式）
在需求分析中，我们应该先从用户的考虑出发，首先要了解用户需要的是什么，然后对待具体问题进行市场分析等等。尤其是当我们在刚刚拿到这个问题的时候，我们要通过分析来确定他值不值得我们去把问题解决。
下面，引用知乎上一个大佬文卿的关于《构建之法》的阅读笔记来对NABCD模式进行了解。
原文地址：https://zhuanlan.zhihu.com/p/36896480
1. N（Need，需求）
你的创意解决了用户的什么需求？这个需求可以是明确的、公开的（例如：希望能上网玩三国杀）也可能是说不清道不明的，例如——以前没人说：嗯，如果我能找到这样一个网站，我可以去偷菜，就好了……我们要充分了解用户的痛苦，他们对已有软件、服务不满意的地方。
2. A（Approach，做法）
好，你找到了需求，下一步怎么办，得看看你有什么招数，特别是独特的招数，来解决用户的痛苦。你不能说我会C++，所以我一定可以写好这个软件。你得有独特的办法，例如，有人脸识别技术，会做超大规模的数据处理。那你（你的团队）会什么呢？只会冒泡排序？这些招数不光是技术上的，也可以是商业模式上的（例如，我们第一个做众包的服务）、地域的（例如，我们对本市的公交线路很熟）、人脉的（例如，我们认识很多大学生）、行业的（例如，我们有地图测绘行业的资质），或者是成本上的（例如，我们能找到更便宜的资源来维护网站）。
3. B（Benefit，好处）
这时候你已经有了独特的做法，那你这个产品/服务会给客户/用户带来什么好处呢？如果用户已经有一个解决方案（例如用户已经在用QQ聊天），那你的新的聊天软件具体有哪些好处，能让用户离开现有产品，使用你的产品呢？这还有一个用户迁移成本的问题——用户要花费多少精力、时间、金钱才能得到你的产品的好处？如果你要求用户必须有8GB内存、最好的显卡、10Mbps以上的宽带连接，才能使用你的“更好的”视频聊天工具，那么会有多少用户愿意支付这个成本呢？
4. C（Competitors，竞争）
竞争对手也没有闲着，这个市场有多大，目前有多少竞争者在瓜分，你了解么？你的产品如果不是最先进入某个市场的，你还能赢么？先进入市场的产品，有所谓的先发优势（FirstMover Advantage，FMA），当然也有劣势。后面进入市场的产品，有种种不利的因素，但是也有后发优势（Second Mover Advantage，SMA）。
5. D（Delivery，推广）
在实际项目中经历多次的NABC之后，许多人意识到这个框架还应该加一个元素D：Delivery。怎样把你的创新产品交到用户的手中？例一，你想到了一个好主意，建一个比hao123更好的导航页面！我们姑且认为NABC都没问题，那如何把这么好、这么简单的产品交到（Deliver）用户手中呢？例二，你想到了一个手机的应用，NABC都不错，那如何把产品交到千万个用户手中呢？
这是对NABCD模式的各个阶段的介绍，那我们在对项目进行分析的时候就应该从这几部分进行考量，来对自己的项目进行统一的分析后使他的利益最大化，进而分而治之。
四、用户场景
对于一个项目来说，我们是一定要给自己的项目确定明确的用户对象，所以，为了更好的给自己的用户以良好的体验感，我们必须要去做用户场景测试。邹欣老师在书中提到了关于用户场景的分析。他通过不同的例子来进行各种用户场景的分析。这就让我想起了上学期我们学习的uml建模语言，当时并不是觉得uml有多大的用处，直到现在才发现，确立一个好的用户场景是多么的重要。只有确定好自己的用户和场景，才能在接下来的开发中做好定位，才能是自己的产品更加的被用户接受。
那么，怎么去确定用户场景呢？
我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。我们的产品不能是适合于所有人的，一定要是适合于部分人的。我们不能对用户的需求一丝不苟的执行，典型用户只是我们的设想，还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户。归根结底，最后的分析与确定是由我们来完成的。
在有了用户之后，我们就要确定场景，简单来说，场景就是用户所要达到的目标，正式他们使用我们产品的原因。对于每一个目标，我们需要列出达到目标所必须经历的过程，这就是场景。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。
《构建之法》的阅读暂且先到这里，之后还会重新去温习，毕竟现在还有太多的不懂的地方。