写博客如何助力敏捷团队

把团队的决定和考量从成员的私人收件箱放在博客上，可以让所有成员触手可及、未来易查易得、所有人有所参考。你完全可以用写博客的方式（blogumentation），而非写文档的方式（documentation），来传播知识和记录项目历史，以提供代码的来龙去脉。

Matt Jukes 是 mySociety 的产品经理，最近在 Agile Cambridge 2017 峰会 讲述了开放的重要性。InfoQ 以 Q&A、总结和专题文章的形式报道了此次峰会。

InfoQ 采访了 Jukes，话题涉及开放为何重要、合适的博客话题有哪些而不合适的又有哪些、敏捷团队和管理者可以从写博客中获得哪些益处以及写博客的优秀实践策略。

InfoQ：您为何认为开放很重要？

Matt Jukes：对我而言，英国政府数字化服务项目（UK’s Government Digital Service (GDS)）设计原则的第十条总结的再好不过了，“开放，让事物更美好。”互联网是基于开放而建立的。虽然现在我们可能生活在互联网巨头不断建立高墙隔阂的时代，开放依旧是更加宏伟的，开放让人们与世界各地的人们分享和互相学习——这是我热衷互联网的动力所在。

我觉得，写博客是互联网上最为纯净的开放形式之一（并不始终如此）。开放的核心精神是慷慨。人们明白，通过公开分享自身经验，其实是在为全球范围内帮助他人的事业作出贡献。作为产品经理和领导者，我从博客中学到的比我从书本或者课程中学到的都多，所以我觉得自己有责任做出回馈。

InfoQ：合适的博客话题有哪些？不合适的又有哪些？

Jukes: 我不太喜欢诸如社交媒体纲领或者博客发表计划之类的东西——我个人和我所在的团队都不喜欢。然而我确实希望人们能够多写常识性文章，另外我认为话题不应该有限制。

你觉得没什么意思的话题或者太基础的话题会迅速被读者接受（而在其他情况下，你觉得特别有意思的内容可能根本没人看！），这还是很让人惊诧的。

即便如此，我的博客主要是为自己而写——理清自己的头绪和自言自语。我鼓励大家撰写 #weeknotes ，用他们最基础的水平来写，就像是工作周记一样。坚持写周报虽然简单，却可以让问题和其他人觉得有意思的想法浮出水面。

我写的博客中最受欢迎的话题是有关与敏捷团队工作和领导敏捷团队的——这是个永不终结的流行话题。很多技术同事都写过以“如何……”开头的流行网文，但就像我之前说的，你真的根本不知道什么内容会流行。

比较难写的博客是你在工作中处于困境的时候——我称为“煤矿中的金丝雀”博客（注：煤矿工人会利用金丝雀检测煤矿中的一氧化碳等气体，如果这些有害气体大量聚集，金丝雀会死亡——这可以作为矿工安危的指示，矿工可以及时逃生）。如果你在写博客的时候发现自己老是在对自己进行自我审查和二次猜测，那问题可能没出在写作上，而是出在你写作所处的环境中。

InfoQ：敏捷团队可以从写博客中获得哪些益处？

Jukes：我认为，写博客在几个大的方面是有助于（敏捷）团队的。首先是，（我认为）良好的团队一定会有畅通的沟通。很多的敏捷实践形式都只是试图增加团队内部交流，写博客是增加团队交流的另一种有效工具。

另一个益处是英国政府数字化服务项目曾经说的“发布（博客），而非发送（邮件）”。这一理念是基于这一观点而得出的：将团队成员的所思所想和所做的决定从他们的收件箱转移到博客上确实是有益的，博客是所有成员触手可及、未来易查易得、所有人均可参考的。

与此相关的是写博客的另一个巨大好处——敏捷团队经常受知识传递和文档的困扰。我总是喜欢说写博客——鼓励团队轻松无压力地写博客，写他们关心的话题，这就直接变成了解说项目历史的文章，也提供了代码的来龙去脉。

InfoQ：是否可以推荐一些写博客的优秀实践策略？

Jukes：如果说的是我自己的博客，我可能给出的都不是最佳实践。优秀实践策略有这么几条：

• 为未来的自己而写。
• 发布博客之前找其他人通读全文——仅仅是检查，而不是编辑（我没这么做，但确实应该这么做）。
• 发布。优秀是良好的敌人。我认识很多人都写了一整个文件夹的草稿却从来没有发布过。
• 链接信息来源。该引用的时候就引用。
• 自然书写。你写的不是新闻稿或者教科书，所以不用费力写的太官方或者学术化。

查看英文原文： How Blogging Empowers Agile Teams

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。