文化基因生命周期
Julian Everett和Chris Matts认为:一个IT业务案例可以作为一种“文化基因(meme)”。它要在市场区隔这样的复杂生态系统中与其他文化基因——也就是其他IT业务案例 ——竞争。他们还揭示了其背后的理念。
作者 Chris Sims 译者 郑柯 发布于 2008年9月30日 上午2时51分
每日站立会议是被广泛接受的敏捷实践。团队成员在其中分享:
Mike Cohn最近分析了站立会议的一些不同方式,这些会议将完成各个用户故事作为会议进程的一部分。
变种之一,是逐个报告各个故事的状态,而不是逐个人说明。Mike建议为每个故事指定一个“故事负责人”,即使有多人开发同一个故事,也由此人负责跟踪故事的工作进展。此人要在每次站立会议上说明故事的进展情况,至少要知道谁负责提供故事的最新状态。
另一种与故事状态联系起来的方法,是让团队成员指出他们的工作与哪个故事有关。要想推进这种方法,可以让大家在任务板前开会。任务板上的故事和任务之间的关系要保持清晰,当大家谈及自己的工作时,可以让他们指出自己处理的具体工作条目。
您的团队是否为了将注意力放在用户故事上,调整过每日站立会议的形式?请留下您的评论,告诉我们你们的具体方法以及产生的效果。
查看英文原文:Story-Focused Standups
作为经常被提到的敏捷和精益,是否真的需要每个人都说一遍自己昨天干了啥?
如文中所说:指定一个“故事负责人”,即使有多人开发同一个故事,也由此人负责跟踪故事的工作进展。此人要在每次站立会议上说明故事的进展情况,至少要知道谁负责提供故事的最新状态。 ──团队规模或者项目的复杂程度到了这个地步吗?team leader 自己无法跟踪全部的进度情况?还需要在一个敏捷团队中再指定一些负责人?
另外,文中提到“让团队成员指出他们的工作与哪个故事有关”。既然敏捷实践对于每个迭代周期都会控制的比较短,那么作为 team leader,不清楚前一天 team member 做得事情跟哪个故事有关吗?
如果一个 team leader 如上面所提到的工作,那说明他/她太不称职了!
一个称职的 team leader,应该在每天早上的 stand up meeting 上,通过与 team member 确认上一日工作和未完成的工作,来确认如下问题:
1.确认进度是否偏离,是否已经找到了偏离的原因和解决的方法;
2.确认质量是否超出可接受的下限,是否已经找到了原因,是否准备立即解决;
3.是否存在需要team leader来协调解决的问题;
4.明确当前工作目标。
但是作这个事情的时候,对于已经包含在计划中的工作,尽量避免反复的让 team member 来重复。
不过文中提到的思路,关注“故事”而不仅仅是完成了什么,是有益的,避免开发人员只关注代码完成,而忽略了“故事”作为一个工作任务的整体性。
Julian Everett和Chris Matts认为:一个IT业务案例可以作为一种“文化基因(meme)”。它要在市场区隔这样的复杂生态系统中与其他文化基因——也就是其他IT业务案例 ——竞争。他们还揭示了其背后的理念。
本演讲将探讨如何用Microsoft Visual Studio 2010搭配MSF for AgileScrum的流程模版,助力您的团队进行Agile项目的开发工作。本视频为第一部分,演示如何进行项目计划与跟踪。
相比其他行业,IT技术由于信息流动便捷,新技术更新非常频繁。架构师经常面临新技术及传统方案选择的困惑。架构师应如何抓住本质构建新一代的应用?本文从几个方面提出一些思路供架构师参考。
InfoQ中文站最近采访了微软的Ramesh,在采访中,Ramesh从过程控制、架构与设计的控制以及测试组织等方面分享了他所带领Visual Studio软件生命周期管理工具团队使用敏捷方式组织管理大规模软件团队方面的经验。
在去年10月份的Kungfurails大会上,InfoQ中文站有幸采访了从台湾专程赶过来的张文钿,与他探讨了关于台湾Ruby社区的发展、Rails的商业化,Restful Design等话题。
《代码之道》以一位微软内部人士的视角,揭示了关于软件编码、软件测试和项目管理的残酷现实。针对每一个话题,I.M.Wright都根据丰富的工作经验提出了自己的观点,并介绍了来龙去脉,令人信服。
2 条回复
关注此讨论 回复