Iran Agile

Iran Agile pinned «کارگاه آموزشی مالک محصول حرفه ای (مدیریت محصول چابک) این هفته در چهار جلسه برگزار خواهد شد. سرفصل کارگاه: - ایجاد چشم انداز و تدوین استراتژی محصول - ایجاد ارتباط بین هدف و اجزای بک لاگ محصول - تکنیک‌های متفاوت ایجاد نقشه راه محصول …»

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

سرفصل کارگاه:
- ایجاد چشم انداز و تدوین استراتژی محصول
- ایجاد ارتباط بین هدف و اجزای بک لاگ محصول
- تکنیک‌های متفاوت ایجاد نقشه راه محصول
- مدیریت ذینفعان و نکات کلیدی در دنیای واقعی
- مدیریت و سازماندهی موثر بک لاگ محصول
- چگونه با تیم در طول اسپرینت باید کار کرد؟
- شیوه های متفاوت اولویت بندی
- آشنایی با Story Mapping

اطلاعات بیشتر در این لینک

آینده شغلی مدیریت محصول چه خواهد شد؟

در این ویدئو کلیر وو، مدیر ارشد محصول در لانچ‌دارکلی و بنیانگذار چت‌پی‌اِرد،به این سوال جواب میدهد که آینده شغلی مدیریت محصول چه خواهد شد . در این سخنرانی، او به موارد زیر می‌پردازد:

- چرا مدیریت محصول به شکلی که می‌شناسیم، در حال مرگ است؟
- چگونه هوش مصنوعی توسعه محصول را سریع‌تر از حد انتظار متحول می‌کند؟
- ظهور "سه‌گانه‌های قدرتمند" مبتنی بر هوش مصنوعی که می‌توانند وظایف محصول، طراحی و مهندسی را بر عهده بگیرند؟
- رهبران محصول برای ماندگاری در عصر هوش مصنوعی به چه اقداماتی نیاز دارند؟
- چگونه تیم‌های محصول مبتنی بر هوش مصنوعی را بسازیم و مدیریت کنیم؟

https://www.youtube.com/watch?v=93fCvFkY1Lg

چند روز پیش، یکی از دوستان گله‌ای را با من در میان گذاشت که عمیقاً با تجربه‌های خودم در تیم‌های مختلف همخوانی داشت: «جلسات بازنگری (retro) تیم ما بی‌فایده شده. جالب اینکه همه قبول دارند مشکلاتی وجود دارد، اما همیشه انگشت اتهام را به بیرون نشانه می‌روند. همیشه پای ‘وابستگی‌ها’، ‘قوانین شرکت’، یا ‘گروه یا دپارتمان دیگر’ وسط است و انتهای همه بحث‌ها به این نتیحه میرسیم که فقط مشکلات را به اطلاع مدیران برسانیم، اما هیچ تغییری از طرف خودمان اعمال نمی‌شود.»

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

البته این لزوماً از روی بدجنسی نبوده و یک تمایل طبیعی انسانی است. مغز ما طوری طراحی شده که دنبال توضیحات ساده بگردد و از ناهماهنگی شناختی دوری کند.

ادامه نوشته
https://blog.scrum.ir/2025/01/useless-retro-meetings/

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

سرفصل کارگاه:
- ایجاد چشم انداز و تدوین استراتژی محصول
- ایجاد ارتباط بین هدف و اجزای بک لاگ محصول
- تکنیک‌های متفاوت ایجاد نقشه راه محصول
- مدیریت ذینفعان و نکات کلیدی در دنیای واقعی
- مدیریت و سازماندهی موثر بک لاگ محصول
- چگونه با تیم در طول اسپرینت باید کار کرد؟
- شیوه های متفاوت اولویت بندی
- آشنایی با Story Mapping

اطلاعات بیشتر در این لینک

مدل ذهنی Probabilistic Thinking

به عنوان یک رهبر فنی، یکی از متداول‌ترین (و شاید ناخوشایندترین) سوالاتی که با آن مواجه می‌شوید: «این کار کی تمام می‌شود؟» مشتریان، ذینفعان و حتی اعضای تیم خودتان به دنبال قطعیت در حوزه ای ذاتا نامطمئن هستند. در حالی که ارائه تاریخ‌های دقیق تحویل غیرممکن است، در اینجا می‌توانیم از مدل ذهنی Probabilistic Thinking برای ارائه تخمین‌های واقع‌بینانه‌تر و ارزشمندتر استفاده کنیم.

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

