🍜۱۱ استراتژی برای رفع وابستگی مابین تیم‌های چابک

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

دلایل زیادی برای وجود این وابستگی ها وجود دارد: مانند ساختار سازمانی، عدم فرا-وظیفه‌ای بودن تیم، معماری نامناسب، سیستم‌ها یا فرآیندهای قدیمی، مقاومت در برابر تغییر و ...

اما تا زمانی که با این وابستگی‌ها مواجه نشویم، چابکی به معنای واقعی لمس نخواهد شد

در ادامه ۱۱ استراتژی در خصوص مواجهه با این وابستگی ها معرفی شده است:

https://medium.com/@caminmccluskey/11-strategies-for-managing-dependencies-between-agile-squads-aac11e3c1f11

@iranagile

❇️ پیاده سازی راحت تر درگاه های پرداخت با Parbad

پرباد یه کتابخونه کاربردی و راحت جهت پیاده سازی درگاه های پرداخت هست و از ASP.NET CORE و AS.PNET MVC و ASP.NET WebForms پشتیبانی میکنه
این کتابخونه از انواع درگاه های زیر پشتیبانی میکنه، همچنین یه درگاه پرداخت تستی هم براتون میسازه که در زمان توسعه بتونین راحت تر پرداخت هاتون رو تست کنین.
✔️Mellat
✔️Melli
✔️Saman
✔️Pasargad
✔️Parsian
✔️Iran Kish
✔️Asan Pardakht
✔️ZarinPal
✔️Pay.ir
✔️IDPay.ir
🔰اینم اموزش فارسیش
https://www.dotnettips.info/post/3009
https://www.dotnettips.info/post/3011
https://www.dotnettips.info/post/3012
https://www.dotnettips.info/post/3013

🗂البته داکیومنت خودش بروز تره
https://github.com/Sina-Soltani/Parbad/wiki

https://github.com/Sina-Soltani/Parbad
____________
@DotNetZoom

قانون آشنایی جیکوب

الگوهای طراحی یا (Design Patterns) زمانی ایجاد می‌شوند که مدت زیادی را کاربران با آن رابط و تجربه‌ی کاربری مشغول هستند و بهترین راه‌حل ممکن را دریافت کرده‌اند.

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

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

bit.ly/dxgn607

(زمان حدودی مطالعه: ۵ دقیقه)

نویسنده: حسین میرزاده

#تجربه_کاربری #قانون_آشنایی_جیکوب #الگوی_طراحی

@Dexign فلسفه دیزاین

_____

طول اسپرینت باید چقدر باشد؟

بستگی دارد...
جواب مشاورها برای این سوال دقیقاً همین خواهد بود. اما دقیقاً به چه چیزی بستگی دارد؟

اسپرینت قلب اسکرام است، یک بازه‌ای زمان ثابتِ یک‌ماهه یا کمتر که طی آن، یک فرآورده «تکمیل‌شده»، قابل‌استفاده و بالقوه قابل‌ارائه، ساخته می‌شود.

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

اما دقیقاً در تعیین طول اسپرینت باید به چه عواملی توجه داشته باشیم؟

https://medium.com/serious-scrum/how-long-a-sprint-should-be-c41a12494471

@iranagile

❇️ نکاتی در مورد تست نویسی روی EF6 / EFCore توسط دیتابیس InMemory

🔸یکی از مزیت های الگوی Repository، قابلیت تست پذیری لایه دیتا به واسه ساختن ریپازیتوری های Fake هست. در واقع ریپازیتوری هایی میسازیم که از (مثلا IRepository) ارث بری میکنه ولی به جای ذخیره سازی در بانک اطلاعاتی، دیتا ها رو به صورت InMemory ذخیره و واکشی میکنه
همچنین روش های دیگری برای اینکار وجود داره مثل Mock کردن DbContext یا DbSet که هر کدوم دردسر ها و محدودیت های خودشو داره تا جایی که حتی بخشیدن عطاش به لقاش منطقی تره
اینجا لیستی از بهترین منابعش رو گلچین کردم (1 و 2 و 3 و 4 و 5 و 6 و 7 و 8 و 9) تا واسه خودمم آرشیو بمونه

🔻توی EFCore به دلیل وجود پروایدر InMemory نیازی به این کار نیست و عمل تست نویسی رو برامون خیلی راحت کرده ولی توی EF6 چون پروایدر InMemory نداریم مجبوریم تن به یکی از این بدیم.

