متخصص، متعهد، متخصص متعهد

ارسال شده در تاریخ آوریل 17, 2011 Uncategorized

در ابتدای این پست از مهندس مهرداد تشکر می کنم که  پست کتاب خوبم  آرزو است را در وبلاگ خودشان مطرح کردند و سبب شدند که تعدادی از دوستان پاسخی به سوالات ارائه شده بدهند. از همه این دوستان نیز بخاطر پاسخ هایشان تشکر و قدردانی می کنم.

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

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

کتاب خوبم آرزو است

ارسال شده در تاریخ مارس 19, 2011 مهندسی نرم افزار

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

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

انسان به امید زنده است ….

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

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

Three Simple Truths

ارسال شده در تاریخ مارس 8, 2011 Agile, مهندسی نرم افزار

The following are three simple project truths that, once accepted, get rid of much of the drama and dysfunction we regularly see on software projects.

It is impossible to gather all the requirements at the beginning of a project.

Whatever requirements you do gather are guaranteed to change.

There will always be more to do than time and money will allow.

Accepting the first truth means you are not afraid to begin your journey without knowing everything up front. You understand that requirements are meant to be discovered and that not proceeding until all are gathered would mean never starting.

Accepting the second means you no longer fear or avoid change. You know it is coming. You accept it for what it is. You adapt your plan when necessary and move on.

And by accepting the third, you no longer get stressed when your todo list exceeds your time and resources to deliver. This is the normal state for any interesting project. You do the only thing you can—you set some priorities, get the most important stuff done first, and save

the least important for last.

Once you accept these three simple project truths, much of the stress and anxiety traditionally associated with software delivery disappears. You are then able to think and innovate with a level of focus and clarity that escapes most in our industry.

مراحل رشد یک تیم

ارسال شده در تاریخ دسامبر 27, 2010 Agile, كار تيمي

به محیط اطراف خود نگاه کنید. انسانها، گیاهان، اشیاء و …. و حالا یک سوال از خودتان بپرسید. آیا شما، همکارتان، همسرتان و یا ماشینی که سوار آن می شوید به سطحی از بلوغ و پایداری در چرخه زندگی خود رسیده است که بتوان آنرا موفق نامید؟ اگر پاسخ شما در مورد هر کسی و هر چیزی که در ذهن دارید بلی است، یک سوال دیگر از خودتان بپرسید. آیا این شخص یا چیز از روز اول در این سطح متولد شده است یا برای رسیدن به این مرحله، سطوح و مراحل مختلفی را پشت سر گذاشته است؟

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

یک انتقاد

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

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

مدل تاکمن

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

Storming :این مرحله برعکس مرحله قبل که مرحله و جو بچه مثبتی بود، مرحله جر و بحث، گفتکو و اختلاف نظر بین اعضای تیم می باشد.سخت ترین مرحله بین 4 مرحله، این مرحله می باشد و اگر تیم بتواند از این مرحله با موفقیت عبور کند، اعضاء می توانند امیدوار باشند که تیم به احتمال زیاد می تواند به مرحله چهارم نیز برسد. در غیر اینصورت تیم به احتمال زیاد از هم خواهد پاشید. بعضی از مسائلی که در این مرحله می توان مشاهده کرد به شرح زیر است:

  • جر و بحث و اختلاف نظر بین اعضای تیم وجود دارد. حتی در مواردیکه افراد قبلا روی آن موضوع توافق کرده اند.
  • حسادت اعضاء نسبت به یکدیگر افزایش می یابد.
  • اعضاء با آرمانها و اهداف تیم و مجموعه مخالفت می کنند، و حتی اعلام می کنند که آنها اشتباه است.
  • اهداف غیر واقعی (جدا از هدفی که تیم برای آن ایجاد شده است) توسط افراد مطرح می شود و حتی در جهت آن اهداف نیز حرکت می شود.
  • روابط بین اعضای تیم کاهش می یابد، شاید بتوان گفت تیم به صورت انزوا حرکت می کند.
  • …

مسائلی که در بالا اشاره شد، نسبت به درجه شیوع آن می تواند قسمتی از انرژی اعضاء را مصرف کند و شاید دیگری انرژی و قدرتی برای کسی نماند که بسوی هدف اصلی گام بردارد.

