zhaoenweiex的博客

前言现状问题改进目标具体思路相关计划

前言最近在看《深入核心的敏捷开发》这本书，发现确实有不少干货的，能够解答我不少问题，特别是其中对于展示会的论述很到位。七宗罪准备工作没做好由于参与展示会的目的是展示迭代成果，参与人员大多是关系到项目成功与否的关键人物，因此会有不少的上级领导或客户代表等大佬，他们时间都很忙，所以如果到了预约时间无法进行演示那么情况就不好了，你能想象你的老板盯着你花了半小时才的启动好系统，却发现数据不对么？可能给团队带来极为负面的影响。没有上下文铺垫同样的原因参与展示会的大佬普遍缺乏对于本周期的任务的了解，所以你直

总体业务价值和目标这里主要是记录项目完成给公司点来的业务价值或收益。主要内容【迭代范围（做哪些，不做哪些）】这里是相对具体的工作内容，最好是一个表格形式，当然项目启动时不需要太详细只要让大家了解大体的内容即可。验收通过准则（AC，DoD）这个是通用的验收标准，每个周期如何掩饰，单元测试覆盖率，自动化测试覆盖率，以及完成的定义。关键节点与里程碑（版本发布说明）有哪些发布版本，哪个版本发...

要限制业务团队或PO变化需求的次数和周期内变化程度测试如果能协助开发定位测试出的问题的话，会有绩效加分测试被打回后会对整个团队的绩效产生影响开发团队要尽量做到bug日清沟通和流程也要直接反馈团队文化有责无界，有责任划分，但解决问题却没有边界可以采用Credit Point的形式（虚拟货币）来提高价值导向测试要给开发一个敏捷的反馈，加快反馈流程...

前言敏捷落地在我们团队落地已经接近五年了，作为一个相对成熟的团队，不少问题也浮现了出来，比如不少团队成员对于未来缺乏长期规划和工作上也相对的缺乏热情和激情。团队大多都忙于应对项目上的工作，对于个人自身的成长关注度不足，存在温水煮青蛙的危险。最近一直在寻找合适的手段来帮助大家突破困局，再一次激活团队，发现OKR是一个不错的途径于是开始着手学习，并尝试着实践。目前刚刚开始，先把一些思考记录在这以便帮...

前言本文主要是记录并分享一次敏捷团队的改进过程以及如何面对和处理不太理想的改进措施。背景团队接触敏捷开发已经超过4年了。分为两个相对独立的两个项目团队管理，每个团队有相对成熟的技术负责人带队。改进的提出考虑到新年后的第一周，大家显然都无法进入状态，所以第一周就留给大家调整，而没有安排开发周期，最后一天我们还进行了某个领域的全年复盘，复盘具体内容就不提了，最后开发团队成员反馈，每周要花...

前言本文将探讨一个所有软件开发者都头疼的问题，那就是项目计划和其中涉及到的估算。任何一个项目都离不开项目计划，但绝大多数项目计划都不怎么靠谱。以前已经有一篇文章讲了计划会议的实践，这里是传送门。但项目计划并不是简单的计划会议，而是一整套的活动才能确定的。接下来就结合经典的敏捷开发方法论以及我们团队的实践来看看在敏捷开发里项目计划和估算的实践方式是否能够给你带来一点启示。内容敏捷计划的特点首...

前言近几年敏捷开发犹如旋风一般刮过国内的软件开发公司，不管是一线互联网大厂，还是大型国企亦或是二三十人的小公司几乎都已经或试图尝试敏捷，但搞多的团队绝大多数都失败了。本周作者结合自身团队经验说一下在导入敏捷之前需要做的几件事。其实这类题目已经差不多写烂了，但大多都是集中在理论上，实际使用遇到不少问题，所以这篇文章讲的主要是实施层面，至于原理有时间再讨论。先决条件1.你是谁？敏捷活动的推动者...

前言这段时间我发现我们有一部分团队成员在解决小问题时做的还不错，但面对规模稍微大一些的问题时总是感觉找不到门的感觉，所以借着这个机会介绍一下我比较推崇的解决思路。这篇文章将从下面几部分展开讨论。 为什么分享思路的原则具体的解决思路思路主要分为下面四个阶段 1确认阶段 我们要解决什么问题 问题清晰么？ 干系人跟我的意见一致么 问题解决到什么程度2分...

