经过一系列的避坑警醒，以及前期准备工作，程序员们期待的产品开发工作就要开始了，但作为创业软件，与传统的软件开发是大大的不同。就我所知，基本上大多数的企业管理软件开发，都在走瀑布式开发，而互联网类型的变动太大的软件，走的是敏捷开发模式。

敏捷开发以用户角色为中心，通过不停的深化用户故事，反复迭代产品，不光能适应变化，而且是最贴近用户使用体验的开发模式，值得好好学习。

传统网络公司的瀑布式开发与其难题

• 假设一个产品需要六个月，以下是最常出现的时程：
  • 花了3、4个月访谈需求。
  • 花1个月请美术设计视觉与接口，以及反复修改。
  • 最后，剩下不到两周再请RD进场写程序。
• 这种开发方式被称为是“瀑布式开发”。
  • 手段是先搜集完备规格，然后再开工。
• 工程师往往对参加这样的会议会感到很痛苦。因为现场老是会出现这样的冲突：
  • 项目经理可能这功能觉得很容易，不太费劲。
  • 但是工程师觉得这明明很复杂，于是被激怒了。
  • 项目经理觉得理所当然的功能，但工程师身为网络重度使用者，一看就知道不可行，双方吵起来。
  • 程序设计一直拒绝项目经理提出的功能，项目经理觉得程序设计不尊重业务专业与创意。
• 瀑布式开发型的项目，整个开发周期当中80%的时间。
  • 往往花在这些会议上，确保产出“完备的规格”。
  • 等到规格写完之后，才会再把这些规格交给视觉设计师去设计接口。
• 这种开发方式，其实很像是在豪赌。
  • 也是一种ALL IN的方式，中间没办法转向。
  • 只能将赌注压在一开始的决定上。

现今的互联网公司：敏捷式开发

• 敏捷Agile。有别于过去瀑布式开发的作法，敏捷强调适应真实需求的快速变化。
• 什么是敏捷式开发？
  • 2001年2月，Martin Fowler、Jim Highsmith等17位著名的软件发展专家齐聚美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。
  • 在这次会议，他们正式提出了Agile（敏捷开发）这个概念，并共同签署了《敏捷宣言》。
• 敏捷宣言
• 《敏捷宣言》的开场如下。
• 借着亲自实践，并协助他人进行软件开发， 我们正致力于发掘更优良的软件开发方法。 透过这样的努力，我们已创建以下价值观：
  • 个人与互动：重于流程与工具。
  • 可用的软件：重于详尽的文件。
  • 与客户合作：重于合约协商。
  • 回应变化：重于遵循计划。
  • 也就是说，虽然右侧内容有其价值， 但我们更重视左侧内容。
• 敏捷宣言背后的原则
• 《敏捷宣言》提到，他们遵守下列这些原则
  • 我们最优先的任务，是透过及早并持续地交付有价值的软件，来满足客户需求。
  • 竭诚欢迎改变需求，甚至已经处于开发后期亦然。 敏捷流程掌控变更，以维护客户的竞争优势。
  • 经常交付可用的软件，频率可以从数周到数个月，以较短时间间隔为佳。
  • 业务人员与开发者必须在项目全程中天天一起工作。
  • 以积极的个人来建构项目，给予他们所需的环境与支持，并信任他们可以完成工作。
  • 面对面的沟通，是传递信息给开发团队及团队成员之间效率最高且效果最佳的方法。
  • 可用的软件是最主要的进度测量方法。
  • 敏捷程序提倡可持续的开发。
  • 赞助者、开发者及使用者，应当能不断地维持稳定的步调。
  • 持续追求优越的技术与优良的设计，以强化敏捷性。
  • 精简――或最大化未完成工作量之技艺――是不可或缺的。
  • 最佳的架构，需求与设计皆来自于能自我组织的团队。
  • 团队定期自省如何更有效率，并据此适当地调整与修正自己的行为。
• 敏捷带来的作法以及其他带来的好处
  • 敏捷式开发的项目有几个特点：
    • 将软件切分为不同版本，逐步开发。而非一次性讨论与开发最终版本。
    • 舍弃厚重的规格，每个开发循环版本里，只实做当前版本能够对客户有价值的功能。
    • 保持计划的灵活性，若发现原始方向不对，立刻拥抱变化。
    • 每日沟通与测试修正，让非开发人员也高度参与开发过程，确保交付出正确的软件。
    • 利用流程与程序码，记载软件需求，而非撰写厚厚文档。
• 我在这里白话翻译一下：
  • 敏捷开发不写规格，作法是围绕着项目的核心价值开发功能。
  • 每周检讨实作结果，并且调整方向。
  • 采用版本释出的方式，逐渐完善整个产品。
  • 特别适合小团队采用。
