نویسنده: علیرضا اسماعیلی، مدیرعامل شرکت رویای سبز نرم افزارهای آینده (فیوسافت) و عضو تیم ترجمه کتاب اصول و روش کاربردی اسکرام

علیرضا اسماعیلی هستم. مدیر مجموعه‎ای که شاید یکی از مهمترین دغدغه‎هاشون، تولید محصول باکیفیت بوده. این قراریه که با هم گذاشتیم: محصول باکیفیت تولید می‎کنیم؛ محصولی که زیر اون رو امضا کنیم و همه‎ی مسئولیتش رو می‎پذیریم؛ هرچند در دوره‎های مختلف، تجربه‎های موفق و ناموفق زیادی داشته‎ایم.
به نظرم جا انداختن چنین ارزشی در تیم یا به اصطلاح فرهنگ‎سازی اون، نیازمند به‎کارگیری یکی از مهمترین تجربه‎های چابکه. Test Driven Development یا به اختصار TDD. برای اطلاعات بیشتر اینجا و اینجا رو که ببینید.

با دوست عزیزم آقای مهندس مسعود خاری مشورت کردم، آمازون را جستجو کردم و کتاب‎های مختلف تو این حوزه رو بررسی کردم تا به کتاب Professional Test Driven Development with C#: Developing Real World Applications with TDD از انتشارات راکس رسیدم.

کتابی که مفاهیم TDD رو به زبانی ساده بیان می‎کنه و در کنارش شما رو تا جزییات پیاده‎سازی همراهی می‎کنه. این کتاب به زبانی ساده نوشته شده و مرجع مفیدی برای برنامه نویساست. لذت خوندن این کتاب رو از دست ندید!
متأسفانه رویکردی که بیشتر افراد در برخورد با مطالب جدید در پیش می‎گیرند مراجعه به اینترنت و استفاده از مطالب جسته و گریخته است. به جد توصیه می‎کنم که برای یادگیری این موضوع به سراغ اینترنت نرید و از کتاب‎های معتبر استفاده کنید. در این مورد کتابی دیدم با عنوان «کم‌عمق‌ها – اینترنت با مغز ما چه می‌کند». این کتاب در سال 93 توسط آقای امیر سپهرام، ترجمه و توسط انتشارات مازیار به چاپ رسیده. برای اطلاعات بیشتر اینجا رو ببینید.

برای انتقال مفاهیم به همه‎ی اعضای تیم، مطالعه کتاب رو تو دستور کار تیم قرار دادیم. هر ماه دو فصل و آخر ماه یک آزمون کتبی به همراه آزمون عملی و انجام پروژه. این یادگیری حدود شش ماه طول کشید. مایلم نتیجه را از زبان چند نفر از اعضای تیم بشنوید:

مسیری جهت توسعه ی ماندگار وقابلیت نگهداری.
روشی که با آن از تغییرات نمی ترسیم.
روشی که با آن منبع باگ ها و مشکلات را به سرعت پیدا میکنیم.
زبانی است برای تعامل بهتر با کاربران غیر فنی و نیازمندهای عملیاتی.

آرین شمشیری، عضو تیم توسعه سیستم‌های مالی

با اینکه حرفای آرین شبیه به تبلیغاته ولی عین واقعیته.

توسعه مبتنی بر تست نه تنها یک روش، بلکه می‎تونیم بگیم یک تفکره. تفکری که منجر به بالا رفتن کیفیت کد و برنامه می‎شه و باعث می‎شه که در انتهای توسعه‎ی یک جزء کوچک یا یک ویژگی، از این موضوع اطمینان داشته باشیم که آن جزء یا ویژگی بطور کامل و صحیح وظیفه خودش رو در برنامه به انجام می رسونه و همچنین به یکپارچگی دائمی اجزای برنامه کمک بزرگی می‎کنه.

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