- سندرم فرسودگی شغلی: توسعه‌دهندگان تحت فشار قرار می‌گیرند تا ضرب‌الاجل‌ها را رعایت کنند که منجر به استرس و کاهش بهره‌وری در بلند مدت می‌شود.

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

- از دست دادن اعتماد: عدم رعایت مکرر ضرب‌الاجل‌ها، اعتماد بین تیم توسعه و ذینفعان را از بین می‌برد.

به جای تاریخ‌های ثابت، بیایید عدم قطعیت را بپذیریم. در اینجا نحوه کمک Probabilistic Thinking آورده شده است:

شناسایی عدم قطعیت‌های کلیدی:

پیچیدگی: پیچیدگی کار چقدر است؟ آیا ناشناخته‌ها یا وابستگی‌هایی وجود دارد؟
تغییر دامنه: احتمال تغییر نیازمندی‌ها چقدر است؟
تجربه توسعه‌دهندگان: تجربه تیم در زمینه فناوری و حوزه مسئله چیست؟
عوامل خارجی: آیا عوامل خارجی احتمالی وجود دارد که می‌تواند بر پروژه تأثیر بگذارد (مانند مشکلات زنجیره تامین، تاخیرهای غیرمنتظره)؟

تخصیص احتمالات:

بر اساس ارزیابی شما از این عدم قطعیت‌ها، احتمالات را به سناریوهای مختلف اختصاص دهید.
به عنوان مثال، «۷۰٪ احتمال تکمیل شدن در عرض دو هفته، ۲۰٪ احتمال تکمیل در عرض سه هفته و ۱۰٪ احتمال مواجهه با تاخیرهای غیرمنتظره وجود دارد.»

ارتباط شفاف:

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

ارزیابی مجدد مداوم:

- با پیشرفت پروژه، بازخورد جمع‌آوری کنید، پیشرفت را کنترل کرده و تخمین‌های خود را متناسباً تنظیم کنید.
- این به‌روزرسانی‌ها را به طور منظم با ذینفعان در میان بگذارید تا شفافیت و اعتماد را حفظ کنید.

مثال:

درخواست ویژگی ظاهراً ساده‌ای می‌رسد: «دکمه‌ای به پروفایل کاربر اضافه کنید.»

پیچیدگی: در حالی که این کار ظاهراً ساده است، ممکن است وابستگی‌هایی به سایر بخش‌های سیستم یا موارد حاشیه‌ای غیرمنتظره وجود داشته باشد.
تغییر دامنه: مشتری ممکن است پس از مشاهده اجرای اولیه، درخواست اضافی کند.
ارتباط: به جای گفتن «تا جمعه انجام خواهد شد»، تیم لید ممکن است بگوید: «بر اساس ارزیابی اولیه، ۸۰٪ احتمال تکمیل این کار تا جمعه وجود دارد، اما ۲۰٪ احتمال وجود دارد که با چالش‌های غیرمنتظره‌ای مواجه شویم که می‌تواند جدول زمانی را تمدید کند.»

ایجاد اعتماد از طریق شفافیت

با پذیرش Probabilistic Thinking و ارتباط صادقانه و شفاف، رهبران فنی یا مدیران پروژه می‌توانند اعتماد را با ذینفعان ایجاد کنند. این رویکرد نه تنها منجر به انتظارات واقع‌بینانه‌تر می‌شود، بلکه فرهنگ همکاری و بهبود مستمر را نیز تقویت می‌کند.

نقشه راه چابکی : مدل اجایل فلوئنسی

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

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

ایستگاه 1: متمرکز شدن – تسلط بر اصول پایه
این آغاز سفر چابکی است. تیم‌ها در این مرحله، پایه‌های کار را محکم می‌کنند: هدف‌گذاری شفاف، اولویت‌بندی کارها و همکاری مؤثر. چارچوب هایی مثل اسکرام و کانبان، در این مرحله کاربرد خواهند داشت.

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

