构建之法阅读笔记05
——软件工程团队开发
我要来解释一下为什么标题会叫做“软件工程团队开发”。到今天为止，软件工程的团队开发一直在或紧或松、张弛有度的进行着；老师上课也早在五一左右就开始讲述有关团队合作开发的种种……眼看我们的团队第二期也就是最后一期的冲刺在明天就要拉开帷幕了，而且，确实也是好久没有写阅读笔记了。所以我觉得我应该也有必要总结一下我们实际正在进行的团队开发和老师讲的或者说是“理论上的”开发流程，在这一点上，不得不说，我想说的还真不少……
一、软件团队角色与合作
在第一期团队开发冲刺开始之前，老师就让我们写过“团队计划Backlog”，也就是要召开团队计划会议。在会议上要制作任务索引卡、认领个人的工作任务、拍摄团队人物看板照片、每天召开站立会议、绘制团队燃尽图……”有这么多的任务，天啦噜！“最开始我不得不承认，我们每个人都不理解为什么这么麻烦，不就是合作一起做出来一个能够发布的软件吗？而且，对于“认领任务卡”这一点更是我们以前没有做过的。之前的合作中我们一般都是由组长根据任务的难易和对我们每个人的了解或者说积极程度“分配”任务，要不就是我们会坐在一起一块儿商量着同时编写一部分的代码。但其实，这么做不但容易在大家烦躁的时候引起团队内部矛盾，还会极大的降低了团队的效率。因为我们要想一起编程就需要寻找大家都有时间的时候。其次，难免会出现有人在查资料了，有人就会抽空玩会儿手机……经过这次的团队合作，我对于《构建之法》中提出的这种团队成员认领任务的办法深信不疑。
任务认领完成，好了，我们开始执行各自的任务吧！……那么同时就有一个问题，我们要怎样找到我们在团队中的位置；要怎样才能更好的做到在大家的模块代码编写完成后能够更高效更有默契的完成代码整合的工作？这个时候我们会说——当然是团队协作了，但是我们真的可以做好吗？
《构建之法》中介绍了“软件开发中的动物世界”问题：在一片神奇的丛林里，生活着猪、鸡和鹦鹉，他们经商讨决定开一家早餐店……猪提供猪肉、鸡提供蛋、鹦鹉提供咨询。这项创业对三个动物的负担是一样的么？它们应该各自占多少股份？在一个软件团队中，不同的成员来自五湖四海，为了一个共同的目的，走到一起来了，但是不同的人对于团队的承诺是不一样的。有些人是猪，他们全身心投入；有些人是鸡，他们只是参与；有些人是鹦鹉， 而他们仅仅是围观……
我们的团队肯定不是成员之间能力不同、责任感不同、对待团队合作开发的目的和期望不同。但无论怎样，存在即合理。我们要分清楚团队成员的投入/承诺/责任是属于哪一个级别；想想自己是应该做猪、鸡还是鹦鹉。不能说一定是猪就是最好、团队中就要什么都听猪的，整个团队中的成员缺一不可，我们都在或多或少的为团队贡献自己的力量。因此我认为我们必须要找准自己在团队中的位置，积极的配合自己的组员的工作，同样任务要靠自己也不要过分的依赖团队中的谁谁谁。
其次就是团队成员之间协作的问题了。虽然说我们的团队已经“在一起”很成时间了，彼此之间既是室友又是亲密的合作伙伴，但是我们真的能够做到完全了解彼此的编程思想、完全信任彼此的编程能力吗？会不会出现在开发过程中任务完成重复，比如一个人完成一项任务后，本应该继续改进他的算法，但是在此过程需要另一个成员的算法做嫁接，然后他就迫不及待的自己开始了编写，完全不管队友的进度。虽然大家这么做都是为了团队的最终进度，但是这样就会耽误团队的效率还可能激发团队矛盾（……你是不是不相信我，为什么你还要重复做本该我做的部分……）。就像上课的时候老师带领我们做的那个游戏——两人双臂相互交叉，合力使双方一同站起。在玩游戏的过程中，开始我们都是各自朝着自己的方向使劲，希望能够依靠自己的力量将整个团队拽起，但是事与愿违，我们越是这样越会使力量分散，最后大家都结结实实的坐在地上了。后来老师给我们讲解了里面涉及的问题：我们应该彼此将后背使劲靠在队友的身上，依靠大家的力量一起站起来。这就是《构建之法》带给我的团队合作中对于“同心协力”四个字的新认识。
二、软件的需求分析
解决并且规定了团队成员之间的规范和责任以后，我们就要开始考虑软件的问题了。书中讲到“软件工程是充分与人打交道的一门学科”，那么我们为用户做软件，就要了解并获取用户的需求，就要进行用户调研。书中也讲到，这里面最常用的就是“调查问卷”。“……这种方法给用户事先规定好的问题，让用户回答。有时候你在浏览某个网站的时候，一个弹窗打断了你的思路，它请你回答几个问题。用户在回答这类问题的时候，是否心不在焉，乱点一气？……”调查问卷看似简单实际大有门道，而且一些不懂其中道理的人经常会出现问题定义不准确、使用含糊不清的词、问题带有引导性的倾向、全开放式的问题、选项内容不能涵盖所有的情况……等等。那么就会导致我们的调查结果并不准确，就会导致我们花费大量的时间做出来的软件用户觉得一文不值。由此可见，做好软件的用户需求分析是至关重要的。
《构建之法》第八章中介绍了一种可用的需求分析模型——NABCD模型。能够避免我们开发一些已经存在的，用户不需要的，过时的，毫无新意的软件。
1、N (Need 需求) 你的创意解决了用户的什么需求?我们要充分了解用户的痛苦，他们对已有软件，服务不满意的地方。
2、A (Approach 做法) 好，你找到了N，下一步怎么办的，得看看你有什么招数，特别是独特的招数，来解决用户的痛苦。
3、B (Benefit好处) 这时候你已经有了独特的做法，那你这个产品/服务会给客户/用户带来什么好处呢?
4、 C(Competitors竞争) 竞争对手也没有闲着，这个市场有多大，目前有多少竞争者在瓜分，你了解么?
5、D(Delivery推广) 怎样把你的创新产品交到用户的手中？
三、用户体验
而我们的软件做成什么样儿才算是合格呢？在软件工程开发中，没有考试那样成绩是否合格，只有用户是否满意。也就是最后要达到用户体验良好的软件就是经典。
《构建之法》第十二章中介绍到用户体验的几个要素：
1、从用户的角度考虑
试想，如果我们做出的软件界面繁琐复杂、操作步骤还很多，用户进入界面还没有搞清楚这个软件是干嘛的就要使用邮箱、手机号、验证码、密码什么的登陆，之后的界面让人眼花缭乱……如果我们是用户肯定下次再也不想见到这款软件了吧。对于某一个功能也是如此，像书中写道，如果希望用户发邮件反馈信息，那么邮箱的地址就要找一个方便记忆的。除此之外，我么还要适当的考虑用户的使用习惯，比如登陆时用户肯定希望尽量少的点击鼠标，焦点可以随着用户的输入而变化。
2、从头到尾都要记住用户的选择
这一点不光是体现在记住用户名和密码上面，如果是不需要登陆的软件呢？那就是要记住用户的常用习惯，比如我们的软件，我们需要记住用户经常听的催眠曲、经常浏览的图片等等。
3、短期刺激和长期的好处/坏处
在这一点上我还是觉得软件的界面美观固然重要，但是设计也要有个分寸，相比于那些花哨玄乎的软件还是那些简洁大方有品位的软件使用的持久好评也高，就像苹果手机一样，对吧？
4、不让用户犯简单的错误
对于这一点我想起来安卓老师曾经说过，我们在开发app时应该把一些常用的、用户容易产生点击错误的按钮做的大一些。防止有些用户手大、而按钮小造成输入或者点击错误。此外，我们的产品固然不能规范用户的选择，但是可以在软件上、设计上进行错误预测和处理。
在章节的最后抛出了一个问题：用户体验和产品质量冲突的时候，是不是牺牲利益去追求客户体验呢？对于这个问题我认为在利益损失不大的情况下，我们有义务也是有必要去迎合用户，因为我们的所有软件都是为用户服务的，没有用户我们的软件就是一团垃圾，也不会造成什么经济效益。
