بایگانی

بایگانی برای دسته ی ‘مهندسی نرم افزار’

اندازه‌گیری پیچیدگی نرم‌افزار

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

تعداد مسیرها که آیسا می‌توانست برای رسیدن به هدفش را طی کند میزان پیچیدگی شرایط‌ش در نظر گرفتیم. در سال ۱۹۷۶ شخصی به Thomas McCabe متریکی را برای اندازه‌گیری پیچیدگی در نرم‌افزار به نام Cyclomatic complexity معرفی کرد. او نیز تعداد مسیرهای مستقلی که کل یک ماژول یا متد را پوشش بدهد به عنوان پیچیدگی آن در نظر گرفت. برای محاسبه تعداد مسیرهای مستقل در متد روشهای مختلفی وجود دارد، رسمی‌ترین روش برای این کار رسم گراف کنترل جریان آن متد می‌باشد. در تصویر زیر گراف کنترل جریان متد حستجوی باینری رسم شده است.

گراف کنترل جریان

گراف کنترل جریان متد جستجوی باینری

بعد از رسم گراف کنترل جریان با استفاده از فرمول زیر تعداد مسیرهای مستقل را محاسبه می‌کنیم.

Cyclomatic complexity = E – N + 2

تعداد یالهای گراف = E

تعداد گره‌های گراف = N

بر اساس تصویر بالا گراف کنترل جریان متد دارای ۱۲ گره و ۱۴ یال می‌با‌شد پس :

CC = 14 – ۱۲ + ۲ = ۴

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

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

if | while | for | for each | case | default | continue | goto | && | || | catch | ?: | ??

 

اگر حوصله رسم گراف و شمردن نقاط تصمیم‌گیری را ندارید، استفاده از ابزارهای که متریک‌های کد را محاسبه کرده و نمایش می‌دهند بهترین گزینه هست. یکی از بهترین گزینه‌ها برای اینکار می‌تواند XDepend باشد برای دات نت NDepend، برای جاوا JDepend و برای پی‌اچ‌پی می‌توانید از PDepend استفاده کنید.  البته اگر از ویژوال استودیو استفاد می‌کنید نیازی به نصب ابزار دیگری نیست می‌توانید از منوی ANALYAZ بر حسب نیاز خود یکی از دو گزینه مشخص شده در تصویر را انتخاب کنید و نتیجه را مشاهده کنید.

منوی اندازه گیری متریک‌های کد

منوی اندازه گیری متریک‌های کد

صفحه خروجی متریک‌های کد نرم‌افزار

صفحه خروجی متریک‌های کد

مقدار قابل قبول برای Cyclomatic Complexity یک متد چقدر هست؟

یک مقدار ایده‌ ال برای محدود کردن Cyclomatic Complexity در یک متد وجود ندارد. تا ۱۰ را یک مقدار قابل قبول برای یک متد میدانند. و با افزایش آن میزان پیچیدگی افزایش و در نتیجه آن تست پذیری و قابلیت نگهداری کاهش می‌یابد. بازه‌های زیر را SEI برای مقدار  Cyclomatic Complexity منتشر کرده است.

Cyclomatic Complexity سطح پیچدگی ریسک
۱-۱۰ ساده کم
۱۱-۲۰ نسبتا پیچیده متوسط
۲۱-۵۰ پیچیده زیاد
بزرگتر از ۵۰ غیرقابل تست خیلی زیاد

 

آیا ارتباطی بین مقدار Cyclomatic Complexity و تعداد تست‌های واحد (unit test)  وجود دارد؟

مقدار Cyclomatic Complexity برابر حداقل تعداد تست‌های هست که می‌توان نوشت تا تمام مسیر‌های برنامه را پوشش بدهد. یعنی اگر برای هر مسیری که مشخص شده هست یک تست بنویسیم می‌توانیم از پوشش تمام مسیرهای برنامه توسط تست‌هایمان مطمئن شویم. در پست بعدی سعی می‌کنم در مورد میزان پوشش تست‌ها (test coverage) بنویسم و درباره انواع پوشش تست‌ها توضیح خواهم داد.

به‌عنوان نمونه تست‌های نوشته شده برای مسیر ۱ و ۲ در متد جستجوی باینری در پایین نمایش داده شده است. سطرهای که با رنگ سبز مشخص شده است مسیر اجرای آن تست را نشان می‌دهد و سطرهای که با رنگ قرمز مشخص شده است سطرهای هست که آن مسیر پوشش نمی‌دهد.

مسیر ۱:  ۰->1->2->3->11

تست مسیر 1

