دسته: Agile

ارزشهای پنجگانه

ارسال شده در تاریخ ژوئن 1, 2010 Agile

در پست قبلی درباره ارزش و ضایعات نرم افزار صحبت کردیم و در این پست به ارزشهای كه در بعضی از متدلو‍ژیهای سبك مانند XP و Scurm وجود دارد كه زير بناي اصلی تكنیكهای اين متدلوژیها را تشكیل مي دهد خواهيم پرداخت و سعي خواهيم كرد كه با استفاده از این ارزشها به ائده ها و اصولی دست پیدا كنيم كه ضایعات را از فرآیند توسعه نرم افزار تا حد قابل قبولی حذف كنیم.

در جدول زیر ارزشهای مربوط به هر دو متدلوژی XP و Scrum آورد شده است ولی ما در اين پست فقط به بررسی ارزشهاي موجود در XP خواهیم پرداخت.

Scrum Values XP Values
ارتباطات  (Communication) ارتباطات  (Communication)
(Focus) سادگی (Simplicity)
(Openness) بازخورد (Feedback)
شجاعت (Courage) شجاعت (Courage)
احترام (Respect) احترام (Respect)

ارتباطات

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

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

XP برای ایجاد ارتباط در تیم ها،از تکنیک های استفاده می کند که ارتباط در تیم را اجباری می کند، تکنیک های مانند Planning Game، Pair Programming، Stand up meeting، تخمین کارها. یک تیم XP، از نقش مربی برای کنترل ارتباطات، حصول اطمینان از به کارگیری آن و تشویق برای سود جستن از تکنیک ها، به منظور غلبه بر مشکلات استفاده می کند.

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

تیمهای خود سازمانده و غیررسمی را که درAgile مورد تاکید قرار گرفته است می توان به عنون یک از عوامل موثر بر اثر بحشی ارتباطات نام برد.

سادگی

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

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

رابطه بین ارتباط و سادگی: سادگی نیاز به ایجاد ارتباط را کاهش می دهد.

فیدبک

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

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

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

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

شجاعت

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

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

تغییرات را باید پذیرفت اما نه کورکورانه. تکینک های XP را به کار ببندید تا اعتمادتان به این تکنیکها افزایش پیدا کند. در این صورت به خودی خود، جسارت به کار بستن این تکنیک ها و ائده های جدید را پیدا خواهید کرد.

احترام

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

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

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

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

ضایعات نرم افزاری

ارسال شده در تاریخ آوریل 29, 2010 Agile, مهندسی نرم افزار

با شنیدن کلمه ضایعات چه چیزی به ذهن شما رسوخ می کند؟ نان خشکی، ضایعات آهن، کاغذی که الان در حل مچال کردن آن هستید و یا هزاران چیز دیگر. تعریف شما از کلمه ضایعات چیست و چه چیزی را زائد می نامید؟

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

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

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

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

نرم افزار تویوتا
Extra features (تولید پیش از حد) Overproduction
Requirements (موجودی پیش از حد)Inventory
Extra Steps () Extra processing steps
Finding Information (جابه جایی غیر لازم) Motion
Bugs not caught by tests (معایب) Defects
Waiting for decisions, Including customers (انتظار)Waiting
Handoffs (حمل و نقل غیر ضروری) Transportation

از میان این هفت مورد کدام یک از آنها مهم تر است و باید فورا در جهت حذف آن اقدام کنیم؟ اکثر صاحبنظران توسعه نرم افزار  روی گزینه ویژگیهای اضافی (Extra features) توافق دارند. ویژگیهای اضافی! ویژگیها و عملکردهای از نرم افزار که مشتری از آنها استفاده نمی کند یا به ندرت از آن استفاده می کند.  طبق بررسی های انجام شده تقریبا فقط 20 درصد از ویژگیها و عملکردهای یک نرم افزار به طور مکرر استفاده می شود و 45 درصد از آن تقریبا اصلا استفاده نمی شود و 35 درصد آن به طور کم مورد استفاده قرار می گیرد، یعنی همان قانون هشتاد و بیست.

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

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

اما راه حل چیست؟

