因此,我发现自己在包括我在内的四人小团队中工作了几周.我在300多家开发商店的上一份工作发生了相当大的变化,我在那里参与了敏捷方法的采用.
我一直偷偷地介绍像持续集成服务器这样的有用工具,并偷偷摸摸地开始测试驱动开发.
还有哪些其他敏捷项目管理和开发实践适合小型商店？
好吧,对我来说,你的实际配置比100多个开发商店更适合敏捷(不太确定Agile是如何在那里实现的,我很想听到更多关于这个,因为缩放到那个尺寸需要非常高的水平敏捷IMO成熟度).
所以,我的答案实际上是:从4个人开始,所有的价值观和做法都是恰当和有价值的.实际上,您之前采用了哪种敏捷方法？你实施了哪些做法？是什么让你认为他们不合适？
PS:如果可以的话,尝试超越工程实践,敏捷不仅仅是(对于Scrum来说尤其如此).测试驱动开发,持续集成等实践很不错,但它们只是一种手段,而不是目的.它们不足以成功实施敏捷.敏捷是一种面向业务的组织模式.换句话说,技术内容实际上并不是实施Scrum的最佳起点,您应该从组织事物开始.
专注于引入为团队增加最大价值的实践.
由于团队对变化的影响很小,因此如果您与团队合作并展示改进,那么您可以返回并添加另一个 - 再次为团队增加最大价值.
最重要的一点是,项目以敏捷的思维方式接近,在长期项目的背景下添加工具和技术,这些项目无法适应变化并且没有高度调整,客户将无法获得最终结果你应该瞄准.