Norming :اگر تیم بتواند از طوفانی که در مرحله قبل او را تا حد نابودی تهدید می کرد، به سلامت عبور کند. می تواند در این مرحله روح و شخصیت خود را بدست بیاورد. به این صورت که اعضاء دیگر خود را به عنوان عضوی از تیم قبول می کنند. خواسته ها و نظرات شخصی خود را بالاتر از هدف تیم نمی دانند.قدرت نقدپذیری خود را بالا می بردند و البته نقدی که ارائه می شود از روی حسادت و غیر واقعی نیست. وظایف و نقش افراد به طور دقیق مشخص می شود و هر فرد برای رسیدن به هدف مشترک تیم تلاش می کند.

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

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

الگوهای طراحی در قالب یک فایل

ارسال شده در تاریخ دسامبر 27, 2010 الگوهای طراحی

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

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

لینک دانلود الگوهای طراحی

رقص فیل ها

ارسال شده در تاریخ دسامبر 25, 2010 اصول و الگوها

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

“من بر پایه اصول، نه روش ها مدیریت می کنم.”

واقعا جمله ای بزرگی است که باید درباره آن اندیشید. اجازه بدهید باز روی هدف پست قبلی تاکید کنم ولی اینبار با ذکر مثالهای از کتابهای رقص فیل ها و راه تویوتا. (جای کتاب “ساختن برای ماندن” در این پست بسیار خالی است، چون این کتاب را به یکی از دوستان امانت داده ام )

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

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

هر دو جمله بی شک معنای مشترکی دارند، حال مهم نیست که این جمله را لویی گشنر بیان کرده باشد یا تائیچی اونو. مهم این است که از این اصول استفاده کنیم و مهم نیست که گفته شود این قسمتی از راه تویوتا است یا هر اسم دیگری.

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

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

باز دو جمله با معنای مشترک.

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

و در انتها یک از نظرات بسیار زبیای که آقای گشنر بیان کرده اند و من شدتاً  به آن اعتقاد و علاقه دارم را برای دوستان در می نویسم (ارزشهای پنجگانه و نظر شخصی من در این پست). “سلسله مراتب به نظر من خیلی بی اهمیت است. اجازه دهید در همه ی جلسات کلیه ی افرادی که می توانند در حل مسئله کمک کنند، صرف نظر از موقعیت شغلی شان، حضور داشته باشند. تعداد کمیته ها و جلسات را به حداقل برسانید. تصمیم گیری کمیته ای را کلاً کنار بگذارید تا مقدار زیادی از ارتباطات صریح و بی پرده انجام شوند.”

 

 

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

“من بر پایه اصول، نه روش ها مدیریت می کنم.”

واقعا جمله ای بزرگی است که باید درباره آن اندیشید. اجازه بدهید باز روی هدف پست قبلی تاکید کنم ولی اینبار با ذکر مثالهای از کتابهای رقص فیل ها و راه تویوتا. (جای کتاب “ساختن برای ماندن” در این پست بسیار خالی است، چون این کتاب را به یکی از دوستان امانت داده ام )

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

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

هر دو جمله بی شک معنای مشترکی دارند، حال مهم نیست که این جمله را لویی گشنر بیان کرده باشد یا تائیچی اونو. مهم این است که از این اصول استفاده کنیم و مهم نیست که گفته شود این قسمتی از راه تویوتا است یا هر اسم دیگری.

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

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

باز دو جمله با معنای مشترک.

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

و در انتها یک از نظرات بسیار زبیای که آقای گشنر بیان کرده اند و من شدتاً  به آن اعتقاد و علاقه دارم را برای دوستان در می نویسم (ارزشهای پنجگانه و نظر شخصی من در این پست). “سلسله مراتب به نظر من خیلی بی اهمیت است. اجازه دهید در همه ی جلسات کلیه ی افرادی که می توانند در حل مسئله کمک کنند، صرف نظر از موقعیت شغلی شان، حضور داشته باشند. تعداد کمیته ها و جلسات را به حداقل برسانید. تصمیم گیری کمیته ای را کلاً کنار بگذارید تا مقدار زیادی از ارتباطات صریح و بی پرده انجام شوند.”

