رویداد سوم نقطه:
با موضوع: Clean Product

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

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

مفهوم Clean Product یعنی بازگرداندن وضوح، هدف و یکپارچگی به چیزی که می‌سازیم، نه فقط به نحوه‌ی ساختنش.
اما تعریف Clean این‌جا ساده نیست؛ بدون context درست و مناسب Clean Product نمی‌تواند make sense کند

در این سخنرانی، مسعود بهرامی از زبان، تصمیم‌ها و نیت‌هایی می‌گوید که تمیزی واقعی یک محصول را شکل می‌دهند، و دوگانگی میان Clean Code و Clean Product به‌عنوان فرمول یک محصول موفق را معرفی می‌کند

این رو از من داشته باشید که:

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

🗓 سه‌شنبه ۲۹ مهرماه ۱۴۰۴
🕖 ساعت ۱۹:۰۰ تا ۲۰:۳۰
💻 آنلاین

🔗 ثبت‌نام: https://luma.com/qc2yhog5

سلام خدمت همه عزیزان و همراهان گرامی 👋

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

🔵 پلن‌ها:
🔹کوتاه – ۵ ساعت: بررسی سریع و راهنمایی فوری برای تیم‌های کوچک
🔹ماهانه – ۲۰ ساعت: بررسی کامل، Roadmap جامع، جلسات Mentoring و Code Review برای تیم‌های در حال رشد
🔹 پرمیوم – 42 ساعت: معماری کامل، Roadmap چند فصلی، mentoring، Code Review، CI/CD و DevOps guidance، پشتیبانی مستمر برای تیم‌های بزرگ

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

🔗 جزئیات و جلسه هماهنگی رایگان رو از لینک زیر می‌تونید مشاهده کنید
https://masoudbahrami.com/fractional-cto-software-architecture/

🔵 لازم به ذکر هم هست که کماکان جلسات منتورشیپ person-to-person و رایگان من در Adplist هم برقرار است
https://adplist.org/mentors/masoud-bahrami

سلام به همگی عزیزان و همراهان گرامی خسته نباشید

کمتر از 1 ساعت دیگه شروع میشه این برنامه. منتظرتون هستیم😍

خیلی خوشحالم که مقاله و دیدگاه من درباره Technical Debt در آخرین مقاله موسسه جهانی و معتبر CIO.inc با عنوان “How to Fix Decades of Technical Debt” نقل‌قول شده و مورد استناد قرار گرفته است.

این نوشته من همینطور بر روی چندین موسسه و سایت شناخته‌شده جهانی زیر مجموعه Information Security Media Group (ISMG) منتشر و رفرنس داده شده: 🔹 BankInfoSecurity.com 🔹 InfoRiskToday.com 🔹 DataBreachToday.com

🔴 موسسه CIO.inc یکی از معتبرترین و معروف‌ترین موسسات دنیا برای مدیران ارشد IT و رهبران فناوری است و انتشار دیدگاه من در این سطح، فرصتی مناسب برای مطرح شدن گفتمان فنی و سازمانی در سطح جهانی است.

توی این مقاله به پیشینه استعاری بدهی فنی پرداخته‌ام و کاستی‌ها و سوءبرداشت‌های رایج درباره آن را بررسی کرده‌ام. نکته کلیدی که بر آن تأکید کردم این است که بدهی فنی صرفاً مشکلات کد نیست؛ بلکه در اصل یک میانبر زمانی است که بعداً باید با اختصاص زمان مناسب بازپرداخت شود.

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

فراموش نکنیم که زمان مهم‌ترین عامل در توسعه نرم‌افزار است و نحوه مدیریت آن تعیین‌کننده موفقیت یا شکست پروژه‌هاست. متأسفانه این جنبه حیاتی اغلب نادیده گرفته می‌شود و به فراموشی سپرده شده است.

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

🔵 همچنین توی مقاله چهار گروه بدهی را معرفی کردم:

🔹 بدهی از جنس Code-level : توابع نامرتب، نامگذاری ناسازگار و منطق تکراری
🔹 بدهی از جنس Architectural : ماژول‌های به شدت وابسته، تفکیک ناکافی مسئولیت‌ها
🔹 بدهی از جنس Process : نبود تست‌های خودکار، CI/CD کند یا مستندسازی ناقص
🔹 بدهی از جنس Business : نیازمندی‌های محصول نامشخص، تغییر دامنه، یا ویژگی‌های موقتی برای رضایت ذی‌نفعان

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

خیلی خوشحال می‌شوم اگر بازخورد، نظر یا تجربه‌ای درباره این موضوع دارید با من در میان بگذارید.

🔗 مقاله CIO.inc: https://www.cio.inc/how-to-fix-decades-technical-debt-a-29899