Ebey، شنیدن این کلمه شما را یاد چه چیزی می اندازید ؟ فروشگاه، خرید اینترنتی و شاید پیر امیدیار هموطنمان. اما اکثر ویژگیهای Ebay  چگونه توسعه داده شد؟ به شکل بسیار زیبا.  مشتریانی که پیشنهادی برای بهبود سایت داشتند (پیشنهاد مشتری = ارزش ) یک ایمیل به امید یار می فرستند و در سربعترین زمان ممکن آن ویژگی پیاده سازی می شد. نه نیازی به مرحله زمانبر تحلیل و طراحی فرآیندهای کلاسیک هست و نه در انتها خبری از ضایعات نرم افزاری.

مثال بالا یک نمونه ساده از چیزی که ما می خواهیم بدان برسیم بود، یعنی Agile. ما در اینجا به جای مشتریانی که برای امیدیار ایمیل می زدند Product owner یا on-site customer خواهیم داشت، به جای ایمیل ها، Story User ها که همراه با Product owner تهیه کردیم و توسط تیم اولویت بندی کردیم داریم و اجازه بدهید با کمی تحفیف Inbox را با Task Board یا Epic Board مقایسه کنیم و فیدبک کار را ایمیل مجدد یک مشتری در نظر بگیریم. اینها حداقل های هستند که با قرار دادنشان در جعبه ابزار خود و همراه کردن آن با یک فرآیند افزایشی می توانیم به فکر حذف ضایعات محصول خودمان باشیم و تصور یک فرآیند چابک را داشته باشیم. (چرا گفتم تصور؟ با اعتقاد به اینکه Agile یک فرهنگ است برای پاسخ، به نوشته زیر که بر گرفته از راه تویوتا است مراجعه کنید. )

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

حالا اگر در جعبه ابزار شما ابزارهای بالا همراه با ابزارهاي و تكنيك هاي بهبود كد و تست هست و یک تیم همراه با Product owner یا on-site customer چگونه به نبرد با این ضایعات خواهید رفت؟ اگر در جعبه ابزار شما ابزار دیگری هست که ریشه در خلاقیت تیمی شما دارد آنها را بیان کنید تا ما نیز آنها را در جعبه ابزار خود قرار دهیم. پس اجازه بدهید جعبه ابزار خود را باز کنیم و تا پست بعدی بدنبال یک راه حل خوب باشیم.

چگونه به سمت Agile حرکت کنیم؟ (قسمت سوم – اصول چهاردگانه تویوتا – Lean )

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

در پست قبل، نگاهي به تاريخچه تويوتا داشتيم. در اين پست چكيده اي از 14 اصل روش كاري تويوتا را بيان خواهيم كرد كه اين 14 اصل مي تواند يكي از پايه هاي اصلي فرهنگ Agile باشد.

چکیده ای از چهارده اصل روش کاری تویوتا

بخش اول: فلسفه بلند مدت

اصل اول: تصمیماتی مدیریتی خود را بر پایه فلسفه بلند مدت بنیان نهید، حتی به قیمت اهداف کوتاه مدت مالی.

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

· برای مشتری، جامعه و اقتصاد ارزش ایجاد کنید – این نقطه آغاز کار است. هر عملکردی را در شرکت بر حسب توان آن در رسیدن به این هدف، مورد ارزیابی قرار دهید.

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

اصل دوم: شیوه کاری پیوسته ای ایجاد کنید تا مشکلات را پدیدار کند.

· شیوه های کاری را برای دستیابی به ارزش افزوده بالا و جریان کار پیوسته، مجددا طراحی کنید. سعی کنید میزان زمانی را که هر پروژه کاری ساکن و بی استفاده می ماند یا منتظر کسی است که روی آن کار کند، به صفر کاهش دهید.

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

·         جریان کار را در سراسر فرهنگ سازمانی خود نمایان سازید. ای امر کلید روند اصلاح مداوم و صحیح و پیشرفت افراد است.

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

· آنچه را مشتریان در فرآیند تولید می خواهند، در زمانی که می خواهند، و به میزانی که می خواهند، برای آنان فراهم کنید. تجدید و تکمیل مجدد که با مصرف آغاز می شود، بنیان اصل “درست به موقع” است.

· با ذخیره مقداری اندک از هر محصول و ذخیره محدود آنچه مشتری از موجودی انبار برداشته و کم کرده است، کار خود را در انبارداریکالا کاهش دهید.

