Agile/Lean/Project management enthusiast, 一帮精益，敏捷和项目管理爱好者的群体博客
敏捷方法主张各级领导者应当具备“服务型”领导力（servant leadership）。然而我们都知道，服务型领导力非常难得，更常见的领导力是”管理”型。好一点的是”指导型”，再好一点是”辅导型”。一般领导能做到”常辅导、少指导、偶管理”就顶天了。
https://mp.weixin.qq.com/s/6MdIWFlXCX4pPk0cyFVUtQ
服务型领导力是工具， 但用不用取决于其是否与组织发展需要相契合，不契合没必要用
也有情况是，组织的发展确实需要知识型人才&服务型领导力， 但是个别员工内驱力发展缓慢，或者就是要混日子的， 不买服务型领导力的帐，那是员工与组织发展需求[……]
The Agile Manifesto was written in 2001, and it signified the acceptance of the Agile methods. It consists of four values (that we will dig deeper into in this lesson) plus twelve principles that you should read through at some point in time.
Please take a moment to study the[……]
Walk into a factory and you perceive noise, activity and movement. But walk into an organisation that works with digital information — a software development company for example — and you perceive silence, inactivity and stillness. A lot of things are happening, a lot of work is being done, but it i[……]
相信大家在项目运作过程中，一定碰到过多产品线同步开发、多项目并行的场景。我根据在RingCentral的团队运作经验，整理了此篇文章供大家参考、学习交流。
在RingCentral，我所负责的开发团队因致力于各类丰富应用平台的产品集成，团队面临着多产品同步并行的挑战。在实际的开发过程中，曾应用经典的敏捷开发模式，仍然遇到了很多挑战。我和团队经过多种尝试与实践，沉淀出一套方法，并将其命名为Flexagile，是团队一个重要进步的里程碑。
Flexagile不同于Scrum必须跑迭代，不同于SAFe适用于百人的大型团队，也不同于XP、kanban等适合小团队。其适用于多项[……]
许多Scrum团队用用户故事来打造产品的待办事项列表。但是，当某个迭代(sprint)承载一个比较大的故事，可能会引发很多问题。通常建议是把用户故事拆小到团队可以在每个迭代完成6-10个。那么问题来了，为什么要这么做呢？
如果是小的用户故事，团队通常可以在1-3天内完成并且很快就可以从产品经理或者其他干系人那里获得反馈意见或建议，而不是等到迭代末再发出。特别是如果DoD (Definition of Done)包含了验收性测试(UAT)，那就更需要更快速的反馈了。
偷偷告诉你们，程序猿们一般只能比较清晰的记得24小时内写的代码。如果在此期[……]
Neil是”抛弃估算“运动的领军人物之一，这篇文章是他”抛弃估算”系列的开篇之作。
（本文由Agilean学院 张迎辉，高宁，满成圆译，侯伯薇评审）
软件开发中的估算是个庞大的话题，我会在一系列文章中讨论这个话题，这是第一篇。
我们会在很多不同场景下做估算，在这一系列文章中，我会尽可能涵盖所能想到的场景，但观点始终如一：在软件项目中，不应该基于估算做决定。对软件产品提供方及其内部和外部客户而言，有比估算更好的替代方案，既经济又人性化。其中很多方案已应用于公司实践，发布产品给真实客户，并产生了巨大的影响。
考虑到这个话题之繁杂，本文只针对特定场景，即一个scrum团队[……]
很多年了，人们一直在讨论产品经理和产品负责人角色之间的区别。这两个角色是否可以共存，以及应该使用哪一个角色。本文谈谈我对这个问题的一些想法，以及对产品负责人起源的一些思考。
大家都遇到什么问题了呢？
您可能知道，产品负责人源自Scrum，其最大的职责是“最大化产品的价值”。[1]对我来说，这听起来像是教科书上产品管理的职责范畴。尽管如此，产品负责人经常被认为是一个战术角色，负责管理产品Backlog，细化产品需求、以及和开发团队进行协作，那这样的职责定义到底是怎么来的呢？
这些困惑至少部分是自于Scrum 本身，Scrum是一个关注在帮助团[……]
摘要：
本文主要描述Scrum中完成的定义（Definition of Done，DoD）以及验收标准（Acceptance Criteria，AC）的用法。
完成的定义，即DoD不清晰，不仅仅是概念本身可能存在误解，常常由深层次的原因引起的。
每日站会上，团队成员A：“昨天我完成了条目1！今天我将开始工作于条目2上。”两天后，产品负责人找到团队，“条目1怎么回事，这个流程和我想要的并不一样……”上面这个场景，每天都在不同的团队上演着。为什么会发生这样一幕？有可能他们缺少完成的定义与验收标准
“完成”的定义
当产品待办列[……]