What is Code Decay?
Code decay occurs when a software system becomes increasing difficult to maintain. The design and code of the system become more complex, making changes to the system becomes noticeably more difficult, more costly in time and resources, and more prone to regression errors. Code decay can result in a system that is more expensive to maintain because the number of errors introduced by a single change in the system (regression) steadily increases. In the worst case, a single change can – on average – introduce one or more regression errors into the system.

How Does Code Decay Occur?
Code decay occurs simply by touching the code. The more code is touched – as measured by changes to the files where the code resides – the higher the amount of code decay. This is true on average across the collection of files. Code decay happens because code tends to increase in complexity the more it’s modified. Files that have been modified the most are usually the most complex, thus most likely to suffer from code decay.

How Can Maintenance Slow Down Code Decay?
Refactoring reduces code decay. Refactoring is a set of techniques for simplifying code without changing what it does.

Reference: IBM RUP for Maintenance

گزیده:
«تنها حریفی که در مقابل من پس از باخت، بهانه نمی آورد، کامپیوتر است.»
بابی فیشر قهرمان شطرنج

داشتم ارائه آقای مایک کوهن را در اینجا می‌دیدم.

A Reusable Scrum Presentation (An Introduction to Scrum)
This scrum presentation is a 90 minute introduction to Scrum that is fully redistributable and reusable. It can be used to introduce Scrum to your user group or organization.
This is a completely updated, much fancier version of this popular scrum presentation file that has been available for download since 2002.

توجهم جلب شد که ارائه به زبانهای مختلف ترجمه شده است و درسایت ایشان قرار گرفته است.

با خود گفتم چه خوب خواهد شد اگر بتوانم این ارائه را به کمک دوستان و عزیزانم به فارسی ترجمه و به این فهرست اضافه کنم. هم فال خواهد بود و هم تماشا.

پس شروع کردم!

در کنار همه مزیت‌ها، این گونه کارها، وقتهایی را که نمی‌توان به کارهای دیگری اختصاص داد (رفت و آمد، انتظارهای قبل از جلسات، …) را پربار می‌کنند.

گزیده:
«به خاطر داشته باش که فقط یک «زمان» از همهٔ وقت‌های دیگر مهم‌تر است و آن «هم‌اکنون» است.» لئو تولستوی

ارتباط و تعامل بین افراد یکی از ارزشهای متدهای چابک است. بسیاری از اقدامات (Practice) این متدها نیز بر این اساس، پایه‌گذاری شده است.
ارتباط و تعامل یکی از مهم‌ترین چالشهایی است که در پذیرش و استقرار متدهای چابک در تیمها، با آن روبرو خواهید شد.

برنامه‌نویسی دونفر یا Pair Programming از جمله اقداماتی است که این چالش در آن پررنگ است. در این اقدام، یک نفر نقش راننده (driver) و نفر دوم، نقش هدایتگر(navigator) را بر عهده می‌گیرد. صفحه کلید در اختیار راننده است که کد را می‌نویسد و وظیفه نفر دوم بازنگری، پایش طراحی و پیدا کردن خطاها است.

بروکس در دهه 1950، کونستانتین در دهه 1990 و فارسر در OOPSLA سال 94 به آن اشاره کرده‌اند. اما شهرت آن به سال 1999 با کتاب XP Explained از کنت بک و سایرین برمی‌گردد.

نکته جالب توجه این است که این تکنیک می‌تواند در تیم‌های غیرچابک نیز اجرا گردد.

به تازگی مقاله‌ای در وال استریت جورنال چاپ شده است که به نکات جالبی از مؤفقیت، شکست و دردسرهای این تکنیک اشاره کرده است. همچنین خاطراتی از کنت بک و کانینگهام را در انجام برنامه‌نویسی دو نفره در خود دارد. این مقاله تأکیدی است بر این که در کنار کارایی فوق‌العاده این اقدام، به‌کارگیری آن ساده نخواهد بود، حتی در شرکتهای آمریکایی.

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

“People who have been pairing a while, they’ll start acting like old married couples,” said Marc Phillips.

مقاله را می‌توانید اینجا مطالعه کنید.
گزیده:

“A good programmer is someone who looks both ways before crossing a one-way street. “
– Anonymous

تازه‌کار: سلام
چابک: سلام. چهره‌ات نشان از سردرگمی دارد. می‌توانم کمک کنم؟