· بیشتر پذیرای تغییرات هر روزه تقاضای مشتری باشید تا متکی بر سیستمها و برنامه های زمانبندی کامپیوتری برای پیدا کردن موجودی بی مصرف در انبار.

اصل چهارم: حجم کار را ثابت نگه دارید (هیجونکا) (مثل لاک پشت کار کنید نه مثل خرگوش)

· حذف زوائد، تنها یک سوم معادله دستیابی به موفقیت است.  برداشتن بار اضافی از دوش افراد و تجهیزات و بر طرف کردن بی نظمی در زمانبندی تولید به همان اندازه دارای اهمیت است.

اصل پنجم: فرهنگ توقف برای رفع مشکل را بوجود آورید تا همان بار اول وضعیت کیفیت روشن شود.

· کیفیت برای مشتری موجب ایجاد ارزش برای شما است.

· از تمام روشهای مدرن تضمین کیفیت استفاده کنید.

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

· سازمان خود را به سیستمهای حمایتی مجهز کنید تا به سرعت مشکلات را حل کنید و اقدامات متقضی را انجام دهید.

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

اصل ششم: وظایف استاندارد، اساس پیشرفت پیوسته و قدرت بخشیدن به کار است.

· برای حفظ پیش بینی پذیری، زمانبندی منظم، و بازده منظم عملکرد خود، همه جا از ارزشهای ثابت و قابل تکرار استفاده کنید. این امر اسا جریان کار و کوشش است.

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

اصل هفتم: از کنترل بصری استفاده کنید تا هیچ مشکلی پنهان نماند.

·         از یک نمایشگر دیداری استفاده کنید تا به افراد کمک نمایید که فورا بتوانند تشخیص دهند که آیا در شرایط استاندارد قرار دارند یا از آن منحرف شده اند.

·         اگر صفحه نمایشگر کامپیوتر تمرکز کارگران را به هم می زند از به کار بردن آن اجتناب کنید.

·         سیستمهای دیداری ساده را در محلی که کار انجام می شود، طراحی کنید تا مدوامت جریان کار و اعمال نفوذ را مورد پشتیبانی قرار دهید.

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

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

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

· با این وجود، افراد خود را تشویق کنید تا هنگام بررسی رویگردهای تازه کاری، فناوری های جدید را مورد توجه قرار دهند. اگر یک فناوری جدید از عهده آزمونهای متعدد بر آمده و می تواند جریان کاری شما را بهبود بخشد به سرعت آنرا مورد استفاده قرار دهید.

بخش سوم: با بسط و گسترش افراد و شرکا به ارزش سازمان خود بیفزایید

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

·         بکوشید رهبرانی را از درون سازمان پرورش دهید، تا اینکه آنان را از خارج سازمان خریداری کنید.

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

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

·         فرهنگی با ثبات و قوی ایجاد کنید که در آن ارزشها و باورهای شرکت به طور گسترده ای بین افراد مشترک باشد و در طول سالیان دراز از بین نرود.

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

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

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

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

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

اصل دوازدهم: برای درک کامل شرایط، بروید و خودتان از نزدیک ببینید (گنجی گنباتسو).

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

·         بر اساس اطلاعاتی که شخصا مورد بررسی قرار داده اید، فکر کنید و سخن بگویید.

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

اصل سیزدهم: تصمیماتی را به آهستگی با رای اکثریت و با در نظر گرفتن تمام گزینه های ممکن، اتخاذ نمایید و با سرعت به تصمیمات عمل کنید.

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

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

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

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

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

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

· از هنسی (انتقاد و بازتاب) در مراحل مهم و پس از اینکه پروژه ای را به اتمام رساندید، برای تشخیص آشکار تمام کاستی های آن پروژه، استفاده کنید. برای اجتناب از انجام مجدد همان اشتباهات، اقدامات متقضی را انجام دهید.

· بهتر از طریق مرسوم کردن بهترین شیوه ها، کار را بیاموزید تا اختراع مجدد چرخ در هر پروژه جدید و با هر مدیر جدید.

اينها خلاصه اي از چهارده اصل  راه تويوتا بودند كه اساس خط توليد تويوتا يا توليد ناب را تشكيل مي دهند. در پست هاي بعدي نمونه هاي از كاربرد اين اصول را صنعت نرم افزار بررسي خواهيم كرد.

