دسته: مقالات تألیفشده
-
نقش واقعی مالک محصول، فراتر از پالودن بکلاگ
در سالهای اخیر، با رشد سریع روشهای چابک (Agile) و بهویژه اسکرام (Scrum)، شاهد برداشتهای سطحی از نقش مالک محصول (Product Owner) بودهایم که آن را محدود به نوشتن داستان کاربری یا تکمیل بکلاگ میدانند. اما اکسپنشن پک اسکرام ۲۰۲۵ دیدگاهی بسیار بالغتر، انسانیتر و ارزشمحور نسبت به این نقش ارائه میدهد. در این مقاله،…
-
دو محور کلیدی نقش مالک محصول در محصولهای چندتیمی: مدیریت ذینفعان و حفظ تمرکز تیمها
یک مالک محصول، چند تیم اسکرام: الگوی بهینه هدایت بدون مداخلهگری این مقاله بر پایه مقاله «Self-organize to Higher Performance» در سازمان اسکرام نوشته شده است که پیشنهاد میکنم ترجمه آن را بخوانید. این مقاله اولین بار در اجایل گپ منتشر شده است و این یک نسخه کپی از آن است. وقتی چند تیم اسکرام، یک محصول…
-
استوری پوینت: زبان مشترک تیمهای چابک برای تخمین هوشمندانه Velocity
در دنیای توسعه نرمافزار به روش چابک، تخمین دقیق کارها همواره یکی از چالشهای اساسی تیمها بوده است. استوری پوینت به عنوان یک واحد اندازهگیری نسبی، انقلابی در نحوه برآورد تلاش مورد نیاز برای تکمیل کارها ایجاد کرده است. این مفهوم که در قلب فرآیندهای اسکرام و کانبان قرار دارد، نه تنها ابزاری برای تخمین،…
-
نقش Product Owner در مدیریت قرض فنی: راهبردهایی برای حفظ سلامت فنی محصول در تیمهای اسکرام
مقدمه در دنیای توسعه نرمافزار، قرض فنی (Technical Debt) مفهومی آشنا ولی اغلب نادیده گرفتهشده است. تصمیمات کوتاهمدت برای تسریع تحویل محصول، معماری ضعیف، تست ناکافی یا نبود مستندسازی میتوانند همگی منجر به انباشت قرض فنی شوند. درحالیکه مهندسان نرمافزار این مسئله را بهخوبی درک میکنند، مسئولیت پیشگیری و مدیریت آن صرفاً بر عهدهی تیم…
-
معرفی «Control Chart» در جیرا – راهنمای عملی برای تیمهای اسکرام
Control Chart چیست؟ کنترلچارت نموداری است برای دیدن چرخهزمان (Cycle Time) هر آیتم کاری از وقتی «شروع به کار» میشود تا وقتی «Done» میشود. هدفش این است که سرعت و پایداری جریان کار را بسنجید و نقاط غیرعادی (Outliers) و گلوگاهها را کشف کنید. اجزای نمودار تعریف Outlier (نقطهٔ غیرعادی): آیتمی که چرخهزمانش بهوضوح خارج…
-
اولویتبندی بکلاگ محصول با مدل Kano: راهنمای کاربردی برای تیمهای محصول
در فرآیند توسعه محصول، یکی از چالشهای اصلی این است که بدانیم کدام ویژگیها بیشترین ارزش را برای کاربران ایجاد میکنند و کدامها صرفاً «باید باشند» تا نارضایتی به وجود نیاید. مدل Kano یکی از ابزارهای معتبر و ساده برای پاسخ به همین مسئله است. این مدل به مدیران محصول و تیمهای توسعه کمک میکند…
-
درمان «وابستگیهای کنترلنشده» در اسکرام: راهنمای جامع و عملی
مقدمه وابستگیهای بینتیمی/برونتیمی وقتی نامرئی و مدیریتنشده بمانند، جریان ارزش را خفه میکنند: اسپرینتها میگذرد، اما Increment قابلاستفاده شکل نمیگیرد یا لحظهٔ آخر، نیمبند تکمیل میشود. درمان این درد، ترکیبی از شفافیت جریان کار، طراحی برشهای عمودی، توافقات بینتیمی، توانمندسازی تیم و بازرسی/انطباق منظم است—همراستا با «تعهدها» و «رویدادهای» راهنمای رسمی اسکرام ۲۰۲۰. مسئله دقیقاً…
-
دو QA برای پنج محصول: از بحران اولویت تا جریان شفاف – راهکار اسکرام
راهنمای عملی برای تسهیل اولویتها، ظرفیتسنجی، و ساخت کیفیت درون فرایند (Scrum Guide 2020) Problem Context — قصهی یک تیم QA «سِرویسی» یک تیم QA دو نفره داریم که بین ۵ محصول بهاشتراک گذاشته شدهاند. هر PO در بورد اسپرینتِ خودش «تسک QA» میگذارد و تیم QA موظف است این تسکها را از محصولات مختلف…
-
۲۰ نشانه “زامبی اسکرام” (Zombie Scrum) یا اسکرام ناکارآمد
۲۰ نشانه “زامبی اسکرام” (Zombie Scrum) با شرح کامل «زامبیاسکرام» زمانی رخ میدهد که تیم ظاهراً اسکرام را اجرا میکند (رویدادها، بردها، اسپرینتها) اما روح تجربهگرایی، تمرکز بر ارزش، و بهبود مستمر در آن مرده است. نتیجه؟ خروجیهای بیارزش، بازخورد دیرهنگام، ناامیدی تیم و بیاعتمادی ذینفعان. این مقاله ۲۰ نشانه اصلی زامبیاسکرام را میگیرد و…