🔹پروژه سورس باز و رایگان Effort یک پروایدر InMemory مخصوص Entity Framework هست (که از نسخه های 5 و 6 EF پشتیبانی میکنه) و امکان Unit Test نویسی برای EF رو براحتی براتون فراهم میکنه و سعی کرده
این کتابخونه از برای دیتابیس خودش از NMemory استفاده میکنه که یک Engine دیتابیس رابطه ای InMemory هست و سعی کرده تا حد زیادی رفتار های یک دیتابیس واقعی رو شبیه سازی کنه و از مواردی از جمله Indexes و Foreign Key Relations و Transaction Handling and Isolation و Stored Procedures و... پشتیبانی میکنه پس به نسبت بقیه روش ها (مثل یه List استاتیک!) در مورد شبیه سازی دیتابیس، رفتار بسیار بسیار قابل اعتماد تری ارائه میده

🔰کار باهاش هم خیلی راحته و از لینک و دردسر ها و محدودیت های پیاده سازی روش های قبلی رو نداره
https://entityframework-effort.net/overview
واسه مطالعه بیشتر هم لینک های زیر خوبن (اینجا و اینجا و اینجا)

نکته:
🔸تمام روش های بالا و اساسا تمام دیتابیس های InMemory (حتی پروایدر InMemory خود EFCore) یه مشکل اساسی دارن و اون هم اینه که هیچ کدوم نمیتونن 100 درصد رفتار یک دیتابیس واقعی رو شبیه سازی کنن. بدیهی هم هست چون که هیچ کدوم نمیتونن تمام قابلیت های دیتابیس واقعی پروژه شما (مثلا SqlServer) رو داشته باشن.

این کمبود ها که تعدادشونم کم نیست بعضی مواقع باعث مشکل میشن مثلا در مورد دیتابیس InMemory خود EFCore :
▪️شما نمیتونین SP های خودتون رو روش اجرا کنین
▪️شما نمیتونین از Transaction های دیتابیسی استفاده کنین
▪️شما نمیتونین از Function های دیتابیسی و یا کلا هر قابلیت منحصر به دیتابیس تون استفاده کنین
▪️قیودی که فقط توی دیتابیس واقعی اعمال میشن و ...
▪️حتی یک کوئری یکسان روی InMemory و دیتابیس واقعی میتونه نتایج متفاوتی داشته باشه (بدلیل تفسیر متفاوتی ازش توسط پروایدر مربوطه انجام میشه)
▪️در واقع تست درون حافظه‌ی LINQ to Objects با تست واقعی LINQ to Entities که روی یک بانک اطلاعاتی واقعی اجرا می‌شود، الزاما نتایج یکسانی نخواهد داشت
▪️حتی اگه یه متدی که معادل SQL ایی نداره توی کوئری هاتون استفاده کنین، هنگام استفاده از InMemory خطا نمیده ولی موقع دیتابیس واقعی خطای عدم امکان تفسیر به معادل Sql میده

🔹در نتیجه همه اینها پاس شدن یک تست با دیتابیس InMemory الزاما دلیل بر صحت عملکرد پروژه و به معنای درست کار کردن برنامه در دنیای واقعی نیست. و ممکنه همون تست با دیتابیس واقعی به خطا بخوره.

🔸در نهایت هرچند که دیتابیس InMemory رفتار قابل اطمینانی از یه دیتابیس رو نمیتونه شبیه سازی کنه ولی در مورادی که به این تناقض ها بخورد نمیکنیم (معمولا در حد CRUD و یه Storage) میتونه خیلی مفید و کاربردی باشه. فقط نکته اش اینه که حواسمون به این کمبود ها باشه و توصیه میشه که حتما در این گونه موارد که از Integration Test به همراه یک دیتابیس واقعی استفاده کنیم

🔻نظر شما در این باره چیه؟ توی پست های بعدی توضیحات بیشتری خواهم داد.
___________________
@DotNetZoom

#پست_مجدد این پست تا به حال نزدیک به ۱۰۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

مفهوم Collectionها در جاوا و نحوه استفاده از آن‌ها مبحث بسیار جذاب و مهمی برای هربرنامه نویس جاوا (یا حتی غیر جاوا) است. همانطور که می‌دانیم مبحث ساختمان‌های داده در جاوا به دو قسمت عمده Collection و Map تقسیم می‌شود که قسمت‌های اول به Collectionها اختصاص دارد . خود collection ها هم به List ها، Setها و ueue ها تقسیم می‌شود.
لینک زیر مقدمه‌ای بر این قسمت ارائه می‌دهد:

