从IT的角度思考BIM（三）：敏捷开发

人们看到了远处BIM的美丽胜景和阻挡在眼前的宽广河流。有些人自信满满地跳入河中打算孤身游过彼岸，可是却失败了。有些人匆匆忙忙地造了船胡乱地滑向彼岸，可是也失败了。

要如何继续这段探索之旅？

无论是《星际之门》还是《速度与激情》，好莱坞告诉我们无论一个人有多么牛，他仍旧需要一个紧密合作的团队。

本文将继续从 IT 的角度来思考 BIM，希望能给大家带来一些启发。

敏捷开发

我们先来看看百度百科里对敏捷开发的解释：“敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。”

百科中还列出了敏捷建模的价值观：沟通，简单，反馈，勇气，谦逊。

简单总结一下，敏捷开发就是：

一个价值观：沟通、简单、反馈、勇气和谦逊。

一个核心：以用户的需求进化为核心。

一个模式：迭代和增量开发。

一个目标：保持软件持续可用。

目标

《命令与征服》中有一句经典标语：One vision，one purpose（一个愿景，一个目标）。可以把这句话稍作改动来说明“保持软件持续可用”这个目标：One version，one purpose（一个版本，一个用途）。

软件开发中的原型是一个基本的实用模型，体现了软件的核心功能。原型经过不断的改进完善，形成了最初的可用软件版本。而随后的升版则是不断地完善软件的稳定性、性能以及功能。

产品需要目标，团队和个人也需要目标。

管理大师彼得·德鲁克在开创管理学时就提出了目标管理，可见目标的重要性。乔治·多兰（George T. Doran）在德鲁克的基础上提出了SMART原则，简单清晰地揭示了目标管理的原则。

SMART不是SM的ART，而是5个单词的首字母，分别是：

Specific（具体的），目标必须是具体明确的。

Measurable（可以衡量的），目标必须是可以量化衡量的。

Attainable（可以达到的），目标必须是可以实现达到的。

Relevant（相关的），各个目标的实现具有相关性。

Time-bound（有时限的），目标的完成是有时间限制的。

你也许听说过WBS，GTD，6点优先工作制，四象限法则，番茄工作法等等，这些方法的本质都是要进行目标管理。

BIM的目标是什么？解决碰撞问题？设计持续准确？项目持续可控？资源持续优化？进度持续加快？工作持续自动化？这些都可以是BIM的目标。目标既会限制视野也会扩大脑洞，选择的目标不同，开展的工作就会不同。

你希望BIM实现什么目标呢？

模式

目标不是凭空实现的，那么如何实现呢？

敏捷开发采用了一种模式：迭代和增量开发。

Scrum是敏捷开发的一个主要分支，它定义了一种工作模式，包含了特定的角色、流程和规则，以便使团队更有效率地进行开发工作。

Scrum中使用的术语：

产品订单（Product Backlog），按照优先级排序的功能需求列表。

冲刺（Sprint），进行迭代和增量开发的时间周期（通常是固定的），团队在此期间细化并实现部分产品订单，交付可用软件。

用户故事（User Story），以一种短小简单的方式从用户的角度来描述渴望得到的功能。通常描述为：作为一个<角色>，我想<功能需求>，以便<受益>。

燃尽图（Burndown Chart），通过可视化图形的方式显示剩余的工作时间与待做事项。

Scrum导师（Scrum Master），负责帮助、引导、管理团队按照Scrum工作模式开展工作。

产品负责人（Product Owner），负责设定和管理目标，维护产品订单。

开发团队（Team），由负责自我管理开发产品的人组成的跨职能团队。团队具有自组织特性，个体需要跨越他们本身的专业而尽可能想办法帮助团队其他成员。

计划会（Sprint Planning Meeting），在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行工作估算的计划会议。

每日立会（Daily Standup Meeting），是团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。

评审会（Review Meeting），在冲刺结束前给产品负责人演示并接受评价的会议。

回顾会（Retrospective Meeting），在冲刺结束后召开的关于团队与个体工作改进的会议。

Scrum团队用来改善工作质量的常用技术实践：

测试驱动开发（TDD，Test-Driven Development），在开发功能代码之前先编写单元测试用例代码，通过测试来推动整个开发的进行。测试驱动有助于优化和改善软件的设计和质量。

重构（Refactoring），通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

集体所有权（Collective Ownership），是指所有的开发人员共同负责开发过程中的所有产出内容，特别是代码和自动化测试。它鼓励任何一个团队成员可以在任何一个程序模块上工作，确保开发人员不会变得太专、只能从事某方面的工作，以免只有个别人清楚某个地方的问题、完成某项工作。

