在软件行业摸爬滚很多年，从开发软件采用分布式编译技术也需要一天一夜才能编译完成一套系统，大家都在使用16寸CRT编写代码的时代，到现在一台Mac的性能远超当时的集群性能。当年一本《硝烟中的Scrum和XP》读的津津乐道，学到的新东西立马在团队试用，到后来作为敏捷教练帮助企业组织转型。近几年企业开始“降本增效”风潮，普遍看到的只是“降本”，采用精益敏捷的方式减少浪费提升效率的实在太少。有时候看到明明只需1/2甚至1/3的人，改变做事方式，就能比现在更好，但企业还是倾向于低效堆人，十分感叹。
言归正传，很早作为软件工程师的时候，喜欢在工作外写一些小工具帮助团队自动化一些事情，这个习惯在做教练的时候也继续保持着，估计还是内心喜欢写代码这件很纯粹有趣的事情。以前也想过开发一些面向用户的软件，投向市场，看看能不能掀起一点浪花。也跟曾经的团队聊过，无奈大家都要吃饭，养家，靠爱发电似乎难以实现。大家都知道现在这类软件基本很难有市场，所以这件事情一直搁置着，但内心仍有不甘。
在从事敏捷教练期间听到最多的争论是“敏捷教练不要只当裁判，也要下场踢球”，“既要管杀，也要管埋”。于是教练不仅要传递知识，方法论，也要下场带着团队一起干。虽然这样，但进行软件交付的核心工作还是团队。除了通过帮助团队，自己也想深度体验敏捷，迭代，持续交付能做到什么程度，所以内心有个想法，自己分别扮演PO，Team，Scrum Master，从一个想法开始，到实现一个软件并推向市场。在这个过程中会对产品经理，开发，测试，运维，运营等角色在敏捷活动中怎样高效的协作有更深入的理解。记录这个过程中发生的事情，分享给大家，希望能有一些帮助。
可以预见执行过程中的难点，一个是能不能完全实现这些想法，中间肯定会遇到各种困难需要去解决，第二个是主要是时间投入的保证，最近公司开始重视提效，希望能有所帮助，估计会有些忙，家里还有小朋友需要陪伴，考验怎样合理安排时间。好了暂时想到这些。
初步想法如下：
- 迭代周期为一周，在迭代内既要完成当前迭代的开发，也要完成下迭代用户故事的准备
- 采用用户故事地图进行版本规划
- 采用看板进行每日任务跟踪
- 每周进行回顾
- 借用TDD思维进行开发，但不完全遵循TDD的步骤
那么下周开始<迭代0-迭代准备阶段>：
准备完成商业模式画布，用户建模，用户故事地图，迭代1用户故事准备,准备决策看板，任务看板
Week 1: Sprint 0 - 迭代准备