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

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13365
我在这个课程的目标是	掌握软件工程方法，提升团队协作开发能力
这个作业在哪个具体方面帮助我实现目标	通过阅读快速掌握

问题1：如何判断订单任务拆分粒度是否合适

章节：6.1 敏捷的流程

上下文：“第二步：决定当前的冲刺（Sprint）需要解决的事情—Sprint Backlog。整个产品的实现被划分为几个互相联系的冲刺（Sprint）。产品订单上的任务被进一步细化了，被分解为以小时为单位。如果一个任务的估计时间太长（如超过16个小时），那么它就应该被进一步分解。订单上的任务是团队成员根据自己的情况来认领。团队成员能主导任务的估计和分配，他们的能动性得到较大的发挥。”

疑问：如何判断订单任务拆分粒度是否合适？部分任务上手快，问题简单，或许容易根据经验判断。然而对于部分任务（比如Debug），其本身具有一定不可知性，预估工作量可能与实际耗时相差较大。尤其在拆分粒度过细的情况下，受依赖关系和突发问题的影响更大，容易造成更多的误差。

示例：作者在下文也提到，在软件工程中，可能存在一些比较艰难和底层的任务，完成这些任务需要超过Sprint所计划的时间。然而，其将原因归结为任务在短周期的迭代中得不到应有的重视。这样的归因忽略了计划中可能存在的不合理的部分，也没能给出解决方案。

问题2：项目需求生存期是否具有普适性

章节：7.2 MSF基本原则

上下文：“最近业界有人总结，项目需求的生存期是18个月，就是说如果一个项目的需求是18个月前确定的，而产品还没有做出来，那几乎就可以不做了，因为需求肯定已经发生了很大变化。大家有没有注意到微软的一些成功项目的各个版本之间也是间隔18—24个月。现在软件开发的重心从桌面软件移到了互联网软件和服务，项目的版本更新就更频繁了。”

疑问：先不说某些领域就是需要花费数年甚至数十年的时间攻坚克难。得出这样的结论，究竟是因为“项目需求的生存期是18个月”，还是因为“18个月过去用户的需求还没能被满足因此放弃使用此产品”？

示例：这时候不得不提某款3D四字游戏，即使该游戏不断寻找新的噱头吸引新玩家入坑，但因为一直忽略用户的诉求而缺乏长期稳定的玩家群体。长期招新玩家，不招长期玩家。这种赚快钱的思路在短期内可能带来一定的收益，但从长期来看是不可持续的。求早日倒闭。

问题3：PM的技能是否应以牺牲技术深度为代价

章节：9.5 PM的能力要求和任务

上下文：“一定的专业能力如果一定要说专业能力的话，PM的专业就是理解和表达，你能否理解不同人的心理、需求和言外之意？你能否借助文字、图表、草图，甚至代码来清晰准确地表达自己的想法？PM 要始终能满怀激情地向用户兜售产品，向团队兜售希望。史蒂夫·鲍尔默的销售能力就是一个极好的例子[注释10]。PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解[注释11]。”

疑问：此处指出PM的专业是理解与表达，似乎和专业技术无关。然而，如果PM对相关技术不够了解，这是否会导致在部分领域缺乏深度和洞见，影响其对开发团队需求的理解和项目进度的把控？另一方面，如果PM需要能够快速理解他人意图并通过提炼总结再表达，这也是需要大量的时间才能掌握的。在实际工作中，由于PM需要面对多种技术和业务领域，本身不可能对每一个领域都具备深厚的技术背景。在这样的情况下，该采用什么策略弥补不足？

示例：部分企业会区分技术PM和市场PM，对于技术PM的要求似乎有点太高了。

问题4：RASCI模型是否存在职责模糊嫌疑

章节：17.1 猪、鸡和鹦鹉的故事

上下文：“在进行一些跨部门合作时，我们更要理清不同部门的权力、责任和流程。下面是一个比较通用的RASCI模型：R：Responsible，负责把具体事情做好。A：Accountable，对任务负全责，有批准的权力。S：Support，对任务提供支持，辅助任务的完成。C：Consulted，咨询，拥有完成项目所需的信息或能力的角色。I：Informed，知会者，应该事后及时通知结果的角色。”

疑问：如果部门过多，是否会因为责任分散而互相推诿责任？尤其是RASCI中的S，这里关于“辅助”一词的理解可以相当主观。在一个涉及多个部门的大型项目中，如何确保“支持”角色（S）真正发挥其作用，而不是仅仅作为名义上的参与者？

示例：如果R和S对辅助的理解出了偏差，那么极有可能会导致二者互相职责，而造成争端。

问题5：如何防止公开冲突走向另一极端

章节：17.5 团队合作的几个阶段

上下文：“这个时期最有可能出现谣言和误解，对此，团队领导最好让矛盾和分歧充分地暴露，将各种冲突公开化，并且学会倾听、理解和调整。有时候，团队领导不得不妥协，以便项目继续向前推进，因为没有时间去说服每个人，从而得到最优结果。积极、公开的信息流动是消除谣言和误解的最好方式。如果缺乏足够的信息交流平台（如SharePoint服务器，公开的电子邮件组，公开的项目进度表），成员之间会互相猜疑。领导必须做出明确规定，要求公司上下都要进行充分的交流，并且告知团队成员，不允许将信息滞留在小团队内部。领导在这个阶段会发现成员的一些特点，要区别对待。”

疑问：一方面，冲突公开是否会导致过多的争吵影响项目进度？而且，在公开化冲突中，团队成员性格差异可能会导致不同的反应。内向型成员可能更倾向于私下沟通，然而在公开后很难再有私下沟通的契机，进而造成一定的bias。另一方面，积极公开信息流动固然好，但是否会额外占用时间和精力？毕竟频繁的信息更新和沟通可能会让团队成员陷入无休止的会议和邮件往来中，从而分散他们对核心工作的注意力。