یکی از مزایایی که TDD به همراه می آورد این است که هر تکه از سیستم قابل اجرا بدون نیاز به کلیت سیستم است، هر تکه از سیستم آماده اجراست دقیقا وقتی شما بیشترین تمرکز و توجه را به چیزی که پیاده کردید دارید. یعنی نیاز نیست بخشهای دیگر کامل شوند تا شما از عملکرد تکه کدی که قبل تر نوشتید اطمینان پیدا کنید. شما در زمان کامل شدن یک ویژگی نمی‌توانید روی همه جزییات آن تسلط داشته باشید. امکان یافتن ، فهمیدن و حل کردن یک نقص در بین مجموعه ای از تکه های یک ویژگی بسیار دشوار تر از فهمیدن و حل کردن آن در یک تکه است!
به بیان دیگر به علت ظرفیت محدود ذهن انسان، هرچه مسئله یا اشکال یا قابلیت مورد نیاز سیستم، ساده تر و کوچک تر باشند ، امکان یافتن، فهمیدن و حل کردن اشکال یا توسعه قابلیت، با سرعت و کیفیت بالاتر همراه خواهد شد و در نهایت این تکه های با کیفیت و بررسی شده ، یک سیستم با کیفیت و بررسی شده را به وجود خواهند آورد.
و مهمترین حسی که این چنین سیستمی به من می دهد حس تسلط بر آن و تحت کنترل بودن اش در شرایط متفاوت است.
بر نیایم یک تنه با سه نفر
پس ببرمشان نخست از همدگر
هر یکی را من به سویی افکنم
چونک تنها شد سبیلش بر کنم

پیمان چیت‎ساز، مدیر پروژه فین‌تک

وقتی TDD رو بخونیم در اول می فهمیم سیستم بدون تست به فاجعه منجر می شه.
دوم اهمیت این موضوع که همه کار رو کنار بذاریم و اول از همه تست رو بنویسیم فوق‎العاده است واقعا کمکت می‌کنه به همون اندازه که نیازه کد بزنی و همین طور خیلی کمک می‌کنه ذهنمون منسجم‌تر, طراحی رو داخل همون تست ایجاد کنه.
سوم با تست خودکار و پیشروی برنامه اگر تست‌ها دقیق باشن با اضافه کردن هر ویژگی از تاثیر آن روی باقی قسمت ها با خبر می‌شیم.
در اخر هر هزینه‌ای برای نوشتن تست انجام دهیم در روند پروژه سرعت و دقتمان رو بالا می‌بره و هزینه انجام‌شده حتی بیشتر برگردانده می‌شود.

امیرمحمد قزوینی، عضو تیم توسعه سیستم‌های مالی

هنر نوشتن کد به میزان کافی برای کسب و کار، هنر وسیع اندیشیدن،

دقیقاً جمله «شروع کردن را متوقف کنید، تمام کردن را آغاز کنید» رو به معنای واقعی کلمه پیاده‎سازی می‎کنه چون باعث میشه صفر تا صد یک ویژگی کسب‎و ‎کار پیاده‎سازی بشه و از درستی‎شون اطمینان حاصل بشه.

ریحانه جعفری، عضو تیم توسعه BPMS

یکی از ارزش‌هایی که در کانبان نقش کلیدی دارد و برخی تجربه‌های کانبان براساس آن تدوین شده‌اند، «شفاف‌سازی» (Transparency) است و سه مورد از شش تجربه‌ی اصلی کانبان با این ارزش مرتبط هستند:
تجربه‌ی اصلی 1: تصویرسازی کنید (Visualize)
تجربه‌ی اصلی 4: سیاست‌ها را شفاف بیان کنید (Make policies explicit)
تجربه‌ی اصلی 5: حلقه‌های بازخورد را طراحی و پیاده‌سازی کنید (Implement feedback loops)

در بخش‌های بعد به ترتیب به این تجربه‌ها خواهیم پرداخت.

تصویرسازی کنید
کانبان واژه‌ای ژاپنی است و معادل آن «علامت تصویری» (Visual Sign) است. بنابراین تعجبی ندارد که پیاده‌سازی و اجرای آن این گونه شروع شود: یک تخته‌ی کانبان که به عنوان نوعی سیستم تصویرسازی برای مدیریت کارها استفاده می‌شود. دلیل تأکید کانبان بر استفاده از تکنیک‌های تصویرسازی در اجرای کار، تلاش برای مشهود کردن کارهای دانشی نامشهودی است که در تیم‌های نرم‌افزاری انجام می‌شود. کار دانشی، طبق تعریف، کاری است که طی آن داده‌ها و اطلاعات از شکلی به شکل دیگر تبدیل می‌شوند بنابراین نتیجه‌ی کار اغلب نامشهود و ناملوس است. کانبان سعی می‌کند با بردن این کارها روی تخته، به مشهود شدن آنها کمک کند و بر قابلیت رهگیری این کارها بیفزاید.

