问我会花多少时间来计划短跑等等？

EN

我认为这在很大程度上取决于项目的性质和现状：

乐观:所有加入团队的新开发人员都将来自类似的领域，并立即发现您正在构建的特性中的挑战。由于您了解域和体系结构(而且项目不太大)，您可以轻松地回答有关它的问题，而无需绘制白板会话等等。此外，系统编写得非常好(使用TDD)，并有完整的文档记录。

悲观:多年来，这个系统是由几个团队建立的，每个团队都认为他们在遵循他们的最佳实践。这意味着代码库现在有几个解决类似问题的策略。此外，到目前为止，项目管理一直以快速推出新功能为中心，因此技术债务已经堆积起来。此外，单元测试一直是一个事后考虑。此外，该领域是非常利基和所有新的开发人员将需要广泛的培训，然后他们将了解领域的一部分。

因此，在乐观的场景中，您可能会很快地与新开发人员一起编写代码。唯一的主要问题是团队形成凝聚力时的个性和工作行为。在悲观的场景中，作为域(业务)和体系结构(技术)的主要链接，您将进行广泛的对话，并编写大量的wiki条目或文档。

你可能会看到事情的发展方向，比如“最好的希望，最坏的计划”。

在过去的类似情况下，我想说的是，至少在4-6个月内，您根本不应该计划编写代码。承担一个大型项目的架构和业务链接的责任可能需要大量的工作(甚至对于一个由5人组成的团队)。这并不意味着您将完全不编码。然而，你编码的时间应该经常被问问题的人打断。(你可能想研究一下波莫多罗技术之类的东西)

好吧，现在我戴着悲观的帽子再做几件事。:)

你的经理说这只需要你10%的时间。因此，这大致相当于每周4个小时。如果是这样的话，为什么你的经理不只是管理这个项目？可能是因为他或她知道这最终会花费更多的时间。

作为开发商，国际海事组织，我们往往严重低估良好的管理。现在，SCRUM还远远不够完善，但这7份全职工作中有2份用于管理是有原因的(scrummaster和产品所有者)。

在确定这些内容时，需要考虑以下几点：

• 估计:这些都应该是自下而上的--如果你采用用户故事的方法，那么在每次冲刺结束的时候与你的团队和中小企业定期开会，用足够的用户故事来更新你的产品待办事项，以涵盖接下来的几个冲刺。在早期冲刺的2-3个小时的会议上的数字，也许下降到一个小时在以后的冲刺。
• 管理任务:尽量分散(分散)痛苦--也就是说，如果可能的话，委派一名不同的团队成员来完成每一次冲刺。有一个任务板，团队可以在每次冲刺过程中进行更新。
• 执行:也就是说，确保团队正在帮助评估和更新任务板。这将需要更多的时间开始，然后变得琐碎。
• 培训/指导:你必须做团队需要做的事。这对局外人来说是很难判断的。
• 排除障碍:这可以是全职工作，视情况而定。你的经理在帮忙吗？

所以，你应该让你的经理知道，一开始，你将花费25%到50%的时间来使项目的正常运转，以及一些时间的培训/指导。希望在几个月后，这一比例将降至10-15%.真正的问题是，你将得到多少支持，以消除团队遇到的障碍。如果你是一个人在那里，你将不会做任何编码。

我是一名软件架构师，后来转变为一个团队的技术产品所有者。根据我的经验，我需要花我25%或更多的时间严格地作为产品负责人工作。做好这份工作花费了惊人的时间，而当我没有做到的时候，它影响了整个团队。

有几个星期，我花了50%的时间，甚至更多。很难说，因为我也是建筑师--这让我可以省去普通的PO/Architect会议，因为我只是在和自己见面。在成为架构师和PO之间，我很少每周花超过6-8个小时编写代码。

不要忘记，整理待办事项并使其及时更新需要实时的时间，并且需要真正的思考。这不仅仅是一些额外的工作，你必须做。此外，准备sprint演示和回顾也需要实时的时间。对我来说，在演示的日子里，我的时间是100%花在非编码活动上，而前一天的时间是50%-75%或更多。

因此，这里有一些轶事证据表明，您至少需要花费四分之一的时间，而且可能更多地取决于您的组织、团队和您正在开发的产品。