Is your application internal or do you have an external customer? If a client is paying for your work on and support of the application, it may be difficult to get them to sign off on cards like the ones you suggest.
Also, with your second card idea, it might be hard to say what "Done" is.
A specific approach to your issue could be Defect Driven Testing - the idea is that when you get a bug report and estimate the card that says to fix it, see what test(s) you can add in at the same time that are similar but increase coverage.
And you don't specifically ask for technical details about how to get your project under test, but this book is very helpful once you start actually doing it:Working Effectively with Legacy Code
There should be a distinction between an engineering practice and technical debt. I view test driven development and automated testing as practices.
Having taken code assets that were built by waterfall teams, the assets did not have automated unit, functional or performance tests. When we assumed responsibility for the software asset, we trained the product owner in Agile and told them of the practices we would use.
Once we begin using the practices, we begin to identify technical debt. As technical debt was identified, technical story cards were written and placed on the product backlog by the product owner. The developer and testers estimated all work using the XP engineering practices (TDD, automated testing, pair programming etc.). Those practices identified fragility in the code via TDD, automated function and performance tests. In particular, a significant performance issue was identified via automated performance testing and profiling. The debt was so large that we estimated the fix to take 6 iterations. we informed the product owner that if new features were developed they would not be able to be used by the user base given the poor performance of the application. Given that we had to scale the app from a few hundred users to 10s of thousands of users, the product owner prioritzed the performance technical debt very high and we completed the technical cards in the iterations estimated.
Note: technical debt that can be fixed via refactoring within the estimate of a story card does not require a technical story card. Larger technical debt will. For technical debt that will require a technical card, identify the business impact and ask the product owner to prioritize the technical card. Then work the card. Don't create technical debt for engineering practices. Do all estimating knowing that the engineering practices will be part of the estimate. Do not create a card to retrofit the application with automated unit, functional and performance test. Instead, include the work only in the cards you are estimating and add the automated test to the code you touch via the cards being worked. This will enable the app to improve over time without bringing progress to a halt. Stopping the addition of all business cards should only be saved for the most drastic situation such as inability of the application to perform or scale.
Given the case where you inherit a code base without automated unit, functional and performance test, inform the business partner of the sad state of affairs. Let them know how you will estimate the work. Create technical debt as it is uncovered via the engineering practice. Finally, informed the product owner that the team's velocity will improve as more and more of the code base is touched with automated unit, functional and performance tests.
I work in an Agile environment, but where the current codebase had existed for several years before the agile techniques were adopted. This leads to having to try to work in an agile way, around code that was not written with automatic regression testing in mind.
Because the technical debt affects how quickly we can deliver new features, we record how much time was added due to working with the legacy code. This data allows us to make a case for time dedicated to paying off technical debt. So when the customer (be it manager, or CTO or whoever) thinks that estimates are too high you have data which can reinforce your position.
Of course occasionally, you find your estimates go over because of unexpected quirks of the legacy code where you had to pay off technical debt. We have found that as long as the extra time can be explained and accounted for, and a case can be made for the benefits of the extra time spent, it's generally accepted pretty well.
Of course, YMMV dependent on customer or other factors, but having statistics which represent the effect of technical debt going forward is very useful.
I think it's a good idea to ask how much longer the customer(s) expect to be using the application. If the application's lifespan is limited (say, three years or less) then it may not make sense to put much effort into refactoring. If the lifespan is expected (or hoped) to be longer, then the payback for refactoring becomes that much more attractive.
You might also want to try creating a business case for the investment in refactoring. Show specific examples of the kinds of improvements that you would want to make. Make an honest assessment of the costs, risks, and expected payback. Try to find a specific refactoring that you could implement independently of the others, and lobby for approval to make that change as a test run of the refactoring process.
Note that, when you talk about payback, you may be expected to provide specific numbers. It's not enough to say "it will be much easier to fix bugs." Instead, you should be prepared to say something like "We'll see a minimum 30% improvement in turnaround time for bug fixes", or "We will experience 40% fewer regressions." You should also be prepared to negotiate with management and/or customers so that you all agree that you have measurements that are meaningful to them, and to provide measurements from before and after the refactoring.
Reducing technical debt is something everyone should do, each time we submit code.
When you edit code, you tidy up a bit, like scouts before leaving a camping ground.
This way, code that changes often will be in better shape, which is good for business.
Code that never change won't improve, but then again why should it, if it works?
Don't schedule tasks for this, although a long-term plan is helpful, as is a forum to discuss issues.
Very large projects would benefit from some kind of locking scheme so that two coders don't refactor the same piece of code simultaneously without synchronizing.
发布评论
评论（5）
您的应用程序是内部应用程序还是有外部客户？ 如果客户为您的应用程序工作和支持付费，可能很难让他们在您建议的卡片上签字。
另外，对于你的第二张卡片的想法，可能很难说“完成”是什么。
解决您的问题的一种具体方法可能是缺陷驱动测试 - 这个想法是，当您收到错误报告并估计要修复它的卡片时，看看您可以同时添加哪些类似但不同的测试增加覆盖范围。
而且您不会专门询问有关如何测试项目的技术细节，但是一旦您开始实际进行测试，这本书就会非常有帮助：有效地使用旧代码
Is your application internal or do you have an external customer? If a client is paying for your work on and support of the application, it may be difficult to get them to sign off on cards like the ones you suggest.
Also, with your second card idea, it might be hard to say what "Done" is.
A specific approach to your issue could be Defect Driven Testing - the idea is that when you get a bug report and estimate the card that says to fix it, see what test(s) you can add in at the same time that are similar but increase coverage.
And you don't specifically ask for technical details about how to get your project under test, but this book is very helpful once you start actually doing it:Working Effectively with Legacy Code
工程实践和技术债务之间应该有所区别。 我将测试驱动开发和自动化测试视为实践。
采用瀑布团队构建的代码资产后，这些资产没有自动化的单元、功能或性能测试。 当我们承担软件资产的责任时，我们对产品负责人进行了敏捷培训，并告诉他们我们将使用的实践。
一旦我们开始使用这些实践，我们就开始识别技术债务。 确定技术债务后，产品负责人编写了技术故事卡并将其放置在产品待办事项列表中。 开发人员和测试人员使用 XP 工程实践（TDD、自动化测试、结对编程等）评估所有工作。 这些实践通过 TDD、自动化功能和性能测试识别了代码中的脆弱性。 特别是，通过自动化性能测试和分析发现了一个重要的性能问题。 债务如此之大，我们估计修复需要 6 次迭代。 我们通知产品所有者，如果开发了新功能，由于应用程序的性能较差，用户群将无法使用它们。 鉴于我们必须将应用程序从几百个用户扩展到数十万个用户，产品负责人将性能技术债务列为非常高的优先级，我们在估计的迭代中完成了技术卡。
注意：可以通过在故事卡的估计范围内进行重构来修复的技术债务不需要技术故事卡。 更大的技术债务将会。 对于需要技术卡的技术债务，确定业务影响并要求产品所有者优先考虑技术卡。 然后办卡。 不要为工程实践创造技术债务。 进行所有估算时都知道工程实践将成为估算的一部分。 不要创建卡来通过自动化单元、功能和性能测试来改造应用程序。 相反，仅将工作包含在您正在估计的卡片中，并将自动化测试添加到您通过正在工作的卡片接触的代码中。 这将使应用程序能够随着时间的推移不断改进，而不会导致进度停止。 仅应在最严重的情况下停止添加所有名片，例如应用程序无法执行或扩展。
如果您继承的代码库没有自动化的单元、功能和性能测试，请告知业务合作伙伴这种悲惨的情况。 让他们知道您将如何估算工作量。 通过工程实践发现技术债务。 最后，告知产品负责人，随着越来越多的代码库涉及自动化单元、功能和性能测试，团队的速度将会提高。
There should be a distinction between an engineering practice and technical debt. I view test driven development and automated testing as practices.
Having taken code assets that were built by waterfall teams, the assets did not have automated unit, functional or performance tests. When we assumed responsibility for the software asset, we trained the product owner in Agile and told them of the practices we would use.
Once we begin using the practices, we begin to identify technical debt. As technical debt was identified, technical story cards were written and placed on the product backlog by the product owner. The developer and testers estimated all work using the XP engineering practices (TDD, automated testing, pair programming etc.). Those practices identified fragility in the code via TDD, automated function and performance tests. In particular, a significant performance issue was identified via automated performance testing and profiling. The debt was so large that we estimated the fix to take 6 iterations. we informed the product owner that if new features were developed they would not be able to be used by the user base given the poor performance of the application. Given that we had to scale the app from a few hundred users to 10s of thousands of users, the product owner prioritzed the performance technical debt very high and we completed the technical cards in the iterations estimated.
Note: technical debt that can be fixed via refactoring within the estimate of a story card does not require a technical story card. Larger technical debt will. For technical debt that will require a technical card, identify the business impact and ask the product owner to prioritize the technical card. Then work the card. Don't create technical debt for engineering practices. Do all estimating knowing that the engineering practices will be part of the estimate. Do not create a card to retrofit the application with automated unit, functional and performance test. Instead, include the work only in the cards you are estimating and add the automated test to the code you touch via the cards being worked. This will enable the app to improve over time without bringing progress to a halt. Stopping the addition of all business cards should only be saved for the most drastic situation such as inability of the application to perform or scale.
Given the case where you inherit a code base without automated unit, functional and performance test, inform the business partner of the sad state of affairs. Let them know how you will estimate the work. Create technical debt as it is uncovered via the engineering practice. Finally, informed the product owner that the team's velocity will improve as more and more of the code base is touched with automated unit, functional and performance tests.
我在敏捷环境中工作，但在采用敏捷技术之前，当前的代码库已经存在了好几年。 这导致必须尝试以敏捷的方式工作，围绕未考虑到自动回归测试的代码进行工作。
由于技术债务影响我们交付新功能的速度，因此我们记录了由于使用遗留代码而增加的时间。 这些数据使我们能够花时间专门偿还技术债务。 因此，当客户（无论是经理、首席技术官还是其他人）认为估算过高时，您就有了可以巩固您地位的数据。
当然，有时您会发现您的估计超出了预期，因为遗留代码出现了意外的怪癖，您必须还清技术债务。 我们发现，只要能够对额外的时间进行解释和解释，并且能够证明额外时间所花费的好处，那么它就会被普遍接受。
当然，YMMV 取决于客户或其他因素，但拥有代表技术债务未来影响的统计数据非常有用。
I work in an Agile environment, but where the current codebase had existed for several years before the agile techniques were adopted. This leads to having to try to work in an agile way, around code that was not written with automatic regression testing in mind.
Because the technical debt affects how quickly we can deliver new features, we record how much time was added due to working with the legacy code. This data allows us to make a case for time dedicated to paying off technical debt. So when the customer (be it manager, or CTO or whoever) thinks that estimates are too high you have data which can reinforce your position.
Of course occasionally, you find your estimates go over because of unexpected quirks of the legacy code where you had to pay off technical debt. We have found that as long as the extra time can be explained and accounted for, and a case can be made for the benefits of the extra time spent, it's generally accepted pretty well.
Of course, YMMV dependent on customer or other factors, but having statistics which represent the effect of technical debt going forward is very useful.
我认为询问客户预计使用该应用程序的时间是个好主意。 如果应用程序的生命周期有限（例如，三年或更短），那么投入太多精力进行重构可能没有意义。 如果预期（或希望）寿命更长，那么重构的回报就会变得更具吸引力。
您可能还想尝试为重构投资创建一个业务案例。 展示您想要进行的改进类型的具体示例。 对成本、风险和预期回报进行诚实的评估。 尝试找到一个可以独立于其他重构实现的特定重构，并游说批准进行该更改作为重构过程的测试运行。
请注意，当您谈论投资回报时，您可能需要提供具体的数字。 仅仅说“修复错误会容易得多”是不够的。 相反，您应该准备好这样说：“我们将看到错误修复的周转时间至少缩短 30%”，或者“我们将减少 40% 的回归”。 您还应该准备好与管理层和/或客户进行谈判，以便大家都同意您的测量对他们有意义，并提供重构之前和之后的测量。
I think it's a good idea to ask how much longer the customer(s) expect to be using the application. If the application's lifespan is limited (say, three years or less) then it may not make sense to put much effort into refactoring. If the lifespan is expected (or hoped) to be longer, then the payback for refactoring becomes that much more attractive.
You might also want to try creating a business case for the investment in refactoring. Show specific examples of the kinds of improvements that you would want to make. Make an honest assessment of the costs, risks, and expected payback. Try to find a specific refactoring that you could implement independently of the others, and lobby for approval to make that change as a test run of the refactoring process.
Note that, when you talk about payback, you may be expected to provide specific numbers. It's not enough to say "it will be much easier to fix bugs." Instead, you should be prepared to say something like "We'll see a minimum 30% improvement in turnaround time for bug fixes", or "We will experience 40% fewer regressions." You should also be prepared to negotiate with management and/or customers so that you all agree that you have measurements that are meaningful to them, and to provide measurements from before and after the refactoring.
减少技术债务是每个人每次提交代码时都应该做的事情。
当你编辑代码时，你会稍微整理一下，就像离开露营地之前的侦察兵一样。
这样，经常更改的代码将处于更好的状态，这对业务有利。
永不改变的代码不会得到改进，但话又说回来，如果它有效的话，为什么要改进呢？
不要为此安排任务，尽管长期计划和讨论问题的论坛很有帮助。
非常大的项目将受益于某种锁定方案，这样两个编码人员就不会在不同步的情况下同时重构同一段代码。
/罗杰
Reducing technical debt is something everyone should do, each time we submit code.
When you edit code, you tidy up a bit, like scouts before leaving a camping ground.
This way, code that changes often will be in better shape, which is good for business.
Code that never change won't improve, but then again why should it, if it works?
Don't schedule tasks for this, although a long-term plan is helpful, as is a forum to discuss issues.
Very large projects would benefit from some kind of locking scheme so that two coders don't refactor the same piece of code simultaneously without synchronizing.
/Roger