剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Mark Levison译者 李剑 发布于 2008年7月21日 上午9时17分
上个月,日本劳工委员会声明Camry Hybrid项目的首席工程师死于过劳。在他生命中的最后几个月里,他几乎每个月都要加班超过80小时。就在他要飞往Detroit Auto Show的前一天,心脏病突发,与世长辞。
一石激起千层浪,种种争论纷至沓来。我们能从丰田学到什么?什么是可持续的开发步骤?我们为什么开发软件?
Joe Little 想问的问题是,在丰田里面,到底拼命加班算是精益的基础,还只是跟某个具体的团队有关?他提醒人们,即使丰田是精益的制造者,他们自己也没有做的很到位。不过我们依然可以向丰田和其它精益实践者学习。
这个故事让人很难过,但也能让人学到不少东西。丰田的精益制造开发模型,把产品负责人、Scrum Master、技术领导都混在了一起,变成了一个角色,名为首席工程师。我跟Mary Poppendeick曾经讨论过,这种模型也可以用于软件开发。我遇到的问题是,产品负责人本身已经负担很重了,再加上额外的技术和过程方面的责任,实 在让我不堪重负,没法一直保持良好的工作状态。我感觉这也许就是问题所在。
精益软件开发的作者Mary,在回复中谈到了她在3M作为产品带头人的工作经历:
在优秀的团队里面,团队成员对他们开发的产品充满激情,所以他们会自愿超额工作,加班。我也不觉得技术带头人是个什么都知 道,什么都掌控的家伙,他只是可以用他的远见卓识,带动起团队的干劲。我当产品带头人的时候,连产品负责人的工作都没法自己干,但是我知道怎么从团队里面选出合适的人来,放到合适的位置,让他们积极完成目标——然后一切都会顺理成章。
她继续谈到,如果大家只是把工作当成一大堆要干的事情自己抗起来,不跟团队一起承担,那任何角色都会成为生命不可承受之轻。
最后,在谈到管理层提出的最后期限和固定特性时,Mary回复说:
也许导致这种症状的最大问题在于,出于某些原因,软件是从整个系统中脱离开来的,也跟系统的整体业务目标扯不上干系。所以 没人能对它产生热情。我们必须停止开发软件,动手搭建为重要需求服务的系统,这样团队成员就可以做出正当的决定:这个规划有多重要?那个难度很大的特性有 多重要?从长远目标来看,哪种测试策略最合适?整个系统的成本到底有多高?查看英文原文:Death of Hybrid Camry Chief Engineer is Ruled Overwork
IT = I'm Tired ? exactly the truth ?
过尤不及,加班并不一定是好事,有时还是费力不讨好的事情。在项目管理过程中,就有这么一个说法,如果你发现你的团队成员总在加班,那么你就需要看看他的工作是否偏离了你的方向,或者说他有可能在做无用功。
不知道以吃东西来做比是否恰当,我们知道,自己很喜欢吃的一个东西在一次吃腻之后可能就再也不想碰了。职业也是一样,如果激情烧过了头,可能就会讨厌自己开始喜欢的工作,多么得不偿失的事情。所以,当你加班过多时,自我控制一下是不错的选择。
要在身体和精神可承受的范围内有限加班是可以的.
不能为了加班而加班, 这样工作效率也不会很差
唔~~偶看到这条新闻的第一反应是,在创造出精益理论的丰田也有这种事情发生,第二反应是,华为啊~~~
同意啊...
过劳死这种事情好像只在亚洲发生过,特别是东亚,一方面说明我们勤劳,一方面也是压力大
近期走访了几家公司,一个奇怪的现象是:大部分公司都和该办公大楼的物业就周末是否开空调的问题沟通过,他们说自己的员工特别积极,很多人周末了也到公司来上班,公司要为他们提供一个良好的工作环境。员工和公司,孰对孰错?
我觉得两个因素:
1、员工被“洗脑”了,真觉得不干活都不好意思跟同事打招呼
2、公司该洗脸了,为什么就不能构建一种可以让员工在家干活的环境?如果是涉及到机密与核心问题,那另当别论。但总是可以为大家设置一些在家里也是喜闻乐见的软性任务吧?
好消息就是,大家现在越来越关注这样类似的话题,关注工作和生活间的平衡。再先进的技术,再先进的过程(精益),再被人推崇的公司,都不能脱于这个话题。毕竟是份工作,每个人有每个人的特点和需求。大家量力而行吧。
再来看看这个兄弟碰到的上司:www.javaeye.com/topic/213612?page=1
一个最新的证据是:同仁堂39岁董事长心脏病发猝死
这些事实都告诉大家,什么40岁之前拿命换钱的说法是多么荒谬~
Giampaolo说的很对。我觉得这样的事情发生,与公司无关。健康是自己的事情,自己为自己负责。
比如说effort estimation,本来基于过去的velocity可以得出一些预期的项目估计,如今因为加班的话,在其中加入了一些变量,更困难了。如果把加班带来的velocity作为常态,则难以为继。如果作为一个校准,则难以度量其影响。
加班,做敏捷的最好别沾上。
本文主要讲述了如何用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的未来规划。
14 条回复
回复