پانزدهمین گزارش وضعیت چابک

چه ترندهایی در دنیای چابک در جریان است؟

@iranagile

چرا کامیونیتی‌های چابک دچار کج روی شدند؟

نزدیک به پنجاه تا مقاله در حوزه چابک در سایتهای معتبر و لینکدین بررسی کردم، بسیار نکته جالبی دریافت کردم، نویسندگان و تولیدکنندگان این مطالب به صراحت در مورد برخی چیزها ادعا کرده بودند بدون داشتن هیچ استدلالی، یا حداکثر استدلال ارجاع دادن به سخن یا توییت یکی از افراد برجسته کامیونیتی بوده است.

مثلاً فلانی هم گفته «تخمین زدن بیخود هست» یا «فلان روش کار نمی‌کند »، اکثرا این ادعا همراه با استدلال‌های خیلی ضعیفی بیان می‌شوند و یا دچار خطاهای شناختی هستند.

البته حرف من در اینجا این نیست که نتیجه بگیرم "تخمین عالی است" ، "SAFe ایده خوبی است" و "اسکرام‌مستر همچنین می توانند مالک محصول نیز باشد". حرف من این است که به نظر می رسد تلاش های سیستماتیک واقعی برای بررسی این موضوعات با رویکرد تجربی، دیدگاه ظریف‌تری در مورد این سوالات ارائه می‌دهد.

چرا کامیونیتی‌های چابک از تجربه گرایی فاصله گرفتند؟

آنچه به ویژه در اینجا آشکار می شود این است که جامعه چابک ظاهراً همه راجع به "تجربه گرایی" است. اما آیا ما واقعا تجربه گرا هستیم؟ ویکی پدیا تجربه گرایی را چنین تعریف می کند:
"تجربه گرایی […] بر شواهد تأکید می کند، به ویژه که در آزمایشات کشف شده باشند. این یک بخش اساسی از روش علمی است که همه فرضیه‌ها و نظریه‌ها باید در برابر مشاهدات جهان طبیعی آزمایش شوند تا اینکه فقط به شهود یا مکاشفه پیشینی استوار باشند."
تجربه گرایی به ما امکان می دهد تا دانش قابل اعتمادی در مورد جهان ایجاد کنیم و عواقب اقدامات را درک کنیم. دانش قابل اعتماد مستلزم شواهد معتبری است که متناسب با ادعا باشد. با اینکه احساس شهود و ترجیحات شخصی مطمئناً ارزش خود را دارند ، منابع معتبری برای شواهد نیستند. کارل ساگان فیزیکدان این طور خلاصه کرد که "ادعاهای خارق العاده به مدارک خارق‌العاده نیاز دارند". ساگان همچنین از ما می‌خواهد که نسبت به ادعاهایی که فاقد شواهد متناسب هستند تردید داشته باشیم و کسانی را که فاقد چنین شواهدی ارائه می دهند به چالش بکشیم. از همه مهمتر ، وجود شواهد عینی همچنین زمینه ما را حرفه ای تر می کند زیرا بحث‌های بهتری برای متقاعد کردن افراد بدبین ارائه می دهد.

چه چیزی شواهد خوبی ارائه می دهد؟

شواهد خوب عاری از سوگیری شخصی است و با روشهای بی طرفانه جمع آوری و تحلیل می شود. این بدان معناست که افراد دیگر می توانند داده های یکسان (مشاهدات ، موارد ، اعداد) را جمع آوری کرده و از همان روش ها برای رسیدن به نتایج یکسان استفاده کنند. این در علم "تکرار" نامیده می شود ، و این استاندارد طلایی برای چگونگی تولید دانش قابل اعتماد است.

نوشته کامل در لینک زیر 👇

https://medium.com/the-liberators/why-doesnt-the-agile-community-practice-empiricism-12082e48ffba

@iranagile

ورکشاپ مدیریت محصول چابک (آنلاین) – هفته آینده ۱۴ و ۱۵ مردادماه

از استراتژی تا تاکتیک، اما به سبک چابک
آنچه یک مدیر محصول چابک باید بداند، و اینکه حلقه مفقوده اسکرام در مدیریت محصول چیست؟ و چگونه یک مالک محصول باید بتواند مدیریت محصول چابک انجام دهد (البته نه اینکه صرفا اسمش تبدیل به مدیر محصول شود)

