شرکت مشاورین مبنا
“Technical debt, yes we have some of this, but what can we do…?” Here’s a few ideas to get you started:
۱) Organize a lunch-and-learn with your team to introduce the concept of technical debt. Illustrate it with examples from your own projects, if possible.
۲) Create a category “TechDebt” in your issue tracking system, distinct from defects, or new features. Point at the specific artifacts involved.
۳) Standardize on one single form of “Fix me” or “Fix me later” comment in the source code to mark places that should be revised and improved later. They will be easier to spot with a tool.
۴) Acquire and deploy in your development environment a static code analyser to detect code-level “code smells”. (Do not panic in front of the large number of positive warnings).
۵) Prioritize technical debt items to fix or refactor, by doing them first in the parts of your code that are the most actively modified, leaving aside or for later the parts that are never touched.
۶) Organize small ۱-hour brainstorming sessions around the question: “What design decision did we make in the past that we regret now because it is costing us much?” or “If we had to do it again, what should have we done?” This is not a blame game, or a whining session; just identify high level structural issues, the key design decisions from the past that have turned to technical debt today.
۷) For identified tech debt items, give not only estimates of the cost to “reimburse” them or refactor them (in staff effort), but also estimate of the cost to not reimburse them: how much it drags the progress now. At least describe qualitatively the impact on productivity or quality. This can be assisted by tools from your development environment, to look at code churn, and effort spent.
۸) At each development cycle, try to constantly reduce some of the technical debt by explicitly bringing some tech debt items into your iteration or sprint backlog.
۹) Refine in your issue tracker the TechDebt category into at least 2 subcategories: simple, localized, code-level debt, and wide ranging, structural or architectural debt.
۱۰) For your major kinds of technical debt, identify the root cause –schedule pressure, process or lack of process, people availability or turn over, knowledge or lack of knowledge, tool or lack of tool, change of strategy or objectives– and plan specific actions to address these root causes, or mitigate their effect.
۱۱) Acquire and deploy a tool that will give you hints about structural issues in your code: dependency analysis.
۱۲) Develop an approach for systematic regression testing, so that fixing technical debt items does not run you in the risk of breaking the code. (Counter the “It is not really broken, so I won’t fix it.”)
۱۳) If you are actively managing risks, consider bringing some major tech debt items in your list of risks.
Reference: Philippe Kruchten, ۲۰۱۷
Here are some of the strategies that DAD promotes when it pertains to technical debt:
- Do a bit of up front thinking. One of the process goals of DAD is Identify an Initial Technical Strategy. By thinking through critical technical issues before you implement your solution you have the opportunity to avoid a technical strategy which needs to be reworked at a future date. The most effective way to deal with technical debt is to avoid it in the first place.
- Have an explicit architecture owner. The Architecture Owner (AO) on a disciplined agile team is responsible for guiding the team through technical decisions, particularly those at the architecture level. AOs often mentor other team members in design skills, skills that should help them to avoid injecting new technical debt into the environment. They should also be on the lookout for existing technical debt and where appropriate motivate the team to address that technical debt when appropriate.
- Be enterprise aware. Disciplined agile teams are enterprise aware, realizing that what they do should leverage and enhance the overall organizational ecosystem. They will work close with your enterprise architecture and reuse/asset teams, if you have such, so that they can take advantage of existing assets. Assets could include code, patterns, services, templates, guidelines, or anything else worthy of being reused.
An important strategy for avoiding technical debt is to reuse existing assets and not rebuild or rebuy something that you already have.
- Refactor technical debt away. DAD provides guidance for when to apply several forms of refactoring, including code refactoring, database refactoring, and user interface (UI) refactoring. Refactorings are typically very small, such as renaming an operation or splitting a database column, so should just be part of everyday development. Rework, on the other hand, is more substantive and should be explicitly planned. The Architecture owner will often negotiate rework-oriented work items with the Product Owner (the person on the team who is responsible for prioritizing the work).
- Regression test continuously. One of the easiest ways to find problems in your work is to have a comprehensive regression test suite that is run regularly. This test suite will help you detect when defects are injected into your code, enabling you to fix them, or back out the changes, right away.
- Automate code/schema analysis. There are many tools available for assessing the quality of your code and even your database schema. Disciplined agile teams will include the use of these tools in their continuous integration (CI) strategy. Knowing where your technical debt exists is the first step in removing it.
- Measure technical debt. Organizations that are serious about technical debt measure it, something that code/schema analysis tools help with, and more importantly keep an eye on the trends (which should be going down over time). You may choose to track code quality metrics, data quality metrics, usability metrics, time to address defects, time to add features, and many other things.
- Explicitly govern technical debt. Several of the previous strategies require investment that some organizations wouldn’t normally consider to be part of the mandate of a delivery team. For your organization to succeed at reducing technical debt it must be governed, albeit in an agile fashion. This means it needs to be understood by senior management, measured (see previous point), and funded. The DAD framework includes explicit guidance around how to govern agile teams effectively.
- Reducing technical debt should be part of your culture. Technical debt isn’t going to fix itself, and worse yet will accrue “interest” over time in the form of slower and more expensive evolution of your existing assets.
- Address technical debt before handing over an asset. Passing systems with high technical debt to other teams, such as a sustainment team or maintenance group is generally a bad practice. It should be ingrained in your culture that each team is responsible for keeping the quality of their solutions high. It is reasonable to expect maintenance groups to resist accepting systems that have high technical debt.
- Accept some technical debt. Sometimes you will decide to explicitly accept some short term technical debt for tactical reasons. Perhaps you need to get something developed quickly because you are running a market experiment (a la Lean Startup). Perhaps there is a new component or framework about to be delivered by another group in your organization, so you’re writing a small portion of what you need for now until you can replace it with the more robust asset. Regardless of the reason, part of the decision to accept technical debt is to also accept the need to pay it down at some point in the future. Having good regression testing assets in place assures that refactoring accepted technical debt in the future can be done with low risk.
Scott Ambler. ۱۱ Strategies for Dealing With Technical Debt
New tech spawns new anxieties, says scientist and philosopher Grady Booch, but we don’t need to be afraid an all-powerful, unfeeling AI. Booch allays our worst (sci-fi induced) fears about superintelligent computers by explaining how we’ll teach, not program, them to share our human values. Rather than worry about an unlikely existential threat, he urges us to consider how artificial intelligence will enhance human life.
About Grady Booch:
Booch served as Chief Scientist of Rational Software Corporation since its founding in 1981 and through its acquisition by IBM in 2003, where he kept working until March, 2008. Afterwards he became Chief Scientist, Software Engineering in IBM Research, and series editor for Benjamin Cummings.
Booch has devoted his life’s work to improving the art and the science of software development. In the 1980s, Booch wrote one of the more popular books on programming in Ada. Grady Booch is best known for developing the Unified Modeling Language with Ivar Jacobson and James Rumbaugh in the 1990s.
Grady Booch published several articles and books. A selection:
* Software Engineering with Ada.
* Object Solutions: Managing the Object-Oriented Project.
* The Unified Software Development Process. With Ivar Jacobson and James Rumbaugh.
* The Complete UML Training Course. With James Rumbaugh and Ivar Jacobson.
* The Unified Modeling Language Reference Manual, Second Edition. With James Rumbaugh and Ivar Jacobson.
* The Unified Modeling Language User Guide, Second Edition. With James Rumbaugh and Ivar Jacobson.
* Object-Oriented Analysis and Design with Applications.
از مقدمه جلد دوم کتاب «اصول و روش کاربردی اسکرام»:
“این کتاب به مرد بزرگی تقدیم شده است که زحمات خالصانه، بدون چشمداشت و بزرگوارانهی ایشان برای انفورماتیک ایران بر کسی پوشیده نیست. هر چند نیک میدانیم که «برگ سبزی است تحفهی درویش» اما «چه کند بینوا، ندارد بیش». امیدواریم این کار باعث شود که نسل جوان جامعهی نرمافزاری ما با ایشان بیشتر آشنا شوند و قدردان زحمات ایشان باشند. برای «استاد ابراهیم نقیبزاده مشایخ» تندرستی و سرافرازی آرزومندم.”
هفتهی گذشته فرصتی شد تا به همراه تیم ترجمه به دیدار استاد گرانقدر، استاد ابراهیم نقیبزاده مشایخ برویم و “برگ سبز″مان را تقدیم این انسان فرهیخته نماییم.
جای شما خالی بود.
باخبر شدم که جلد دوم کتاب “اصول و روش کاربردی اسکرام” توسط انتشارات اشراقی در اختیار علاقهمندان قرار گرفته است. پس از ماهها تلاش جانانه در کنار یک تیم سه نفره، از شنیدن این خبر در پوست خود نمیگنجم. خوشحالم که یکی دیگر از برنامههایم به سرانجام رسید.
نقشم در تیم ترجمه، مانع از آن است که بتوانم آن طور که شایستهی این کتاب وزین است دربارهاش بنویسم و فقط به این جملهی مارتین دِووس بسنده میکنم که «به نظر من کِنی روبین موفق شده است تا کتابی بنویسد که هر کسی که با توسعهی اسکرام سر و کار دارد باید آن را بخواند! او هر چیزی که لازم است شما دربارهی اسکرام بدانید و حتی فراتر از آن را نیز در این کتاب ارائه کرده است.»
با توجه به موضوعات بررسیشده در جلد دوم، شک ندارم که این کتاب، راهنما و راهگشای بسیاری از تیمها و شرکتهای ایرانی خواهد بود.
بار دیگر از عزیزانم علیرضا اسماعیلی، مریم معصومیراد، یاسر کازرونی سپاسگزارم و برای آنها بهترینها را آرزومندم.
آدرس سفارش کتاب:
* انتشارات اشراقی، سفارش آنلاین؛ آدرس: خیابان انقلاب، مقابل دبیرخانه دانشگاه تهران، نبش خیابان اردیبهشت، بازارچه کتاب، پلاک ۶، ۶۶۴۰۸۴۸۷
* شهر کتاب آنلاین، سفارش آنلاین.