تخفیف های 80 درصدی دوره های سایت دانشجویار
دوره فروشگاه جنگو من هم شامل شده
البته اینی که پای لپ تاپ ع، ظاهرا شهرشون یه متر برف باریده تو پاییز 🥶
https://www.daneshjooyar.com/landing/autumn1404/
دوره فروشگاه جنگو من هم شامل شده
البته اینی که پای لپ تاپ ع، ظاهرا شهرشون یه متر برف باریده تو پاییز 🥶
https://www.daneshjooyar.com/landing/autumn1404/
🥱7😁3👍2
جنگولرن
سری مهندسی نرم‌افزار: پست 10 از لینکدین Saeed Shahrivari Joghan اسکرام چکش طلایی نیست! در پست قبلی اجمالاً راجع به چارچوب بودن اسکرام صحبت کردم. مجدداً تاکید می‌کنم که من طرفدار اسکرام نیستم ولی شدیداً با روال توسعه بی‌برنامه و یلخی هم مشکل دارم. من اخیراً…
سری مهندسی نرم‌افزار: پست 11
از لینکدین Saeed Shahrivari Joghan
قواره کردن کت به سبک خیاطی
این پست راجع به کاستومایز کردن اسکرام هست و طبعاً آخرین قسمت از دنباله اسکرام. در قسمت‌های قبلی مفصل راجع به چارچوب بودن اسکرام و ممنوع بودن دستکاری در اصول اون صحبت شد. اما چطوری میشه اسکرام رو برای تیم خودمون و یا حتی سازمان دل‌پذیر‌تر کنیم؟ خب اسکرام سبکه و میشه با سلیقه خودمون و با حفظ اصولش تا حد زیادی کاستومایزش کنیم. من به چند محور اشاره می‌کنم:
۱- ادغام نقش‌ها: من خیلی از دوستان با تجربه شنیدم که نقش‌هایی مثل «مالک محصول» به درد نمی‌خوره و چرنده و ما چرا باید به یه نفر کلی حقوق ماهیانه بدیم که یه نقش الکی به نام مالک محصول داشته باشه؟ خب اگه شما حتی یه تجربه خیلی محدود در پیاده‌سازی یک سیستم مالی یا سرمایه‌گذاری داشته باشید خیلی راحت درک می‌کنید که در چنین نرم‌افزارهایی به دلیل دانش تخصصی عملاً یک مهندس نرم‌افزار بدون کمک کسی که مالک محصول باشه توانایی دلیور کردن نخواهد داشت. اما در تمام پروژه‌ها واقعا نیاز به یک مالک محصول تمام وقت نیست و خیلی از اوقات یکی از توسعه‌دهنده‌ها میتونه همزمان نقش مالک محصول رو هم ایفا کنه یا برعکس در پروژه‌های خیلی پیچیده ممکنه چندین مالک محصول داشته باشیم. بنابراین به جای حذف نقش‌های مالک محصول و اسکرام مستر میشه عوض یک فرد تمام وقت این نقش‌ها رو به
توسعه‌دهنده یا فرد دیگه‌ای سپرد ولی لطفا هرگز این نقش رو حذف نکنیم (توجه کنید که از واژه نقش استفاده می‌کنم نه فرد)
۲- تغییر در سرمونی‌ها: میشه جلسات پلنینگ رو به چند جلسه کوتاه‌تر شکست یا برای پیش‌برد بهتر در یه قسمت طولانی‌تر با کمک چند عضو تیم عمده کار رو انجام داد و بعد در یک جلسه کوتاه‌تر با شرکت تمام اعضای تیم کار رو جمع کرد که باعث خستگی افراد نشه. خیلی اوقات میشه جلسات رترو رو در قالب یک جلسه به صرف چای یا قهوه انجام داد تا کسالت کمتر بشه یا حتی خیلی کوتاه در عرض ۱۰ دقیقه در انتهای جلسه ریویو برگزارش کرد.
۳- تغییر در آرتیفکت‌ها: برای مثال اگه انجام تخمین برای وزن‌دهی به آیتم‌های بک‌لاگ با استفاده از اعداد براتون سخته میشه از سایز‌های تیشرت استفاده کرد. یا میشه تعریف done رو برای هر تیم شخصی‌سازی کرد.
در آخر مجدداً جمع‌بندی می‌کنم که اسکرام چکش طلایی نیست و به درد تمام پروژه‌ها نمی‌خوره اما از اون طرف هم اگه یه نفر بیاد بگه اسکرام در پیته و قدیمی شده و کلاً به درد نخوره به نظرم حرف ناپخته‌ای زده. اسکرام برای همه پروژه‌ها مناسب نیست ولی در طیف خوبی از پروژه‌ها خوب پاسخ می‌ده و معمولاً اگه از این افراد منتقد بپرسی خب اگه اسکرام رو اجرا نکنیم چیکار کنیم؟ جواب قانع‌کننده‌ای ندارند یا یه روش من‌در‌آوردی از خودشون ارائه میدن که قابل اتکا نیست. اسکرام بر خلاف چیزی که مشهوره یه چارچوب نسبتا سبکه و تا حد خوبی میشه با حفظ اصول کاستومایزش کرد اما از اون سمت هم نباید به خود چارچوب دست بزنیم مثل قواره کردن یه کت.
از لینکدین Saeed Shahrivari Joghan
قواره کردن کت به سبک خیاطی
این پست راجع به کاستومایز کردن اسکرام هست و طبعاً آخرین قسمت از دنباله اسکرام. در قسمت‌های قبلی مفصل راجع به چارچوب بودن اسکرام و ممنوع بودن دستکاری در اصول اون صحبت شد. اما چطوری میشه اسکرام رو برای تیم خودمون و یا حتی سازمان دل‌پذیر‌تر کنیم؟ خب اسکرام سبکه و میشه با سلیقه خودمون و با حفظ اصولش تا حد زیادی کاستومایزش کنیم. من به چند محور اشاره می‌کنم:
۱- ادغام نقش‌ها: من خیلی از دوستان با تجربه شنیدم که نقش‌هایی مثل «مالک محصول» به درد نمی‌خوره و چرنده و ما چرا باید به یه نفر کلی حقوق ماهیانه بدیم که یه نقش الکی به نام مالک محصول داشته باشه؟ خب اگه شما حتی یه تجربه خیلی محدود در پیاده‌سازی یک سیستم مالی یا سرمایه‌گذاری داشته باشید خیلی راحت درک می‌کنید که در چنین نرم‌افزارهایی به دلیل دانش تخصصی عملاً یک مهندس نرم‌افزار بدون کمک کسی که مالک محصول باشه توانایی دلیور کردن نخواهد داشت. اما در تمام پروژه‌ها واقعا نیاز به یک مالک محصول تمام وقت نیست و خیلی از اوقات یکی از توسعه‌دهنده‌ها میتونه همزمان نقش مالک محصول رو هم ایفا کنه یا برعکس در پروژه‌های خیلی پیچیده ممکنه چندین مالک محصول داشته باشیم. بنابراین به جای حذف نقش‌های مالک محصول و اسکرام مستر میشه عوض یک فرد تمام وقت این نقش‌ها رو به
توسعه‌دهنده یا فرد دیگه‌ای سپرد ولی لطفا هرگز این نقش رو حذف نکنیم (توجه کنید که از واژه نقش استفاده می‌کنم نه فرد)
۲- تغییر در سرمونی‌ها: میشه جلسات پلنینگ رو به چند جلسه کوتاه‌تر شکست یا برای پیش‌برد بهتر در یه قسمت طولانی‌تر با کمک چند عضو تیم عمده کار رو انجام داد و بعد در یک جلسه کوتاه‌تر با شرکت تمام اعضای تیم کار رو جمع کرد که باعث خستگی افراد نشه. خیلی اوقات میشه جلسات رترو رو در قالب یک جلسه به صرف چای یا قهوه انجام داد تا کسالت کمتر بشه یا حتی خیلی کوتاه در عرض ۱۰ دقیقه در انتهای جلسه ریویو برگزارش کرد.
۳- تغییر در آرتیفکت‌ها: برای مثال اگه انجام تخمین برای وزن‌دهی به آیتم‌های بک‌لاگ با استفاده از اعداد براتون سخته میشه از سایز‌های تیشرت استفاده کرد. یا میشه تعریف done رو برای هر تیم شخصی‌سازی کرد.
در آخر مجدداً جمع‌بندی می‌کنم که اسکرام چکش طلایی نیست و به درد تمام پروژه‌ها نمی‌خوره اما از اون طرف هم اگه یه نفر بیاد بگه اسکرام در پیته و قدیمی شده و کلاً به درد نخوره به نظرم حرف ناپخته‌ای زده. اسکرام برای همه پروژه‌ها مناسب نیست ولی در طیف خوبی از پروژه‌ها خوب پاسخ می‌ده و معمولاً اگه از این افراد منتقد بپرسی خب اگه اسکرام رو اجرا نکنیم چیکار کنیم؟ جواب قانع‌کننده‌ای ندارند یا یه روش من‌در‌آوردی از خودشون ارائه میدن که قابل اتکا نیست. اسکرام بر خلاف چیزی که مشهوره یه چارچوب نسبتا سبکه و تا حد خوبی میشه با حفظ اصول کاستومایزش کرد اما از اون سمت هم نباید به خود چارچوب دست بزنیم مثل قواره کردن یه کت.
❤1👍1