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

http://www.agilebuddha.com/agile/agile-estimation-8-steps-to-successful-story-point-estimation/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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

___

نمونه‌ای جالب و جسورانه از تاثیر «مشاهده» در دیزاین gov.uk

محدودیت‌ها و تعصب‌های ذهنی، یکی از بزرگترین دشمنان دیزاینرها هستند. محدودیت‌های ذهن به ما اجازه نمیدن که خرق عادت کرده و Out of box فکر کنیم، تعصب‌ها بدتر هستن و حتی بعضا اجازه نمیدن که ما چیزی رو که میبینیم، باور کنیم.

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

مقاله امروز یه مقاله گزارشی هست درباره بهبود Radio Buttonها و Checkboxها در سایت gov.uk.
این مقاله از دو جهت به نظرم بسیار بسیار هیجان‌انگیز هست. یک اینکه لزوم انجام بهبودهایی که اشاره میشه از طریق مشاهده کار کاربران بوده، و دو اینکه احتمالا دیزاین نهایی به سلیقه بسیاری از ماها خوش نمیاد ولی بسیار کاربردی هست.
در این مقاله مشاهده‌ای برای نحوه برخورد کاربران هنگام مواجهه با Radio Buttonها و Checkboxها انجام شده و متوجه شدند که کاربران برای انتخاب یک گزینه در یک لیست، بصورت ناخودآگاه به جای کلیک روی متن اون گزینه، اصرار دارند که روی Radio Button یا Checkbox کوچکی که در اول سطر قرار داره کلیک کنند.

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

پیشنهاد می‌کنم برای مطالعه بیشتر این بحث و البته دیدن دیزاینی که دیزاینرهای gov.uk بعد از مشاهداتشون بهش رسیدن، به لینک زیر برید.
کامنت‌های زیر پست هم برای مطالعه پیشنهاد میشه. :)

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

https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-radios-and-checkboxes-on-gov-uk/

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

#تجربه_کاربری #گزارش
@HamDesign هَم دیزاین

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. اشتباهاتی که همه ما دیزاینرها انجام می‌دهیم (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/598

۲. معرفی Dapper به عنوان یک Micro ORM
#orm #dapper
https://telegram.me/SoftwarePhilosophy/599

۳. معرفی و مقایسه session storage، local storage و cookie
#clientstorage
https://telegram.me/SoftwarePhilosophy/601

۴. قدم‌های مناسب برای رسیدن به تخمین موفق در پروژه
#estimate
https://telegram.me/SoftwarePhilosophy/602

۵. نمونه‌ای جسورانه از تاثیر مشاهده در دیزاین (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/603

ـــــــــــ
@SoftwarePhilosophy

مدل اسپاتیفای را کپی نکنید

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

@iranagile
@Iranagile

☑️☑️☑️
https://www.infoq.com/news/2016/10/no-spotify-model

الگوی Async Retry Pattern یکی از الگوهایی است که در برنامه‌نویسی برنامه‌های نسل جدید بسیار مهم است. بسیاری دستگاه‌ها و بسترهای جدید شبکه مطمئنی ندارند. برای مثال اینترنت روی گوشی ممکن است بسته به موقعیت قطع و وصل شود و یا کیفیت پایینی داشته باشد. در این بسترها عملیات باید در صورت ناموفق بودن چند بار تکرار شوند و یا اصلاحا retry شود. ابزارهایی که برای retry طراحی شده‌اند این امکان را می‌دهند تا بتوان یک کار را با چند بار retry کردن انجام داد. برای مثال:
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);

RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);

کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.

مقاله زیر ضمن تشریح این الگو، توضیح داده‌است که چطور می‌توان با استفاده از async/await الگوی retry pattern را پیاده‌سازی کرد.

https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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

___

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

🏂🏂🏂

@iranagile
@iranagile

http://www.mountaingoatsoftware.com/blog/the-chief-product-owner-on-large-agile-projects

مدتیست کمپین #NoEstimates در توییتر توجه مهندسین نرم‌افزار را به خود جلب کرده‌است. این کمپین فلسفه جالبی دارد، افراد در این فلسفه اعتقاد دارند story ها نباید estimate شوند!! در این فلسفه تنها تخمین درست این است که آیا یک story به اندازه کافی کوچک هست یا نه. اگر یک story هنوز به اندازه کافی کوچک نیست، باید به تکه‌های کوچکتر شکسته شود. در این تیم‌ها به جای مجموع زمان باقیمانده یا point های باقیمانده از «تعداد» استوری‌های باقیمانده استفاده می‌شود.
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کرده‌است.

