با شدت گرفتن روند تغییرات در درخواست‌های مشتریان، نیازمندی‌های پروژه‌ها و مسائل مربوط به پشتیبانی محصولات در دهه‌های اخیر، بسیاری از شرکت ها پی بردند که هماهنگ شدن با بازار با استفاده از فرآیند های تجاری قدیمی امکان پذیر نیست. لذا بسیاری از توسعه دهندگان و مدیران محصولات به متدلوژی‌های جدید مانند Agile روی آوردند. در حال حاضر این متدلوژی با وجود نواقصی که به آن وارد است بیشترین طرفدار و بازدهی را به خصوص در میان شرکت های کامپیوتری داشته است.
اما لزوما استفاده از یک متدلوژی، روش یا ابزار موفق، دلیل بر موفق شدن ما نیست، لذا آشنایی با متدلوژی ها و رویکردهایی مانند Lean، Scrum یا Kanban و انتخاب بهترین روش بین آن ها با توجه به نوع محصول، مشتری و شرایط شرکتی که در آن مشغول به فعالیت هستیم یک ضرورت است.
مطالعه لینک زیر می تواند در انتخاب هوشمندانه‌تر این متدولوژی ها بسیار کمک کننده باشد.

https://realtimeboard.com/blog/how-to-choose-between-agile-lean-scrum-and-kanban-which-methodology-is-the-best/#.V18eTlUrLDe

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

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

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



___

✏ چرا مدیرانی که متدولوژی تولید ندارند فکر می کنند اجایل کار می کنند؟

حدود ده دوازده سال پیش در شرکتی مشغول به کار بودم. آنجا هم مثل بسیاری دیگر از شرکتها متدولوژی مشخصی برای تولید نرم افزار نداشتیم و به قول معروف Code & Fix می کردیم. بابت این مساله هم گاهی در جلسات با مشتری شرمنده می شدیم و در جواب اینکه “از چه متدولوژی استفاده می کنید؟”، آسمان و ریسمان می بافتیم و توجیه می کردیم. تا اینکه اسم Agile یا چابک به گوش مدیران شرکت خورد. آن زمان تازه متدولوژی های چابک مطرح شده بود و بخصوص XP مورد توجه بود.

با وجود واژه نوظهور چابک که به دامنه لغات تولید کنندگان نرم افزار اضافه شده بود، مدیران شرکت دیگر نیاز به توجیه در جلسات نداشتند و در پاسخ مشتری ادعا می کردند که متدولوژی تولیدشان چابک است. خیلی هم به روز و دهان پرکن! صرفا با استناد به یکی دو ایده از مفهوم چابک و بدون اینکه کوچکترین تغییری در روش کار شرکت ایجاد کرده باشند.

واقعیت این است که این مساله ربطی به این شرکت و آن زمان ندارد. هنوز هم بسیار اند شرکت هایی که درواقع متدولوژی تولید ندارند، ولی فکر می کنند که چابک کار می کنند. اما این تصور از کجا ناشی می شود؟ چرا مدیران فکر می کنند (یا تظاهر می کنند) که روش کارشان چابک است؟ یا بهتر است بگویم چه چیزی در مفهوم Agile هست که به مدیران و صاحبان شرکت های نرم افزاری اجازه می دهد خود را چابک بدانند؟
📰 📝

https://blog.scrum.ir/2016/01/we-do-agile

@iranagile

📝 بام چگونه روش برنامه‌ریزی خود را تغییر داد؟

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

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

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

اما این مشکل را چگونه باید حل کرد؟

📰 📝

https://blog.scrum.ir/2017/02/bam-release-plan

اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارید «مهندس نرم‌افزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید.
این پیغام را برای آنها Forward کنید.

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

مفاهیم Promise و Deffered Objects در برنامه‌نویسی جاوااسکریپت بسیار مهم و حیاتی هستند. این مفاهیم کمک می‌کنند روش برنامه نویسی async در این زبان استاندارد و یکسان شود. مقاله زیر این مفهوم را به طور خیلی خلاصه و مفید توضیح داده‌است و سه کتابخانه q.js, when.js و jQuery.js را از لحاظ performance برای پیاده سازی promise‌ مقایسه کرده‌است.

https://blog.mediumequalsmessage.com/promise-deferred-objects-in-javascript-pt1-theory-and-semantics

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

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



___

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

۱. نمایش لاگ‌ بیلد‌های MS Build به صورت درختی
#build #msbuild #buildlog
https://t.iss.one/SoftwarePhilosophy/692

۲. شیوه انتخاب «فرایند توسعه محصول» مناسب برای شرکت
#softwareprocess
https://t.iss.one/SoftwarePhilosophy/694