🔗 مقاله کامل من: https://masoudbahrami.com/article/technical-debt-more-than-code-more-than-a-metaphor/

📘 10 + 1 Common Software Architecture Mistakes.pdf

این کتابچه مروری سریع بر ۱۰+۱ اشتباه متداول در معماری نرم‌افزار است که در تیم‌های ایرانی مشاهده کرده‌ام. البته که مواردی که در این فایل ذکر شده فقط مختص ایران یا صنعت خاصی نیستند؛ بسیاریشون کاملا جهان شمول هستند.

در این فایل می‌خوانید:
🔵 متداول‌ترین اشتباهات معماری که باعث کاهش سرعت و چابکی تیم‌ها می‌شود
🟡 علائم، اثرات و راه‌حل‌های عملی برای جلوگیری از این اشتباهات
⚪️ نکات کاربردی برای طراحی معماری نرم‌افزار پایدار و مقیاس‌پذیر

نسخه: 1.0.0

🔗 Download the PDF

✍️ نویسنده: Masoud Bahrami
🌐 MasoudBahrami.com

Introducing Exploratory Domain Discovery

Many modeling techniques help us describe what happens in a system; how events unfold, how people interact, how stories flow.

But few help us understand why things are the way they are, or how to reshape them strategically.

Exploratory Domain Discovery (EDD) is a collaborative modeling and design approach aimed at enabling strategic clarity in complex domains. It helps teams reach a shared understanding of their problem space by combining structured exploration with visual collaboration, turning scattered insights into a coherent, evolving model of the domain.

🔘 Watch the video:
https://youtu.be/pH2i1rAAEVQ

🔴 Try EDD:
https://exploratorydomaindiscovery.com/

اطلاع رسانی رویداد آنلاین Exploratory Domain Discovery - Live Demo

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

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

📅 زمان: جمعه، ساعت 17:00 الی 18:30
🌐 محل: آنلاین – LinkedIn Live
💬 شرکت رایگان است!
در این جلسه، EDD را روی یک مثال واقعی به‌صورت زنده مرور خواهیم کرد و کاربرد آن در پروژه‌های واقعی را بررسی می‌کنیم.

🔗 لینک حضور در رویداد(لطفا دکمه attend رو بزنید). لطفا با بقیه هم به اشتراک بگذارید.
https://www.linkedin.com/events/7392826863901016064/

🔗جهت اطلاعات بیشتر در مورد EDD به لینک زیر مراجعه فرمائید
https://exploratorydomaindiscovery.com/

📣 Finally I managed to release my handbook:
How to Fail Test Automation Easily!
Lessons I’ve Learned (and Unlearned) from Failed Test Automation

This handbook dives deep into 60+ real-world mistakes in test automation that I’ve seen countless teams make, small, daily habits that silently destroy test reliability, slow down development, and erode confidence.

📙 Inside, you’ll find practical guidance and examples on:

1. Strategy & Mindset: How teams think about testing, not just how they do it. Avoid treating testing as a checkbox or a late-phase activity.
2. Test Design & Intent: Writing meaningful tests, avoiding overlapping coverage, and focusing on behavior, not implementation.
3. Technical & Execution Mistakes: Handling flaky, slow, or fragile tests, and creating resilient test setups.
4. Tools & Infrastructure: Choosing frameworks wisely, CI/CD pipelines, observability, and maintaining test suites.
5. Team & Collaboration: Breaking silos between QA, Dev, and Product, defining ownership, and improving knowledge sharing.
6. Cost & Value: Understanding ROI, avoiding uneconomical tests, and prioritizing what really matters.
7. Context & Local Challenges: Real-world constraints, common anti-patterns, and strategies to test effectively in complex domains.

💡 Beyond the lessons, the book also includes:
✅ Checklists for healthy testing habits and common bad smells
✅ A Test Strategy Template to guide your team’s approach
✅ Domain-Centric Test Naming examples to align tests with business intent
✅ A Metrics Cheat Sheet showing what to measure (and what to ignore)

With concrete JavaScript examples, realistic scenarios (like bookings, orders, and accounting), and actionable solutions, this book helps you build tests that actually protect both the software and the business.

Whether you are a developer, QA engineer, architect, or team lead, this book will help you recognize bad practices, understand why they happen, and adopt healthy testing habits that improve confidence, speed, and maintainability.

🙏 It’s completely free, if you find it useful, please share it with your team, colleagues, or anyone who’s passionate about better testing.

✍️ Author: Masoud Bahrami
🌐 MasoudBahrami.com
📘 Version: 1.0.0

Download for free:
https://leanpub.com/TestAutomationMistakes

سلام به همگی عزیزان عصر جمعتون بخیر باشه
لایو به زودی استارت میخوره. منتظرتون هستیم

