阅读提问
快速看完整部教材《构建之法:现代软件工程》(教材还没买到的同学,可以先看邹欣老师的博客园讲义),列出你仍然不懂的至少五个问题,发布在你的个人博客上。
- 在结对编程的过程中,如果两人水平相差较大,会不会导致效率低下?
- 书中提到结对编程是为了提高效率,要求不间断的复审从而减少错误。
- 但如果水平相差较大,将会有大量的时间被浪费在解释代码和思路上,也可能陷入某个技术细节的争论中无法自拔。
- 在实际工作中,水平较高的一方通常会承担更多的工作,这样反而效率更高,从而让较弱的一方少做少错,并在闲暇时间阅读代码提升水平,做一些力所能及的工作。
- 敏捷开发中,如何正确预估一个任务的时间?
- 书中提到敏捷开发中,任务的时间应该是由开发者自己来评估,而不是由项目经理来安排。
- 但是前文中也提到,开发者可能会因为自己的主观意识而过于乐观或悲观,导致任务时间的不准确。
- 在实际工作中,可以通过历史数据来评估,但是这样的数据可能会因为人员变动、技术变化等原因而失效。
- 特别是对于刚接触到软件工程的学生来说,这个任务更加艰巨。如何在学习软件工程,实践敏捷开发中提升预估任务的能力?或者说有什么方面需要注意?
- 如何在团队创建的初期快速熟悉互相之间水平,找准每个人的定位和适合其负责的工作?
- 书中给出了很多团队的模式,从最初级的一窝蜂模式,到功能团队模式,官僚模式等.
- 但其中更重要的是,如何熟悉团队成员的水平,找准每个人的定位和适合其负责的工作,结合起来选择一个适合团队的模式。
- 在我们团队的组建中,参考上届学长的经验,创建了一个有明确分工的业余剧团模式。团队角色有 PM,前端,后端,运维,架构等。但在团队讨论每个人负责的部分的时候,就连我们自己也很难说是否能完成自己的任务,或者说是否适合该任务。
- 目前我们的解决方案是,按照当前的任务分配下进行尝试,然后根据实际情况随时调整。
- 如何将合适地任务进行分解,即分而治之?
- 书中提到 WBS 策略需要将大型任务分解成小任务,然后再分配给团队成员。在此期间各个任务不能互相覆盖,同时也不能有遗漏,还要保证每个任务足够的小。
- 那么,PM 作为一个并不一定精通于技术的角色,通过怎样的方式才能确定每个任务合适的粒度?在分解的过程中有什么好的实践法则?是采取个人决策,还是集体决策,抑或是专家决策?
- 什么时候进行扩大化 / 泛化?
- 书中提到了过早扩大化 / 泛化会带来会使得软件变得复杂,难以实现,但是过晚扩大化 / 泛化又会导致软件的扩展性差,难以维护。
- 那么在实际工作中,如何判断当前进行的任务是否需要提前抽象以适应以后可能的任务?如何掌握这个度从而在复杂度和扩展性之间取得平衡?