【问题标题】：Software development process for small teams [closed]小团队的软件开发过程[关闭]
【发布时间】：2008-10-03 10:17:17
【问题描述】：

我在这里可能是个例外，但我从未在一个拥有超过三个开发人员和/或五个人的团队中工作过。我们仍然可以设法完成工作（以某种方式）。

是否有适合这种“极端”场景的软件开发流程？而且，如果您作为独立的程序员工作，您是否可以适应您的日常生活，使其更可预测、更连贯、更有文档，并且仍然可以完成工作？

【问题讨论】：

标签： architecture project-management

【解决方案1】：

agile methodologies 是一个很好的起点，因为恕我直言，它们更适合小团体。

至于保持您的个人工作节奏，我推荐一种基于 TODO 列表的方法和一些工具，例如 Task2Gather。你也可以看看GTD。

即使是我一个团队，我也永远不会放弃的事情：

源版本控制
备份
待办事项
单元测试/TDD
代码文档
重构/代码审查

【讨论】：

@Manrico：作为一个由 1 人（我）组成的团队，我也进行源代码控制、备份和待办事项，但没有单元测试（除了通过一些常见场景手动尝试我的 Web 应用程序）和代码审查。你对我如何开始添加这些有什么建议吗？一个关于你的过程的博客会很棒！ ;)
@Sprogz：给你（这只是一个草稿）babilsenior.blogspot.com/2008/10/…
@Manrico：非常感谢！我已经阅读了许多关于 TDD 理论的文章，但我真的缺少关于普通开发人员如何使用它来帮助他们的开发过程的动手示例。您的博客文章很有帮助，我很想阅读更多内容！不错的作品。我会为你的博客添加书签。
我真的认为“人员配备”不是一个因素......敏捷是为了最大限度地降低成本，而不是招致。这是一种风格，而不是规则。 5 或 500，敏捷对所有参与的工程师来说总是好的 :)。您可以拥有一个量身定制的敏捷（即并非所有实践都是您的目的所必需的），但仍然为您的最终产品保持良好的编程实践。

【解决方案2】：

让强大的SecretGeeek教你how to be a standalone programmer。享受:)

   intellisense 
        ||
        \/
       code >>> compile >>>>> run >>>> success >>>> profit ;-)
        /\         ||          ||         
        ^^         \/          \/
        ^^      errors       errors 
        ^^          \\       //
        ^^           \\     //
        ^^             google
        ^^              ||
        \\              \/
         \<<<<<<<  copy N paste

【讨论】：

把最后一部分改成“成功>>>>?>>>>利润”，我就被卖了。
我想这就是为什么不是所有开发者都富有的原因......我仍在寻找开发成功和利润之间的桥梁。

【解决方案3】：

TODO driven development

来自SecretGeek 的严肃建议。

设置您的开发环境或编辑器以自动列出所有带有 TODO 标记的行 - Visual Studio 默认执行此操作。

步骤 1

编写类或方法大纲（即，'Public Class ...' 或 'Public Sub...' 内部没有代码。）
包括粗略的逻辑
添加以“TODO:”开头的伪代码
只写非常琐碎的代码——其他的只要添加一个TODO

第二步

重复第 1 步，直到整个应用程序被粗略完成
您现在有一个“待办事项”任务的大列表
检查完整性（宽度）
查看可以删除的内容。
看看有什么可以简化的（例如，两个相似的 todo cmets：它们可以变得相同吗？

第三步

将 TODO 替换为对不存在的类、方法等的调用... （对于测试驱动的开发，请为这些方法/类中的每一个创建详尽的测试）

第四步

通过以下方式一次修复一个编译错误：
- 编写类、方法等的外壳，
- 添加 TODO: 伪代码到其中的每一个。
- （如果时间紧迫，还可以添加 'HACK:' cmets 和适当的解释）
- 在适当的情况下，将 TODO 替换为所需的琐碎代码

第 5 步

重复第 4 步，直到不存在编译错误。
如果还有TODO，则返回步骤3。

（还有很多事先计划、纸质原型设计、客户会议、讨论、拖延、数据库设计、喝咖啡、sprocs 和 crud-sproc 调用的代码生成、可重用 DAL 的导入， PAG 阻止使用，去 PAG！，在文件签署之前来回辩论，争论，深夜，沮丧，与朋友聊天，筛选电子邮件，在 visio 中刮擦，打印出来并把它们放在一堆，寻找订书钉，赶公共汽车，做背部和颈部伸展等，但为了简单起见，这些都被忽略了......）

（又是MarkJ）有点像Code Complete的伪代码编程过程。还有we all agree 每个人都应该阅读 Code Complete，对吧？

【讨论】：

这真的很简单，尽管它看起来很笨重，但它适用于单独开发一个您不再记得缺少什么的大型项目

【解决方案4】：

大多数敏捷方法都适合您的个人资料。

目前最受欢迎的是SCRUM。它专为小型团队的生产力而设计，它的粉丝声称开发时间比传统的瀑布方法要快 5-10 倍。

如果你想开始阅读，我推荐 Headfirst Software Development 书

【讨论】：

Scrum 是我目前正在与我的团队一起做的事情。我承认它的一些原则有点戏剧化，但我们正在变得更好。既然你提到它...我们忘记了我们的日常会议！ :O

【解决方案5】：

我推荐Crystal Clear 方法

七种属性

使用时间框迭代的频繁交付/集成
反思改进、批评修正
通过办公室组织和开放渠道进行渗透（被动）知识获取和交流
个人安全、诚实安全、有信心接受法庭批评
保持专注、明确任务、工作优先级、限制工作量
访问专家用户、快速、高质量的反馈
常用的敏捷方法：自动化测试、CM、持续集成

【讨论】：

一瞬间我以为你在暗示这个：thedailywtf.com/Articles/FrontAhead-Design.aspx :D :D
Crystal clear 比 Scrum 更适合我（而且我是 CSM）

【解决方案6】：

开发流程基本上是为大型团队创建的，以避免可能出现的混乱。如果您尝试自己完成大型项目，那么无论您使用哪种开发流程都会失败，因为您需要大量的人才能及时完成所需的工作。

如果您从事小型项目，那么任何敏捷方法都可以。 GTD 不是方法，它是一种方法。这就像我为我的大脑过程申请专利一样。

【讨论】：

肯定有一个可接受的（工作量）/（团队人数）比率。

【解决方案7】：

不是直接回答您的问题，但史蒂夫·麦康奈尔 (Steve McConnell) 有一篇名为 Less is More 的文章十多年前写的关于为什么小团队更有效率的文章。

【讨论】：

一篇不错的文章，但确实偏离了问题的主题。目前在一个 11 人的团队中工作，发现在沟通方面要求很高。

【解决方案8】：

持续集成是我一直尝试在我工作的团队中建立的第一件事，因为我相信它是良好开发实践的基础，即经常集成、自动构建/发布、自测试构建，任何人都可以轻松获得最新的。

在此处了解更多信息： http://martinfowler.com/articles/continuousIntegration.html

【讨论】：

你知道，持续集成是整个公司都可以从中受益的东西，但我看不出它可以为小型团队（从 1 到 5 人）节省大量工作，只要他们沟通很多 - 至少没有启动和运行所需的工作量。
有一些工具可以帮助您完成设置工作 (teamcity)。是否选择实施它取决于您，但这是我在处理大型项目时尝试设置的第一件事，因为我认为它至关重要。拥有一个可以构建包括 iinstallers 甚至部署在内的所有内容的一键式构建已经为我节省了无数次，没有什么比发布一个产品只是因为人为错误导致它无法安装更令人尴尬的了。 CI 消除人为错误。