Scrum:架构设计的任务依赖和任务 [英] Scrum: task dependency and task for architecture design
问题描述
我有一些 Scrum 问题:
I have some Scrum problems:
任务依赖:我读过的大多数书似乎都将任务视为相互独立的.一个程序员的任务不会影响另一个的，因此可以并行运行.如何处理依赖于另一个任务的任务?
Task dependency: Most books I read seem like treating the tasks as independent from each other. One programmer tasks doesn't affect the other's one, thus can be run in parallel. How to deal with task which is depend on another one?
任务基于故事/特征/功能:在设置项目之前有很多基础工作，例如设计架构，学习架构，框架等.而大部分功能性任务都依赖于这个架构工作来完成.那是第一季度的问题.这个时候架构设计就只有一个程序员，团队其他人都没有分配任务?
Task is based on story/feature/function: There are a lot of ground works before setting up the project, e.g. design the architecture, learning the architecture, framework etc. And most functional tasks are depend on this architecture work to be completed. That's Q1 problem. At this time, there will be only one programmer working on the architecture design, while the rest of the team don't have any assign task?
请告诉我如何解决这个问题.谢谢
Please tell me how to tackle this problem. Thanks
推荐答案
(1) 任务是实现用户故事目标的步骤，类似于配方中的步骤.在这两种情况下，都依赖于什么时候做什么以及以什么顺序做.关键是团队会讨论如何拆分事情以最有效地工作.这不是一个人的工作，而是 Scrum 团队的工作.这最初发生在 sprint 计划期间，当用户故事被分配任务时(由整个团队)，但也发生在日常工作中(每日站立等).
(1) Tasks are the steps towards the goal of a user story, similar to steps in a recipe. In both cases there are dependencies what to do when and in what order. The key is that the team talks about how to split things to work most efficient. This is not one person's job, but the Scrum team's. This happens initially during sprint planning when user stories are tasked out (by the whole team), but also daily as work is being done (daily standup etc.).
这项技能并不是真正地寻找没有相互依赖关系的任务，而是最大限度地减少依赖关系并以最佳方式组织事物以提高团队效率.这是团队的责任.Scrum Master 的工作是在这个方向上指导他们.
The skill is not really about finding tasks with no inter-dependencies as much as it is to minimize the dependencies and to organize things in an optimally for team efficiency. This is the team's responsibility. A Scrum Master's job is to mentor them in this direction.
(2) 在 Scrum 中(敏捷)你不预先做架构.这并不意味着敏捷中没有架构工作.相反，架构是贯穿整个项目的.从一开始就有松散的概念和想法的容器如何做事，后来在项目中，这个外壳充满了具体的架构，根据正在处理的用户故事的需要一点一点.
(2) In Scrum (agile) you don't do architecture up front. That doesn't mean there is no architecture work in agile. On the contrary, architecture is done continuously throughout the whole project. From the start there are loose concepts and containers of ideas how to do things, and later on in the project this shell is filled with concrete architecture, bit by bit as needed by the user stories being worked on.
关于学习，无论敏捷与否，这在任何情况下都是正确的.在敏捷中，您一直在学习.不是前期.在最初的几个冲刺中，由于团队需要学习新技术和其他东西，因此选择的用户故事可能会少得多，但最重要的是每个冲刺都需要采用可交付的东西.这有几个好处，因为团队可以尝试架构理念以及他们利用新技术的技能.随着时间的推移，这种情况会发生变化，团队将非常清楚整体架构是什么样的，以及该技术如何运作以挑选更多用户故事.
With regards to learning, this is true in any case, agile or not. In agile you learn the whole time. Not upfront. In the first few sprints there might be much less user stories picked as the team needs to learn new technology and other things, but the essential thing is that something shippable needs to be taken on every sprint. This has several benefits because the team can try both architectural ideas as well as their skills harnessing a new technology. Over time, this alters and the team will have a pretty good idea what the overall architecture looks like and how the technology works to pick more user stories.
我的最后一个建议是不要从瀑布中接管任何约束，例如 Q1、里程碑等，即架构是在那时完成的.这会适得其反，而且会失败.保持敏捷(或不保持)！
My last advice is to not take over any constraints from waterfall like Q1, milestones etc. that say architecture is done by then and then. This is counter-productive and will fail. Stay agile (or not)!
这篇关于Scrum:架构设计的任务依赖和任务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