به این ترتیب، به راحتی و با یک نگاه می‌توانیم بفهمیم:

• چه کاری متوقف شده است؟
• هر فرد مشغول انجام چه کاری است؟
• چند نوع کار داریم و هر کدام چند درصد از کل کار است؟
• چه‌قدر کار داریم و هر کدام در چه مرحله‌ای است؟

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

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

به این ترتیب، یک حلقه‌ی تأثیرگذاری متقابل (Virtous Circle) شکل می‌گیرد:

• سیستم کانبان، کارها را سازماندهی می‌کند.
• افراد خودشان را بر مبنای کارها سازماندهی می‌کنند.
• بعد از مدتی این افراد با دیدگاه جدید خود می‌بینند که سیستم کانبان می‌تواند کارها را بهتر از وضعیت فعلی سازماندهی کند و در نتیجه آن را تغییر می‌دهند.

گزیده:
کانبان بهتر از اسکرام نیست، بلکه تنها از آن کوچکتر است.
هنریک نیبِرگ

بخش قبلی

بخش بعدی

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

مترجم‌ها: یاسر کازرونی، مریم معصومی‌راد

کار در جریان(ادامه)

آدام گفت: «بسیار خب، در مورد شما توسعه‌دهنده‌ها چه­‌طور؟ چه عددی برای شما مناسبه؟» و ماژیک را به سمت اریک پرتاب کرد که او هم فوراً آن را به دافنه داد.

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

اریک با اعتماد به نفس گفت: «به نظرم 4 قلم کاری. ما توی یه روز بیش‌تر از این کار انجام می‌دیم. از پسش برمی‌­یایم.»

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

بث گفت: «برای کار تحلیل، به نظرم سقف 2 قلم کاری منطقی باشه.» و عدد 2 را بدون معطلی بالای ستونش نوشت. به نظر می‌رسید که هچ کس اعتراضی به آن ندارد.

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

یوآخیم که کنار ایستاده بود و به نظر می‌­رسید از این­که به تیم اجازه داده تا خودش جواب رو بفهمد راضی است، گفت: «منظورت چیه؟»

فرانک گفت: «خب، ستون­های آماده‌ی انجام، پذیرش و در انتظار عملیات و غیره. نباید مثل بقیه عددهایی روی اون‌ها باشه؟»

مراکوس گفت: «اون‌ها هم می‌تونن. اما چرا؟ چه نفعی برای شما داره؟»

فرانک اعتراف کرد: «اِه، من فکر ‌کردم همه ستون­ها باید یه عدد داشته باشن.»

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

سزار در حالی‌که با خودش به آرامی حرف می‌­زد جلو رفت: «بذارید ببینم. محدود کردن آن ستون، 4 قلم به‌­معنی اینِ که اگه این ستون با چهار واحد کاری پر بشه…» کمی مکث کرد و عدد 4 را بالای ستون پذیرش نوشت.

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

مارکوس پیشنهاد کرد: «چه‌طوری می‌­تونید محدودیت را بردارید؟» بقیه ساکت بودند و سزار به فکر کردن ادامه داد.

«خب، من و بث قلم‌ها رو بررسی و پذیرش می‌­کنیم…»

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

آدام پرسید: «بسیار خب، پس چرا سقف1 قلم رو برای اون نداریم؟»

مارکوس گفت: «چون…» اما قبل از این­که بیش­تر توضیح بدهد، سزار وسط حرف او پرید.

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

بخش قبلی

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

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

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

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

گزیده:
کانبان چیزی است که در تلاش هستید تا از دست آن خلاص شوید، نه چیزی که به داشتن آن، افتخار کنید.
جفری لیکر

بخش بعدی

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

پیش‌گفتار:

متن زیر بخشهایی از گفتگوی آقای مسعود خاری است که در گروه تلگرامی «متدهای چابک» (Agile Methods) آمده است.

گفتگو:

در گروه پیشنهاد شد که دوستان با همفکری هم یک فهرست از کتابهای ضروری برای مطالعه‌ی تیم‌های چابک تهیه کنند.
موضوعاتی که تیم‌ها برای رسیدن به سرآمدی فنی (Technical Excellence) بایستی به صورت جدی و عمیق مطالعه کنند.