برای اطلاعات بیشتر به لینک زیر مراجعه کنید:

https://scrum.ir/%D8%B1%D9%88%DB%8C%D8%AF%D8%A7%D8%AF%D9%87%D8%A7/pm-course/

🎯 آگاهی موقعیتی یکی از قابلیتهای اصلی شرکتهای ضد شکننده یا آنتی فرجایل است. آگاهی موقعیتی (به انگلیسی: Situation awareness) به درک معنی عناصر محیطی و پدیده‌ها با توجه به زمان یا مکان، و تجسم وضعیت آینده‌شان گفته می‌شود.

فکر می کنم همه با این ایده موافق هستیم که در این جهان پر از تغییرات سریع، باید از وضعیت خود و تغییرات محیطی بسیار آگاه باشیم و سریع تصمیم بگیریم و بر اساس این آگاهی عمل کنیم. اما در دنیای واقعی چه اتفاقی می افتد؟

سوگیری ادراکی (بدان معنی که ما بر اساس ورودی های حسی خود علیه چیزی یا برای آن تعصب داریم و باعث می شود برخی چیزها از دیگر چیزها قابل توجه تر به نظر برسند) و کوری ناخواسته (هنگامی که ما روی یک چیز یا یک نگرانی تمرکز می کنیم، اغلب چیزهای دیگر را دیگر نمیبینیم) موانع بزرگی برای داشتن یک آگاهی موقعیتی جامع هستند.

🤦 آنها منجر به فیلتر شدن آگاهی ما خواهند شد به طوریکه با یک آگاهی ناقص و ناکافی باقی خواهیم ماند. از سوی دیگر، ما فکر می کنیم که آگاهی ما از همه ادراکات دیگر صحیحتر است. در شرکتها، لایه های مختلف یا تیم های مختلف با نگرانی های متفاوت و برداشت های متفاوت داریم. اگر از آنها بپرسید "مهمترین کار بعدی چیست؟" پاسخ های متفاوتی خواهید شنید که همه آنها بر اساس آگاهی موقعیتی آنها درست است.

تیم فنی فکر می کند که ما باید بر روی تاب آوری یا کدهای تمیز تمرکز کنیم ، مدیران ارشد فکر می کنند که باید وارد بازار های جدیدی شویم، بچه های فروش فکر می کنند برای رسیدن به مشتریان جدید باید فیچرهای جدیدی را به محصول اضافه کنیم ، ... با اینکه، همه آنها آگاهی زیادی نسبت به دامنه تخصصی خود دارند اما آنها دارای سوگیری ادراکی و کوری ناخواسته نیز هستند.

آگاهی از موقعیت باید منسجم باشد. برای داشتن آگاهی موقعیتی منسجم، هنگام تصمیم گیری در مورد اولویتهای بعدی، به ناهمگونی و تنوع نیاز داریم.

پس صرفا نباید در تصمیمهای گامهای بعدی یک سری افراد با دلمشغولی و نگران یکسان دور هم جمع بشوند، بخاطر اینکه صرفا همدیگر را تایید خواهند کرد و احتمالا تصمیم بر اساس آگاهی جامع یا منسجم نخواهد بود.

اسد صفری

@irangile

چرا بدهی انسانی مهمتر از بدهی فنی است؟

اکثر ما با اصطلاح بدهی فنی آشنا هستیم، جایی که بسیاری از کارهای لازم فنی، مهندسی و کیفت را به دلایلی مثل فشار زمانی یا دلایل دیگر کنار میگذاریم، ولی بدهی آن انباشته می شود و در نهایت در قالب باگهای زیاد یا حتی از دسترس خارج شدن دائم سیستم خود را نشان خواهد داد.

اما بدهی انسانی، مساله دیگری است که باید آن را شناخت و بسیار اهمیت داد. این بدهی تقریبا معادل بدهی فنی است اما برای افراد است. همه ابتکارات، پروژه ها، نیت هایی که ما (سازمان) می بایست برای کارکنان خود بهتر انجام می دادیم، اما در نیمه راه کنار گذاشته یا فراموش شدند. همه فرصت های از دست رفته برای سهولت و شادی در زندگی و کارشان. همه صحبتهای پوچ درباره برابری، احترام، عدم سرزنش، شجاعت و اعتماد. همه فرهنگ سمی ایجاد شده توسط اینها: این بدهی انسانی است.

