敏捷项目管理、敏捷开发:早期集成
我相信，如果一切都是敏捷的，那么敏捷是可行的。
在软件开发领域，我认为如果早期集成团队成员的代码，代码将更加同步，这有很多优点：
- 早期集成有助于团队成员避免痛苦的合并。
- 鼓励更好的编码习惯，因为每个人都确保他们不会每天违反同事的代码。
- 开发人员和架构师(代码审查员)可能会实时检测到错误的设计决策或错误的开发方向，从而防止无用的工作。
实际上，我说的是获取最新版本的代码库，并每天将您自己的代码签入源代码控件。
当您开始您的编码一天(即您到达您的工作)，您的第一个行动是更新您的代码库的最新版本，从源代码管理。另一方面，当您离开工作回家大约一个小时时，您的最后一个操作是签入源代码控制代码，并确保您的日常工作不会破坏项目的构建过程。
与其在完成整个任务后更新和签入代码，我相信最好的方法是在完成这些任务后修复小而灵活的个人里程碑和签入代码。
我真的相信这种编码方法更适合敏捷项目管理的概念。
你知道一些文件，博客帖子，维基，文章，或任何你可以建议我，可能与我的意见同步？那么，你觉得这种方法有什么问题吗？
提前谢谢你。
回答 2
Software Engineering用户
发布于 2012-11-23 20:39:14
那么，你认为使用这种方法有什么问题吗？
我将集中讨论这一点。
我确实对这种方法有问题，主要是因为它与人们应该做的事情有些正交。当然，我们应该促进更频繁的‘获取最新的’和提交，但使那些与工作日是不一致的，与我们真正想要解决的问题，以及开发将如何工作。
程序员应该在开始任务之前，在提交任务代码之前获得最新信息。这是开发人员进行合并的两个自然点。如果开发人员没有这样做，那么纠正这一点是非常直接的。“嘿，你应该得到最新的，以防止破坏构建和合并痛苦。”开发人员喜欢减少开发的痛苦。
如果这在某种程度上导致集成的频率低于每天，那么您就会遇到比不频繁的集成更糟糕的问题。你有很大的任务。这将本质上更容易出错，并导致更多的合并问题的整体；不管您的集成频率。您应该考虑将常见的任务大小减少到更易于管理的块中。这将大大减少您的集成痛苦(以及其他开发问题，如估算错误、协调问题、时间/问题跟踪准确性等)，而不是要求人们合并，即使他们不是一个好地方。
Software Engineering用户
发布于 2012-11-23 22:19:21
好吧，我认为你的专业名单上的“优势”比较弱。
早期集成有助于团队成员避免痛苦的合并。
痛苦的合并是两种类型:或者它们还不存在，或者已经存在过。冲突(这一行动的事实)造成混乱，而不是它面前的行动的数量。
鼓励更好的编码习惯，因为每个人都确保他们不会每天破坏同事的代码。
如果将同事的代码合并到我的工作代码库中会破坏构建，这不是我的错，对不起！在与合并相反的方向上也是如此。
开发人员和架构师(代码审查员)可能会实时检测到错误的设计决策或错误的开发方向，从而防止无用的工作。
如果我在我的团队中看到这种工作风格(仅控制合并代码)，则PM和TL将立即以黑色标记被取消。
我指的是获取最新版本的代码库，并每天将您自己的代码签入源代码管理程序。
“这取决于”(c)：
- 如果没有人接触“我的”文件，我(可以)不用担心无关的代码更改。
- 如果我关闭了许多与其他任务相关的小任务，我会更喜欢尽快合并更改
https://softwareengineering.stackexchange.com/questions/176973
复制相似问题
腾讯云开发者
