شایع‌ترین دلیل تخمین زمان اشتباه یک پروژه

تخمین زمان یک پروژه کار آسانی نیست، مخصوصا اگر بخواهید خیلی دقیق باشید. ولی اغلب موارد مشکل تخمین این نیست که خیلی دقیق نیست، بلکه مشکلش این است که خیلی پرت است!
یکی از شایع‌ترین عواملی که باعث می‌شود تخمین زمانی یک پروژه خیلی اشتباه باشد، تفاوت قائل نشدن بین دو مفهوم خیلی مهم است: «تخمین زمان» و «تخمین کار».
«تخمین زمان» مفهومی است که مدیران پروژه دوست دارند در مورد آن صحبت کنند. وقتی صحبت می‌کنند دائما به دنبال شنیدن تخمین زمانی هستند. برای مثال جمله‌ای مانند «این کار تا پنجشنبه هفته بعد انجام می‌شود» جمله‌ای است که زمان انجام شدن کار را تخمین می‌زند.
در مقابل «تخمین کار» مفهومی است که معمولا برنامه‌نویسان دوست دارند در مورد آن صحبت کنند. آنها ترجیح می‌دهند بگویند که این کار به چقدر زمان نیاز دارد. مثلا کاری است که به ۳ روز زمان نیاز دارد. مثلا جمله «این کار به یک هفته کار نیاز دارد» به این معنی نیست که یک هفته دیگر این کار تمام می‌شود و صرفا حجم کار مورد نیاز بیان شده.

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

پست زیر این دو مفهوم را معرفی کرده و تفاوت آن‌ها را در مدیریت پروژه شرح داده‌است.

https://mehrandvd.me/2017/08/02/effort-vs-time-estimation/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/958i30erVZs

#مهران_داودی (https://ow.ly/GwIl309lFEm)

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

___

۱۰ اشتباه کوچک ولی مهلک دیزاین

تا چندی قبل، دیزاین به معنای کامل رفع مشکل نبود و از دید عموم یک محصول خوب، به محصولی گفته می‌شد که زیبایی بصری (Visual Design) خوبی دارد. امروزه محصول ‌خوب یعنی محصولی که نیاز کاربران را رفع کرده، و یا مشکل کاربران را حل کند؛ و دیزاینر خوب کسی است که بتواند راه‌حل‌های خوبی برای حل مشکلات ارائه دهد.

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

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


https://uxplanet.org/10-small-design-mistakes-we-still-make-1cd5f60bc708

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

از #نویسنده_مهمان: آرش دامن‌افشان

#اشتباهات #اصول #طراحی_محصول
@Dexign فلسفه دیزاین

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

آیا ترکیب WebAssembly و .Net آینده برنامه‌نویسی front-end است؟ این نام مقاله جدید اسکات هانسلمن است که در آن توضیح می‌دهد چطور .NET Core 2.0 این ایده را امکان پذیر کرده‌است که کدهای front-end را با c# نوشت و به WebAssembly کامپیال کرد. در این مقاله توضیح داده شده که چطور Steve Sanderson (برنامه نویس اصلی فریم‌ورک knockout) در یک پروژه آزمایشی به نام Blazor دقیقا مانند Angular, Knockout و Ember کد نوشته، با این تفاوت که این کد با C# نوشته شده.

مقاله زیر جزئیات نوشتن کد روی WebAssembly را با استفاده از .Net Core و C# شرح داده‌است.

https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFutureOfTheFrontend.aspx

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/KVCh30ewRvs

#مهران_داودی (https://ow.ly/GwIl309lFEm)

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

___

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

ممکن است در فرایند توسعه‌ی برنامه‌های SPA که UI‌ آن‌ها با screen‌های با اندازه‌های متفاوت موبایل تا دسکتاپ سازگار است٬ نیاز به تست برنامه روی Device ها داشته باشید. Browsersync ابزاری قدرتمند است که در ترکیب با Webpack و Hot Reloading این امکان را به شما می‌دهد تا به جای تست app روی شبیه ساز های device بتوانید مستقیما روی device تست و debug را انجام دهید.
برای توضیحات بیشتر به لینک زیر مراجعه کنید.