https://bit.ly/2x0dMx2

#شهریار_انتظام (http://ow.ly/qDN430nPiCg)

کانال تلگرام:
@SoftwarePhilosophy

___

مبانی سلسله مراتب بصری

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

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

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

برای آشنایی بیشتر با اصول ایجاد و بهبود سلسله مراتب بصری مقاله زیر را مطالعه کنید:

https://bit.ly/dxgn612

(زمان حدودی مطالعه: 15 دقیقه)

نویسنده: محمدرضا پناهی

#سلسله_مراتب #طراحی_بصری #تجربه_کاربری

@Dexign فلسفه دیزاین

______

😡 پنج تکنیک رفع تعارض در تیم‌ها

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

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

🔨 در اینجا پنج روش برای رفع تعارض معرفی شده است

🔗https://www.leadinganswers.com/2020/07/5-tools-for-team-conflict-resolution.html

@iranagile

❇️ استفاده از MongoDb در سیستم احراز هویت ASP.NET Core Identity

اگه توی پروژه ASPNET Core ایی تون از MongoDb استفاده میکنین و میخواین از سیستم احراز هویت Identity روش پیاده کنین
این کتابخونه (AspNetCore.Identity.MongoDbCore) کار یکپارچه سازیش رو براتون انجام میده

کتابخانه های زیادی برای پشتیبانی از MongoDb در Identity وجود دارند که من همشون رو بررسی کردم و این بهترینشون و کاملترینشون بود (بعدشم این یکی AspNetCore.Identity.Mongo)

🔰لینک ریپازیتوری گیتهاب (اموزششم توش هست)
https://github.com/alexandre-spieser/AspNetCore.Identity.MongoDbCore

#MongoDb #Identity
__________________
@DotNetZoom

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

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

۱- فضای کاری مشخصی برای خود در خانه ایجاد کنید.

۲- بین فعالیت‌های شغلی و کارهای شخصی خود در خانه مرزبندی ایجاد کنید.

۳- ساعت کار منظمی برای خود تعیین کنید و در آن زمان در دسترس سایر اعضای تیم باشید.

۴- وضعیت کاری خود را به طور مستمر با هم تیمی‌های خود به اشتراک بگذارید.

۵- با اعضای تیم خود در ارتباط باشید و در مسائل مختلف همفکری کنید.

۶- از ابزارهای برنامه‌ریزی مثل ترلو، آسانا، تسکولو و ... جهت ایجاد نظم در فعالیت‌های تیم استفاده کنید.

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

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

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

https://bit.ly/dxgn613

(زمان حدودی مطالعه: ۵ دقیقه)

نویسنده: نیما‌ حکیم‌رابط

#دورکاری #کارتیمی
@Dexign فلسفه دیزاین

______

👌 چهار روش برای نابود کردن یک تیم چابک توسط یک مدیر/مالک محصول

1. عدم تمرکز یا چشم انداز

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

2. ارتباطات ضعیف پیرامون اهداف و نتایج

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

3. عدم داشتن اختیارات در زمینه اولویت بندی بک لاگ محصول

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

4- عدم احترام به تیم

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

متن کامل
https://medium.com/serious-scrum/4-ways-a-product-owner-can-destroy-a-scrum-team-e6e5cff59eac

@iranagile

آموزش آپلود کردن فایل در ASP NET Core

در این ویدیو تمامی مراحل آپلود کردن فایل در ASP NET Core آموزش داده میشود. فایل با IFormFile از مرورگر کاربر دریافت میشود و در فولدر سرور کپی میشود. در ادامه با محدود کردن دسترسی به فایل آشنا میشوید.

https://codehaks.com/go/eoz

✅ کتابخانه اعتبارسنجی FoolProof برای ASP.NET Core

خیلی وقتا لازم میشه یه سری اعتبارسنجی روی مقادیر ورودی کاربر داشته باشیم. مثلا مقدارش کمتر یا بیشتر از فلان مقدار نباشه و ... تو این شرایط معمولا خودمون میایم و یه Attribute Validation سفارشی ایجاد میکنیم (که تازه اعتبار سنجی سمت کلاینت با jQuery رو هم نداره و فقط سمت سرور چک میشه) ولی الان میخوام یه کتابخونه رو معرفی کنیم که کارتون رو خیلی راحت میکنه.