تازه‌کار: حق با شماست. بعد از توضیحات شما در مورد چابکی، بیش از پیش دچار ابهام شده‌ام.
چابک: ابهام چیز ناخوشایندی نیست. کدام بخش برایت مبهم است؟

تازه‌کار: چرایی متدهای چابک. یعنی فلسفه به وجود آمدن متدهای چابک و ارتباط آن با ایجاد نرم‌افزار
چابک: اجازه بدهید ابتدا کمی تاریخ برایتان بگویم.
متدهای اسکرام و دی‌اس‌دی‌ام قبل از متد اکس‌پی ارائه شده بودند. اولی چارچوبی برای مدیریت پروژه و دومی، متدی برای ایجاد سیستمهای کسب‌وکاری(business). ارائه اکس‌پی توسط کنت بک و دوستانش، نقطه عطفی بود بر این گونه متدها. به دلایل متعدد از جمله ارائه‌دهندگان اکس‌پی و تولد آن از دنیای توسعه‌دهندگان و برنامه‌نویسان، این متد با اقبال بسیاری روبرو شد، موج و حرکت جدیدی را به وجود آورد که تا به امروز نیز ادامه دارد.

تازه‌کار: نام چابک از کجا آمد؟
چابک: پس از مدتی چند تن از پیشروان این پارادایم، به دعوت باب مارتین (رابرت سی مارتین معروف به عمو باب) در جایی جمع شدند. هدف اصلی گردهمایی این بود که بین متدهای سبک شامل Adaptive Software Development, XP, Scrum, Crystal, Feature-Driven Development, Dynamic System Development Method (DSDM), and “pragmatic programming.” مشابهتی وجود دارد یا خیر.

یکی از نتایج گردهمایی، نامگذاری این گونه از متدها بود. در آن گردهمایی مجموعه‌ای از اسامی پیشنهاد شد و پس از مراحلی، بین دو نام چابک (agile) و سازگار (adaptive) رای به چابک داده شد، هر چند عنوان دوم در بسیاری از مراجع و حتی توسط بسیاری از پیشروان این متدها هنوز به کار برده می‌شود.

تازه‌کار: آِیا گردهمایی فقط منجر به انتخاب عنوان متدها شد؟
البته که خیر.
شرکت‌کنندگان گردهمایی در مورد چند موضوع اتفاق نظر داشتند:
– در سطح اول، بر سر ضرورت پاسخ‌گویی مناسب به تغییرات
– در سطح دوم، بر سر چهار ارزش اصلی (Value)
– در سطح سوم ( و به دشواری) ، بر سر دوازده بند و اصل همخوان با ارزشهای چهارگانه(Principle)

سطوح دوم و سوم به صورت بیانیه‌ای (Agile Manifest) صادر و توسط این افزاد امضاء شد. این افراد پس از آن، Agile Alliance را نیز پایه‌گذاری کردند.

تازه‌کار: خوب، پس هدف اصلی متدهای چابک، پذیرش تغییرات و اعمال مناسب آنهاست.
چابک: البته. اما این موضوع، همه فلسفه چابک را در بر نمی‌گیرد.
در دهه گذشته، حرکت به سوی متدهای چابک سرعت روزافزونی به خود گرفته است. در این سالها، واضعان این متدها با تفکرات متفاوت اما همگرا و با تکیه بر تجربه­های مؤفق نشان دادند که اجرای این متدها تأثیر به­سزایی در بهبود چهار پارامتر بزرگ و مهم دارند: کارایی، کیفیت، روحیه افراد و زمان ورود به بازار.

هدف اصلی متدهای چابک تحویل سریع­تر نرم­افزار و کسب اطمینان از پوشش نیازهای در حال تغییر مشتری است. بطور کلی این متدها بر چهار موضوع انسانها و تعاملات بین آنها، پذیرش تغییرات نیازمندی­ها، تحویل زود به زود نرم­افزار قابل استفاده و همکاری نزدیک مشتری و توسعه­دهندگان تأکید دارند.

تازه‌کار: خوب، پس از فردا شروع می‌کنم به چابک‌کار شدن و مدیرانم را نیز تشویق می‌کنم به چابک‌کاری.
چابک: صبر کن. به کجا چنین شتابان. چقدر زود احساساتی شدی. به قول دوستان «چرا جوگیر شدی؟».