ایستگاه 2: تحویل دادن – ارسال ارزش به‌طور مستمر
اتوبوس حالا سرعت می‌گیرد و به ایستگاه "تحویل یا دلیور" می‌رسد. در اینجا، تمرکز تیم‌ها بر تحویل پایدار و با کیفیت است. تصور کنید قابلیت هایی که همیشه سر وقت و بدون دردسر به دست مشتری می‌رسند—بدون موعدهای از دست رفته یا عجله‌های دقیقه نودی.

چرا مهم است: دست یافتن به این مرحله منجر به کاهش اتلافات و باگ ها شده و البته زمان رسیدن به بازار را کوتاه می‌کند. تیم‌ها تبدیل به گروه‌هایی بسیار کارآمد می‌شوند. در این مرحله چارچوب فنی تر مانند اکس پی، DevOps , ... بیشتر مطرح خواهند بود.

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

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

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

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

مدل اجایل فلوئنسی درباره یک مسیر خطی نیست، بلکه درباره انتخاب آگاهانه است. کدام ایستگاه همین حالا برای شما مناسب است؟ به این پرسش‌ها فکر کنید:

چالش‌های اصلی کسب‌وکار شما چیست؟ (مثلاً تحویل ناپایدار، کمبود نوآوری، تأخیر در رسیدن به بازار)
چقدر می‌خواهید سرمایه‌گذاری کنید؟
فرهنگ سازمانی شما چگونه است؟

مدل اجایل فلوئنسی به شما امکان می‌دهد سفر چابکی‌تان را بر اساس نیازهای خاص خودتان تنظیم کنید. بحث رسیدن به یک "بهشت افسانه‌ای چابک" نیست؛ بلکه انتخاب مسیر درست برای دستیابی به اهداف کسب‌وکارتان است.

ورکشاپ بعدی "تحول چابک با مدل اجایل فلوئنسی" در حال ثبت نام است، برای اطلاعات بیشتر میتوانید این لینک را مشاهده کنید.

ورکشاپ "تحول چابک با مدل اجایل فلوئنسی" در حال ثبت نام است

تاریخ برگزاری : ۶، ۷، ۱۳، ۱۴ دیماه ۱۴۰۳

https://lnkd.in/dnjsJMci

چگونه یک جلسه پری‌مورتِم برگزار کنیم؟

بسیاری از تیم‌های مهندسی زمانی که خطا یا مشکلی رخ می‌دهد، جلسه‌ی پست‌مورتِم (Post-Mortem) برگزار می‌کنند. این جلسات برای آن است که تیم دور هم جمع شود و درباره‌ی دلیل بروز مشکل و راه‌های جلوگیری از وقوع مجدد آن بحث کند (نه برای پیدا کردن مقصر یا سرزنش کردن).

اما اگر بتوانیم این شکست‌ها را قبل از وقوع پیش‌بینی و از آن‌ها جلوگیری کنیم چه؟ اینجاست که پری‌مورتِم (Pre-Mortem) وارد می‌شود.

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

چطور یک پری-مورتِم برگزار کنیم؟

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

شروع جلسه

تسهیلگر(معمولاً مدیر محصول یا لید مهندسی) جلسه را با یک پرسش ساده شروع می‌کند:
"چند روز از لانچ محصول گذشته و پروژه شکست خورده است. دلایل این شکست چه بوده‌اند؟"

حاضرین سپس دلایل فرضی و احتمالی شکست پروژه را می‌نویسند. هدف این است که خلاق باشند و هیچ ایده‌ای "بد" یا "مسخره" تلقی نشود.

برای افزایش حس امنیت روانی، سه دسته‌بندی از دلایل مطرح می‌شود:

- ببر (Tiger): مشکلی واقعی که می‌تواند پروژه را به خطر بیاندازد.
- ببر کاغذی (Paper Tiger): مشکلی که دیگران ممکن است نگران آن باشند، اما شما نیستید. دلیل این نگرام نبودن معمولاً این است که شما تقریبا مطمئن هستید این موضوع جای نگرانی ندارد یا حداقل برنامه مشخصی برای آن دارید.
- فیل (Elephant): موضوعی که نمی‌دانید مشکل است یا نه، اما نگران هستید که گروه به اندازه‌ی کافی درباره‌ی آن صحبت نمی‌کند.

