敏捷研发

从发展社会主义到外企进入，无数的案例告诉我们，照猫画虎，原样照搬在这里是很难行得通，需要进一步特色化，才能更好的发挥作用。 敏捷开发也是同样如此。 敏捷开发是一种轻量敏捷，第一原则是快，何谓快呢？不是

其实这个问题也是和小兵聊出来的，他问我敏捷的终点是什么？或者说团队究竟要做到什么程度才算是真的敏捷。 我的第一反应是这是个好问题，但却不简单，相反，它是一个复杂问题，并不是可以通过单一的标准判断。我觉

如何确保快速获取反馈？ 原型验证 何时用草图？何时用中保真原型？ 草图原型，简单、便宜、快捷，可一边讨论一边画，想法随时落地为可见的草图，方便精准传达各方意图，并且可及时与业务方确认想法。 中保真原型

日前，七月9日，Digital.ai发布了全球敏捷状态报告，这是该系列第15份报告，Agilean咨询团队第一时间翻译了这份23页的报告，作为一个敏捷思想的践行者和推广者，笔者第一时间阅读了这份报告，

Scrum是一个高效、有质量的迭代。 能够高效、有质量地交付每一个迭代计划的目标，是一个敏捷团队成熟的标志。 如何管理好迭代容量是迭代成功的关键，也是一个难题！ 敏捷、Scrum如何快速适应变化 Sc

精益看板管理五大实践 限制在制品:加速流动、显露问题，激发协作 管理价值流动:即时、有效地发现和处理问题、阻塞，让团队顺畅运作 建立度量体系并持续改进:指导深层次改进，渐进性演进 可视化价值流:可视化

敏捷方法或设计思维有着相似的理念：收集客户的反馈并采用迭代方法进行设计，以激发灵感，帮助团队规避错误，产生更好、更快、更出色的产品。

从需求梳理会到迭代回顾，这整个过程再加上敏捷推荐的5个价值观，便是Scrum 的3-3-5-5框架。所以迭代的5个关键活动（会议）是整个团队协作的基础，也是团队及敏捷非常重要的实践。

迭代计划会 目的 团队明确一个短周期内的承诺的交付范围，符合团队的实际容量 所有工作有明确的责任人 一般在迭代第1天商务召开，PO、DM、Team全员参与，由DM主导 活动 对需求梳理会上未解答的遗留

在敏捷迭代中，产品经理和团队需要对从用户、客户和其他干系人那里获得的需求进行梳理，以便程序开发人员进行开发活动。 上图是Scrum框架，在Scrum中，产品经理形成产品代办清单，团队成员自主选择该迭代

在产品开发过程中，我们需要在多个层级上进行产品规划，对产品需求功能进行分析，拆解，以及模块化，将模块化的业务价值拆分成更小、更详细的PBI，直到用户故事足够小，足够详细，是可以放入一个迭代中的用户故事

敏捷开发过程重视团队的交流与管理问题，其提高开发效率的显著成果，使得敏捷开发逐渐成为继瀑布式开发之后，最为流行的软件开发方式，其中，Scrum过程无疑是目前最为成功的敏捷方法。 它强调小团队、多交流、

用户故事是可用于陈述业务价值的一种简便格式，适合各种PBI，特别是特性。用户故事的制作方式旨在帮助业务人员与技术人员双方都能理解需求。 用户故事的结构很简单，为会话提供了一个立项的占位符，同时，也可以

敏捷研发工作中，如何拆分用户故事，如何让迭代中的用户故事更适合在迭代中开发交付？以及好的用户故事需要有哪些特征？ 这些是在敏捷实践中，常遇到的问题。接下来，这篇文章我们就来一起探讨一下敏捷项目中用户故

Scrum敏捷中，建议是2～４周一个迭代周期，但并没有说规定，必须是两周或者四周具体的迭代周期还是需要团队人员根据项目计划任务作出适应性的调整。 在敏捷状态的报告中，可以看到采用Scrum敏捷的团队中

用户故事是可用于陈述业务价值的一种简便格式，适合各种PBI，特别是特性。用户故事的制作方式旨在帮助业务人员与技术人员双方都能理解需求。

在敏捷项目管理中，我们常会在对于用户故事进行评审的时候，提到一个词，那就是故事估点。 这篇文章我们就聊一聊，敏捷开发中的故事点是什么？以及如何进行故事估点。 先说概念。 复杂度包括功能的难易程度、风险