剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Mike Bria译者 乔梁 发布于 2008年3月2日 上午4时41分
在最近的一系列贴子中,James Golick和Reg Braithwaite讨论了这样一个经常被置之高阁的事实,即陷入“赶工状态”的团队是如何导致不良结果的。讨论中提到了将压力施加于团队后产生的各种各样的情况,这些情况经常将项目推向更糟的境地;同时还讨论了团队和管理者如何使用不同的方法改变类似糟糕的处境。
James Golick最初的假定条件是:通过将“全明星”程序员变成平庸之辈,开始采取“赶工”的方式,最后反而会导致整体生产率下降,这看起来极俱讽刺意味。Golick的基本主张是:当开始加班“赶工”时,使得最佳程序员具备高生产力的习惯会首先被屏蔽掉。
在超级程序员与你千挑万选尽可能不雇佣的普通程序员之间可能存在一个巨大的差别:超级明星程序员以代码为先,而普通程序员最先考虑的是如何每天按时下班回家。当转向“赶工模式”后,他们的优先级就发生变化了。
当每个人都为了在某个日期之前完成某些任务而加班加点、每天刚踏进办公室就开始想如何在这么短的时间里交付更多的特性时,压力就来啦。大家开始偷工减料,打破正常做事的步骤,写的测试越来越少,重构也越来越少。这时你的全明星团队就已经被你成功转变成一群平庸的程序员了。
Golick 进一步阐述了为什么对团队施加压力很可能产生负面后果:
当你将团队送上死亡之旅后,会很快让程序员感到疲惫,进而导致出现质量低劣的代码。而且,开发人员很可能变得士气低落,精疲力尽,对所做的东西根本提不起兴趣来。也许最糟糕的是你,因为他们开始对你的领导忿恨不已。在这种情形下,很多项目因为那些低级缺陷而令项目后期的修改和维护困难、更有甚者,会导致重新开发工作,这会使得赶工状态下的实际总产出反而更少。
为了避免“赶工模式”的缺陷,这个贴子还为程序员提供了以下两点建议:
当“赶工”结束后,你就是那个收拾烂摊子的人,而且大家都知道根本没时间能收拾干净。公司也不得不处理这个低质量的软件,最终它很可能是被修修补补地发布了。给果,各方都是输家。
Reg Braithwaite之前发布过一个贴子,其中也提到第二点建议,即“勇于说‘不’”。Braithwaite认为,作为软件专业人才的你,有责任为完成你的工作而坚持使用某种方法。但在很多情况下,你最好还是调整一下来满足老板的需求:
如果承担决策后果的人坚持要我遵循他们的判断,我可以违背直觉做出让步……(另一方面)如果让我开发一个不可靠、并有可能泄漏私人数据的软件,我宁可说“不”。
为了响应Golick,Braithwaite提出:虽然很多经理认为“仅此一次而已”,但许多“赶工状态”的出现并非例外情况。Braithwaite强调:如果“赶工”状况频繁发生,或者本可以通过事先计划而避免,那么发生“赶工”就不是例外。许多管理层和开发人员将“赶工”的发生或者项目的失败归咎于“未列入计划之事”而一笔带过,Braithwaite亦对此提出了严重质疑。
我也许无法确切知道会有什么缺陷,但是从统计学上来看,我知道一定会有缺陷,需求会成为焦点,而估算仅仅是估算。我无法对我的老板说:“我不知道他们 这么做是想要那样的结果,我也不知道这事儿会没按我们预期的方式发生,因此,我们得在没有测试的情况下赶紧把活干完。”
我可以——而且确实——预见到这些事情会发生,所以我可以——而且必须——为这些事情做计划。
关于在敏捷项目中如何避免“短路”,请查看InfoQ的这篇文章以了解更多观点。
查看英文原文:Crunch Mode And Making Superstars Average
不是所有人都能承受压力的。
不是所有压力都是积极的。
《用“看板图”实现敏捷项目的可视化》这篇提到的“表情日历”我觉得很有价值,能跟踪团队的心理状态。
如题
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。
在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。
InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!
在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。
通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。
本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。
InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。
3 条回复
回复