个人阅读作业Week17

 

个人阅读作业Week17

reading buaa software

---

 

解决的问题

这是提出问题的博客链接：http://www.cnblogs.com/SivilTaram/p/4830893.html

在week1的阅读中我提出了6个问题，下面是已经解决的问题及解决心得：

P89页：在这里关于结对编程我有一个困惑：如果结对编程的伙伴不与我沟通，并且对于结对编程没有热情，这样的结对编程反而只会让效率低下。在这种情况下，除了换结对伙伴外（一般出门在外，身不由己），怎样能提高结对编程的效果？

　　这一个问题简直就是预见了我后来结对编程的现状。在第一次结对匹配伙伴时，我的伙伴是仉伯龙，他是北京的同学，但是不在宿舍住。一开始要求结对编程时，努力联系他却一直联系不上。在几天后，无奈之下向罗老师申请更换了结对伙伴。后来结对的伙伴虽然是一名韩国同学，但是他的态度很真诚，并且有比较多人性化的想法。我们在结对编程结束后仍然体验了一周每天结对2~4小时，虽然我们两个之间还存在语言上的部分障碍，但是结对编程结束后双方都有了比较大的收获。
现在看待这个问题，我将会自己回答：结对编程是两个人的事，不是一个人的事情。在结对伙伴执意不肯沟通，缺乏热情的情况下，一定要更换结对伙伴。结对编程这件事，有没有技术是其次的，主要是结对伙伴的态度。否则两个人结对还不如一个人自己编码来得快。

P85页：真的有必要对不可能运行到的代码路径进行单元测试吗？尤其是在本来封装性很好的情况下，为了单元测试而强行拆解函数，把类增加了很多无用的方法？老师如何看待这种问题？

在第二阶段我们遇到了这个问题，对于这个问题我现在的回答是这样的：如果说为了单元测试而强行拆解函数，只能说明类里放法的设置不够合理。强行拆解函数即意味着这个函数可能是多个函数合并而成的，比如我们在beta阶段原想对之前的1071进行一次Test。但是蹑手蹑脚没法下手，是因为1071函数将读取xml、数据处理、生成pdf的过程全部串到了同一个函数里，耦合性非常高，没办法暴露出数据处理的接口。这样，我们没办法下手册是。
现在看这个问题，我会这样回答自己：因为单元测试而拆解函数的，说明函数没设计好，不怪单元测试。

P117页：关于敏捷开发。敏捷开发的模式可以说是种轻便的模式，但是有一个严肃的问题摆在我们面前：小的创业团队一旦敏捷开发了一款创意优秀的软件并且在完善它到很好的程度前就发布了。这样会不会引来大公司的创意剽窃？尤其是在财力，人力都不如大型公司的情况下，怎样解决这种在敏捷开发中可能遇到的问题？

　　这个问题现在自己稍微有些想法了。现在的想法主要建立在本团队的团队发布策略和另一组的团队项目的发布策略上。本团队遵循的是敏捷开发的原则，出口条件不极端，不苛刻，满足基本需求即出口发布，然后让用户的反馈与团队的更新来让它更好。而另一个团队是将项目做得比较完美后才想发布。个人现在的观点是，一个创意优秀的项目不会被轻易复制————只要团队不断有迭代更新。及时的发布与获取用户反馈进行及时的迭代更新是有必要的，不能因噎废食。比如手机QQ，即使做到了用户上亿，依旧是每过些天就会有不同的迭代更新，在这一点上的坚持是初创公司更应该有的。所以现在我认为如果每周有迭代更新，那么一款创意优秀的软件是不会被大公司创意剽窃的，一个软件不能在完善到很好的程度才发布，那时候可能已经失去市场了。

 

新的问题

由于阿尔法阶段和贝塔阶段我都是作为团队的项目经理的职位出现的，有几个关于团队管理方面的问题想问：

1. 对于有着比较弱的学习能力的队员来说，是花费一定的学习成本让其学会某种编程语言，学会使用某种工具更好呢，还是说让其做一些团队项目中的杂活以团队效率最大化？选择前者要面临着高额学习成本，可能还要项目经理付出监督成本，团队项目风险加大，而后者对队员来说没有太大提升。不知道在课程实践的角度来讲，选择哪种方案更优？

