多个敏捷团队之间的版本控制
当多个敏捷开发团队在同一个代码库上进行工作时,如何在保证混乱最小化的同时,还能在每个迭代结束时拥有一个干净的、可发布的软件版本?Henrik Kniberg在本文中罗列出了在“Scrum and XP from the Trenches”迷你书中所使用的策略要点。本文并非为版本控制专家编写,而是为我们这些希望进行简单、有效的协作的人所准备的。
当多个敏捷开发团队在同一个代码库上进行工作时,如何在保证混乱最小化的同时,还能在每个迭代结束时拥有一个干净的、可发布的软件版本?Henrik Kniberg在本文中罗列出了在“Scrum and XP from the Trenches”迷你书中所使用的策略要点。本文并非为版本控制专家编写,而是为我们这些希望进行简单、有效的协作的人所准备的。
Yahoo!的extremeprogramming讨论组中正在进行关于简单化设计的讨论,而且有人给出了不少有用的推荐资料。讨论的开始源于对增量式设计参考资料的请求,很快就演变为如何成功地实施增量式设计。
领导者们常常由于时间的压力,会向团队抛出最先想到的问题。不过经过一点反思之后,一个开放的明智问题可以为陷入困境的团队带来更多新的可能。这种有几个世纪历史的教育技巧,有时被称为“强力问题”,对所有的团队成员来说都是一种有力的工具,可以将“困境”转化为学习的机会。

前不久,InfoQ中文站上发表了一篇文章:Scrum在中国——企业实施情况调查实录,引起了激烈争论。在本文中,作者会对调查报告中的案例分类进行分析、诊断。并探讨什么是敏捷开发方法、什么是SCRUM、使用敏捷方法需要什么条件、它可以解决什么问题以及如何在团队中合理的使用敏捷方法。

敏捷的“自组织团队”模式需要团队成员们具备新的技能——包括他们曾寄希望于项目经理具备的人际交往技能。此时,管理不再是多余的东西,它对帮助团队学习新的沟通和协作方式起到了非常重要的作用。本文为如何传授新的技巧给出了一些策略,并提供了一些相关资源。

在本文中,InfoQ中文站就Scrum实施情况与国内一些企业的相关人士进行了问卷调查。从调查结果中我们选出了5个比较有代表性的案例。希望这篇文章可以让尚未接触敏捷实践,或者在推广敏捷实践中碰到困境的读者有所收获。

管理顾问Johanna Rothman帮助她的客户管理风险:包括项目中人员的风险,人员管理方式的风险,或是项目自身的风险。在这次采访中,她谈论了包含在她的新书《Manage It! Your Guide to Modern Pragmatic Project Management》中,对于处于不同敏捷度时期的所有团队都有效的降低风险的策略。

Scrum的创建人Jeff Sutherland估计每个工作日,大概会有120,000个Scrum团队在开展每日立会。但其中有多少是真正在实施Scrum呢?在QCon 2006伦敦会议上,他谈到了“诺基亚测试”,而且他喜欢用其来甄别团队是否在实施敏捷或仅仅是迭代过程,甚或两者都没有实施!他还揭示了在Scrum和火星探测机器人之间的联系。

有证据表明,Scrum已经成为发展最快的敏捷方法了,在原来的Scrum书中都有关于这套方法的详细介绍,但这些书人们常常读完一次就放在一边了。SPRiNT-iT的敏捷教练们从长期的实践中抽取了Scrum的基本要素,为大家献上这样一份简练的参考资料,帮助团队更有效地推动所有的Scrum会议,并创造Scrum成果。这本书的目的不是为了进行Scrum教学,而是为了给接受过培训的团队带来信心,让他们轻车上路,成功启动最初的Sprints——这些成功将帮助他们的组织更亲密地拥抱Scrum。

如何设计能深刻反映业务领域的领域模型?领域模型设计的未来发展方向是什么?……本书是Eric Evans的《领域驱动模型》一书的精简版,让你在短时间内理解领域驱动设计的内容。这本书没有介绍任何新的概念,它只是概要总结了领域驱动设计的本质,抽取了Eric Evans原书中关于这一主题的大部分内容,以及其他相关资料。这本书可以让你快速了解领域驱动设计的基础知识,但不能替代Eric书中提供的大量事例和案例研究或者Jimmy书中提供的动手事例等。