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

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

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

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

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

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

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

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

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

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

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

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

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

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

یکی از کتابهای که واقعا از مطالعه آن لذت می برم، کتاب  پنجمین فرمان (The fifth discipline)  می باشد. در این منبع بحث خوبی بر روی موضوع یادگیری جمعی صورت گرفته است. یکی از عناوینی که در این کتاب مورد بحث و بررسی قرار گرفته، بررسی عناوین "گفتگو" و "مباحثه" می باشد. که من به دلیل اهیمت این موضوع، به قسمتهای از آن در پایین اشاره می کنم. و امیدوارم که بتوانم گفتگو و مباحث مفیدی را در جلسات خود تجربه کنیم.

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

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

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

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

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

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

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

ما باید به عنوان یک گروه یادگیرنده باید یاد بگیریم که چگونه بین بحث و گفتگو حرکت کنیم. هر کدام برای چه اهدافی بکار می روند و چه تفاوتهای باهم دارند. 

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

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

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

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

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

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

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

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

گزیده:

The important thing is not your process.

The important thing is your process for improving your process.

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

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

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

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

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

برای حل این مشکل شما چه راه حلی ارائه می دهید؟ یکی از راه حلهای بسیار خوب و ساده ای که برای حل این مشکل  وجود دارد استفاده از یک Not list است. یعنی در همان اول مشخص می کنیم که ما می خواهیم چیکارهای را در داخل این پروژه انجام بدهیم و به طور روشن نیز مشخص می کنیم که چه چیزهای را نمی خواهیم انجام بدهیم. برای انجام این کار می توانیم از جدول شبیه جدول زیر استفاده کنیم.

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

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

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

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

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

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

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

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