اشتراک‌گذاری و دسته‌بندی دلایل

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

توسعه‌ی راه‌حل‌ها و برنامه‌های پشتیبان

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

پرداختن به فیل‌ها

در پایان جلسه، به فیل‌ها می‌پردازیم. این مسائل معمولاً ناشی از کمبود ارتباطات هستند، اما مطرح کردن آن‌ها باعث ایجاد امنیت روانی و ارتباط عمیق‌تر در تیم می‌شود.

جمع‌بندی جلسه

جلسه را با خلاصه‌ای از نگرانی‌های اصلی (ببرها، ببرهای کاغذی، و فیل‌ها) و برنامه‌های عملی به پایان برسانید. اقدامات بعدی، افراد مسئول، و زمان‌بندی مشخص را تعیین کنید و از همکاری تیم تشکر کنید.

متن اصلی

چرا استعاره تحول کرم‌ابریشم به پروانه برای تغییرات سازمانی اشتباه است

شاید این چیزی که میگویم یک نظر نامحبوب باشد ولی بیایید یک استعاره قدیمی و پرکاربرد را به چالش بکشیم: این که تغییر در سازمان مثل تبدیل شدن کرم‌ابریشم به پروانه است. این استعاره در اکثر کتاب های تحول دیجیتال استفاده شده است.

این استعاره در نگاه اول زیبا به نظر می‌رسد. یک کرم‌ابریشم 🐛 که تلاش می‌کند، در نهایت به یک پروانه‌ی زیبا و بی‌نقص 🦋 تبدیل می‌شود. انگار دو حالت مشخص داریم: وضعیت فعلی که ناقص است و آینده‌ای آرمانی و ایده‌آل که همه چیز در آن کامل است.

اما مشکل اینجاست: تغییر در دنیای واقعی این شکلی نیست.

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

اما حقیقت این است که زندگی - و سازمان‌ها - هیچ‌وقت این‌طور عمل نمی‌کنند.

چسبیدن به این استعاره باعث می‌شود انتظارات اشتباهی ایجاد کنیم و در نهایت خسته شویم. چرا؟ چون:

- حالت ایده‌آل یک سراب است 🏝️ – هیچ وضعیت کاملی وجود ندارد. هر مرحله جدید چالش‌های و مشکلات خاص خودش را دارد.
- باعث نارضایتی می‌شود 😕 – وقتی آینده‌ای بی‌نقص را بزرگنمایی می‌کنیم، ارزش حال حاضر را پایین می‌آوریم و وقتی به آن کمال نمی‌رسیم، افراد ناامید می‌شوند.
- خستگی ناشی از تغییر را افزایش می‌دهد 💤 – تلاش برای رسیدن به یک آرمان غیرممکن انرژی و انگیزه تیم‌ها را تحلیل می‌برد.

تکامل استعاره بهتری از تحول است 🌱

در علم پیچیدگی، رسیدن به تعادل، هدف نیست؛ بلکه یک زنگ خطر ⚠️ است. سیستم‌هایی که به تعادل می‌رسند، از تکامل بازمی‌مانند و در طبیعت، این یعنی مرگ 💀. سیستم‌های زنده با سازگاری مداوم زنده می‌مانند.

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

چرا تکامل استعاره بهتری است؟ 🔄
تکامل این واقعیت‌ها را درباره تغییر بهتر نشان می‌دهد:

- تداوم دارد 🔁 – تغییر متوقف نمی‌شود. هر قدم دریچه‌های جدید را باز می‌کند، اما موانع جدیدی هم به همراه دارد.
- واقع‌گرایانه است ⚙️ – تمرکز بر پیشرفت است، نه کمال.
- انطباق‌پذیر است 🌍 – تکامل به محیط واکنش نشان می‌دهد و بر پایه بازخورد و ظهور شکل می‌گیرد.

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

