你跟踪任何你必须在问题中稍后“完善”的内容跟踪器或将 TODO 留在源代码中 - 并在用例运行后仔细检查这些
用例 用例并不是那么“未经打磨”，以至于客户不能/不会给您提供有用的反馈
As I understand it, the Tracer Bullet method has two main goals
address fundamental problems as soon as possible
give the client a useful result as soon as possible
Your motivation in not "polishing" each use case is probably to speed up 2. further. The question is whether in doing so you endanger 1. and whether the client is actually interested in "unpolished" results. Even if not, there's certainly an advantage in beng able to get feedback from the client quickly.
I'd say your idea is OK as long as
You make sure that there aren't any fundamental problems hiding in the "unpolished" parts - this could definitely happen with error handling
You track anything you have to "polish" later in an issue tracker or by leaving TODOs in the source code - and carefully go through those once the use cases are working
The use cases are not so "unpolished" that the client can't/won't give you useful feedback on them
If you take approach #1, you will have 90% of the functionality working pretty quickly. However, your client will also think you are 90% done and will wonder why it is taking you 9 times as long to finish the job.
If you take approach #1 then I would call that nothing more than a prototype and treat it that way. To represent it as anything more than that will lead to nothing but problems later on. Happy day scenarios are only 10% of the job. The remaining 90% is getting the other scenarios to work and the happy day scenario to work reliably. It is very hard to get non-developers to believe that. I usually do something between #1 & #2. I attempt to do a fairly good job of identifying use-cases and all scenarios. I then attempt to identify the most architecturally impacting scenarios and work on those.
I would suggest for Tracer bullets you can use a combination of positive + negative test cases
Positive test cases(these will be mentioned in your user stories/feature documents/functional specifications)
Negative test cases(common negative scenarios that can be expected in a BAU scenario) (Rare business scenarios can be left out after careful consideration.)
These test cases were run using specflow to automate testing.
Inclusion of Common Negative scenarios in your test cases provides sufficient confidence that successive developments can be done using the underlying code.
发布评论
评论（3）
据我了解，Tracer Bullet 方法有两个主要目标
您不“抛光”每个用例的动机可能是为了进一步加快速度。 问题是这样做是否会危及 1. 以及客户是否真的对“未经修饰”的结果感兴趣。 即使没有，beng 能够快速获得客户的反馈肯定有一个优势。
我想说你的想法是可以的，只要
As I understand it, the Tracer Bullet method has two main goals
Your motivation in not "polishing" each use case is probably to speed up 2. further. The question is whether in doing so you endanger 1. and whether the client is actually interested in "unpolished" results. Even if not, there's certainly an advantage in beng able to get feedback from the client quickly.
I'd say your idea is OK as long as
如果您采用方法 1，90% 的功能将很快运行。 然而，您的客户也会认为您已经完成了 90%，并且会想知道为什么您需要花费 9 倍的时间才能完成工作。
如果您采用方法#1，那么我只会将其称为原型并以这种方式对待它。 如果将其表示为更多的东西，只会导致以后出现问题。 快乐的一天场景只占工作的 10%。 剩下的 90% 是让其他场景正常工作，让快乐的一天场景可靠地工作。 很难让非开发人员相信这一点。 我通常会在 #1 和 #1 之间做一些事情。 #2. 我尝试在识别用例和所有场景方面做得相当好。 然后，我尝试确定对架构影响最大的场景并致力于这些场景。
If you take approach #1, you will have 90% of the functionality working pretty quickly. However, your client will also think you are 90% done and will wonder why it is taking you 9 times as long to finish the job.
If you take approach #1 then I would call that nothing more than a prototype and treat it that way. To represent it as anything more than that will lead to nothing but problems later on. Happy day scenarios are only 10% of the job. The remaining 90% is getting the other scenarios to work and the happy day scenario to work reliably. It is very hard to get non-developers to believe that. I usually do something between #1 & #2. I attempt to do a fairly good job of identifying use-cases and all scenarios. I then attempt to identify the most architecturally impacting scenarios and work on those.
我建议对于 Tracer 项目符号，您可以使用正面 + 负面测试用例的组合
（经过仔细考虑后，可以忽略罕见的业务场景。）
这些测试用例是使用 Specflow 运行的，以实现自动化测试。
在测试用例中包含常见的负面场景可以提供足够的信心，表明可以使用底层代码完成后续开发。
在这里分享经验 http://softwarecookie.wordpress.com/2013/12/ 26/曳光弹/
I would suggest for Tracer bullets you can use a combination of positive + negative test cases
(Rare business scenarios can be left out after careful consideration.)
These test cases were run using specflow to automate testing.
Inclusion of Common Negative scenarios in your test cases provides sufficient confidence that successive developments can be done using the underlying code.
Sharing the experience here http://softwarecookie.wordpress.com/2013/12/26/tracer-bullet/