تست مسیر ۱ در متد جستجوی باینری

مسیر ۲: ۰->1->2->4->5->6->11

 

تست مسیر 2

تست مسیر ۲ در متد جستجوی باینری

جیدوکا در فرآیند توسعه نرم افزار

۱۸ فروردین ۱۳۹۱ بدون دیدگاه

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

کیفیت، هزینه کم! این یک پارادوکس است. نه این یک پارادوکس نیست، بلکه این بسیاری از باورهای دورنی ما است که با واقعیت های عینی دنیا ما در تضاد است. امروز می‌خواهیم با استفاده از یک قانون و یک تکنیک این پارادوکس را در وجود خود از بین ببریم.

هزینه یک محصول معیوب، هر چه در خط تولید به جلو می رود، به نحوی چشمگیری افزایش می یابد. این جمله متن همان قانونی است که به آن اشاره کردیم. تصویر زیر که بر اساس نتایج بررسی های انجام شده برای اندازه گیری هزینه خطاهای فازهای مختلف پروژه های نرم افزاری در شرکت IBM، TRW، GTE و HP تهیه شده است، به روشنی بیانگر نتیجه حاصل از این قانون است. ‌برای اینکه به یک محصول معیوب اجازه ندهیم در خط تولید رو به جلو حرکت کند، چگونه باید عمل کنیم؟

نسبت هزینه رفع خطا و نواقص در هر مرحله

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

چگونه می توان جیدوکا را در دنیای توسعه نرم افزار بکار برد؟ اگر شما از توسعه تست گرا (TDD) یا تست واحد (Unit Test) در فرآیند توسعه خود استفاده می کنید، جیدوکا را به کار می‌برید. شما تست های مورد نظرتان را می نویسید، اگر آنها شکسته شدند، شما کد خود را اصلاح می کنید تا بتوانید تست‌ها را با موفقیت تمام پاس کنید. اگر شما به آزمونهای خودتان وفادار باشید تا حد امکان اجازه نخواهید داد که خطاها در فازهای  بعدی کشف شوند و هزینه اصلاح آنها به شدت افزایش یابد. اگر شما در فرآیند توسعه خود از یکپارچه سازی پیوسته (Continuous Integration) استفاده می کنید و به همراه آن از مفهوم فیدبک پیوسته (Continuous Feedback) استفاده می کنید از جیدوکا استفاده می کنید. هر زمانیکه عمل Build در سرور CI شما با شکست روبرو شد. سرور CI با مکانسیمی که شما برای فیدبک پیوسته در نظر گرفتید، نتیجه را به اطلاع اعضای تیم خواهد رساند و اعضای تیم شروع به رفع مشکل خواهند کرد. دو مورد اشاره شده، بیشتر

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

مکانسیم فیدبک پیوسته (Continuous feedback mechanism)

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

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

پا‌نوشت: تصویر اول از کتاب روش کاربردی تحلیل نیازمندی های نرم افزار نوشته دوستان عزیز یوسف مهرداد، پویا شهبازیان و مظفر ایراف برداشت شده است. تصویر دوم هم از کتاب Continuous Integration برداشت شده است.


من پشت سرم را نگاه می کنم، شما چطور؟

جدول زیر را در نظر بگیرید:

Daily Scrum Meeting

بدون در نظر گرفتن تعداد نفرات تیم یک جلسه زمان بسته (time-boxed) 15 دقیقه ای می باشد.

Sprint Planning Meeting

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

Sprint Review Meeting

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

Sprint Retrospective
Meeting

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

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

به مثالهای بالا اشاره کردم تا به جمله ای برسم که واقعا با آن مشکل دارم. یعنی این جمله : ” ﻧﻘﺶ ﻫﺎ ، ﻣﺼﻨﻮﻋﺎت ، روﯾﺪادﻫﺎ و ﻗﻮاﻧﯿﻦ اﺳﮑﺮام ﺗﻐﯿﯿﺮ ﻧﺎﭘﺬﯾﺮ ﻣﯽ ﺑﺎﺷﻨﺪ و ﻫﻤﭽﻨﯿﻦ ﭘﯿﺎده ﺳﺎزی ﺑﺨﺸﯽ از اﺳﮑﺮام ﻣﻤﮑﻦ ﻣﯽ ﺑﺎﺷﺪ و اﻟﺒﺘﻪ ﻧﺘﯿﺠﻪ ﺣﺎﺻﻠﻪ از اﯾﻦ ﻧﻮع ﭘﯿﺎده ﺳﺎزی اﺳﮑﺮام ﻧﺨﻮاﻫﺪ ﺑﻮد.”.
به نظر من وقتی در اسکرام از تغییر ناپذیری صحبت می شود ما در واقع با ذات و ماهیتی که اسکرام بر روی آن بنا شده است مخالفت می کنیم. پایه ها و زیر بنای اسکرام بروی تجربه گرایی بنا شده است، تجربه گرایی اعتقاد دارد که دانش از تجربه حاصل می شود. اجازه بدهید بر خلاف راهنمای اسکرام  تنها به همین چند کلمه اکتفا نکنیم و چند کلمه ای بیشتر درباره آن بدانیم. فرانسیس بیکن
 یکی از بنیانگذاران فلسفه تجربه گرایی است، او معتقد بود که علم زمانی به دست می آید که فرد محسوسات و جزئیات را به مشاهده و تجربه در آورد و برای
