مدیر نمونه

  • یوسف مهرداد بی‌بالان

وقتی خاطره‌ زیر به قلم مهندس علی عبداللهی را خواندم، خیلی تحت تأثیر قرار گرفتم:

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

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

توسعه نرم افزار چابک: کسب و کار نوآوری – بخش اول

  • یوسف مهرداد بی‌بالان

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

مقدمه
مقاله Agile Software Development: The Business of Innovation نوشته Jim Highsmith و Alistair Cockburn دو تن از امضاءکنندگان بیانیه چابک(Agile Manifest) است. این مقاله در سپتامبر سال 2001 یعنی حدود هفت ماه پس از امضای بیانیه در مجله IEEE Computer چاپ شده است.

این مقاله شامل بخشهای زیر است:
+ مسأله
+ پاسخ متدهای چابک
++ اصول بنیادی
+ بیانیه نرم‌افزار چابک
+ قواعد زاینده
+ اقدامات چابک
++ برنامه‌ریزی ویژگی و اولویت‌بندی پویا
++ بازخورد و تغیییر
++ تأکید بر کارتیمی

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

رویکردهای چابک از جمله XP‏ ،Crystal،‏ Lean Development،‏ Scrum و‏ ASD از دریچه­ای به تغییر می­نگرند که نشانگر آشفتگی محیط کسب­وکار و تکنولوژی کنونی است.

مسئله
به تازگی در تحقیقی که Michael Mah در QSM Associates بر روی بیش از 200 پروژه توسعه نرم افزار
انجام داده، گزارش داده است محققان قادر به یافتن تقریباً نیمی از طرحهای[1] اولیه پروژه­ها برای مقایسه با یکدیگر نشدند. چرا ؟ زیرا هدف اصلی، اجرای پروژه مطابق با طرح اولیه نبوده و به جای آن، راضی نگه­داشتن مشتری -در هنگام تحویل پروژه و نه در آغاز آن– اولویت پیدا کرده است.

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

پذیرش اعتبار نظریه “ضرایب متغیر هزینه­ Barry Boehm”مبنی بر اینکه هزینه تغییرات در طول چرخه حیات پروژه ثابت نبوده و افزایش می­یابد، بدین معناست که پرسش اصلی، چگونگی مدیریت تغییرات ناخواسته در پروژه است و نه چگونگی جلوگیری از بروز آنها.

روش­های رایج فرض می­کنند فقط با تلاش بیشتر می­توان مجموعه کاملی از نیازمندی­ها را در اسرع وقت شناسایی و پیش‌بینی کرد و از این رو هزینه‌ها را با جلوگیری از ایجاد تغییرات کاهش داد. امروزه نپذیرفتن و انجام ندادن سریع تغییرات به معنی بی توجهی به شرایط و موفقیت کسب­وکار است.

روشهای رایج مدیریت فرایندها نیز با اندازه­گیری­های مستمر، شناسایی خطاها و بهبود فرایند می‌کوشند تا تغییرات را در جایی خارج از فرایندها مدیریت کنند. این روشها فرض می­کنند خطاها عامل تغییرات هستند. هر چند برخی خطاها ناشی از مشکلات فرایندها هستند اما واقعیت این است که عامل ایجاد تغییرات اساسی‌، تغییرات محیطی­اند. از آنجایی که قادر به حذف تغییرات محیطی نیستیم، کاهش هزینه انجام آنها، تنها استراتژی بادوام و درازمدت است. به عبارت دیگر، استراتژی جدید به جای حذف دوباره کاری(بازکاری)، سعی در کاهش هزینه آن دارد.

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


[1] Plan

گزیده:
لازم نيست آدم از كوهي بالا رود تا بفهمد بلند است. پائولو كوئيلو
مرجع: اس.جی.

واژه‌گزینی برای اصطلاحات چابکی (agile dictionary)

  • یوسف مهرداد بی‌بالان

حضرت مولانا می‌فرماید:
اختلاف خلق از نام اوفتاد
چون به معنی رفت آرام اوفتاد

استاد گرانمایه، انسان دوست‌داشتنی و آموزگار دانا، استاد روحانی رانکوهی در یکی از کلاسهای پایگاه داده روی تابلو نوشت: پایگاه داده. سپس ادامه داد، دانشجویان عزیز، این زبان «مادری» است. در گوشه‌ دیگری از تابلو نوشت: Database. باز ادامه داد، عزیزانم این زبان «مادرجانی». زبان مادرجانی از زبان مادری عزیزتر است- به واسطه پسوند «جان».