• 敏捷开发并非不写规格。
  • 只是规划项目的角度与实做方式跟传统很不一样。
  • 敏捷开发中，是用另外一种方式：“User Story”（使用者故事），

去沟通协作一个项目里面应该被执行实作的细项。

User Story：回归产品真正的本质

• 什么是User Story？
  • 软件开发的目的应该是让“使用者能够在系统上完成有价值的事”。既然如此，我们应该回归本质。
  • User Story，就是一种新的叙述方式，强调透过简单的语境，具体描述软件在“使用者”的手上，怎么样被“操作”。
  • 透过一个一个使用场景，整理出会在这个系统里面出现的“角色”以及“会完成的工作与价值”。
  • 这里是一些User Stories的范例：
    • 使用者可以在网站上张贴履历，以达到履历曝光的效果。
    • 使用者可以搜寻有哪些工作，以提升检索效率。
    • 公司可以张贴新工作，以曝光职缺。
    • 使用者可以限制谁可以看到他的履历，以避免被前东家发现要跳槽。
  • 一个网站的真实价值与“主要功能”，大概用10-20条用户故事就可以叙述完毕。
• 以角色为轴心，找出被掩盖的复杂度
  • User Story“用户故事”撰写，是以角色作为划分：身为“什么角色”，我要“做什么事情”。
  • 为什么多数的瀑布式开发项目做不完？
    • 很大的原因是因为都是做到最后，才临时在某个画面或者软件工程细节里面，
    • 发现竟然隐藏大量的技术细节需要实现，导致工作量暴增。
  • 透过先写User Story的方式，我们可以提早把这个项目里面“有多少角色”、“有多少要完成的事”，先在纸上迭代，估算出来。甚至可以暂时把“不重要角色”要做的事先忽略。
  • 可以光用几张 A4纸，就能将第一版工作量的粗估出来。后续再依项目时程人力，工作量与优先权，删减迭代。
    • 哪些功能在最初几个礼拜就要先实做，否则会阻挡后面开发？
    • 有哪些功能可以上线前再添加，甚至是上线后再做也不迟？
    • 哪些功能完全没必要存在？
  • 这些功能将在一个一个迭代循环之中，被实做或被舍弃。
• User Story 的核心规划有几个重点：
  • 在纸上预先迭代工作量。
  • 每个版本都是“相对性的完整版”。
  • 实际的细节份量，可以针对版本的不同以及人力的分配去递增。
• 如何撰写User Story？
• 以下我以OTCBTC为例子，示范怎么拆User Story。
• 第一版
• 第一版的User Story可以不用很复杂：
  • 使用者可以在网站上张贴广告卖币
  • 使用者可以在网站上张贴广告买币
  • 使用者可以在网站上看到广告下单买币
  • 使用者可以在网站上看到广告下单卖币
• 第二版
• 我们发现其实有两个流程重复，为了避免前期开发太过复杂，因此决定先做发广告卖币，下单买币。
  • 身为一个商家，我要能够在后台上架卖币广告，并且设定上架贩卖。
  • 身为一个消费者，我要能够在前台看到广告，并且下单购买。
• 这时候明确引入角色。
• 第三版
• 把隐藏的前期细节加入：
  • 身为一个商家，我要能够在后台上架卖币广告，并且设定上架贩卖。
  • 使用者必须要储值数码币进来，有足够的余额，才能够上架广告。
  • 身为一个消费者，我要能够在前台看到广告，并且下单购买。
  • 使用者必须经过身分认证，才能使用下单购买功能。
• 第四版
• 将隐藏的功能梳理出来，变成主要大功能：
  • 身为一个商家，我要能够在后台上架卖币广告，并且设定上架贩卖。
  • 身为一个消费者，我要能够在前台看到广告，并且下单购买。
  • 身为一个使用者，必须在网站上拥有数码货币钱包，进行储值、提币。
  • 身为一个使用者，必须经过身份验证功能，才能使用完整功能。
  • 身为一个使用者，为了确保资产安全，必须绑定联络方式。