استخراج قواعد به کلیات جمع آوری مواد روی آورد. اما این جمع آوری مواد، مشاهده و تجربه را سرسری نباید گرفت، و با نهایت دقت و تامل باید به کار برد. وی در شناخت واقعیت ها بر محسوسات و تجربه اهمیت زیادی قائل بود و تاکید داشت که جهت شناخت معارف و کسب علم باید از تاکید بیجا و افراط بر گفته ها و نوشته های دیگر علما پرهیز نمود  و با تکیه بر دیدگاه و جهان بینی خود در راه تاسیس علم و معرفت قدم برداشت
 .پس بر اساس اصول پایه اسکرام یاد بگیریم که تنها به نوشته های روی کاغذ و قوانین مبدعان پایبندی بی اساس نداشته باشیم و اجازه بدهیم که این قوانین، رویدادها و نقش ها را با شرایط و فرهنگ خود تجربه کنیم و بر اساس تجربیات خود آنها را تغییر دهیم و برای تیم خود بهینه سازی کنیم.

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

۲٫       بازرسی (Inspection) : یک فرآیند کنترلی داشته باشید که بررسی کند که آیا رویدادها، قوانین و مصنوعات موجود در اسکرام به دلایل انتخابی شما پاسخگو است یا نه؟

۳٫       منطبق سازی (Adaptation) : اکر در حین بررسی متوجه شدید که یک رویداد ارزش خاصی برای تیم ایجاد نمی کند، آن رویداد را تغییر دهید و حتی حذف کنید. اگر با نقش های که در تیم اسکرام هست نمی توانید تمام مسائل خود را پوشش بدهید نقش های جدید برای حل مسئله خود به آن اضافه کنید.

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

گزیده:

The important thing is not your process.

The important thing is your process for improving your process.

تیم شما چقدر اسکرام هست؟

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

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

First, are you doing Iterative Development?

  • Iterations must be time-boxed to less than 4  weeks
  • Is the software completely tested and working at the end of an iteration
  • Can the iteration start before specification is complete

The next part of the test checks whether you are doing Scrum (in Nokia’s opinion):

  • Does the team know who the product owner is
  • Is there a product backlog prioritized by business value
  • Does the product backlog have estimates created by the team
  • Does the team generate its burndown charts and knows its velocity
  • Does the team have outside people disrupting the work of the team during the sprint

البته توجه شود که در بعضی از نسخه های این آزمون time-box را برای یک Iteration، ۶ هفته در نظر گرفته اند. اما در نسخه های که فقط متد اسکرام را در نظر داشتند همان ۴ هفته در نظر گرفته شده است.

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

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

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

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

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

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

Three Simple Truths

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.

نیازهای نیروی انسانی جامعه برنامه نویسان

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

۱٫ استفاده از فناوری روز و آموزش مداوم پرسنل

۲٫ عدم اضافه کار اجباری (در صورت اضافه کار، بایستی حقوق آن پرداخت شود)

۳٫ اعتماد و صداقت متقابل بین کارفرما و پرسنل و پرسنل با پرسنل

۴٫ شرایط محیط کار (امکان سفارش سازی محیط کار و استفاده از مبلمان کاری مناسب و استاندارد )

۵٫ امکان ترقی و رشد برنامه نویس در شرکت (در اکثر شرکتها امکان تغییر پست برای یک برنامه نویس در یک شرکت وجود ندارد، مگر اینکه به یک شرکت دیگر انتقال یابد.)

۶٫ عقاید مذهبی، سیاسی و … هر فرد بستگی به خود فرد دارد و نباید در شرایط کاری فرد تاثیرگذار باشد.

۷٫ مشخص بودن نقش و سمت فرد در شرکت

