|
|
3 回复 | 直到 12 年前
|
1
3
首先,到目前为止,我已经在做3个或多或少的Scrum项目。 There are a couple of unclear things in your story. 公司的目标是开发图书馆或最终产品?对我来说,这两者似乎相当矛盾,尤其是对一家小公司而言。 另一件事是,在没有任何真正用户的情况下,从一个库开始开发对我来说并不是很灵活。在我看来,一个敏捷的设置将从另一个角度开始:首先开发一个具体的产品,根据具体情况重构设计,以可能达到某种分层的架构,其中较低的层可以被提取到一个可重用的库中。然后,开始开发更多具体的产品,寻找在项目之间重用代码的可能性,并根据客户(产品开发团队)的具体使用和需求再次改进公共库的设计。 在某种程度上,图书馆开发可能需要它自己的团队——在开始时,可以让它的设计和积压工作在不同的团队之间进行协调。 |
|
2
1
关于您的关于团队相互开发代码的问题-这就是源代码管理的目的。为新的东西叉子,然后在下一个冲刺重新融入和稳定。 关于第二季度,Scrum是一种增量方法,因此如果设计适合于增量的工作部分,那么它当然是合适的。 关于第三季度,雇佣“在他们内部工作很好并且他们想与之合作的人”是一件很糟糕的事情吗? |
|
|
3
1
团队组织和系统结构高度依赖。 See Conway's Law 这意味着,要让两个独立的团队处理两个独立的代码模块(库团队和产品团队),您需要在团队之间有一个明确定义的通信通道,因此,开发的代码将在设计中反映这些通道。传统上,这意味着您最终为库定义一个API或接口,该接口的作用就像每个团队可以开发的契约。敏捷实践通常采用更紧急的设计理念,因此很难创建一个有意义的API。 大多数敏捷团队解决这一问题的方法是将开发时间限制在可管理的增量上。因此,虽然设计整个API可能是不现实的,但产品团队和库团队可能会就一个API设计达成一致意见,该设计足以满足2周的工作需要。编写代码,部署,为下一个迭代设计,然后重复。这样就建立了团队和代码模块之间的通信路径,这样两个团队就可以独立工作,而不必相互干涉。 我最近看到的另一个选择是让更大的团队使用看板/有限的WIP流程进行管理。让每个人都在同一个团队中,通过看板管理,可以实现更有机、更灵活的自我组织,这意味着您的系统能够更容易地发展。通过保持工作在进行中高度可见,它增加了通信,并且通过限制正在进行中的工作,您限制了开发人员通过保持系统在任何一个方向上进化得太远而相互击倒对方。结合一个坚实的风投,你应该很好去。 最后,另一个选择是,在深入开发之前,您需要花一些时间来真正考虑您的体系结构。使用软件体系结构设计过程,如 Architecture Centric Design Methodology (acdm)在有限的“spike 0”类型的角色中,可以帮助您解决在允许紧急设计时通常遇到的许多问题。在设计冲刺结束时,您将能够制定一个对您需要做的事情更有意义的计划。And remember, just because it's a design phase doesn't mean you don't write code - quite the opposite. ACDM强烈主张实验。 |