چرا این موضوع برای عوامل تغییر مهم است؟ 💡
به عنوان عاملین تغییر، باید از فروختن آرمان‌شهرها 🏰 دست برداریم. به جای این که آینده‌ای دست‌نیافتنی را وعده دهیم، بیایید تغییر را به عنوان یک سفر 🚶‍♂️🚶‍♀️ معرفی کنیم—سفری که ارزشش نه به خاطر پایان آن، بلکه به خاطر این است که ما را به سازگاری، رشد و کشف وادار می‌کند.

سازمان‌ها، مثل سیستم‌های زنده، زمانی رشد می‌کنند که تکامل را بپذیرند، نه وقتی که در تعقیب یک توهم کمال باشند.

اسد صفری

انجمن DDD ایران با افتخار اعلام می‌کند که در راستای گسترش تعاملات علمی در حوزه مهندسی نرم‌افزار برای ایرانیان و فارسی‌زبانان، با برگزاری یک رویداد آنلاین در رویداد جهانی 2024 Global Day of DDD مشارکت خواهد داشت.

رویداد Global Day of DDD که توسط جامعه مجازی Virtual Domain-driven design سازماندهی می‌شود، شامل یک رویداد آنلاین اصلی و مجموعه‌ای از رویدادهای محلی (Local) است که توسط جوامع DDD در کشورهای مختلف به طور همزمان و در یک بازه 16 ساعته برگزار می‌شود. انجمن DDD ایران افتخار دارد که در این رویداد جهانی مشارکت کند و با برگزاری یک رویداد آنلاین، فضایی برای تعامل و تبادل نظر علاقه‌مندان ایرانی فراهم آورد.

🔹 اطلاعات رویداد

▪️ تاریخ : پنجشنبه 1 آذر ۱۴۰۳
▪️ زمان: از ساعت ۹ الی ۲۲
▪️ قالب برگزاری: آنلاین
شرکت در این رویداد برای تمامی علاقه‌مندان رایگان است.

لینک ثبت نام:
https://evand.com/events/global-day-of-ddd-6256241

جلسات بی فایده، یا عدم مشارکت اعضای تیم در موضوعات جلسه

این دو مورد از شایع ترین مواردی هست که این روزها در تیم های چابک گزارش می شود، یا اعضای تیم از جلسات بی فایده شکایت دارند که وقتشان در آن تلف می شود، یا اسکرام مسترها/مربی‌های چابک از این که اعضای تیم در جلسات مشارکت نمی‌کنند، گله‌مند هستند.
اینجا دقیقا جایی است که نقش یک تسهلیگر خوب تعریف می شود:

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

اسکرام مسترها/مربی‌های چابک باید بر روی مهارت تسهیلگری خود سرمایه گذاری خوبی انجام بدهند، زیراکه می توانند با این ابزار در داخل تیم و شیوه کاری تحول بزرگی ایجاد کنند.

ورکشاپ تسهیل‌گری چابک آبان امسال در شش جلسه از 17 آبان تا 2 آذر به صورت آنلاین برگزار خواهد شد. برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید.

🧩 بزرگ‌ترین سوءتفاهم درباره تبدیل شدن به یک مدیر محصول 🧩

هفته قبل در طی دوره آموزشی مدیر محصول چابک، مفهومی مطرح شد بعنوان اینکه مدیر محصول باید mini-CEO محصول باشد، مثل اینکه در رأس یک ساختار سازمانی قرار بگیری، تیم‌ها رو هدایت کنی و تصمیم نهایی با تو باشد. اما این تصویر یک ذره رمانتیک تر از واقعیت هست.

🚫 انتظار: قرار گرفتن در بالای ساختار سازمانی و تصمیم‌گیری نهایی.

✅ واقعیت: در واقع، در رأس هیچ چیزی نیستی! به جای اون، در مرکز یک شبکه از منافع متضاد قرار داری. فروش، بازاریابی، مهندسی، پشتیبانی مشتری، تجربه کاربری... هر کدوم اولویت‌های خودشون رو دارن، و به عنوان مدیر محصول، تو باید همه رو به یک تعادل نسبی و توافق جمعی برسونی، بدون اینکه حق تصمیم‌گیری نهایی توی هیچ حوزه‌ای داشته باشی.