در اینجا چند نمونه از این بدهی انباشته در سطح شرکت آورده شده است:

👈 پروژه های منابع انسانی که شروع و رها می شوند
👈 مدیرانی که از بالا فقط حرف میزنند و کاری انجام نمی شود
👈 تغییرات مدیریتی و رهبری بد
👈موضوعات بزرگ و مهمی که همین طور باز میمانند: شادی کارکنان، شیوه های کار و ...
👈 بررسی و پرسش نامه های عقیم (بعدش اتفاقی نمی افتد)
👈اعمال تنبیهی
👈 فرهنگ ترس و اجتناب از شکست
👈 اجازه دادن به سیاست های سمی و سکوت در صورت وجود زورگویی سیستماتیک
👈 تأیید شیوه مدیریت فرمان و کنترل یا ذره بینی
👈 اجایل فقط در حد مراسماتو بدون تغییر طرز فکر
👈 کارکنان ناراضی و بدون مشارکت

تقریباً هر بنگاه اقتصادی تا حدی این موارد را دارد، اما نمونه های عمومی زیادی هست که " این موارد انباشته شده و آنها موفق به حل آن نشدند و به خاک سیاه نشستند" ، و در هر یک از این مثال ها شکست آنها تقریباً مستقیماً به موارد بالا نسبت داده می شود. سقوط شدید نوکیا را که در سال 2015 در مطالعه INSEAD رونمایی شد، نتیجه فرهنگ سمی است که کارکنان تجربه کرده بودند و باعث شد آنها پیشرفت رقبای خود را انکار کنند. یا شکست شدید بوئینگ که در نتیجه محیطی از ترس ایجاد شده بود، جایی که مهندسان آنها می ترسیدند در مورد شکست های مداوم که مشاهده می کردند صحبت کنند و در نهایت منجر به فاجعه 737 شود.

اما چه باید کرد؟

در این نوشته میتوانید بیشتر بخوانید:
https://www.infoq.com/articles/human-debt

@iranagile

🔶 تابه‌حال خرابکاری کرده‌اید؟ من کرده‌ام! شمع روشنی را در نزدیک‌ترین فاصله ممکن با دستمال‌کاغذی‌ها رها کردم! فاجعه‌ای رخ داد! خوش‌اقبال بودم که کسی آسیب ندید؛ اما تعداد زیادی لحاف و تشک اجدادی تبدیل به کربن شد!

حقیقتش را بخواهید، خرابکاری مقوله‌ای علمی است! درواقع می‌توان خرابکاری را فرموله کرد، آموزش داد و حتی لیسانس و نشان خرابکاری گرفت... باورش دشوار است!؟ برای من هم سخت بود؛ ولی با من همراه شوید تا با منسجم‌ترین راهنمای خرابکاری جهان که هنوز هم کاربرد دارد آشنایتان کنم!

نزدیک به هشتاد سال پیش، برای فروپاشاندن و تخریب یک سیستم پیچیده تطبیق‌پذیر – کشور، شرکت و اداره، مواردی طراحی و توصیه‌شده است که به شکل عجیبی امروزه هم بسیاری از آن‌ها و مصادیقشان را در محیط‌های کاری شاهدیم. عجیب‌تر اینکه بسیاری از آن‌ها، نه به‌عنوان عامل منحوس خرابکاری و فروپاشی که به‌عنوان یک استاندارد عُقلایی، متد طلایی یا تجربه موفق پذیرفته‌شده‌اند!

چگونه محیط کاری خود را به آتش بکشید!

🔥 https://vrgl.ir/ciMjw


@iranagile

تفکر سیستمی برای توسعه دهندگان نرم‌افزار

چند روز پیش، آقای کنت‌بک(مبدع اکس پی ) یک ارایه خیلی جذاب در مورد تفکر سیستمی ویژه برنامه نویس‌ها داشت.

از این لحاظ این ارایه جذاب هست که هم خیلی ساده توضیح میدن، و هم اینکه برای نرم‌افزاری‌هاست و اینکه خود ایشون از دنیای چابک است. مثلاً اینکه چرا خیلی از تغییرات ما در دنیای نرم‌افزار مثل نوشتن تست اتوماتیک اتفاق نمی‌افتند