الگو های طراحی (Design Pattern)

ارسال شده در تاریخ نوامبر 30, 2010 الگوهای طراحی, شي گرايي, طراحي

الگو های طراحی (Design Pattern) :

 

کسی وجود دارد که قبلاً مسله شما را حل کرده است.

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

الگو ها تکنیک هایی هستند که افراد زمانی از آنها برای حل مسائل خاص استفاده کردند. و به عنوان راه حل های خوب شناخته شده اند. سپس این تکنیک ها مستند سازی شده اند تا توسعه دهندگان هنگام برخورد با مسائل مشابه از این مستندات استفاده کنند و مسائل خود را حل کنند.

 

تاریخچه الگو های طراحی :

استفاده از الگوها برای اولین بار به ذهن یک معمار به نام الکساندر خطور کرد. الکساندر با این مشکل روبرو شد که یک طرح خوب و با کیفیت برای یک ساختمان چگونه می تواند باشد. او برای حل مشکل خود، ساختمانها، خیابانها، شهرک ها و هر مکانی که یک انسان برای خودش می سازد را مورد مطالعه و بررسی قرار داد. او کشف کرد که بناهای خوب از نظر طراحی دارای ویژگیهای مشترک هستند. او کشف کرد که بناهای خوب دارای ویژگیهای مشابه هستند واین ویژگیهای مشابه را الگو نامید.

هر الگو بیانگر یک مسئله و مشکل است که می تواند بارها و بارها روی بدهد همراه با راه حل آن مسئله، وشما می تواند از این راه حل برای میلیون ها بار استفاده کند بدون نیاز مجدد برای پیدا کردن راه حل.

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

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

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

در اوایل دهه 1990، افرادی زیادی روی الگوهای طراجی کار می کردند. اما چهار نفر به نام های، گاما، جاکوبسون، هلم و ولسایدز بیشترین تاثیر را در این زمینه با نوشتن کتابی به نام

“Design Pattern: Elements of Reusable Object-Oriented Software”، داشتند. این چهار نویسنده به Gang of Four مشهور است. آنها در این کتاب ائده استفاده از الگوها را در طراحی نرم افزار به کار بردند.و یک فرمت استاندارد را برای مستندسازی الگوها ایجاد کردند. 23 نوع از الگوها را دسته بندی کردند و …. به مرور زمان فرمت های استاندارد دیگری برای مستند سازی الگوها پیشهناد شد.

 

 قالب مستند سازی برای الگوهای طراحی :

 

 

نام الگو

یک نام خوب و مفید برای الگو

هدف (intent)

یک جمله کوتاه و مختصر درباره چیزی که الگو انجام می دهد. (تعریف مسله و راه حل به صورت مختصر و مفید)

نام مستعار

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

ساختار

یک نمایش گرافیکی از الگو

اجزاء تشکیل دهنده (Participants)

کلاس ها و اشیائ که در الگو شرکت دارند (وجود دارند).

همکاریها (Collaborations)

چگونه اجزای تشکیل دهنده با هم همکاری می کنند تا وظایفشان را انجام دهند.

نتايج‌ (Consequences)

نتایج استفاده از الگوی مورد نظر

پیاده سازی

تکنیک های برای پیاده سازی الگوی مورد نظر

نمونه کد

تکه کدی برای پیاده سازی یک نمونه

الگو های مرتبط

الگوهای طراحی دیگری که ارتباط نزدیگ با الگوی مورد نظر دارند.

 

دسته بندی الگو ها :

1-   الگوهای بوجود آورنده(Creational Pattern): همه الگو های که در این دسته قرار می کیرند در ارتباط با روش های ایجاد اشیاء هستند.

2-   الگوهای ساختاری(Structural Patten): این نوع الگوها شرح می دهند چگونه اشیاء و کلاس ها می توانند در ساختارهای بزرگتر باهم ترکیب شوند.

3-      الگوهای رفتاری(Behavioral Pattern): این نوع الگو ها روی ارتباط اشیاء با یکدیگر تمرکز دارند.

 

Creational

Structural

Behavioral

Factory Method

Abstract Factory

Builder

Prototype

Singleton

Adapter

Bridge

Composite

Decorator

Flyweight

