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?
任务是根据故事/特性/功能：有大量的地面设置项目，例如之前的作品设计架构，学习建筑，框架等，功能最全任务是依赖于这种架构的工作要完成。这是Q1的问题。这时，有将只有一个程序员的架构设计工作，而球队的其他部分没有任何分配任务？
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团队的。这最初发生在用户故事的任务了（由整个团队）冲刺规划过程中，也以每天的工作正在做（每日站立等）。
(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.
至于学习，这是在任何情况下真实的，敏捷与否。 在敏捷你学习的整个时间即可。没有前期。在最初的几个短跑可能会有少得多用户故事选为球队需要学习新的技术和其他的东西，但本质的东西就是要采取在每个冲刺的东西可交付的需求，。这样做有几个好处，因为球队可以尝试两种建筑理念以及他们的技能，利用一种新技术。随着时间的推移，这改变和球队都会有pretty好主意整体架构是什么样子，以及如何技术的工作原理来接更多的用户故事。
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屋！
