软件工程提问与个人总结
学期初提问博客
学期初问题与解答
第4章 结对编程
总之，如果运用得到，结对编程可以取得更高的投入产出比（Return of Investment）。
- Q1
此处的投入产出比仿佛是一个缺乏定义的概念。结对编程的核心想法大概是一人领航一人实际操作，并通过频繁交流迫使双方共同努力提高自身水平，这种工作模式在参与者水平均较高且相当的情况下一定程度上自然能减少错误、有一定督促效果，但考虑到磨合成本，以及现实中参与者往往存在水平、技能的差异，能否真的达到比两人高效协同工作收益更高，我持怀疑态度。 - 回答
- 本学期实际的结对编程中确实出现了上面提到的磨合、技能差异问题，代码复审确实能提高代码质量，但效率和收益并不高。总的来说，结对编程还是需要结对两人均有较高且相当的水平才能效果较好。
第6章 敏捷流程
教材中对敏捷开发团队成员提出了较高的要求：
1.以有进取心的人为项目核心，充分支持信任他们。
2.自助管理、自我组织、多功能型。
对于团队成员质量的保证，我有以下两个问题：
- Q2
这样的团队成员要求不说极高，但也算很高了。那么，为了持续保证成员质量，是否需要以某种形式进行团队成员出入的管理？以何种标准合适呢？ - 回答
- 团队项目有安排换人，但我们组通过了无人转会申请，所以并没有人员更换。主动的人员出入对于一个团队来说可以说是比较纠结的一件事，队伍磨合后可能出现谁都不想换的局面。但在实际项目中，若以效率和收益为首要考虑，换人仍是很有必要的。将与团队融入程度不高的个人替换可能确能提高整体的工作效率，但这件事需要一个高层管理人员执行，否则我想大多数队伍内部会碍于面子、伤和气等问题不处理这样的问题。至于具体以何种标准，我认为是一个很难描述的问题，视情况而定。
- Q3
敏捷开发以充分信任为前提，但人和团队往往是有惰性的。即便是每日例会平行比较工作量，如果所有人在安逸的条件下都有一定的惰性，那就失去了比较的价值。如此而来，是否应当引入外界筛选压力从而督促团队提高效率呢？外界压力和信任是否存在一定冲突？ - 回答
- 在团队项目中我们让每个人做超短期的每日计划，并通过每日例会追踪进度保证工作的持续推进。实际效果很好，有效地降低了惰性，大家都很负责地及时交付自己的任务。一般情况下不需要额外的外界压力也能做好自己的本质工作，并在例会上交流问题保持一个相互信任的友好环境。
对于敏捷流程，我有以下问题：
- Q4
敏捷开发以个人冲刺为工作行为单元，任务多零散。这样的模式对于有复杂依赖关系的软件系统，是否会导致在工作对接上导致效率降低呢？ - 问答
- 在团队项目中，我体验过前后端对接协同修改的艰辛。自然，相比于一个人把一个功能点全栈完成，进一步打散的任务会有更高的对接成本。但对于一个分工明确的队伍，这样做总体而言效率会更高。只能说愈合熊掌不可兼得。若要真切地提高对接效率，只能在需求文档制定时尽可能细化明确需求，让涉及的人员都有明确同一的参考标准。
第16章 IT行业的创新
两三个专注于某一领域的匠人，用非大规模制造技术打造出来的东西还有价值么？IT历史告诉我们，有很多成功的产品都是从小作坊开始的。
- Q5
历史中的成功和当下成功的条件是很不同的。如今，软件行业的质量要求、用户需求都比以往多得多（用户容忍度低），在这种情况下，小作坊形式的产物会不会更容易面临因资源不足的问题难以达到当今环境的质量标准线，从而难以成功？ - 回答
- 视需求而定。一个一般的软件（指全栈开发，尚不面临超大用户量带来的诸多技术问题）开发所需的技能和整个流程往往很相似。实际需要的最小团队规模也可以压缩的很小，个人认为对一些简单任务，本学期团队项目的人数到其两倍左右的人数就足矣胜任。要保证质量，需要有专人测试，并且各角色的开发人员对自己的工作充分负责并积极改进，可以说是态度问题吧。在需求明确的情况下达到需求即可，在需求尚未充分明确时以一种尽可能好的态度去争取，面对发现的问题认真解决，把握时间节点，那做出来的项目质量就可以保证。抛开推广相关问题，小作坊可以把产品做得小而精，我想在合适的大环境机会下也有同样机会获得成功。
软件工程实践中学到的知识点
需求分析
- 面对众多需求，团队需要进行充分的分析和必要的用户调研从而确定优先级。
- 一个清楚的需求文档对于前后端高效对接至关重要。
代码设计
- 尽可能早的明确代码规范并执行。
- 前端开发尽可能早的统一UI风格和组件库，或项目开始前先实现统一的组件库一同使用。避免后期风格不一致造成的额外修改成本。
代码实现
- 多问多查，参考他人的实现改进。
代码测试
- 我在团队项目中的开发工作是前端开发和PM。测试前端时对照需求进行完整的功能测试，不放过任何error。
- 可以的话找用户内测，实践经验表明100个人一起找Bug发现问题的效率要高的多，并常常发现和基于设备差异的问题。
代码发布
- 宣传很重要。在特定开发场景下可以的话争取官方支持。团队项目过程中我们联系了社联官方进行宣传推广后用户量激增。
代码维护
- 敏捷开发讲究快速响应用户反馈，我们在团队项目中实践了这一原则，用户反响很好，不断积极地给我提出各种反馈帮助我们改善软件。
心得总结
结对编程
- 个人认为结对项目体验较差，问题过于关注算法，与其说像一个软工题不如说是个算法题。建议以后的结对项目问题换成轻量级的全栈开发任务，两人实现一个五脏俱全的迷你软件（如小网站），适当延长时间，将任务重心移到软件工程上，不要再出算法题了。当然这样的话测试成本会高的多，还是要根据课程组实际资源考虑。
团队项目
- 团队项目中我的角色是前两个阶段前端开发，最后一个阶段PM。
- 前端开发最大的感受是UI设计应该尽早统一风格。否则，每只程序猿的美术风格（造诣）不同，实现出来的UI会风格差异较大。另外，不明确设计时程序猿往往倾向于找现有组件凑合着用，有的组件可修改性较差，后期若要调整工作量较大。可以的话在项目真正开始开发前先统一写一套样式组件共用，这样就能较好的统一风格。
- 当PM的感受颇多。首先是面对众多需求，要根据用户真实需要、软件当前阶段的核心目标、团队成员的时间进行筛选，应优先将精力投入高优先级的任务尽快提高软件整体的用户体验再关注细节改进。其次是进度追踪的方法。项目中我们让每个人做超短期的工作计划并在每日例会上追踪，效果较好，每个人都基本能及时完成任务，即便某一天因种种原因没有进度，后面也会快速补上。最后是宣传推广时直面核心用户的好处。我们在beta阶段发布后拉起了社团管理人员的群，接收各种反馈意见，与此同时不断推广我们的软件，从这起，我们的用户量快速增加。
- 最后，感谢我的所有团队成员，他们都超！超！超！超！可！爱！！（芬姐两倍的超以表真情）。我们队伍氛围始终很融洽，每个人都对自己的任务很负责，并互相帮助，在欢快吐槽中愉快改bug。大家都在积极学习新技能， 整个项目过程中，我们除去PM有6个开发人员，其中三个都尝试过全栈开发，其中雨飞爸爸更是从小程序写到后端再写到网页端兼代码复审orz。尤其感谢芬姐详细得令人窒息的需求文档、精致的原型设计和魔鬼Push，也感谢我没有选课但友情全程参与开发的小伙伴lqc，还有自愿联系我们加入的宇飞提供的社联层面的宣传推广帮助。
- 配图一张：
