|
9. 误区：敏捷是反文档的。项目管理者联盟
文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题?难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。项目管理者联盟
应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。service.mypm.net
因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。项目管理者联盟
文档不是目的，有效沟通才是目的。项目管理者联盟
就工作量而言，不写文档，减少写文档时间，看起来确实可以加快开发速度，但实际会严重伤害项目。互联网应用开发不需要似传统大型软件开发那样，按照软件工程，花大量时间去写文档。不要为了写文档而写文档，而是为了开发而写文档。club.mypm.net
例如需求文档(或者功能文档-可以含有版本信息，业务流程文档，互通操作文档)，无论具体形式如何，需要清晰地给出你的应用针对什么，提供什么，解决什么。需求文档有时也可以作为测试的指导。如果是client+server，你需要给出本期目标的性能，可以简单到一两页纸，但是绝对不能缺。在迭代开发中，你不断地修改它，它是你开发的轨迹。项目管理者联盟
例如开发文档，不一定要什么概要设计、详细设计这类学院派的东东，但是你需要有文档能够清晰描述开发对象的架构，模块划分，client和server的交互流程，以及关键的核心技术，例如，如何避免client和server中过多连接造成的server压力，为何采用长连接tcp而非upd(反之亦然)，如何制定心跳，是否需要通过使用底层的socket进行特定优化等等。你至少需要从架构师的角度对产品进行梳理，描述实现的架构、采用的机制和关键技术。开发文档或繁或简，甚至可以在代码中通过注释说明，利用javadoc生产HTML，格式不论。项目管理者联盟
不要让文档成为开发的负担，而是成为帮助。现在工作的流动性很大，没有文档，当中一两个开发人员离职，如何后续处理。没有开发文档，在架构和关键技术上没有想清楚，贸然而上，开发的永远只是个demo产品。项目管理者联盟
没有任何文档，极容易导致推出后，疲于奔命地修修补补，每天一个版本。敏捷开发是快，但是快不等于敏捷开发。项目管理者联盟
10. 误区：敏捷是自由的，无约束的。项目管理者联盟文章
敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。但是应该清楚，凡事都是要讲究一个平衡，人也是两面的，消极的一面和积极的一面同时并存，绝对的自由会放纵人消极的一面。敏捷并非是绝对自由，无约束的。作为管理者，有一个职责，就是引导团队成员用自己积极的一面去压制消极的一面，不能放任团队中出现搭便车的现象，否则将打击整个团队的士气。如果实在无效，那就只能将其排除出团队了，这个惩罚够有约束力吧?www.mypm.net
文章来源：懂点项目管理项目管理者联盟
training.mypm.net
|
