小团队的软件开发流程

Question

也许我是个例外，但我从未与超过三名开发人员和/或五个人的团队一起工作过。尽管如此，我们仍然可以设法完成工作。

是否有适合这种“极端”情况的软件开发流程？如果您作为独立程序员工作，是否有一些适用于日常生活的方法可以使其更可预测、连贯、记录，并且仍然能够完成工作？

- rshimoda

Answer 1

敏捷方法论是一个很好的起点，因为它们更适合小团队。

关于保持个人工作节奏，我建议使用基于TODO列表和Task2Gather等工具的方法。你可能还想看看GTD。

即使是对于只有我一个人的团队，我也绝不会放弃以下事项：

• 源代码版本控制
• 备份
• TODO
• 单元测试/TDD
• 代码文档
• 重构/代码审查

- Manrico Corazzi

---

@Manrico: 作为一个单人团队，我进行源代码控制、备份和拥有待办清单，但是除了手动模拟一些常见场景测试我的 Web 应用程序之外，我没有做单元测试和代码审查。您有任何建议，可以帮助我开始添加这些工作吗？写一篇关于您的流程的博客会很棒！;) - Sprogz

@Sprogz：这是你要的（只是草稿）http://babilsenior.blogspot.com/2008/10/test-driven-development1-eng.html - Manrico Corazzi

@Manrico：非常感谢！我已经阅读了许多关于TDD理论的文章，但我确实缺少普通开发人员如何使用它来帮助他们的开发过程的实际例子。你的博客文章很有帮助，我非常有兴趣继续阅读！做得好。我会收藏你的博客。 - Sprogz

我真的认为“人员配备”不是一个因素... 敏捷开发是为了减少成本，而不是增加成本。它是一种风格，而不是规则。 无论是5人还是500人，敏捷开发都可以对所有参与的工程师都有好处 :) 您可以拥有一个定制的敏捷开发（即不需要所有实践来满足您的需求），但仍然保持良好的编程实践，以实现最终的产品。 - ha9u63a7

Answer 2

让强大的SecretGeeek教你如何成为独立程序员。享受吧 :)

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

- MarkJ

---

将最后一部分改为“成功 >>>> ? >>>> 利润”，我就同意了。 - Robert Groves

我想这就是为什么不是所有的开发者都富有的原因... 我仍在寻找在开发成功和利润之间的桥梁。 - rshimoda

Answer 3

TODO驱动开发

这是一个来自SecretGeek的认真建议。

设置开发环境或编辑器自动列出所有带有TODO标记的行——Visual Studio默认就会这样做。

步骤1

• 编写类或方法概述（即，“Public Class …”或“Public Sub…”，内部没有代码。）
• 包含粗略逻辑
• 添加以“TODO:”为前缀的伪代码
• 只编写非常简单的代码——其他任何内容都可以添加TODO

步骤2

• 重复步骤1，直到整个应用程序粗略完成
• 现在你有了一份很长的“TODO”任务列表
• 检查完整性（广度）
• 看看哪些可以删除。
• 看看哪些可以简化（例如，两个相似的todo注释：它们可以变得相同吗？

步骤3

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

步骤4

• 逐个修复编译错误：
  • 编写类、方法等的框架，
  • 在进行操作时添加TODO：伪代码。
  • （如果时间紧迫，还可以添加“HACK: ”注释和解释。）
  • 如果适当，将TODO替换为所需的简单代码。

步骤5

• 重复步骤4，直到没有编译错误为止。
• 如果还有TODO，那么回到步骤3。

（还有很多先期规划、纸质原型设计、客户会议、讨论、拖延、数据库设计、喝咖啡、生成存储过程和CRUD-sproc调用的代码、可重用DAL的导入、PAG块的使用、go PAG！、签订文件之前的来回争论、争吵、熬夜、沮丧、与朋友聊天、查看电子邮件、在Visio中涂画、打印出东西并把它们扔在一堆上、寻找订书机、做后背和颈部伸展等等，但为了简单起见，这些都被省略了...）

(再次是MarkJ) 有点像《代码大全》中的伪代码编程过程。而且我们都认为每个人都应该阅读《代码大全》，对吧？（链接） （参考）

- MarkJ

---

这非常直接了当，尽管它看起来有些笨重，但在开发庞大的项目时独自工作时，它能够很好地发挥作用，因为你已经记不清缺少什么。 - rshimoda

Answer 4

大多数敏捷方法都符合您的要求。目前最流行的是SCRUM。它专为小团队提高生产力而设计，其支持者声称开发时间比传统的瀑布式方法节约5-10倍。如果您想开始阅读，我建议您阅读Headfirst Software Development书籍。

- Sebastian

---

Scrum是我目前和团队所采用的方法。我承认其中一些原则有些夸张，但我们在不断地进步中。现在你提到了它...我们居然忘记了我们的每日会议！ :O - Manrico Corazzi

Answer 5

I'd recommend the Crystal Clear method.

七大特性：

• 使用时间框架迭代频繁交付/集成
• 反思和改进，批评和修复
• 通过办公室组织和开放渠道进行被动知识获取和沟通
• 个人安全，可以坦诚，有信心面对批评
• 保持专注，明确任务，工作优先级，限制工作量
• 获得专家用户的支持，快速获得优质反馈
• 通常的敏捷实践：自动化测试，配置管理，持续集成

- epatel

---

我瞬间以为你在建议这个：http://thedailywtf.com/Articles/FrontAhead-Design.aspx <b>:D :D</b> - Manrico Corazzi

Crystal clear 对我来说甚至比 Scrum 更好（而我是 CSM）。 - rshimoda

Answer 6

开发流程基本上是为了避免可能出现的混乱而为大团队创建的。如果你试图独自完成大型项目，无论使用何种开发流程，你都将失败，因为你需要更多的人才能及时完成所需的工作。

如果你在小型项目上工作，那么任何敏捷方法都可以做到。GTD不是一种方法，它只是一种方法的冒充品。这就像我在专利我的大脑过程。

- Milani Milivoj

---

肯定需要一个可接受的（工作量/团队人数）比例。 - rshimoda

Answer 7

这不是对你问题的直接回答，但是 Steve McConnell 在十多年前写了一篇名为 Less is More 的文章，讲述了小团队更具生产力的原因。

- Martin Liversage

---

这是一篇不错的文章，但离问题的主题有些偏离。目前我在一个由11人组成的团队工作，发现在沟通方面非常具有挑战性。 - rshimoda

Answer 8

持续集成是我在工作团队中总是尝试首先设置的事情，因为我相信它是良好开发实践的基础，即经常集成、自动化构建/发布、自测试构建、任何人都可以轻松获取最新版本。

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

- Burt

---

你知道，持续集成是整个公司都可以受益的东西，但只要小团队（1到5人）之间进行了充分的沟通，我就看不出它能为他们节省多少工作量，至少不会比启动和运行它所需的工作量更少。 - rshimoda

有一些工具可以帮助你轻松地设置（例如TeamCity）。你可以选择是否实施，但在处理大型项目时，这是我尝试设置的首要事项之一，因为我认为它非常重要。拥有一个一键式构建工具，可以构建所有内容，包括安装程序甚至部署，这已经帮我省去了无数次麻烦。没有什么比发布产品后由于人为错误导致无法安装更令人尴尬的了。CI可以消除人为错误。 - Burt