📚 فهرست منابع و لینک‌های پیشنهادی که در طول لایو دمو به آنها اشاره شد

🔹 وب‌سایت رسمی EDD
🔗 https://exploratorydomaindiscovery.com
خانه‌ی EDD، شامل مقالات، مثال‌ها، ابزارها و نظریه‌های پایه.

🔹 معرفی رسمی Exploratory Domain Discovery
🔗 https://exploratorydomaindiscovery.com/b/introducing-exploratory-domain-discovery/
مقدمه‌ای رسمی بر EDD، هدف، ساختار و طرز فکر پشت آن.

🔹 اولین جریان اکتشاف (مثال دمو)
🔗 https://exploratorydomaindiscovery.com/b/the-first-flow-of-exploratory-domain-discovery/
یک نمونه‌ی عملی و گام‌به‌گام از اولین جریان اکتشاف.

🔹 معرفی Domain Circular Pattern (خیلی مهم) ❗️
🔗 https://exploratorydomaindiscovery.com/b/domain-circular-patterns/
توضیح مفهوم چرخه‌ی ارزش و تکرار الگوها در دامنه‌های پیچیده.

🔹 قلب EDD
🔗 https://exploratorydomaindiscovery.com/b/the-heart-of-exploratory-domain-discovery/
بررسی فلسفه‌ی پشت EDD و مفهوم Main Point.

🔹 بلوک‌های سازنده‌ی EDD
🔗 https://exploratorydomaindiscovery.com/b/building-blocks-of-edd/
شرح دقیق بلوک‌های اساسی مورد استفاده در جلسات اکتشاف.

🔹 چهار نقش از پنج نقش
🔗 https://exploratorydomaindiscovery.com/b/the-4-out-of-5-roles/
تشریح نقش‌ها و دینامیک بین افراد در ورکشاپ EDD

🔹 سخنرانی کنفرانس Naming is Caring با موضوع DDD Europe 2024
🔗 https://2024.dddeurope.com/program/naming-is-caring/
متدولوژی EDD اولین بار توسط مسعود بهرامی در DDD Europe 2024 معرفی شد. این رویکرد در ابتدا با عنوان Breadth-First Exploration ارائه شده بود و بعدها برای انعکاس بهتر هدف و گستره‌ی آن به Exploratory Domain Discovery تغییر نام پیدا کرد.

📺ویدئوی رویداد سوم نقطه با موضوع: موضوع: چطور تصمیم‌ها در تیم شما گرفته می‌شوند؟

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

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

ویدئوی این رویداد در کانال یوتیوب منتشر شده است. می‌توانید از طریق لینک زیر ویدئوی کامل رو مشاهده بفرمائید.(توضیح اینکه متاسفانه بخاطر مشکلی که پیش اومد، قسمت‌های ابتدایی برنامه ریکورد نشده)

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

🌟 رویداد چهارم نقطه: چه چیزی فرهنگ تیمی موفق را می‌سازد؟

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

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

سؤالات برای بحث:
⬅️ چه رفتارها یا عادت‌هایی تیم را مثبت و مؤثر می‌کنند؟
⬅️ اعتماد در تیم چگونه شکل می‌گیرد و چه چیزی آن را خراب می‌کند؟
⬅️ تیم شما با اختلاف نظر یا تعارض‌ها چگونه برخورد می‌کند؟
⬅️ چه روش‌ها یا مراسمی به تیم کمک می‌کنند هماهنگ و انگیزه‌مند باقی بماند؟

🗓 تاریخ: سه‌شنبه، ۲۸ آبان ۱۴۰۴
🕖 زمان: ۱۹:۰۰ – ۲۰:۳۰
💻 مکان: آنلاین(لینک رویداد برای افراد بعدا ارسال خواهد شد)

🔵 لینک ثبت‌نام:
https://luma.com/r09py22a

🔵 صفحه رویداد در لینکدین(لطفا بر روی attend کلیک کنید)
https://www.linkedin.com/events/7395354056090750976/

برنامه شروع شده عزیزان. لینک رویداد برای همه عزیزان ایمیل شده. می‌تونید از طریق لینک زیر جوین بشید به رویداد

https://event.alocom.co/class/soheilkarami/noghteh0

📚 لیست منابع برای مطالعه بیشتر

1. کتاب Radical Candor
مدیریت انسانی، بازخورد صادقانه و محترمانه
🔗 https://www.radicalcandor.com/the-book

2. مقاله "Communication is The Job"
نوشته‌ی اندرو بوسورث (CTO متا) – اهمیت نقش ارتباطات در تیم‌ها
🔗 https://boz.com/articles/communication-is-the-job