توصیه می‌شود با حوصله ببینید حتی اگر فنی نیستید، البته لازم نیست فنی باشید 👇👇👇

https://youtu.be/z8bL_V9in9o

@iranagile

🌱 چگونه رفتار سیستم را تغییر بدهیم؟

اسامی عوض می شوند ولی تغییر خاصی در رفتارها و نرم های قدیمی به وجود نمی‌آید. شاید این پرتکرارترین سوال دوستان در حوزه چابکی باشد: بسیاری از شرکتها (مهم نیست کوچک و بزرگ) خودشان فعالانه دنبال چابک شدن هستند، هزینه های زیادی (مثل آموزش، استخدام مربی چابک، گرفتن نقش اسکرام مستر و .. . تغییر عناوین شغلی) یا ایجاد روال های جدیدی کار مثل جلسات اسکرام انجام می‌دهند، ولی تعداد زیادی از شرکتها دوباره همان عادتهای قدیمی را این بار با اسامی جدید انجام می‌دهند. مثلا به جای “گانت چارت” از نقشه راه یا رودمپ استفاده می‌کنند که دقیقا کارکرد گانت چارت قبلی را داشت.

رفتار و عادتهای فعلی سیستم از کجا ایجاد می‌شوند؟

خیلی عوامل، ولی یکی از مهمترین فاکتورها در هر سیستم چیزی هست به اسم “جاذب‌ها یا مجذوبگرها” یا به انگلیسی “Attractor”. بگذارید با یک مثال واقعی از دو شرکت ایرانی شروع کنیم (البته اسم شرکتها رو برای ایجاد نکردن سوتفاهم ذکر نمی‌کنم).

ادامه نوشته در لینک زیر 👇👇👇

https://blog.scrum.ir/2021/08/system-attractors/

@iranagile

داستان تحول چابک بوش آلمان

بوش با هر استانداردی شرکت عظیمی محسوب می شود. این شرکت مهندسی و فناوری آلمانی حدود 400000 کارمند دارد و محصولات آن - آگاهانه و ناآگاهانه - بخشی از زندگی روزمره ما هستند.

طی پنج سال گذشته ، تحول هیجان انگیزی در بخش ابزارها شرکت ایجاد شده است. بخش کالاهای مصرفی انواع ابزارهای برقی، ابزار اندازه گیری و لوازم جانبی مانند مته، اره برقی، سمباده و چیزهای دیگر را تولید می کند.

در لینک زیر می‌توانید داستان این سفر پنج ساله بوش را مطالعه کنید 👇👇👇

https://corporate-rebels.com/transforming-bosch


@iranagile

چرا اکثر تخمین‌ها در تیم‌های نرم افزاری اشتباه از آب درمیاید؟

آیا اصلا امکان این وجود دارد که بتوانیم تخمین خیلی دقیق داشته باشیم؟ چند روز قبل به صورت اتفاقی یک پدیده ای برای من اتفاق افتاد که دقیقا سوال همین پرسش‌ها بود.

https://blog.scrum.ir/2021/09/%d8%aa%d8%ae%d9%85%db%8c%d9%86-%db%8c%d8%a7-%d9%be%db%8c%d8%b4-%da%af%d9%88%db%8c%db%8c/

@iranagile

✍️ مراقب تله واعظ شدن بعنوان یک اسکرام‌مستر باشید

یکی از وجوه لازم برای هر اسکرام‌مستر معلم بودم و توانایی انتقال مفاهیم و اصول اسکرام و چابک به تیم و سازمان است، اما در همان حال اسکرام‌مستر میتواند در تله واعظ بودن بیفتد. واعظی که فقط موعظه می‌کند.
در این وضعیت قوانین اسکرام را بدون در نظر گرفتن کانتکست تیم، ویژگی‌های منحصر به فرد محیط و دینامیک سازمان، شروع به تبلیغ می‌کند. قوانین اسکرام به عنوان حقایقی خشک ارائه می‌شوند که باید رعایت شوند.
تشخیص اسکرام مستر به عنوان واعظ بسیار آسان است زیرا هر مکالمه ای در مورد اسکرام در سطح تئوری و نظری باقی می‌ماند. اغلب اوقات حتی مکالمه طولانی هم نیست، زیرا تنها استدلال این است "زیرا در راهنمای اسکرام است ..."
چرا یک تیم باید از هدف محصول استفاده کند؟
زیرا اخیراً به راهنمای اسکرام اضافه شده است.
چرا دیگر نمی‌توانیم درباره تیم‌های توسعه صحبت کنیم؟ زیرا در نسخه جدید راهنمای اسکرام حذف شده است.
چرا باید "خود سازماندهی" را به "خودمدیریتی" در همه جا تغییر دهیم؟ زیرا Scrum Guide عبارت را تغییر داده است.

