开发人员和团队经理指南
知道一个工作量很大的家伙/团队，但是项目启动却停留在同一阶段：“还没开始”？ 该系统适用于希望提高生产力，更快地构建和发布更好的产品的技术团队。 该系统还可以帮助人们避免精神错乱
小型团队负责管理有限的资源（时间和人员），以交付对项目成功最重要的事情，并继续前进。 如果您没有做这些基本的事情：您没有利用技术团队高达100％的努力，损害了团队成员的安宁，并且没有以最快的速度前进。 确保该计划执行良好，是团队中每个人的责任。
1.值得做的一切都进入“全局任务列表”
改变我们委派/承担任务责任的方式。 而不是口头或聊天。 将每个传入的任务记录在“全局任务列表”中。 全局任务列表应该是选择任务的唯一方法。
2.限制个人时间和工作时间
团队成员应首先阻止个人/非工作时间（您肯定无法工作的时间）。 然后大致了解您一周的工作时间。 与团队清楚地沟通。 设定总工作时间目标也很有帮助，但不应以使用个人时间为代价。 纪律和计划应该是实现这一目标的唯一方法。 有一小段重叠的工作时间窗口（每天30分钟就足够了）。
3.在冲刺中工作
将开发工作划分为sprint。 从1周的冲刺开始。 每周评估总体目标，并确定本周要处理的任务的优先级。 挑选任务的最佳方法是基于用户故事（“用户应该能够X”）。 在冲刺结束时，团队将解决方案（“产品发布”）部署给其他人进行测试并提供反馈。 反馈/待办事项进入全局任务列表。 在下一个sprint中确定任务优先级时，您会看到哪些。
4.像专家一样优先处理工作
尽可能延迟任务！ 是的，这是正确的。 我们一听到有关错误就立即开始执行任务（通过讨论或编码）的错误。 这样我们肯定会感到很忙，但这是事实：
如果我们开始做所有的事情，我们最终将无所作为或做不到
休息一下，想一想！ 这将花费3分钟以上的时间进行思考，编码和部署吗？ 花费3分钟在全局任务列表中记录它（与功能/改进/错误修正的任务类型无关）。
非开发人员，请不要通过使开发人员切换其上下文，推动他们从事最初不在sprint计划中的新任务来破坏开发人员的生产力。 有耐心在下一个Sprint或之后完成它。
那关键的任务呢？
这很简单，您可以即兴创作，尽快完成它并推送修补程序，而不管您的冲刺计划如何。 但…
关键任务比我们想象的要少（〜0）。 问问自己，如果我们等到下一个冲刺来优先处理此任务，我们将会失去什么？
关键任务如下所示：
范例1：修复付款系统， 因为我们的当前用户由于错误而无法付款，因此我们在赔钱。 立即修复。
Example＃2：我们的系统漏洞是公开的，并且是众所周知的，这可能会给我们当前的用户造成金钱或隐私损失。 立即修复。
5.零依赖
对于某人而言，理想的生产方案是他/她可以独立进行当前的sprint，而无需等待某人的某些信息。 虽然我们一般都无法实现理想，但是该怎么办呢？
- 计划任务：这样，一个人可以等待1-2天从某人那里获取信息，而仍然继续从事其他任务或同一任务。 提前想好！
- 文档：尽可能多地记录事物（项目仓库的README.md中的文档，问题跟踪，官方发布文档，代码，最适合的地方），因为它可以帮助您实现零依赖。
- 始终以零依赖性为目标！
6.适当沟通
沟通对于每个项目都至关重要。 请记住，这与数量无关，而与质量有关。 交流过多会影响个人的注意力。 适当的沟通是关键。
- 就您的需求和优先事项保持清晰清晰的沟通
- 尽可能记下其他团队成员的需求。 想一想人们通常会问您什么问题。 通过记录节省您的时间。 如果您有问题，请阅读文档，可能会在那里找到答案，而不是戳团队成员并等待他们的答案。
- 花一些时间进行团队讨论。 如果每个人每天（或每隔几天）最多可以同时相处30分钟，并提出快速问题和简短答案，则更好。 您只有30分钟的时间。 讨论的目的不是在讨论中“找到答案”，而是使负责人更容易做到。 快问，无论是问题还是答案。 在这些讨论中，您将不会获得所有答案，因此请放心。 通过调查/调试找到自己的答案。 如果您仍然找不到答案。 保持镇静，阅读＃1或寻求帮助！ 您应该做出哪个决定。
最后， 始终要前进 。 始终牢记冲刺目标，坚持计划。 并且您将能够在sprint的每一步都这样说：
您有什么要添加到列表中的吗？ 让我知道。
如果您在提高技术团队生产力方面需要更多帮助，请在此处与我聊天。 我还在Twitter上发布了有关生产力，开发和远程工作的积极推文。
