تمرین تیم‌سازی در چارچوب Scrum

دسته: تیم اسکرام

  • تخمین در اجایل خراب نیست؛ اما شاید طرز فکرمان خراب باشد

    تخمین در اجایل اغلب حس «خراب بودن» می‌دهد.اما شاید مشکل از تکنیک نباشد؛ مشکل از ذهنیتی است که پشت آن قرار دارد. تا به حال این جملات را شنیده‌اید؟ اگر مشکل واقعی ابزار نباشد، بلکه نوع فکر کردن ما درباره آن باشد، چه؟ «اجایل همین‌طوری کار می‌کند…» مدتی پیش، تیمی به ما گفت کوچ اجایل‌شان…

  • اسکرام نه متدولوژی است، نه ابزار کنترل

    یکی از ریشه‌ای‌ترین سوءبرداشت‌ها درباره اسکرام این است که آن را یک متدولوژی کامل یا بدتر از آن، یک فرآیند حاکمیتی و کنترلی می‌دانند؛ چیزی شبیه دستورالعملی گام‌به‌گام که اگر «درست اجرا شود»، خروجی تضمین‌شده می‌دهد. این تصور نه‌تنها نادرست است، بلکه مستقیماً با فلسفه‌ای که اسکرام بر آن بنا شده در تضاد قرار دارد.

  • Velocity؛ آن چیزی نیست که فکر می‌کنید

    تیتر «Velocity؛ آن چیزی نیست که فکر می‌کنید» همراه با آیکون‌های خودرو، ساعت، تابلو محدودیت سرعت و مسیر پرپیچ‌وخم—نمادی از برداشت‌های اشتباه درباره Velocity در اجایل و نیاز به درک بهتر آن. در پست قبلی گفتیم که تخمین در اجایل به‌خاطر تکنیک‌ها خراب نیست؛مشکل از طرز فکر پشت آن‌هاست. (می‌توانید آن مطلب را اینجا بخوانید.)…

  • هنوز از Velocity استفاده می‌کنید؟ دوباره آن را مفید کنید

    و به‌جای این‌که بپرسیم «آیا به تاریخ موردنظر می‌رسیم؟»، سؤال‌ها تغییر می‌کنند به: چه چیزهایی را با اطمینان انجام خواهیم داد؟ چه چیزهایی در معرض ریسک هستند؟ حاضر به چه بده‌بستان‌هایی هستیم؟

  • BPMN زبان مدل‌سازی بصری برای جریان‌های کاری و فرایندهای سازمادر مدیریت محصول، از «تصویر ذهنی مبهم» تا «درک مشترک عملیاتی»

    BPMN چیست؟ BPMN یا Business Process Modeling Notation یک زبان مدل‌سازی بصری برای کاربردهای تحلیل کسب‌وکار و مشخص‌کردن جریان‌های کاری فرایندهای سازمانی است. BPMN یک استاندارد باز برای ترسیم فلوچارت‌های گرافیکی است که برای تعریف جریان‌های کاری فرایندهای کسب‌وکار به کار می‌رود. این نوتیشن، زبانی محبوب و شهودی دارد که به‌راحتی توسط همهٔ ذی‌نفعان کسب‌وکار…

  • ذی‌نفعان شما به فرآیندتان اعتماد ندارند؛ این‌طور درستش کنید

    استفان وولپرز (آلمان)۱۵ دسامبر ۲۰۲۵ متا-رتروسپکتیو: ذی‌نفعان بدبین را به هم‌پیمانان فرآیند تبدیل کنید بیشتر تیم‌های اسکرام رتروسپکتیوها را پشت درهای بسته برگزار می‌کنند و بعد تعجب می‌کنند که چرا ذی‌نفعان، فرآیند آن‌ها را مثل یک «جعبه سیاه» می‌بینند. شکایت همیشه یکی است:«آن‌ها نمی‌فهمند ما چطور کار می‌کنیم.»اما واقعاً برای کمک به فهمیدنِ کارتان چه…

  • نقش واقعی مالک محصول، فراتر از پالودن بک‌لاگ

    در سال‌های اخیر، با رشد سریع روش‌های چابک (Agile) و به‌ویژه اسکرام (Scrum)، شاهد برداشت‌های سطحی از نقش‌ مالک محصول (Product Owner) بوده‌ایم که آن را محدود به نوشتن داستان کاربری یا تکمیل بک‌لاگ می‌دانند. اما اکسپنشن پک اسکرام ۲۰۲۵ دیدگاهی بسیار بالغ‌تر، انسانی‌تر و ارزش‌محور نسبت به این نقش ارائه می‌دهد. در این مقاله،…

  • دو محور کلیدی نقش مالک محصول در محصول‌های چندتیمی: مدیریت ذی‌نفعان و حفظ تمرکز تیم‌ها

    یک مالک محصول، چند تیم اسکرام: الگوی بهینه هدایت بدون مداخله‌گری این مقاله بر پایه مقاله «Self-organize to Higher Performance» در سازمان اسکرام نوشته شده است که پیشنهاد می‌کنم ترجمه آن را بخوانید. این مقاله اولین بار در اجایل گپ منتشر شده است و این یک نسخه کپی از آن است. وقتی چند تیم اسکرام، یک محصول…

  • راهنمای فارسی صوتی اسکرام ۲۰۲۰

    اگر دوست دارید اسکرام را «در گوش‌تان» یاد بگیرید، این کتاب صوتیِ راهنمای اسکرام دقیقاً برای شماست.اسکرام یک چارچوب چابک برای ساخت محصولات پیچیده است که بر کار تیمی، بازرسی و تطبیق مداوم، و تحویل تدریجی ارزش تکیه می‌کند.در این کتاب صوتی، متن به‌روز راهنمای اسکرام با زبانی واضح و آهنگ مناسب خوانده شده تا…

  • نقش Product Owner در مدیریت قرض فنی: راهبردهایی برای حفظ سلامت فنی محصول در تیم‌های اسکرام

    مقدمه در دنیای توسعه نرم‌افزار، قرض فنی (Technical Debt) مفهومی آشنا ولی اغلب نادیده‌ گرفته‌شده است. تصمیمات کوتاه‌مدت برای تسریع تحویل محصول، معماری ضعیف، تست ناکافی یا نبود مستندسازی می‌توانند همگی منجر به انباشت قرض فنی شوند. درحالی‌که مهندسان نرم‌افزار این مسئله را به‌خوبی درک می‌کنند، مسئولیت پیشگیری و مدیریت آن صرفاً بر عهده‌ی تیم…

error: اجازه کپی محتوا وجود ندارد