敏捷开发培训课程所想

以下仅为个人看课后的个人想法，有局限性，仅供参考。

Q:敏捷开发为何诞生？即敏捷开发解决了什么样的问题，适合什么样的项目场景？

1. 项目有一些需求不够明确，存在较高的不定性，容易变化：需求优先级变化，新增需求，删除需求，修改需求等情况。
   a. 所以敏捷提倡小步快跑是为了应对需求不确定性而来，小步摸索尝试，获得产品和客户的反馈，来确认本次尝试是否成功需要修改。
2. 项目可以部分需求独立上线，并能产生一定价值。

Q:实现敏捷要求哪些条件？

1. 更多的测试：自动化测试。
   a. 因为敏捷的小步快走，会引发一个问题，会有很多小的步骤的代码版本提交。导致版本频繁的更新，会需要反复的测试来确保每一个小代码版本整体代码的
2. 对于团队成员要求更高：
   a. 专业水平更全面+某领域专精：为了应对需求变动时可以快速全面的决策评估。
   b. 自主性要求更高，积极主动面对需求变化时，如何推进团队去快速响应和项目继续稳步执行。
   c. 高效的沟通，快速决策应对：面对每次需求变化后，如何快速达成产品，开发，客户等多方人员的高效快速的达成应对本次变化的公示，而且没有沟通盲区。（本课程推荐面对面沟通+个人感觉沟通后的结论还是要有留档，以备以后查阅）

Q: 本次课程使我对于敏捷开发有哪些其他的收获、感想、疑问。

1. 敏捷是针对项目和其项目团队为单位来考虑的。
2. 本课程也提及了要考虑需求(故事卡片）优先级来排序开发顺序：但是优先级从哪些角度去评估没有提及。个人只是想到：需求可变性高低；用户认为的价值；开发成本；开发时间；是否依赖其他需求的实现为前提。
3. 需求开发的时间评估，课程里指提到了类比法，就是用之前开发过的相似需求的经历来评估时间。但是对于新的未开发过的需求时间评估闭口不谈！个人暂时还是觉得对于新的未知需求，还是先提前预调研之后，才适合给出一个粗略的排期。
4. 课程提到好几次关注需求的价值，那价值是如何判定？因为有些需求的价值只是我们项目组人员（客户，产品，开发）认为的实际上可能上线是利用率也不高。
5. 时间计划推荐由开发人员制定。
6. 项目复盘是所有项目成员（客户，产品，开发，项目负责人等）参与，共同反馈，并把反馈建议落实。
7. 敏捷开发本质是应对需求快速变化。为了降低需求变化对于项目各方面（新增沟通点；排期变化）等而采取的相对高效的无奈之举，小步尝试。但是对于理想的项目来说，尽量稳定的需求是项目稳定的根本。再优秀的敏捷团队面对复杂多变的需求，也只是能应对的更熟练，但是对于项目进展来说，多变的需求总会是负面影响。而如何快速（尽量少的迭代）找到高价值且稳定的需求，应该是比敏捷开发更先进更值得项目团队去努力追求的方向。
8. 敏捷开发只是无法把握真正有价值稳定需求情况的应急手段，不是项目开发追求的上上策，只是不得已的下策。敏捷开发再熟练的队伍，面对朝令夕改的需求变动，效率也不会高到哪里。 只要有需求变化就会增加项目成本！ 敏捷开发只是尽量控制需求变化时引起的成本激增。 我们应该一方面掌握敏捷开发的本质，来应对各种变化。但是另一方面更应该提高和努力的是，着力于去研究如何挖掘项目中更高价值、更稳定的需求作为更核心目标。只要减少需求变化次数和大小，就减少了变化后的沟通成本、计划调整等其他相关工作。

Q:对于我们部门当前情况有什么措施建议

迭代周期划分

迭代根据项目走，而不是以部门固定3周一迭代

我们的项目情况

我们的大部分项目，需求相对来说比较稳定了，开发前经过讨论需求变动不会很大了，已经减少不错的额外沟通和修改排期的成本，值得我们继续保持。但是还是需要预留一些时间应对一些零散的需求变动和临时任务。

项目排期拆分

如果自动化测试开发速度无法跟上项目开发进度，而且一个项目的整体功能流程上，有些会存在前后相互影响，不建议中短期项目进行1,2期拆分，因为2期还要回归测试1期的内容，人工测试会浪费测试时间。尽量把测试安排到项目开发完再开始，使得测试可以完整的从头到尾测试，而不用纠结于遇到的一些问题还要考虑是如果是2期的问题，现在发现也不用管。这样测试人员也可以把之前用于测试1期的时间，可以用来为最终的测试做准备，比如准备压力测试的模拟数据，编写部分核心的功能的自动化测试。
那对于整体开发期的代码质量，需要代码审核工作来辅助确保代码不会有太大的问题。另外对于开发人员开发期间的自测也提出了更高的要求。
当然开发也可以考虑增加单元测试的编写，来提高自己的代码质量以回归测试时提供一些代码质量检验上的帮助。

理想的项目团队状态

一手掌握敏捷应对随时的需求变化；另一手深挖需求，找到高价值低变数的的需求，减少不得不敏捷去应对需求变化的窘境，才是比敏捷开发更敏捷之路。