وظیفه تو چی هست؟ تأثیرگذاری بدون اختیار مستقیم، هماهنگ کردن تیم‌های مختلف و پیش بردن کارها به سمت هدفی مشترک حتی وقتی که ذی‌نفعان اهداف متفاوتی دارند. شاید مسئولیت‌ها مشترک باشد، ولی تصمیم‌گیری یک کار تیمی هست. این نقش به همدلی، مهارت‌های ارتباطی و کمی دیپلماسی (با چاشنی صبر زیاد) نیاز دارد.

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

«آها»

بین آگوست ۱۹۷۶ تا آگوست ۱۹۷۷، دکتر پال مک‌کریدی و یک تیم کوچک از اعضای خانواده و دوستانش در جنوب کالیفرنیا صدها نسخه از هواپیمای «گاسامر کاندور» خود را ساختند و بهبود دادند؛ هواپیمایی فوق‌العاده سبک که با نیروی انسانی کار می‌کرد و آنها امیدوار بودند که بتوانند با آن جایزه کرمر را ببرند. برای بردن این جایزه ۵۰ هزار پوندی که در سال ۱۹۵۹ توسط تاجر بریتانیایی، هنری کرمر، بنیان گذاشته شده بود، یک هواپیمای با نیروی انسانی باید از زمین بلند می‌شد، یک مسیر به شکل عدد هشت به طول یک مایل را طی می‌کرد و به سلامت فرود می‌آمد. مک‌کریدی و تیمش ۲۲۲ پرواز آزمایشی انجام دادند و ۹ بار تلاش کردند تا این جایزه را ببرند. اما در پرواز ۲۲۳ و دهمین تلاششان، بالاخره موفق شدند.

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

آیا شما در کارتان از «آها»های کوچک استفاده می‌کنید؟

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

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

«آها» های کوچک به ما در این مسیر کمک می‌کنند. ما به سرعت از یک «آها» به «آها»ی بعدی می‌رویم و به تدریج یاد می‌گیریم که چه چیزی نتیجه مطلوب را تولید می‌کند.

یک «آها»ی کوچک با مفهوم تولید در دسته‌های کوچک در تولید ناب تفاوت دارد. در حالی که دسته‌های کوچک بر سرعت تکمیل کار تمرکز دارند، «آها» های کوچک بر سرعت کشف تأکید دارند.

برای داشتن «آها»ی کوچک، باید:

- سرعت: هرچه سریع‌تر به «آها» برسیم.
- یادگیری: هر «آها» به ما کمک می‌کند که یاد بگیریم و تطبیق پیدا کنیم.
- امنیت: ما باید در حین یادگیری، احساس امنیت کنیم که موفق شویم یا شکست بخوریم.

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

به این نتایج و «آها»های کوچک مرتبط با آنها که به ما کمک می‌کنند در مسیر رسیدن به آن نتایج پیش برویم توجه کنید:

نتیجه: من می‌خواهم آشپز بهتری شوم. آها: «همه از همبرگرهای سبزیجاتی که درست کردم خوششان آمد!»

نتیجه: من می‌خواهم با افراد بیشتری در شبکه‌های اجتماعی ارتباط برقرار کنم. آها: «توییت روز یکشنبه‌ام هیچ توجهی جلب نکرد. شاید باید از روزهای یکشنبه دوری کنم یا حداقل یک تصویر و هشتگ اضافه کنم؟»

نتیجه: من می‌خواهم یک کتاب پرفروش بنویسم. آها: «مردم تمثیل هنرهای رزمی من را درک نکردند، اما گفتند که دیاگرام‌هایم بسیار واضح هستند.»

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

لینک اصلی متن

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

سرفصل کارگاه:
- ایجاد چشم انداز و تدوین استراتژی محصول
- ایجاد ارتباط بین هدف و اجزای بک لاگ محصول
- تکنیک‌های متفاوت ایجاد نقشه راه محصول
- مدیریت ذینفعان و نکات کلیدی در دنیای واقعی
- مدیریت و سازماندهی موثر بک لاگ محصول
- چگونه با تیم در طول اسپرینت باید کار کرد؟
- شیوه های متفاوت اولویت بندی
- آشنایی با Story Mapping

اطلاعات بیشتر در این لینک

