- 博客(43)
- 收藏
- 关注
RSS订阅原创 AgileDo实践集：异地协作的敏捷开发实践
AgileDo敏捷教练团队帮助客户北京、深圳、济南三地团队通过敏捷开发协作完成一个产品，文章分享遇到的困难和AgileDo的解决方案
2024-04-17 21:00:28
120
原创 AgileDo实践集：嵌入式开发的敏捷实践
AgileDo团队已经有60+具体的敏捷技术实践和模式，以实现嵌入式开发的更高质量、快速交付、聚焦客户价值和应对需求的变更。这里分享其中的一部分
2024-04-16 19:05:34
319
再读经典的“微软团队－成功秘诀”
今天静下心来，重新读了一下很久以前就读过的“微软团队－成功秘诀”，有一些体会分享：（有些是老生常谈，但确实是最容易疏忽的） ① 软件是智能产品，包含的智能越高，软件的价值就越高。管理者最辛苦的地方就是如何将团队的智能用聪明的方法结合起来 ② 软件团队必须将软件和用户结合在一起，即软件不只是提供功能、性能，而且要提供用户体验（页面风格、交互、帮助、文档等），只有软...
2013-07-19 08:29:25
224
38人团队，分为4个子产品小组，如何一起做回顾会议？
38人团队，分为4个子产品小组，如何一起做回顾会议？这是一个大的回顾会议，时长会在0.5～1天，总体分为两个部分，简单介绍如下： ① 搜集数据a) 可视化项目 i. CPO从项目的整体（预期的交付和实际的交付、技术债务等）做说明，写在大的翻纸上，以便其他人补充 ...
2013-05-22 08:41:59
230
Adobe Premiere Pro小组的Scrum实践
Adobe Premiere Pro小组的Scrum实践①使用敏捷开发的原因：计划超期25％，重要的原因是在改Bug。敏捷转型首先使用的是Scrum ②人员比较多，Scrum团队如何组成？方案是：包含3个跨职能团队，Program manager作为三个团队的Scrum master，Senior Product Manager作为CPO，有最终的发言权，但是PO组包含了Eng...
2013-05-06 09:07:48
215
Martin对敏捷宣言中“可工作软件胜过面面俱到文档”的解释
Martin对敏捷宣言中“可工作软件胜过面面俱到文档”的解释没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。 然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造...
2013-04-12 08:54:32
987
TargetProcess公司敏捷开发历程－开发实践篇
TargetProcess公司敏捷开发历程－开发实践篇TargetProcess公司的创始人Michael Dubakov，分享了该公司50个月的敏捷开发演变历程，这里分享的是工程实践部分。 ...
2013-04-07 08:28:55
230
导致迭代交付失败的11名杀手
在敏捷开发中，短周期迭代是非常常用的方法。但是在现实中，迭代交付延期也是经常遇到的问题。在我实际遇到的众多案例中，我分析了以下11种因素是造成迭代交付延期的重要原因： 大图见：http://photo.weibo.com/1874343052/photos/large/photo_id/3560580984269281 ...
2013-04-02 09:06:47
236
落地敏捷典型问题：计划会议中的估算，你纠结吗？
计划会议中的估算，你纠结吗？ 在Scrum中的计划会议中，估算是较为让人纠结的环节。主要的问题是：1) 花费的时间长；2) 估算不准确 3) 估算是否有必要 原因是什么？我认为主要是：1) 对需求的理解不到位；2) 每一个需求严格按照planning poker的方式，对于简单的需求和强分工的任务意义不大，但是耽误了时间；3) 设计的风险没有被发现；4) 团队受到“兑现承...
2013-03-26 08:47:52
132
TargetProcess公司敏捷开发历程－流程篇
TargetProcess公司敏捷开发历程－流程篇TargetProcess公司的创始人Michael Dubakov，分享了该公司50个月的敏捷开发演变历程。 大图见：http://ww2.sinaimg.cn/mw690/6fb8348cjw1e2txvvzvhwj.jpg ...
2013-03-19 08:31:40
427
落地敏捷典型问题：有了这些迹象，一定是出现了问题
落地敏捷典型问题：有了这些迹象，一定是出现了问题有了这些迹象，一定是出现了问题 我们在周而复始的一次一次做迭代，提交新版本。但有一些迹象一旦出现，我们必须停下来，解决这些问题，否则将越来越糟。 1. 提交给客户的质量是不能接收的，客户很不愿意升级版本，因为会遇到无法预计的一些Bug 2. 给客户提交新功能，需要越来越长的时间。这个问题有可能产生于：功能的实现依赖于特定...
2013-03-14 09:25:47
205
落地敏捷典型问题：新产品开发的两大教训
落地敏捷典型问题：新产品开发的两大教训 我在2004年开始用敏捷开发的模式带领团队快速交付，一路走来有很多的经验，也有很多的教训。这里分享两个曾经的失败教训： 1. 没有正确理解PO角色：PO要和客户直接沟通，要能真正代表客户意图，否则产品很可能失败 关 键的客户沟通不到位，导致快上线了，客户认为的关键功能PO都不知道。产品开发之初，公司没有产品负责人（PO）...
2013-03-13 08:39:41
418
Robert C. Martin 对验收测试的解释
Robert C. Martin 对验收测试的解释作 为验证工具来说，单元测试是必要的，但是不够充分。单元测试用来验证系统的小的组成单元应该按照所期望的方式工作，但是它们没有验证系统作为一个整体时工 作的正确性。单元测试是用来验证系统中个别机制的白盒测试（white-box tests）。验收测试是用来验证系统满足客户需求的黑盒测试（black-box tests）。 验收...
2013-03-12 09:15:53
126
落地敏捷典型问题：Sprint中的外包
落地敏捷典型问题：Sprint中的外包在我们的实践中，遇到这样一些情形：在Sprint内团队确实无法完成，但业务、商务必须要实现，否则就会推迟数月不能开展业务，此时我们选择的是外包。虽然最终都完成了功能，达到了业务需要，但还是有一些经验和教训可以分享： 1.选择按项目承包，而不是“按人承包” 2.由于无法明确所有的需求细节，而且遍于沟通，要求承包公司的员工在我们公司实地办公...
2013-03-11 08:58:11
220
落地敏捷典型问题之项目透明：固定的白板模式是失败的起点
落地敏捷典型问题：固定的白板，失败的起点在Scrum的模式中，白板被用来发现风险、团队协作、透明化等，确实是一种简单实用的手段，很多团队在使用白板后获得了直接的效果。但是，白板的使用过程中经常会出现以下问题，例如： 1) 一种固定模式的白板，对应一种固定模式的协作方式，但是在不同的实际场景中行不通2) 白板上的关键信息不做持续记录和更新，失去存在的意义...
2013-03-08 09:33:12
486
用最适合自己的方式实施Scrum
用最适合自己的方式实施ScrumHenrik Kniberg推荐的Scrum开发模式的checklist，我们在实践中把考量问题的重心放在“底线”上，具体的实施环节不拘泥于Scrum，同时参考了KanBan，Agile modeling，XP等其他模式，但“核心”部分的环节确实是我们经常用到的。 需要特别说一下的是：推荐部分很有意思，并不强制要求团队中的每一个人都是“全面手”、...
2013-03-06 10:06:25
214
多团队敏捷开发的组织架构和协作模式（续）
多团队敏捷开发的组织架构和协作模式（续）在博客 http://yuan-bin01.iteye.com/blog/1756125 中，我介绍了在实践中多团队敏捷开发的组织架构和协作模式。这里在补充介绍一下“技术专家”团队的一些特别做法。 这里的技术专家团队可以由内部工程师组成，但一些场合也可以考量外部的技术资源。 我们在实践中有这样的场景：系统处在试运行中，性...
2013-03-05 09:37:23
909
敏捷实践－微软实施敏捷的经验
敏捷实践（六）－微软实施敏捷的经验此处会介绍微软在分布式团队环境下如何实施敏捷开发的一些经验。对于面向全球市场、想节省成本的公司，分布式团队是应用非常广的一种方式。 每一个团队的组成：产品经理：代表客户，帮助团队更好的了解需求。对Product Backlog排列优先级并为每一次迭代确定user story。微软为一个团队安排一名产品经理教练：负责团队如何工作，例如...
2013-03-04 08:58:39
370
原创 优秀公司的实践（一）：Facebook的工作方式
优秀公司的实践（一）：Facebook的工作方式本文介绍Facebook如何工作。文章摘自网络，在文章的结尾会注明所有的出处。文章的目的是分享成功的公司的成功经验。成功经验很难单一复制，但思路值得思考。 1) 工作方式 a) 公司最大的两群人是技术开发人员和实施人员(Ops),各自有400～500人。这两部分人占去了公司构成的50%。 b) ...
2013-03-02 14:41:39
442
DAD（有纪律的敏捷交付）在不同类型交付的应用
DAD（有纪律的敏捷交付）在不同类型交付的应用我在2004年开始的第一个敏捷开发项目，到目前自己经历的、看到的项目或者产品，如果是规模比较大，从开始、交付、持续维护和改进的过程中，总是有DAD的影子在里面，或者说有DAD的关键因素在里面。我对DAD（有纪律的敏捷交付）的理解是： 1) 基于交付（结果）的流程，清晰的阶段，清晰的里程碑，每一个阶段有明确的目标和推荐的实践，整个...
2013-03-01 09:25:53
535
我们这样做Scrum的评审会议
我们这样做Scrum的评审会议在实践中，我们发现如果只在Sprint之后再做Demo，由于Sprint过程中沟通不充分，Demo展示的功能很可能不符合客户真正的需求，导致Sprint失败。于是，我们按照优先级和耦合做分组，高优先级的需求组尽早完成做Demo，让需求缺陷的风险前移。这里的分阶段 Demo不是正式的Demo，在10分钟内完成。 流程可以参考图： 好处：...
2013-02-27 09:54:06
438
外包团队在中德模式下的经验分享
外包团队在中德模式下的经验分享项目背景：为德国某著名汽车生产商离岸开发的流程改进定制项目，项目成员近百人，分布中国和德国两地。中国的团队占据了70％以上。项目的合作效果不错，有一些经验和大家分享： a. 建 立信任。由于地域的问题，双方无法面对面互相了解，同时英语都不是双方的母语，在开发和交流过程中很容易引起误解甚至猜忌。所以我们在项目的初期和中期有 两次的互访，目的是互相了解以及在...
2013-02-26 09:29:22
161
如何让第一个试点Scrum项目成功
如何让第一个试点Scrum项目成功当我们在尝试应用敏捷开发时，Scrum方法是最容易实施的。但是如果要想使敏捷开发进行下去，第一个试点的Scrum项目要尽量成功，这样会得到管理层更多的支持。以下是我们在实践中的一些具体做法： a. 选择一个试点项目 1）这个项目是对企业的business有一定影响（但不是最影响的），这样一方面可以得到管理层的支持，如果成功有很强的示范效应，同...
2013-02-25 17:07:05
315
优秀的团队（一）：如何让团队保持更长的工作热情
团队的问题，除了人员流动外，还包括很多，诸如随着项目的进行，成员工作热情的减弱。热情的减弱，会导致沟通欲望的下降，卓越质量的欲望下降...。需要有一些事情可以使团队保持热情，分享一些我们的具体做法： 1) 确定迭代周期，不至于太短使团队压力过大，也不至于太长使团队松懈。“小跑”的节奏是保持热情的一 个开始 2) 让大家每个人的工作放在整个团队的面前，例如可以...
2013-02-25 09:50:52
384
做有效的估算
估算，我们当然希望估算会更加准确一些。当然，如果达成这个目标的时间更短，大家会更开心。所以我对有效估算的定义是：更短的时间内做出更加准确的估算。如何做到有效的估算？基本的思路是：尽量短的时间把需要估算的任务状态提升到“需求、设计都尽量清楚和正确”，即由图中的状态A提升到状态B 我们实践中考量两个具体的因素：人和技术。 ...
2013-01-09 14:10:05
150
多团队敏捷开发的组织架构和协作模式
写这篇文章的背景是：一个项目组实施Scrum取得成效，如何在整个开发部门推广Scrum？看一下我们一个大产品，三个项目组共同完成的具体实践：我们做了如下的组织调整：1. 产品部增加一名总监（CPO），负责公司层面的产品思路，整合三个子产品2. 各个Scrum小组的架构师和DBA成立虚拟架构师团队，架构师团队根据产品部的整体...
2012-12-28 09:07:12
1959
技术债务的那些事
技术债务最早是由Ward Cunningham提出的，当时是为了向非技术背景的项目干系人解释为什么要去做我们现在称之为“重构”的事情。Steve McConnell对技术债务的解释是：技术债务是短期的一种权宜，但从长期看相同的工作会比当前会费的成本要高很多。Jean-Louis Letouzey对技术债务的解释是：对不适合做法的补救成本的总和关于技术债务，我们要重点讨论的是：...
2012-12-27 12:00:50
670
敏捷实践的他山之石（一）：Yahoo的敏捷实践
这里分享Yahoo的体育频道的团队如何实现每日发布的一些实践。 每日发布的具体思路包括：1. 利用时差。南非的团队可以工作准备发布，而这个时候大多数人在睡眠中 2. 更好的流程2.1. 团队保持足够的灵活性，特别是减少工作移交（handoffs）造成的浪费2.2. ...
2012-12-19 09:10:21
79
敏捷需求管理（五）：拆分需求的18班武器之武器篇
我们在实践中会用到需求拆分的各式武器，这里列举一些常用的武器：角色、实体、目的、解决方案、数据对象、业务操作、业务流程、“个性－共性”原则、“简单－复杂”原则等等，这些武器会帮助我们从最初的产品愿景逐步分解为迭代交付中的开发需求。 下图说明了一般情况下各种武器在不同阶段的使用场景，迭代0是非常关键的一个阶段，它会就需求、设计、团队等多方面为以后的迭代做准备。就需求这个范畴，这个...
2012-12-12 14:35:54
257
敏捷需求管理（四）：拆分需求的18班武器之序言篇
拆分需求的目的：通过将需求拆分为松耦合，有独立交付价值，可快速交付的小需求，使我们的开发可以降低风险，快速得到反馈（无论从市场的角度还是技术的角度），不断修正错误，以得到成功的目的。这样我们有机会工作在“做正确的产品”和“正确的构建”这个范畴，即下图的第一象限。如何拆分需求，特别是从用户的想法拆分到迭代可以使用的需求的整个过程？以下是我们的一些实践：我们...
2012-11-29 09:30:27
452
敏捷需求管理（三）：拆分用户故事的流程
Richard Lawrence介绍了拆分用户故事的流程，包含三个部分：判断故事是否需要拆分、应用多种模式拆分故事、评估拆分效果。具体的流程见图： 原文参考：http://www.richardlawrence.info/2012/01/27/new-story-splitting-resource/ ...
2012-11-20 09:11:21
1798
敏捷需求管理（二）：如何有效拆分用户故事
拆分用户故事，INVEST是一个原则，需要更有场景的实例。特别是在获得用户需求的初期，如何形成系统级的用户故事？在随后的拆分过程中，如何有效的拆分故事？以下是我们的一些实践： 1) 获得系统级的用户故事，我们使用的方法是：按照用户类别、用户实例、用户要达到的目的、用户为此目的想要的解决方案。尽量先考量目的，再考量解决方案。很多时候用户改变需求，实际改变的是解决方案，而不...
2012-11-19 20:00:18
2636
敏捷需求管理（一）：从用户想法到Product Backlog
如何从最初的客户想法到持续维护的Product Backlog，大家的做法各有千秋。这里分享我们的一些做法，见下图：第一步：独立需求。这里是从愿景开始，根据角色、行为、数据对象拆分为独立的需求第二步：粗颗粒细化需求。这里的目的是为了分析成本考量，但并不是类似Use Case那样的细化，只需要包含90％的用户使用场景即可，有很多做法，其中一个是选择...
2012-11-15 09:19:30
577
迭代开发还是流开发（二）：Kanban提供了哪些不同思路
Kanban虽然有透明、限制WIP（在制品）和度量、提升工作流、PULL模式作为基本的特点，但这并不是说选择Kanban是因为Scrum不具备这些特点。应该说，两者都具备这些特点，只是在细节处各有侧重。Kanban和Scrum比较，在团队组织、交付频率、流程管理等方面有以下的不同之处，了解这些区别，会方便我们选择是否用Kanban：...
2012-11-05 09:07:23
157
迭代开发还是流开发（一）：迭代开发遇到的困难
[size=medium]迭代开发还是流开发（一）：迭代开发遇到的困难基于Scrum的迭代开发已经很多年，很多团队会在2周一个迭代的周期频率下不断交付，基于跨职能的团队，同时迭代中不允许有变化的需求。但是有一些场景让这种迭代很困难，例如：1) 紧急的技术支持2) 临时增加的非常高的优先级的需求3) 需求的批量小，导致无法2~4周一个迭代稳定发布4) 估算非常难，导致不容易承诺，...
2012-10-31 09:03:52
221
研发团队的绩效考核（三）
[size=medium]我和大家分享的内容主要包括以下三个方面：① 研发团队的绩效考核的方式② 研发团队绩效考核KPI如何评估③ 如何让绩效考核发挥作用今天是第三部分③ 如何让绩效考核发挥作用如何要让绩效考核发挥作用，提高交付质量。减少学习债务和技术债务，增强团队的成熟度，我们的实践是要做到以下几点：1) 绩效考核年度、季度来做正式的评估当然可以，最好每天的工...
2012-10-30 08:55:20
678
研发团队的绩效考核（二）
[size=medium]我和大家分享的内容主要包括以下三个方面：① 研发团队的绩效考核的方式② 研发团队绩效考核KPI如何评估③ 如何让绩效考核发挥作用今天是第二部分② 研发团队绩效考核KPI如何评估团队部分KPI指标的评估方式：每次迭代的交付物是否可以被接受：以需求提出者对本次开发迭代交付物的评价为标准，分为“接受”和“拒绝”两种每次迭代的生产率是否理性的增...
2012-10-28 20:12:53
689
研发团队的绩效考核（一）
我和大家分享的内容主要包括以下三个方面：① 研发团队的绩效考核的方式② 研发团队绩效考核KPI如何评估③ 如何让绩效考核发挥作用这次介绍第一部分：① 研发团队的绩效考核的方式很多人觉得研发团队的绩效考核很头痛，甚至不想做绩效考核，其实研发团队绩效考核我认为是需要的，因为绩效考核实际是一个“指挥棒”，它会引导研发团队朝着企业认为最佳价值的方向，通过团队/个人自己的努力达到，而...
2012-10-26 09:12:56
3730
2
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人