在moode实习，另一个深切的感受是他们的工作流程。老板是敏捷开发践行者，带我的ThoughtWorker传授了完整的敏捷开发理念，1999年，ThoughtWorks全面转向了敏捷开发，这个时间比敏捷宣言的提出还要早两年。敏捷和传统开发模式到底区别在哪呢？
首先感受到的，是每日站会（以下简称“站会”）。站会的时间在每天刚上班的时候，每个人要讲自己昨天做了什么，遇到了什么问题，今天的任务是什么。起初的时候，我也没感觉这有什么，以为又是一种形式主义，后来才渐渐发现了站会的意义。这是一种透明度极高的工作方式，大家共享任务进度，共同解决遇到的问题。而且当你某天偷懒了的时候，你自己就会特别的清楚。一种共同监督和自我督促。所以每天早晨挤在北京有名的地铁一号线里的时候，脑子里想的是我站会要讲些什么，拎着早饭走在华彬前的胡同里，想的是我今天要做些什么。站会这种形式，确实是一种很好的督促~
对于迭代，印象很深刻，从第一次去找老板进行痛点分析，到临走前去做的那次show case，老板每次都在不停的跟我讲迭代，他要的是MVP(Minimum Viable Product)，一次迭代要做的是最简可行化产品。
在公司里，我们的开发流程是这样的。首先，要去和客户（用户）沟通，进行痛点分析，确认需求；然后，画界面原型的UI，做好Story卡，去和客户再次确认；确认完成后，修正Story卡，和开发人员针对Story卡的内容和细节开一个IPM会议。在IPM会议上，产品经理和开发人员共同看卡，针对每张卡的内容，开发人员都要进行反讲，来确认是否达成了共识。确认完成后，开发人员需要对卡进行估点，点数越大，开发难度越大，开发时间越长，当点数太大的时候，产品经理就要考虑是不是要将这张卡太大了，需要拆开。IPM会议后，开发过程就正式启动了。开发人员每次从PM这里领一张卡，读卡完成后，要进行反讲，然后把他认为的功能点列出来，备注在这张Story卡上。
一旦开发开始进行了，卡的内容就不能再修改了。我们之前就碰到过这种糗事，程序员已经开始开发了，突然，程序员跑过来跟我说，你这需求有问题，这个时候，很是考验PM了。这种时候，一般有两种情况。一种是确实需求出现了问题。这时候，PM要和开发人员对问题进行讨论，大家统一出一个解决方案，然后会新建一张卡，把方案内容写进去。然后在原来的那张Story卡上，添加上连接到这张卡的链接。
还有一种情况，就是程序员的有意蓄谋了。当需求不好实现的时候，他们就会跑过来挑你需求的问题，希望成功把你绕进他们的思路里去，然后把需求改掉。这个时候就需要PM坚定的好品质了。PM的需求都是和客户确认好的，要是中途改了需求，客户怎么会买账，PM可是个顶雷的，开发做出来的东西跑偏了，责任大半是PM的。所以，千万要小心那群心眼无数的程序员们。
一次迭代产品完成后，产品和开发人员要共同去找客户，进行show case。
Show case对我来说，也是一段血泪史。第一次去的时候，其实根本不知道要说什么，然后就一个按钮一个按钮的跟老板解释。哎~老板的心思太难捉摸了，天知道他想要看的是哪些功能。我演示了半天，老板说，这些不是我想看的，我要的功能呢？这次演示我要给你一个叉子。然后我就又被乖乖的教育了一个小时，还好有好脾气的守波哥哥，跟我说我做的第一次show case已经不错了~还和我说老吴不该中途总是打断我的。每次从老板办公室出来都是一身汗。
然后守波哥就和我去了小屋，研究如何做一个好的showcase，老板君想要的show case到底是什么样的。一个好的showcase需要把我们的产品用一个故事串联起来，演示给客户。为了保证真实性和参与性，现场的每个人可以就是故事里的人物。然后在演示过程中，观察你的客户，看在你讲哪些功能的时候他会特别关心，哪些不在意。这种东西，还真是得慢慢悟啊。直到最后，老板君跟我说，这一次我还是要给你一个不及格。哎~幸好已经不是给我一个叉子了。阿Q一下好了~
Show case后，客户会提出他们对于二次迭代的要求，然后就是重复以上的过程了。
敏捷开发带给我的主要感受是快速迭代，这样我们才知道我们的产品是不是市场上所需要的，而且也会大大减小开发的成本和代价。相对于传统开发模式，优势还是很大的。
