程序员讨厌写文档？敏捷开发真能省掉它吗

众多程序员认为敏捷开发所拥有的最大益处便是无需去撰写文档，是这样的想法实际上显露出了一个普遍存在的问题，那就是大家仅仅将敏捷当作一种技术方法来进行学习，然而却并没有领会它背后所蕴含的逻辑。

学语言还是学思维

有不少团队在引入敏捷开发之际，那种态度恰似去学习一门编程语言。他们着重关注具体的仪式，像是每日站会该如何去开，迭代周期要怎样来定，然而却忽视了敏捷乃是为了回应变化才被设计而成的这点。这样一种“仅是学方法，却不学思维”的行事做法，致使好多人将避开文档以及减少流程当作是那种微小而确切的幸福。

实际上，敏捷并非致使团队不撰写文档，而是要撰写恰好足够用的文档。有一位身处杭州的某互联网公司工作达三年之久的后端开发人员告知我，其所在团队每两周便会进行一次迭代，技术文档仅仅记录核心接口以及数据库变更。结果是该项目历经半年时间，当新人接手时全然无法看懂业务逻辑，原因在于诸多决策过程都留存于大家的聊天记录之中了。

培训师不懂你的项目

不少公司所聘请的敏捷培训者属于专业讲师，并非产品经理，亦非项目经理。这些人在谈及Scrum框架时，说得有条有理，然而他们并未实际带领过项目。有一家位于上海的金融科技公司的技术总监向我抱怨，他们花费八万元聘请了一位认证培训师，这位培训师授课两日，最终团队依旧不清楚该如何应对老板临时添加的需求。

大公司之中人才并不匮乏，然而，决策流程耗时长久、项目周期严重超出标准范围的状况依旧存续着。有一位身处北京的头部电商企业的项目经理讲道，他们的需求评审环节需要经由五个部门依次签字，待整个流程全部完成的时候，市场环境已然发生了变化。在这样的情形之下，敏捷开发被视作能够挽救局面的关键举措，不过，真正的问题根源并不在于开发方法于此。

CMMI和敏捷各有各的用

把某个领域的知识予以模式化的进程是CMMI所开展的事项，随后将其复制到各异的客户那里，这样的方式适宜于需求清晰、变动较少的项目，像是政府系统、银行核心交易系统这般的，然而敏捷则契合需求不明确、需要迅速进行试错的情景，例如面向普通用户的App。

环境发生了改变，敏捷这才拥有了施展本领的空间。以往不少服务经由企业之后才传递至个人，如今互联网使得服务能够直接抵达用户。至于用户所期望获得的事物，相较于工程师能够做到的事情更为关键。倘若缺失乔布斯那般的灵感，那么察觉需求最为有效的方式便是进行试错。有一位身处深圳的创业公司创始人讲道，他们打造了一款社交产品，前三个版本均以失败告终，直至第四个版本才寻觅到那群合适的人。

老板眼中的敏捷不是节省时间

从老板这个角度来讲，敏捷开发不一定就会节省时间，然而却能够更早地知晓产品方面的问题，且能更加准确地了解项目成本。有一位身处成都负责电商系统的技术负责人讲了这样一件事，他们在第一个迭代的时候仅仅做了登录注册以及商品浏览这两项内容，老板在看完演示之后便直接把三个功能给砍掉了，原因在于那些功能用户根本就不需要。

喜欢敏捷的程序员，是由于小改能够避免大改。有一位来自广州的游戏公司主程分享，他们以前运用瀑布模型，需求一旦变更，就要去修改几十个文件。换用敏捷之后，每两周便会交付一个可玩的版本，产品以及运营在看到实物之后所提出的修改意见，反倒变得更加准确。但这并不意味着能够随意修改，每个迭代的目标在启动的时候就需要锁死。

技术大牛往往是最大风险

团队当中，最具危险性的并非那些对敏捷仅有浅尝辄止认知的人员，而是技艺高超的技术大牛。在一次项目开启会议上，一位负责后端系统架构设计的工程师决定去尝试全新的技术框架。当首个迭代周期完结的时候，他通宵达旦地工作，并且提议将时间延长两周，声称新的框架能够带来高达十倍的灵活性。然而，三周过后，底层的模块运行成功了，可是前端的功能却一个都尚未完成。

老板等待了一个月，期望查看演示，然而项目却无法拿出成果来。敏捷开发需尽力规避完美主义，要确保稳定持续地输出。项目自身不应当成为新技术的试验场所。这位架构师随后承认，他对于技术实现是否优雅更为关注，而非业务是否能够运行通畅。

Scrum Master到底该不该写代码

国内不少人觉着Scrum Master是那种不投身于开发过程，单单进行起思想方面安抚工作的精神激励者，然而在国内多数团队当中，这样的身份根本无法安稳存在，一位投身于南京敏捷教练工作长达五年之久的人表明，他实际的身份是兼具产品经理以及项目经理特质的存在，属于项目的负责人，唯有如此才能够朝着老板去争取所需资源，抑制住技术领域极为厉害人群不由自主爆发的冲动行径。

技术背景对于判断周期以及风险是存在一定帮助的，然而却会致使Scrum Master抑制不住想要参与技术实现。有一个人分享了一个失败的案例，那就是同时管理三个并行的项目，在这当中他参与程度最多的那个项目反倒进展最为不顺利。数据库设计的速度较为缓慢，他认为设计不够美观便直接动手进行了修改。正确的做法应当是把开发权归还给DBA，仅仅从输出的结果来评估是否能够交付。

并非所有项目中，程序员背景性格皆相异，那样便不存在敏捷开发这个所谓的“万能药”，Scrum Master虽不参与代码编写，然而借助推动程序员来达成产品，此本就是编程的别样形态。

你认为于你们团队之中，敏捷开发切实落地所存最大阻碍究竟是什么呢？欢迎于评论区阐述你的经历，同样别忘记点赞并转发给正在因敏捷而苦闷的同事哟。