تازه‌کار: مگر شما نگفتید که چابک خیلی خوب است.
چابک: چرا!
تازه‌کار: خوب. پس باید شروع کنیم.
چابک: حتماً ابتدا شروع می‌کنی یک بک‌لاگ محصول می‌نویسی،..، بعد هم تکرارهای ماهانه (اسپرینت) خواهی داشت، جلسات ایستاده روزانه برگزار می‌کنی؟

تازه‌کار: شما از کجا فهمیدید؟
چابک: چون ساده‌ترین بخش کار، همین مواردی است که شما می‌خواهید انجام دهید. خیلی از کسانی که می‌شناسم به همین گونه شروع کرده‌اند و بعد «عشق آسان نمود اول، ولی افتاد مشکل‌ها»

بگذارید آماری را خدمت شما ارائه دهم. مؤسسه Standish Group در گزارش سال 2011 خود، اعلام کرده است که:
9 درصد پروژه‌های چابک شکست خورده‌اند.
49 درصد …. دچار چالش بوده‌اند.
42 درصد …. با مؤفقیت پایان یافته‌اند.

این آمار به این معنی است که با وجود مؤفقیت متدهای چابک، 58 درصد پروژه‌ها دچار مشکل هستند. به عبارت ساده‌تر اجرای متدهای چابک حتی به بهترین شیوه آن، به معنی واکسینه شدن در مقابل خطرات و ریسکهای پروژه‌ها نیست.

تازه‌کار: پس چه کار کنم؟
چابک: به قول یکی از دوستان «درست که من جو می‌دهم، ولی شما که نباید جو گیر شوی». بداجرا کردن، بددفاع کردن از یک موضوع، از دشمنی با آن فاجعه‌بارتر است.
اجازه بدهید کمی بیشتر درباره ابعاد قضیه با هم صحبت کنیم و بعد، ایده‌هایمان را با هم اجرا می‌کنیم.

تازه‌کار: بسیار خوب.
چابک: بقیه‌اش باشد برای بعد. تعطیلات خوش بگذرد.
تازه‌کار: به شما هم همینطور.

مراجع:
سیلابس دوره متدهای چابک (Agile Methods)
Agile Software Development: The Cooperative Game, 2^nd, Alistair Cockburn
Standish Group, CHAOS Report, 2011

گزیده:

Agile methods derive much of their agility by relying on the tacit knowledge embodied in the team, rather than writing the knowleadge down in plans.
Barry Boehm

Code is often refactored to simplify it and make it easier to maintain. A similar activity can be taken to clean up the requirements. Like code refactoring, refactoring requirements does not increase the number of features or fix bugs. The intent is to reduce complexity and ambiguity in the requirements so they are easier to manage and to improve the ability of the team to support and maintain the system.

When refactoring requirements look for duplicate requirements, ambiguous requirements, requirements that are difficult to test, and requirements that appear to contradict other requirements. This is also a good time to re-examine the Requirements Management Plan to see what should be added or removed. There may be attributes that track information the team doesn’t use, or traces between requirements that are never examined. Each item in a Requirements Management Plan requires overhead to maintain, so if it’s no longer needed it should be removed. Conversely, there may be some difficulties the team has had in managing requirements. This is a good time to add appropriate attributes, traces, or activities that will better support the environment.
Reference: IBM Rational Unified Process

Quote:
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superflouus.
Martin Fowler

Software engineering is gravely hampered by immature practices. Specific problems include: The prevalence of fads more typical of the fashion industry than an engineering discipline; a huge number of methods and method variants, with differences little understood and artificially magnified; the lack of credible experimental evaluation and validation; and the split between industry practice and academic research.

At the root of the problems we lack a sound, widely accepted theoretical basis. A prime example of such a basis is Maxwell’s equations in electrical engineering. It is difficult to fathom what electrical engineering would be today without those four concise equations. They are a great example to the statement “There is nothing so practical as a good theory”. In software engineering we have nothing similar, and there is widespread doubt whether it is needed. This talk will argue for the need of a basic theory in software engineering, a theory identifying its pure essence, its common ground or its kernel.

The Semat (Software Engineering Methods and Theory) community addresses this huge challenge. It supports a process to refound software engineering based on a kernel of widely-agreed elements, extensible for specific uses, addressing both technology and people issues. This kernel represents the essence of software engineering.
Reference: ASE 2012 Keynote, by Ivar Jacobson

Quote:
“I find that I am most happy and healthy when I am living in alignment with my goals, dreams, and principles.”
Steve Maraboli