个人作业 Last

对M1/M2阶段的总结　　

      M1阶段的总结反思见我以前的博客，我以前曾经写过。现附上链接。http://www.cnblogs.com/jirufeng/p/4990245.html

　　M2阶段主要是对我们做的LETS的升级。我们主要在关注、评论、IM和界面几个方面进行的升级。我们按照功能进行了分工，平均是两个人做一个功能。M2阶段和M1阶段就有了很大地不同。因为M1阶段，几乎是我们一块做的开发，所以工程中每个部分都很熟悉，对整体有较好的了解，而M2阶段，完全是新做一个功能，然后融合到原来的工程里面，这就使我对整体工程的把握变少了。应该说这样更符合软件工程的思想，比如到了大公司，我肯定只是做软件的一部分。另一个不同点就是我们M2阶段是以功能为主导，通过实现一个功能来学习一系列的技术，而M1阶段是以技术为主导的，最初功能为空，每学会一个技术，就把它能实现的功能加进去。这使得M2阶段的难度增长了很多，因为新增一个功能要学习太多的功能，而且由于时间有限，不可能从零开始一点点的做新的功能。这就只能找一个现有的工程，进行抽取和融合。这个过程中出现了很多难以解决的问题首。先是xml类的问题，比如manifest.xml中的activity的说明，layout中的布局，使用的图片等等。这些从一个项目转移到另一个项目时，很多需要更改。下一个问题是Bmob的消息发送机制，它把发送的函数实现写在一个sdk中，我们无法查看，所以并不知道它的实现原理，然后仿照它的消息发送写，就是不成功，这里浪累了很长的时间。而且要是完全使用被引入的项目的数据结构，需要改变数据库的结构。这个我们最初竭力避免的，但是最后通过android studio的反汇编，努力读出了必须是用一个新的类，必须改变数据库的结构。

　　以上是关于技术方面的感悟。另外还是感觉到一个团队不应该全都是搞技术的人。张炯老师说过，一个团队里如果有人只是负责想法或者管理，一点代码也不写，这也是合理的。从公司的角度看，这确实是正确的，我感觉在公司并不是程序员就是最NB的。但是在我们的课程中，我们无法模拟到公司的环境，还是做得以技术、代码量为重。有点感觉我们所有的队伍都缺少系统的测试、缺少定期进行规划。缺少系统的测试是说，每个队伍都认为可以一边写一边测试，甚至认为测试是浪费开发时间。编译课程的学习让我认识到了测试真的是一门艺术，有的同学的测试就十分完善，测试数据覆盖面很全，测试思路十分清晰，测试结果显示也十分清晰。还有缺少定期规划，大多数队伍都是开始定了计划，本次迭代要开发哪些功能（当然可能也有队伍没有规划，就是有空就写点，写多少算多少）。但是，随着学业压力的增大，大家都先去写哪些最着急的作业了，比如编译、数据库、数学建模，导致软件工程开发时间不够了。这时应该对任务进行重新规划，以期仍然能够按时发布，而大多人都仍然开发着原来计划的任务，导致到截止时间时，项目并不是一个完整的整体，最后是截止时间的一次次的推迟。

　　总的来说，还是认为这样的软件工程课是很棒的尝试。从这门课中，确实学到了很多知识，收获了很多前大班所没有收获的。技术上学习到了安卓的很多知识，让我比较轻松地通过了本学期的安卓课程；团队合作上，增加了一定的经历，有了很多感受；项目管理上也积累了一定的经验，比如对git、对文档有了更深的认识。

 

原来提的问题

　　这是我学期之初提的问题。http://www.cnblogs.com/jirufeng/p/4830821.html

1、成长与代码量是什么关系？代码量与工程师的水平呈现什么关系？

　　在一个常数以下，成长和代码量是正相关的。但达到这个常数后，代码量增加并不会让自己成长，因此需要使用新的方式来是自己技能增长。

　　Edsger Dijkstra 在1969年写道：

　　一个Clift 所指的初级程序员，学会了爬行，接着蹒跚学步，然后行走，然后慢跑，然后再跑步，最后冲刺，他认为，“以这样加速度前进我可以赶上超音速喷气机的速度！“但他跑进了2,000行的极限，因为他的技能不会再按比例增加。他必须改变移动方式，比如开车去获得更快的速度。然后，他就学会了开车，开始很慢，然后越来越快，但有进入到了20000行极限。驾驶汽车的技术不会变成开喷气式飞机。

　　这个问题是通过上网搜集资料解决的。

2、课本上对结对编程很赞赏，而实际工作中，两个人结对编程是不是浪费了一个人的工作量，有多少比例公司或者部门领导允许两个员工结对编程？