http://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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

___

یکی از صحبت های ناتمام در دنیای چابک مسئله Code Review است؟

اصولا نیازی به Code Review داریم؟ آیا فقط یک نفر باید این کار را انجام دهد؟ چه زمانی باید انجام شود؟

تجربه تیم اطلسین استرالیا می تواند به این سوالات جواب دهد

🛠🛠

@iranagile
@iranagile


https://www.atlassian.com/agile/code-reviews

خلق تجربه کاربری خوب و مناسب برای تمام وسایل نمایش، فارغ از سایز آنها، هدف اصلی طراحی responsive است. خواه موبایل باشد یا تبلت یا رایانه شخصی و ....
در حال حاضر 99 سایز متفاوت برای نمایش وجود دارد که این تعداد روز به روز بیشتر می شود. بنابراین با توجه به این تنوع زیاد منطقی به نظر نمی رسد که طراحی ها براساس سایز هر وسیله نمایش باشد. به این معنی که نباید نقاط شکست (breakpoints) را براساس سایزهای مختلف وسایل موجود درنظر گرفت. بلکه این نقاط شکست می بایست براساس محتوی سایت درنظر گرفت. یعنی نقطه شکست وقتی اضافه شود که دیکر نحوه نمایش محتوی مناسب نیست. با این روش دیگر نیازی نیست نگران به بازار آمدن وسایل با سایز نمایشی جدید باشد زیرا نقاط شکست شما با توجه به محتوی سایت شماست نه سایز وسیله نمایش...
مقاله زیر به شرح کامل نحوه انتخاب نقاط شکست(breakpoints) می پردازد.

https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints

#مریم_داودی

لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a

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


___

برنامه‌نویسی VR یا Virtual Reality و دنیای آن بسیار هیجان‌انگیز است. همچنین تجهیزات IoT یا Internet of Things برای برنامه‌نویسان بسیار جذاب است. در «استارتاپ ویکند مد و تکنولوژی» امکان استفاده از این تجهیزات مهیا شده‌است. در این رویداد یک دستگاه Gear VR و همچنین چند دستگاه Beacon برای برنامه‌نویسی مهیا شده‌است. شما می‌توایند برنامه‌های خود را روی این دستگاه‌ها نیز به داوران ارائه کنید.

با توجه به اینکه اعضای کانال @SoftwarePhilosophy عمدتا جز برنامه‌نویسان حرفه‌ای و یا مدیران فنی شرکت‌ها می‌باشند، امکان ثبت‌نام برنامه‌نویسان پر انرژی این کانال با تخفیف ۳۰.۰۰۰ تومانی در «استارتاپ ویکند مد و تکنولوژی» فراهم شده‌است. شما می‌توانید از کد تخفیف زیر در هنگام ثبت‌نام استفاده کنید.

کد تخفیف: SoftwarePhilosophy

لینک ثبت‌نام: http://modotech.ir

ـ

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. مدل اسپاتیفای را کپی نکنید. (iranagile)
#srcum
https://telegram.me/SoftwarePhilosophy/605

۲. الگوی Async Retry Pattern
#async #csharp
https://telegram.me/SoftwarePhilosophy/606

۳. آیا در پروژه‌های بزرگ هم یک نفر تصمیم گیرنده است؟ (iranagile)
#srcum
https://telegram.me/SoftwarePhilosophy/607

۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimate
https://telegram.me/SoftwarePhilosophy/608

۵. پرسش و پاسخ‌هایی در زمینه Code Review
#scrum #codereview
https://telegram.me/SoftwarePhilosophy/609

۶. طراحی responsive و نحوه انتخاب نقاط شکست
#responsive
https://telegram.me/SoftwarePhilosophy/610

۷. کد تخفیف «استارتاپ ویکند» برای اعضای کانال SoftwarePhilosophy

https://telegram.me/SoftwarePhilosophy/611

ـــــــــــ
@SoftwarePhilosophy