3. پادکست WeAreNetflix – موضوع: Feedback
گفتگو درباره فرهنگ بازخورد در نتفلیکس
🔗 https://www.youtube.com/watch?v=M-NYcfyVMeU

4. ویدیو: 5 درس برتر رید هستینگز، مدیرعامل نتفلیکس
🔗 https://www.youtube.com/watch?v=BH-Dq50Cz8Q

5. سخنرانی Patty McCord – Creating High Performance Culture (Talks at Google)
🔗 https://www.youtube.com/watch?v=thzDy5A-KfE

6. Netflix’s Engineering Culture
پست / پادکست گرگ اوروز با CTO نتفلیکس، الیزابت استون
🔗 https://newsletter.pragmaticengineer.com/p/netflix

7. Sustaining a Day 1 Culture – Amazon
سخنرانی بث گالتی (Amazon SVP HR)
🔗 https://www.youtube.com/watch?v=oq69KKpq0b0

8. How Netflix builds a culture of excellence – Lenny’s Podcast
گفتگو با الیزابت استون (CTO)
🔗 https://www.youtube.com/watch?v=2XgU6T4DalY

📺How AI will change Software Engineering?

Hosted by Gergely Orosz from The Pragmatic Engineer with Martin Fowler

🔹Abstract:
In this episode, they discuss how AI is changing software development: the shift from deterministic! to non-deterministic! coding; where generative models help with legacy code; and the narrow but useful cases for vibe coding. Martin explains why LLM output must be tested rigorously, why refactoring is more important than ever, and how combining AI tools with deterministic techniques may be what engineering teams need.

They also revisit the origins of the Agile Manifesto and talk about why, despite rapid changes in tooling and workflows, the skills that make a great engineer remain largely unchanged.

🔵 Watch the video:
https://www.youtube.com/watch?v=CQmI4XKTa0U

🎬 ویدئوی رویداد: Exploratory Domain Discovery - Live Demo

🔵 معرفی کوتاه: Exploratory Domain Discovery(EDD) یک رویکرد مدل‌سازی و طراحی مشارکتی است که با شروع از نتیجه (Outcome) مورد انتظار از سیستم، فضای مسئله را به صورت معکوس (Backward) مدل‌سازی می‌کند.

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

اجزای سازنده اصلی EDD (ساده و کم‌تعداد):
🔹 کارت مفهوم دامنه (Domain Concept)
🔹 ارتباطات بین مفاهیم دامنه
🔹 کارت مثال (Example) به ازای هر مفهوم دامنه
🔹 کارت سوال یا چالش
🔹 کارت قانون کسب‌وکار (Business Rule)

🎙 محتوای این رویداد:
مسعود بهرامی در این رویداد، ضمن معرفی کامل EDD، به صورت عملی و زنده (Live Demo) نشان داد که چطور می‌توان از این رویکرد برای مدل‌سازی یک دامنه پیچیده بهره برد.

خبر خوب برای علاقه‌مندان: در وبینار بعدی به صورت زنده نشان خواهیم داد که EDD چگونه می‌تواند در مرحله طراحی سیستم (System Design) به ما کمک کند.

لینک تماشای کامل ویدئو: 👇
https://www.youtube.com/watch?v=brMtD9s7Ne4&t

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

تو پروژه‌های مختلف، وقتی می‌خواید دامنه یک مسئله را درک کنید، معمولاً روی کدام تمرکز می‌کنید؟

🔹جمع‌آوری نیازها (Requirements) از بیزنس و ذینفعان، مثل لیست فیچرها، KPIها، محدودیت‌ها و توقعات مدیر محصول

🔹ساخت و تثبیت زبان مشترک دامنه (Ubiquitous Language) بین تیم توسعه و بیزنس، یعنی همه درباره مفاهیم کلیدی دامنه با یک زبان واحد حرف بزنند و مدل ذهنی مشترک شکل بگیره

💡 تفاوت دیدگاه‌ها در اینجا مطرح هست. برخی معتقدند:

🔵 اول باید Requirements کامل فهمیده شود و بعد سراغ مدل‌سازی و زبان مشترک رفت.

دیگرانی هم می‌گویند:
🔴 تا وقتی زبان مشترک شکل نگرفته، فهم واقعی امکان‌پذیر نیست و باید از ابتدا روی آن کار کرد.

❓ پرسش برای بحث:
- آیا بدون زبان مشترک می‌توانیم Requirements واقعی را درست بفهمیم؟
- یا بدون جمع‌آوری نیازها، زبان مشترک دقیقی شکل نمی‌گیرد؟


🔹 تجربه شما چیست و شما کدام رو برای شروع ترجیح می‌دهید؟ توی گروه کانال می‌تونید نظرات و تجربیاتتون رو به اشتراک بگذارید