- 博客(5)
- 收藏
- 关注
RSS订阅原创 绩效管理：软件开发团队的非物质激励机制
IT人士要想被激励起来，除了可以用薪酬之外，其实还有很多办法。比如笔者刚刚毕业的时候，曾经彻夜编制一个软件长达5个月，原因是自己居然有一台专属的486电脑；而数年后我一个同事会在中午一边吃饭一边编程，是因为他独自负责一个至关重要的模块……很多人身边都因为各种不同的原因发现神奇的被激励的人，这些激励机制有哪些可遵循的规律呢？我02年左右曾经读过一本麦克康奈尔（当时人称美国几大GURU之一，《完美
2011-03-10 12:48:00
574
原创 139团队（大型研发团队或大型敏捷开发团队的管理）
定义简单看，139团队就是1个项目经理，3个小组长，9个开发人员，小组长管理各自管理3个左右开发人员。139团队从管理上缩减了团队规模，可以被视同只有1个项目经理和3个小组长，细节交由小组长处理。这样就方便在大型团队中进行敏捷开发了。角色在Scrum敏捷团队中，队员们是平等的，只有Scrum Master是个个例。但由于在国内很难找到Scrum Master（一则知识缺少，二则一般PM不愿意放弃管理权和技术而转而做“协调”工作），且团队往往超过7～9人，139团队会是一个替代方案。项目经理主要工作与原来的项
2011-03-10 12:44:00
1518
原创 敏捷测试与传统测试的区别
在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通不畅或或博弈成分超过合作。在敏捷开发中需求与进度的冲突由计划会和自组织团队机制解决，成本由BDC和故事点开发率的提升来解决（解决的不好），而进度与质量间的矛盾，则由新型的测试理念来解决。在传统测试中，测试团队被认为是找BUG的人，比
2011-03-10 12:40:00
461
原创 敏捷开发中提高软件生产率的方法
很多人都知道甚至感觉到敏捷开发的生产率比传统开发高，但到底敏捷开发是怎样提升生产率的呢？以及当前自己正在实施的敏捷开发还有多大的生产率潜力？当然“受激励的个体”会产生生产率，但只是这样解释恐怕难以服众，更难说服老板。让我们换一个角度吧。下面几个问题揭示了一些隐性的生产率潜力：•10万/100万/1000万代码行的项目有20%/48%/65%被取消（Jones, 1998）•成功交付的产品中，约2/3延期交付（The Standish Group, 1992~2004）•所有软件平均60%左右的功能从未或很少
2011-03-10 12:36:00
588
原创 “迭代期间内变更”与敏捷开发产品版本规划
迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。只在开发层面，这个问题无解。让我们站在产品版本规划的高度来看这个问题。下个产品版本（或下个迭代）中到底应该有什么功能？最重要的功能？最基础的功能？当前可能实现的功能？已经弄清楚的功能？这些角度都是基于技术活动而非市场目标来制定的，都有其局限性。其实，每个产品的版本都是企业的一步棋：在某个时间，推出某些功能，满足某些需求，获取某些客户，打败某些对手，取代某些产品
2011-03-10 12:33:00
1002
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人