业务分析师在敏捷项目中的作用
Software Education的首席知识官Shane Hustie点明了一个敏捷的迷思——我们不需要业务分析人员，同时他指出：只要以正确的方式向业务看齐，而不是以开发团队为导向，业务分析师就可以帮助敏捷团队成功。
InfoQ
InfoQ
促进软件开发领域知识与创新的传播
主题/标签专用视图
补充实践相关的内容
最新“补充实践”相关专题内容
“补充实践”相关新闻
价值流图适用于软件开发吗？
价值流图是精益制造中用于分析物流和信息流的方法，为客户提供产品或服务时这是必须的。丰田成功地在制造业中实现了这个过程，同时价值流图也已经映射到软件开发中。软件开发与制造业使用的是相同方法吗？
我们能把敏捷规则改变为指导方针吗？
规则通常是一项活动的已定义的标准，要求大家遵照执行。换句话说，通俗地讲法律也可称为一种“规则”。另一方面，指导方针则尝试着根据一系列的常规程序来精简出特定的流程。根据定义，指导方针永远不是强制性的。那么敏捷团队应该制订规则呢，还是只要指导方针就够了？
回顾之回顾
当你的所有团队都使用敏捷、忙于实施本地改进之时，在过去被称作“IT”或者“系统开发”的更大范围的组织中，会发生什么？一位大型敏捷项目组的教练分享了一个策略，他们打算让更大范围的团队发现趋势并从所有这些知识中获益。Paulo Carol将其称作“回顾之回顾”。
SOA实现中的4个最差实践
在铺天盖地的SOA宣传文章中，最佳实践是出现频率最高的词汇之一。相比起来，最差实践就没那么风光了。但是，俗话说得好“吃一堑，长一智”，看看别人犯过的错，未尝对自己没有帮助。最近，Information Builders的市场副总裁Jake Freivald就撰文介绍了SOA实现中常见的4种最差实践，并针对每个实践给出了解决方案。
“补充实践”相关文章
剖析短迭代
Valtech的敏捷教练Dave Nicolette提出：短迭代的效果要好过长迭代。Dave证明：短迭代可以更快响应变化，同时提供更多发现和解决问题的机会。此外，Dave还说明了诸如短迭代可能使人筋疲力尽以及其他一些问题。
M三兄弟－精益三人组
关于软件开发中应用精益原则的讨论，大部分集中在识别和消除浪费（浪费在日语中叫作：muda）。同样，精益思考的目标是消除过重的负担（过重的负担在日语中叫作：muri）和不必要的变化（不必要的变化在日语中叫作：mura）。Roman Pichler对“Ｍ三兄弟”之间的关系进行了讨论，并建议将消除过重的负担作为走上精益之路的第一步。
将看板应用于软件开发：从敏捷到精益
许多团队仅对软件价值流（software value stream）的一部分做了优化，但是Kenji Hiranabe向我们展示了如何将精益生产中的看板跟踪系统嫁接到软件开发中，以便与更多的组织结构进行沟通。
如何设计优秀的伙伴关系合约?
敏捷教练Michael Spayd告诉我们：不管是承包商还是永久雇员，都可以担任“咨询师”的角色，并且应该思考与客户一起制定咨询合同或是设计伙伴关系——不是为了完成金钱交易，而是按照“咨询师”自己的价值观与喜好来工作，并要帮助客户产出卓越的绩效。