يك چهارده اصل ديگر نيز به نام 14 اصل دمينگ وجو دارد كه توسط ادوارز دمينگ بيان شده است، همانطوريكه در پست قبلي نوشتيم مديران تويوتا هنگام طراحي خط توليد تويوتا تحت تاثير نظرات ايشان قرار گرفتند و نظرات ايشان را در كار خود تاثير دادند. همانند تويوتا، Agile نيز از نظرات ايشان و اصول 14گانه دمينگ تاثير گرفته است. براي آشنايي با ادوارز دمينگ و 14 اصل آن مراجعه كنيد به ويكي پديا.

راه تویوتا

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

به تصوير پايان نگاه كنيد، آيا اين مرد را مي شناسيد، آيا دليل تعظيم اين مرد را در يك كنفراس خبري مي دانيد؟ شايد اگر اهل دنبال كردن اخبار باشيد، حتما اين تصوير را ديده ايد و از جريان آن آگاه هستيد. ولي اگر اهل دنبال كردن اخبار نيستيد، بدانيد اين مرد كسي نيست جز آكيو تويودا رئيس شركت خودروسازي تويوتا. او در يك كنفراس خبري بخاطر اشكال فني كه در خودروهاي شركت وجود داشت برابر همه حاضران تعظيم مي كند و از همه مشتريان خود معذرت خواهي مي كند. اين مديران در چه فرهنگي رشد كردند و آموختند كه حق هميشه با مشتري است. چه فرهنگ و طرز فكري بر اين شركت بزرگ حاكم است كه اينهمه به كيفيت ارج مي نهاند و در برابر همه طوفانهاي اقتصادي جهان استوار و پابرجا هستند.

قبل از اينكه به قسمت سوم “چگونه به سمت Agile حركت كنيم؟” برسيم، فكر كردم بهتر باشد قبل از اينكه به اصول چهاردگانه خط توليد تويوتا برسيم و يا همان اصول مبناي Lean، نگاهي به تاريخچه اين شركت داشته باشيم و ببينيم اين اصول از كجا و چگونه شكل گرفته اند. قبل از اينكه انديشه ها را ياد يگيريم، چگونه انديشيدن اين مردان بزرگ عالم مديريت و توليد را نيز بررسي كنيم.

خلاصه اي از تاريخچه تويوتا

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

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

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

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

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

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

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

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

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

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

اين خلاصه اي از تاريخچه شركت خودروسازي تويوتا بود كه در كتاب راه تويوتا آمده است (البته اين خلاصه اي از يك فصل كتاب بود توسط من). نتيجه گيري از اين خلاصه بعهده خود دوستان، براي حل مساله خودتان برويد و ببينيد.

چگونه به سمت Agile حرکت کنیم؟ (قسمت دوم – سازمانهای یادگیرنده)

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

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

یک سازمان یادگیرنده، چگونه سازمانی است؟

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

به‌ نظر ‌داجسون‌ سازمان‌ يادگيرنده‌ سازماني‌ است‌ که‌ با ايجادساختارها و استراتژي‌ها به‌ ارتقاي‌ يادگيري‌ سازماني‌ کمک‌ مي‌کند و داراي‌ توانايي‌ ايجاد، کسب‌ وانتقال‌ دانش‌ است‌ و رفتار خودش‌ را طوري‌ تعديل‌ مي‌کند که‌ منعکس‌ کننده‌ دانش‌ و ديدگاههاي‌ جديد باشد. مايکل‌ جي‌. مارکوارت در کتاب‌ ارزنده‌ خود به‌‌عنوان‌ « ساختن‌ سازمان ‌يادگيرنده‌» ، تعريف‌ نسبتاً جامعي‌ ارائه‌ کرده‌ است‌: «در تعريف‌ سيستماتيک‌، يک‌ سازمان‌ يادگيرنده‌ سازماني‌ است‌ که‌ باقدرت‌ و به‌ صورت‌ جمعي‌ ياد مي‌گيرد و دائماً خودش‌ را به‌ نحوي‌ تغيير مي‌دهدکه‌ بتواند با هدف‌ موفقيت‌ مجموعه‌ سازماني‌ به‌ نحو بهتري‌ اطلاعات‌ را جمع‌آوري ‌، مديريت‌ و استفاده‌ کند.»