https://manavsehgal.com/browsersync-and-webpack-for-testing-web-apps-across-multiple-devices-64e7f7fa62f2


⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/3dge30eCtwT

#شراره_لطفی (https://ow.ly/xvC530dx8xL)


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

___

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

تبدیل کدهای C# به JavaScript در بسیاری از شرایط می‌توان مفید باشد. معمولا قسمت قابل توجهی از کدهای بین سرور و کلاینت که شبیه هم هستند می‌توانند در یک جا نوشته شوند. برای مثال مدل‌های انتقال اطلاعات DTO و یا Validation ها همه کدهایی هستند که پس از تعریف در سمت سرور می‌توانند در سمت کلاینت هم دوباره استفاده شوند.
هدف پروژه Bridge.NET اینجا امکان تبدیل کدهای C# به کدهای TypeScript و یا JavaScript است. در سایت این پروژه به صورت آنلاین می‌توانید آن را آزمایش کنید تا از نحوه کار آن مطلع شوید.

https://bridge.net/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/yrVs30eL96Y

#مهران_داودی (https://ow.ly/GwIl309lFEm)


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

___

يك خبر خوب براى دوستانی كه قصد دارند وارد حوزه هوش مصنوعى شوند.

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

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

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

در صورتی که از کندی Visual Studio رنج می‌برید و علاقه مند هستید سرعت کار ویژوال استدیو را بالاخص در زمان دیباگ و اجرای برنامه‌ها تا چندین برابر بهبود دهید، راهکارهای ارایه شده در این مقاله را که همگی تست شده اند و بعضا دارای PowerShell Script آماده به اجرا هستند استفاده کنید و از بهبود به دست آمده لذت ببرید.

https://docs.bit-framework.com/docs/good-to-know/visual-studio-speedup.html



⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/GrJ430eStMy

#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)

✅ با سپاس از آقای سعید صالحی برای مشارکت در تهیه این مطلب
https://github.com/1saeedsalehi


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

___

اغلب در دولوپ اپ‌های انگولاری که نیاز به بک اند برای تبادل اطالاعات وجود دارد، بک اند روی پورت دیگری از localhost بوده و یا بک اند روی سرور دیگری قرار دارد. در این صورت برای ارسال ریکوست از سمت کلاینت به سرور بک اند دو راه وجود دارد. یکی استفاده از CORS یا سرور ساید پروکسی.
خوشبختانه، Angular CLI این امکان را به ما می‌دهد که با ست کردن proxy config ریکوست از سمت کلاینت به سرور بک اند مورد نظر فرستاده شود.
لینک زیر نحوه انجام این کانفیگ را توضیح می‌دهد.

https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/proxy.md

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/41My30mm7ym

#مریم_داودی (https://ow.ly/HGkG309B7de)


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

___

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

بسیاری از برنامه نویسان و طراحان نرم افزار خاطره خوشی از معماری سرویس‌گرا ندارند. این مسأله دلایل بسیاری دارد که از جمله آنها می توان به پیچیدگی‌های فراوان ESB (Enterprise Service Bus) ها اشاره کرد. معماری سرویس‌گرا تلاشی بود برای جلوگیری از مشکلاتی که معماری یکپارچه (Monolithic) به تیم و محصول تحمیل می‌کرد. هرچند معماری سرویس‌گرا اقبال خوبی از سمت سازمان‌ها و شرکت‌های بزرگ کسب کرد ولی عمر زیادی نداشت و امروز از توجه کمتری برخوردار است. از طرفی محصولات یکپارچه بزرگ سازمانی و مشکلاتشان همچنان وجود دارند.
میکرو سرویس مفهمومی است که سعی میکند با استفاده از تجربه معماری سرویس‌گرا نقص‌های آن را برطرف کرده و به کمک طراحان بیاید.
در معماری میکروسرویس سیستم به اجزاء کوچکتری تقسیم می‌شود که هرکدام به طور مستقل عمل می‌کنند و یک عمل خاص را به خوبی انجام می‌دهند. این میکروسرویس‌ها درکنار همدیگر همان کار یک نرم افزار یکپارچه را انجام خواهند داد، آن‌ها توانایی این را دارند که زندگی را برای طراحان ساده‌تر و زیباتر کنند!