Façade

Proxy

Interpreter

Template Method

Chain of Responsibility

Command

Iterator

Mediator

Memento

Observer

State

Strategy

Visitor

 

فهرست الگوهای طراحی

 

 

الگوی Iterator

ارسال شده در تاریخ نوامبر 30, 2010 الگوهای طراحی, شي گرايي, طراحي

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

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

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

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

دیاگرام الگوی Iterator

تعریف اینترفیس IIterator

Public Interface IIterator

 Function FirstItem() As Object

 Function NextItem() As Object

 Function IsDone() As Boolean

 Function CurrentItem() As Object

End Interface

 

پیاده سازی اینترفیس IIterator

Public Class ConcreteIterator

 Implements IIterator

 Private List As New ArrayList

 Private Current As Integer = 0

 

 Public Sub New(ByVal VarList As ArrayList)

 List = VarList

 End Sub

 

 Public Function CurrentItem() As Object Implements IIterator.CurrentItem

 Return List(Current)

 End Function

 

 Public Function FirstItem() As Object Implements IIterator.FirstItem

 Current = 0

 If IsDone() Then

 Return List(Current)

 Else

 Return Nothing

 End If

 End Function

 

 Public Function IsDone() As Boolean Implements IIterator.IsDone

 If Current >= List.Count Then

 Return False

 Else

 Return True

 End If

 End Function

 

 Public Function NextItem() As Object Implements IIterator.NextItem

 Current += 1

 If IsDone() Then

 Return List(Current)

 Else

 Return Nothing

 End If

 End Function

End Class

 

تعریف اینترفیس Aggregate

Public Interface IAggregate

 Function CreateIterator() As IIterator

End Interface

 

پیاده سازی اینترفیس Aggregate و کلاس Book

Public Class Book

 Implements IAggregate

 Private _Name As String

 Private _Chapters As New ArrayList

 

 Public Property Name() As String

 Get

 Return _Name

 End Get

 Set(ByVal value As String)

 _Name = value

 End Set

 End Property

 

 Public Sub New()

 

 End Sub

 

 Public Sub New(ByVal VarName As String)

 _Name = VarName

 End Sub

 

 Public Sub Add(ByVal Chapter As Chapter)

 _Chapters.Add(Chapter)

 End Sub

 

 Public Function CreateIterator() As IIterator Implements IAggregate.CreateIterator

 Return New ConcreteIterator(_Chapters)

 End Function

End Class

 

 

تعریف کلاس Chapter

Public Class Chapter

 Private _Name As String

 Public Property Name() As String

 Get

 Return _Name

 End Get

 Set(ByVal value As String)

 _Name = value

 End Set

 End Property

 Public Sub New()

 

 End Sub

 Public Sub New(ByVal VarName As String)

 _Name = VarName

 End Sub

End Class

 

نحوه استفاده

Dim Book As New Book(“Book1”)

Book.Add(New Chapter(“Chapter 1”))

Book.Add(New Chapter(“Chapter 2”))

 

Dim Iterator As IIterator = Book.CreateIterator

Dim Ins As Chapter = Iterator.FirstItem

While Iterator.IsDone

 System.Console.WriteLine(Ins.Name)

 Ins = Iterator.NextItem

End While

 

 

الگوی Composite

ارسال شده در تاریخ نوامبر 30, 2010 الگوهای طراحی, شي گرايي, طراحي

همانطوریکه روی صندلی نشسته اید به بدن خود تان توجه کنید و آنرا مورد بررسی قرار بدهید، شاید بدن خود را به صورت ترکیبی از چندین شی مانند دست، پا، چشم و …  ببینید. سپس با دست خود یک کتاب را بردارید و شروع به ورق زدن آن بکنید، مشاهده می کنید که یک کتاب از ده ها صفحه تشکیل شده است و هر صفحه از چندین پارگراف و هر پار گراف از چندین سطر تشکیل شده است.  روی آیکون My Computer کلیک می کنید، دریواهای که کامپیوترتان دارید نشان داده می شود، روی یکی از دریواها کلیک می کنید، لیست فایل ها و folder های آن دریوا نشان داده می شود، سپس روی یکی از folder ها کلیلک می کند، مشاهده می کند که خود آن folder، از چندین folder و یا فایل تشکیل شده است. در هر کدام از نمونه های بالا، همانطوریکه دیدید یک شی ممکن شامل چندین شی ساده یا مرکب دیگر نیز باشد، آن شی باید بداند که چگونه این اشیاء را نگهداری و مدیریت کند و هر چه تعداد اینگونه اشیاء مرکب در سیستم افزایش یابد، سیستم پیچیده تر خواهد شد. شما برای حل این مشکل چه پیشنهادی دارید و چه راه حلی ارائه می کنید؟

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