مسعود در پاسخ به این سوال که «کتاب‌های خوب طراحی شی‌ گرا کدام کتاب‌ها هستند» پنج کتاب را معرفی می‌کند:

“کتاب Design Patterns: Elements of Reusable Object-Oriented Software یا Gang of Four کتاب معروف الگوهای طراحی هست که خیلی عالیه. در ابتدا چند اصل طراحی رو بیان می‌کنه و به شرح بعضی مفاهیم شیءگرایی می‌پردازه و بعد شروع به معرفی الگوهای طراحی می‌کنه.

اما این کتاب در سال 1995 نوشته شده و متنش و ادبیاتش و اصطلاحاتش برای برنامه‌نویسان امروز کمی ناآشناست و کمی هم ثقیل هست. عمده‌ی برنامه‌نویسانی که در شرکت‌های امروزی می‌بینم، با متن این کتاب ارتباط برقرار نمی‌کنند. به علاوه بعد از گذشت بیش از 20 سال و طی تجربه، به نظر میاد بعضی الگوهای این کتاب چندان مفید نیستند و بعضی الگوهای مفید وجود دارند که در کتاب نیومدند. اما به هر حال اگر کسی عزم خودش رو جزم کنه که مطالعه‌اش در این زمینه رو عمیق کنه، به شدت توصیه میشه.”

“نسخه سوم کتاب Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development به معرفی روش‌های تحلیل و طراحی می‌پردازه و متدهای توسعه‌ی تکراری-افزایشی و به طور خاص UP رو معرفی می‌کنه و به شرح فازهای اون می‌پردازه، که راستش توصیه نمی‌کنم که درگیرش بشید. 🙂 به نظرم چندان مفید نیستند. اما غیر از فرایندها، فصل‌هایی از کتاب به معرفی اصول و پترن‌های طراحی شیءگرا می‌پردازه که خیلی خوبه.

به طور خاص در فصل 17 به معرفی اصول طراحی GRASP می‌پردازه که در عین ساده به‌نظررسیدن، به نظرم خیلی مهم و پایه‌ای و مفید هستند. در بخش‌های بعد از اون هم در مورد شیءگرایی صحبت می‌کنه.

نسخه‌ی اول این کتاب در سال 1995 نوشته شده. ویرایش سومش مربوط به سال 2004 هست که سعی شده بخش‌های فرایندی کتاب با مفاهیم روز (به خصوص چابکی) به‌روز بشه. اما همون‌طور که اشاره کردم، به نظرم چندان در این کار موفق نبوده.”

“کتاب معروف Refactoring: Improving the Design of Existing Code آقای فولر که نیازی به توضیح نداره. خیلی از الگوهای ریفکتورینگ بر مبنای اصول طراحی شیءگرا هستند.

“کتاب معروف Domain-Driven Design: Tackling Complexity in the Heart of Software آقای اوانس که عالی است. و برای کسانی که بعد از مسلط‌شدن به مفاهیم شیءگرایی، بخوان با مفاهیم پیشرفته‌تر آشنا بشن خیلی خوبه. اما برای کسی که بک‌گراند شیءگرایی نداشته باشه مناسب نیست.”

“کتاب Analysis Patterns; Reusable Object Models فاولر، که به روش‌های تحلیل حوزه‌ی مسئله، با استفاده از مفاهیم طراحی شیءگرا می‌پردازه و بی‌اندازه عالی و عمیق هست. اما کتاب در سال 1996 نوشته شده، یعنی قبل از این که UML استاندارد بشه 🙂 و متاسفانه نمودارهای کتاب با نمادهای عجیب و غریب دوره‌ی قبل از UML ترسیم شده که کمی خوندن کتاب رو دشوار می‌کنه.”

در ادامه مسعود به معرفی کتابهایی در حوزه‌ی سرآمدی فنی می پردازد:

“ویرایش دوم کتاب Extreme Programming Explained: Embrace Change که به معرفی متد چابک خودش یعنی XP یا همون Extreme Programming می‌پردازه. یکی از بهترین کتاب‌هایی هست که خوندم.