۸٫ تعادل ساعات کاری با درآمد

۹٫ اولویت بندی افراد بر حسب تخصص و تجربه آنها نه بر حسب مدارک دانشگاهی افراد

۱۰٫ ایجاد ثبات کاری و حس ثبات در پرسنل (تمدید به موقع قرارداد و داشتن اطلاعات کافی و به موقع نسبت به نیازمندی یا عدم نیاز شرکت به من در دوره های بعدی )

۱۱٫ هدفمند و علاقه مند بودن نیروهای قدیمی به گونه ای که باعث تهییج و تحریک نیروهای جوان و تازه کار شود. (حداقل خواسته عدم سنگ اندازی پرسنل قدیمی در برابر نیروی تازه کار)

۱۲٫ آگاهی کافی در مورد برنامه ها جاری و آتی شرکت و …

۱۳٫ تشویق پرسنل در قبال انجام کارهای خوب و خلاقانه

۱۴٫ محدودیت ها و شرایط بی مورد در زمان قرارداد یا در حین کار

۱۵٫ پرداخت قسمتی از قرارداد یا فروش به پرسنل به عنوان پاداش یا … (به قول آقای وحید نصیری: “هیچ حقی نسبت به کاری که انجام دادید ندارید. فقط حقوق آخر برجو بس. در حالیکه قسمت اعظم پروژه را شما انجام دادید”)

۱۶٫ توجیه نیروی تازه کار در مورد خط مشی شرکت، پروژه های در دست اجرا، روشهای تولید و پشتیبانی محصولات

۱۷٫ امکان نظارت پیوسته و منظم بر کار نیروها برای پیشرفت در انجام امور و بازدهی بهتر

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

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

تکمیل لیست نیازها و درخواست ها

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

یک روز خوب می آید که ….

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

۹ اردیبهشت ۱۳۸۹ ۱ دیدگاه

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

اجازه بدهید دوباره به تویوتا و خط تولید آن رجوع کنیم. تائیچی اونو از سیستم تولید تویوتا به عنوان سیستمی برای حذف کامل ضایعات از فرآیند تولید نام می برد. او ادامه می دهد ما اینکار را بدین صورت انجام می دهیم که زمان را از لحظه دریافت سفارش تا هنگام دریافت پول از مشتری در نظر می گیریم و در صدد هستیم که خط زمانی (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) توافق دارند. ویژگیهای اضافی! ویژگیها و عملکردهای از نرم افزار که مشتری از آنها استفاده نمی کند یا به ندرت از آن استفاده می کند.  طبق بررسی های انجام شده تقریبا فقط ۲۰ درصد از ویژگیها و عملکردهای یک نرم افزار به طور مکرر استفاده می شود و ۴۵ درصد از آن تقریبا اصلا استفاده نمی شود و ۳۵ درصد آن به طور کم مورد استفاده قرار می گیرد، یعنی همان قانون هشتاد و بیست.

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

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

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

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 )

۱۰ فروردین ۱۳۸۹ ۳ دیدگاه

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

راه تویوتا

۶ فروردین ۱۳۸۹ ۲ دیدگاه

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

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

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

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

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

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

تویودا پسرش کیچرو را در سال ۱۹۲۹ به انگلستان فرستاد تا حق اختراع دستگاه ریسندگی خود را به شرکت برادران پلیت بفروشد، آنها را روی رقم صد هزار پوند توافق کردند و در سال ۱۹۳۰ پایه های موسسه تویوتا موتور بر روی این سرمایه بنا نهاده شد.

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

تاسیس شرکت با جنگ جهانی دوم همزمان شد و آمریکایها برنده این نبرد بودند، اما شانس با تویوتا بود چون برای ساختن مجدد ژاپن نیاز به کامیون بود و اینکار به تویوتا سپرده شد.  اما در این سالها اشغال توروم رشد چشمگیری داشت و در سال ۱۹۴۸، دیون تویوتا ۸ برابر کل ارزش سرمایه آن بود. تویوتا برای جلوگیری از ورشکستگی، مذکراتی با کارمندان انجام داد و به جای اخراج آنها حقوق پرداختی کارمندان را ۱۰% کاهش داد. اما این راهکار نیز جواب نداد و ۶۰۰ نفر از کارکنان به صورت دواطلبانه از کار کنار گیری کردند و در انتها کیچرو مسئولیت ورشکستگی خودروسازی تویوتا را بعهده گرفت و از سمت رئیس شرکت استفعا داد بخاطر فلسفه بلند مدت شرکت.

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

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

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

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

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