با این طراحی  Clinet می تواند یک مجموعه از اشیاء FileSystemComponent را ایجاد کند. و با استفاده از متد addComponent، شی  DirComponent، نمونه های مختلفی از FileSystemComponents را به DirComponent اضافه کند.

هنگامیکه Clinet بخواهد سایز هر کدام از این اشیاء را استخراج کند، به سادگی متد getComponentSize را فراخوانی کند، Client نباید از نحوه محاسبه و عملیاتی که برای اندازه گیری سایز یک مولفه صورت می گیرد آگاه باشد. در این مورد، client با هر دو شی FileComponent و DirComponent به یک صورت رفتار می کند.

Clinet  در مورد متد مشترک getComponentSize، با هر دو شی  FileComponent و DirComponent رفتار یکسانی را دارد. اما Clinet   برای فراخوانی متدهای مانند addComponent و getComponent نیاز دارد که دو شی را از همدیگر تشخیص دهد، چونکه این متدها فقط برای DirComponent تعریف شده است. به همین دلیل client نیاز دارد تا نوع شی مورد نظر را برای فراخوانی این متدها چک کند تا مطمئن شود که با یک نمونه از DirComponent سر و کار دارد.  برای بهبود این طراحی بگونه ای که نیازی به تشخیص تفاوت بین دو شی وجود نداشته باشد، طراحی را به چه صورت تغییر می دهد.

ما می خواهیم طراحی را بگونه ای تغییر دهیم که clinet  نیازی به تشخیص شی مرکب DirComponent از FileComponent نداشته باشد، و با هر دو شی به یک صورت رفتار کند.

طراحی را می توانیم به این صورت تغییر دهیم که، متدهای addComponent و getComponent را به اینترفیس مشترک FileSystemComponent  انتقال دهیم، و یک پیاده سازی پیش فرض برای این متدها انجام دهیم و اینترفیس مشترک FileSystemComponent   را به یک کلاس abstract تغییر دهیم. پیاده سازی پیش فرض برای این متدها بخاطر FileComponent  هست و کار خاصی را انجام نمی دهد. اما کلاس DirComponent این متدها را بازنویسی مجدد می کند تا پیاده سازی خاص خود را انجام دهد.

با این کار مشکل قبلی ما حل می شود، چون کلاس پدر FileSystemComponent، دارای یک پیاده سازی پیش فرض برای متدهای addComponent و getComponent هست، و دیگر clinet   نیاز به کنترل نوع شی برای فراخوانی این دو متد ندارد.

تصور کنید که می خواهیم یک متد جدید با نام  removeComponent را به کلاس DirComponent اضافه کنیم، در اینصورت این متد را به پدر FileComponent نیز اضافه می کنیم و یک پیاده سازی پیش فرض برای این متد در نظر می گیریم.

با طراحی بالا ما توانستیم مشکل خود را حل کنیم، اما روشی که برای غلبه بر مسئله استفاده کردیم، الگوی Composite نام دارد. ما در مواقعی از این الگو استفاده می کتیم که یک شی پیچیده داریم و می خواهیم آنرا به یک سلسله مراتب از اشیاء کل و جز (part-whole hierarchy) تجزیه کنیم. یا همانند مثال بالا،  client قادر باشد تفاوت بین اشیاء مرکب (DirComponent) و اشیاء منفرد را نادیده بگیرید. و client با همه اشیاء موجود در ساختار مرکب بصورت یکسان رفتار کند.

کلاس دیاگرام این الگو به صورت زیر است:

در دیاگرام بالا کلاس Leaf، کلاس های هستند که دارای فرزند نیستند مانند کلاس FileComponent در مثال.

