大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
裁员下的敏捷
作者 Mark Levison 译者 麦天志 发布于 2009年1月10日
Adrian Carr提到在裁员下如何让团队能继续以Scrum方式运作。原本团队有四个开发人员，一个测试人员，一个产品负责人，以及一个Scrum Master。在裁员下，团队只剩下四人，Adrian当上了兼职的Scrum Master，并没有产品负责人。相关的业务单位也同样面对裁员，所以只能提供一个“明白该业务并且已受权对项目作决定的高级联系人”。Adrian所面对的问题是：保存Scrum的哪些部分？Adrian的初步想法是：
- 保持Scrum中在小团队中有意义的部份：每日站立会议、短迭代、检讨、回顾、Burndown
- 团队分别承担产品负责人的工作，如跟各方有关人事、用户等会议，但Adrian会维护产品Backlog，以及作出最后决定
- 减少浪费
- 把事情保持得尽量简单
- 只考虑现行运作系统上的故事点数（story points），使团队只付运较少点但易管理的功能，也缩短开发周期，提高回馈密度
- 同一时间只处理两三个工作任务
- 集中先做最有价值的项目
- 清楚是为谁做软件，知道他们的名字，职位角色，知道他们为什么想这样做
- 留意及抵抗一切拖慢团队的外在因素
Innovel公司的Robin Dymond关注一个主要问题：欠缺一个专职的产品负责人。他指出让开发人员当上产品负责人的角色，会使他们变成了业务专家，占据了他们应该用来做开发的时间。他建议：
如果业务人员没有时间的话，可以让开发队伍跟他们紧密地开短会议，业务人员可以同意接受条件而不用亲自去写，他们只专注于优先次序。但他们一定要承担这责任，开发团队不能当上这角色，因为开发团队难免对要求有其他的理解，有不同的优先考虑，作出跟商业世界不一样的决定。
Mary Poppendieck（"Implementing Lean Software Development"一书的作者）则认为，产品负责人常常都不是必需的，甚或都用不到去考虑这个角色的存在，因为如果开发人员明白客户所要的东西，那 产品负责人就是两者之间多出的层次，而资讯亦可能因为多了一层而流失。Mary认为，关键在于找出各方都能同意的简易衡量方式作为目标，然后所有功能都能 以它对这目标所带来的价值作出衡量。
Ron Jeffries认为要小心潜在团队、产品负责人、业务部门之间不清晰的可能性，如果产品最后未必符合客户所要，业务部可能会责难开发团队所作出的决定，Ron指出，传统产品负责人或顾客角色的好处是在于，如果产品未能满足顾客期望时，业务部门对自己负责，而不是责难其他人。
查看英文原文：Doing Agile After Layoffs
译者 麦天志 现就职于Odd-e从事团队教练工作，从小对编程产生兴趣，毕业於香港大学，主修计算机科学。
没有回复
关注此讨论 回复