掘友等级
获得徽章 0
今天又是精神满满的一天,
摸鱼到十一
【书名】:如何阅读一本书
【读书笔记】:对于经常阅读的朋友来说,通过这本书,可以让我们掌握阅读技巧,用不同的方式读不同的书,快速掌握知识,或者慢慢享受阅读的乐趣。
跨团队合作,需求又重叠,既可以你们做,也可以我们做,针对这种情况,我们应该怎么处理,下面是我觉得可以使用的一些原则和处理方式。
1. 一致性。 所有的team都是一个团队,不分彼此。采取分工策略是为了更有效率,更高质量的完成需求,早日上线,而不是相互推诿。这个是第一原则。
2. 效率优先。在一致性的原则下,分工策略采取的应该是效率优先,哪个团队做的快,做的完整就由哪个团队负责。 一个需求,最好是由同一条业务线的产品、开发、测试来负责,尽量避免交叉情况。如果A团队的产品提了一个需求给B团队。因为B团队有自己的一些排期,所以这个优先级可能会被降低。
3. 核心优先。A团队因业务需求需要改B团队的代码,这个代码改动会涉及全局和核心功能。对于这种情况,最好是有B团队原班人马来处理。如果时间上来不及,A团队的代码要由B团队review然后合入。
4. 事前通知。如果要改别的团队代码,应该事前通知,这样可以避免一些后期带来的麻烦。
跨团队合作,需求又重叠,既可以你们做,也可以我们做,针对这种情况,我们应该怎么处理,下面是个人的一点思考。
一致性。 所有的team都是一个团队,不分彼此。采取分工策略是为了更有效率,更高质量的完成需求,早日上线,而不是相互推诿。这个是第一原则。
效率优先。在一致性的原则下,分工策略采取的应该是效率优先,哪个团队做的快,做的完整就由哪个团队负责。 一个需求,最好是由同一条业务线的产品、开发、测试来负责,尽量避免交叉情况。如果A团队的产品提了一个需求给B团队。因为B团队有自己的一些排期,所以这个优先级可能会被降低。
核心优先。A团队因业务需求需要改B团队的代码,这个代码改动会涉及全局和核心功能。对于这种情况,最好是有B团队原班人马来处理。如果时间上来不及,A团队的代码要由B团队review然后合入。
事前通知。如果要改别的团队代码,应该事前通知,这样可以避免一些后期带来的麻烦。