25

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

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

4

8 回答 8

23

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

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

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

  • 源版本控制
  • 备份
  • 去做
  • 单元测试/ TDD
  • 代码文档
  • 重构/代码审查
于 2008-10-03T10:26:23.987 回答
6

让强大的SecretGeeek教你如何成为一个独立的程序员。享受 ：）

   intellisense 
        ||
        \/
       code >>> compile >>>>> run >>>> success >>>> profit ;-)
        /\         ||          ||         
        ^^         \/          \/
        ^^      errors       errors 
        ^^          \\       //
        ^^           \\     //
        ^^             google
        ^^              ||
        \\              \/
         \<<<<<<<  copy N paste
于 2009-02-28T21:15:10.783 回答
5

TODO 驱动开发

来自SecretGeek的严肃建议。

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

第1步

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

第2步

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

第 3 步

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

第4步

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

第 5 步

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

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

（又是 MarkJ）有点像Code Complete中的伪代码编程过程。我们都同意每个人都应该阅读 Code Complete，对吧？

于 2009-02-28T21:26:05.407 回答
4

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

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

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

于 2008-10-03T10:30:59.250 回答
4

我会推荐Crystal Clear方法

七大属性

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

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

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

于 2009-10-20T08:49:51.993 回答
1

不是直接回答您的问题，但史蒂夫·麦康奈尔 (Steve McConnell)十多年前写了一篇名为“少即是多”的文章，探讨了为什么小型团队更有效率。

于 2009-10-20T10:05:55.287 回答
1

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

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

于 2009-10-20T10:10:18.433 回答