ساختن محيطي يادگيرنده و افزايش شايستگي و قابليت منابع انساني، لازمة ايجاد هر سازمان يادگيرنده است که هر عضو آن هر لحظه به دنبال يافتن اطلاع از نياز براي تغيير، کسب اطلاعات و دانش لازم، ارائه ايده مناسب و به‌کارگيري آن ايده در عمل، براي تطبيق دادن خود و سازمان با تغييرات ايجاد شده در محيط خارجي است. مديريت منابع انساني براي مديريت دانش بستري فراهم مي کند که در آن کسب اطلاعات و دانش و به اشتراک گذاشتن آن در سرتاسر سازمان نهادينه مي‌شود و زمينه را براي ايجاد سازماني يادگيرنده فراهم مي‌سازد.

دیسیپلین پنجم

شاید اگر بخواهیم درباره خاستگاه نظریه سازمانهای یادگیرنده سخنی به میان بیاوریم، باید از دانشگاه MIT نام ببریم و از کتاب دیسیپلین پنجم (دیسیپلین پنجگانه، فرمان پنجم نیز ترجمه شده است) که توسط اساتید این دانشگاه به رشته تحریر در آمده است و به عنوان یکی از مراجع اصلی این نظریه به شمار می رود. در این کتاب سنج نویسنده کتاب ویژگیهای زیر را به عنوان ویژگیهای سازمانهای یادگیرنده بیان می کند:

peter senge the fifth discipline.pdf

داشتن دیدگاه مشترک (Shared vision): ايجاد ديدگاه مشترک يعني بنا شدن حس تعهد در گروه و ايجاد تصوير مطلوب از آينده با ويژگي پاسخ‌گويي فردي – که منجر به احساس تعهّد و مسئوليت در تمامي اعضاي گروه مي‌شود – هم‌خواني دارد. به اين معنا که تک‌تک اعضا نسبت به يادگيري خود و ديگران مسئول و متعهدند. (فصل مشترک کتابهای که تا به امروز درباره سازمانهای موفق خوانده ام یک نقطه بود، آرمان مشترک. آرمان مشترک، نقطه مشترک هر اجتماع موفقی است حال این اجتماع یک تیم، یک شرکت یک سازمان و یا یک کشور باشد.)

تفکر سیستمی (System Thinking) : ايجاد تفکر سيستمي مستلزم شناخت صحيح از کل سيستم، شناسايي نقاط قابل بهبود، درک نقاط قوت و تدوين راهکارهايي براي حل مشکلات است. به اين معنا که گروه، اطلاعات را به بحث و تبادل‌نظر و مشورت مي گذارد و هر يک با ديد سيستمي به تفکر جمعي، بازخورد گروهي و در نهايت خلق راهکارهاي جديد و توليد دانش در يک موضوع و بستر اقدام مي‌کنند.

یادگیری تیم (Team Learning) : سازمانهای یادگیرنده با استفاده از ساز و کارهای گفتگو و بحث یادگیری گروهی را ترویج و در سازمان استمرار می بخشد. باید به گروهای سازمانی تفهیم شود که مجموع تلاش های آنان به عنوان یک گروه بیش از جمع مساعی تک تک آنها است. گروههای هماهنگ و منسجم می توانند به اتفاق هم یاد بگیرند و یادگیری آنان نیرویی شگفت آور برای رشد و پیشرفت به سازمان ارائه می دارد.

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

قابلیت های شخصی (Personal Mastery) : تسلط و قابليت هاي شخصي عبارت است از نظامي كه در آن فرد به صورت مستمر ديدگا ه هاي شخصي خود را روشن تر و عميقتر مي نمايد، انرژي و توان خود را متمركز مي كند، صبر و بردباري خود را گسترش مي دهد و بالاخره آنكه واقعيات را منصفانه و بي غرض درمي يابد. با چنين تعريفي، تسلط و تواناييهاي شخصي يكي از اركان اساسي در سازمان هاي فراگير است.

گفتگو (Dialog) و مباحثه (Discussion) :

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

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

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

متن بالا حداقل های درباره سازمان یادگیرنده بودند. ولی این مفاهیم چگونه در دل Agile جا می گیرند؟ برای نمونه شما موضوع بحث و گفتگو را در نظر بگیرید و انواع جلساتی که در تیم های Agile برای کارهای مختلف تشکیل می شود مقایسه کنید، برای نمونه تکنیک Planning Poker.

