احتمالاً یکی از پروژه‌های سال آینده‌ام، پروژه‌ی “به دنبال فی (Phi یا φ)” است. امیدوارم زود پیدایش کنم.

نظر آقای مایک کوهن درباره‌ی مستندسازی در تیم‌های چابک.

How Helpful Is Your Documentation

One of the myths I have to bust frequently is that agile teams avoid all documentation. That’s just not true. Agile teams value written documentation, but believe that most projects benefit from writing less.

So, agile teams try to shift from documents to discussion. Even so, most teams find that some documentation remains helpful and necessary. So the question becomes, how do you tell which documents are helpful and which are not?

One way is to schedule a documentation-review meeting with the team. Prepare by printing out all the documentation from your current (or a recent but similar) project. For very lengthy documents, feel free to print just the first section or even just the title page. The point of this exercise is to show how much written documentation was produced and, to a lesser degree, to show the proportions in which it was created.

Next, sort the documents into stacks based on type: technical design documents in one pile, requirements documents in another, end user documentation in another, and so on. Then ask the team to sort each stack from the most frequently used on one end of the table to documents that were never used once they written at the other end.

Expect to encounter debate as the team works through this. One team member will insist a document was useful; another will say it wasn’t. Encourage the discussion, steering it whenever possible to help uncover things the team might not otherwise know. Note any documents that were intended for one purpose but used for something different and documents that you thought were essential but were not used at all.

Once the documents are in priority order, discuss which documents are helpful (and should continue to be produced) and which are not (and could be eliminated).

Then, see if you can take it one step further. For each type of document the team has agreed to continue producing, ask the team to brainstorm alternatives that involve talking more and writing less.

Again, I’m not suggesting you eliminate useful or required documentation. The goal is merely to help a team shift from documents to discussions. Taking the steps I’ve just described should help your team do that.

And that will help you succeed with agile,

Mike

ترلو از جمله ابزارهایی است که بخشی از زندگی من را تشکیل می‌دهد. بدون ترلو تقریباً نظم کارهایم را از دست خواهم داد. دوست داشتم چند خطی درباره‌ی ترلو بنویسم. حالا این فرصت را پیدا کردم.

ترلو چیست؟

Trusted by millions of people from all over the world, Trello is the easy, free, flexible, and visual way to manage your projects and organize anything.

www.trello.com

ترلو را چه کسی به من معرفی کرد؟

ترلو را دو دوست نازنین، روح‌اله دل‌پاک و علیرضا اسماعیلی به من معرفی کردند. از این دو عزیزم بسیار سپاسگزارم.

خبر خوب برای من درباره‌ی ترلو

ایمیلی دریافت کردم که در آن گفته شده بود ترلو توسط شرکت اتلسیان خریداری شد.

We’re excited to announce that Trello is being acquired by Atlassian.

We launched Trello five years ago to make it easy and fun to collaborate in a unique way. Since then, more than 19 million people have used Trello to solve many different challenges both personal and professional.

Atlassian has a great track record making excellent collaboration tools like JIRA, Confluence, HipChat and BitBucket. Both the Trellists and the Atlassians share a passion for helping teams work better together.

گزیده:

With self-discipline most anything is possible.

Theodore Roosevelt

دیروز پنج‌شنبه دوازدهم اسفند هزار و سیصد و نود و پنج، به خاطر چاپ جلد دوم کتاب با دوستان مترجم و عزیزم، و خانواده‌هایمان دور هم جمع شدیم. روز خوبی بود و خیلی هم خوش گذشت.

جای شما خالی!

گزیده:

ویتو:‌ وقت صرف خانوادَت می‌کنی؟

جانی فانتین: البته که می‌کنم.

ویتو: خوبه. چون مردی که وقت صرف خانوادَش نمی‌کنه،‌ هیچ وقت نمی‌تونه یه مرد واقعی باشه.

مرجع: پنجاه دیالوگ برگزیده سه‌گانه پدرخوانده

“Technical debt, yes we have some of this, but what can we do…?” Here’s a few ideas to get you started:

1) 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.

2) Create a category “TechDebt” in your issue tracking system, distinct from defects, or new features. Point at the specific artifacts involved.

3) 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.

4) 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).

5) 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.

6) Organize small 1-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.

7) 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.

8) 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.

9) 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.

10) 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.

11) Acquire and deploy a tool that will give you hints about structural issues in your code: dependency analysis.

12) 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.”)

13) If you are actively managing risks, consider bringing some major tech debt items in your list of risks.

Reference: Philippe Kruchten, 2017

Here are some of the strategies that DAD promotes when it pertains to technical debt:

1. 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.
2. 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.
3. 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.
4. 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).
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.

Reference:

Scott Ambler. 11 Strategies for Dealing With Technical Debt