　　从网上搜集的资料表明结对编程很受争议。有很多证明结对编程更加高效的理论，但也有很多人对结对编程表示十分厌恶。反对的人有如下观点：

　　我们中三分之一是性格内向的人（程序员中的比例可能更高！）。在一般情况下，我们不仅偏好单独工作，而且独自工作时成效更显著。我们并不是不喜欢别人，而是我们的大脑更容易被外部刺激所扰乱（不管好还是坏，结对也是刺激的一种）。对于我们来说，高质量的工作是和得到和保持自己的“区域”有关系的。如果确保了这一点，我们就能做到高效率。如果确保不了，我们就做不到。

　　应该说不是所有的情况都适合结对编程，

　　App Annie有开展结对编程，并进行过多次回顾，目前大家比较认可的看法是：

　　（1）结对编程特别适合于知识的分享和传递。特别适合于帮助开发者快速熟悉自己所不熟悉的领域。对于新员工，效果特别明显。

　　（2）如果两个人水平相似，并且对正在工作的领域都很了解的人，结对编程有浪费时间的嫌疑。但我对于这个前提是存疑的。除非特别简单的部分，很难有人真正能说对一个领域全面了解。

　　（3）结对编程很累。要求结对的双方都要保证有充沛的精力。

　　（4 结对的双方如果脾气对味，技术观点相近，结对会很愉快，而且碰撞出很多火花，效率有明显提高。反之，就可能陷入很多的争吵，而导致进度停滞不前。甚至影响团队协作。

　　（5）不是所有的工作都适合结对。技术验证和架构设计都不适合结对。结对比较适合在需求和架构设计明确后的实现阶段。常见的方式有一个人写，一个人看；或者一个人写实现，一个人写测试。一段时间后交换。

　　（6）结对编程不能替代代码评审。虽然结对编程对代码的审核程度比代码评审细致的多。但两个结对的人有明显的思维趋同性，从而忽略同样的问题或者犯下同样的错误。

　　由此看，如果一个公司不分具体情况，一味使用结对编程，它是注定失败的。

　　有知乎网友提到国内很少有人实施，我也搜不到国内结对编程效果的实证，应该可以认为是国内很少实施结对编程。

3、书中讲的敏捷流程变化大，效率高，但我感觉这只适用于小团队，人少才好管理，如果很多人的团队，能否在用敏捷流程？

　　现在感觉大公司也不是全都是大型工程，他也分部门、团队，也要开发新的小项目，也是可以使用敏捷开发的。

　　下面是一个网友讲阿里的敏捷开发。

　　我来说一下阿里的敏捷开发吧，准确地说是scrum开发。就我所知，部分部门如p4p采用的是scrum开发。这些开发模式都结合业务做了一些改良。另外一些部门，任务是根据业务需求来的，就是一个一个的排需求，做需求。

　　下面说说Scrum。首先是晨会：即站会。每天早上10-20分钟讲三个问题，昨天做了什么，今天做什么，遇到什么问题。晨会一般9点30分左右开始。迟到一般是请水果之类。

　　需求PK：一般2周一次，或者一个月一次需求pk。大概两个月作为一个需求review的周期。

　　日报：通过各种方式填写日报；

　　项目周报：一般写日报就不写周报。但是需要写项目周报。

　　某些团队搞燃尽图：但是实际上这个玩意儿不实用。

　　to do、doing、done，这三种任务的面板，某些团队在用，另外也有web的管理工具，用起来相对方便。

　　总体来说严格的scrum开发是挺累的，如果连续两天遇到问题没有进展，会压力比较大。可能要请求其他人的帮助了。

　　Scrum Master是一个非常重要的角色，因为他要负责和其他团队pk需求。到底做哪些需求，基本上master要非常清楚代价和实现难度。要根据团队的技术实力和团队的成长情况来安排需求。如果master不给力，团队会比较难受。

　　很多人都有疑惑，机器学习类的团队如何开展敏捷开发。一般是这样的，通过任务分解把工作拆分为半天到一天的工作量，然后制定里程碑时间点。如看资料、做实验的时间；训练样本、特征开发的时间；模型和预测的时间；最后工程实现。这几个流程下来项目一般会有好几个月。

　　这个问题是通过网上搜集资料解决的。

4、如何避免产品开发后期有重大修改？

