传统的产品待办项列表(Product Backlog)相对于传统管理办法是一个巨大的进步，但是仍然存在一些问题：
- 只见树木不见林
- 重要的待办项容易淹没在各种细节中
- 看不到全貌因而难以排列优先级
- 并未明显地聚焦于用户需求
而故事图谱是一个可视化Product Backlog的简单工具，有助于解决上述问题，特别是当PB越来越大，越来越复杂的时候。
固定范围、固定交付日期情景下团队盲目做出不能实现的承诺，如何改善？
在我给客户提供需求培训和教练服务时，以及在各种敏捷社区活动中，被多次问到scope fixed，deadline也fixed的时候，团队被强制“承诺”必须完成全部需求，此时除了抱怨还有其它方法吗？我把这类问题定义为“固定范围、固定交付日期情景下团队盲目做出不能实现的承诺，如何改善”的问题。
除了背地里大骂那些经理们无知之外，我们真的无计可施了吗？非也，”THERE IS ALWAYS A WAY OUT”， 我整理了下我在不同场合的回答和思考，做成了一个脑图，敏捷教练不传之秘也，供大家参考。
更多敏捷教练经验观点见 https://www.uperform.cn/blog-article/
如何在每个迭代中满足安全性要求？
某些公司对安全性有着较高的要求。在传统瀑布模式下，会有阶段性的安全检查milestone。但是在引入敏捷，每个迭代都需要交付，满足DoD。那么，security是否也应该是DoD的一部分？如何将安全性要求融入每个短迭代中呢？
参见下列脑图中的一些思考。
更多敏捷教练经验观点见 https://www.uperform.cn/blog-article/
Spotify的新型敏捷矩阵组织：部落、分队、分会和协会
组织导入敏捷往往更加关注形式和标准化，然后却发现不同团队的接受程度不同。 这里介绍了Spotify 的大规模敏捷之路。Spotify是继Pandora之后，国外第二大音乐媒体网站，在从6个人扩张到1200人的过程中，它使用一种了新型的矩阵组织来扩展：部落、分队、分会和协会。
如何理解用户故事INVEST规则中的独立性和破解依赖？
用户故事INVEST规则中的第一个“I”，Independent独立的，是说用户故事应该是自包含的，没有对于其他用户故事的内在依赖。但在实践中，很多人觉得这个基本很难做到，甚至完全不可能，造成很多困惑，那到底该如何理解这条规则呢？
借鉴前人的知识，结合本人的认识和经验，这篇博文从理论和实践角度对此做一个深度剖析，希望能对你有所帮助。
优普丰十年敏捷推广的心得总结
（作者：Bill李国彪；审校：谢炜玮／Jacky申健）
核心看点：
关键时刻：听说并尝试Scrum；成为CSM；翻译第一本Scrum著作；成立优普丰；第一次CSM上海公开课；第一次中国Scrum Gathering大会；结识Vernon史文林；奇虎360公司内训；
关键心得：选正确的事；顺势而为；跟对人；心态开放；拥抱意外的学习；要专注；把手弄脏；快速试错；恒心；社区；善观察；多思考；找对人；
自2007年优普丰敏捷学院成立并开始专注在中国推广敏捷，光阴如梭，已有十个春秋。虽我不善词藻，回想敏捷在这十年中给我以及我身边的朋友、同事、社区的伙伴及各大客户带来的变化和成长、开阔的眼界，以及更积极和正向的思维方式和心态，我抱着感恩之心，不禁想写点什么与大家共勉。如今回顾这一历程，信心不断加持，也鼓舞我们投向未知的但也是无比广阔的未来。
Git命令扫描频繁修改代码热力图以提高代码质量
对于大型复杂架构的产品代码，如何知道哪些是被频繁修改的？哪些不稳定或蕴含了潜在的缺陷或者需要频繁的回归测试，以保证持续交付的质量？如果能根据代码痕迹画出热力图或云图。据此就能找到那些不稳定的模块和代码，调动人员review这些代码，分析导致变动的原因，解决那些不稳定因素，不管是耦合问题，还是抽象层次问题，那么代码的质量会直线上升，程序员工作量就会直线下降。
Git Log加命令行管道
git log命令的结果中包含了所有的提交信息，可以通过参数只筛选出文件名，然后先按照文件名进行排序(sort)，然后用(uniq)命令来统计每个文件名出现的次数，然后再按次数排序(sort)，最后是(head)命令来找出提交次数最多的10个，即是那些被频繁修改的代码文件。
git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10
管道命令可以任意拼接，比如只想从所有C#代码里面来扫描，就再加一个grep管道来过滤即可：
git log --pretty=format: --name-only | grep .cs$ | sort | uniq -c | sort -rg | head -20
Git Effort
如果你在安装GIT命令行时安装了附加工具包git-extras，就可以用git-effort命令来扫描, 它会列出你的仓库中所有文件及提交次数。例如，你可以用下列命令来忽略少于4次提交的文件：
git-effort --above 4
新加坡一家银行的数字化创新：DBS走出石器时代的十条敏捷转型经验
作者：2017年4月4日，Paul Cobban, DBS星展银行首席数字化及转型官
中文版授权翻译团队信息（译者：刘文举；审校：赵瑜、李国彪）
原文链接：http://sina.lt/f2wY
译文链接: https://www.uperform.cn/digital-innovations-singapore-bank-10-lessons-learnt-when-dbs-came-out-of-the-stone-age/
我们在团队创新中吸取的经验
还记得我在DBS的第一天。当我告诉新加坡出租车“叔叔”我要去DBS时，他说道 “DBS-慢得要死。”(“Damn, Bloody, Slow.”)
毫无疑问，2009的DBS银行因其官僚作风盛行、想象力缺乏、反应迟钝而享有盛誉。
我们当时也有了一位新的行政长官Piyush Gupta。他下定决心要扭转这种局面。我们都知道我们该做点改变，但不知道从何入手。
银行业以外的汽车行业给我们带来了灵感，尤其是Kaizen持续改善的理念。Kaizen是由日本管理大师Masaaki Imai 今井正明提出的，它强调的是持续改进的过程，最初应用于汽车生产线。这也是今天我们所读到的精益管理的基础。
在参观日本工厂期间，我们有机会幸会了Masaak imai本人，也看到了持续改进过程在现代制造业中的影响力。但它是否适用于银行呢？我们决定一试。
敏捷项目迭代过程中测出缺陷要不要在看板加一列Bug List?
说说我对于迭代过程中测出bug这件事的看法：先不论开发测试是不是独立团队，也不争论Scrum与看板方法（两者都是遵循精益思想），测出的bug分几种情况处理：
- 如果产品负责人/产品经理判断立刻要改，那么就是个阻塞项，贴红色标记，留在当前列里面不回流，不修好这个item不能称为完成
- 如果判断说根本不是bug，那么直接丢弃
- ROI不高的鸡肋，狠心丢弃（断舍离），实在太纠结就重新回到Product Backlog待办列表一列，待将来重新排期(虽然很可能再也不会改了)
为什么这么做？
有害的“这样效率最高”思维
在与一些人交流时经常碰到对方说，你的方法好是好，就是不如现在的方式效率高，因此并不愿意作出改变。我们来分析下，为什么说这样的思维方式是有害的。