小团队的软件开发过程

时间：2008-10-03 10:17:17

标签： architecture project-management

我可能是一个例外，但我从未在拥有超过三名开发人员和/或五人的团队中工作过。我们仍然可以设法完成工作（不知何故）。

是否有符合这种“极端”情景的软件开发流程？而且，如果你作为一个独立的程序员工作，你可以适应你的日常生活，使其更具可预测性，连贯性，记录并完成工作吗？

8 个答案:

答案 0 :(得分：22)

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

至于保持个人工作节奏，我建议使用基于TODO列表的方法和Task2Gather之类的工具。您也可以查看GTD。

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

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

答案 1 :(得分：6)

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

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

答案 2 :(得分：5)

TODO driven development

来自SecretGeek的严重建议。

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

第1步

  • 写出类或方法大纲（即“公共类......”或“公共子...”，里面没有代码。）
  • 包含粗略逻辑
  • 使用“TODO：”
    • 添加预先编码的伪代码
  • 只写非常琐碎的代码 - 其他任何东西只需添加一个TODO

第2步

  • 重复步骤1，直到整个应用程序被粗略化
  • 您现在已经有了一份“TODO”任务的大清单
  • 检查完整性（广度）
  • 查看可以删除的内容。
  • 看看可以简化的内容（例如，两个相似的待办事项评论：它们可以相同吗？

第3步

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

第4步

  • 一次修复一个编译错误：
    • 编写类，方法等的shell，
    • 随着时间的推移，为每一个添加TODO：伪代码。
    • （另外，如果按时间，请添加'HACK：'评论和解释）
    • 在适当的情况下，将TODO替换为所需的简单代码

第5步

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

（还有很多先前的计划，纸张原型设计，客户会议，讨论，拖延，数据库设计，喝咖啡，代码生成用于sprocs和crud-sproc调用，导入可重复使用的DAL， PAG阻止使用，去PAG !,在文件签收之前来回辩论，争论，深夜，沮丧，与朋友聊天，通过电子邮件筛选，刮擦visio，打印出来并将它们留在堆中，寻找主食，抓住公共汽车，做背部和颈部伸展等等，但为了简单起见，这一切都被遗漏了......）

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

答案 3 :(得分：4)

我建议使用Crystal Clear方法

The Seven Properties

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

答案 4 :(得分：3)

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

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

如果你想开始阅读

，我推荐Headfirst Software Development本书

答案 5 :(得分：2)

基本上为大型团队创建了开发流程，以避免可能的混乱。如果您正在尝试自己做大型项目，无论您使用何种开发过程，都会失败，因为您需要大量数据来完成所需的时间。

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

答案 6 :(得分：1)

不是你问题的直接答案，但Steve McConnell在十多年前写了一篇名为Less is More的文章，讲述为什么小团队的工作效率更高。

答案 7 :(得分：1)

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

在这里阅读更多相关信息： http://martinfowler.com/articles/continuousIntegration.html

相关问题
最新问题