Scrum敏捷项目管理

黄盘–团队中心敏捷软件开发

在本书的开头,艾伦·凯利(Allan Kelly)将黄盘描述为一种方法和一种哲学,他关于软件如何或应该如何创建以及敏捷如何或应该如何工作的哲学。如果Xanpan基本上是XP(极限编程)和看板的结合,则它包含其他敏捷和精益方法的思想和技术,着重于团队应如何协同工作以提供更好的软件和价值。

本书解释了如何将Xanpan原理和观点应用于敏捷软件开发的所有方面,例如计划和评估。它还提出了一套应有助于团队的技术和非技术实践。 Xanpan还提供了一个计划,可以在接下来的两周迭代之后进行计划,从而使团队对下一个季度将要完成的工作有更深入的了解,甚至可以进一步了解路线图。本书最有趣的部分是最终附录,其中艾伦·凯利(Allan Kelly)讨论了自己对软件质量的定义并提出了“quality 上 ion”.

xanpan

通过本书Xanpan,Allan Kelly提出了他自己的关于敏捷软件开发的非常有趣的个人观点。我将这本书推荐给每位ScrumMaster,Agile Coach或软件开发人员,他们认为改善团队的软件开发流程与其说是盲目采用新方法,不如说是对当前流程进行正确的更改。

参考: 黄盘–Team Centric敏捷软件,Allan Kelly,200页, http://leanpub.com/xanpan
网站: http://www.xanpan.org

行情

说Xanpan以团队为中心,也有助于调和Xanpan内部的冲突。一方面,Xanpan是团队可以选择和使用的过程。另一方面,Xanpan的目的是说“创建自己的流程,不要遵循别人的处方。”如果说Xanpan的本质是团队,那么可以说建立并积极创建并同意他们自己的流程的任何团队都将跟随Xanpan。

当然,没有团队运动可以使每个场上的球员在比赛的任何时刻都无法准确地知道得分。然而,在软件开发中,找到不知道下一个截止日期或其同事在做什么的团队成员并不少见。找不到对即将开展的工作或离开工作后实际情况没有洞察力的管理人员也很常见。

对于一个严格的Scrum团队而言,没有工作结转的问题,因为团队只承诺他们保证会完成的工作,因此所有承诺的工作都已完成。虽然许多Scrum团队发现从sprint到sprint anathema的过渡都需要进行工作,但我还是建议团队进行工作。确实,继续开展工作以改善人流是Xanpan的主要特征。对于Xanpan团队来说,工作结转已成事实。作为计划会议之前的审核过程的一部分,团队应查看从结束迭代到董事会剩余的工作,并确定哪些工作(如果有的话)将被延续到下一个迭代。

英国几乎所有的金融产品都带有警告:“过去的表现并不代表未来的表现”,或类似的措辞。与金融服务不同,在软件开发中情况相反:“过去的表现是未来表现的良好指标”。该声明有其自身的警告:“…未提供任何重大更改”。找出对您的团队而言“重要”的因素。常见的例子包括人们离开团队,团队以不适当的速度扩展,工作流改变方向或被破坏,其他资源突然变得不可用等。这是双向的。如果事情进展不顺利,那么积极的思考和领导的劝告都不会使事情顺利。除非您采取措施解决所发现的问题,否则它们不会突然得到解决。也不会仅仅因为您声明自己正在执行敏捷,Scrum,Xanpan或其他任何操作而修复它们。同样,如果一切顺利,则可以合理预期它们继续前进。可以确定程度地预测未来的交付量和进度–如果您掌握正确的技术。

尽管代码审查的大部分好处仅在于让第二只眼睛阅读代码,– but very valuable –好处是被评审者和评审者共享知识和学习。代码审查使个人暴露于替代做法和模式,并允许讨论更好的做法。同样,自动或电子媒介的评论可能会阻碍此类讨论。