虽然在自己的项目里面，一直坚持着向敏捷开发靠拢，但毕竟公司瀑布模型用惯了，而且本身也是处在传统行业，和由互联网发扬光大的敏捷开发也在很多地方有所冲突，所以还没有达到理想中的效果。上周的作业，也对本地的快速研发流程做了总结和设想，结合这周的阅读，还可以进一步总结和完善。这篇文章，也希望今后能够不断更新。
20170902
既然计划后续更新，就在开始起个头吧，注上日期。
- 敏捷工具实践。
目前主要还是使用的依赖TFS开发的管理工具，这也是公司全球统一的工具。但对于产品经理来说，还是有很多限制，比如不能随时访问，Dashboard不够清晰，操作复杂等。在一些小的项目里面，尝试使用过一些其他工具辅助管理，例如Teambition, Tower, Trello, Leangoo等。结合个人使用情况，觉得主要的问题就是过于分散以及动力不足。由于只是尝试，很难让大家养成习惯，每天更新任务状态，工具往往流于形式。并且电子化的看板，虽然更利于记录，但缺少了透明化的展示。正如书中提到的，实体看板最大的好处就是随时可见，项目成员、老板路过都会看两眼，每个人要自己贴条，也是一种督促和帮助。如果遇到困难，大家也能及时发现并提供帮助。但是实体看板最大的缺陷，就是不便于记录和存档。所以，我想在今后的实践中，采用实体看板和电子看板结合的方式：
- 每个Sprint计划会之后，将任务呈现在实体看板上；
- 每个Sprint的User story，尽量把任务切细，这样在看板上可以看到实时的进度。同时，自己的Task不断前进，也是心理上的激励；
- 每个Sprint的周期内，由Scrum Master负责，把实体看板的Task状态，更新到电子看板中，以便存档。
但是由于大公司对于数据保密要求较高，在公司的政策范围内选择一款看板工具，还需要多加斟酌。Tower好处是显而易见的，微信可以直接登陆查询状态，对于本地的研发（最主要是我这个产品经理）很方便，但国内软件的安全性还有待考量；Teambition比Tower更强大一些，同时也在国外证明过自己。但有一点是我一直割舍不下的，虽然Teambition和Tower都支持“一起写”这个功能（谁让国内用Google Doc那么麻烦），但不知为什么，Teambition只支持文档，不支持表格。
- 沟通工具实践。
微信群：个人非常不喜欢在微信群讨论工作。碎片化非常严重，总结起来很困难。同时，由于发言的碎片化，大家的思考也是碎片化的。
邮件：邮件的好处，是在写邮件的同时，也在整理自己的思路，所以写出的邮件往往对问题有更加全面的描述和分析。但是，邮件的效率又很低，写邮件很容易陷入力求完美的状态，花费时间写清了所有问题，但最后其实只需要大神几句话就可以解决是常常发生的情况。大家对邮件，默认也是异步沟通，第二天回邮件是常态，毕竟大家都有很多邮件需要回复。最后，不得不吐槽，Outlook什么时候能做得像Inbox那样好用。
当面沟通：好处显而易见，及时快速有效。但容易打乱工作节奏。
后面计划尝试一下，还是使用邮件系统，但更新一下规则：
- 邮件在小组内部不必完美，甚至可以使用中文（一般大家默认都是英文邮件）；
- 邮件表明重要级别，Important严格是看到后1个小时内回复；
- 超过三封邮件往来的讨论，直接改为当面讨论；
- 问题讨论结束后，由发起人，将讨论过程的总结和结论，更新在共享文档中，存档。
- 重新定义MRD/PRD里的需求级别。原先的需求，分为三个等级：Must-have/Shoud-have/Could-have。一般的项目，大部分都是Must-have级别，也就是一定是要在研发阶段完成的。高级别的需求太多，优先级不够明确，也是研发周期过长的原因之一。因此，根据KANO模型，我重新划分了级别：基础功能Must-have；亮点功能Excite-to-have（对应Should-have），期望功能Nice-to-have和无差别功能（对应Could-have）。同时，大幅度减少Must-have的占比，只将整个项目的基础功能，如协议、架构等，作为Must-have优先级。尽量完成多的Should-have功能，Could-have基本不做。
- 缩短研发周期至6个月。对于大的软件项目，宁愿分为多期完成，每一期完成之后，根据市场的反馈重新定义需求。我们不期望2年憋一个大招，而是期望小步快跑。
- 借鉴Design Sprint，将UI/UX设计，从项目中抽离出来，分配尽可能多的资源。传统企业往往重视技术而不重视用户交互，可以做出很多大而全的软件，而做不出小而美的方案。给予UI/UX相对独立的环境，矫枉过正，加强对UI/UX的重视。
- 每次去拜访客户，尽量可以带一名开发人员前往。这样可以让开发人员真实看到客户的需求，也看到自己的成果。
- 每个月，让开发人员做一次自己的分享，对产品的未来做出规划，大家一起讨论。
20170909
- 关于共享文档的安全问题，可以通过内网搭建WIKI解决。
20171015
- 使用了Tower在一个小的Sprint上，发现Tower有两个缺陷，并不适合作为敏捷开发的工具：
a. 结构呈现不够清晰。虽然在Tower里面，可以利用#给任务分类，比如#UI可以把所有的UI任务合在一起查询。但作为看板，不能添加泳道，不能一眼就看出任务的分类。不得不说，这点直接让我想要放弃Tower。
b. 点击任务开始后，不能记录任务开始的时间，以及任务开发持续的时间。但是这个Feature，我调研了Teambition，Trello和Leangoo，都没有。难道是大家没有这个需求？ - Leangoo在建立任务卡片的时候，我觉得有个Feature可以让看板呈现得更加鲜明——标签。Leangoo可以给每个任务卡片添加一个彩色标签。每个彩色标签，我定义为一个泳道。但是遗憾的是，每次加任务，都必须手动分配标签，有点麻烦。不知道大家是如何应用标签功能的？
