https://virgool.ir/feed/@k_niknafsمربی اجایل، توسعه‌دهنده نرم‌افزارfa2026-11-11 09:27:30https://files.virgool.ir/upload/users/182905/avatar/Vdkcc7.pnghttps://virgool.ir/@k_niknafshttps://virgool.ir/@k_niknafs/ذهنیت-اجایل-آرام-و-شجاع-باش-tlordkudz3rdذهنیت اجایلآرام و شجاع باشبعضی وقتا فکر می‌کنیم که تمام دنیا در مقابل ما ایستاده.در این مواقع است که شجاعت معنا پیدا می‌کنه و این شجاعته که ما رو در این مواقع آروم نگه میداره.وقتی آروم باشیم، می‌تونیم بدون هیچ ترسی با چشمان باز نقاط ضعف دشمنانمون رو ببینیم.از اون زمانی که با شمشیر با مشکلاتمون روبرو می‌شدیم خیلی وقته که میگذره اما چیزهای که باید باهشون مبارزه کنیم خیلی تغییر نکردن و برای مقابله باید جنگجوی درونمون رو بیدار کنیم.برای اینکار از مغزمون خیلی کاری برنمیاد و باید با تمام وجود از قلبمون پیروی کنیم. مکانی که جایگاه عشقه بدون تردید یک جنگجو واقعی درون اون زندگی می‌کنه.در اینصورته که می‌تونیم تمام دنیا رو وادار کنیم که جلوی ما زانو بزنه.حافظ چه خوب میگه:با دل خونین لب خندان بیاور همچو جامنی گرت زخمی رسد آیی چو چنگ اندر خروشعباس نیک‌نفسعباس نیک‌نفسSat, 23 May 2020 21:07:54 +0430https://virgool.ir/@k_niknafs/اجایل-و-شنا-z2kll7zfaujxبه نظر من اجایل و شنا خیلی شبیه هم هستند. هر دو در نگاه اول خیلی ساده به نظر می‌رسند. دستورالعمل شنا کردن خیلی ساده هستند، تنها کاری که باید انجام بدیم اینکه که با حرکت دستها و پاها به روشی ساده به جلو حرکت کنیم. همینطور وقتیکه به بیانه و یا اصول اساسی اجایل نگاه می‌کنیم به نظر خیلی ساده و بديهی به نظر می‌رسند و به خودمون میگیم چه عالی رعایت کردن و انجام این کارها خیلی ساده است. اما مثل شنا هنگامیکه اولین قدم رو در آب می‌گذاریم متوجه می‌شویم که داستان به این سادگیها هم نيست. مقدار زیادی تلاش، تمرین و شجاعت لازمه تا اینکه بتونیم فقط سرمون رو بالای سطح آب یک استخر راکد نگه داریم. اون وقته که تازه می‌فهمیم که شنا کردن رو نمیشه با خوندن کتاب یاد گرفت. ورود به یک پروژه پرچالش حتی با خوندن تمام منابع نوشته شده‌ی اجایل مثل این میمونه که بخوایم فقط با خوندن کتاب آموزش شنا در یک رودخونه خروشان شنا کنیم.عباس نیک‌نفسعباس نیک‌نفسThu, 07 May 2020 16:58:42 +0430https://virgool.ir/@k_niknafs/اسکرام-یا-xp-cfttai5l615lاسکرام یکی از محبوب ترین چارچوبهای اجایل در همه جای دنیاست و در این شکی نیست ولی آیا همه نیازهای یک تیم توسعه نرم‌افزاری رو برطرف میکنه و اگه صرفا از این چارچوب استفاده کنیم می‌تونیم صفر تا صد یک پروژه نرم‌افزاری رو با موفقیت جلو ببریم؟ بدون شک پاسخ دوستانی که تجربه اجرای عملی حتی یک پروژه رو داشته باشند منفیه چون که در اجرا متوجه شدن که اسکرام فقط بعضی از دیسیپلین‌های چرخه حیات نرم‌افزار رو پوشش میده.ولی برای اینکه نگاه دقیق تر و علمی‌تری به پوشش اسکرام از ارزشهای اجایل بصورت کیفی داشته باشیم بد نیست با استفاده از یک چارچوب بررسی کمی، ارزشهای اجایل اسکرام واکس‌پی رو با هم مقایسه کنیم. من اینکار رو قبلا در یک تحقیق با استفاده از چارچوب Quantitative Framework for the Evaluation of Agile انجام دادم و به خاطر اینکه از حوصله این نوشته خارج نشه خلاصه و ماحصل اون رو تویه این نوشته میارم.اين چهار چوب معيارهایی(سنجه‌هایی) رو بر اساس چهار ارزش کليدی اجایل تعريف مي‌کنه. اگر فرض کنيم که ارزشهای اجایل رو P در نظر بگيريم برای هر ارزش، تقابل دو مشخصه هر ارزش را با Pi.1  و Pi.2 نشون میده و معيار ارزيابی نهایی بر اساس فرمول زير بدست می‌یاد:m (Pi) = m (Pi.1) + m (Pi.2)         i=1..4برای مثال ارزش P1 نشون دهنده "ارزش افراد و تعاملات بالاتر از فرآيندها و ابزارها" با دو معيار اندازه‌گيری دو مشخصه "ارزش افراد و تعاملات" (P1.1) و معيار اندازه‌گيری مقدار "ارزش فرآيندها و ابزارها" (P1.2) میشه.مشخصه‌های هر ارزش با اولويت بالاتر در بيانه اجایل بصورت اعداد مثبت از 0 تا 5 سنجيده و ارزش با اولويت کمتر بصورت منفی از 5- تا 0 در نظر گرفته مي‌شن. بدين ترتيب هر اصل بيانيه اجایل در بدترين حالت مقدار 5- (یعنی مقدار 5- برای مشخصه منفی و 0 برای مشخصه مثبت) و در بهترين حالت مقدار 5 را خواهد داشت ( 0 برای مشخصه منفی و 5 برای مشخصه مثبت). اگر نتيجه مقدار صفر یا نزديک به صفرباشه نشون دهنده مشخصه مثبت (با ارزش بالاتر از ديد چابکی) به مقدار کافی بر مشخصه منفی (دارای ارزش کمتر از ديد چابکی) غلبه نمیکنه و شرط چابکی به مقدار کافی برقرار نمیشه.ارزش افراد و تعاملات بالاتر از فرآيندها و ابزارها      P1نرم افزار کارا بالاتر از مستند سازی جامع                 P2همکاری با مشتری بالاتر از قرارداد کاری                 P3پاسخ‌گویی به تغييرات بالاتر از پيروی يک طرح         P4در اینجا خیلی وارد نحوه محاسبه و جزئیات نمیشم. نتیجه پوشش کمی ارزش های اجایل اسکرام و اکس‌پی رو در نمودار زیر می‌بینیم.به وضوح ديده میشه که XP پوشش بهتری نسبت به اسکرام از ارزشهای کليدی اجایل دارهاسکرام از دسته روشهای مديريت پروژه‌گراست والبته اسکرام مزایای زیادی دارهاز جمله مزایای اسکرام میشه به موارد زیر اشاره کرد-    باعث استفاده بهینه از زمان و هزینه میشه-    قابليت شکستن پروژه‌های بزرگ به تکه‌های کوچکتری به نام اسپرينت رو داره که مدیريت پروژه‌های بزرگتر رو راحتر میکنه-    ماهيت اسکرام باعث اعمال نظرات ‌‌ذی‌نفعان و مشتريان در محصول نهایی بصورت تدریجی و در طول انجام پروژه می‌شه-    با انجام کارها در اسپرينت‌های با طول زمانی کم امکان بازخورد مشتريان رو اعمال میکنهاما متاسفانه اسکرام دارای معايبی و نواقصی هم هست که البته میشه با شناخت دقيق اونا رو برطرف کرد به‌گونه‌ای که مزاياش رو تحت تاثیر قرار نده . از جمله این نواقص می‌توان به موارد زیر اشاره کرد:-    تمرکز اسکرام بيشتر بر تمرينات مديريت پروژه متمرکز شده و در مورد مهندسی نرم‌افزار برای توليد محصول تمرينات ‌خاصی را مشخص نمی‌کنه و اصلا حرفی برای گفتن نداره-    اسکرام به کيفيت و کفايت اعضای تیم خیلی وابسته است، و در صورت وجود یک عضو با کیفیت کم دچار مشکل میشه-    در بسیاری موارد زمان و دامنه‌ی درگیر در پروژه اسکرام از قبل قابل تخمین نیست-    در اسکرام در مورد مستندات توسعه نرم‌افزار بصورت صريح صحبت نمیشه و کلا هر چیزی که مربوط به اجرای کار باشه اسکرام براش هیچ راهکاری ندارهدر شکل زیر پوشش جنبه‌های مختلف چرخه حیات نرم‌افزار توسط سه چارچوب اسکرام – XP و RUP رو می‌بینیم البته RUP از دسته متدولوژ‌های سنگینه (Heavy methodologies) و فقط برای شاخص پوشش در این نمودار نشون داده شده.خوب حالا با این اوصاف چه باید کرد؟البته اگر بنا بر انتخاب یکی از این دو بود من قطعا XP رو ترجیح می‌دادم چون XP واقعا برای توسعه‌دهندگان نرم‌افزار کاربردی تره و کسانی که درگیر اجرا و عملیاتی کردن پروژه هستن قدر ارزشهای کلیدی و تمرینهای ناب XP رو می‌دونن که به نظر من بدون وجود اونا واقعا کاری رو نمیشه پیش برد (جزئیاتش بمونه اگر خدا بخواد برای نوشته‌های دیگه) ولی خوشبختانه حداقل اینجا مجبور به انتخاب نيستم و از این خوان گسترده می‌تونیم به فراخور استفاده کنیم.خوب پس یک جواب میتونه استفاده از چارچوب ترکیبی باشه. چرا اسکرام و اکس پی رو با هم استفاده نکنیم؟ که البته خیلی‌ها هم در سراسر دنیا اینکارو میکنن.ترکيب و تلفيق اسکرام و XP یک ترکيب خوب و مناسب به نظر می‌رسه چرا که در XP تمرکز بر روی تمرين‌های مهندسی و استانداردهای توسعه است اما XP در راهکارهای مديريت پروژه چندان شفاف و قوی نیست و البته XP روی پروژه‌های با اندازه کوچک از کارایی زیادی برخورداره و کاملا" وابسته به مشتريانه که این موضوع ريسک شکست پروژه رو افزايش می‌ده از طرفی ديگه تمرکز اسکرام بر تمرين‌های مديريت پروژه است و در مورد تمرين‌های مهندسی نرم‌افزار حرفی برای گفتن نداره. این دو واقعا میتونن نقاط ضعف همدیگه رو پوشش بدن و نقاط قوت همدیگه رو تقویت کنند من به شخصه از ترکیب این دو در اجرای پروژه‌های مختلف در طول سالها استفاده کردم و بسته به شرایط نتیجه قابل قبول بوده البته این رو هم بگم که گر چه این دو روش با پوشش مناسب همدیگه روش خوبی رو برای ما به ارمغان میارن ولی در نهایت مسائل مهم دیگه‌ای در تولید نرم‌افزار وجود داره که هیچکدوم از این دو راهکاری برای اونا ندارن ؟!!!و باید جای دیگه به دنبال اونا بگردیم. شاید بشه در فرصتی دیگه در موردشون صحبت کنیم.عباس نیک‌نفسعباس نیک‌نفسTue, 05 May 2020 20:18:17 +0430https://virgool.ir/@k_niknafs/باورهای-نادرست-در-مورد-اجایل-m35qup6nsbgsاجایل یعنی سریع و ارزون !!!"ما باید اجایل باشیم چون با اجایل میتونیم یک کار معین رو خیلی سریعتر و ارزون تر انجام بدیم"همه بچه باحالها، این روزا اجایل کار می‌کنند.حالا که ما هم یک پروژه بزرگ داریم به جای روش آبشاری که طولانی و پرهزینه است چطوره اجایل کار کنیم سریع و ارزون! درسته؟ دیگه چی بهتر از این ?فکر میکردم بعد از گذشت این همه سال دیگه واقعا چنین جملاتی نشنوم.اول اینکه اجایل اصلا انجام پروژهای بزرگ و سنگین به این صورت رو قبول نداره. اجایل ما رو به حرکت از تفکر پروژه محور به تفکر محصول محور و از انجام کارهای حجیم و از قبل برنامه ریزی و زمان بندی شده به سمت انجام کارهای در اندازه هر چه کوچکتر تشویق میکنه. اصول توسعه اجایل بر توسعه افزایشی (incremental) و تکراری (iterative) بنا شده.اشتباه نشه، این به این معنی نیست که یک پروژه بزرگ با دامنه از پیش تعریف شده رو به تعداد زیادی مرحله بشکنیم که این مورد متاسفانه خیلی هم رایجه، بعضی وقتا حتی با دامنه نامشخص و ناواضحه!!! اگر اجایل رو اینجوری درک کنیم به خودمون و اجایل ظلم کردیم.اجایل میگه فقط با یک قدم کوچیک شروع کنیم بعد از اون یک قدم کوچیک دیگه رو تعریف و برنامه ریزی کنیم و تویه هر قدم   یاد ‌بگیریم و دامنه رو متناسب یافته ها تغییر بدیم و به قدم بعد بریم و همینطور رو به جلو حرکت کنیم.اجایل در واقع درکوتاه مدت حتی میتونه کمی کندتر باشه و این اصلا اشکالی نداره. اولویت اصلی اجایل توسعه نرم افزار باکیفیت و با ساختار فنی درسته برای همین در اجایل کلی زمان صرف بازنگری کدها، ساختارها و نیازمندیهای کسب و کار میشه و این هزینه رو با کمال میل می‌پذیره و این در واقع به این معناست که اجایل در تحویل ویژگیهای مورد نیاز حتی تا حدودی کند عمل میکنه و این درست در مقابل جمله "سریع و ارزونه" چون نرم‌افزار سریع و ارزون معادل نرم‌افزرای کم کیفیت و پر از اشکال و خطاست.کیفیت ضعیف و خطاها و مشکلات نامشخص معمولا حاصل اجرای پروژه‌های با دامنه بزرگ و بعضا نامشخص در بهترین حالت با مدل آبشاریه (باور کنید بعضی وقتا مدل فواره‌ای هم هست ?) و جای تعجب نیست که این نوع پروژه ها تبدیل به یک معضل بزرگ برای سازمان و نفرات درگیر در اون پروژه بشن که از تحویلهای دیر و کم کیفیت با صرف هزینه های گزاف رنج میبرن و ما می مونیم با یک تیم خسته که دیگه انگیزه ای برای انجام کار خوب نداره.اگر چه اجایل حتی ممکنه برای ساخت هر ویژگی مجزا به نظر کند تر برسه ولی مزایای بسیار بیشتری در برابر مدل آبشاری ارائه میکنه که یکیشون ارائه زودهنگامه. شما ترجیح میدید یک پروژه شش ماه طول بکشه و هشت ویژگی رو در انتها ارائه کنه و یا هشت ماه طول بکشه و هر ماه یک ويژگی با کیفیت ارائه کنه تازه اولین محصول تنها یکماه بعد از شروع پروژه ارائه بشه؟ممکنه زمان اجرای کار طولانی تر بشه ولی با ارائه زود هنگام ارزشها، یادگیری زودتر، دریافت نیازمندیهای واقعی زودتر مشتری و در نهایت کاهش ریسک کل پروژه ارمغانیه که اجایل برای ما خواهد داشت.به اعتقاد بعضیا اجایل یک طرز تفکره (Mindset) که البته درست هم هست ولی این تازه اول ماجراست.اینکه ما طرز تفکر اجایل داشته باشیم پایه و بستری آماده میکنه برای درک عصاره اصلی اجایل یعنی حرکت.بله! اجایل یک حرکت و جریان رو به جلوست. Agile is a movementاجایل یک روش و دیدگاه جدیده که بتونیم با همدیگه کار کنیم، تبادل نظر کنیم، همدیگه رو تشویق و حمایت کنیم و در کنار هم این جریان رو به جلو حرکت بدیم.شاید یک جمله بهتر در مورد اجایل به جای "سریع و ارزون" جمله "کوچک و زود" باشه من فکر میکنم این جمله بهتر فلسفه وجودی اجایل و مزایای اجایل رو نشون میده. تمرکز اجایل بر مشتریانه نه ذینفعانشاید این ایده اشتباه که اجایل سریعتر و ارزون تر از روشهای دیگه است از این طرز تفکر سنتی مدیریت پروژه که "هر چه که ذینفعان پروژه می‌خواهند باید انجام دهیم" نشات میگیره که البته در نگاه اول خیلی هم منطقی به نظر میرسه و متاسفانه هنوز هم اساس قضاوت نحوه‌ی کار مدیر پروژه ها در بسیاری از سازمانها و موسساته.مبانی تفکر اجایل البته سعی میکنه که از زوایه دید مشتریان واقعی به قضیه نگاه کنه و سوالهای از این قبیل رو مطرح میکنه:نرم‌افزارواقعا"چه کاری برای مشتری باید انجام بده؟ و چه ارزش افزوده ای میتونه برای مشتریان فراهم کنه؟چطوری میتونیم بعضی قابلیتها (و نه همه‌ی قابلیتهای ممکن) رو سریع به مشتریان تحویل بدیم؟چطوری میتونیم به سرعت از ویژگیها و قابلیتهای که تاکنون ارائه کردیم برای اصلاح و یا ادامه کار یاد بگیریم.و چطوری میتونیم قابلیتهای خودمون رو برای ارائه ارزشهای بیشتر به مشتری توسعه بدیم.البته اینجا تمرکز اجایل بر سرعته! اما توجه کردید؟ زبان و نوع بیان اجایل متفاوته.اصول بیانیه اجایل از واژه سریع استفاده نمی‌کنه بجاش واژه های زودهنگام و پرتکرار بکار میبره.Our highest priority is to satisfy the customer through early andcontinuous delivery of valuable softwareDeliver working software frequently, from a couple of weeks to a couple of months,with a preference to the shorter timescaleبنابراین اجایل بجای ارائه یک پروژه بزرگ در یک زمان کم به معنای سریع و تعجیل برعکس از ارائه زودهنگام و مکرر وِیژگیها و تغییرات خیلی کوچک در بازه های زمانی کوتاه حمایت میکنه.اجایل از مثلث آهنی متفاوتی استفاده میکنهمثلث آهنی ستنی مدیریت پروژه همانطوری که همه میدونیم از محدوده Scope ، زمان Time و هزینه Cost تشکیل شده به این صورت که هزینه معمولا تابعی از زمانه ( معمولا به افراد بر اساس زمانی که صرف می‌کنند پرداختی داریم) و زمان هم تابعی از محدوده‌ست.بنابراین در یک روش مدیریت پروژه ضعیف کلی زمان صرف کنترل محدوده پروژه میشه و همیشه دنبال روشهای هستند که زمان و هزینه پروژه رو کاهش بدن!!!ولی کنترل این مثلث آهنی برای هر مدیر پروژه‌ای میتونه یک کابوس واقعی رقم بزنه، چرا که واقعا در مورد نرم‌افزار از ابتدا نمی‌توان تخمین زد که نیازهای واقعی مشتریان چیه، چرا که در خیلی موارد خود مشتریان هم از قبل نمی‌‌دونن واقعا چی میخوان و هر چه محدوده‌ی پروژه‌ بزرگتر باشه این مشکل هم حادتره. هر چه که ما در پروژه‌‌های نرم‌افزاری جلوتر می‌ریم از نکات و تغییرات و نیازهای جدیدی که توسط مشتریان مطرح میشن متعجب میشیم. بنابراین فرض بر ثابت نگه داشتن محدوده یک روش بسیار غلط در کنترل مثلث آهنیه و البته وجود این مثلث و کنترلش در تولید نرم‌افزار کلا از پایه اشتباه.اجایل از یک مثلث دیگه برای کنترل تولید محصول استفاده میکنه. مثلث اجایل از سه راس ارزش Value، کیفیت Quality و محدودیتهاConstrains تشکیل شده (توصیه میکنم اگه تونستید یک نگاهی به کتاب Agile Project Management جیم های‌اسمیت بندازین) و محدودیتها به مثلث اول یعنی مثلث آهنی STC اشاره میکنه. پس محدودیتهای کل پروژه تنها یکی از فاکتورهایه که باید بهش توجه کنیم و البته در اجایل محدودیتها اغلب به اندازه دو راس دیگه یعنی ارزش و کیفیت اهمیت ندارن.اگه به نظرتون این مسئله خیلی ملموس نیست فرض کنید در حین پروژه مشتری درخواستی رو مطرح میکنه که قبلا نبوده ولی الان ارزش زیادی براش داره و حتی حاضره پول زیادی بابتش بده ولی پیاده سازی این مورد باعث میشه از محدوده و زمان از قبل تعیین شده خارج بشیم. بنظرتون نباید این مورد انجام بشه؟!!! پس خلق ارزش بر محدودیتها اولویت داره و یا فرض کنید در حین پیاده سازی پروژه به باگ و مشکلاتی بخوریم که از قبل پیش بینی نشده و اصلاح اونها باعث بشه از سقف محدودیتها خارج بشیم. آیا نباید مشکلات نرم‌افزار برطرف بشه؟ بالاخره در این حالت یا باید با تاخیر پروژه انجام بشه و از محدوده‌ی زمان خارج بشیم و یا تعدادی ویژگی رو که باید پیاده می‌شدند رو حذف کنیم (کم کردن محدوده) ولی بدیهیه که روی کیفیت نمی‌تونیم معامله کنیم.بنابراین تمرکز اجایل بر خلق ارزش و کیفیته و این دو، از اولویت بسیار بیشتری از محدودیتها برخوردارن درصورتیکه در روشهای سنتی با کنترل هزینه و زمان سعی در راضی کردن ذینفعان پروژه دارن نه مشتریان واقعی و نرم‌افزای که مشتری واقعی ازش راضی نباشه محکوم به شکسته.عباس نیک‌نفسعباس نیک‌نفسWed, 29 Apr 2020 10:34:40 +0430