جلسهٔ ۱۸ مرداد ۱۳۹۳
| جلسهٔ ۱۸ مرداد ۱۳۹۳ | |
|---|---|
| افراد شرکت‌کننده | موضوعات و فعالیت‌های پیشنهادی |
| یه‌انقلابی |
موضوع ۱: بررسی لزوم برگزاری جلسات هفتگی موضوع ۲: بررسی و مقایسهٔ اجمالی روش کار بنیاد دانش آزاد با متدهای علمی روز (متد مورد نظر = چابک) |
| علیرضا پورعابدین | |
| سعید علیجانی | |
| علی رستمی | |
| دانیال بهزادی | |
| اسحاق فدائی | |
| امیرحسین گودرزی | |
| پانته‌آ تورنگ | |
| حمید رضا قوامی | |
| سیدمحمدمسعود صدرنژاد | |
| دانیال صائبی‌پور | |
محتویات
دستورجلسه (مطالب مطروحه)
در این جلسه به دلیل حضور اعضای جدید و به منظور آشنایی بیشتر اعضا با یکدیگر، در ابتدا اعضا خود را معرفی کردند. در ادامه یه‌انقلابی به طرح فرضیهٔ شباهت روش فعالیت دانش آزاد و به خصوص بنیاد دانش آزاد با متد چابک پرداخت. قصد داشتیم تا لزوم برگزاری جلسات حضوری را هم در برنامه داشته باشیم که به علت کمبود زمان نشد اما محتویات فایل ارائه را در ادامه قرار خواهیم داد.
محتوای ارائه‌شده در زیر آمده است:
دو هدف دارم از گفتن این حرف‌ها:
۱- اولیش اینه که یک زمانی این ایراد به ما گرفته می‌شد که از روش‌های علمی برای پیشبرد کارهامون استفاده نمی‌کنیم و دلیل کند بودن یا موفق نبودن هم همینه. اما الان من دلیل موفق نبودن یا کند بودن فعالیت‌ها رو در تنها گزینهٔ باقی مونده که همون نبود انگیزهٔ کافی برای فعالیت افراد است، می‌دونم.
۲- اگر بتونیم از روش‌های علمی که در جهت افکار ما است و ناسازگاریی در روش و هدف با روش و هدف دانش آزاد ندارد استفاده کنیم، سرعت و راندمان فعالیت‌هامون رو بیشتر کردیم و توضیح قابل ارائه‌ای هم برای افراد دیگر داریم.
در ابتدا یه معرفی خیلی خیلی اجمالی از متد چابک ارائه می‌دم:
حرف اصلی متد چابک چیست؟
اجرای قطعه قطعه و متناوب
حذف اضافات در سریعترین زمان
پذیرش تغیرات در لحظه
روش ارتباط افراد در چابک چیست؟
برای رسیدن به هدف، چابک یک متد ارتباطی بین اعضای مرتبط در یک پروژه، طرح یا محصول در نظر گرفته که شرح این متد ارتباطی برای ما مهمه.
تذکر: متد چابک در اجرای پروژه‌هایی که در برابر تغییرات مقاوم هستند (هزینهٔ تغییر زیاد باشد)، کاربرد ندارد.
اول خود چابک رو توضیح می‌دیم و بعد روش ارتباطی چابک رو بررسی می‌کنیم.
توجه به این نکته که چابک سیستم مدیریت نیست و متد توسعه است و از دستهٔ روش‌ها و چگونگی‌ها است، نیز لازم است.
یه تعریف:
گروهی از متدهای توسعه مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه‌حل‌ها از طریق خودسازمان‌دهی و همکاری بین تیم‌های مختلف کاری، انجام می‌شوند.
مانیفست چابک به شرح زیر است:
۱- افراد و تعاملات بالاتر از فرایندها و ابزارها
- لزوم برگزاری جلسات حضوری
۲- نرم‌افزار کار کننده بالاتر از مستندات جامع
- بستر اجتماعی مهمتر از مقالات تشریحی
۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
- در یک بحث برنامه‌ریزی شده مثل یک ارائه، بحث‌های انجام شده در میان ارائه و مرتبط با ارائه از خود ارائه مهمتر است.
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم
- این جمله خیلی جالبه
افراد مهمترین نقش را در پیروزی یک پروژه دارند.
- این جمله رو بارها شنیدیم که افراد صاحب دانشی که به آزادی دانش اعتقاد دارن، مهمتر از دانش مکتوب آزاد هستند.
مقدمه:
در نرم‌افزار آزاد و دانش آزاد نقش مدیر، کارفرما و تولیدکننده محصول، طرح یا پروژه، به عهدهٔ تمامی افراد است. از این رو به عنوان مثال هر فرد در گروه تولید باید توانایی مدریت پروژه، طراحی پلن منفعت و تولید پروژه را داشته باشد.
ما در این قسمت فقط متد تولید محصول رو در نظر می‌گیریم و به باقی جنبه‌های موضع به طور جداگانه خواهیم پرداخت.
قسمت‌های مدیریت چابک:
مدیر پروژه = به عنوان مثال Scrum Master
کارفرما = به عنوان مثال Product Owner
توسعه‌دهندگان
Backlogها
اسپرینت (Sprint)
Planing Poker
Story
Story Pointها
کارفرما:
کارفرما در سیستم نرم‌افزار آزاد شامل:
افراد جامعه، که هیچ سفارش مستقیمی برای تولید محصول نداده‌اند
تولیدکنندگان (اسکرام مستر و تیم اجرای پروژه)، که خود اولین کارفرمای مستقیم محصول هستند می‌شود.
تهیهٔ Backlog:
قبل اسکرام می‌باشد و نقطهٔ شروع. یک لیست اولویت‌بندی شده از نیازمندی‌ها و ویژگی‌های مورد نیاز محصول و داستان‌ها.
تذکر: توضیح Story فراتر از هدف این نوشته است ولی برای پیاده‌سازی حتماً باید مطالعه شوند.
موردی که از توضیح Story که لازم است در اینجا عنوان شود، Story Pointها هستند که برآورد تیم از زمان لازم برای پیاده‌سازی هر Story است.
مورد دیگر توضیح در مورد شکل پیاده‌سازی نهایی هر Story است که یعنی در زمان ارائه به چه شکلی باید باشد.
در تهیهٔ Backlog همیشه باید سعی شود که خواست نهایی در لیست نوشته شود و نه راه‌حلی که برای دستیابی به یک خواست نهایی است. به عنوان مثال مشکلی که در محصول وجود دارد باید در لیست وارد شود و نه راه‌حل احتمالی حل مشکل.
در تهیهٔ Backlogها همیشه سعی شود تا به مفهوم‌ترین و ساده‌ترین شکل ممکن نوشته شده باشند تا برای تمامی (کارفرماها) افراد جامعه قابل فهم باشند.
در نرم‌افزار آزاد ما با پدیده‌ای مواجه هستیم به نام Idea Pool یا همان استخر ایده.
اگر تصمیم بگیریم به عنوان تولیدکننده، محصولی را برای اجتماع تولید کنیم که نیازی از آن را برآورده کند (دقیقاً مشابه یک تیم انحصاری که محصولی را برای مشتری خود آماده می‌کند که مسلماً مطابق با نیاز مشتری است وگرنه مشتری هزینه‌ای بابت محصول پرداخت نخواهد کرد) و سپس توقع حمایت از اجتماع داشته باشیم، بهترین روش رجوع به این استخرهای ایده است تا با نیازمندی‌های اجتماع آشنا شویم. اما ایرادی که در استخرهای ایده وجود دارد این است که هنوز تبدیل به Backlog نشده‌اند. یعنی هنوز از نظر درجهٔ نیاز جامعه، اولویت‌بندی نشده‌اند.
نتیجه‌گیری:
به عنوان یک تیم آزاد، ابتدا باید محصولات (مورد نیاز جامعه) و Backlog محصول را تهیه کنیم تا بتوانیم اولویت پیاده‌سازی آنها را مشخص کنیم.
اسپرینت (Sprint)
برگزاری جلسات به منظور پیاده‌سازی عملی طرح، پروژه یا محصول.
یکی از خصوصیات داشتن اسپرینت در پیاده‌سازی محصولات بزرگ است. بدون داشتن این فرایند، بسیاری از پروژه‌های بزرگ اصلاً پیاده‌سازی نمی‌شوند.
این مورد در نرم‌افزارهای آزاد بسیار متداول است. یکی از دلایلی که پروژه‌هایی که توسط یک توسعه‌دهندهٔ آزاد پیاده‌سازی می‌شوند موفق به اجرا می‌شوند، همین برگزاری جلسات اسپرینت است.
لابد الان می‌پرسید چگونه؟ اگر دقت کرده باشید قبلاً عنوان شد که در نرم‌افزار آزاد کارفرما و تولیدکنندهٔ محصول یکی است. پس در عمل جلسات اسپرینت در فکر تولیدکنندهٔ نرم‌افزار برگزار شده و خروجی آن پیاده‌سازی قدم‌به‌قدم محصول است. توضیح بیشتر را لازم نمی‌دانم.
مشکل اصلی در پروژه‌های آزاد هنگامی رخ می‌دهد که یک پروژهٔ بزرگ قرار است تا پیاده‌سازی شود. در این شرایط تولیدکننده به تولیدکنندگان و کارفرما به کارفرمایان تبدیل می‌شوند و این درحالی است که در اغلب موارد افراد توانایی تعامل با گروه را ندارند.
تذکر: در سیستم انحصاری تولید، به دلیل ایجاد انگیزه در تیم تولید توسط کارفرمای پروژه، تیم تولید سعی در ایجاد سازش و تفاهم با یکدیگر خواهد کرد البته تا جای امکان. حال آن که در نرم‌افزار آزاد به دلیل نبود عامل ایجاد انگیزهٔ خارجی، افراد گروه باید توانایی فعالیت گروهی را در خود داشته باشند. توضیح این که خصوصیات یک فرد برای فعالیت گروهی چیست در مقاله‌ای دیگر بررسی خواهد شد.
نکتهٔ دیگر در برگزاری جلسات اسپرینت در نرم‌افزار آزاد این است که تولیدکنندگان هم باید نقش خود را ایفا کنند و هم نقش کارفرمای محصول، طرح یا پروژه را.
یک اسپرینت خوب اسپرینتی است که بتواند یک قسمت از محصول، پروژه یا طرح هرچند بزرگ را، با توجه به توان تیم تولید، گستره، هزینه و زمان، پیاده‌سازی کند.
تنها اصلی که در خروجی یک اسپرینت باید لحاظ شود، کیفیت داخلی محصول، پروژه یا طرح است.
کیفیت داخلی آن چیزی است که معمولاً برای کاربر نهایی قابل مشاهده نیست و فقط مربوط به تیم تولید است و همیشه باید در بهترین حالت باشد.
کیفیت خارجی هم معلوم است آن چیزی است که کاربر نهایی مشاهده خواهد کرد. کیفیت خارجی را می‌توان در دستهٔ گستره قرار داد.
زمان جلسات برنامه‌ریزی اسپرینت ممکن است بیش از حد طول بکشد پس تنها کار اضافه کردن زمان جلسات بصورت جلسهٔ اضافه است و نه اضافه کردن زمان جلسهٔ فعلی. اگر اسپرینتی در جلسهٔ ۴ ساعت اول آماده نشده است، بهتر است جلسهٔ ۴ ساعت دوم را برگزار کنید.
زمانبندی جلسات می‌تواند کمک‌کننده باشد تا از زمان جلسه بهتر استفاده شود.
طول مدت اسپرینت کوتاه مورد علاقهٔ کارفرما و بلندمطلوب توسعه‌دهندگان است اما از آنجا که در دانش آزاد هر دوی این گروه‌ها اغلب مشترک هستند، چگونه باید طول اسپرینت را انتخاب کرد.
طول کوتاه و بلند هر کدام مزایا و معایت خود را دارد.
هر اسپرینت بهتر است دارای هدف باشد. تعیین هدف هم از دید کارفرما و هم از دید توسعه‌دهندگان کاری مشکل است.
در دانش آزاد امکان نبود هدف خیلی خیلی کمتر (نزدیک به صفر) از مشخص نبون چگونگی رسیدن به آن است. همیشه این احتمال را می‌دهیم که راه بهتری برای رسیدن به هدف وجود دارد، به همین دلیل هم از روش‌های بالا استفاده می‌کنیم حال اگر هدفی نباشدبرای چه فعالیت کنیم!
در صورتی که هدف اسپرینت خودبه‌خود به دست نیامد، می‌توانیم از راه‌های کمکی کمک بگیریم. به عنوان مثال:
چرا من در این جلسه حضور دارم؟ چرا به جای آن در حال تفریح و لذت بردن از زمان خود نیستم؟
برآورد زمانی Planing Poker:
همانطور که در متد چابک به دلایل واضح زیر، حضور همهٔ توسعه‌دهندگان در هنگام برنامه‌ریزی زمانی لازم است، در دانش آزاد نیز این کار لازم است. دلایل:
۱- دقیقاً مشخص نیست چه کسی قرار است چه قسمتی از کار را انجام دهد.
۲- معمولاً برای پیاده‌سازی یک بخش چندین تخصص لازم است.
۳- در زمان برنامه‌ریزی به منظور وضوح بیشتر سؤالاتی پرسیده می‌شود که این باعث بالا رفتن دانش جمع می‌شود. به عنوان مثال تفاوت برد ترللوی جشن روز آزادی با جشن ۲۰۰ لاگ.
۴- وجود افراد بیشتر موجب نظرات متفاوت می‌شود که برای یک برآورد همه‌جانبه نیاز است.
حال سؤال اینجا است که پیاده‌سازی یک چنین شراطی در دانش آزاد مستلزم قرار دادن خروجی تیم توسعه در اختیار کل افراد جامعه است و با توجه به دور بودن افراد جامعه از محیط، سطح دانش و تفکر تیم توسعه، هرچه مفهوم‌تر بودم این به‌اشتراک‌گذاری بر مشارکت جامعه خواهد افزود.
تذکر: اطلاعات بالا با مستندسازی کاملاً تفاوت دارد و بیشتر برابرسازی یا مجازی‌سازی شرایط برای جامعه است.
تذکر: هرچه این کار بهتر انجام شود، سرعت پیاده‌سازی بالاتر خواهد رفت و جبران نقاط ضعف سیستم خواهد بود.
یادمون می‌مونه که هیچ چیزی رو تو لیست اسپرینت تغییر ندیم، چون تمرکزمون رو از بین می‌بره
آخرین جلسه بعد از اتمام هر محصول فرصتی با ارزش برای بهبود عملکرد تیم می‌باشد:
کدامیک از عملکردهای ما درست بود
کدامیک از عملکردهای ما نیاز به اصلاح دارد
چه بهبودهایی را می‌توان برای آینده در نظر گرفت
در روش دانش آزاد این مرحله بصورت آنلاین و در تمام زمان طول پروژه قابل انجام است. این کار به هدف نهایی متد چابک که همان تغییرپذیری حداکثری در طول طراحی و پیاده‌سازی پروژه است، نزدیک‌تر است.
داستان‌ها: هر محصول، پروژه یا طرح را به قسمت‌های کوچکتر قابل انجام تقسیم می‌کنیم. به این تقسیم‌ها که هر کدام از اهمیت مختلفی برخوردارند را داستان می‌گوییم.
حال ممکن است که هر داستان با درجه اهمیت مختلف، دارای اجزای بزرگ‌تری برای اجرا و پیاده‌سازی باشد. در این موارد که داستان‌ها از اندازهٔ مشخصی بزرگ‌تر هستند، بهتر است تا آنها را به قسمت‌های کوچک‌تری تقسیم کنیم. اندازهٔ مشخص چقدر است: بستگی به نظر تیم دارد ولی می‌توان برای شروع آن را حداقل مدت زمان انجام یک اسپرینت (طول اسپرینت) در نظر گرفت.
هر داستان باید برای کارفرما و تیم توسعه، تعریف یکسان و مشخصی داشته باشد. بهتر است تعریف در همهٔ سطح‌های چیستی، چرایی و چگونگی به طور جداگانه واضح و یکسان شده باشد.
زمان پیاده‌سازی هر داستان Story Point از نظر همهٔ افراد تیم توسعه بهتر است یکسان باشد و برای این منظور می‌توان از روش‌هایی مثل Planning Poker بجای پرسش مستقیم استفاده کرد.
نکات جالب:
یک نیروی قوی لازم نیست که برنامه نویسی عالی باشد، بلکه کافیست که یک برنامه نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران، تعامل درست و سازنده با سایر اعضای تیم خیلی مهمتر از این که یک برنامه نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفقتر هستند از تعداد برنامه نویسی عالی که قدرت تعامل مناسب با یکدیگر را ندارند.
- این هم باز لزوم شخصیت افراد بر سطح دانش
نرم‌افزار بدون مستندات، فاجعه است. با این حال، مستندات زیاد از مستندات کم بدتر است. چرا؟ ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می‌گیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می‌شوند. بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نماید
- یعنی انتقال خصوصیات فردی اصلی دانش آزاد مهمتر از تحلیل عمیق مفاهیم است.
البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نماید.
- خب سعی می‌کنم یه طرحی با همین خصوصیات بنویسم
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال می‌دهیم. ما آنها را بخشی از تیم می‌کنیم و با تعامل نزدیک و رو در رو به آنها آموزش می‌دهیم
- این هم باز بر لزوم برگزاری جلسهٔ حضوری است.
- نرم‌افزار نمی‌تواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم‌افزاری که می‌خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده می‌کند، بسازند. اما این تعامل به کیفیت پایین نرم‌افزار و در نهایت شکست آن می‌انجامد.
پروژه‌های موفق بر اساس دریافت بازخورد مشتری در بازه‌های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به طور تنگاتنگ با تیم توسعه کار کرده و مرتباً اعمال نظر می‌کند
- اگر جامعه دانش آزاد رو نرم‌افزار فرض کنیم، همیشه در حال تغییر است. ارتباط مداوم با جامعه از لوازم جامعه دانش آزاد است.
توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم‌افزاری است. وقتی که طرحی را می‌ریزیم باید مطمئن شویم که به اندازه کافی انعطاف‌پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد.
- خب نرم‌افزار آزاد در عمل ثبت کرده که انعطاف‌پذیرترین مدل توسعه است. پس دانش آزاد هم باید دارای همین خاصیت باشد.
- اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمی‌کنند، قادر به برآورد مناسب خواهیم بودم.
- باید ببینیم در دانش آزاد می‌توان نیازهای ثابت پیدا کرد یا خیر.
یک استراتژی خوب برای برنامه ریزی این است که یک برنامه ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه ریزی کلی برای سه ماه بعد
- خب این زمانبندی برای هر پروژه فرق می‌کنه ولی نسبتش ثابته.
- همکاری نزدیک و روزانه بین افراد کسب‌وکار و تیم توسعه
- مکالمهٔ رو در رو بهترین شکل ارتباطات است (محل مشترک)
- پروژه‌ها در اطراف افراد باانگیزه، که باید به آنها اعتماد کرد، شکل می‌گیرند
- هر پروژهٔ آزاد در کنار افرادی شکل بگیرد که هم دغدغه آن را دارند و توانایی کافی. تشکیل تیم‌های مختلف.
- توجه مستمر به برتری فنی و طراحی خوب
- برتری تکنولوژی سیستم دانش آزاد در هر پیاده‌سازی
- سادگی- هنر به حداکثر رساندن کارهای انجام‌نشده- ضروری است
- کاری که جزو نقاط ضعف ما تا امروز است.
Self-Organize یا خود سازمانده هستند. از متد مدیریت Micromanagement یا مدیریت دستور-کنترل برای این تیم‌ها استفاده نمی‌شود و این تیم‌ها خود-سازمانده می‌باشند. در واقع به این تیم‌ها فقط گفته می‌شود که می‌خواهیم چه کاری انجام دهیم و نه اینکه بگوییم این کار را انجام بده و اینگونه هم انجام بده.
- روش فعالیت افراد در دانش آزاد هم دقیقاً خودسازمانده است + خودمدیریت.
یکی از نکات مثبت داشتن خروجی اجایل در پروژه‌های آزاد، امکان استفادهٔ بهینه از توان افراد خارج از گروه توسعه‌دهنده مشخص پروژه است. به این معنا که هر فرد یا افرادی از اجتماع در صورت علاقه خواست و توان کافی می‌تواند تا با برداشتن یک یا چند داستان، به پیاده‌سازی محصول، پروژه یا طرح کمک کنند.
برآورد سرعت واقعی اسپرینت یک تیم توسعه آزاد به مراتب از تیم‌های انحصاری کندتر است و دلیل این امر ضریب توجه تیم توسعه‌دهنده است.
نقاط ضعف یا تفاوت سیستم دانش آزاد با متد چابک:
بطور واضح نبود اسپرینت.
بطور نامشخص نبود product backlog
بطور واضح نبود محصول. البته طرح موجوده ولی محصول خیر.
ایراداتی که جلسات روزانه را تهدید کند:
- ارائهٔ گزارش به یک نفر= در راستای رفع این مشکل تیم‌ها اقدام به قرارگیری دایره‌ای در جلسات می‌کنند :)
- دیر کردن افراد = در جلسات بسیار پیش می‌آید که افراد دیر کنند یا غیبت کنند.
- بی‌میلی افراد به گوش دادن به صحبت‌های دیگران
- طولانی شدن جلسه
- آف‌تپیک
- کلاس آموزش شدن
رویکرد چابک اترن:
تو پروژه‌های کلاسیک گستره رو ثابت نگه می‌داریم. مثلا قراره یه بیمارستان بسازیم، گستره‌ش ثابته… یه بیمارستان کامله، با تعداد طبقه و زیربنای مشخص و مصالح تعیین شده و امثال اون‌ها. با هزینه و زمان طوری بازی می‌کنیم که به اون گستره برسیم. سعی می‌کنیم هزینه و زمان رو محدود نگه داریم، ولی اگه ببینیم مثلا وقت کم داریم، معمولا گستره رو کوچیک نمی‌کنیم (مثلا یه طبقه بیمارستان رو حذف کنیم، یا تاسیسات مکانیکیش رو بذاریم کنار)، یا بیشتر هزینه می‌کنیم، یا زمان بیشتر مصرف می‌کنیم. کیفیت رو سعی می‌کنیم ثابت نگه داریم، ولی خیلی وقت‌ها مجبور می‌شیم برای رسیدن به گستره کیفیت رو هم قربانی کنیم.
تو رویکرد چابک اترن (DSDM Aten) برعکس عمل می‌کنیم، یعنی هزینه و زمان و کیفیت رو از ابتدا مشخص و ثابت می‌کنیم و گستره رو کم و زیاد می‌کنیم.
خب ما تو سیستم دانش آزاد تا به حال همین سیستم رو انجام دادیم.
کاری که با گستره می‌کنیم اینه که با تکنیک اولویت‌بندی مسکو مدیریتش می‌کنیم:
حروفی که تو مسکو (MoSCoW) هستن ابتدای این عبارت‌هان:
Must have – اون بخش‌هایی از گستره که حتما باید تولید بشن و اگه نباشن محصول نهایی پروژه اصلا به درد نمی‌خوره.
Should have – اون بخش‌هایی از گستره که واقعا بودنشون لازمه، ولی اگه نباشن باز هم می‌تونیم از محصول نهایی پروژه استفاده کنیم، فقط ممکنه لازم باشه یه راه حل‌های جانبی برای بعضی کمبودها در نظر بگیریم.
Could have – اون بخشی از گستره که خیلی خوشمون میاد تو محصول نهایی باشه، ولی نباشه هم اتفاقی نمی‌افته.
Won’t have this time – اون چیزهایی که فعلا قصد نداریم تو محصول نهایی پروژه باشه؛ هرچند که ممکنه به نظر مرتبط بیاد.
از این روش تو پروژه‌هایی استفاده می‌شه که:
تغییرات و عدم قطعیت زیاد باشه
و تا وقتی کارفرما بخش‌هایی از کار رو ندیده باشه نتونه انتظارهای خودش رو به روشنی مشخص کنه
ایده‌ای که پشت همه این‌ها هست همون قاعده ۲۰/۸۰ هست؛ اینکه حدود ۸۰ درصد ارزش محصول نهایی پروژه با حدود ۲۰ درصد گستره اون ایجاد می‌شه. پس چرا:
۱. زیاد از حد زمان و هزینه رو صرف گستره‌ای کنیم که ارزش خیلی زیاد تولید نمی‌کنه؛ خصوصا تو پروژه‌های نرم‌افزاری که چرخه عمر محصولش خیلی کوتاهه.
۲. حواسمون باشه که توجهی که باید صرف عناصر پر ارزش بشن رو صرف عناصر کم ارزشی که جلب توجه می‌کنن نکنیم.
محتوای ارائهٔ لزوم برگزاری جلسات بنیاد دانش آزاد
متد رفتاری در جوامع دانش آزاد
یکی از مهمترین منابع در دسترس در جوامع آزاد، افراد هستند. این افراد دارای خصوصیات منحصربفرد دانش آزاد هستند.
در موضوع متد رفتاری چابک در دانش آزاد به این نکات اشاره کردیم:
تعریف چابک:
- چابک، گروهی از متدهای توسعه مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه‌حل‌ها از طریق خودسازمان‌دهی و همکاری بین تیم‌های مختلف کاری، انجام می‌شوند.
مانیفست چابک:
- ۱- افراد و تعاملات بالاتر از فرایندها و ابزارها
- لزوم برگزاری جلسات حضوری
- یک فرد با قابلیت همکاری تیمی بهتر یک متخصص
- انتقال دانش بوسیلهٔ نشستن کنار هم و کمک کردن به یکدیگر و بخشی از تیم کردن افراد جدید.
- همکاری نزدیک بین صاحبان محصول و تیم توسعه. ما ممکن است عضو تیم توسعه نباشیم ولی جزئی از صاحبان محصول هستیم.
خصوصیات افراد:
- افراد تیم خود سازمان‌دهنده هستند.
خصوصیات افراد:
۱- حرف زدن؛ که برای حرف زدن باید فکر کرد
۲- فکر کردن. برای فکر کردن باید مسئولیت داشت.
۳- تصمیم گرفتن
۴- انتخاب کردن؛ که برای انتخاب باید دلیل داشت و دلیل رو در جمع عنوان کرد یعنی توانایی تعامل با جامعه
۵- مخالفت کردن یعنی وقتی دلیل انجام کاری رو نمی‌دونی یا می‌دونی و باهاش مخالفی رو عنوان کنی و یه عضو منفعل نباشی
مسئله: آیا لزومی به تغییر خصوصیات افرادی که وارد جوامع دانش آزاد می‌شوند، وجود دارد؟
مسئله: برای تبدیل افراد جدیدی که وارد جامعهٔ دانش آزاد می‌شوند به افرادی با خصوصیات بالا چه راهکاری می‌توان ارائه کرد؟
مسئله: آیا راهکار پیشنهادی باید سازگاری با خصوصیات قبلی افراد داشته باشد؟ به عبارتی اگر تغییر دادن افراد باعث ایجاد دافعه در افراد شود آیا باید روش معتدل‌تری را انتخاب کرد؟
مسئله؛ آیا مسامحه با خواست افراد جدید و سازگاری (تغییر) سیستم دانش آزاد با توجه به خصوصیات قبلی افراد درست است؟
به منظور شناخت خصوصیات افراد جدید، نیازمند آن هستیم که زمان کافی و مکان مناسبی را برای شناخت این خصوصیات فرآهم کنیم
یکی از این زمان‌ها و مکان‌ها می‌تواند برگزاری جلسات حضوری باشد.
برگزاری جلسات حضوری به منظور افزایش دانش افراد یا انجام پروژه نیست بلکه به منظور آموزش عملی خصوصیات رفتاری دانش آزاد به افراد جدید، به عنوان یک روش انتقال دانش رفتاری است.
برگزاری جلسات حضوری در جوامع دانش آزاد:
قسمت‌های مختلفی را می‌توان در یک جلسه قرار داد اما از همه مهمتر حضور افرادی با خصوصیات دانش آزاد به عنوان محیط جلسه است.
این افراد لازم است تا:
۱- خود دارای خصوصیات دانش آزاد باشند و به آن روش عمل کنند
۲- به تعداد کافی در جلسه حضور داشته باشند
بعد از مواد لازم می‌رسیم به قسمت‌های یک جلسهٔ حضوری:
۱- شناخت خصوصیات افراد جدید به صورت تک‌به‌تک و سپس آموزش رفتار دانش آزاد به صورت عملی به افراد جدید که می‌توان از روش بحث آزاد برای این منظور استفاده کرد.
۲- تمرین روش رفتاری دانش آزاد برای افراد قدیمی
روش برگزاری جلسات حضوری:
پیشنهاد: به ازای هر نفر تازه‌وارد به حدود ۵ نفر که خصوصیات دانش آزاد را دارند و روش آموزش آن را نیز می‌دانند برای ایجاد بستر آموزشی احتیاج است.
در ابتدا لازم است تا ببینیم که فرد جدید جرات حرف زدن دارد یا خیر.
به دلیل آموزش دیدن افراد جدید در سیستم آموزشی آکادمیک احتمال زیادی دارد که در ابتدا افراد جرات حرف زدن نداشه باشند.
برای حل این مشکل می‌توان افرا جدید سوال پرسید و آنها را وادار به پاسخ دادن کرد.
پس تا اینجا ما به یک سری سوال احتیاج داریم.
در ادامه که مشکل حرف زدن و مشارکت فرد جدید حل شد، لازم است تا حرف زدن فرد جدید از روی تفکر باشد.
افراد جدید یا خود این خصوصیت را دارا می‌باشند یا به احتمال خیلی زیاد مشکل حرف زدن بدون فکر دارند که آن هم باز به دلیل سیستم آموزشی آکادمیک غلط است.
برای حل این مشکل باید بعد از هر حرف فرد جدید ازش دلیل حرفش را پرسید و به ظاهر مخالفت کرد تا فرد مجبور به ارائهٔ دلیل شود. این کار در روند حرف زدن فرد جدید اختلال ایجاد می‌کند ولی چاره‌ای نیست.
بعد حرف زدن و فکر کردن می‌رسیم به تصمیم گرفتن در زمان کار بر روی یک پروژه.
بخاطر سیستم غلط موجود در جامعه افراد، سریع به سراغ رای‌گیری می‌روند. چرا؟ تا از زیر بار:
۱- فکر کردن
۲- تصمیم گرفتن
۳- پذیرش مسئولیت تصمیمی که گرفته‌اند
شانه خالی کنند
در اینجا ما با استفاده از متد اجماع افراد را وادار به تصمیم گرفتن و پذیرش مسئولیت تصمیم‌شان می‌کنیم
به این صورت که باید تصمیم بگیرند که یا با تصمیم جمع مخالفت کنند یا خودبخود با تصمیم گرفته‌شده موافق شمرده می‌شوند و مسئولیت تصمیم گرفته‌شده به عهدهٔ آنان خواهد بود.
حال ممکن است افراد باز در این روش از زیر تصمیم گرفتن شانه خالی کنند که می‌توان از افراد جدید بابت موافقت با تصمیم جمع، دلیلشان را پرسید.
مسئله: در اینجا بعضی از افراد هستند که با وجود حرف زدن، تفکر کردن و تصمیم گرفتن، همچنان از زیر بار انتخاب کردن شانه خالی می‌کنند یه این معنی که همیشه منتظر می‌شوند تا پیشنهادات از طرف دیگر افراد مطرح شود.
برای حل این مشکل می‌توان از قدردانی جمعی و تشویق افرادی که نظرات جدید ارائه می‌کنند استفاده کرد. هرچند این موضوع به مرور با حضور در جوامع آزاد حل می‌شود.
یا در آن روی قضیه، با یک تصمیم مخالف هستند ولی اعلام نمی‌کنند.
؟این رو نمی‌دونم فعلا راهش چیه؟ جلسات هفتگی بنیاد دانش آزاد می‌تواند به دو منظور استفاده شود:
۱- هر هفته به عنوان طول زمان یک اسپرینت در نظر گرفته شود و عملاً جلسات هفتگی در حکم یک جلسهٔ برنامه‌ریزی اسپرینت باشد.
۲- جلسات هفتگی به عنوان جلسات اسکرام در نظر گرفته شود.
نکته‌ای که در اینجا باید مد نظر قرار گیرد، خروجی جلسات است. هدف از برگزاری جلسات می‌تواند موارد زیر باشد:
۱- قصد از برگزاری یک جلسه، آموزش خصوصیات فردی دانش آزاد به افراد جدید یا تمرین کار گروهی برای افراد قدیمی بنیاد باشد.
۲- به منظور پیاده‌سازی یک محصول، پروژه یا طرح باشد.
۳- ترکیبی از مورد یک و دو باشد. منطقاً مورد یک همیشه وجود دارد و به تجربه ثابت شده که موارد نادری وجود داشته که مورد دوم در جلسه مطرح نشده باشد.
با توجه به موارد بالا می‌توان گفت که جلسات هفتگی برای مورد اول، جلسهٔ اسپرینت هستند و برای مورد دوم جلسهٔ اسکرام.
سؤال مهمی که ما باید در هنگام حضور در جلسه از خود بپرسیم و برای آن پاسخ مشخص داشته باشیم. چرا من در این جلسه حضور دارم؟ چرا به جای آن در حال تفریح و لذت بردن از زمان خود نیستم؟
