[I.1]阅读与提问

项目	内容
软件工程	课程社区
作业要求	作业要求
课程目标	理论与实践相结合，掌握实用的软件工程技术，积累软件开发经验
本作业期望实现的课程目标	粗读教材，了解软件工程的基本概念和方法论

阅读与提问

问题一 单元测试的撰写者

单元测试必须由最熟悉的人（程序的作者）来写。
——《构建之法》1.2 好的单元测试的标准

书中强调作者最熟悉代码的特点与局限性，是撰写单元测试的最佳人选，但是根据我的经验而言，作者本身往往也存在局限性，对于代码的漏洞常常是不自知的，毕竟人在主观上不会写自己认为有问题的代码，也就是说，我认为作者很难测出认知之外的bug，通常可以测试出的是“已实现但错误”的情况，而不能测试出“实现的不完善”，所以，如果一个不参与代码编写的人通过了解代码实现的目标，其编写的单元测试效果与作者本人编写的会有很大差别吗？甚至会不会优于作者编写的单元测试？

关于这个问题，我也尝试寻找了一些资料，发现在《软件测试的艺术》这一书中有出现“程序员应当避免测试自己编写的程序”的观点，作者从心理学的角度剖析，发现程序员存在的“确认偏误”，即程序员在测试自己的代码时，往往不自觉地寻找那些能够证明自己正确的用例，会导致对自己代码的测试用例成功率偏高约20%，此外，还有类似的“测试者分离原则”，以及一些团队在实践中对非编写者测试用例的占比要求，是否都在说明这个观点过于绝对化？或者我认为还有一种更为妥帖的说法：作者是写正向功能测试的最佳人选，因为ta最熟悉代码，此外，还需要一位协作者帮助ta发现潜在缺陷，编写异常路径的测试，这种分工模式是否比作者单一主体编写更能提升测试的整体质量？

问题二 预估与实际的误差

在软件的开发过程中，“预估”是重要的，像在敏捷开发流程中，作者认为以时间为度量的燃尽图更有效果，并给出一个在实际项目中使用的燃尽图，其跟踪的三个时间值指标为：

• 实际剩余时间：每个团队成员所有认为的剩余时间的总和。
• 预估剩余时间：根据每个人每天的理论进度推算的剩余时间。
• 实际花费时间：实际花费的时间。

——《构建之法》P120

然而，一个很现实的问题是，作为一个缺乏项目经验的开发者，我们应该如何面对与解决“预估与实际”的误差？面对有可能出现在燃尽图中的“实际与预估”的巨大鸿沟，我们应该如何努力跨越？
经过了解，发现在敏捷实践中“计划速率”与“实际交付”不一致”的现象也比较常见，例如“故事点估算偏差”，在使用故事点预估工作量时，很重要的一点就是“确定故事点的标准”，即“找到一个基准故事”，如果团队成员对故事点的理解不一致，就容易出现“估算偏差”，此外，该“误差”还可能发生在项目中技术变化较快的阶段，因为原有的估算标准可能已经失效。
经过这些了解，我认为“预估与实际”的误差很像现实生活中“一串玉米粒”与“一根玉米棒”的问题，刚到北方的南方人很可能一个人点出一桌子菜（预估与实际的错误估计导致），但正确的方法从来不是不吃饭（不解决问题），而是“吃一堑”以及“问一嘴”（试错与沟通），调整与变化才能让每个人吃到满意的饭菜（项目顺利进行）。

问题三 “持续交付”与“需求管理”矛盾

敏捷开发的原则是：

• 尽早并持续地交付有价值的软件以满足顾客需求
• 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势

—— 《构建之法》6.1 敏捷的流程简介

在敏捷开发中提到的这两项原则，在实际执行过程中是否会出现矛盾？或者换句话说，如何在高频交付的同时避免需求频繁变更的影响？过度迎合用户是否会导致迭代目标偏移？需求变更频繁是否会让技术人员疲于应对？
现有的解决方案也有很多，例如，给需求引入“优先级”的概念，在Scrum框架中，可以在每日立会中动态调整需求优先级，或者通过Sprint Backlog冻结来限制变更，但对于客户频繁提出高优先级变更，似乎还是很难保证在不破坏团队节奏的前提下灵活响应。
更为实际的问题是，在我们项目的开发中，我们是否应该允许并实现“客户需求的随时提出”，以及是否需要引入“变更影响评估”机制，保证“持续交付”的质量？

问题四 故事的粒度

在《构建之法》第十章中，讲述了很多关于“典型用户与场景”的概念，其中给出的一个可能的典型用户的模板，包括以下内容：

……
年龄与收入
使用本软件/服务的环境
知识层次和能力
……

包括在10.1.4 从典型用户到场景中，给出了一个十分具体的场景示例，细节到“……他设置了‘记住我的登录信息、，Stone网站会自动登录。”
如果从直观感受上来说，通过一个故事，我们确实能很有效地发现问题、了解需求。但是，同样明确的情况是，一个购物网站和一个专业论坛的“故事”一定会是两个不同的画风，我们应该关注什么？是看使用场景还是看用户教育背景？是专注使用便利性还是搜索机制？这都注定了我们所讲出的故事之间的巨大差异。
所以，既然故事的粒度没有统一的标准，我们故事的粒度应该如何确定？特别是，作为团队内策划的身份时，我们需要将故事的细节展开到何种程度才能将需求表达清楚？我们又要留给设计人员多大的自由度呢？

问题五 软件的价值

在《构建之法》的第十四章中，剖析了软件的质量，是从软件的功能的特性方面进行判定，例如“吞吐量”“准确度”“覆盖率”等等，也有提及软件工程的质量体现在“开发过程的可见性”“开发过程的风险控制”等等方面，以及，第十六章《IT行业的创新》中，讲述了很多创新的关键要点，似乎希望软件工程师能够参与到更有质量的开发中，创造出带来深刻改变的产品。
但是，又该如何评价软件的价值呢？按照最合理的软件工程理论构建出来的就是有价值的软件吗？如果我有一个想法，以此创造出一个软件，它可能是无用的，可能是没有受众的，那它是否有价值？以及，一款游戏和一款办公软件有价值上的高低之分吗？
我认为这个问题决定了“我们应该向哪里出发”，所以，会有一个客观的“好的出发方向”吗？也许存在，也许并不会有，或许当这节课结束后，创造出“我们的项目”以及看过大家各不相同的“故事”之后，我会有更深刻的理解。