از نقاط قوت متد اکس‌پی اینه که نه تنها فرایندهای مدیریتی، بلکه پرکتیس‌های مهندسی لازمه‌ی چابکی رو به خوبی پوشش میده (مثلاً تست و TDD و CI و غیره) که بدون اون‌ها، اجرای فرایندهایی مثل ایتریشن و جلسات روزانه به تنهایی موجب چابکی تیم نمیشه. خیلی از پرکتیس‌هایی که توسط اکس‌پی معرفی شدند باعث ایجاد انقلابی در نحوه‌ی توسعه‌ی نرم‌افزار شده و هنوز پابرجا هستند.

اما از نقاط قوت کتاب (یا شاید باز هم متد اکس‌پی) اینه که پرکتیس‌های مدیریتی و فنی رو به صورت ملقمه‌ای از آیتم‌های مستقل و بی‌ربط معرفی نمی‌کنه. بلکه برای این که به انسجام بین اون‌ها و به نحوه‌ی تاثیرگذاری اون‌ها روی هم پی ببریم، کتاب به یک معرفی سه‌سطحی می‌پردازه؛

ارزش‌ها، اصول، و پرکتیس‌ها (Values, Principles, Practices)

ارزش‌های اکس‌پی ریشه‌ی همه‌ی فرایندهای اکس‌پی هستند و طبعاً خیلی کلی هستند. (مثلاً «فیدبک»، یا «احترام».) پرکتیس‌ها هم روش‌های عملی هستند که به بیان نحوه و هدف اجرای کارها می‌پردازند، که در کتاب به دو دسته‌ی اصلی و جانبی تقسیم میشن. (مثلاً TDD یا CI.) اما برای این که بتونیم بین ارزش‌ها و پرکتیس‌ها پلی برقرار کنیم و به تعامل بین اون‌ها پی ببریم، اکس‌پی به معرفی مجموعه‌ای از اصول می‌پردازه که مثل چسبی بین ارزش‌ها و پرکتیس‌ها عمل می‌کنند. (مثلاً «منفعت متقابل» یا «کیفیت» یا «شکست».)

روی هم‌رفته پی می‌بریم که اون‌چه باعث موفقیت تیم چابک میشه، ایجاد بالانس مناسبی از مجموعه‌ی همه‌ی این آیتم‌هاست که روی هم تاثیر افزاینده و یا حتی گاهاً متناقض دارند، و حذف بعضی از اون‌ها احتمالاً باعث شکست کل فرایند توسعه‌ی نرم‌افزار میشه. مثلاً «تست» و «CI» به دریافت سریع‌تر «فیدبک» کمک می‌کنه و …

این سطح از انسجام بین پرکتیس‌ها رو در متدهای دیگه مشاهده نمی‌کنیم. حتی اسکرام صرفاً اخیراً به اضافه‌کردن مجموعه‌ای از «ارزش‌ها» به راهنمای رسمی اسکرام پرداخته.

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

یک مسئله‌ی دیگه هم در مورد اکس‌پی و این کتاب این هست که مسلط‌شدن به فرایند در ابتدا کمی دشوار و زمان‌بر هست، در قیاس با فرایندهایی مثل اسکرام.

نکته‌ی دیگه‌ای که برای من کتاب رو خیلی ارزش‌مند می‌کنه، پرداختن به مسائل انسانی در کنار مسائل فنی هست که در این سطح نظیرش در کتاب‌ها و متدولوژی‌های دیگه کمتر دیده میشه. این گزیده‌ای از فصل اول کتاب هست:

XP is my attempt to reconcile humanity and productivity in my own practice of software development and to share that reconciliation. I had begun to notice that the more humanely I treated myself and others, the more productive we all became. The key to success lies not in self-mortification but in acceptance that we are people in a person-to-person business “.

“کتاب Planning Extreme Programming از آقایان کنت بک و فاولر در مورد برنامه‌ریزی پروژه به روش XP. این کتاب به طور بنیادی به شرح این می‌پردازه که برنامه‌ریزی چیه و چرا برنامه‌ریزی می‌کنیم و در روش‌های چابک برنامه‌ریزی چطوری کار می‌کنه. موضوعاتی مثل برنامه‌ریزی رلیز و ایتریشن، نوشتن استوری‌ها و تخمین اون‌ها، این که اصلاً تخمین به چه معنی هست و چرا و چگونه انجام میشه، و مسائل گوناگون پیرامون برنامه‌ریزی، محتوای کتاب رو تشکیل می‌ده.