　　这个问题没有得到较好的解决。从课本上看，要在最初的时候做好定位，考虑到产品需求的变化，最初做好架构，以避免后期有重大修改。有重大修改，我认为有两类原因：一类是客户改了需求，一类是自己架构错误。自己架构错误可能是对架构的不熟悉，也可能是对需求理解有偏差，这些应该是可以尽量避免的。还有，客户改了需求，这时候如果客户认为自己改动很大，一般是允许推迟工期的，但一般是客户认为需求只是小改，而产品却要大改，这就产生于没有考虑到需求的变化。一个不负责任的答案就是：要有预测未来的能力。

5、如何进行风险管理？能否用更多的例子来讲解它。

常见的风险应对措施
　　风险分析活动分析的目的在于建立处理风险的策略．而风险规避的最好方式是把风险控制在项目启动阶段，把损失减小到最小程度．常见的风险应对措施有：
　　(1)建立畅通的沟通渠道和沟通策略．需求的不确定性风险很大程度上是由沟通不畅引起的．因此，在需求调研阶段，要多和应用部门沟通，了解他们真正的需求，最好能将目标系统的模型向应用部门演示，并得到反馈意见，直到双方都达成共识，形成双方认可的验收方案和验收标准，并做好变更控制和配置管理，尽量降低需求不确定性风险．
　　(2)配备高素质的项目管理人员．最好是具有丰富的项目管理经验，或是经过系统的项目管理知识训练的人员来担任项目经理，通过制定有效的项目管理计划，并认真执行落实，提高项目的可控性．同时，风险不是静止的、一成不变的，它会随着项目状况的变化而变化，因此，风险管理必须被作为一个日常的正式活动列入项目工作计划，成为项目管理人员的一个重要工作．
　　(3)建立一支协作高效的项目团队．技术部门有技术，业务部门有需求，因此，项目组中不仅要有开发商和技术部门的参与，更要有应用部门的参与，从而形成一个合作的项目工作团队，共同理解企业的战略规划和业务发展，从整体全局的角度，提出有效的信息化需求，共同研讨项目进展中出现的问题，共同控制项目进度，共同为项目质量把关．
　　(4)制定科学的风险管理计划．从风险管理的角度对项目规划或计划进行审核，建立“风险清单”，对每个可能存在风险的表现、范围、时间做出尽量准确的判断并对风险进行监控，提前做好应对准备．如针对需求风险，要制定相应的需求变更控制；针对技术风险，要安排核心技术人员全程参与开发等．
　　(5)选择合适的开发技术．虽然在系统设计时需要考虑新技术的发展和技术的先进性问题，但“最好的不一定是最合适的，最合适的才是最好的”，如果项目组的人员对所需开发的技术不熟，在满足业务需求的前提下，尽可能采用熟悉的技术来减轻项目在成本或进度方面的影响，也可以事先进行培训来减轻对项目的影响，以避免因技术瓶颈导致的项目失败。

　　通过上网搜集到的，但是关于具体的实例没有找到。

 

产生的新的问题

　　软件开发中公司是如何培养新人的？一个新人加入团队，他肯定要通过团队的文档来了解项目，但是只是这样是不够的，所以提出问题公司一般如何培养新人。

 

新的体会

　　谈谈关于大泥球的体会：软件开发是一个代码量越来越膨胀的过程。为了引入IM功能，我们引入了有关IM的代码，同时还要做必要的修改以进行融合。这里面实际上引入了很多病没有使用过的代码，使我们的项目出现了杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码，如果继续开发会造成很大地困难：读不懂，出错了不知道是哪，也不敢随意删掉。

　　关于敏捷开发的体会：以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。在M2阶段，我们组分了几个小项目：平分、评论、关注、IM。每个小项目的工作能够正常运行时，就把这些代码push到git上，这就保持了敏捷开发的特点。

 

做中学

　　我学到的知识点：

　　需求阶段：使用NABC进行需求分析，通过问卷调查获得用户的需求。

　　设计阶段：根据用户的需求进行功能设计，前后端共同设计，设计好接口，如果有多个任务，就优先设计重要度最高的任务，按序进行。

　　实现阶段：使用合理的代码管理工具管理项目代码，每天scrum进行任务总结与分配。在分配任务时，要根据队员不同的能力安排不同的任务。在组织和管理一个团队的时候，应当尽量做到一个学习成本最小化。

　　测试阶段：针对不同的安卓机型进行充分的测试。发布前要进行单元测试、全方位的测试，进行场景测试。

　　发布阶段：发布要制定好出口条件，如果满足了出口条件就要尽快发布，不要在想着继续完善再发布，这样就影响了整个计划。

　　维护阶段：进入到维护阶段时，一定要及时处理用户反馈的bug，要倾听用户的声音，然后对自己的产品进行修复，产品上的再次迭代。同时要写好技术文档，方便之后再迅速理解之前的代码。