۳. چرا مدیرانی که متدولوژی تولید ندارند فکر می کنند اجایل کار می کنند؟ (Iran Agile)
#agile #softwareprocess
https://t.iss.one/SoftwarePhilosophy/695

۴. بام چگونه روش برنامه‌ریزی خود را تغییر داد؟ (Iran Agile)
#planning
https://t.iss.one/SoftwarePhilosophy/696

۵. مفاهیم Promise و Deffered Objects در JavaScript
#javascript #promise
https://t.iss.one/SoftwarePhilosophy/699

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

خلاصه‌ای از کتاب Managing Humans

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

🔋 آیا جلسات منظم تک به تک برگزار می‌کنید؟ در این جلسات می‌توانید درباره‌ی هر موضوعی غیر از status report بحث می‌کنید؟(+1)
🔋آیا تیم میتینگ را مرتب برگزار می‌کنید؟(+1)
🔋 آیا status report های هفتگی می‌نویسید؟(-1)
🔋به راحتی می‌توانید به مدیرتان نه بگویید؟ (+1)
🔋آیا می‌توانید استراتژی سازمان را به یک غریبه توضیح بدهید؟ (+1)
🔋آیا می‌توانید بگویید وضعیت تجاری سازمان‌تان در چه حال است؟ (یا می‌توانید کسی را معرفی کنید که این را بداند؟) (+1)
🔋 آیا در جمع همکاران، مدیر می‌تواند هر چیزی در ذهنش می‌گذرد را بیان کند؟(+1) آیا حرفش را قبول می‌کنید؟(+1)
🔋 مسیر شغلی که باید طی کنید را می‌دانید؟ (+1) امتیاز اضافه: مدیرتان می‌داند؟ (+1)
🔋 آیا زمان مشخصی دارید که به استراتژی فکر کنید؟ (+1)
🔋آیا شایعات را بلافاصله از بین می‌برید؟ (+1)

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

📰 📝

https://alideishidi.com/2017/01/04/rands-test

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

مفهوم Computer Vision یا «بینایی کامپیوتری» یکی از مباحث جذابی است که اخیرا در نرم‌افزارهای زیادی اثرات آن را می‌بینید. اینکه چگونه در یک عکس، اشیا تشخیص داده شوند و یا در یک فیلم، اشیا متحرک شناسایی شوند مفهومی کاملا پیشرفته است و علوم و تکنیک‌های زیادی در آن دخالت دارند.
مقاله جالب زیر یک دید کلی نسبت به این مفهوم را ترسیم کرده‌است، سپس مثال‌هایی را در زبان C# بیان کرده‌است.

https://www.c-sharpcorner.com/article/a-quick-introduction-to-computer-vision-using-c-sharp

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

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



___

اس کیو ال سرور برای لینوکس

در مارچ 2016 مایکروسافت خبر مهمی منتشر نمود مبنی بر اینکه نسخه تحت لینوکس SQL Server در دست تهیه است. در آن زمان نسخه اولیه بصورت دعوتی در اختیار برخی افراد قرار گرفت اما پس از سپری شدن چند ماه اکنون دانلود و نصب آن برای عموم میسر است.
این نسخه پیش درآمدی بر نسخه اصلی SQL Server به حساب می آید که در آینده برای ویندوز و لینوکس باهم ارائه میگردد. به لطف پشتیبانی از مکانیزم Docker، کاربران mac OS نیز قادر خواهند بود آنرا اجرا نمایند.
چنین رویکردی در زمان مدیریت "استیو بالمر" قابل تصور نبود اما با حضور مدیر جدید مایکروسافت "ساتیا نادلا"، قرار است سرویسها و ابزارها به جایی بروند که مشتریان مایکروسافت حضور دارند، نه فقط جایی که ویندوز وجود داشته باشد. ارائه نسخه کامل تحت لینوکس برای اواسط 2017 برنامه ریزی شده است.
برای ورود به دنیای جدید SQL Server از این لینک شروع کنید:

https://www.microsoft.com/en-us/sql-server/sql-server-vnext-including-Linux

شاد باشید و خوش فکر...
امین ثباتی

📙 Category of Post: #General
📡 Channel: @HighTecSQL
🍀 Your Comments: @AminSobati

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

فریم‌ورک Bootstrap به عنوان یکی از محبوب‌ترین فریم‌ورک‌های CSS شناخته می‌شود. این فریم‌ورک به حدی محبوب شده‌است که آشنایی با آن در بسیاری از جلسات مصاحبه فنی برای موقعیت Front-End Developer حیاتی است.
لینک زیر سوالات متداولی که در جلسات مصاحبه با نیرو‌های جدید در مورد این فریم‌ورک پرسیده می‌شود مطرح شده‌اند.