ورک‌شاپ TDD OpenAI with SemanticKernel and skUnit
ارائه: مهران داودی
زبان ورک‌شاپ: انگلیسی

این چهارشنبه ساعت ۵ تا ۶ عصر، ورک‌شاپ برنامه‌نویسی هوش‌مصنوعی (OpenAI و LLM) در #dotnet با استفاده از فریم‌ورک‌های #SemanticKernel و #skUnit برگزار می‌شه.

تو این ورک‌شاپ یک kernel هوش مصنوعی از صفر ساخته ساخته می‌شه و همزمان نحوه تست کردنش با استفاده از skUnit آموزش داده می‌شه.

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


🙂 لینک ورک‌شاپ:
https://www.linkedin.com/events/7246447233418547201/comments/

ویدئو: چرا برگزاری جلسات رترو میتواند وقت تلف کردن باشد؟ و چگونه میتوان آن را حل کرد؟

بهبود مستمر در قلب Agile قرار دارد، اما چه اتفاقی می‌افتد وقتی جلسات رترو (Retrospectives) که قرار است ابزاری برای ایجاد این فضای بهبود باشند، در عمل سودمند نیستند؟ در این ویدیو، به دلایل واقعی شکست احتمالی جلسات رترو در تیم‌های چابک پرداخته شده و روش‌هایی برای حل علل اصلی این مشکلات ارائه شده است.

👇👇👇👇👇

https://www.youtube.com/watch?v=nmYqrOs-qeo

ویدئو: چرا استوری پوینت و پلنینگ پوکر میتواند وقت تلف کردن باشد؟ 💢

در تیم‌های چابک، تخمین زدن گاهی اوقات شبیه به بازی حدس و گمان است. 🎲 بسیاری از ما به پلنینگ پوکر 🃏 و استوری پوینت‌ها 📊 برای این حدس‌ها متکی هستیم، اما آیا واقعاً این روش‌ها به ما کمکی می‌کنند؟ مشکل در نحوه استفاده از این روش‌هاست—تیم‌ها اغلب نسبت نسبی استوری پوینت‌ها را فراموش می‌کنند و آنها را به چیزی شبیه به ساعت‌ها یا روزها تبدیل می‌کنند، که این هدف اصلی چنین رویکردی را نقض می‌کند.

برای مثال، وقتی یک کار با ۲ استوری پوینت ارزیابی می‌شود، باید از نظر اندازه—چه از نظر تلاش، پیچیدگی، یا عدم قطعیت—دو برابر بزرگ‌تر از کاری باشد که با ۱ استوری پوینت ارزیابی شده است. با این حال، در عمل، این نسبیت اغلب نادیده گرفته می‌شود 🚧

در این ویدیو، اسد صفری به بررسی این پرداخته است که چرا پلنینگ پوکر و استوری پوینت‌ها ممکن است زمان شما را هدر دهند ⏳ و یک راه‌حل ساده و مؤثر برای حفظ دقت و هماهنگی در تخمین‌ها ارائه داده است.

👇👇👇👇👇

https://www.youtube.com/watch?v=ukaplANARHk

#چابک #اسکرام_مستر #رهبری #بهره‌وری #کار_تیمی #توسعه_نرم‌افزار #کار_هوشمند #همکاری

💡کارگاه اسکرام کاربردی این هفته برگزار خواهد شد. 

به اطلاع دوستانی که پیگیر ورکشاپ  اسکرام کاربردی بودند، می‌رساند که این دوره همین هفته در روزهای ۲۲ - ۲۳ - ۲۹ و۳۰ شهریورماه ۱۴۰۳ با مربی گری اسد صفری برگزار خواهد شد.


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

📎 برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید.

ویدئو: راه حل جلسات روزانه بدرد نخور 💢

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

اینکه چطور میشه از این تله فرار کرد، و فضایی بهتری در جلسات روزانه یا دیلی استنداپ ایجاد کرد؟ ویدئوی جدید در همین مورد است:

👇👇👇👇👇

https://www.youtube.com/watch?v=fo0qtUTbCnM

#چابک #اسکرام_مستر #رهبری #بهره‌وری #کار_تیمی #توسعه_نرم‌افزار #کار_هوشمند #همکاری

