在去年的一篇文章《在团队中使用GitLab中的Merge Request工作模式》中简单介绍了下Git的几种模式和在团队中使用的Merge Request的模式。文章的结尾也抛出了几个问题：
- 如果系统上线后有紧急
bug需要处理，这个流程应该怎样去调整？ - 每个任务都在单独分支并行开发，这时如果A和B都依赖C开发的一个模块，应该怎么解决？
- 理论上
Issue管理员和开发人员都可以进行创建，什么样的Issue可以有开发人员来创建？
现在团队的管理方式有了些调整，也可以顺便解答下上面的几个问题。Git也好，Tapd也罢，都是些辅助工具，目的永远都是：怎样持续交付高质量的产品。100个团队可能有100种不同的落地的方法，我们也在不停的探索，改进，因为只有适合自己的才是最好的。
在上篇《敏捷，每个人都有自己的理解》中提及到了团队现在在使用腾讯的Tapd，虽然是阉割版，但也够用。下面说说落地后的需求管理方法和分支使用的调整。
整体计划
将全年的整体开发计划大致分为三个大的阶段，第一阶段可以拆解的比较细，从需求到具体的任务项，指派到具体的人。第二三阶段可以只列出相关的需求点，因为不确定性因素很多，有的需求到临近会有调整，有的需求需要进行更近一步的讨论。
我的计划是使用OmniPlan工具来完成，目前发现的Mac中最好用的项目计划管理工具了，使用OmniPlan来做整体计划是因为需要向领导汇报。在OmniPlan中，有以下几点需要注意：
1、需求分为两级，第一级为需求点，第二级就是具体的任务项，可以指派到具体开发人员，这么做是便于后面将计划拆解成小的迭代记录在Tapd中；
2、计划中的需求点尽量不要跨周，如果有一些大的需求预估周期较长，就需要将大的需求点进行拆解，这是因为要在每一个迭代中可以交付完整的功能。
从计划到迭代
迭代目前是以周为单位，每个迭代必须能够交付完整的功能。整体的计划就像是一个大的需求池，每周从池子里拿出对应的需求记录到Tapd的迭代需求中，在Tapd的需求中会写明业务背景、实现方式（包括一些原型图）、验证点等。
每个迭代中的需求也不完全是按照之前的计划，计划是在事前设置的目标，是随时拥抱变化的，所以每周的迭代中，可能会有新增需求，也有可能会将某些需求移动到下一个迭代，还有些需求可能随着市场的变化会演化成一些其他的需求点，这些都属正常现象。
分支管理
现在的任务管理模式和之前Merge Request最大的区别是，现在是以需求为导向，而之前是以任务为导向。
一个迭代由若干个需求组成，每个需求都设置有需求负责人，需求负责人负责在Gitlab中创建Issue和Merge Request，每个需求对应一个Issue和Merge Request。很多时候一个需求会由多个开发人员共同完成，多个人员在同一个分支下协同工作。
管理员负责在Tapd中进行需求、迭代的管理，需求负责人负责Gitlab上的操作，并通知该需求的参与人员应该使用哪个分支进行开发，最终由管理员进行代码的合并。
新的方式会遵循以下的一些规则：
1、master为稳定的发布分支；
2、在开始一个新的迭代前，以master分支为基础创建一个迭代分支，此迭代中的Merge Reqeust以迭代分支来创建；
3、在一个迭代周期内完成的需求，合并到迭代分支进行提测；
4、迭代结束，将迭代分支合并到master分支进行发布；
5、有紧急bug需要处理，以mater分支创建bug分支，修改测试通过后合并到master分支进行发布，并且将master分支反向合并到迭代分支。
总结
对于敏捷，每个团队有自己的理解和实践，可以个性化，但一定要在敏捷原则的指引下前行，下面是敏捷开发宣言提出的十二条原则：
1、通过早期和持续交付有价值的软件，实现客户满意度。 2、欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。 3、不断交付可用的软件，周期通常是几周，越短越好。 4、项目过程中，业务人员与开发人员必须在一起工作。 5、项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。 6、面对面交谈是最好的沟通方式。 7、可用性是衡量进度的主要指标。 8、提倡可持续的开发，保持稳定的进展速度。 9、不断关注技术是否优秀，设计是否良好。 10、简单性至关重要，尽最大可能减少不必要的工作。 11、最好的架构、要求和设计，来自团队内部自发的认识。 12、团队要定期反思如何更有效，并相应地进行调整。
对于Git，为了保持简单，目前仅用了最基本的功能，只是在分支的管理上做优化和调整。像cherry-pick、stash等相对高级的功能也在学习和探索中，没准哪天能派上用场了。