گزیده : در زندگی دو نفر باش: یکی برای خودت، یکی برای دیگران. برای خودت زندگی کن و برای دیگران زندگی باش.

تولد مجددت مبارک

ارسال شده در تاریخ مارس 20, 2010 Agile

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

تولد مجدد طبیعت می تواند تولد مجدد تک و تک ما نیز باشد، پس در سال نو تولد مجددت مبارک.

چگونه به سمت Agile حرکت کنیم؟

ارسال شده در تاریخ فوریه 17, 2010 Agile, مهندسی نرم افزار

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

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

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

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

البته در بحث های جداگانه سازمانهای یادگیرنده و تاریخچه و اصول تفکر ناب را مورد بررسی قرار خواهیم داد و شکل خاصی از Lean را که برای فرآیند توسعه نرم افزار ارائه شده است (البته هنوز بحث بر روی اینکه آیا آنرا یک فرآیند توسعه نرم افزار در نظر بگیریم یا به عنوان مجموعه ای از ابزارها که می تواند همراه با Agile بکار گرفته شود) نیز مورد بحث قرار خواهیم داد.

planning poker

ارسال شده در تاریخ نوامبر 30, 2009 Agile, مهندسی نرم افزار

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

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

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

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

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

آیا می توانیم از روش مشابه بالا برای تخمین زدن اندازه کارها در پروژه های نرم افزاری استفاده کنیم یا نه؟ پاسخ بله است. در متدلوژهای Agile ما تکنیکی به نام planning poker برای تخمین زدن داریم که تقریبا مشابه روش بالا می باشد. در این تکنیک به جای اینکه فقط مدیران کار تخمین را انجام بدهند، کل تیم یعنی مدیران، تحلیلگران، معمارها، مدیران پایگاه داده و …. با هم اینکار را نجام می دهند.

در این روش ما مجموعه ای از کارت ها داریم، که بر روی هر کدام از آنها عددی نوشته شده است. این اعداد در اکثر موارد سری فیبوناچی یا یک سری مانند سری مقابل 0,1/2,1,2,3,5,8,13,20,40,100 می باشد.

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

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

Question Until You Understand

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


“Accept the explanation you’ve been given. If you’re told where the problem lies, that’s where you look. Don’t waste your time chasing ghosts.”

Suppose there’s a major problem in an application, and they call you in to fix it. You aren’t familiar with the application, so they try to help you out, telling you the issuemust be in one particular module you can safely ignore the rest of the application.
You have to figure out the problem quickly, while working with people whose patience may be wearing thin.


When the pressure is on like that, you might feel intimidated and not want to question too deeply what you’ve been told too deeply. To solve the problem, however, you need a good understanding of the big picture. You need to look at everything you think may be relevant — irrespective of what others may think.


Consider how a doctor works. When you’re not well, the doctor asks you various questions—your habits, what you ate, where it hurts, what medication you’ve been taking, and so on. The human body is complex, and a lot of things can affect it. And unless the doctor is persistent, they may miss the symptoms completely. For instance, a patient in New York City with a high fever, a rash, a severe headache, pain behind the eyes, and muscle and joint pain might be dismissed as having the flu, or possibly the measles. But by probing for the big picture, the doctor discovers the hapless patient just returned from a vacation to South America. Now instead of just the flu, a whole new world of possible diagnoses opens up including dengue hemorrhagic fever.

Similarly, in a computer, a lot of issues can affect your application. You need to be aware of a number of factors in order to solve a problem. It’s your responsibility to ask others to bear with you—have patience—as you ask any questions you think are relevant.


Or, suppose you’re working with senior developers. They may have a better understanding of the system than you. But, they’re human. They might miss things from time to time. Your questions may even help the rest of your team clarify their thinking;your fresh perspective and questions may give others a new perspective and lead them to find solutions for problems they have been struggling with.

“Why?” is a great question. In fact, in the popular management book The Fifth Discipline: The Art and Practice of the Learning Organization, the author suggests asking no fewer than five progressive “Why?”s when trying to understand an issue. While that might sound like a policy oriented more toward an inquisitive four-year-old, it is a powerful way to dig past the simple, trite answers, the “party line,” and the usual assumptions to get down to the truth of the matter.


