最近参加了敏捷软件开发的培训，其中的感慨还是很多。
第一个就是老师讲课的方式。听课的时候，长时间保持坐姿，注意力还是比较集中的。体现了老师讲课的功力。中间穿插了一些公司案例。
讲课的时候讲到了敏捷的一些案例，讲到了商业画布，敏捷的丽念和一些实践等。需求的分析和拆分等。
如何估算准确？ 用户故事包含UI设计、研发、测试的整个流程，对于员工来讲，不熟悉其他岗位的工作流程没能相对准确的评估时间。这两个都是后台的开发UI设计都不太复杂，而且也不需要表设计业务也不复杂，只需要考虑研发和测试。即使如此 差别还是很大的。业务复杂度还是有差别的。
关于迭代会议(需求评审会议)的问题。由于第一次开所以不知道怎么问，从哪些方面问，思想还停留在 以前的工作方式上。以前是 直接分配任务，做的时候不清楚的需求再问的，而敏捷软件开发要求先弄清楚需求，估算所用的时间，形成一个迭代周期，在此期间尽量不兼做其他的项目任务。实际上很难做到，因为目前项目发布后没有移交给专门的项目维护人员，而且有些bug需要修改。更多的时候对需求的理解存在一定的问题，通常是在做的时候才发现需求没有理解清楚。先想清楚需求然后再做难度有点大。用户故事没有排优先级，拆分得不合理，依赖于其他的用户故事，用户故事做完还是不能测试。
敏捷软件开发对开发人员的要求很大。首先是要了解其他岗位的工作情况。了解情况才能评估其他岗位的工作量。但是现实中基本不了解其他岗位的工作情况。而且UI设计人员和研发人员以及测试人员的比例相差太多又不是分开评估的，很难估算准确。接手用户故事后开始的时间内 要重构代码，重构本身就是一项艰巨的任务。包含代码的可读性、简洁性、有没有重复造轮子、逻辑的严密性和准确性、UI界面、页面交互、是否可以给其他模块复用，需求实现是否正确合理。
回顾会议，需要总结任务实际完成的时间和之前评估的时间的差异。就像我之前做的微信矩阵的长篇故事，我故事的两个用户故事都是1个点，但实际上我花的时间分别是0.5天和1.5天，差别还是很大的。有哪些是可以避免的，下次会不会还有这些坑等等。