لینک زیر مقدمه مناسبی برای آشنایی دنیای میکروسرویس‌ها است.

https://www.nginx.com/blog/introduction-to-microservices/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/4aX530f2OZz

#مهدی_بلوچی (https://ow.ly/5kxI30exl7k )

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


___

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

یکی از مسایل مهم در دنیای نرم افزار، مساله تغییرات همزمان داده و جلوگیری از آن است. در SQL Server با داشتن یک Transaction از نوع Isolated می‌توان از تغییر همزمان یک آیتم جلوگیری کرد. حال اگر فرآیندهای کاری در .NET پیاده سازی شوند و نرم افزار توزیع شده (دارای چند سرور) باشد، چگونه در کد می‌توان از تغییر همزمان جلوگیری نمود؟ کتابخانه DistrubtedLock در .NET به این امر می‌پردازد و اجازه می دهد تا با استفاده از مکانیزم‌های مختلف در .NET ، یک Lock بین چند سرور نرم افزار ایجاد نمود و از همزمانی جلوگیری نمود.

https://github.com/madelson/DistributedLock/tree/master/DistributedLock

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/jSR630f9rrn

#علیرضا_وفی (https://ow.ly/Vna930dsUGr)

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


___

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

برای APIها و نرم افزارهایی که کاربران زیادی دارند Load Test امری حیاتی بشمار می‌آید. ابزارهای open source زیادی برای اینکار وجود دارند که Gatling یکی از آن ابزارها ست . Gatling ابزاری قدرتمند در زمینه Load test است که از پروتکل HTTP پشتیبانی می کند. با Gatling تنها با استفاده از تعداد اندکی دستگاه می‌توانید صدها هزار درخواست در ثانیه را روی Web application خود شبیه سازی کنید و گزارش و تحلیل‌هایی با پارامترهای دقیق بدست بیاورید. از نکات جذاب Gatling امکان تعریف سناریو تست کارایی به همان صورتی که در سایر فریمورک‌های تست اتوماتیک فراهم شده، می‌باشد. بدین ترتیب می توان این تست را هم در فرایند تست خودکار گنجاند.
توضیحات بیشتر در لینک های زیر:

https://dzone.com/articles/api-load-testing-with-gatling

https://gatling.io/performancetesting /

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/obSH30firlJ

#شراره_لطفی (https://ow.ly/xvC530dx8xL)

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


___

حساسیت‌ها، زنجیری بر بال خلاقیت

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

از روش‌هایی مانند تفکر دیزاین گرفته تا اصولی مانند Material Design و یا Guidelineهای مختلفی که شرکت‌ها برای طراحی تجربه‌کاربری اپلیکیشن‌ها ارائه می‌کنند همه و همه به ما کمک می‌کنند که کار ما، به عنوان دیزاینر، استانداردتر و منظم‌تر شود.
در سال‌های اخیر شرکت‌هایی مانند IDEO ،frog ،IBM و همینطور Cooper کارهای قابل تحسینی در استانداردسازی روش‌ها انجام دادند که به دیزاینرها کمک می‌کنم وقتی در جایی از حل مسائله گیر کردند، به کمک روش‌های ارائه شده، راه‌حلی پیدا کنند.
ولی تب روش‌ها، ابزارها و قواعد ارائه شده توسط شرکت‌های مختلف، این حساسیت را در دیزاینرها ایجاد کرده که اگر در جایی از آن‌ها پیروی نکنند، در حال ارتکاب اشتباهی نابخشودنی هستند. بارها به دیزاینرهایی برخوردم که وقتی طرحی کوچکترین تغییری می‌کند که دیگر با اصول Material Design سازگار نیست، گویی حقوق بشر پایمال شده است. درحالی که اگر تمامی ما اصول Material Design را عینا و مو به مو پیاده کنیم، اپلیکیشن‌های تولید شده همگی شبیه Gmail و Duo و سایر محصولات گوگل خواهد شد.

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

مقاله امروز را از دست ندهید:
https://uxdesign.cc/on-our-obsession-with-design-methods-and-how-to-avoid-it-839ae022ba78

(زمان حدودی مطالعه، ۷ دقیقه)

#ابزارها #روشها #دیزاین
@Dexign فلسفه دیزاین

___

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