2. 如何能教导队员明白一定要使用清晰的commit提交日志呢？不管前端工程师还是几位开发人员，总喜欢在commit提交日志里写打油诗，不利于清晰追踪项目每次commit的概要内容。

3. 其实整个项目流程走下来以后，我发现每个主力在团队中的地位几乎都是不可替代的。所以关于这一点，我不太清楚，在实际生产环境中是否会出现这样的问题，即骨干力量对一个团队的影响是起导向性作用的，而一个团队里的每个骨干都是不可替代的，这样项目经理又该如何做风险控制？怎样能把每个人可能出现的不好的行为（比如停工）对整个工程开发的不良影响降到最低？

 

新体会

　　本来我觉得不会有什么新体会了。但是在重读的过程中，发现了很多神奇的映证证——团队项目在Beta阶段曾陷入过的困境和解决方法，软件工程中的前辈们都有过类似经验与血的教训。

　　http://continuousdelivery.com/2012/08/why-software-development-methodologies-suck/　　

　　首先是Beta阶段遇到的一个团队内的人力资源配置的问题。我们团队面临的一个严重问题时，有一个技术层次上的活只能项目经理来做，其他人想做这个综合性的技术活需要先积累丰富的经验。这就像Chronos团队的PM曾跟我说过的，可能他们队里PM使用10分钟可以解决一个bug，不熟悉的开发人员可能要半天，一天或者毫无进展。在这种情况下，我和他们团队都是顶着压力挺过来的。而根据持续交付里的这篇文章所述，在组建一个团队的时候就应当考虑每个人在团队中能够发挥的作用，尽量不要使得职能重复。reduce cycle time and increase feedback 的前提，或者说比根据反馈迭代更重要的一点应当是在组建一支团队的时候要building an organization which learns and adapts as fast as possible。不过根据这篇文章所述的，我觉得这一点上没有什么太好的解决方法。大家现在组建团队依然是以宿舍为基本向周围扩散的方式，好像没有哪支团队是公开招聘，然后面试筛选组建而成的。同时，大家也都是第一次进行团队协作开发，项目经理还没有那么毒辣的眼光能一眼看出一个人IT技能掌握的水平以及其适合的职能。文章所述的问题是存在的，但解决方案在软工实践课里是不太可行的，不过对生产环境里有比较好的启发作用。

　　剩下的还在读...（会继续更）

　　

知识点

• 需求：
  • 　　需求不是空想臆测来的，需求需要落地。不论是场景分析与需求用户分析，以及直击重点的用户调查问卷，都是为了让需求落地，需求要真正地贴近用户。在开发中要有舍有得，要为功能制定优先级进行开发，不能大头小头一把抓，最后什么都没做成。需求文档应该随着用户需求的反馈而进行更新。（这一点上我们没做好，很遗憾...）
• 设计：
  • 　　设计阶段是最重要的阶段，前端应当在这个阶段进行原型设计，原型设计文档将作为前后端对接的接口。而后端应当在这个阶段进行后端逻辑框架的API与设计文档。
• 实现：
  • 　　在分配任务时，一定要按照队员不同的能力分配安排不同的任务。在组织和管理一个团队的时候，应当尽量做到一个迭代内的学习成本最小化，要尽可能让每个队员在单个迭代内接触到或者新增加的学习内容是同一领域的，可以具体到编程语言，也可以具体到某些单一重复的工作。尽量不在在一个迭代内让能力弱一些的同学跨领域学习很多东西，成本过高，风险太大，容易不可控。
• 测试：
  • 　　一定要单元测试，一定要单元测试，一定要单元测试！单元测试真的可以保证代码质量！质量！质量！发布前一定要进行全方位的测试，至少不能让用户用起来觉得一点都不好用，要亲自体验，进行场景测试。
• 发布：
  • 　　发布时要满足一定的出口条件，但是在满足出口条件的情况下发布要越早越好。出口条件不要控制的太为严苛，要在发布后及时获取用户反馈进行新的迭代开发，这样才是一个可持续的迭代过程。空想的需求不是真正的需求。
• 维护：
  • 　　进入到维护阶段时，一定要及时处理用户反馈的bug，要倾听用户的声音，不断收集用户的有创意的想法，然后再通过这些想法对自己的产品进行定位上的微调与功能、产品上的再次迭代。