آن روز همه خندیدیم و همه می‌دانستیم که استاد به زبان فارسی در متون فنی بسیار پای‌بند است.

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

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

“Translation is not a matter of words only: it is a matter of making intelligible a whole culture.” Anthony Burgess

گفت‌وگوی چابک و تازه‌کار (4) – agilist and novice

  • یوسف مهرداد بی‌بالان

تازه‌کار: سلام
چابک: سلام

تازه‌کار: امروز می‌خواهم یک سوال شخصی از شما بپرسم. این پرسش با خواندن این مطلب برایم پیش آمده است.
چابک: بفرمایید.
تازه‌کار: چرا شما به متد خاصی اشاره نمی‌کنید و مدام کلمه چابک را به کار می‌برید.
چابک: مثلاً کدام متد؟
تازه‌کار: مثلاٌ اسکرام.
چابک: متوجه شدم. اجازه دهید کمی درباره آن توضیح دهم.
در گردهمایی سال 2001 که منجر به بیانیه چابک شد، همه شرکت‌کنندگان در مورد اولین موضوعی که توافق داشتند این بود که: ما به دنبال تجمیع و تلفیق متدها برای ایجاد چیزی به نام متدولوژی سبک یکپارچه-(Unified Light Methodology” (ULM- نیستیم. بعد از حدود یازده سال از آن زمان، چیزی که پیشروان متدها بدان تأکید می‌کنند این است که ما واژه مشترکی به نام “چابکی” داریم و نه یک متد خاص.
اجازه دهید مثالی عرض کنم:
کیفیت طراحی یکی از موضوعات تاکید شده در متدهای چابک است. متد DSDM با به‌کارگیری مجموعه‌ای از نمونه‌سازی‌ها(Prototype) به حوزه‌های ناشناخته یا ناپایدار تکنولوژی، کسب‌وکار و رابط کاربری حمله می‌کند. Scrum با استفاده از جلسات کوتاه روزانه و بازنگری‌های جامع انتهای Sprint استفاده می‌کند. XP از تکنیکهای Spike و TDD کمک می‌گیرد و …. اینها نمونه‌هایی از تکنیکهایی هستند که در این متدها وجود دارند.
چرا باید فقط به یک یا دو متد بسنده کنیم و آموزه‌هایشان را یاد نگیریم و به کار نبندیم؟ چابکی تاکید فراوانی بر سازگاری و تطابق با محیط دارد. در هر شرایطی، روش تطبیق‌پذیری و سازگاری متفاوت خواهد بود. یادگیری آموزه‌های همه متدهای چابک، کمک خواهد کرد تا انتخاب مناسبی برای جااندازی آنها داشته باشیم.

بسنده کردن به یک متد، به خلاقیت و نوآوری شما، آسیب خواهد زد، آن چه یکی از اهداف متدهای چابک است.

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

یادتان باشد که بعضی از متدها کاربردهای خاص دارند مثلاً اسکرام یک چارچوب زیبای مدیریتی است. اما همین چارچوب زیبا، در مورد مباحث فنی و تخصصی تولید نرم‌افزار ادعایی ندارد. در خیلی از تیمها، آن چه که آزاردهنده است، موضوعات فنی و تخصصی است و نه موضوعات مدیریتی.

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

چابک: اشکالی ندارد. جوانی است و هزار تا دردسر.

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

با این دیدگاه جاهایی نیاز به نظم و نظام (Discipline) خواهید داشت و متدهای چابک مسائل شما را حل نخواهند کرد و بر عکس، جلوی سازگاری و تطبیق‌پذیری شما را خواهند گرفت. در این شرایط ضروری است نگاهی به متدهای با نظام (Discipline based methods) داشته باشید و از تجربه‌ها و آموزه‌های آنها استفاده کنید.

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

دو تیم را به یاد می‌آورم که دو شیوه مختلف برای ورود به متدهای چابک انتخاب کرده بودند. یکی تاکید می‌کرد که می‌خواهد مبتنی بر Scrum کار کند و دیگری تاکید می‌کرد که می‌خواهد بهبود (Improvement) ایجاد کند. تیم اول ناخودآگاه به این سمت حرکت کرد که واو به واو متد Scrum را بر اساس نیازهایش اجرا کند. در حالی که تیم دوم، به فکر مشکلات و مسائل خود بود و برای رفع آنها، دنبال راه حل می‌گشت – منبع راه حل مهم نبود، حتی تجارب گذشته تیم -.
هر چند اشکال، به اجرا بر می‌گشت و اشکالی به متدها وارد نبود، اما ناخودآگاه، تیم به این گونه تفکرات – واو به واو اجرا کردن متدها و بسته‌شدن تفکر و خلاقیت- متمایل می‌شود و گریز از آن دشوار است.

تازه‌کار: وقت به پایان رسیده است. آیا می‌توانید مرجعی برای موضوع گفت‌وگوی بعدی معرفی کنید.

چابک: قطعاً.
پیشنهاد می‌کنم که دو مرجع اصلی چابکی را مطالعه کنید. یکی از بین توسعه‌دهندگان بیرون آمده و دیگری از مدیران پروژه و رهبران تیمها. اولی بیانیه چابک (Manifest for Agile Software Development) و دیگری اعلامیه وابستگی متقابل (Declaration of Interdependence) است.

تازه‌کار: سپاسگزارم.

چابک: من هم همین طور. تا دیداری دیگر، بدرود.

گزیده:

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

سه داستان

  • یوسف مهرداد بی‌بالان

گوشی‌ام نشان می‌دهد که دوستی روی خط است. پاسخ می‌دهم که: در جلسه‌ام، تماس می‌گیرم. خداحافظی می‌کند. جلسه که تمام می‌شود، شماره‌اش را می‌گیرم. بعد از احوال پرسی، کارش را جویا می‌شوم.
دوست: دنبال کسی می‌گردم که بتواند چند پروژه شرکت را مدیریت کند.
… در لابه‌لای صحبت می‌گوید:
دنبال کسی می‌گردم که به جای من، کارها را انجام دهد.
می‌پرسم: شما چه کار خواهید کرد؟
دوست: مدتی از شرکت مرخصی گرفته‌ام.
به شوخی می‌گویم: کجا انشاءالله؟
دوست: دارم می‌روم …[نام یک کشور]
لحظاتی بدون صحبت می‌گذرد. از همه انتظار رفتن داشتم، غیر از این یکی. نمی‌دانم برایش خوشحال باشم یا برای خودم ناراحت. خوشحالی بسیار بهتر از ناراحتی است، پس خوشحال می‌شوم.
هر وقت کارفرمایی دنبال پیمانکاری مجرب و متعهد می‌گشت، او و شرکتش، اولین پیشنهادم به کارفرما بودند. چندین پروژه‌ای را که قبول کرده بود، به درستی به پایان رسانده بود. همیشه خوشحال بودم که در این گونه موارد، دوست مورد اعتمادی وجود دارد که به دوست دیگری معرفی کنم.
با خود فکر می‌کنم، چه کسی جای او را پر خواهد کرد؟
تا کسی مثل او در اینجا ساخته شود و آماده به کار گردد، چقدر هزینه و زمان لازم است؟ جقدر فرصت از دست خواهیم داد؟
در دلم برایش آرزوی خوشبختی کردم. خوشبختی و آرامشی که حقش بود و نداشت.

——————————
به جلسه‌ای دعوت شده‌ام. مدیران میانی شرکت دور هم گرد آمده‌اند تا در مورد موضوع مهمی صحبت کنند. همه مشغول بحث و گفت‌وگو هستند.
یکی به ناگاه می‌گوید که انجام این بخش از کار را به فلانی – یکی از افراد با تجربه و کاردان شرکت- بسپریم.
دیگری می‌گوید: او را جزو آمار نیار.
با تعجب می‌پرسم: چرا؟
می‌گوید: او تا چند وقت دیگر به ..[یک کشور] می‌رود.
خیلی متعجب نشدم، چرا که اگر نگویم همه، اما اغلب عزیزانی که می‌شناسم در صف مهاجرت هستند. فقط زمان رفتن، نامعلوم است.
آن چه ذهنم را مشغول کرد، این بود که ظرفیت کاهش یافته شرکت، چقدر طول می‌کشد، به اندازه قبلی برگردد؟ در این مدت، چقدر فرصتها از دست خواهد رفت؟ چقدر کارها، عقب خواهد افتاد؟
برایش یافتن آن چه که آرزویش را داشت، آرزو می‌کنم.

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

——————————-
روزی دوستی که مسئولیتی در شرکتی داشت و از مهاجرت کارمندانش به شدت مستأصل و بیچاره شده بود، به شوخی گفت: اگر روزی پروسه مهاجرت کوتاه شود، بیچارگی‌ام پایان می‌یابد، چرا که کارمندی نخواهم داشت که بدانها فکر کنم.

گزیده:
من
رویایی دارم، …
رویای یک رقص بی‌وقفه از شادی
یغما گلرویی

Code Decay

  • یوسف مهرداد بی‌بالان

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.

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

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

پس شروع کردم!

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

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

برای خروج از جستجو کلید ESC را بفشارید