earendilzhu

[I.1] 个人作业:阅读和提问

[I.1] 个人作业:阅读和提问

项目 内容
这个作业属于哪个课程 https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR
这个作业的要求在哪里 https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13365
我在这个课程的目标是 通过实际的工程实践,进一步体会现代软件工程构建的方法论,在这个过程中不断完善个人技术栈
这个作业在哪个具体方面帮助我实现目标 本教程帮助我在软件工程方面开拓了眼界,了解了实际开发中产生的问题以及有效的应对方法(如单元测试,NABCD模型等),进一步明确了自己在软件开发中的定位

阅读提问

1.在AI时代,“技能的反面”还仍然是“解决问题”吗?

​ 我在阅读 第二章e.技能的反面 一节时产生了这个问题。

你发现他把时间都花在“解决 (低层次) 问题”上了, 你想考察的“算法技能”、“C# 程序设计技能” 都无暇顾及。注意, 这是在他认为非常精通的编程工具和编程语言中出现这样的问题。你要这样的员工么?

那怎么提高技能呢? 答案很简单, 通过不断的练习, 把那些低层次的问题都解决了, 变成不用经过大脑的自动操作, 然后才有时间和脑力来解决较高层次的问题。

​ 考虑到本教材产生的时间较早(2009年开始用于北航软件工程课程),作者很可能没有估计到AI给未来人类社会带来的变化。当今时代ChatGPT,Deepseek等大模型成为重要生产力,原文中所述的“低层次问题”在实践中早已弱化。事实上如果将一个漏洞百出的程序直接交给人工智能修改,大概率也能得到正确的答案。

​ 我个人认为在这个时代,“技能”本身的含义也逐渐偏移向“如何更好使用工具的能力”,而不单纯是“个人的技术能力”,技能的反面也就随着偏移。当然我并不否认技术能力的提高给个人带来的好处。

2.探索阶段中为什么不适合结对编程?

​ 我在阅读 第三章b.结对编程 一节时产生了这个问题。

并不是所有的项目都适合结对编程,下面是一些不适合使用的例子。

1)处于探索阶段的项目,需要深入地研究,在这种情况下,一个人长时间的独立钻研是有必要的。

​ 我并不认同书中的这一观点。在上学期的编译原理课程中,我就因为独自钻研指导书不透彻导致了后续编译器设计的一系列失误,而在工程实践中,尤其是复杂工程中,想要一个人将项目钻研透是几乎不可能的。这时候就体会出了结对编程的必要性。两个人一起讨论项目需求的时候会产生一个人不会产生的新思路与思维碰撞,更能注意到自己注意不到的地方,避免陷入思维定势,为后续的开发带来很多便利。

​ 除此之外,书中也提到独立钻研需要很长时间,而项目中不可能专门有很长时间供你研究项目。结对研究可以缩短这一阶段用时,更加符合敏捷开发原理,提高开发效率。结对编程可以促进知识的快速共享。

3.对于实际工程开发情景,RASCI 模型是否过于简单理想化?

​ 看到 第五章b.不同的投入 一节时,我产生了一个疑问。

在进行一些跨部门合作的时候, 我们更要理清不同部门的权力, 责任和流程。 下面是一个比较通用的 RASCI 模型:

R: Responsible, 负责把具体事情做好。

A: Accountable, 对任务负全责, 有批准的权力

S: Support, 对任务提供支持, 辅助任务的完成

C: Consulted, 咨询, 拥有完成项目所需的信息或能力的角色。

I: Informed, 知会者, 应该事后及时通知结果的角色。

当你的项目看到很多影评者的时候, 你不妨想想他们属于RASCI的哪一个角色, 然后依照相应的规范行事即可。

在一个流程漫长, 合作者众多的项目中, 项目的管理者要把每一个环节的RASCI 角色都列出来, 每个环节有且只有一个R.

​ 书中所描述的各司其职的状态是过于美好和理想化的,我举两个例子说明。

​ 在项目的不同阶段中,一个成员很有可能担任不同的角色,如在项目启动阶段和开发阶段,产品的负责人需要分别担任A和C角色。还有可能一个成员同时担任不同角色,如产品负责人同时作为A和C角色。在这种情况下,应该如何处理?如何在调整角色的同时保证项目分工的合理性?更进一步的,不同子项目之间的角色应该如何妥善对接?

4.可以牺牲质量去追求用户体验吗?

