northwzh的专栏

Scrum印记之糟糕的回顾会    敏捷转型已三月有余，是否仍然有些力不从心。            尽管我们深知传统瀑布模式的种种诟病，对闭塞的环境环深恶痛绝，对快速有效的沟通心怀渴望。种种美好的愿望，还请佯装淡定，既然习惯已成，根深蒂固且发芽开花，若奢望敏捷全套方法搬用往往事与愿违。                        一个糟糕的Sprint回顾会。

轮流值班目的：为了保证高效的工作，避免工作被中途频繁打断，故设置轮流值班机制。轮流值班也可帮助每位同学学习其他成员的业务逻辑，一举两得。原则：轮到工作日的同学，不一定非得全部由自己的来解决问题，也可以协助于其他同事，但是必须手动去操作，去查询，去处理。

Scrum手语之看板管理为何一定要用传统墙上看板？看板，乍一眼看上去像是上个世纪的产物，和当下信息化的潮流不太应景。无非是工作的跟踪与管理，相关的产品不再少数。但是这种传统的纸质看板无可替代，整个团队簇拥在一起为了共同的目标而激烈地讨论，众目睽睽下拖动任务卡片，这种议题结果达成的感觉是一个人闷头在电脑前动动鼠标无法比拟的。在看板前，任务的任何问题即使隐匿再深也可以暴露无遗。看板不仅仅可

清晨站立会

传统的项目往往产品从业务方处获取需求，然后产品独自构思prd，邮件给开发和测试。测试组织需求评审，制定排期。开发开始写代码，然后提交测试，提交bug、解决bug，最后开发来上线。这个看似完整的过程存在哪些问题？1.产品拿到的需求真的是业务方想要的吗？这么实现可以带来什么样的效果？对系统性能有无影响？2.开发按照产品意淫的prd就可以戴着耳机，闷头写代码了吗？如果有分歧就只是prd描述的

1.代码定期构建，并自动跑测试用例。2.用于上线的主干的测试用例只包含粗略的业务条线，构建频率可以短一些，每次构建在10分钟内完成。3.详细的测试用例，在分支环境构建，测试用例的粒度可以细致一些。4.一旦构建失败，则由Jenkins显示的最后提交者发起问题的解决。不一定是最后提交者提交代码的问题，但是必须得有此人来发起对问题的追踪。5.构建失败者得公示，如戴着牛仔帽，或者挂着失败勋

青龙是京东物流配送的核心支撑系统，也是京东订单时效的重要保障之一。你是否曾有这样的疑问，配送系统业务流程繁杂、战略项目层出不穷、与日俱增的访问量与背后技术体系需要不断优化……今天我们就来分享京东青龙研发部，是如何运用敏捷精益化的管理方法，实现了产品的快速交付。传统的瀑布模式之所以被诟病，其核心是交付周期长，上线效果弱，用户差评高。而所有问题的根源，就在于无法实现产品的快速，持续交付和快速反馈。我们今

敏捷看板 持续交付 dod wip