کتاب نسبتاً کم‌حجم هست و قلم شیرینی داره. و در این دور و زمونه که دید خیلی‌ها نسبت به تخمین در توسعه‌ی نرم‌افزار منفی هست، به نظرم می‌تونه خیلی مفید باشه. 🙂

البته بنده به شخصه توصیه می‌کنم که به غیر از خوندن این کتاب، دیدگاه‌هایی که متد کانبان به مقوله‌ی برنامه‌ریزی داره رو مکمل این کتاب کنید. و صد البته دیدگاه‌های دیگه‌ای که در کتب و مقالات دیگه اومده در کنار هم می‌تونه دید خیلی خوبی نسبت به مقوله‌ی برنامه‌ریزی بده. خلاصه این که به قول اون جمله‌ی معروف از میاموتو موزاشی:

Do not develop an attachment to any one weapon or any one school of fighting.”

“کتاب The Clean Coder: A Code of Conduct for Professional Programmers کتابی عالی از رابرت سی مارتین که به شرح رفتار حرفه‌ای برنامه‌نویسان می‌پردازه. این رو با کتاب Clean Code از همین نویسنده اشتباه نگیرید. کتاب Clean Code که کتاب خوبی هم هست و دوستان معرفی کردند، بیشتر به تکنیک‌های کدنویسی می‌پردازه. اما کتاب The Clean Coder بیان می‌کنه که یک برنامه‌نویس برای این که حرفه‌ای باشه، چه رفتارها و عادت‌هایی رو در خودش پرورش می‌ده.

موضوعات کتاب شامل عادت‌های کدنویسی، تمرین‌های روزمره، «نه گفتن» و «بله گفتن» به مدیران (!)، کار تیمی، رفتارهای محیط کار، مدیریت زمان و مدیریت فشار، اشتباهات برنامه‌نویسی، تخمین و ماهیت و تکنیک‌های تخمین، بعضی پرکتیس‌های مهندسی و … هست.

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

گروه متدهای چابک:

برای عضویت در گروه متدهای چابک، از این آدرس استفاده نمایید.

در روز تولدم در کنار سایر هدیه‌ها، یک هدیه‌ی تولد غیرمعمول هم دریافت کردم. کتاب “اصول و روش کاربردی اسکرام” 🙂 🙂 (اینجا را ببینید) این هدیه توسط دوستان عزیزم در شرکت فیوسافت تهیه شده بود که از تک‌تک آنها برای تهیه هدیه‌ی تولد و برگزاری جشن، سپاسگزارم.

هر چند هدیه‌ی آنها خمیرمایه‌ی طنز و شوخی داشت و هدف این بود تا دقایقی کنار هم بخندیم و شاد باشیم، اما عزیزانم نمی‌دانند که چه هدیه‌ی گران‌بهایی را برایم تهیه کرده‌اند. حالا دست‌کم مطمئن هستم که یک جلد از کتاب در کتابخانه‌ شخصی‌ام همیشه وجود خواهد داشت و به سرنوشت کتاب‌های دیگر دچار نخواهد شد و تقدیم دوستان و بستگان نخواهد گردید. 🙂 🙂 . همواره مصداق این ضرب المثل بوده‌ام که “کوزه‌گر از کوزه شکسته آب می‌خورد”.

گزیده:

بپرسد چه کارست برتر ز مرگ
اگر باشد این را چه سازیم برگ
چنین داد پاسخ کزین تیره خاک
اگر بگذری یافتی جان پاک
هرآنکس که در بیم و اندوه زیست
بران زندگی زار باید گریست
فردوسی

کاروان شهید رفت از پیش
وآن ما رفته گیر و می‌اندیش
از شمار دو چشم یک تن کم
وز شمار خرد هزاران بیش

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

خداحافظ ای همنشین همیشه / خداحافظ ای داغ بر دل نشسته

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

تو را می‌سپارم به مینای مهتاب / تو را می‌سپارم به دامان دریا

اگر شب نشینم اگر شب شکسته / تو را می‌سپارم به رویای فردا

به شب می‌سپارم تو را تا نسوزد / به دل می‌سپارم تو را تا نمیرد

اگر چشمه واژه از غم نخشکد / اگر روزگار این صدا را نگیرد

خداحافظ ای برگ و بار دل من / خداحافظ ای سایه سار همیشه

اگر سبز رفتی اگر زرد ماندم / خداحافظ ای نوبهار همیشه