袁斌_AgileDo
- 浏览: 64349 次
- 性别:
- 来自: 北京
-
最新评论
-
windshome：
谢谢袁老师的回复。以我从事设计开发十五年的工作经历来看，因为自 ...
Martin对敏捷宣言中“可工作软件胜过面面俱到文档”的解释 -
袁斌_AgileDo：
windshome 写道袁老师，刚听过了您的课，对这一篇说点自 ...
Martin对敏捷宣言中“可工作软件胜过面面俱到文档”的解释 -
zh_harry：
微信的成功秘诀====抄袭！！
再读经典的“微软团队－成功秘诀” -
archy123：
微软的成功秘诀====抄袭
再读经典的“微软团队－成功秘诀” -
archy123：
微信的成功秘诀====抄袭！！
再读经典的“微软团队－成功秘诀”
文章列表
敏捷实践（六）－微软实施敏捷的经验
此处会介绍微软在分布式团队环境下如何实施敏捷开发的一些经验。对于面向全球市场、想节省成本的公司，分布式团队是应用非常广的一种方式。
每一个团队的组成：
产品经 ...
优秀公司的实践（一）：Facebook的工作方式
本文介绍Facebook如何工作。文章摘自网络，在文章的结尾会注明所有的出处。文章的目的是分享成功的公司的成功经验。成功经验很难单一复制，但思路值得思考。
1) 工作方式
a) 公司最大的两群人是技术开发人员和实施人员(Ops),各自有400～500人。这两部分人占去了公司构成的50%。
b) 产品经理跟技术人员的比例大概是1：7到1：10。产品经理有很大的独立性和自由度，影响力的产生关键在于和技术经理建立好良好的关系，需要有足够的技术知识来避免自己提出愚蠢的建议。
c) ...
DAD（有纪律的敏捷交付）在不同类型交付的应用
我在2004年开始的第一个敏捷开发项目，到目前自己经历的、看到的项目或者产品，如果是规模比较大，从开始、交付、持续维护和改进的过程中，总是有DAD的影子在里面，或者说有DAD的关键因素在里面。我对DAD（有纪律的敏捷交付）的理解是：
1) 基于交付（结果）的流程，清晰的阶段，清晰的里程碑，每一个阶段有明确的目标和推荐的实践，整个过程持续改进
2) 基于迭代，面向学习：短周期的迭代，可以得到需求、技术、流程等各方面的反馈，尽早发现风险，及时改正。背后的思路是：可工作，才可以把需求至交付整个流程中的问题暴露出来
...
我们这样做Scrum的评审会议
在实践中，我们发现如果只在Sprint之后再做Demo，由于Sprint过程中沟通不充分，Demo展示的功能很可能不符合客户真正的需求，导致Sprint失败。于是，我们按照优先级和耦合做分组，高优先级的需求组尽 ...
外包团队在中德模式下的经验分享
项目背景：为德国某著名汽车生产商离岸开发的流程改进定制项目，项目成员近百人，分布中国和德国两地。中国的团队占据了70％以上。项目的合作效果不错，有一些经验和大家分享：
a. ...
如何让第一个试点Scrum项目成功
当我们在尝试应用敏捷开发时，Scrum方法是最容易实施的。但是如果要想使敏捷开发进行下去，第一个试点的Scrum项目要尽量成功，这样会得到管理层更多的支持。以下是我们在实践中的一些具体 ...
团队的问题，除了人员流动外，还包括很多，诸如随着项目的进行，成员工作热情的减弱。热情的减弱，会导致沟通欲望的下降，卓越质量的欲望下降...。需要有一些事情可以使团队保持热情，分享一些我们的具体做法：
1) ...
估算，我们当然希望估算会更加准确一些。当然，如果达成这个目标的时间更短，大家会更开心。所以我对有效估算的定义是：更短的时间内做出更加准确的估算。
如何做到有效的估算？基本的思路是：尽量短的时间把需要估算的任务状态提升到“需求、设计都尽量清楚和正确”，即由图中的状态
A
提升到状态
B
我们实践中考量两个具体的因素：人和技术。
人的因素，这里分享一些我们的做法：
1)
包含必须的角色进入估算。如果团队中没有人对估算的需求有了解，对需要用到的技术有了解，估算意义不大。
2) ...
写这篇文章的背景是：一个项目组实施
Scrum取得成效，如何在整个开发部门推广
Scrum？看一下我们一个大产品，三个项目组共同完成的具体实践：
我们做了如下的组织调整：
1.
产品部增加一名总监（CPO
），负责公司层面的产品思路，整合三个子产品
2.
各个Scrum
小组的架构师和DBA
成
立虚拟架构师团队，架构师团队根据产品部的整体产品思路，提出并实现公司层面的技术架构（此时每一个项目组需要一个高级开发人员参加）。公司所有产品在这
个架构平台上进行开发。这样的好处是：公司整体的开发成本、维护成本降低，质量提高。同时架构师和参加架 ...
技术债务最早是由Ward
Cunningham提出的，当时是为了向非技术背景的项目干系人解释为什么要去做我们现在称之为“重构”的事情。Steve
McConnell对技术债务的解释是：技术债务是短期的一种权宜，但从长期看相同的工作会比当前 ...
这里分享
Yahoo的体育频道的团队如何实现每日发布的一些实践。
每日发布的具体思路包括：
1.
利用时差。南非的团队可以工作准备发布，而这个时候大多数人在睡眠中
2.
更好的流程
2.1 ...
我们在实践中会用到需求拆分的各式武器，这里列举一些常用的武器：角色、实体、目的、解决方案、数据对象、业务操作、业务流程、“个性－共性”原则、“简单－复杂”原则等等，这些武器会帮助我们从最初的产品愿景逐步分解为迭代交付中的开发需求。
下图说明了一般情况下各种武器在不同阶段的使用场景，迭代
0是非常关键的一个阶段，它会就需求、设计、团队等多方面为以后的迭代做准备。就需求这个范畴，这个阶段会根据这些武器逐步拆分和理解需求，并保证需求不过度分析，不产生额外的浪费，以最小的成本适应变化的需求。
系统级故事中会包含“非功能性需求”和“功能性需求 ...
拆分需求的目的：通过将需求拆分为松耦合，有独立交付价值，可快速交付的小需求，使我们的开发可以降低风险，快速得到反馈（无论从市场的角度还是技术的角度），不断修正错误，以得到成功的目的。这样我们有机会工作在“做正确的产品”和“正确的构建”这个范畴，即下图的第一象限。
如何拆分需求，特别是从用户的想法拆分到迭代可以使用的需求的整个过程？以下是我们的一些实践：
我们用“用户故事”来描述和管理需求。把用户故事分为三级：系统级、架构级和开发级。系统级是为了对产品有一个了解，那就是
Who、
What、
Why即可；架构级是为了在
sprint0中工作，做整体的 ...
Richard Lawrence
介绍了拆分用户故事的流程，包含三个部分：判断故事是否需要拆分、应用多种模式拆分故事、评估拆分效果。具体的流程见图：
原文参考：
http://www.richardlawrence.info/2012/01/27/new-story-splitting-resource/
拆分用户故事，
INVEST是一个原则，需要更有场景的实例。特别是在获得用户需求的初期，如何形成系统级的用户故事？在随后的拆分过程中，如何有效的拆分故事？以下是我们的一些实践：
1) 获
得系统级的用户故事，我们使用的方法是：按照用户类别、用户实例、用户要达到的目的、用户为此目的想要的解决方案。尽量先考量目的，再考量解决方案。很多
时候用户改变需求，实际改变的是解决方案，而不是背后要实现的目的，只是我们在获得需求的时候没有首先关注“背后的目的”而已。
2) 系统级的用户故事接下来的拆分，我们使用到的方法有：
2.1 拆分目的，再根据目的拆分解决方案 ...