مفهوم Asynchronous Programming در Java تاثیر بسیار خوبی در عملکرد نرم‌افزارهای بزرگ و قابلیت Scale شدن آنها دارد. در این مدل thread های استفاده شده در عملیات I/O Blocking باعث می‌شود resource های ارزشمند سرور به هدر نرود و از آنها به درستی استفاده شود. یکی از مشکلات این سبک برنامه‌نویسی «سخت بودن» آن است. نوشتن این نوع کدها معمولا پیچیده‌تر از کدهای معمولی است. مهمترین مفهوم در این سبک برنامه‌نویسی مفهوم Feature است که به معنی کاری است که در آینده انجام خواهد شد و نتیجه آن بعدا آماده می‌شود. برای مثال Feature<String> کاری است که در آینده یک نتیجه از نوع String خواهد برگرداند.

پست زیر در مورد این مفهوم و best practice های استفاده از آن توضیح داده‌است.

http://www.developer.com/java/data/best-practices-of-asynchronous-programming-with-java.html

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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

___

تخفیف برای اعضای کانال @SoftwarePhilosophy

کد تخفیف: SoftwarePhilosophy

ثبت‌نام در: http://modotech.ir

این تخفیف تا روز دوشنبه اعتبار دارد و برای تعداد محدودی قابل استفاده است.

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

گرافیک سه بعدی کامپیوتری و ساخت بازی‌های کامپیوتری جز تکنولوژی‌های پیچیده محسوب می‌شود. اینکه یک ویدئو ساخته شده سه بعدی بتواند کاملا واقعی به نظر برسد کاری بسیار سخت است. در حقیقت ۳ عامل خیلی مهم وجود دارد که باعث واقعی شدن یک نمایش گرافیکی سه بعدی می‌شود.
۱. حرکت‌های طبیعی (Motion)
۲. سایه‌ها (Shadow)
۳. بافت‌ها (Texture)
مفهوم سایه فقط به سایه جسم روی زمین ختم نمی‌شود. به عنوان مثال، برای اینکه موهای یک شخص طبیعی دیده شود سایه تک تک تارهای مو باید به درستی روی بقیه تارهای مو بیفتد و این یعنی حجم وحشتناکی از محاسبات در ثانیه! مفهوم بافت مفهومی است که به یک مدل سه بعدی معنای قابل لمس می‌دهد و آن را برای ما ملموس می‌کند.

ویدئوی زیر که توسط شرکت Method Studios ساخته شده‌است یکی از نمونه‌های فوق‌العاده است که سه مفهوم بالا در آن به زیبایی نمایش داده شده‌است.

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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

___

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

نحوه تعریف متغییرها در یک برنامه می تواند تاثیر زیادی بر کارآیی برنامه داشته باشد. مقاله زیر با زبانی ساده نشان می دهد که چگونه boxing و unboxing می تواند بر بهینه سازی برنامه تاثیر داشته باشد و شش مفهوم Stack ، Heap ، Value type ، Reference Type ، boxing و unboxing را توضیح داده است. همچنین در این مقاله مشاهده می‌کنید که چگونه Cast کردن‌های بیهوده می‌تواند سرعت برنامه ما را تحت تاثیر قرار دهد.

http://www.codeproject.com/Articles/76153/Six-important-NET-concepts-Stack-heap-value-types

#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

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

___

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

کتابخانه Audit.Net کتابخانه فوق‌العاده‌ای است که امکان هندل کردن تمامی سناریو‌های مربوط به لاگ کردن و Audit را با معماری بسیار زیبایی در اختیار معماران نرم‌افزار می‌گذارد. این کتابخانه از فلسفه Convenction over Configuration استفاده کرده و برای تنظیم کردن آن علاوه بر روش‌های متداول، به زیبایی از Fluent API استفاده شده‌‌است.
مساله Audit کردن عملیات برنامه همیشه انرژی زیادی از برنامه‌نویسان سیستم‌های بزرگ می‌گیرد. ساخت Audit در مکان‌های مختلف برنامه می‌توانید اتفاق بیافتد. برای مثال در بستر Object، EntityFramework، WebApi، WCF و بسترهای دیگر می‌توان فرایند Audit را فعال کرد. پیچیدگی دیگر مربوط به نحوه ذخیره‌سازی Audit است. می‌توان آنها را در File، Event Log، Sql Database، NoSQL Database، Azure Blob Store و بسترهای مختلف دیگر ذخیره کرد.

https://github.com/thepirat000/Audit.NET

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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

___

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