• 这个时候，把主要的Must Have找出来。
• 第五版
• 展开主要大功能，继续展开Must Have里面的细部：
  • ✓      身为一个商家，我要能够在后台上架卖币广告，并且设定上架贩卖。
  • ✓      身为一个卖家，可以在管理后台上架广告。
  • ✓      身为一个卖家，可以在发布广告时调整价格。
  • ✓      身为一个卖家，广告锚定的应该是全球BTC行情均价。
  • ✓      身为一个卖家，可以在买币者下单后，与卖家沟通进行交易。
  • ✓      身为一个卖家，可以在买币者付完钱汇款后，提供数码货币给对方。
  • ✓      身为一个卖家，可以在买币者下单后，收到通知后，立即处理订单。
  • •       身为一个消费者，我要能够在前台看到广告，并且下单购买。
  • ✓      身为一个消费者，可以在前台看到下单广告列表。
  • ✓      身为一个消费者，可以在前台看到广告内容详情。
  • ✓      身为一个消费者，可以在下单后，与卖家沟通，进行交易。
  • ✓      身为一个消费者，下单之后，卖家数码货币必须进行锁定，确保交易安全。
  • •       身为一个使用者，必须在网站上拥有数码货币钱包，进行储值、提币。
  • ✓      身为一个使用者，可以申请一个钱包 (BTC/ETH) 。
  • ✓      身为一个使用者，申请钱包后，可以拿到一个数码钱包位址。
  • ‧ 身为一个使用者，可以储值到钱包位址（6个确认后到帐）。
  • ✓      身为一个使用者，可以发起提币。
  • •       身为一个使用者，必须经过身份验证功能，才能使用完整功能。
  • ✓      身为一个使用者，必须通过Email验证。
  • ✓      身为一个使用者，必须通过实名验证（身份证）。
  • ✓      身为一个使用者，必须通过进阶验证（银行提款卡、信用卡）。
  • •       身为一个使用者，为了确保资产安全，必须绑定联络方式。
  • ✓      身为一个使用者，必须通过Email验证。
  • ✓      身为一个使用者，必须绑定两步骤验证。
• 透过这样的方法，我们逐步找出这个产品最关键的功能与流程

用重构式开发，打闪电式战争

• 一般来说，User Story写到第五版。大致上的骨架就会出来。
  • 大骨架在完稿时大概会是20条上下的主要框架。
  • 中骨架是在大骨架下继续展开的Must Have功能，展开后大概会有100条。
  • 这100条里面有更小的细节，最后扩展最终会达到大致1000条左右的规模
• 我们会在大骨架完稿后，先做一版流程图，确定业务逻辑方向不会被这些细节分散。
• 开发方向：确定主干后，闭环重构
  • 主动线确立后。团队的主程序在开发时，并不会优先实做各个画面的细节。而是直接把每一个大的User Story的画面骨干，先开发出来，串成一个完整的Workflow。团队再以“重构”的方式，去补完每个画面的细节。
• 重构式开发的好处
  • 重构式开发的好处在于在第一周动工时，就有一个非常粗糙的1.0版本。能让整个团队成员知道目前系统有多少条确定的“闭环功能主线”，骨架非常明确，有了明确的工作方向以及工作量预估。接着整个团队就能够以“重构每个功能画面”为目标去前进。
    • 程序设计师可以专注完善该功能的细节。
    • 美术设计可以专注设计该功能的画面。
  • 达到平行开发的目的，两者可以各自完工后再整合，加速整个开发流程的速度。
• 如何在35天迭代出OTCBTC
  • 目标是得在11/01前上线OTCBTC。我们是在9/22确立项目，也就是剩下不到40天的时间。
  • 但是经过使用者访谈后，他们不这么认为，强调完整版一定要有双向广告。要知道，如此一来，系统里面就有两种角色：
    • 发广告的卖方。
    • 发广告的买方。
  • 而系统每多一个角色，工作量就多一倍。多加一个币种也是多一倍工作量，这当中的架构线图，甚至在第一版复杂到搭不出来。同事都崩溃的不知道如何动工。
  • 最后怎么解决的？“骗”字诀！我哄着大家：“这样吧！我们第一版求上线就行。有事我担。”
  • 第一版，只做：
    • 只做卖家广告。
    • 只支持BTC。
    • 只支持简体版。
  • 既然卖家广告线已经做完了。那我们反过来加买家广告要花多久时间？
  • 既然BTC都做完了，那支持ETH要花多久时间？
  • 那我们可以支持繁体版吗?
  • 我们就用这种“诡异的迭代法”，在短短二十几天内把第一版OTCBTC “逼”出来了。
• 高速开发的诀窍
  • 第一次做区块链服务，花了比较久的时间。用的也是类似的方法。
  • 这当中的秘诀就在于：
    • 控制难度，控制角色复杂度。
    • 在非常早期，就找出真正有价值的功能，其余尽量舍弃或变通。
    • 点出地图上的终点，让团队第一时间都知道最终要盖出什么。
    • 平行开发，没有谁挡谁的进度。
• 我们在开发过程当中，还用了其他工具加速团队协作。
• 第一版的OTCBTC，完成的小故事、功能，总共高达600条。
• 在后面的章节，我会继续分享，我们是借助什么工具和流程，展开以及收敛使用者故事，达到快速上线的效果。

作为创业公司的老板兼产品开发经理，我想经过上续的工作，产品的雏形初现端倪了，下一步，就是要确保时限了，创业公司的时间如金钱，因此如何确保不超时，就特别关键了。