🔸کتابخانه FoolProof.Core تعداد زیادی Attribute برای اعتبار سنجی مقادیر کاربر داره که همگی علاوه بر Server-side از Client-side Validation هم پشتیبانی میکنن. نسخه قدیمی آن (foolproof) برای ASPNET MVC سابق است.
(آموزش استفاده از آن در سایت dotnettips) ولی این نسخه از ASPNET Core پیشتیبانی میکنه

🔹لیست Attribute های پشتیبانی شده:
✔️ Is
✔️ EqualTo
✔️ NotEqualTo
✔️ GreaterThan
✔️ LessThan
✔️ GreaterThanOrEqualTo
✔️ LessThanOrEqualTo
✔️ Improved required validators:
✔️ RequiredIf
✔️ RequiredIfNot
✔️ RequiredIfTrue
✔️ RequiredIfFalse
✔️ RequiredIfEmpty
✔️ RequiredIfNotEmpty
✔️ RequiredIfRegExMatch
✔️ RequiredIfNotRegExMatch
✔️ In
✔️ NotIn

🔰لینک پکیچ Nuget و مخزن گیتهاب
https://www.nuget.org/packages/FoolProof.Core/
https://github.com/rpgkaiser/FoolProof.Core

#FoolProof #Validation #اعتبارسنجی
__________________
@DotNetZoom

قانون فیتس

«زمان دستیابی به هدف، تابعی از فاصله و اندازه‌ی هدف است.»

این قانون در سال ۱۹۵۴ توسط روانشناسی به نام پائول فیتس مطرح شد. او با بررسی سیستم حرکتی انسان، نشان داد که زمان لازم برای حرکت به یک هدف، به مسافت آن بستگی؛ و با اندازه‌ی آن رابطه‌ی عکس دارد.
طبق قانون او به دلیل سبک-سنگین کردن کاربر بین دقت و سرعت، حرکات سریع و اهداف کوچک منجر به خطای بیشتری می‌شود.

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

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

https://bit.ly/dxgn615-1

https://bit.ly/dxgn615-2

و همینطور صفحه‌ی ویکیپدیای این قانون به راحتی از طریق لینک زیر قابل دسترسی است:

https://bit.ly/dxgn615wiki

(زمان حدودی مطالعه‌ی مقاله‌‌ی اول: ۹ دقیقه، مقاله‌ی دوم: ۱۱ دقیقه )

نویسنده: حسین میرزاده

#تجربه_کاربری #قانون_فیتس #طراحی_تعاملی #فاصله #اندازه

@Dexign فلسفه دیزاین

_____

🎯 اسکرام مسترها قرار است جریان ساز باشند نه اینکه در جریان غر زدن غوطه ور شوند

داستان از آنجا شروع شد که مدیران ارشد سازمان از تیمها درخواست دادند، که میخواهند سرعت (Velocity) تیم ها را در انتهای اسپرینت را ببیند، از نظر اجرایی این کار سختی برای ما نبود اما نگران عواقب آن بودیم.
تمام اسکرام مسترها جمع شدیم و در مورد این نگرانی صحبت کردیم، "پایه استوری پوینت هر تیم با تیم دیگر کاملا متفاوت هست، اگر قرار باشد، با این متر تیمها با هم مقایسه شوند، این عواقب بدی خواهد داشت، مثلا تیم با سرعت 40 به معنی دو برابر بودن سرعت ان نسبت به تیم با سرعت 20 نیست. زیرا آنها اصلا پایه پوینت متفاوتی دارند و ایجاد یک پایه مشترک شدنی نیست".
قرار شد این نگرانی را با مدیران ارشد در میان بگذاریم. آنها به ما قول دادند که چنین نیتی ندارند...

🔬 چند مدت بعد یکی از ذینفعان ما در جلسه گفت، "شما نمی خواهید برای سرعت تیمتون فکری کنید؟"
پرسیدیم : "چطور؟"
گفت:"تیم ایکس رو دیدم که سرعتشون دو برابر شما است..."

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

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

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

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

منبع
https://medium.com/serious-scrum/people-over-processes-but-scrum-master-over-organizational-rules-325a288e3656

