大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
敏捷方法需要文档吗？
作者 Geoffrey Wiseman 译者 乔梁 发布于 2007年7月20日
有些人认为敏捷不需要文档，甚至不支持任何形式的文档化。在CIO杂志上的一个敏捷案例研究中声称，这是一个误解。Frans Bourmar最近写了一些关于敏捷方法与文档化的内容 ，而Ian Cooper据此写道：“该是'拨乱反正'的时候了”。
Ian 首先从敏捷宣言讲起。敏捷宣言指出有价值且可工作的软件胜于详尽的文档。他指出，敏捷宣言是一套基本原则和标准，用于检验某个过程是否敏捷，而不是一个具体的方法论。他以下面三种开发过程方法为例，来解释这些原则是怎样发挥作用的：
要理解这个警示，必须记住非敏捷方法论常有文档驱动开发的特征，因为在写代码之前，它需要以大量的文档作为输入。很多情况下，软件开发团队执行相应的过程步骤，只是因为方法论要求他们这样做，尽管它们几乎没有什么价值。结果，很多开发团队完全放弃了这些方法论。敏捷试图避免漫无目标的文档产物，而再次把焦点放在软件开发过程的关键产物上，即代码。不幸的是，很多人没有认识到应该抛弃什么，从而使那种即兴而为式或纸上谈兵式的有限文档成了目标，这些人基本上没有对瀑布式过程（如SSADM）进行完整的实践。
回想一下水晶方法是如何处理文档：
水晶方法把开发看作是一系列的协作游戏，而写文档的目标就是只要能帮助团队在下一个游戏中取得胜利就行了。水晶方法的工作产品包括用例、风险列表、迭代计划、核心领域模型，以及记录了一些选择结果的设计注释。水晶方法也为这些产品定义了相应的角色。然而，值得注意的是，这些文档没有模板，描述也可不拘小节，但其目标一定要清晰，那就是满足下次游戏就可以了。我总是将这些思想以下面的方式向我的团队成员表达：通过它们，你只要了解你明天加入这个团队所要知道的内容就行了。
而极限编程是如何对待文档的呢？
与水晶方法相比，XP认为在团队内外，文档都不必太多，并把它看作是需要交付给客户并由客户付费的故事。我觉得这样做的目标就是通过与其它特性集合进行对照评估，来减少多余的文档数量。XP更依重于开发人员之间的直接交流来传递相关的知识而不是依靠写好的文档，而结对编程使其成为可能：因为通过结对，你就可以和其它人分享对系统的理解，而消灭“死角”，也就很少需要文档来记录这些知识了。另外，代码与测试也被看作是描述软件实现细节的文档，它没有更新不及时的问题……总而言之，就是团队必需的东西或者客户想要的东西。
在你的敏捷项目中，应该有多少文档呢？对你来说，多少算多，多少算少呢？
查看英文原文：Do Agile Methods Require Documentation?译者 乔梁 有十多年软件开发及项目管理经验，专注于提高软件企业提高交付能力。现任百度项目管理部高级架构师。
讲讲了
发表人
zhou Glamey
发表于
只写有价值的文档
发表人
小刀 凉粉
发表于
文档是必须的。
发表人
竹十一 Julian0zzx
发表于
Re: 文档是必须的。
发表人
小刀 凉粉
发表于
Re: 文档是必须的。
发表人
He Yiding
发表于
Re: 文档是必须的。
发表人
小刀 凉粉
发表于
Re: 文档是必须的。
发表人
lee tom
发表于
Re: 文档是必须的。
发表人
dmhorse dmhorse
发表于
-
这个说的是什么呢 ，能给我讲讲吗？我现在也是正在研究java，比较感兴趣哈。
-
对于那些无谓的需求，设计文档，要保持同步是非常浪费的一件事情。所以还是写该写的东西，比如Story Card，不也是文档么？
最痛恨的就是为了应付什么CMM或者CMMI的评估来写文档，tnnd，评你MB！估你MB！ -
即使是在XP中，文档也是必须的，成文的东西总是要比口头的东西来的实在！
考虑极端的情况，如果小组的人全都离职了，这时候软件如何更新呢？总不能天天电话里跟那些离职的员工XP吧？
我觉得关键在度的问题。文档要适度，不能成为小组工作的累赘，又要做到出现争议的时候有具可查。
在我看来，至少有两份文档是必须的：需求文档和概要设计(Requirement and High Level Design)。需求文档的目的是告诉大家，我们开发的软件要做成什么样子要实现那些功能，这份文档应该是经常更新的，记录XP过程中最新达成的结论。概要设计的用处是让同志们在XP的过程中不会脱离开轨道，天马行空是没错，可马儿总得奔着青草跑吧？至于在细枝末节上的东西XP的过程能解决的很好。
其实还有一份文档如果有，可能会效果更好，这份文档就是关于UI的文档。可用性(usability)对一个软件来说非常非常重要，就跟大家都喜欢美女帅哥一个理由。相比较来说这个文档可能只是个demo和一些简单的说明，它应该是很XP的。 -
我也不否认应当要有必要的文档，但是Story card加上充分的测试用例能不能代替需求文档呢？毕竟要保持文档的同步是非常痛苦的一件事情，除非可以弄一个CM专门做这件事情。
-
如果成员离开后你还必须联系他们才能继续工作，那说明他们留下的代码很糟糕，以至于看都看不懂。
-
对啊，就是这样子
-
完全同意。的确，文档是必须的。
项目开发很大程度上是探索和管理的过程。
没有文档，常常没有有效的累积，没有进一步改进的基础。逃避文档，往往是在逃避清晰准确的表达需求和目的的努力，逃避由于“白纸黑字”所带来的责任。
文档应该精简，目标和思路最重要。文档应该分为多种层次和形式，应用场景描述、需求分析、架构设计、业务/流程建模、项目包、代码结构、方法名、注释、第三方包文档等都是文档。不同层次和形式的文档适合于表达不同的内容，在不同的条件、策略下保持更新。
经过梳理和提炼的需求和设计文档至关重要，想想面对客户，你怎么和他沟通；新成员加入，你让他顺着什么思路快速了解情况，把握轻重...
毕竟，不是每个人都有着同样的思维，就是我们自己，也需要不断的清理、释放，才能放心的不断前进。 -
不同意楼上的,面对客户,他们根本不愿意看这些所谓需求文档和设计文档,与客户沟通的方式最好是在短时间内拿出可运行的软件,或者prototype(UI)
CMMI要求的文档大多被SEPG组织理解后,建立一套庞大但低效的文档库,让程序人异常痛苦
新人进来最好的方法是XP和交流,而不是单纯看一堆几百页的文档,看过的人,有多少新人能真正理解了呢?
我觉得User Story是最能表达需求的写法,在撰写User Story也会去努力的消除所有的假设,但一字一句将所有细节撰写下来,太浪费时间了,特别是保持文档同步,如果CMMI需要,让product manager去弄吧
8 条回复
关注此讨论 回复