业务分析师在敏捷项目中的作用
Software Education的首席知识官Shane Hustie点明了一个敏捷的迷思——我们不需要业务分析人员，同时他指出：只要以正确的方式向业务看齐，而不是以开发团队为导向，业务分析师就可以帮助敏捷团队成功。
InfoQ
主题/标签专用视图
补充实践 Content on InfoQ
最新“补充实践”相关专题内容
“补充实践”相关新闻
SOA实现中的4个最差实践
在铺天盖地的SOA宣传文章中，最佳实践是出现频率最高的词汇之一。相比起来，最差实践就没那么风光了。但是，俗话说得好“吃一堑，长一智”，看看别人犯过的错，未尝对自己没有帮助。最近，Information Builders的市场副总裁Jake Freivald就撰文介绍了SOA实现中常见的4种最差实践，并针对每个实践给出了解决方案。
从利润出发，排定（待办事宜）优先级
觉得排定优先级很困难么？Luke Hohmann描述了一种做出定量决策的方法，有助于决定处理待办事宜的先后顺序。除了要考虑像实现所需工作量这样的常用属性之外，Luke建议加入新的属性，来衡量干系人的需要、向战略看齐，并且检查某个条目是否能够驱动利润。
采纳敏捷时，过于滥情会造成障碍
在采纳敏捷时陷入困境了么？Amr Elssamadisy主持了一个话题讨论，主题是关于造成采纳敏捷流程很困难的原因。他为听众提供了三种模型，用以理解在采纳敏捷时可能见到的问题。
敏捷项目中的跟踪矩阵
通过分析跟踪矩阵的关联，人们能够很容易地分析需求变化所造成的影响。那么，跟踪矩阵在敏捷项目中有用武之地吗？本文从众多博客和邮件讨论组中选取了不同的观点，为这个问题寻找答案。
“补充实践”相关文章
剖析短迭代
Valtech的敏捷教练Dave Nicolette提出：短迭代的效果要好过长迭代。Dave证明：短迭代可以更快响应变化，同时提供更多发现和解决问题的机会。此外，Dave还说明了诸如短迭代可能使人筋疲力尽以及其他一些问题。
M三兄弟－精益三人组
关于软件开发中应用精益原则的讨论，大部分集中在识别和消除浪费（浪费在日语中叫作：muda）。同样，精益思考的目标是消除过重的负担（过重的负担在日语中叫作：muri）和不必要的变化（不必要的变化在日语中叫作：mura）。Roman Pichler对“Ｍ三兄弟”之间的关系进行了讨论，并建议将消除过重的负担作为走上精益之路的第一步。
将看板应用于软件开发：从敏捷到精益
许多团队仅对软件价值流（software value stream）的一部分做了优化，但是Kenji Hiranabe向我们展示了如何将精益生产中的看板跟踪系统嫁接到软件开发中，以便与更多的组织结构进行沟通。
如何设计优秀的伙伴关系合约?
敏捷教练Michael Spayd告诉我们：不管是承包商还是永久雇员，都可以担任“咨询师”的角色，并且应该思考与客户一起制定咨询合同或是设计伙伴关系——不是为了完成金钱交易，而是按照“咨询师”自己的价值观与喜好来工作，并要帮助客户产出卓越的绩效。