به نظر می رسد اسکرام مستر به عنوان واعظ دارای سه ویژگی مشخص است:

یک - عدم تجربه در دنیای واقعی
دو - اعتماد به نفس کاذب
سه - تنها ابزار موجود در جعبه ابزارش اسکرام است

مهارت آموزش زمانی موثر است که بتوانید دانش خود را در چارچوب یک تیم قرار دهد. اگر موانعی را که یک تیم با آن روبرو است و محیطی که بخشی از آن هستند درک کنید، می توانید رویکردی متناسب با آن ارائه دهید. با این حال، اگر شما تجربه واقعی ندارید و وضعیت تیم را به درستی درک نمی کنید، تنها چیزی که باقی می‌ماند این است که آنچه راهنمای اسکرام بیان می کند را تکرار کنید.

بیشتر بخوانید 👇👇

https://medium.com/the-liberators/when-the-scrum-master-as-a-teacher-becomes-a-preacher-98810c545752

@iranagile

چگونه مطمئن شویم تحول چابک شکست خواهد خورد؟

یکی از مشکلاتی که جامعه و متخصصین حوزه چابک با اون مواجه هستند اینکه اطلاعات خیلی زیادی در حوزه چابک بدست آوردن و دقیقاً میدونند که یک تیم چابکی چه شکلی هست، چگونه کار می‌کند و یا ساده تر اینکه تصویری از اوتوپیا دارن، اما اینکه یک تیم یا شرکت را چگونه باید از نقطه فعلی به اون نقطه که در ذهنشون هست برسونند، دانش کمی دارن، چون این در حیطه خود چابکی نیست و معمولا چون این انتقال در دنیای واقعی شکل نمی‌گیرد، اون دانش چابک نیر فقط در سطح نظری باقی میمونه و اکثرا ناامید می شوند، تو این ویدئو بیشتر در خصوص این داستان صحبت شده است 👇👇

https://lnkd.in/dSv3u4Pg

☝️☝️☝️

اطلاعات بیشتر در خصوص تحول چابک و یادگیری بیشتر خصوص تحول چابک برآیند محور یا outcome driven

👈 هفته آینده رویداد بعدی شروع خواهد شد

https://scrum.ir/agile-transformation-mastery/

🔨 مدیریت اینقدر مهم هست که آن را نباید به مدیران بسپاریم

در صنعت توسعه نرم‌افزار، برخی واژگان به صورت اشتباه به جای هم استفاده می‌شوند، مثلاً کمتر توجه می‌کنیم که مدیریت محصول مساوی با مدیر‌محصول نیست، یا معماری نرم‌افزار مساوی با معمار نرم افزار نیست یا ...

اولی یک سری فعالیت و مأموریت هست که باید انجام شود، دومی نقش یا جایگاهی هست که در سازمان تعریف شده است برای انجام یک سری فعالیت و به ثمر رساندن مأموریتی خاص.

اما این آیا همان نیست؟ نکته مهم این هست که بعضاً اشتباه در اینجا صورت می‌گیرد که فکر می‌کنیم صرفا مدیر محصول باید مدیریت محصول را انجام بدهد، یا معماری نرم‌افزار باید توسط یک نقش به نام معمار نرم افزار انجام شود. در مثال مدیریت محصول، مدیر محصول باید مطمئن شود که فعالیت‌های مربوط به مدیریت محصول رو زمین نمانده و انجام می شوند ولی این به معنی نیست که همه تصمیم‌ها را خودش باید بگیرد. مثلاً یکی از فعالیت‌های مهم در مدیریت محصول کشف و تدوین استراتژی محصول هست، اما آیا مدیر محصول می‌تواند این فعالیت را به تنهایی انجام بدهد؟ اگر حتی بتواند، آیا اختیارات را لازم را دارد؟ اگر اختیارات لازم را دارد، اصلا بدون درگیر کردن ذینفعان میتواند به استراتژی مناسبی رسید؟

