We design the UI first. This is absolutely critical for our designs, as a complex UI will almost immediately alienate potential buyers. We prototype our designs on paper, then as we decide on specifics for the design, prepare the View and any appropriate Controller code for continuous interactive prototyping of our designs.
As we move towards an acceptable UI, we then write a paper spec for the workflow logic of the application. Paper is cheap, and churning through designs guarantees that you've at least spent a small amount of time thinking about the implementation rather than coding blind.
Our specs are kept in revision control along with our source. If we decide on a change, or want to experiment, we branch the code, and IMMEDIATELY update the spec to detail what we're trying to accomplish with this particular branch. Unit tests for branches are not required; however, they are required for anything we want to incorporate back into trunk. We've found this encourages experiments.
Specs are not holy, nor are they owned by any particular individual. By committing the spec to the democratic environment of source control, we encourage constant experimentation and revision - as long as it is documented so we aren't saying "WTF?" later. On a recent iPhone game (not yet published), we ended up with almost 500 branches, which later translated into nearly 20 different features, a huge number of concept simplifications ("Tap to Cancel" on the progress bar instead of a separate button), a number of rejected ideas, and 3 new projects. The great thing is each and every idea was documented, so it was easy to visualize how the idea could change the product.
After each major build (anything in trunk gets updated, with unit tests passing), we try to have at least 2 people test out the project. Mostly, we try to find people who have little knowledge of computers, as we've found it's far too easy to design complexity rather than simplicity.
We use DOxygen to generate our documentation. We don't really have auto generation incorporated into our build process yet, but we are working on it.
We do not code review. If the unit test works, and the source doesn't cause problems, it's probably ok - but this is because we are able to rely on the quality of our programmers. This probably would not work in all environments.
Unit testing has been a god-send for our programming practices. Since any new code can not be passed into trunk without appropriate unit tests, we have fairly good coverage with our trunk, and moderate coverage in our branches. However, it is no substitute for user testing - only a tool to aid in getting to that point.
For bug tracking, we use bugzilla. We don't like it, but it works for now. We will probably soon either roll our own solution or migrate to FogBugz. Our goal is to not release software until we reach a 0 known bugs status. Because of this stance, our updates to our existing code packages are usually fairly minimal.
So, basically, our flow usually looks something like this:
View Code + Unit Tests » User Testing » Step 1 or 2
Paper Controller & Model Spec + Planning » Mental Testing » Step 2 or 3
Model & Controller Code + Unit Tests » User Testing » Step 3 or 4
Branched Idea » Spec » Coding (no unit tests) » Mental Testing » Rejection
Branched Idea » Spec » Coding (no unit tests) » Mental Testing » Acceptance » Unit Tests » Trunk » Step 2 or 4
Known Bugs » Bug Tracker » Bug Repair » Step 2 or 4
Finished Product » Bug Reports » Step 2 or 4
Our process is not perfect by any means, but a perfect process would also imply perfect humans and technology - and THAT's not going to happen anytime soon. The amount of paper we go through in planning is staggering - maybe it's time for us to get a contract with Dunder Mifflin?
I am not sure why this question was down voted. I think it's a great question. It's one thing to google search, and read some random websites which a lot of times are trying to sell you something rather than to be objective. And it's another thing to ask SO crowd which are developers/IT Mangers to share their experiences, and what works or doesn't work for their teams.
Now that this point is out of the way. I am sure a lot of developers will point you towards "Agile" and/or Scrum, keep in mind that these terms are often used very loosely especially Agile. I am probably going to sound very controversial by saying this which is not my intention, but these methodologies are over-hyped, especially Scrum which is more of a product being marketed by Scrum consultants than "real" methodology. Having said that, at the end of a day, you got to use what works the best for you and your team, if it's Agile/Scrum/XP or whatever, go for it. At the same time you need to be flexible about it, don't become religious about any methodology, tool, or technology. If something is not working for you, or you can get more efficient by changing something, go for it.
To be more specific regarding your questions. Here's the basic summary of techniques that have been working for me (a lot of these are common sense):
Organize all the documents, and emails pertaining to a specific project, and make it accessible to others through a central location (I use MS OneNote 2007 and Love it for all my documentation, progess, features, and bug tracking, etc.)
All meetings (which you should try to minimize) should be followed by action items where each item is assigned to a specific person. Any verbal agreement should be put into a written document. All documents added to the project site/repository. (MS OneNote in my case)
Before starting any new development, have a written document of what the system will be capable of doing (and what it wont do). Commit to it, but be flexible to business needs. How detailed the document should be? Detailed enough so that everyone understands what the final system will be capable of.
Schedules are good, but be realistic and honest to yourself and business users. The basic guideline that I use: release quality and usable software that lacks some features, rather than a buggy software with all the features.
Have open lines of communication among your dev. team and between your developers and business groups, but at the end of a day, one person (or a few key people) should be responsible for making key decisions.
Unit test where it makes sense. But DO NOT become obsessive about it. 100% code coverage != no bugs, and software works correctly according to the specs.
Do have code standards, and code reviews. Commit to standards, but if it does not work for some situations allow for flexibility.
Comment your code especially hard to read/understand parts, but don't make it into a novel.
Go back and clean up you code if you already working on that class/method; implementing new feature, working on a bug fix etc. But don't refactor it just for the sake of refactoring, unless you have nothing else to do and you're bored.
And the last and more important item: Do not become religious about any specific methodology or technology. Borrow the best aspects from each, and find the balance that works for you and your team.
We use Trac as our bug/feature request tracking system
Trac Tickets are reviewed, changed to be workable units and then assigned to a milestone
The trac tickets are our specs, containing mostly very sparse information which has to be talked over during the milestone
No, but our development team consists only of two members
Yes, we test, and yes, TDD has helped us very much. Coverage is at about 70 Percent (Cobertura)
No, we refactor when appropriate (during code changes)
We document only public methods and classes, our maximum line count is 40, so methods are usually so small to be self-describing (if there is such a thing ;-)
svn with trunk, rc and stable branches
trunk - Development of new features, bugfixing of older features
rc - For in house testing, bugfixes are merged down from trunk
stable - only bugfixing merged down from trunk or rc
To give a better answer, my company's policy is to use XP as much as possible and to follow the principles and practices as outlined in the Agile manifesto.
So this includes things like story cards, test-driven development, pair programming, automated testing, continuous integration, one-click installs and so on. We are not big on documentation, but we realize that we need to produce just enough documentation in order to create working software.
In a nut shell:
create just enough user stories to start development (user stories here are meant to be the beginning of the conversation with business and not completed specs or fully fleshed out use cases, but short bits of business value that can be implemented in less then 1 iteration)
iteratively implement story cards based on what the business prioritizes as the most important
get feedback from the business on what was just implemented (e.g., good, bad, almost, etc)
repeat until business decides that the software is good enough
发布评论
评论（4）
对于我的（小）公司：
我们首先设计 UI。 这对于我们的设计来说绝对重要，因为复杂的用户界面几乎会立即疏远潜在买家。 我们在纸上上对设计进行原型设计，然后当我们决定设计细节时，准备视图和任何适当的控制器代码，以便为我们的设计进行持续的交互式原型设计。
当我们朝着可接受的 UI 迈进时，我们会为应用程序的工作流程逻辑编写一份论文规范。 纸张很便宜，并且反复进行设计可以保证您至少花少量时间思考实现而不是盲目编码。
我们的规格与我们的来源一起保存在修订控制中。 如果我们决定进行更改或想要进行实验，我们会对代码进行分支，并立即更新规范以详细说明我们试图通过此特定分支完成的任务。 不需要分支的单元测试； 然而，对于我们想要合并回主干的任何东西来说，它们都是必需的。 我们发现这鼓励实验。
规格并不神圣，也不属于任何特定个人。 通过将规范提交给源代码控制的民主环境，我们鼓励不断的实验和修订 - 只要它被记录下来，这样我们就不会说“WTF？” 稍后。
在最近的一款 iPhone 游戏（尚未发布）中，我们最终得到了近 500 个分支，这些分支后来转化为近 20 个不同的功能，大量的概念简化（进度条上的“点击取消”而不是单独的按钮） 、一些被拒绝的想法和 3 个新项目。 伟大的事情是每一个想法都被记录下来，因此很容易想象这个想法如何改变产品。
在每次主要构建之后（主干中的所有内容都会更新，单元测试通过），我们尝试让至少 2 个人测试该项目。 大多数情况下，我们试图找到对计算机知之甚少的人，因为我们发现设计复杂性而不是简单性太容易了。
我们使用 DOxygen 来生成我们的文档。 我们还没有真正将自动生成合并到我们的构建过程中，但我们正在努力。
我们不进行代码审查。 如果单元测试有效，并且源代码不会引起问题，那么可能没问题 - 但这是因为我们能够依赖程序员的质量。 这可能不适用于所有环境。
单元测试对于我们的编程实践来说是天赐之物。 由于没有适当的单元测试，任何新代码都无法传递到主干，因此我们的主干覆盖率相当高，而分支机构的覆盖率适中。 然而，它并不能替代用户测试——只是一个帮助实现这一点的工具。
对于错误跟踪，我们使用 bugzilla。 我们不喜欢它，但它目前有效。 我们可能很快就会推出自己的解决方案或迁移到 FogBugz。 我们的目标是在达到 0 已知错误状态之前不发布软件。 由于这种立场，我们对现有代码包的更新通常相当少。
因此，基本上，我们的流程通常如下所示：
我们的流程无论如何都不是完美的，但完美的流程也意味着完美的人类和技术——而这不会很快发生。 我们在规划过程中需要处理的文件数量惊人 - 也许我们是时候与 Dunder Mifflin 签订合同了？
For my (small) company:
We design the UI first. This is absolutely critical for our designs, as a complex UI will almost immediately alienate potential buyers. We prototype our designs on paper, then as we decide on specifics for the design, prepare the View and any appropriate Controller code for continuous interactive prototyping of our designs.
As we move towards an acceptable UI, we then write a paper spec for the workflow logic of the application. Paper is cheap, and churning through designs guarantees that you've at least spent a small amount of time thinking about the implementation rather than coding blind.
Our specs are kept in revision control along with our source. If we decide on a change, or want to experiment, we branch the code, and IMMEDIATELY update the spec to detail what we're trying to accomplish with this particular branch. Unit tests for branches are not required; however, they are required for anything we want to incorporate back into trunk. We've found this encourages experiments.
Specs are not holy, nor are they owned by any particular individual. By committing the spec to the democratic environment of source control, we encourage constant experimentation and revision - as long as it is documented so we aren't saying "WTF?" later.
On a recent iPhone game (not yet published), we ended up with almost 500 branches, which later translated into nearly 20 different features, a huge number of concept simplifications ("Tap to Cancel" on the progress bar instead of a separate button), a number of rejected ideas, and 3 new projects. The great thing is each and every idea was documented, so it was easy to visualize how the idea could change the product.
After each major build (anything in trunk gets updated, with unit tests passing), we try to have at least 2 people test out the project. Mostly, we try to find people who have little knowledge of computers, as we've found it's far too easy to design complexity rather than simplicity.
We use DOxygen to generate our documentation. We don't really have auto generation incorporated into our build process yet, but we are working on it.
We do not code review. If the unit test works, and the source doesn't cause problems, it's probably ok - but this is because we are able to rely on the quality of our programmers. This probably would not work in all environments.
Unit testing has been a god-send for our programming practices. Since any new code can not be passed into trunk without appropriate unit tests, we have fairly good coverage with our trunk, and moderate coverage in our branches. However, it is no substitute for user testing - only a tool to aid in getting to that point.
For bug tracking, we use bugzilla. We don't like it, but it works for now. We will probably soon either roll our own solution or migrate to FogBugz. Our goal is to not release software until we reach a 0 known bugs status. Because of this stance, our updates to our existing code packages are usually fairly minimal.
So, basically, our flow usually looks something like this:
Our process is not perfect by any means, but a perfect process would also imply perfect humans and technology - and THAT's not going to happen anytime soon. The amount of paper we go through in planning is staggering - maybe it's time for us to get a contract with Dunder Mifflin?
我不确定为什么这个问题被否决了。 我认为这是一个很好的问题。 谷歌搜索和阅读一些随机网站是一回事，这些网站很多时候试图向您推销一些东西而不是客观的。 要求开发人员/IT 经理等人群分享他们的经验以及什么对他们的团队有效或无效是另一回事。
现在这一点已经不存在了。 我确信很多开发人员会向您指出“敏捷”和/或 Scrum，请记住，这些术语通常使用得非常宽松，尤其是敏捷。 我这样说可能听起来很有争议，这不是我的本意，但这些方法论被过度炒作了，尤其是 Scrum，它更像是 Scrum 顾问推销的产品，而不是“真正的”方法论。 话虽如此，归根结底，您必须使用最适合您和您的团队的方法，如果是敏捷/Scrum/XP 或其他方法，那就去做吧。 同时你需要保持灵活性，不要对任何方法、工具或技术抱有宗教信仰。 如果某件事不适合你，或者你可以通过改变某件事来提高效率，那就去做吧。
更具体地回答您的问题。 以下是对我有用的技术的基本摘要（其中很多都是常识）：
组织与特定项目相关的所有文档和电子邮件，并使其可供其他人通过中心位置访问（我使用 MS OneNote 2007 并喜欢它来记录我的所有文档、进度、功能和错误跟踪等。）
所有会议（您应该尽量减少会议）后面都应该有行动项目，其中每个项目都分配给一个特定的人。 任何口头协议均应写入书面文件。 添加到项目站点/存储库的所有文档。 （在我的例子中是 MS OneNote）
在开始任何新的开发之前，请编写一份书面文档，说明系统能够做什么（以及不能做什么）。 致力于它，但要灵活地满足业务需求。 该文件应该有多详细？ 足够详细，以便每个人都了解最终系统的功能。
时间表固然不错，但对自己和企业用户要现实且诚实。 我使用的基本准则是：发布缺乏某些功能的质量和可用软件，而不是发布具有所有功能的有缺陷的软件。
在您的开发人员之间保持开放的沟通渠道。 团队之间以及开发人员和业务团队之间，但最终，一个人（或几个关键人员）应该负责做出关键决策。
在有意义的地方进行单元测试。 但不要对此过于着迷。 100% 代码覆盖率！= 没有错误，并且软件根据规范正常工作。
有代码标准和代码审查。 遵守标准，但如果它在某些情况下不起作用，则允许灵活性。
注释您的代码特别难以阅读/理解的部分，但不要将其写成小说。
注释
如果您已经在使用该类/方法，请返回并清理您的代码； 错误等。但是不要为了重构而重构它，除非你没有其他事可做并且感到无聊。
最后也是更重要的一项：
不要对任何特定的方法或技术抱有宗教信仰。 借鉴每个方面的优点，找到适合您和您的团队的平衡点。
I am not sure why this question was down voted. I think it's a great question. It's one thing to google search, and read some random websites which a lot of times are trying to sell you something rather than to be objective. And it's another thing to ask SO crowd which are developers/IT Mangers to share their experiences, and what works or doesn't work for their teams.
Now that this point is out of the way. I am sure a lot of developers will point you towards "Agile" and/or Scrum, keep in mind that these terms are often used very loosely especially Agile. I am probably going to sound very controversial by saying this which is not my intention, but these methodologies are over-hyped, especially Scrum which is more of a product being marketed by Scrum consultants than "real" methodology. Having said that, at the end of a day, you got to use what works the best for you and your team, if it's Agile/Scrum/XP or whatever, go for it. At the same time you need to be flexible about it, don't become religious about any methodology, tool, or technology. If something is not working for you, or you can get more efficient by changing something, go for it.
To be more specific regarding your questions. Here's the basic summary of techniques that have been working for me (a lot of these are common sense):
Organize all the documents, and emails pertaining to a specific project, and make it accessible to others through a central location (I use MS OneNote 2007 and Love it for all my documentation, progess, features, and bug tracking, etc.)
All meetings (which you should try to minimize) should be followed by action items where each item is assigned to a specific person. Any verbal agreement should be put into a written document. All documents added to the project site/repository. (MS OneNote in my case)
Before starting any new development, have a written document of what the system will be capable of doing (and what it wont do). Commit to it, but be flexible to business needs. How detailed the document should be? Detailed enough so that everyone understands what the final system will be capable of.
Schedules are good, but be realistic and honest to yourself and business users. The basic guideline that I use: release quality and usable software that lacks some features, rather than a buggy software with all the features.
Have open lines of communication among your dev. team and between your developers and business groups, but at the end of a day, one person (or a few key people) should be responsible for making key decisions.
Unit test where it makes sense. But DO NOT become obsessive about it. 100% code coverage != no bugs, and software works correctly according to the specs.
Do have code standards, and code reviews. Commit to standards, but if it does not work for some situations allow for flexibility.
Comment your code especially hard to read/understand parts, but don't make it into a novel.
Go back and clean up you code if you already working on that class/method; implementing new feature, working on a bug fix etc. But don't refactor it just for the sake of refactoring, unless you have nothing else to do and you're bored.
And the last and more important item:
Do not become religious about any specific methodology or technology. Borrow the best aspects from each, and find the balance that works for you and your team.
为了给出更好的答案，我公司的政策是尽可能多地使用 XP 并遵循敏捷宣言中概述的原则和实践。
http://agilemanifesto.org/
http://www.extremeprogramming.org/
因此，这包括故事卡、测试驱动开发、结对编程、自动化测试、持续集成、一键安装等。 我们并不擅长文档，但我们意识到我们需要生成足够的文档才能创建工作软件。
简而言之：
To give a better answer, my company's policy is to use XP as much as possible and to follow the principles and practices as outlined in the Agile manifesto.
http://agilemanifesto.org/
http://www.extremeprogramming.org/
So this includes things like story cards, test-driven development, pair programming, automated testing, continuous integration, one-click installs and so on. We are not big on documentation, but we realize that we need to produce just enough documentation in order to create working software.
In a nut shell: