|
是敏捷吗?www.mypm.net
我们并没有因为采用Scrum而变得更好更快的交付软件，仍然是按照原来的节奏每年发布几个release。项目管理者联盟
我非常期待的特性团队，即一个团队中既有需求人员，
又有开发人员，还有测试人员，文档人员等并没有建立起来。负责需求的业务分析师和开发团队若即若离，测试团队还是按照自己的步点来干活，
无法深度的参与到完成一个用户故事的活动中来。项目管理者联盟
每个Sprint结束以后很难产生一个可供客户演示、甚至发布到产品环境的软件。bbs.mypm.net
开发团队的本质仍然是老一套，还是依赖项目经理、或者team leader 去驱动各个developer去干活，
看不到自组织(self-directive)的力量。项目管理者联盟
对用户故事进行工作量评估的时候，大家还是关注资深开发和架构师的意见，做不到全员参与。项目管理者联盟
那个每日站会完全变成了一个汇报会，向项目经理汇报。项目管理者联盟
Sprint 说的是橄榄球比赛中的冲刺， 大家团结一致，为了完成该Sprint的目标疯狂向前冲。 实际开发中却很难体会到。training.mypm.net
总而言之，我们似乎只是改了形式， 而没有改变精神。项目管理者联盟
2009年和2010年， 我也有幸走出去实施了几次敏捷咨询服务，包括工行广州开发中心，华为杭州研究所，鼎桥等等。 我发现不仅是我们，
大家都有类似的问题， 实施了敏捷形式而缺乏灵魂。项目管理者联盟
听起来很美好的敏捷软件开发很难落地，生根发芽，开花结果， 这些情况引起我的反思： 难道理想中的敏捷开发根本就不存在?
为什么敏捷开发这么难于实施?项目管理者联盟
经过一段时间的思考，我觉得实施敏捷最重要的有以下几点， 如果做不到这几点，敏捷是很难真正成功的：项目管理者联盟
1. 组织结构一定得变革项目管理者联盟
如果还是维持那种需求/产品团队， 开发团队，测试团队的方式，各个团队各自为政，老死不相往来的方式，敏捷肯定要失败。PgMp.mypm.net
由多种技能人员组成的特性团队是非常重要的，对小公司来说， 建立特性团队相对容易，
但对大公司来说，这简直就是一场革命，肯定要触动不少人的利益，有既得利益者的阻挠， 这是非常难的。项目管理者联盟
所以很多大公司也了解敏捷的好处， 在小范围内做了试点，然后说敏捷不错， 但现阶段还不适合我们， 最后不了了之。项目管理者联盟
2. 人的技能和意识一定得提高talent.mypm.net
先说技能，敏捷开发对团队成员的要求是提高了，而不是降低了。项目管理者联盟
开发人员要能写代码、写测试、做重构、做Build， 还得具备处理遗留代码的能力。项目管理者联盟
写出的代码质量一定得高，扩展性强， 这样才能“拥抱”客户的变化，这比以前随便写代码，完成功能的要求不知道要高了多少。项目管理者联盟
敏捷之前的团队有人专门做设计， 有人专门做开发， 敏捷之后这个界限模糊了， 大部分人设计和开发都得做，
对那些习惯做最基本开发的程序员是重大挑战。bbs.mypm.net
同样，开发角色和测试角色的界限也开始模糊，开发人员要能做些测试工作， 测试人员也要能协助做点开发工作。这样才能够在打仗的时候互相掩护， 奋勇冲锋。
一个人出了状况很快就有人能补上去。项目管理者联盟
特性团队中的成员，最好是像军队中的特种兵那样强悍。项目管理者联盟
其次是意识，正如我前边所提到的，现在的很多团队成员主动性并不强，都是在被动的等待任务的分配， 也不敢大胆的提出自己的观点和见解，
这和敏捷开发的要求是相悖的。项目管理者联盟
有些公司在大量使用外包人员参与开发， 这些人在工作中就会出现上面的情况， 并不是贬低外包， 我也见过非常优秀的外包人员， 但是大部分人的主动性都不够，
敏捷开发是搞不起来的。blog.mypm.net
|