حال دقیقاً همین کانسپت را در مورد مدیریت در نظر بگیرید، مدیریت بعنوان یک سری فعالیت و مدیر بعنوان یک نقش یا جایگاه

اگر بخواهیم مفهوم تیم خود مدیریت را ساده توضیح بدهم، در نظر بگیرید که ما انتظار داریم یک فرد همه تیم را مدیریت و سازماندهی کند یا تیمی داریم که بخشی از فعالیت‌های مدیریت در درون تیم صورت می‌گیرد و مدیر مطمئن می‌شود فعالیت‌های مدیریت در حال انجام هستند.

در نوشته‌ جالبی می‌خواندم، مدیریت چنان مهم هست که آن را نباید به مدیران بسپاریم، این به این معنی نیست که مدیران را کنار بگذاریم، بلکه این بدین معنی است که به جای اینکه سعی کنیم یک تنه همه را مدیریت کنیم، که معمولا این همراه با تجربه حس استرس بالایی خواهد بود بخاطر اینکه مدیریت افراد باهوش بسیار کار سختی و بعضاً غیرممکن هست، آنها را در فعالیتهای مدیریت درگیر کنیم.
اما چگونه باید تیم خودمدیریت ایجاد کنیم؟ 👇👇👇

https://blog.scrum.ir/2021/01/%da%86%da%af%d9%88%d9%86%d9%87-%d8%aa%db%8c%d9%85-%d8%ae%d9%88%d8%af-%d8%b3%d8%a7%d8%b2%d9%85%d8%a7%d9%86%d8%af%d9%87-%d8%a7%db%8c%d8%ac%d8%a7%d8%af-%da%a9%d9%86%db%8c%d9%85%d8%9f/

@iranagile

وقتی شرکت فولکس واگن ۵۰ میلیارد دلار بخاطر نشاختن دینامیک توسعه نرم‌افزار به فنا می‌دهد؟

رشد سریع شرکت تسلا در صنعت خودروسازی بعنوان یک شرکت فناوری، همه شرکتهای خودروسازی را در معرض خطر بزرگی قرار داد. یکی از این شرکتها، شرکت خودرو سازی فولکس واگن بود. چرا ما با این تجربه و پشتوانه در صنعت خودروسازی نباید بتوانیم خودروهای هوشمند طراحی کنیم و یک شرکت کوچک بتواند بازار را بگیرد؟ پنجاه میلیارد دلار با ایده شکست و گرفتن بازار تسلا در این پروژه سرمایه گذاری شد، اما چه شد؟ خودرو آماده بود ولی‌خبری از نرم افزار نبود...
یا حتی بدتر، بعد اینکه ماشین تحویل مشتریان شد، بعد از مدتی مشتریان برای آپدیت نرم‌افزار باید به دوباره به کارخانه مراجعه می‌کردند. مثل اینکه شما هر بار گوشی خودتان را می‌خواهید آپدیت کنید باید به صورت حضوری به شرکت اپل مراجعه کنید.

اما داستان این بود، آنها شناختی از توسعه نرم‌افزار نداشتند، دقیقا فرایند توسعه نرم‌افزار را دقیقاً مانند خط تولید خودرو تصور می‌کردند، بزرگترین اشتباه این بود که فکر می‌کردند، توسعه نرم‌افزار یک پروژه است که شروع می شود و تمام خواهد شد، اما فضای نرم‌افزار چنین نیست، نرم افزار پویا است نه استاتیک. آنها محصولات و خدماتی هستند که شما به طور دائم ارائه می‌دهید. در فضای فکری تولید همیشه بیشتر یعنی بهتر، اما در توسعه نرم افزار: نرم افزار بیشتر و بدهی فنی بیشتر. هدف واقعی این است که تا آنجا که ممکن است نرم افزار کمی توسعه داده شود.

نرم افزار قابل صنعتی سازی شدن نیست ؛ بخاطر اینکه تکامل می‌یابد - این یک سیستم بیولوژیکی است نه مکانیکی (حتی اگر روی ماشین ها کار کند)

اما در واقع فولکس واگن با ماهیت تکاملی و توسعه ای نرم‌افزار دقیقا به صورت تولیدی و صنعتی شده یا همان مثال خط تولیدی برخورد کرد.

متن کامل را اینجا بخوانید

https://jeffgothelf.com/blog/volkswagens-electric-car-ambitions-a-sense-respond-case-study/

@iranagile

🧗فروش لباس زیر توسط برنامه نویس ها در برند ویکتوریا سکرت: چگونه توسعه دهندگان یاد گرفته اند که عاشق صحبت کردن با مشتریان شوند

👈 داستان برای چند سال قبل هست که قرار بود من بعنوان مربی محصول دیجیتال با شرکت ویکتوریا سکرت یکی از بزرگترین تولیدکنندگان لباس زیر همکاری کنم. در یکی از کارگاههای آموزشی که برای توسعه دهندگان نرم افزار بود، در مورد مبحث کشف نیازمندیها باید صحبت میکردیم. خوب همه ما میدانیم، برای کشف نیازمندی ها، یکی از بهترین راهها صحبت کردن با مشتری است، اما توسعه دهنده گان چقدر حاضر هستند با مشتری صحبت کنند؟

برای روز دوم کارگاه اموزشی، من تمرینی طراحی کردم، که توسعه دهنده ها باید در یکی از شعبه های شرکت حاضر میشدند، و با مشتریان واقعی صحبت میکردند.
صبح همان روز، مسئول آموزش شرکت بسیار هراسان سراغ من آمد و گفت برخی از برنامه نویس ها تهدید کردند که اگر آنها را مجبور کنیم که به شعبه بروند و با مشتری صحبت کنند، همین امروز استعفا خواهند داد و این برای ما پذیرفقتنی نیست...
برای من چنین عکس العملی خیلی عجیب بود ... مگر قرار نبود در چابکی ما به تیم ها اجازه و اختیار بدهیم که با مشتری صحبت کنند؟ حالا چرا به جای اینکه خوشحال باشند، چنین عکس العملی نشان می دهند؟

ادامه داستان را در لینک زیر بخوانید

https://jeffgothelf.com/blog/selling-underwear-how-developers-learned-to-love-talking-to-customers/

@iranagile

دوره آموزشی تحول چابک: شروع از هفته آینده

سرفصل دوره :

چرا روش های قبلی تحول کار نمی کنند؟
معرفی روش های برآیند محور
بررسی مدل Agile Fluency Model
بررسی AgendaShift
بررسی Toyota Kata
بررسی Evidence-Based Management Guide
بررسی مدل Factful Agility Framework
شروع تحول با Exploration و رسیدن به یک چشم انداز مناسب
ابزراهای ایجاد چشم انداز تحول و تسهیل گری
بررسی وضعیت فعلی سازمانی – Understand
ابزارهای لازم درک و ارزیابی وضعیت فعلی سازمان
اجرایی کردن اقدامات – Exploit
ابزارهای لازم اجرا و چسبیدن به اقدامات تحول

پیش نیاز دوره آموزشی

این دوره یک دوره پیشرفته محسوب می شود، مثلا اگر بدنبال یادگیری صرفا اسکرام هستید، این دوره برای شما مناسب نیست، و بیشتر برای کسانی است که در دنیای واقعی با چالش های مشخص تحول یا مدیریت تغییرات درگیر بودند.
حداقل دو سابقه کار در حوزه چابکی، یا مدیریت

https://scrum.ir/agile-transformation-mastery/

پنج دلیل برای اینکه چرا باید یک تعریف انجام شد یا Definition of done ✅ داشته باشیم

👇👇👇

https://failfastmoveon.blogspot.com/2021/10/five-reasons-for-having-definition-of.html

@iranagile

🎛️ متریک‌های چابک و اشتباهات رایج

اکثر رهبران و سازمانها اهمیت معیار و متریک‌های چابک را حتی در مدیریت پروژه چابک یا مدیریت محصول درک می‌کنند. ما به عنوان یک شرکت پیشرو در زمینه معیارهای چابک، رایج ترین اشتباهات را هنگام اندازه گیری چابکی از طریق پرسشنامه‌ها و آنچه برای رفع این مشکلات لازم است، را در اینجا آماده کرده ایم.
👇👇👇👇

https://zenexmachina.com/agile-project-management-metrics-and-why-team-surveys-fail/