下载掌阅APP，畅读海量书库
立即打开
这种投资通常不是问题，但当它成为问题时，它将使你停滞不前。所以，检查一下，特别是如果你正处在一个对安全敏感的行业。
问题是，采用诸如12.2节和12.3节中做法的团队在同一台计算机上工作，从安全的角度来看，这可能是令人担忧的，因为登录到计算机的人并不总是那个在键盘前工作的人。事实上，登录的人甚至可能会离开一会儿，去上厕所或和他人进行交流，因为人们经常会每隔几分钟就更换一次打字的人，每次有新的人在键盘前打字的时候，退出并重新登录是不可行的。
如果团队将使用这些实践，请与公司的安全团队进行讨论，并与其合作来解决问题。你通常可以找到一种创造性的方法来支持敏捷的工作，同时也能保持安全。一种常见的方法是创建一个锁定的、共享的开发账户，一些公司将其与专用开发工作站或基于服务器的共享虚拟机结合起来，电子邮件和其他个人工作是在单独分配的笔记本电脑上进行的。
一个相关的问题是可追溯性。一些公司要求每一个提交都可以追踪到它的原始作者。你可以通过在提交注释中添加作者的姓名缩写或电子邮件地址来满足这一要求，Git有一个惯例，就是在提交信息的末尾加上共同作者行。
有些公司要求所有的代码在发布前都要经过审查，结对编程和集体编程符合这一要求，但你可能需要修改工具，以允许代码在发布时不需要单独的审查阶段。如果无法完全取消这一要求，你也许可以修改工具以跳过有共同作者的提交部分。
你可以要求登录的人留在他们的计算机前。如果他们需要离开一下，要么他们切换登录，要么停止工作直到他们回来，这可能会带来比预期更多的分歧，所以更倾向于允许工作继续的解决方案。
团队也可以使用为远程协作而设计的工具，而不是在同一台计算机上工作。但这比其他方案带来的分歧更多，即使团队成员坐在一起也是如此，所以我不建议这样做，除非团队已经采用远程工作方式。
由一对或一群人编写的代码已经经过了同行审查，所以团队对这些代码可以不经审查就批准。
不过这也增加了分歧，所以最好在广泛传播敏捷之前取消这一要求。
如果敏捷在团队中没有发挥作用，特别是如果在多个团队中看到同样的问题，这可能是投资的缺失导致的。团队通常能够告诉你是什么阻碍了他们的工作，但如果他们不确定，请查看下面的常见问题清单。
· 团队成员没有尝试新的实践
◆ 团队没有接受尝试敏捷（见5.5节）。
◆ 团队没有可以教团队成员练习的教练（见4.3节）。
◆ 团队感到交付压力太大（见4.7节）。
· 团队成员之间有很多人际冲突
◆ 团队过于频繁地被解散（见4.3节）。
◆ 团队的压力太大（参见4.7节）。
◆ 团队经理需要帮助调解冲突（见4.5节）。
◆ 人力资源政策助长了竞争（见4.9节）。
· 团队成员不合作
◆ 团队没有接受敏捷的尝试（见5.5节）。
◆ 团队成员不够专注或者相处不融洽（见4.3节）。
◆ 团队没有一个可以教团队成员如何协作的教练（见4.3节）。
◆ 工作分配和跟踪假定为个人工作（见4.4节）。
◆ 团队的工作空间不足（见4.6节）。
◆ 团队的压力太大（见4.7节）。
◆ 团队经理正在分配个人工作（见4.5节）。
◆ 人力资源政策提倡个人工作（见4.9节）。
· 团队花费大量时间估计、计划和跟踪工作
◆ 团队被要求使用公司的跟踪工具（见4.3节）。
◆ 团队被要求创建预测性计划或详细的预测（见4.8节）。
◆ 团队需要发展专注的流畅度（见第二部分）。
· 团队的软件不能满足利益相关者的需求
◆ 团队中没有合适的业务代表，或者需要具备更多客户或拥有用户专业知识的人（见4.3节）。
◆ 团队中没有教练可以教团队成员如何与利益相关者合作（见4.3节）。
◆ 团队不能接触利益相关者（见4.4节）。
· 团队难以获得利益相关者的关注
◆ 利益相关者不愿意尝试敏捷（见5.6节）。
◆ 团队不具备所需的客户技能（见4.3节）。
◆ 利益相关者不认为团队的工作是相关的或有价值的（见4.7节）。
· 团队的软件能够满足客户和用户的需求，但却没有取得商业上的成功
◆ 团队没有合适的业务代表或业务专长（见4.3节）。
◆ 团队需要一个更好的目标（见4.7节）。
◆ 团队需要发展优化区流畅度（见第四部分）。
◆ 团队有优化的流畅性，但不能控制其产品计划和支出（见4.4节）。
· 团队的软件发布周期长，有很多漏洞，或者有操作性问题
◆ 该团队没有具备所有交付技能的人（见4.3节）。
◆ 团队没有一个可以教团队成员交付实践的教练（见4.3节）。
◆ 团队需要发展交付区的流畅度（见第三部分）。
◆ 团队有交付区的流畅度，但不能控制其完整的开发、发布和运营过程（见4.4节）。
◆ 团队正在学习如何处理现有的代码（见4.7节）。
· 开发速度比预期的慢
◆ 团队正在完成敏捷前期的工作或仍在学习（见4.1节）。
◆ 团队需要更多的指导（见4.3节）。
◆ 团队的工作空间不足（见4.6节）。
◆ 团队需要发展交付区的流畅度（见第三部分）。
◆ 团队对其开发过程没有控制权（见4.4节）。
◆ 团队正在处理现有的代码（见4.7节）。
◆ 团队受到管理要求的限制（见4.8节）。
◆ 团队受到安全要求的限制（见4.10节）。