کلاس Composite، کلاسی مانند DirComponent در مثال می باشد. در این کلاس رفتارهای مربوط به مولفه های که دارای فرزند هستند تعریف می گردد.

کلاس FileSystemComponent همان کلاسFileSystemComponent با ویژگیهای که در بالا اشاره شد هست.

آیا اسامی متدلوژی ها میزان موفقیت ما را مشخص می کنند؟

ارسال شده در تاریخ اکتبر 9, 2010 Agile

مکتب ها، مذاهب، متدولوژیها و … اهداف و عصاره مطالب خود را به شکل ها و اسامی مختلف بیان می کنند در صورتیکه اکثر آنها دارای منظور و مقصود یکسان و مشترکی می باشند. شاید این اهداف مشترک که در قالب جملات و اسامی مختلف بیان می شود بیانگر اهمیت آن هدف باشد.

ما در پست ضایعات نرم افزاری، به بررسی مفهومی به نام ضایعات نرم افزاری پرداختیم و آن را از دیدگاه Lean مورد بررسی قرار دادیم. در این پست به بررسی همین موضوع از دید متدلوژیهای دیگر خواهیم پرداخت.

XP و YAGNI

در XP اصلی با عنوان YAGNI که سرنامی برای عبارت “You ain’t gonna need it” می باشد و به معنی “شما به آن نیاز نخواهید داشت” می باشد وجود دارد. که این اصل بیان می کند که شما باید هر چیزی را وقتی پیاده سازی کنید که واقعا به آن نیاز دارید، و نه وقتی که می فهمید در آینده ممکن است به آن نیازمند شوید. این جمله یکی از جملاتی است که XP واقعا روی آن تاکید دارد و اعلام می کند که شما حتی اگر اطمینان حاصل کنید که به این ویژگی در آینده نیاز خواهد داشت آنرا الان پیاده سازی نکنید.

Scrum و قلب آن (Product backlog)

Product backlog را قلب Scrum می نامند. لیستی از ویژگیها و نیازمندیهای نرم افزار که بر حسب اولویت مرتب شده است و بر حسب همان ترتیب در عمل پیاده سازی خواهد شد. اما این اولویت توسط چه کسی یا کسانی و با چه منطقی انجام می شود؟ وظیقه اصلی اولویت دهی را Scrum بر عهده Product owner قرار می دهد و او بر حسب ارزشی که هر ویژگی برای مشتری ایجاد می کند آنها را مرتب سازی می کند. ویژکیهای با ارزش افزوده بالا در ابتدای لیست قرار می گیرند و به به ترتیب که در لیست پایان می رویم از ارزش افزوده هر ویژگی کاسته می شود و همچنین از اولویت پیاده سازی آن.

Lean و حذف ضایعات در هر نقطه و هر زمانی

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

خلاصه و هدف هر سه دیدگاه بالا اولویت بندی نیازمندیها و ویژگیهای برنامه بر اساس ارزشی است که برای مشتری تولید می کنند، انجام هر کار در زمان مناسب با توجه به درخواستهای مشتری و بازگشت سرمایه. ولی هر کدام آن را با شیوه و ابزارهای خود بیان می کنند. شاید بتوان گفت ما باید بیشتر از آنکه درگیر اسامی باشیم باید به فکر ابزارها و شیوه های باشیم که به تیم و فرآیند ما در موفقیت کمک می کند (پست RUP بهتر است یا Agile؟ از استاد مهرداد یا پست آقای شهبازیان در مورد الگوهای فکری می تواند جالب توجه باشد). شاید منظور و هدف من به روشنی از متن پایین قابل استنباط باشد.

XP هیچ چیز جدیدی نیست. بیشتر تکنیک های XP، همان هایی هستند که برنامه نویسان، سال هاست که آنها را مورد استفاده قرار می دهند. تفاوت در اینجاست که XP همه آنها را باهم ترکیب کرده است و کارایی آنها را افزایش داد. ائده آن، پیدا کردن چیزهایی است که خوب کار می کنند همچنین بالا بردن کارایی آنها برای بهتر کار کردن است. بر این اساس، که علت استفاده از کلمه eXtreme معلوم می شود. استفاده زیاد از این تکنیک ها.