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

发布时间：2020-12-14 00:51:09 所属栏目：百科来源：网络整理

导读：我有一些Scrum问题：任务依赖：我阅读的大多数书籍似乎都将任务视为彼此独立.一个程序员任务不会影响另一个任务,因此可以并行运行.如何处理依赖于另一个的任务？任务基于故事/特征/功能：在设置项目之前有很多基础工作,例如：设计架构,学习架构,框架等.大

我有一些Scrum问题：

>任务依赖：我阅读的大多数书籍似乎都将任务视为彼此独立.一个程序员任务不会影响另一个任务,因此可以并行运行.如何处理依赖于另一个的任务？
>任务基于故事/特征/功能：在设置项目之前有很多基础工作,例如：设计架构,学习架构,框架等.大多数功能任务都取决于要完成的架构工作.这是Q1的问题.此时,只有一名程序员在进行架构设计,而团队的其他成员则没有任何分配任务？

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

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

技能并不是要找到没有相互依赖性的任务,而是最大限度地减少依赖关系并以最佳方式组织事物以提高团队效率.这是团队的责任. Scrum Master的工作是指导他们朝这个方向发展.

(2)在Scrum(敏捷)中,你不要事先做架构.这并不意味着敏捷中没有架构工作.相反,在整个项目中不断完成架构.从一开始就有松散的概念和思想的容器如何做事,后来在项目中,这个shell充满了具体的架构,根据正在处理的用户故事的需要一点一点地填充.

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

我的最后建议是不接受像Q1,里程碑等瀑布的任何限制,这些限制表明架构是在那时完成的.这会适得其反,而且会失败.保持敏捷(或不)！

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!