بایگانی

نوشته های برچسب زده شده ‘Agile’

فریم ورک تعاملات – قسمت اول

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

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

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

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

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

فریم ورک تعاملات

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

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

تاریخچه DISC

فریم ورکی که من اکثر موارد برای تیم های مختلف توصیه می کنم  DISC نام دارد. احتمال دارد شما نیز با DISC  آشنایی داشته باشید. اما DISC  بسیار قدیمی تر از متدهای چابک و تفکر ناب هست و ریشه های آن به ۴۰۰ سال قبل از میلاد مسیح برمی گردد، زمانیکه بقراط رفتارهای انسان را مورد بررسی قرار داد و آنها را به چهار گروه تقسیم کرد.

در ۱۹۲۸ ویلیام مولتون مارستن کتابی با عنوان “The Emotions of Normal People” منتشر کرد، که در آن تئوری DISC را تشریح کرد. در طول این سالها، شرکتهای متعددی تاییدیه های آماری و بهبود مستمر را بر روی DISC ارائه کرده‌اند.

تعریف DISC

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

The D—Dominator

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

Dهای مشهور: جورج بوش، مارگارت تاچر، پوتین، مایکل جردن و رابرت دنیرو.

The I—Influencer

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

Iهای مشهور: بیل کلینتون، آندره آغاسی، استیو مارتین

The S—Supporter

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

Sهای مشهور: مادر تزار، مارتین لوتر کینگ، جان اف کندی

The C—Critical Thinker

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

Cهای مشهور: بیل گیتس، آلبرت انشتین، آلن گرین اسپن

آیا زمان یاد گرفتن فرا نرسیده است؟

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

بحث من در این پست بیشتر بر روی متدهای چابک است و بحث خود را با مثالی که مهندس مهرداد در یکی از پست های قبلی حود به آن اشاره کرده بود ادامه می دهم. در این مثال به فردی اشاره شده است که ادعا می کند که در سازمان آنها از متد XP استفاده می شود. و وقتی از او سوال می شود که از تکنیکهای XP  مانند Pair programming،Refactoring ، TDD و یاPlanning game  در سازمان آنها استفاده می شود یا نه؟ جواب این شخص نه است و اشاره می کند که آنها فقط هیچ چیزی را مستند نمی کنند. این دقیقا شبیه طرز تفکری است که در جامعه ما نسبت به متدهای چابک وجود دارد و من یک دلیل خوب برای وجود این طرز تفکر در این جامعه دارم. چون مستند نکردن هیچ چیز، تنها چیزی است که از این متدها می توان استنباط کرد که نیاز به هیچ آموزش و مطالعه ای ندارد و با یک تفسیر نادرست از بیانیه Agile می توان از این بیانیه استنباط کرد. آیا واقعا در متدهای چابک هیچ چیزی مستند نمی شود؟. “تو شروع  به کد نویسی کن، من میرم ببینم مشتری چه می خواهد!” این نقل واقعا به چه میزان با ذات متدهای چابک سازگاری دارد؟ آیا واقعا متدهای چابک فقط برای تیم های کوچک مفید هستند؟ بهتر است به سوالاتی که درباره Agile Planning مطرح می شود نپردازم.

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

Categories: Agile Tags: , ,

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

اولین دوره 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.

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

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

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

XP و YAGNI

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

Scrum و قلب آن (Product backlog)

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

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

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

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

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

توزیع Agile در سازمان

ما می خواهیم به سمت Agile حرکت کنیم، XP، Scrum، Lean، FDD، AUP و شاید دهها اسم دیگر در این دسته از متدلوژیها وجو دارد که من نمی دانم و نشیدنم. ما باید از بین این اسامی کدام را انتخاب کنیم، چگونه انتخاب کنیم و چگونه به سمت آن حرکت کنیم؟ تفاوت اینها نسبت به هم چیست؟ نقاط قوت و ضعف آنها نسبت به هم چیست؟

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

یک انتقاد

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

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

راه حل : تفکر سیستمی

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

سطوح سازمان

در کتابهای مدیریت، سازمان را از لحاظ سطوح مدیریت به سه سطح مختلف تقسیم می کنند :

۱-       سطح عالی (استراتژیک – راهبردی) : در این سطح مدیران وظیفه دارند اهداف بلند مدت، آزمانها و استراتژیهای سازمان را تعیین کنند.

۲-       سطح میانی : این سطح وظیفه دریافت دستورات و برنامه ها را از سطح عالی سازمان و تبدیل آن به برنامه میان مدت، برنامه هایی اجرایی و زمانبندی شده و ابلاغ آن به سطوح پایین تر را بهعده دارد.

۳-       سطح عملیاتی : این سطح مدیریت را سطح درگیر در فعالیت های اجرایی گویند. به عبارت دیگر وظیفه به اجرا گذاردن تصمیمات و دستورات مدیریت عالی و میانی را بعهده دارد.

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

توزیع Agile در سازمان

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

برای پوشش هر سه سطح سازمان، سه گزینه XP،  Scrum و Lean را انتخاب می کنیم و هر کدام از آنها را به یک سطح سازمان نگاشت می دهیم. Lean را به بالاترین سطح سازمان نسبت می دهیم یعنی زمانیکه بازگشت سرمایه و اهداف بلندمدت و استراتژی نمود پیدا می کند (به پست ۱۴ اصل راه تویوتا مراجعه کنید). برای سطح میانی، Scrum را به کار می بریم یعنی سطحی که باید به سازماندهی تیمی، مدیریت زمان و تحویل پروژه تمرکز کرد. سطح آخر یا عملیاتی، جائیکه واقعا XP با آن تکنیک ها و اصول زیبای خود می تواند به تمام نیازهای عملیاتی توسعه نرم افزار جواب دهد.

نظر شما درباره این راه حل و پاسخ چیست؟

نحوه توزیع Agile در سازمان

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

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

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

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

ارتباطات

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

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

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

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

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

سادگی

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

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

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

فیدبک

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

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

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

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

شجاعت

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

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

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

احترام

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

peter senge the fifth discipline.pdf

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

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

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

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

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

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

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

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

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

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

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