❇️ نمونه معماری پیاده سازی شده با ASP.NET Core و Angular و DDD

Architecture with .NET Core 3.1, ASP.NET Core 3.1, Entity Framework Core 3.1, C#, Angular 9.1, Clean Code, SOLID, DDD, Code Analysis, Docker and more.

🔸Technologies
✔️ .NET Core 3.1
✔️ ASP.NET Core 3.1
✔️ Entity Framework Core 3.1
✔️ C# 8.0
✔️ Angular 9.1
✔️ Typenoscript
✔️ JWT
✔️ FluentValidation
✔️ Scrutor
✔️ Serilog
✔️ Docker
✔️ Azure DevOps
✔️ ...
🔹Practices
✔️ Clean Code
✔️ SOLID Principles
✔️ DDD (Domain-Driven Design)
✔️ Unit of Work Pattern
✔️ Repository Pattern
✔️ ...

https://github.com/rafaelfgx/Architecture
________________
@DotNetZoom

قانون کاراییِ زیبایی

شاید مثال نه زیاد درست و نه زیاد غلط «عقل مردم به چشمشان است» را شنیده باشید. امروز به بررسی همین موضوع می‌پردازیم.

اثر کارایی زیبایی در واقع یکی از قوانین اصلی تجربه‌ی کاربری است که به طور صریح می‌گوید:
«کاربران غالباً طراحی زیبا و جذاب را به عنوان دیزاین کاراتر درک می‌کنند.»

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

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

در ۲ مقاله‌ی زیر به بررسی این موارد و نیز چگونگی تست کاربر هنگامی که قاضی او فقط چشمانش هستند می‌پردازیم.

https://bit.ly/dxgn619-1

https://bit.ly/dxgn619-2

(زمان حدودی مطالعه‌ی مقاله‌‌ی اول: ۵ دقیقه، مقاله‌ی دوم: ۶ دقیقه )

نویسنده: حسین میرزاده

#تجربه_کاربری #قانون_کارایی_زیبایی #زیبایی_بصری #کاربردپذیری

@Dexign فلسفه دیزاین

_____

💪 استرس و فشار همیشه وجود دارد، چگونه یک تیم تاب آور درست کنیم؟

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

ادامه مقاله 👇👇👇

https://academy.nobl.io/team-resilience/

@iranagile

✅ معرفی Design Pattern ها به همراه مثال در زبان های مختلف

یکی از بهترین سایت هایی که میشه به عنوان مرجع برای #DesignPattern ها بهش نگاه کرد سایت زیر هست.

این سایت خیلی روون و ساده الگو های برنامه نویسی رو توضیح داده، براشون مثال زده و توی زبان های مختلفی از جمله #C و JavaScript و Java و Python و ... پیاده سازیشون کرده

1️⃣ https://refactoring.guru/design-patterns/catalog
2️⃣ https://www.dofactory.com/net/design-patterns

🔰2تا ریپوی زیر هم پیاده سازی ایی از این دیزاین پترن ها در سی شارپ هست
1️⃣ https://github.com/exceptionnotfound/DesignPatterns
2️⃣ https://github.com/HamidMosalla/CSharpDesignPatterns
_____________________
@DotNetZoom

قانون ۲۰-۸۰ یا اصل پارتو

«۸۰ درصد رخدادها از ۲۰ درصد دلایل به‌وجود می‌آید.»

ویلفردو پارتو اقتصاددان ایتالیایی در سال ۱۹۰۶ دریافت که ۸۰ درصد زمین‌های ایتالیا در دست ۲۰ درصد مردم آن کشور است؛ همچنین پارتو دریافته بود که ۸۰ درصد نخودفرنگی‌های باغچه‌اش در ۲۰ درصد غلاف‌های نخودفرنگی قرار دارند.

اصل ۲۰-۸۰ در تصمیم‌گیری‌های سریع مدیریتی و نیز تجربه‌ی کاربری بسیار کارساز است. شما باید بیشترین تلاش را روی مناطقی متمرکز کنید که بیشترین مزیت را برای اکثر کاربران به همراه داشته باشد.

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

https://bit.ly/dxgn620

(زمان حدودی مطالعه‌ی مقاله‌‌: ۵ دقیقه)

نویسنده: حسین میرزاده

#تجربه_کاربری #اصل_پارتو #قانون_۲۰_۸۰ #بهره_وری

@Dexign فلسفه دیزاین

_____