Scrum:任务依赖和架构设计任务

时间:2011-09-15 15:13:57

标签: architecture task scrum

我有一些Scrum问题:

  1. 任务依赖性:我阅读的大多数书籍似乎都将任务视为彼此独立。一个程序员任务不会影响另一个任务,因此可以并行运行。如何处理依赖另一个人的任务?

  2. 任务基于故事/特征/功能:在设置项目之前有很多基础工作,例如:设计架构,学习架构,框架等。大多数功能任务都取决于要完成的架构工作。这是Q1的问题。目前,只有一名程序员在进行架构设计,而其他团队没有任何分配任务?

  3. 请告诉我如何解决这个问题。感谢

1 个答案:

答案 0 :(得分:0)

(1)任务是实现用户故事目标的步骤,类似于配方中的步骤。在这两种情况下,依赖关系在何时以及以何种顺序执行。 关键是团队讨论如何将事情分解为最有效率的工作。这不是一个人的工作,而是Scrum团队的工作。这种情况最初发生在sprint计划中,当用户故事被任务(整个团队),但每天都在工作(每日站立等)。

技能并非真正关于找到没有相互依赖性的任务,而是最小化依赖关系并以最佳方式组织事物以提高团队效率。这是团队的责任。 Scrum Master的工作就是指导他们朝这个方向发展。

(2)在Scrum中(敏捷)您没有预先建立架构。这并不意味着敏捷中没有架构工作。相反,架构在整个项目中持续进行。从一开始就有松散的概念和思想的容器如何做事,然后在项目中,这个shell充满了具体的架构,根据正在处理的用户故事的需要一点一滴。

关于学习,无论如何都是如此,敏捷与否。 在敏捷中你可以学习全部时间。不是在前面。在最初的几个冲刺中,由于团队需要学习新技术和其他东西,所以选择的用户故事可能会少得多,但必不可少的是,每个冲刺都需要采取可发送的东西。这有几个好处,因为团队可以尝试建筑思想以及利用新技术的技能。随着时间的推移,这会改变,团队将非常清楚整体架构的外观以及该技术如何用于挑选更多用户故事。

我的最后一点建议是不要接受像Q1,里程碑等瀑布的任何约束,这些约束表示架构是在那时完成的。这会适得其反,而且会失败。保持敏捷(或不)!