When we moved to having builds on a consistent basis (in our case weekly or twice per week) we saw the biggest improvement.
When every build was produced we sat down with the development team, the QA team and the product management team and created a list of the work that was included in the new build.
Everyone then helped answer the question of what should be included in the next build.
We have since added many other features of Agile development (including trying to implement a scrum to the letter), but nothing has given us as much "bang for the buck" as iterative building.
Iterative development. Work in small iterations (say 2 weeks), have 'ready' application by the end of each and single iteration, i.e. your testers should be happy to release the results to your customers.
I'm a big fan of mix-and-match, and an incremental change of the development process. I agree that iterative development should be your first goal, but I think you can approach it in even smaller steps.
From my experience, I would recommend the following order - pick the first you don't do already:
Fix Bugs First. I wish I wouldn't have to say that. This is the call of sanity, and also required to have shorter cycles.
Small steps. Train the habit of implementing the smallest change that is a visible step towards the next feature, then compile and test. Break down all your tasks into <1h units before starting to code. Aim for buildable, functional code at least every 15 minutes. This doesn't require much infrastructure change - except maybe fixing the incremental build and having fast machines.
Yes! Start with making sure developers have fast machines. How much better advise could get?!
Build Everything Daily. Set up a double-click full builds from Source Control to installation medium, ideally on a separate PC. This are the first step to the frequent builds, but they help a lot on their own already. For us, it was a crucial step in getting reliable, reproducable build results.
Start writing Unit Tests. Don't bother about coverage yet, don't enforce "write tests first", but put the framework in place. Write tests for new code and changes. Then run them with your daily builds.
Short Cycles. Now it's the time, you have all tools in place to make weekly or two-weekly in house releases: The codebase is in a deliverable state many times a day, making the build is a double-click away, and at least something is working.
My recommendation is start with TDD first. It is very easy to do and has a profound impact on quality.
There are several parts to this.
Everyone has to get the tools (JUnit or whatever -- this can be hard in some cultures.)
Managers have to demand that the testing is done. They must never (NEVER) circumvent the unit testing. As soon as someone says "those tests don't matter, ship it anyway" you've undone all the good from TDD.
You have to manage by test case: how many written, how many passed. You have to define functionality via test cases: feature [X] has [n] test cases, of which some are done, some are in process.
Agile is quite the buzzword now, but please keep in mind that it is NOT a silver bullet; it will not fix your development process just like that. You may want to read Steve Yegge's excellent article about Agile Development to balance the hype.
"Cherry-picking" some aspect of agile development may be difficult if you don't grasp the core of Agile. Agile is more than anything else a way to think: be flexible, accept that things will change, write code in short iterations focused on getting one or few features complete. The opposite of getting a single, complete, monolithic specification, writing all the code, documentation, and then ship it.
If you want to prove that Agile Development works, I'd probably vote for using the sprint to show what "release early, release often" means.
Make a cross-functional team with programmers, testers, technical writers and possibly sales/services folks all together. Make them realize the concept of 'done' i.e. something to be finished is something that is written, tested, documented, installed, deployed and ready for customer to use.
It is important because unless everyone from various functional areas gets together and focus on the single objective of getting something to the client, you cannot implement any other aspect of Agile framework.
Totally depends upon your existing process, but I'll tell you that one of the best moves we made was to get the concept of the item backlog and daily 3-question (What did you work on since we met last? What are you going to work on today? What are the roadblocks keeping you from moving forward?) meeting in the morning to see where we are and what we can do to move forward toward our short-iteration cycle endpoint.
It's good to be able to see the dynamic backlog of work to do and what is being worked on now and what's going to make it into the next iteration. It's good to be able to get an idea about where individual developers are and to help them eliminate any impediments to moving forward. It keeps developers from going dark.
Start with unit testing if you're not already doing that. If you are unit testing, switch to test-driven development. These are both easy to add into existing processes and will pay immediate dividends. When you're ready to tackle process changes, bring in iterative development. If your current process is already iterative, then start doing frequent releases of your iterations to customers to get feedback.
If I had to sum up the "agile" way, I would say deliver high-quality business value early and often. The practices above will get you a long way along that path.
[EDIT] I guess what I'm suggesting is take an agile approach to adopting agile methods and start with easy things that deliver lots of value right away.
I would try to go with Test Driven Development. This will give you many things:
You will get a pretty good unit test coverage (I'm not saying that unit test coverage is important).
Developers will have more confidence that the code is really working (see * later for more information)
You will be able to refactor the code more easily (because you have the tests).
[*] - Kent Beck in this area mentions Influence diagrams. In influence diagrams an arrow between nodes means that an increase in the first node implies an increase in the second node. An arrow with a circle means that an increase in the first node implies a decrease in the second node.
-----> [Stress] <--o-- / --o--> [RunTests]
The more stress you feel, the less testing you will do. The less testing you do, the more errors you will make. The more errors you make, the more stress you feel. Repeat...
How to solve this circle that leads to stressed developers not trusting their own code after a while?
Test first development changes the influence diagram:
[TestFirst] <--o-- / --o--> [Stress]
The more you do test first development, less stress you feel. The less stress you feel, the more tests first development you do.
This leads to better testing code developed by developers who trust their code.
In addition to all the good advices already provided and that I concur with, I'd suggest to strengthen QA with automatic, repeatable tests. Investing in automation will allow you to be more confident when changing already deployed code.
Create regression suites for the new features at the same time as you implement them.
QA can use exploratory testing as an alternative to find holes in your development process.
I think the two most valuable and easy to implement aspects of Agile are
daily stand ups - have a brief daily meeting with the team to review status. Use the 3 questions. Avoid cross-talk, chatter, and bitching. Keep it quick and on on-point.
time-boxed iterations - breaking the project up into two or three week cycles forces you to work towards manageable goals on reasonable deadlines
发布评论
评论（12）
迭代构建
当我们转向在一致的基础上进行构建（在我们的例子中每周或每周两次）时，我们看到了最大的改进。
当每个版本生成后，我们都会与开发团队、QA 团队和产品管理团队坐下来，创建新版本中包含的工作列表。
然后每个人都帮助回答了下一个版本中应该包含哪些内容的问题。
此后，我们添加了敏捷开发的许多其他功能（包括尝试严格执行 Scrum），但没有什么比迭代构建更“划算”了。
Iterative building
When we moved to having builds on a consistent basis (in our case weekly or twice per week) we saw the biggest improvement.
When every build was produced we sat down with the development team, the QA team and the product management team and created a list of the work that was included in the new build.
Everyone then helped answer the question of what should be included in the next build.
We have since added many other features of Agile development (including trying to implement a scrum to the letter), but nothing has given us as much "bang for the buck" as iterative building.
迭代开发。 以小规模迭代（例如两周）进行工作，在每次迭代结束时准备好应用程序，即您的测试人员应该很乐意将结果发布给您的客户。
这是核心。 你可以以此为基础。
Iterative development. Work in small iterations (say 2 weeks), have 'ready' application by the end of each and single iteration, i.e. your testers should be happy to release the results to your customers.
This is the core. You could build on this.
我非常喜欢混合搭配以及开发过程的渐进式改变。 我同意迭代开发应该是您的首要目标，但我认为您可以通过更小的步骤来实现它。
根据我的经验，我会推荐以下顺序 - 选择您尚未执行的第一个：
首先修复错误。我希望我不必这么说。 这是理智的召唤，也要求更短的周期。
小步骤。培养实现最小更改的习惯，这是迈向下一个功能的可见步骤，然后编译和测试。 在开始编码之前，将所有任务分解为 <1 小时的单元。 目标是至少每 15 分钟编写一次可构建的功能性代码。 这不需要太多的基础设施改变 - 除了可能修复增量构建和拥有快速机器。
是的！ 首先确保开发人员拥有快速的机器。 还能得到多少更好的建议？
每日构建所有内容。设置从源代码管理到安装介质的双击完整构建，最好是在单独的 PC 上。 这是频繁构建的第一步，但它们本身已经有很大帮助。 对于我们来说，这是获得可靠、可重现的构建结果的关键一步。
开始编写单元测试。先不要担心覆盖率，不要强制“首先编写测试”，而是将框架放在适当的位置。 为新代码和更改编写测试。 然后在日常构建中运行它们。
周期短。现在，您已经拥有了每周或每两周一次的内部发布的所有工具：代码库每天多次处于可交付状态，从而使构建成为可能双击即可，至少有些东西正在工作。
I'm a big fan of mix-and-match, and an incremental change of the development process. I agree that iterative development should be your first goal, but I think you can approach it in even smaller steps.
From my experience, I would recommend the following order - pick the first you don't do already:
Fix Bugs First. I wish I wouldn't have to say that. This is the call of sanity, and also required to have shorter cycles.
Small steps. Train the habit of implementing the smallest change that is a visible step towards the next feature, then compile and test. Break down all your tasks into <1h units before starting to code. Aim for buildable, functional code at least every 15 minutes. This doesn't require much infrastructure change - except maybe fixing the incremental build and having fast machines.
Yes! Start with making sure developers have fast machines. How much better advise could get?!
Build Everything Daily. Set up a double-click full builds from Source Control to installation medium, ideally on a separate PC. This are the first step to the frequent builds, but they help a lot on their own already. For us, it was a crucial step in getting reliable, reproducable build results.
Start writing Unit Tests. Don't bother about coverage yet, don't enforce "write tests first", but put the framework in place. Write tests for new code and changes. Then run them with your daily builds.
Short Cycles. Now it's the time, you have all tools in place to make weekly or two-weekly in house releases: The codebase is in a deliverable state many times a day, making the build is a double-click away, and at least something is working.
请参阅最佳具体“操作手册” ”关于管理测试驱动和/或敏捷开发？。
我的建议是首先从 TDD 开始。 它非常容易做到，并且对质量有深远的影响。
这有几个部分。
每个人都必须获得工具（JUnit 或其他东西 - 这在某些文化中可能很难。）
你必须通过测试用例来管理：写了多少，通过了多少。 您必须通过测试用例来定义功能：功能 [X] 有 [n] 个测试用例，其中一些已完成，一些正在处理中。
See Best concrete “how-to manual” on MANAGING Test Driven and/or Agile development?.
My recommendation is start with TDD first. It is very easy to do and has a profound impact on quality.
There are several parts to this.
Everyone has to get the tools (JUnit or whatever -- this can be hard in some cultures.)
Managers have to demand that the testing is done. They must never (NEVER) circumvent the unit testing. As soon as someone says "those tests don't matter, ship it anyway" you've undone all the good from TDD.
You have to manage by test case: how many written, how many passed. You have to define functionality via test cases: feature [X] has [n] test cases, of which some are done, some are in process.
敏捷现在是一个流行词，但请记住，它不是银弹； 它不会像那样修复你的开发过程。 您可能想阅读Steve Yegge 的精彩文章 关于敏捷开发以平衡炒作。
如果您不掌握敏捷的核心，那么“挑选”敏捷开发的某些方面可能会很困难。 敏捷比其他任何东西都重要一种思考方式：保持灵活性，接受事情会发生变化，在简短的迭代中编写代码，专注于完成一个或几个功能。 与获取单一、完整、单一的规范、编写所有代码、文档然后发布它相反。
如果你想证明敏捷开发是有效的，我可能会投票支持使用冲刺来展示“尽早发布，经常发布”的含义。
Agile is quite the buzzword now, but please keep in mind that it is NOT a silver bullet; it will not fix your development process just like that. You may want to read Steve Yegge's excellent article about Agile Development to balance the hype.
"Cherry-picking" some aspect of agile development may be difficult if you don't grasp the core of Agile. Agile is more than anything else a way to think: be flexible, accept that things will change, write code in short iterations focused on getting one or few features complete. The opposite of getting a single, complete, monolithic specification, writing all the code, documentation, and then ship it.
If you want to prove that Agile Development works, I'd probably vote for using the sprint to show what "release early, release often" means.
组建一个由程序员、测试人员、技术作家以及可能的销售/服务人员组成的跨职能团队。 让他们认识到“完成”的概念，即要完成的东西是经过编写、测试、记录、安装、部署并准备好供客户使用的东西。
这很重要，因为除非来自不同职能领域的每个人聚集在一起并专注于向客户提供某些东西的单一目标，否则您无法实现敏捷框架的任何其他方面。
Make a cross-functional team with programmers, testers, technical writers and possibly sales/services folks all together. Make them realize the concept of 'done' i.e. something to be finished is something that is written, tested, documented, installed, deployed and ready for customer to use.
It is important because unless everyone from various functional areas gets together and focus on the single objective of getting something to the client, you cannot implement any other aspect of Agile framework.
完全取决于您现有的流程，但我会告诉您，我们采取的最佳举措之一是了解项目待办事项和每日 3 个问题的概念（自从我们上次见面以来，您在做什么？您打算做什么今天要做什么？阻碍你前进的障碍是什么？）早上开会看看我们的进展以及我们可以做些什么来朝着我们的短迭代周期终点前进。
能够看到动态积压的工作、现在正在做什么以及将进入下一次迭代的内容是件好事。 能够了解各个开发人员的情况并帮助他们消除前进的障碍是件好事。 它可以防止开发人员走向黑暗。
无论如何，这就是我的想法。 它对我们有用。
Totally depends upon your existing process, but I'll tell you that one of the best moves we made was to get the concept of the item backlog and daily 3-question (What did you work on since we met last? What are you going to work on today? What are the roadblocks keeping you from moving forward?) meeting in the morning to see where we are and what we can do to move forward toward our short-iteration cycle endpoint.
It's good to be able to see the dynamic backlog of work to do and what is being worked on now and what's going to make it into the next iteration. It's good to be able to get an idea about where individual developers are and to help them eliminate any impediments to moving forward. It keeps developers from going dark.
Anyhow, that is my thought. It worked for us.
如果您还没有这样做，请从单元测试开始。 如果您正在进行单元测试，请切换到测试驱动开发。 这些都很容易添加到现有流程中，并且会立即带来红利。 当您准备好应对流程变更时，请引入迭代开发。 如果您当前的流程已经是迭代的，那么开始频繁地向客户发布迭代以获得反馈。
如果我必须总结“敏捷”方式，我会说尽早并经常交付高质量的业务价值。 上述实践将使您在这条道路上走得更远。
[编辑] 我想我的建议是采用敏捷方法来采用敏捷方法，并从立即提供大量价值的简单事情开始。
Start with unit testing if you're not already doing that. If you are unit testing, switch to test-driven development. These are both easy to add into existing processes and will pay immediate dividends. When you're ready to tackle process changes, bring in iterative development. If your current process is already iterative, then start doing frequent releases of your iterations to customers to get feedback.
If I had to sum up the "agile" way, I would say deliver high-quality business value early and often. The practices above will get you a long way along that path.
[EDIT] I guess what I'm suggesting is take an agile approach to adopting agile methods and start with easy things that deliver lots of value right away.
在自动化构建中运行的自动化测试。
Automated tests that run in an automated build.
我会尝试使用测试驱动开发。 这将为您带来很多好处：
[*] - Kent Beck 在该领域提到了影响图。 在影响图中，节点之间的箭头意味着第一个节点的增加意味着第二个节点的增加。 带圆圈的箭头表示第一个节点的增加意味着第二个节点的减少。
你感受到的压力越大，你做的测试就越少。 你做的测试越少，你犯的错误就越多。 你犯的错误越多，你感受到的压力就越大。 重复...
如何解决这个导致压力很大的开发人员在一段时间后不再信任自己的代码的循环？
测试优先开发改变了影响图：
测试优先开发越多，感受到的压力就越小。 您感受到的压力越小，您在首次开发时所做的测试就越多。
这可以更好地测试信任其代码的开发人员开发的代码。
I would try to go with Test Driven Development. This will give you many things:
[*] - Kent Beck in this area mentions Influence diagrams. In influence diagrams an arrow between nodes means that an increase in the first node implies an increase in the second node. An arrow with a circle means that an increase in the first node implies a decrease in the second node.
The more stress you feel, the less testing you will do. The less testing you do, the more errors you will make. The more errors you make, the more stress you feel. Repeat...
How to solve this circle that leads to stressed developers not trusting their own code after a while?
Test first development changes the influence diagram:
The more you do test first development, less stress you feel. The less stress you feel, the more tests first development you do.
This leads to better testing code developed by developers who trust their code.
除了已经提供的、我同意的所有好的建议之外，我建议通过自动、可重复的测试来加强质量保证。 投资自动化将使您在更改已部署的代码时更加自信。
在实现新功能的同时为新功能创建回归套件。
QA 可以使用探索性测试作为寻找开发过程中漏洞的替代方法。
In addition to all the good advices already provided and that I concur with, I'd suggest to strengthen QA with automatic, repeatable tests. Investing in automation will allow you to be more confident when changing already deployed code.
Create regression suites for the new features at the same time as you implement them.
QA can use exploratory testing as an alternative to find holes in your development process.
我认为敏捷的两个最有价值且易于实施的方面是
限时迭代 - 将项目分解为两到三周的周期，迫使您在合理的截止日期内实现可管理的目标
I think the two most valuable and easy to implement aspects of Agile are
daily stand ups - have a brief daily meeting with the team to review status. Use the 3 questions. Avoid cross-talk, chatter, and bitching. Keep it quick and on on-point.
time-boxed iterations - breaking the project up into two or three week cycles forces you to work towards manageable goals on reasonable deadlines