任务1. 关于我的知易行难
任务主题：用知行视角去总结一个你现在或曾经的项目
说明：回顾是敏捷重要的工具之一，从过去获取经验，行动现在，指引未来。
从知识、技能、心态等多个维度去总结。
上图是周老师在敏捷个人成长体系的logo。代表一个人的统一状态是手、心、头的联接。
头文化代表要思考有思想，手文化代表要行动有结果，心文化则是思想和行动的结合体，成为一个懂生活有目标的人。
回顾自己现在正在带的一个项目，采用的是敏捷的方式。可是带着带着就跑偏了，一直在找个合适的机会带回来，可各种原因 一直拖着，也希望借助这次机会，回顾一下失败的原因。
先说说团队，大PO是部门总，部门有个产品经理PM，开发测试是一帮资深的架构师级别，但是做事典型的开发人员思维，缺乏业务方面的概念，再加一个测试人员。
项目是属于比较偏技术类的，PM技术方面比较薄弱，比较偏重业务。所以，在需求产出过程中，遭遇一群资深技术人员的围攻，天天改需求，话语权比较弱，被改的没脾气了。
我是SM。
刚开始接手时，大家都是按部就班，有一个技术负责人安排所有的活儿，有个大概的计划，等觉得差不多该产出了，就催一下开发同学交成果啦。但是我发现，大家基本没有按照之前排定的计划来做，总是会延期延期，或者临时改需求，这个需求不做了，等有空再说。整个团队开发比较散乱自由。
第一阶段：
我进入项目后，可能因为自己性格的原因，不太强势，所以也没有很生硬的要求团队立刻按照scrum的方式来工作，而是跟团队leader商量，我们先用白板管理一下任务，每天跟踪一下，这样也方便大家明确各自的任务及进度。leader同意了，然后我就先将大家所做的任务拆成了多个页面和多个接口（按照他们原先的工作方式）。然后让每个人都认领了任务，并预估了交付时间。然后每天固定时间跟大家开会对进度。
这时，大家就有声音了，“这个进度会我们需要每天都开么？这个时间我们用来编码不是更好么？”
面对这种问题，我还没有找到一个比较完美的回答，只能从透明任务和控制风险角度来解释，然而并没有什么卵用，大家也是将信将疑的态度。所以会议开得也比较没有成就感，有得同学比较负责任的，会每天做检视，预估的工作完不成也有个合理的解释，有的老油条同学会答非所问，问他什么时候能完成，他说这个很简单，明天就可以完成，到时候又找一堆理由搪塞，进度一直停滞不前。以至于到最后，测试同学叫苦不迭，明天就要demo演示了，还没提交代码，让我怎么测试，不能这么压缩测试时间啊b labla.开发同学又找各种理由，我只是承诺了我开发完，没有算联调的时间啊，把责任推给其他开发产，推给产品、运维。。我在跟踪的过程中，由于技术比较薄弱，之前按照大家原来的方式拆了页面和接口，但是页面和接口没有对应起来，无法形成完整的进度概念，不知道一个功能是否彻底做完了。（自身反思：采用故事的形式，这样跟踪会比较明朗）
后来，找了个机会做了一次回顾会议。大家把一些优缺点都说出来，我们挑出来三条比较好改的，在下阶段改进。然而，执行的也不好，似乎开完会就完了，大家也都抛到脑后了。
自身反思：回顾会的形式适当的有趣些，不要变成吐槽大会，同时要有些吸引力，比如做一些敏捷游戏激发大家合作激情，或者有一些小的奖惩。
第二阶段：
与产品紧密合作。
我协助产品经理梳理需求，并用工具管理，我们采用icescrum工具。将需求拆分成一个个故事，当然，这个工作自打我帮助他梳理开始后，就变成了我的工作😓.......，产品经理说，我做，成了小杂工。
同时，培训开发测试同学使用这个工具，让大家在每个故事下建立自己的任务，当然，好多情况下，是我建好任务，大家点击领取。。。。。
最后，其实，这个工具大部分是我自己在玩。。。。
当然，也有比较配合的同学。我会组织大家每天固定时间站立会，因为有上海同事，所以一般是电话会议。会议后，我要求大家更新工具板的任务，挪动任务并更新剩余时间。
反思：怎么让大家自愿的去使用工具，而不是我一个人玩转。
这个阶段，大家配合的还算可以，基本能按照进度交付，两周一个迭代。
第三阶段
按照以上的节奏，大概做了四五个迭代，因为需求不确定，一些小的需求技术负责人觉得需要改就直接找开发同学改了，后来，也没有大的需求过来，所以大家也都比较散慢了。
工具也不使用了，觉得哪里不太好，技术leader决定要改就直接改了，也不经过产品，好的时候跟产品经理说一声就完了。
再后来，因为服务端人员多，前端资源瓶颈，好多个后端人员对一个前端工程师，同时后端同学也兼顾好几个项目，不是都能全身心这个项目里，所以在规定在迭代内的任务卡在那里无法交付，所以迭代周期就跟着变，做完几个故事交付一次，有的故事大，有的故事小，所以交付周期也不固定了。
后来就这样，乱套了。。。
唯一保留的就是每日的例会，大家照常开，介绍自己的工作任务，障碍，如何解决。
但是大家都是分散的介绍自己的任务，我只能从大局观，把握即将要交付的内容，确定跟交付内容相关的同学的任务是否进展正常，但是由于个人缺乏技术经验，不能很全面的知道哪个环节可能会出问题。
总结：
知识方面：敏捷的基本实践算是都走过一圈，但是知识不牢固，导致实践时问题很多。 加强：如何能在自己权限范围内保证迭代周期不经常变动（各种原因：领导急着看成果，资源分配不均，产品没有产出等等），1.说服领导尽可能的保证项目团队人员全身心投入一个项目 2.虽然敏捷但是还要制定一些适当的流程来规范，比如提测流程、上线规范等，不能太随意了。完成标准做的不好。
技能方面：技术薄弱，对技术方面把控较弱，技术风险不能有效识别。 加强：技术方面的学习 引入自动化测试、持续集成、重构等技术实践。
心态方面：刚开始接手时还是比较负责任，大家不能按时交付会比较着急，会不断催着大家按照进度去交付任务；后来。。。。各种原因各种变动，似乎延期交付并没有对大家造成什么影响，领导也没有怪罪，可能领导也不是特别care这块业务，所以大家做多少交付多少，心态也变得老油条了。。会预留一些buffer出来供上线准备以及演示前的线上测试，通常这部分buffer都被占用的将将够。如果不能保证质量的就放到下一个版本再演示。这样子太不好了，但是整个团队风气已经变成这样了，比较难拽回来了。 如何激发团队士气是下一步考虑的问题。
以上，不是一个好的成功的项目管理分享，比较失败，自己回顾一下，总结经验教训，不断改进吧。