​ 书中 第七章d.用户界面,用户体验的设计 一节中的第五部分 用户体验和质量中举了这样一个例子:

GE 公司的总裁 杰克·韦尔奇讲过这个故事 (来自 《赢》 第 5 章): 1990年代, 韦尔奇注意到核磁共振机器的通道特别狭窄, 在长达几十分钟的检查过程中, 病人常常有得了幽闭恐惧症的感觉。 杰克做过类似的检查, 深有体会。他问, 能不能把通道做得大一些? 专家说那样会降低扫描成像的质量。 他又问, 对于那些不需要太多精度的检查, 能否牺牲一些成像质量, 换取用户的良好体验呢? 专家说, 他们会考虑的… 然后就没有下文了。 不久, 日本的日立公司推出了宽通道的扫描设备, 并夺取了大量的市场份额。 GE 被动迎战, 花了两年时间才赶上对方。

​ 书中用这一段故事表达有时可以通过牺牲质量去追求更好的用户体验。我认为这一点是片面的。对于严肃性准确性要求很高的产品需求,绝不能通过牺牲质量来换取用户体验。试想如果你是一位患者,医生告知你你所用的核磁共振机器的成像质量低,更容易出现误判,你是不可能同意使用的。我认为这个问题的关键点在于确定产品的使用需求情景,并合理地平衡质量与用户体验,而不是去单方面地说牺牲某一方来换取另一方,书中举的例子较为片面。

​ 此外文中提到的只是短期利益。在足够长的时间后,GE公司由于其设备的高质量,会得到更高的品牌美誉度和用户忠诚度;而日立公司设备出现误判后,产品信誉会严重下降。由此可见例子的片面性。

5.大众对一个新产品是否接受是否真的在于那“一小步”?

​ 书中 第九章c.创新的时机 认为就是成功企业比平均值先走的一小步,让大部分人看到了产品的‘相对优势’从而接受产品。

那些成功的企业只是比大众的平均值先走了一小步(平均值 * 0.618), 就是这一小步, 让大部分人看到了产品的“相对优势”从而接受产品。关于技术创新, 一些趋势(例如社会网络),大家早就看到了, 也有一些产品推出, 但是往往最后成功的产品成功在时机上。 一本很有名的书 - cross the chasm 描述了大众对新技术接受的曲线, 曲线下面的面积大致对应人数。大众平均值的0.618 就在“Early Adopter” 那里, 有时一个崭新的技术, 推出的时机太早 (它的值比G-number 小一点), 它就跨不过那道沟 (Chasm). 做前沿研究的人, 可以早于其他人很多年提出新想法, 但是这些想法一般都是在“Innovator” 那个圈子里有影响, 这些想法要等若干年才能由成功的企业家看准时机推向大众市场。

​ 可以很容易地从现实生活的案例中举出反例。以Amazon公司为例,它能够占领大部分零售市场份额并不是因为它比所有的零售业都更早出现,而是因为它对在线零售业的创新。

​ 我个人认为相对于尽早创新,更加重要也更难把握的一点是对时机的选择。如果创新的步子迈的太大就会过于领先市场,无法被市场接受;如果步子太小就会如书中说的那样,市场达到饱和,企业同样无法成功。因此我认为书中的观点过于简化,需要进行补充。

6. NABCD模型对于学生来说是否适用?

​ 第九章e. 如何提出靠谱的项目建议 中为我介绍了NABCD模型,它可以平衡创新与实用,说服别人接受我的创意。

这些事情光靠拍脑袋和拍胸脯是不够的, “二拍" 的后果往往是第三拍 - 拍屁股走人. 有些同学可能还会遭到脑袋被砖头拍, 或者被胸袭的后果。 如果不能拍脑袋, 胸脯, 屁股, 那我们怎么才能想出靠谱的想法, 然后有条理地说服别人? 在宿舍里睡觉, 聚餐, 喝酒, 搞头脑风暴?

下面是一个比较系统的框架 - NABCD 模型, 可供大家参考:

​ 我的问题是,NABCD模型对于大型的项目来说是一个很好的选择,但是对于比较小的项目,比如学生群体开发的小项目是否还有意义?学生群体往往没有足够的资源和知识来全面实施NABCD模型,那么应该如何调整?是应该基于NABCD模型进行简化,还是说应该选用其它更适合的模型?有这样的适合简单情况的模型吗?

posted on 2025-03-06 19:43  earendilzhu  阅读(18)  评论(0)    收藏  举报

导航