项目不太可能一帆风顺的进行到验收，而是充满了变数，愿望是美好的，但现实是残酷的。所以这一次我想跟大家介绍一下如何团队如何面对失败的SprintSprint的成败实际上没有泾渭分明的一条线，除非团队跟PO在做计划会议时就约定Sprint目标。 所谓Sprint目标就是PO确定的本Sprint最重要的任务项，没有完成目标，那么做多少其他工作也是枉然。

前言敏捷开发已经有着超过20年的历史，国内也热起来有五年了，理论和方法学的文章网上数不胜数，但真正深入解决问题的却少之又少，全靠团队自己琢磨，比如下面我们要讨论的如何解决敏捷化开发和需求跟踪和记录的问题。这篇文章我们主要讨论需求管理是如何在敏捷团队中落地，也就是如何才能不损害团队敏捷流程的前提下更好的完成需求的跟踪和记录。 PS:本文作者，zhaoenweiex，拥有近5年的敏捷团队管理实践

程序员最痛苦的几件事:1.别人不写文档,2.别人不写注释,3.我要写文档，4.我要写注释。这虽然是个笑话但也能看出开发人员对于文档的本能的抗拒。本文就结合作者的实践来介绍一下敏捷文档实践的几个思路。

这次我们介绍一下在敏捷开发中我们如何进行任务的估算，简单来说就是确定一项工作到底需要多少资源（一般是人*天）。凡是做软件开发都离不开任务的估算，因为老板总是希望你能告诉他这个系统或软件什么时候能完成，大概需要多少人，这个工作一般都是费力不讨好的活，很难估计，因为估计值根据需求，开发团队的技术水平，人员状态都有密切的关系。

我们团队引入敏捷已经超过2年了，经过长时间的不断尝试逐渐摸索出一套适应于我们团队的方法论，即计划会议+看板+每日站会+评审演示+回顾会议。上一篇介绍了我们如何进行计划会议，这一篇我们介绍一下如何进行每日站会。每日站会是敏捷团队中最有代表性和最有仪式感的团队活动，可以简单的理解为团队成员每天进行站立式的会议。

前言我们引入敏捷已经超过2年了，经过长时间的不断尝试逐渐摸索出一套适应于我们团队的方法论，即计划会议+看板+每日站会+评审演示+回顾会议。这篇文章将着重介绍我们进行回顾会议的经验教训。 回顾会议是scrum中最有价值的会议之一，虽然这个会议很重要，但是在实际的工作中我们会发现往往最容易被砍掉的也是这个会议。主要是因为这个会需要团队的主动参与和思考否则就会流于形式，最终不了了之。

上上周我们已经介绍过《看板实战》这本书，这周我们通过这篇文章来说明我们在实际中是怎么使用看板方法，主要是介绍我们的看板的设计结构，以及我们对于看板的实际应用经验。 我还是想说，看板真是一个好东西，谁用谁知道，特别是物理看板。看板目的作为最重要的元素，在这里再强调一遍也不为过应用任何方法的目的都是为了提高团队的工作效率。看板作为一个强有力的工具，能够将团队的工作流可视化，帮助团队更好的找到瓶颈，

在上一篇敏捷之路中主要讲述了我们软件开发方法方面的改进历程，有近一年的时间里完成了试点团队由do whatever向敏捷开发的迁移。在这一篇文章中讲介绍我们在这个迁移过程的技术转型的故事。

今天出于机缘巧合参加一个敏捷的研讨会，虽然在现在这个敏捷已经烂大街的年代，再一次听到各种熟悉的名词还是能让人再次心潮澎湃。正好趁此机会我把之前在为了奇怪目的根据真实经历写的论文拿出来作为本周的博客。

前言关于我们的敏捷实践故事以及技术转型方面已经在我的《敏捷之路》其他的问题文章中介绍过了，这篇文章中我是想介绍一下团队在转型敏捷过程中采取的根具体技术无关的各种方法。