敏捷研发

对于任何敏捷过程来说，团队协作都是核心。 敏捷宣言告诉我们“个体与交互比流程与工具更有价值”，这时指优秀的软件出自优秀的团队。 Scrum团队一成俱成，一败俱败。这里没有“我的工作”和“你的工作”，只

敏捷项目管理中，如何进行故事估点？ 在敏捷项目管理中，我们常会在对于用户故事进行评审的时候，提到一个词，那就是故事估点。 这篇文章我们就聊一聊，敏捷开发中的故事点是什么？以及如何进行故事估点。 先说概

本篇文章哦我们呢讲讲如何利用每日站会，更好地促进团队有效协作和聚焦，促进需求的顺畅流动和交付，同时及时地暴露问题和风险。 在之前的文章“敏捷 | 看板与站会”简单提到过站会的问题，接下来文章将就每日站

需求管理，是产品或项目管理的核心，需求定义了项目或产品的工作范围便捷，从而决定了其最终价值。 需求管理主要有这几个部分，收集-定义分析-拆解规划-编码开发-变更。 接下来，我们就需求管理的全流程在【鲸

在软件开发过程当中，度量是一个始终无法绕开的问题，管理学大师彼得·德鲁克曾经说过“你如果无法度量它，就无法管理它”，要想有效的管理，有效的度量体系就显得非常必要。有效的度量体系既要面向价值又要面向实施

在软件开发中，最重要的核心是什么？当然是用户故事。 无论是产品经理，还是开发工程师，项目经理，都是围绕着用户故事来展开工作的。在团队使用鲸舟敏捷研发管理平台时，我们发现团队在使用存在诸多问题，为了方便

仁和在线服务团队运用鲸舟工具管理了2个迭代，迭代计划非常明确，每个迭代的版本计划由PO、DM提前规划。 团队成员在迭代冲刺过程中，清楚每个阶段工作优先级。团队围绕故事进行紧密协作，高效完成迭代计划。

当组织需要实施变革时，会实施“变革计划”。变革要有规划，有明确的开始和结束日期，然后组织严格按此实施。 不过是即将实施Scrum，还是准备对已有Scrum的实施进行微调，你都要用敏捷的方式来管理这些工

团队和组织会因为诸多原因而抵制Scrum，反对实施Scrum的其中一个可能原因就是不理解Scrum项目中的新角色。 ScrumMaster和产品负责人的角色都是崭新的，他们在转型前的组织中没有相对应的

如果你对Scrum有所了解，你就会发现Scrum并不明确地说明需不需要测试（以至于，有些人误以为敏捷开发不需要测试），也不会说需要通过结对编程还是测试驱动的方式写代码。 Scrum所要求的是团队在每个

自组织是敏捷软件开发的基本观念。 敏捷宣言有一个原则“最好的架构、需求和设计出于自组织团队”，然而一个普遍的误解是，因为对自组织团队的依赖，敏捷团队带头人的角色将不存在或被弱化。但事实并非如此。 自组

Scrum中的燃尽图是什么？ 燃尽图是剩余工作随时间变化的图形表示。它通常用于敏捷软件开发方法，例如Scrum。但是，燃尽图可以用于包含随时间推移可衡量的进度的任何项目。 通常，在燃尽图中，杰出的工作

对于任何敏捷过程来说，团队协作都是核心。 敏捷宣言告诉我们“个体与交互比流程与工具更有价值”，这时指优秀的软件出自优秀的团队。 Scrum团队一成俱成，一败俱败。这里没有“我的工作”和“你的工作”，只

不少公司都在考虑采用敏捷开发，或者在项目开发过程中融入敏捷的思想，在这里，我列出几个常见的误区，希望能对大家有所帮助。 误区1：敏捷开发 == 极限编程/Scrum/… 敏捷开发是一种方法论，只是一些

软件开发中我们通常都会有一个发布计划，以便对产品的发布节奏和最终交付日期有了一个详细的规划，确保产品管理以及如期交付高质量产品。 创建发布计划需要以下步骤： 确定迭代长度 估算速率 给故事安排优先级

Scrum中有三个主要角色：产品负责人、研发团队、Scrum Master，从Scrum框架来看，确实不存在项目经理，另外，也有很多人指出Scrum提倡自组织，没有项目经理才是合理正常的。 还有一种常

无论说你是ScrumMaster、项目经理、产品负责人或团队成员，还是只是想回答“我如何在现实世界中运行敏捷Scrum项目”这个问题的人，相信这个问题可以可以给你答案。 瀑布式项目管理 传统的项目管理

对敏捷开发常见的抱怨 1、敏捷开发只看到眼前，看不到下一步 成熟敏捷团队能持续规划后续2~3个版本的大致范围，给团队明确的方向。 2、一堆零散的故事，缺少需求全景图 产品或方案作为一个整体，应提供所有

我们都知道Scrum是比较常用的一种敏捷开发框架，是一个用于组织和管理工作的框架。 Scrum开发工作包含一个或多个'Scrum'团队，每个团队由三个Scrum角色组成：产品负责人、ScrumMast

日常开发活动中，经常会遇到客户临时加塞需求，或因业务变动，领导突然要变更需求的情况。作为团队负责人或者产品负责人常会碰见这样的场景： 这个需求必须尽快上，不然影响业务推进； 用户反馈产品出现一个小BU