آیا انجام هر تغییری در هر شرایطی ممکن است؟

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

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

فیلم ضبط شده دورهمی 17 ام : آیا تفکر استراتژیک و برنامه ریزی بلند مدت همخوان با اصول اجایل هستند؟

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

https://youtu.be/VZPadlVuTF4

دیروز در یکی از تیم‌های ما اتفاق جالب و البته آموزنده‌ای رخ داد که به نظرم به اشتراک گذاشتنش با شما خالی از لطف نیست.

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

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

حالا سوال اینجاست: آیا این روش برای متقاعد کردن یک تیم موثر است؟

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

نکته دیگری که به عنوان یک مشاهده‌گر به چشم آمد این بود که اسکرام مستر مدام یک سری نکات را تکرار می‌کرد؛ انگار چیزی را از حفظ یاد گرفته باشد و همین باعث می‌شد تیم حس کند که بیشتر با یک رویکرد تئوریک طرف است تا یک فردی که واقعا به مسائل و دغدغه‌های آن‌ها گوش می‌دهد.

در نهایت، شاید حرف‌های اسکرام مستر از نظر اصول چابک کاملاً درست و منطقی بود، اما اگر تیم حس نکند که صدایشان شنیده می‌شود یا نگرانی‌هایشان در نظر گرفته شده است، حتی درست‌ترین حرف‌ها هم ممکن است با مقاومت مواجه شوند.

اجایل دوناتز 17 (دورهمی آنلاین چابک کاران ایران)

جمعه، 26 مرداد (16 آگوست 2024) ساعت ۲۰:۰۰ به وقت تهران

موضوع: آیا تفکر استراتژیک و برنامه ریزی بلند مدت همخوان با مفاهیم و اصول چابکی هستند و آیا این دو مفهوم در یک اقلیم می‌گنجند؟


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

در این دورهمی خواهیم کوشید که نظرات و تجربیات خودمان را با هم به اشتراک بگذاریم و البته مشتاق شنیدن نظرات و تجربیات همه دوستان هستیم.
🍩☕

لینک جلسه در گوگل میت:

https://meet.google.com/zdh-adzb-khg

💢یک لیست خوب و جامع از مقالات و نوشته ها در حوزه های Agile testing, DevOPS, Continuous Delivery , ...

👇👇👇
https://lisacrispin.com/observability-continuous-delivery-devops-related-resources/

ویدئوی پیشنهادی - پنل گفت‌وگوی هادی احمدی و ابراهیم نبیئی با موضوع چرا کسب‌وکارها از تیم‌های فنی ناراضی‌اند؟


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

اما دلیل این نارضایتی‌ها چیست؟

https://www.youtube.com/watch?v=4TcvKVMR0pg

امروز یک کتاب جالب تو کتابفروشی دیدم - "هنر شنیدن". یکهو به فکر فرو رفتم: ما همیشه دنبال بهتر کردن مهارت‌های فنی‌مون هستیم، ولی آخرین بار کی رو مهارت گوش دادنمون کار کردیم؟

در دنیای آی‌تی ما، معمولاً غرق تکنولوژی و فریم‌ورک‌های جدید می‌شویم.

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

چرا این مهم هست؟

- جو تیم بهتر میشه وقتی همه حس کنند حرفشون شنیده میشه
- مشکلات رو بهتر حل می‌کنیم چون به همه دیدگاه‌ها گوش میدیم
- اعتماد بین تیم و مشتری بیشتر میشه و کار روون‌تر پیش میرود

حالا چجوری مهارت گوش دادنمون رو تقویت کنیم؟

۱. سعی کنیم همدلی کنیم. خودمونو جای طرف مقابل بذاریم.
۲. سؤال بپرسیم. هر چقدر لازمه. وضوح خیلی مهمه.
۳. چیزی که شنیدیم رو خلاصه کنیم. انگار داریم یک تست یونیت می‌نویسیم، ولی برای ارتباطات!
۴. ذهنمون رو باز نگه داریم. شاید بهترین ایده از جایی بیاد که اصلاً فکرشو نمی‌کنیم

دانلود لیست کامل متریک های محصول 2024

لیست کامل متریک های محصول 2024