袁斌_AgileDo
- 浏览: 64146 次
- 性别:
- 来自: 北京
-
最新评论
-
windshome：
谢谢袁老师的回复。以我从事设计开发十五年的工作经历来看，因为自 ...
Martin对敏捷宣言中“可工作软件胜过面面俱到文档”的解释 -
袁斌_AgileDo：
windshome 写道袁老师，刚听过了您的课，对这一篇说点自 ...
Martin对敏捷宣言中“可工作软件胜过面面俱到文档”的解释 -
zh_harry：
微信的成功秘诀====抄袭！！
再读经典的“微软团队－成功秘诀” -
archy123：
微软的成功秘诀====抄袭
再读经典的“微软团队－成功秘诀” -
archy123：
微信的成功秘诀====抄袭！！
再读经典的“微软团队－成功秘诀”
文章列表
今天静下心来，重新读了一下很久以前就读过的“微软团队－成功秘诀”，有一些体会分享：（有些是老生常谈，但确实是最容易疏忽的）
① 软件是智能产品，包含的智能越高，软件的价值就越高。管理者最辛苦的 ...
38人团队，分为4个子产品小组，如何一起做回顾会议？
这是一个大的回顾会议，时长会在0.5～1天，总体分为两个部分，简单介绍如下：
① 搜集数据
a) 可视化项目
i. CPO从项目的 ...
Adobe Premiere Pro小组的Scrum实践
①使用敏捷开发的原因：计划超期25％，重要的原因是在改Bug。敏捷转型首先使用的是Scrum
②人员比较多，Scrum团队如何组成？方案是：包含3个跨职能团队，Program manager作为三个团队的Scrum master，Senior Product Manager作为CPO，有最终的发言权，但是PO组包含了EngineeringManager、Scrum Master、Quality Engineering manage、User Experience designer。
③ Adobe Prem ...
Martin对敏捷宣言中“可工作软件胜过面面俱到文档”的解释
没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。
然而，过多 ...
TargetProcess公司敏捷开发历程－开发实践篇
TargetProcess公司的创始人Michael Dubakov，分享了该公司50个月的敏捷开发演变历程，这里分享的是工程实践部分。
在敏捷开发中，短周期迭代是非常常用的方法。但是在现实中，迭代交付延期也是经常遇到的问题。在我实际遇到的众多案例中，我分析了以下11种因素是造成迭代交付延期的重要原因：
大图见：http://photo.weibo.com/1874343052/photos/large/photo_id/3560580984269281
计划会议中的估算，你纠结吗？
在Scrum中的计划会议中，估算是较为让人纠结的环节。主要的问题是：1) 花费的时间长；2) 估算不准确 3) 估算是否有必要
原因是什么？我认为主要是：1) 对需求的理解不到位；2) 每一个需求严格按照planning poker的方式，对于简单的需求和强分工的任务意义不大，但是耽误了时间；3) 设计的风险没有被发现；4) 团队受到“兑现承诺”的压力，一般会“悲观估算”
如何解决这些问题，我的建议是：
① PO在grooming会议之前提前将需求发出，开发团队是带着问题进行需求讨论，否则刚刚拿到需求，讨论的效果 ...
TargetProcess公司敏捷开发历程－流程篇
TargetProcess公司的创始人Michael Dubakov，分享了该公司50个月的敏捷开发演变历程。
大图见：http://ww2.sinaimg.cn/mw690/6fb8348cjw1e2txvvzvhwj.jpg
落地敏捷典型问题：有了这些迹象，一定是出现了问题
有了这些迹象，一定是出现了问题
我们在周而复始的一次一次做迭代，提交新版本。但有一些迹象一旦出现，我们必须停下来，解决这些问题，否则将越来越糟。
1 ...
落地敏捷典型问题：新产品开发的两大教训
我在2004年开始用敏捷开发的模式带领团队快速交付，一路走来有很多的经验，也有很多的教训。这里分享两个曾经的失败教训：
1. 没有正确理解PO角色：PO要和客户直接沟通 ...
Robert C. Martin 对验收测试的解释
作 为验证工具来说，单元测试是必要的，但是不够充分。单元测试用来验证系统的小的组成单元应该按照所期望的方式工作，但是它们没有验证系统作为一个整体时工 作的正确性。单元测试是 ...
落地敏捷典型问题：Sprint中的外包
在我们的实践中，遇到这样一些情形：在Sprint内团队确实无法完成，但业务、商务必须要实现，否则就会推迟数月不能开展业务，此时我们选择的是外包。虽然最终都完成了功能，达到了业务需要，但还是有一些经验和教训可以分享：
1.选择按项目承包，而不是“按人承包”
2.由于无法明确所有的需求细节，而且遍于沟通，要求承包公司的员工在我们公司实地办公
3.外包的部分只是用户的展示部分和非核心的功能，核心的业务功能还是由我们的团队完成
4.将外包的功能分为相对独立的子集，3天左右经行一次正式的评审（PO需要参加）。 一般的承包方都会要求 ...
落地敏捷典型问题：固定的白板，失败的起点
在Scrum的模式中，白板被用来发现风险、团队协作、透明化等，确实是一种简单实用的手段，很多团队在使用白板后获得了直接的效果。但是，白板的使用过程中经常会出现以下问 ...
用最适合自己的方式实施Scrum
Henrik Kniberg推荐的Scrum开发模式的checklist，我们在实践中把考量问题的重心放在“底线”上，具体的实施环节不拘泥于Scrum，同时参考了KanBan，Agile modeling，XP等其他模式，但“核心”部分的环节确实是我们经常用到的。
需要特别说一下的是：推荐部分很有意思，并不强制要求团队中的每一个人都是“全面手”、并不强制要求燃尽图作为控制进度的手段、并不强制要求团队所有人都参与工作量评估、并不强制要求必须有Scrum Master、并不强制要求用相对大小评估工作量等等，所有这些根据实际场景而定。
...
多团队敏捷开发的组织架构和协作模式（续）
在博客 http://yuan-bin01.iteye.com/blog/1756125 中，我介绍了在实践中多团队敏捷开发的组织架构和协作模式。这里在补充介绍一下“技术专家”团队的一些特别做法。
这里的技 ...