敏捷开发 敏捷个人
上周，我在爱丁堡与Gil Broza一起讲授了有影响力的敏捷领导者研讨会。 （这就是为什么我很安静。我正在旅行和教学。没有时间写，写博客或发推文了。）
一名参与者问我对敏捷扩展的想法。 在我无法解释小世界网络而不是层次结构之前 ，他说：“我确信您扩展敏捷的方式已经完成，而不是逐步发展。
好吧，用羽毛把我吹倒。 他说的比我简单。
如果您看一下我对技术项目团队的了解，就会发现它是如何工作的。
具有实践社区的技术计划
如果可以，则技术计划团队只有一个功能团队。 Joe，Tim和Henry都有独立的功能团队。
如果由于使用相关功能而需要“收集”它们，则可以自行收集。 萨莉（Sally）召集了特色团队。
该团队向外扩展，在技术层面，没有上升。 技术计划团队不必扩大规模。 过去运行程序时，我通过电子邮件将程序团队会议议程（这是一个解决问题的会议）发送给所有人，然后说：“这是我需要参加的人员。 其他人：让我知道您是否参加。”
现在，对于软件程序或硬件程序而言，程序的大小是有限制的。 在某些时候，协调相互依存非常困难，不值得这样做。
如果团队一直在提供小的功能，那么您所需要的人员就不会像您想象的那样多。 批量越小，所需的人员就越少。 您的动力将会更大。 如果您不相信我，请考虑一两分钟。
当您认为扩展敏捷时，请考虑一下，而不是向上。 您使用小型世界网络，当您说“想一想，而不是想起”时，这是一个非常好的口号。
翻译自: https://www.javacodegeeks.com/2014/05/scaling-agile-think-out-not-up.html
敏捷开发 敏捷个人