[I.1] 个人作业:阅读和提问
项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2025年春季软件工程(罗杰、任健) |
这个作业的要求在哪里 | [I.1] 个人作业:阅读和提问 |
我在这个课程的目标是 | 掌握软件工程方法论并提升团队协作能力 |
这个作业在哪个具体方面帮助我实现目标 | 通过阅读提问培养批判性思维和问题分析能力 |
问题1:结对编程的效率提升是否依赖于特定前置条件?
-
章节:讲义第三章 - 双人合作 - 结对编程
-
原文内容:书中强调结对编程能“得到更高的投入产出比”,并列举了减少错误、提高信心等优点
-
矛盾/疑惑点:
- 2013年《IEEE软件工程汇刊》研究指出,结对编程在初期磨合阶段平均效率下降20%-30%,长期效益仅在某些团队(如高技能互补组合)中显现
- GitHub 2022年开发者调查显示,仅12%的团队长期采用结对编程,主要障碍为“时间成本过高”和“协作疲劳”
- 疑问:书中未计算沟通损耗(如思维同步时间)、硬件成本(双人设备配置)等等,本人觉得是否可以将“团队成熟度”“任务复杂度”作为“结对编程能提高效率”的必要前提?
问题2:Scrum中的“每日立会”是否容易流于形式?
-
章节:第四章 - 软件过程/方法论 - Scrum/Sprint章节
-
原文内容:书中提到每日立会中,团队成员报告“昨天做了什么”“今天要做什么”“遇到什么问题”,但指出这种形式可能流于表面
-
矛盾/疑惑点:
-
2019年《IEEE软件工程汇刊》研究指出,缺乏明确任务定义和完成标准的每日立会,对项目进度改善效果有限
-
书中提到“定义任务完成标准”和“记录剩余时间”是改进方向,但未具体说明如何操作
-
- 疑问:如何设计有效的每日立会流程,确保会议不仅汇报进度,还能真正解决问题?
问题3:PM文化盛行的副作用?
-
章节:第五章 - 团队中的角色与合作 - PM
-
原文内容:书中指出PM文化可能导致“中规中矩但缺乏新意”的设计,但未深入探讨其根本原因与解决方案
-
矛盾/疑问点:
-
微软Windows Phone团队曾因过度依赖PM协调,导致决策缓慢,错失市场机会
-
2018年《哈佛商业评论》研究指出,过度依赖PM协调的团队在创新任务中表现较差,因决策链条过长抑制了创造力
-
- 疑问:PM如何在“平衡团队”与“鼓励创新”之间找到平衡点?是否应限制PM在创意设计中的干预权?
问题4:如何平衡代码管理的自由度与规范性?
- 章节:第七章 -设计和开发 - 源代码管理
- 原文内容:书中介绍了不同的代码管理策略,如加锁、自由签出等方式,并探讨了它们的优缺点。
- 矛盾/疑问点:
- 过于严格的代码管理(如强制加锁)可能会降低开发效率,而过于自由的管理方式可能会导致代码冲突或质量下降
- 不同规模的团队是否应该采用不同的源代码管理策略?本人正实践的开发项目,四名开发人员使用三个子分支和主分支,但频繁的PR导致大家同步进度很慢,不如都在一个分支上进行
- 疑问:如何在保证代码质量的前提下,最大程度提升开发效率,找到代码管理自由度与规范性的最佳平衡点?
问题5:如何公平评估团队成员绩效?
- 章节:第十章 - 软件项目的管理 - 绩效管理
- 原文内容:书中提到“绩效评估应以数据驱动,结合团队反馈”,但未具体说明哪些数据最具代表性,也未探讨可能的评估偏差。
- 矛盾/疑问点:
- 代码行数并不能真实反映开发者贡献,过度关注可能导致低效编码习惯
- 研究表明,团队互评存在主观偏见,可能影响公平性,尤其在文化多样化的团队中
- 疑问:在软件工程团队中,如何建立既能量化贡献、又能保证公平性的绩效评估体系?是否需要结合主观评价与客观数据?