自觉良好
就在之前几篇的时候，我们已经默默开始给小团队灌输敏捷知识。
这个团队很小，产品：快一年经验；开发：毕业一年，初级程序员；还有一个有些经验的我。
我们负责的项目有开发任务，同时也有不少运维工作。经常会有新需求插入和变更。
我们效仿一些敏捷形式和方法。有些做得挺好，有些做得不能够长期坚持。
我们产品列表比较混乱，没有做整理细化，有一个摞一个。从外面看整个产品是混乱的，看不清未来方向的。
我们虽然每周都有计划，从上面可以看出，我们没有远期目标。因为我的懒惰，没有从项目上梳理长期的规划。
自认为需求频繁变动，所以没必要清晰的长期规划。也不是说没有想过，讨论过，也达成一致过。但是没有落实到产品列表中。
你从产品列表中不会看到未来系统的模样。
应届生的产品做么？他一直也是这么做的，只是有时我们稍微缺少了引导就会止步不前，不是积极性问题，是他有时真的无法下手。
就好比，你刚毕业就让你负责系统架构一样，我想刚毕业的我有心想做，但是心里还是会战战兢兢。
冥冥之中的隐患
其实说到底还是项目管理的问题。我现在隐隐体会到，敏捷是指导原则，实际贯穿主线的还是项目管理。
所以两者的结合孕育出了很多的优秀的敏捷实践。
我们省去了产品列表的规划，只有零星的周计划。我们甚至没有了项目回顾会议。
我们起初所认为的快 —— 实际上是省去了各种产品列表的优先级排列：史诗级、主题级、冲刺级，由粗到细的用户故事的拆分。
我们虽然将周期调整为一周一个计划，来应对频繁的运维需求的变更。但是我们也缺少了项目相关的评审会议、回顾会议。
我们只管往前跑，冥冥之中感觉自己在做无用功，甚至说我们所做的任务价值意义不大。
导致这种错觉的，一个是很大程度上是没有长远规划，另一个是各种评审和关键点没有设卡，还有一个是没有了回顾和反省。
所以要遵循项目管理的主要规律和重要的实践，虽然这些操作时间上付出是有一定的成本，这些付出是值得的。
需要长远规划
就好比大家没有了共同的目标，这个不利于团队的士气，不利于项目的发展。
需要付出时间和精力来做这些事情，这个好比是架构，一部成长史。参与其中的成长是非常有成就的。
产品列表：史诗级用户故事；主题级用户故事；冲刺级用户故事。冲刺级别是具体可执行的任务。
比如史诗级别：作为一个运维人员，我希望有一个后台可以方便我的日常运维工作，来提高处理问题的速度更快地相应客户。
比如主题级别：作为一个用户，我想我发起的任务可以并行调度而不是长时间等待顺序排队，这样才能很快并陆续收到反馈。
比如冲刺级别：作为一个运维人员，我在系统中能够拥有在线对账的权限，这样利于月中对账，而不是每次都需要写邮件给DBA申请导出.
设卡&评审
关于评审，比如 核心模块的设计评审（思路和技术点）
需求评审
接口协议的设计评审（命名，出入参）
代码走查评审
测试用例评审
从各种评审中我收获到的几个基本的好处是：
1、对于被评审人员，专业技能上是一个肉眼可见的提升。
2、三个臭皮匠顶一个诸葛亮，大家不同的智慧的碰撞会发现很多新的坑。
3、是一种态度的输出
其中几个经验是：
1、功夫都在平时准备：比如设计文档、接口规范设计文档、测试用例的用例（这个我们做的还行，也是需要导师多督促，成员能够主动沟通）
2、会前，发布一个会议大纲。（这个做得也行，这个都会说一下）
比如会议的主要讨论主题是什么？会议的时间是多久？
自己会大约使用多长时间？留给其他人员的讨论时间是多少？
开会只是一个对当前结果的一个讨论。
3、会议设定一个主持人
（这个很重要也很有效果，之前没有主持人会议经常超时。关键是超时还觉得自豪，自豪会议又讨论出很多东西，自豪发言很踊跃。）
其实还是为了一个开会的效果，可以找一个资历高一点的把控会议。避免过度讨论。
也就是大家的时间成本和开会的效果尽量地高效。
4、结束后整理会议纪要（这个执行得算是及格，但是不够坚持）
其实会议纪要是次要的，主要是对会议讨论的结果负责，最好有产出物或者结论。
项目回顾
项目上的回顾，总结过去，计划未来。
好的不好的都需要说。个人来说也是这样，好的不好的都需要总结。个人提高了也是项目整体提高的一部分。
再就是计划一下接下来的工作，明确下一个版本的目标。
加入测试
因为主要提供接口。一开始我们的都是自己测试，久而久之就没有让测试加入。
开始觉得这样挺好，流程更短。
现在想我们的3个总结是：
1、我们其实做得工作并不少，反而多了，因为兼顾了测试的一部分工作
2、任务多了，有可能影响了工期和质量
3、我们相信我们，但是我们还是不够专业。就算是接口简单不需要测试人员介入。
但是需要测试思维，测试的测试角度思维经常会给我们当头一棒，很受用。
坚持执行，不断调整
希望我能够坚持执行，不断反思调整。
根据成员能力和专业程度采用相关的敏捷实践，不是所有市面上好的都有效。
自己近期看了很多敏捷相关的书籍，最近又看完的这一本，收获还是很大的，纠正了很多原来的认知。
比如：所有的用户故事必须符合6原则（其实是允许出现史诗级的用户故事的）
标签：会议,运维,一个,评审,敏捷,好像,真的,我们 来源： https://www.cnblogs.com/hzyimen/p/12343784.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。