https://www.c-sharpcorner.com/article/top-bootstrap-interview-questions-and-answers

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

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



___

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

امروزه استفاده از فریم ورکهای css برای برنامه نویسان front end بسیار رایج است.
فریم ورکهای زیادی در این راستا وجود دارد ولی تعداد محدودی از آنها به عنوان فریم ورک خوب شناخته شده اند.
مقاله زیر به صورت خلاصه به معرفی و بررسی 5 فریم ورک برتر پرداخته است و نقاط قوت و ضعف آنها را بیان کرده است.
این 5 فریم ورکها عبارتند از:
• Bootstrap
• Fundation by ZURB
• Semantic UI
• Pure by Yahoo
• Ukit by YOOtheme

https://www.sitepoint.com/5-most-popular-frontend-frameworks-compared

#مریم_داودی

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

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


___

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

ابزار‌های TFS و JIRA از ابزارهای معروف Issue Tracking در پروژه‌های نرم‌افزاری هستند. با اینکه این ابزارها قابلیت استفاده مستقل از تکنولوژی دارند اما عمدتا در پروژه‌های با تکنولوژی‌های مایکروسافت از TFS و در پروژه‌هایی با تکنولوژی‌های Java از JIRA استفاده می‌شود.
مقاله زیر خلاصه‌ی نتیجه‌ی یک تحقیق عملی درباره‌ی قابلیت‌های این دو ابزار ارائه شده‌است. تحقیق به این صورت بوده که یک تیم چهارنفره به دو گروه تقسیم شده‌اند و یکی از گروه‌ها با JIRA و دیگری با TFS کار کرده و در پایان قابلیت‌ها را با هم مقایسه کرده‌اند. در این مقاله به صورت خلاصه واژه‌های مرتبط مانند CI و ALM هم توضیح داده شده‌اند. هدف این مقاله معرفی معیارهایی است که کمک کند در هر شرایطی بهترین انتخاب اتفاق بیافتد.

https://blog.beolle.com/2014/01/research-around-jira-vs-tfs.html

#سمیه_کرمی

لینکدین :
https://ir.linkedin.com/in/skarami

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


___

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

۱. آزمونی برای سنجش سلامت یک تیم مهندسی (Iran Agile)
#softwareprocess #sdlc
https://t.iss.one/SoftwarePhilosophy/702

۲. مفهوم Computer Vision یا «بینایی کامپیوتری» و مثال‌هایی از C#
#csharp #computervision #ai
https://t.iss.one/SoftwarePhilosophy/704

۳. اس کیو ال سرور برای لینوکس (High Tec SQL)
#sqlserver #linux
https://t.iss.one/SoftwarePhilosophy/705

۴. سوالات متداولی جلسات مصاحبه نیرو‌های جدید در مورد فریم‌ورک Bootstrap
#bootstrap #css
https://t.iss.one/SoftwarePhilosophy/707

۵. آشنایی با ۵ فریم‌ورک برتر CSS
#css #framework
https://t.iss.one/SoftwarePhilosophy/709

۶. آشنایی و مقایسه ابزارهای TFS و JIRA
#tfs #jira
https://t.iss.one/SoftwarePhilosophy/711

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

فرایند آموزش در تکنولوژی‌های جدید بسیار موضوع مهمی است. از آنجایی که تکنولوژی‌ها و زبان‌های جدید به شدت در حال رشد و تغییر هستند وجود فرایندها و محیطهای آموزشی مناسب یکی از دغدغه‌های خالقان این تکنولوژی‌ها است.
یکی از روش‌های مرسوم ساخت ابزارهایی به نام Play Ground برای آزمایش زبان‌ها و تکنولوژی‌ها است. پروژه Xamarin Workbooks و یا بهتر است بگوییم .Net Workbook یکی از پروژه‌های جذابی است که یک Play Ground فوق‌العاده برای آزمایش و یادگیری C#, iOS, Android, Azure, Kinect و ... مهیا کرده است.
در این پروژه می‌توان ترکیبی از مستند و کد را ایجاد کرد که قدرت آموزشی بالایی دارد. این پروژه آنقدر جذاب است که Scott Hanselman تصمیم گرفته که در جلسات آموزشی از آن برای آموزش مفاهیم استفاده کند.

اسکات هانسلمن در بلاگ خود کمی در مورد آن توضیح داده‌است. پیشنهاد می‌کنم حتما Xamarin Workbooks را دانلود کنید و turotial آن را دنبال کنید.

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

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/qJR1309lG26

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

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


___

چیزی که شرکت ها را ورشکست می کند، بدهی فنی است نه بدهی مالی

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

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

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

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

اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارید «مهندس نرم‌افزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید.
این پیغام را برای آنها Forward کنید.