因此,我发现自己在一个四人小组中工作了几个星期,包括我在内。与我上一份在300+开发者商店的工作相比有了很大的变化,在那里我参与了敏捷方法论的采用。
我一直在悄悄地介绍一些有用的工具,比如持续集成服务器,并且正在悄悄地开始测试驱动开发。
其他哪些敏捷项目管理和开发实践适用于较小的商店?
发布于 2009-11-27 07:31:01
嗯,对我来说,你的实际配置比300+开发者商店更适合敏捷(我不太确定敏捷是如何在那里实现的,我很乐意听到更多关于这方面的信息,因为扩展到这种规模需要在敏捷国际上达到非常高的成熟度)。
所以,我的答案实际上是:从4个人开始,所有的价值观和实践都是适当的和有价值的。实际上,您之前采用的是哪种敏捷方法?您实现了哪些实践?是什么让你觉得它们不合适呢?
PS:如果我可以的话,试着看看工程实践之外,敏捷不是(仅仅)关于那个的(这对于Scrum来说尤其如此)。测试驱动开发、持续集成等实践很不错,但它们只是一种手段,而不是目的。它们不足以实现成功的敏捷实现。敏捷是一种面向业务的组织模式。换句话说,在实现Scrum时,技术方面的东西并不是最好的起点,你应该从组织上的东西开始。
发布于 2009-11-27 06:18:44
IMHO所有的开发实践都是适当的。事实上,在很长一段时间里,敏捷团队都被认为是一个小团队(5-9人)。有一个关于它的infoq的artile。
此外,因为你有一个小团队,沟通和协作将变得更容易,因此实践将会更好地工作。
发布于 2009-11-27 07:49:30
重点介绍将most value添加到团队中的实践。
由于团队的影响很小,变化的影响将是非常明显的,如果你和团队一起工作,improvements,那么你可以返回并添加另一个-同样是为团队增加最大价值的那个。
最重要的一件事是,项目是以敏捷的心态来处理的,,在不能适应变化的长期项目的上下文中添加工具和技术,并且与客户的调整不是很高,不会有你应该达到的最终结果。
https://stackoverflow.com/questions/1805867
复制相似问题