The example given in the Fifth Discipline Field Book for this sort of root-cause analysis involves a consultant interviewing the
manager at a manufacturing facility. On seeing an oil spill on the floor, the manager’s first reaction is to order it cleaned up. But the consultant asks, “Why is there oil on the floor?” The manager, not quite getting the program, blames the cleaning crew for being inattentive. Again, the consultant asks, “Why is there oil on the floor?” Through a progressive series of “Whys” and a number of employees across different departments, the consultant finally isolated the real problem: a poorly worded purchasingpolicy that resulted in a massive purchase of defective gaskets.


The answer came as quite a shock to the manager and all the other parties involved; they had no idea. It brought a serious problem to light that would have festered and caused increasing damage otherwise. And all the consultant had to do was ask, “Why?”


“Oh, just reboot the system once a week, and you’ll be fine.” Really? Why? “You have to run the build three times in row to get a complete build.” Really? Why? “Our users would never want that feature.”


Really? Why?

Why?

Keep asking Why. Don’t just accept what you’re told at face value. Keep questioning until you understand the root of the issue.


What It Feels Like

It feels like mining for precious jewels. You sift through unrelated material, deeper and deeper, until you find the shining gem. You come to feel that you understand the real problem, not just the symptoms.

Keeping Your Balance


· You can get carried away and ask genuinely irrelevant questions if your car won’t start, asking about the tires probably isn’t going to help. Ask “Why?” but keep it relevant.


· When you ask “Why?” you may well be asked, “Why do you ask?” in return. Keep a justification for your question in mind before you ask the question: this helps you keep your questions relevant.


· Don’t settle for shallow answers. “Because it used to…” is probably not a good answer.


· “Gee, I don’t know” is a good starting point for more research not the end of the line.

تست واحد (Unit Testing)

ارسال شده در تاریخ اکتبر 17, 2008 Agile, تست نرم افزار, مهندسی نرم افزار

به تصویر بالا نگاه کنید فکر می کنید کلاس دیاگرام بالا متلعق به کدام قسمت از یک نرم افزار است. شاید حدس زدن آن در اولین مرحله برای خیلی ها مشکل باشد پس لطفا بر روی تصویر کلیک کنید تا تصویر را با اندازه واقعی مشاهده کنید و از نام متدها قضیه را حدس بزنید. تمام کلاس های بالا برای تست متدهای کلاس های نرم افزار یا همان تست واحد (Unit Test)  طراحی و پیاده سازی شده است. شاید اگر به سورس بسیاری از نرم افزارهای مشهور دسترسی داشته باشید، حتما مشابه این کلاس ها را در یک پکیچ جداگانه در سورس خواهید یافت (تصویر بالا مربوط به مولفه منوی  RadControls از شرکت Telerik است که حنما اکثر توسعه دهندگان وب با محصولات این شرکت آشنا هستند). پس اجازه بدهید در پایین به بررسی اصول و نحوه پیاده سازی تست های واحد بپردازیم.

تست واحد (Unit Testing):

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

هدف و فلسفه تست واحد

ما از تست واحد استفاده می کنیم تا نشان دهیم که واحد مورد نظر کاری را که ما فکر می کنم انجام می دهد یا نه.

چرا باید تست واحد را انجام بدهیم؟

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

مزایا و منافع

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

1-      تست های واحد همانند یک سند اجرایی هستند که نشان می دهند شما انتظار دارید که کد نوشته شده در شرایط مختلف چگونه عمل کند. اعضای تیم می توانند برای درک عملکرد کد و اینکه چگونه آن را بکار ببرند به تست های واحد مراجعه کنند.

تست های واحد مستنداتی هستند که با تغییر و اصلاح کد بروز رسانی می شوند.

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

2-      به اشتراک گذاری کد با دیگران راحتتر است، چون اگر عضوی از تیم کد را طوری دستکاری کنید که درست کار نکند، اجرای تست ها با شکست روبرو می شود.

3-        با انجام تست های واحد، زمان انجام تست ها در سایر فازها کاهش می یابد.

4-      تست ها، انتظارات برنامه نویس را در مورد چگونگی عمل کردن یک قطعه کد، ارزیابی می کنند.

بهانه و مقاومت

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

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

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

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

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

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

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

(در قسمت بعدی به نحوه پیاده سازی تست های واحد و معرفی Nunit خواهیم پرداخت.)