持续集成（Continuous Integration），是指尽可能快地将开发和修改过的代码通过自动化的方式进行集成并测试，从而尽早地发现集成错误。

结对编程（Pair Programming），是指两个开发人员一起写代码，互相帮助，积极讨论，能力叠加。

也许有人会疑惑：不就是写个代码么，怎么那么复杂？实际上建筑工程也不是画个图、砌个砖那么简单。

工作中我们经常能听到：我只是个建模的，我只负责结构计算，我只负责方案……也会听到别人说：他就是个建模的，他就是个计算结构的，他就是出个方案的……也会自己说：这模型是我建的，这结构是我算的，这方案是我出的……身处建筑领域的我们，是否思考过敏捷？是否打算采用敏捷？是否可以做到敏捷？这是一个值得探索和实践的方向。

不管BIM是不是佛瑞德·布鲁克斯的银弹，至少它对敏捷实践会有很大的帮助。建筑数据化给设计和施工的进化带来了更大的动力和空间。也许十年后人们只负责创意，剩下的事情全部由Cortana、Siri和Now来完成。

核心

一听到“以用户的需求进化为核心”，设计师怒发冲冠、拍案而起：改图？！

让子弹飞一会儿，咱们先看看ADAPT。

ADAPT是5个英文单词的首字母，它们是成功且持续实施Scrum必备的活动。

意识（Awareness）：意识到当前的工作方式已不再有效。

渴望（Desire）：渴望变革，渴望实施新的工作方式来解决问题。

能力（Ability）：通过学习新的思想、新的技术以及创造新的工具来拥有变革的能力。

推广（Promotion）：分享交流变革的知识和经验。

传递（Transfer）：将变革的影响扩大到整个公司，实现整个组织的敏捷转型。

有些程序员会因他们使用的语言建立自己的阵营，然后膜拜自己的语言，嘲笑和攻击其他的语言阵营。这像是技术宗教，语言就是教徒的神。在建筑领域也在发生同样的故事，只不过在这里软件工具才是神。CAD和BIM的口水战，各BIM软件的口水战……

当我们冷静下来时才明白，原始人钻木取火为的是取暖而不是烧香，语言和工具为的是解决问题而不是建立宗教。

如果模型可以自动生成，检查可以自动完成，图纸可以自动绘制，那么甲方和设计师是不是就可以牵手漫步在大明湖畔了？

别逗了，这些怎么可能做到自动呢？为什么不呢？到底是我们觉得不可能，还是我们没有能力让这些变得可能？看看我们的团队构成，建筑有了，模型有了，信息去哪了？建筑信息模型，听起来也和IT脱不了干系吧，可是仍有很多人对IT的认识就是“修电脑的，管网络的”。我们是否意识到BIM本质上就是一个关于建筑的数据模型，而我们现有的知识已经不够用了呢？是否系统性地思考过几个专业的协作和交融呢？使用CAD时我们也许没能意识到跨专业的重要性，但是使用BIM如果还是没有这种意识，那就只能呵呵了。

价值观

软件可以买，知识可以学，模式可以套，价值观呢？

一个人价值观的形成是有意识的还是无意识的？价值观可以进化或颠覆吗？

一个团队、组织、企业的价值观又是如何形成的？

稻盛和夫的经营准则是“做人何谓正确”，它表现为：公平、公正、正义、勇气、诚实、忍耐、努力、善意、关心、谦虚、博爱等。回看一下敏捷建模的价值观，非常相似。

阿米巴经营本质上和敏捷开发是一回事。星星还是那颗星星，月亮还是那个月亮，团队还是那个团队，人还是那个人。成功背后究竟是什么改变了，是价值观。

BIM可以精确到一个零件、一个螺钉，我们可以使用BIM计算出工程量以及投入的人力物力。在一个完全数据化的工作活动下，一切都是透明的，团队和工作是没有隐私的，实现“玻璃般透明”。

虽然实现这些有一些技术问题，但最大的问题则是——人们是否能接受。

企业高管们热衷于学习各种先进理论，然后感叹“听话的总是别人家的孩子”。人们被各种真人秀和梦想秀吸引了眼球，看着一个又一个的人“实现梦想”，而自己的生活却原地打转。一切的问题归根结底都聚焦到了人的问题。

为什么知乎上的回答者非常认真？为什么开源社区的人们愿意分享他们的代码？为什么萨尔曼·可汗愿意向人们提供免费的课程？

你准备好改变价值观了吗？欢迎来到BIM世界。