Forwarded from ZenMaxe (BiGGyWiLi)
🔆 آمدن Api های اکسل برای پایتون!
🔺بالاخره مایکروسافت، پایتون رو بصورت رسمی درون اکسل اضافه کرد ، برای اینکه بتوانید از این فیچر استفاده کنید باید نسخه ی بتا اکسل ورژن 16.0.16818.2000 رو بگیرید.
🔺بزودی این فیچر بصورت رسمی اضافه میشود.
🌐 Github Link
@ZenMaxe
🔺بالاخره مایکروسافت، پایتون رو بصورت رسمی درون اکسل اضافه کرد ، برای اینکه بتوانید از این فیچر استفاده کنید باید نسخه ی بتا اکسل ورژن 16.0.16818.2000 رو بگیرید.
🔺بزودی این فیچر بصورت رسمی اضافه میشود.
🌐 Github Link
@ZenMaxe
👍6🔥3
Fat Models or business logic
مدل های جنگو دیتابیس هستند، که اونهارو تبدیل به انتخاب بدی برای اراعه رابط لایه سرویس به لایه ذخیره سازی (persistence layer) میکنه. مدل های جنگو ذاتا در پنهان کردن، کپسوله کردن و محافظت کردن از جزییات پیاده سازی در برابر مصرف کننده که اهمیت نمیده یا اجازه دسترسی بهش رو نداره، ناتوان هست.
مدل جنگو یک نمایش از وضعیت دیتابیس و بسیار وابسته به دیتابیس هست و همچنین یک شی لایه–زیرساختی حساب میشود.
نیاز های بیزینس شما نباید به دیتابیس شما زیاد وابسته باشد. در حالی که مدلسازی دقیق داده ها برای دیتابیس رابطه ای بسیار مفید هست، باید در نظر داشت که دیتابیس یک اپلیکیشن نیست، هر کدوم کار متفاوتی رو به عهده دارند.
بیزینس لاجیک شما به لایه سرویس یا لایه عملیاتی تعلق داره. لایه سرویس یک رابط ثابت رو به تمام بخش های اپلیکیشن اراعه میده. لایه سرویس شما متد های معقول و قابل درکی رو برای انسان داره مثل " “register user یا “associate device with user”. این متد ها دربردارنده بیزینس لاجیک شما هستند که معمولا نیاز هست تا قبل به وجود امدن مدل دیتابیس اعمال بشوند یا تعدادی بیزینس لاجیک رو پس از بازیابی مدل های موجود اعمال بکنند. لایه سرویس شما اون جزییات زیاد و درهم‌برهم و غیر ضروری وضعیت دیتابیس رو پنهان میکنه. مصرف کننده ها نباید به جزییات اهمیت بدهند، نباید به انها وابسته باشند( تا بتونیم اونهارو تغییر بدیم بدون اینکه رابط به مشکل بخوره) و همچنین احتمالا نباید به انها دسترسی مستقیم برای ویرایش هر چه میخواهند بدهیم.
.اگر این کار رو انجام ندید و بجاش از مدل های چاق استفاده کنید اتفاقات زیر خواهد افتاد :
1- به طور مکرر در هر جا که از مدل ها استفاده بشود بیزینس لاجیک خود را خواهید نوشت، تو سریالایزر ها، ویو هاو ...
2- از نوشتن کد تکراری خسته میشید و متد های مختلف به مدل اضافه میکنید.این همان مدل چاق است! شاید برای یکی دو متد راحت که وظیفه محاسبه یک چیز ساده رو به عهده دارند مناسب باشد اما مشکل شروع شد. به محض اینکه شروع به دسترسی دامنه ها و پیاده سازی یک چیزی شبیه به ثبت دستگاه برای کاربر در مدل یوزر یا مدل دستگاه کنید، انگار شما یک لایه سرویس را به شیوه ای مضخرف دوباره اختراع کردید که در نهایت مدل شمارو به 4000 خط کد میرساند.
3- هر گوشه از اپلیکیشن شما در حال اپدیت کردن دیتابیس خواهد بود، از طریق مدل به هر گونه که بخواهد. هر بخش اپلیکیشن به ان تکیه خواهند کرد و تمام فیچر ها بر ان اساس ساخته خواهند شد. حالا فرض کنید میخواهید یک فیلد دیتابیس رو تغییری بدید یا یک رویکرد جدید پیاده سازی بکنید، 20 بخش مختلف برنامه شما با این فرض ساخته شده‌اند که هر به‌روزرسانی دلخواه پایگاه داده که توسط مدل مجاز است، معتبر و صحیح است.
@code_crafters
مدل های جنگو دیتابیس هستند، که اونهارو تبدیل به انتخاب بدی برای اراعه رابط لایه سرویس به لایه ذخیره سازی (persistence layer) میکنه. مدل های جنگو ذاتا در پنهان کردن، کپسوله کردن و محافظت کردن از جزییات پیاده سازی در برابر مصرف کننده که اهمیت نمیده یا اجازه دسترسی بهش رو نداره، ناتوان هست.
مدل جنگو یک نمایش از وضعیت دیتابیس و بسیار وابسته به دیتابیس هست و همچنین یک شی لایه–زیرساختی حساب میشود.
نیاز های بیزینس شما نباید به دیتابیس شما زیاد وابسته باشد. در حالی که مدلسازی دقیق داده ها برای دیتابیس رابطه ای بسیار مفید هست، باید در نظر داشت که دیتابیس یک اپلیکیشن نیست، هر کدوم کار متفاوتی رو به عهده دارند.
بیزینس لاجیک شما به لایه سرویس یا لایه عملیاتی تعلق داره. لایه سرویس یک رابط ثابت رو به تمام بخش های اپلیکیشن اراعه میده. لایه سرویس شما متد های معقول و قابل درکی رو برای انسان داره مثل " “register user یا “associate device with user”. این متد ها دربردارنده بیزینس لاجیک شما هستند که معمولا نیاز هست تا قبل به وجود امدن مدل دیتابیس اعمال بشوند یا تعدادی بیزینس لاجیک رو پس از بازیابی مدل های موجود اعمال بکنند. لایه سرویس شما اون جزییات زیاد و درهم‌برهم و غیر ضروری وضعیت دیتابیس رو پنهان میکنه. مصرف کننده ها نباید به جزییات اهمیت بدهند، نباید به انها وابسته باشند( تا بتونیم اونهارو تغییر بدیم بدون اینکه رابط به مشکل بخوره) و همچنین احتمالا نباید به انها دسترسی مستقیم برای ویرایش هر چه میخواهند بدهیم.
.اگر این کار رو انجام ندید و بجاش از مدل های چاق استفاده کنید اتفاقات زیر خواهد افتاد :
1- به طور مکرر در هر جا که از مدل ها استفاده بشود بیزینس لاجیک خود را خواهید نوشت، تو سریالایزر ها، ویو هاو ...
2- از نوشتن کد تکراری خسته میشید و متد های مختلف به مدل اضافه میکنید.این همان مدل چاق است! شاید برای یکی دو متد راحت که وظیفه محاسبه یک چیز ساده رو به عهده دارند مناسب باشد اما مشکل شروع شد. به محض اینکه شروع به دسترسی دامنه ها و پیاده سازی یک چیزی شبیه به ثبت دستگاه برای کاربر در مدل یوزر یا مدل دستگاه کنید، انگار شما یک لایه سرویس را به شیوه ای مضخرف دوباره اختراع کردید که در نهایت مدل شمارو به 4000 خط کد میرساند.
3- هر گوشه از اپلیکیشن شما در حال اپدیت کردن دیتابیس خواهد بود، از طریق مدل به هر گونه که بخواهد. هر بخش اپلیکیشن به ان تکیه خواهند کرد و تمام فیچر ها بر ان اساس ساخته خواهند شد. حالا فرض کنید میخواهید یک فیلد دیتابیس رو تغییری بدید یا یک رویکرد جدید پیاده سازی بکنید، 20 بخش مختلف برنامه شما با این فرض ساخته شده‌اند که هر به‌روزرسانی دلخواه پایگاه داده که توسط مدل مجاز است، معتبر و صحیح است.
@code_crafters
❤1👍1👎1
رویکرد ترجیحی :
1- هر دامنه دارای یک لایه سرویس است که شامل بیزینس لاجیک و همچنین یک رابط قابل اعتماد و خوب برای هرچیزی که ممکن است با ان دامنه کار داشته باشد اراعه میدهد. این رابط شامل دادن خطاهای بیزینس لاجیک که معنای مرتبطی با با بیزینس لاجیک ما دارند هست. مثلا خطای "Django.models.DoesNotExist" را نمایش نمیدهد و اروری برمیگرداند که به مصرف کننده بگوید چه اشتباهی رخ داده.
2- لایه سرویس تنها چیزی هست که به مدل های جنگو دسترسی دارد. به طور کامل مدل های جنگو را برای دامنه خود از دیگر بخش های اپلیکیشن پنهان میکند. دیتاکلاس یا اتریبیوت ها یا هرچیزی که برای استفاده نیاز دارید را برمیگرداند. مدل ها دیگر در بخش های متفاوت اپلیکیشن اپدیت نمیشوند. لایه سرویس کنترل میکند که مصرف کننده چه چیزی را میتواند ببیند و یا به ان دسترسی داشته باشد.
اگرچه پیاده سازی لایه سرویس و هندل تبدیل کردن ریسپانس ها ممکنه نیاز به کد های بیشتر و تست های بیشتری داشته باشه، اما این رویکرد چندین مزیت هم خواهد داشت. قابل اعتماد تر و ماژولار تر و درک ان اسون تر خواهد بود و شما میتونید با ترس کمتر از خراب شدن کدتون، فیچر های مختلفی رو اضافه کنید .
بیزینس لاجیک شما در یک مکان به صورت جداگانه وجود خواهد داشت و میتوان به صورت مستقل ان را تست کرد.
مدل های شما نیاز به تست نخواهند داشت چون انها مدل های جنگو هستند و هیچ‌کاری رو انجام نمیدهند مگر قبلش توسط فریمورک جنگو به طور کامل تست شده باشد.
@code_crafters
1- هر دامنه دارای یک لایه سرویس است که شامل بیزینس لاجیک و همچنین یک رابط قابل اعتماد و خوب برای هرچیزی که ممکن است با ان دامنه کار داشته باشد اراعه میدهد. این رابط شامل دادن خطاهای بیزینس لاجیک که معنای مرتبطی با با بیزینس لاجیک ما دارند هست. مثلا خطای "Django.models.DoesNotExist" را نمایش نمیدهد و اروری برمیگرداند که به مصرف کننده بگوید چه اشتباهی رخ داده.
2- لایه سرویس تنها چیزی هست که به مدل های جنگو دسترسی دارد. به طور کامل مدل های جنگو را برای دامنه خود از دیگر بخش های اپلیکیشن پنهان میکند. دیتاکلاس یا اتریبیوت ها یا هرچیزی که برای استفاده نیاز دارید را برمیگرداند. مدل ها دیگر در بخش های متفاوت اپلیکیشن اپدیت نمیشوند. لایه سرویس کنترل میکند که مصرف کننده چه چیزی را میتواند ببیند و یا به ان دسترسی داشته باشد.
اگرچه پیاده سازی لایه سرویس و هندل تبدیل کردن ریسپانس ها ممکنه نیاز به کد های بیشتر و تست های بیشتری داشته باشه، اما این رویکرد چندین مزیت هم خواهد داشت. قابل اعتماد تر و ماژولار تر و درک ان اسون تر خواهد بود و شما میتونید با ترس کمتر از خراب شدن کدتون، فیچر های مختلفی رو اضافه کنید .
بیزینس لاجیک شما در یک مکان به صورت جداگانه وجود خواهد داشت و میتوان به صورت مستقل ان را تست کرد.
مدل های شما نیاز به تست نخواهند داشت چون انها مدل های جنگو هستند و هیچ‌کاری رو انجام نمیدهند مگر قبلش توسط فریمورک جنگو به طور کامل تست شده باشد.
@code_crafters
👍2❤1
بخش کوچکی از روزمرگی‌های سازمانی
بدخطم منتها پست آموزشی نیست😅😅😅
اون لایه که با رنگ آبی فلش کشیدم لایه جدیدمون هست که میخوام اجرایی بشه در سیستم
فلوچارت و شبه کد فقط مربوط به اون لایه هست نه بیشتر
#daily
@code_crafters
بدخطم منتها پست آموزشی نیست😅😅😅
اون لایه که با رنگ آبی فلش کشیدم لایه جدیدمون هست که میخوام اجرایی بشه در سیستم
فلوچارت و شبه کد فقط مربوط به اون لایه هست نه بیشتر
#daily
@code_crafters
👍6
اسکوپ کریپ چیست؟؟؟
این پست مناسب دوستانی هست که پروژه‌های فریلنسری میگیرن
در طول این سالها با دوستانی که برخورد کردم یک موضوع مشترک وجود داشت
یکی از چالش‌های دنیای پروژه‌های فریلنسری توقعات خارج از چهارچوب اولیه توافق شده بین کارفرما و توسعه دهنده هست بابت اشنایی با جنبه‌های مختلف آن و مدیریت بهتر دو لینک زیر رو بخونید
https://productive.io/blog/scope-creep-prevent/
https://mag.hostiran.net/scope-creep-web-design/
@code_crafters
این پست مناسب دوستانی هست که پروژه‌های فریلنسری میگیرن
در طول این سالها با دوستانی که برخورد کردم یک موضوع مشترک وجود داشت
یکی از چالش‌های دنیای پروژه‌های فریلنسری توقعات خارج از چهارچوب اولیه توافق شده بین کارفرما و توسعه دهنده هست بابت اشنایی با جنبه‌های مختلف آن و مدیریت بهتر دو لینک زیر رو بخونید
https://productive.io/blog/scope-creep-prevent/
https://mag.hostiran.net/scope-creep-web-design/
@code_crafters
Productive
What Is Scope Creep? (And How Can You Prevent It)
Scope creep refers to unplanned changes in a project’s scope that typically cause the project to take a lot longer, and sometimes even fail.
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
به قول حضرت عشق جان من است او. 3>
مگه بهتر از کامپیوترها هم هست؟ :)
اولین خاطره کامپیوتریت چی بود؟
#Nostalgic
🧑💻👩💻 @code_crafters
مگه بهتر از کامپیوترها هم هست؟ :)
اولین خاطره کامپیوتریت چی بود؟
#Nostalgic
🧑💻👩💻 @code_crafters
❤6
اجایل مجموعه ای از اصول و ارزش ها هست که معمولا در توسعه نرم افزار استفاده میشود و باعث افزایش بهره وری تیم میشود.
Agile (چابک)
اجایل یک رویکرد تکراری و افزایشی است که بر انعطاف پذیری، همکاری، و اراعه ارزش ها به مشتریان تاکید دارد.
اجایل برنامه ریزی انطباق پذیر، توسعه مداوم و چرخه های بازخورد سریع رو ترویج میدهد.
اجایل به افراد و تعاملات بیش از ابزار ها، به یک نرم افزار کار کننده بیش از مستندات جامع، به مشارکت مشتری بیش از قرارداد، و به پاسخ به تغییرات بیشتر از پیروی کردن از برنامه ارزش میدهد.
12 اصل اجایل پیشنهاد داده است که به شما برای حفظ این ارزش ها کمک کند :
1- رضایت مشتری در اولویت قرار داشته باشد. یک تیم توسعه نرم افزار باید پیوسته و به طور مداوم محصول خود را اراعه دهد.
2- از هر گونه تغییرات استقبال بشود، حتی اگر پروژه در مراحل پایانی قرار دارد.
3- تحویل زود به زود نرم افزار قابل استفاده به مارکت. طبق اصل 1و2 شما باید سریع نرم افزار رو اراعه بدید و تغییرات رو اعمال بکنید. اجایل به شما یک فاصله زمانی 2-3 هفته تا 2-3 ماهه پیشنهاد میدهد تا نرم افزار خود را در مارکت پابلیش کنید. ترجیح به فاصله زمانی کمتر است.
4- ذی‌نفعان کسب و کار و دولوپر ها باید به صورت روزانه با هم مشارکت داشته باشند.
5- مسئولیت پروژه را برعهده افراد با انگیزه بگذارید. به انها ازادی عمل دهید و انها به دلیل با انگیزه بودنشان بسیار جدی پیگیر پروژه خواهند بود.
6- تیم نرم‌افزار به صورت رو در رو اطلاعات را به همدیگر انتقال دهند زیرا بیشترین تاثیر را دارد.
7- معیار سنجش تیم، خروجی کار باشد.
8- توسعه پایدار به صورت ثابت و مداوم حامیان مالی و توسعه دهندگان.
9- توجه مداوم به برتری فنی و طراحی خوب چابکی رو افزایش میدهد.
10- سادگی – هنر افزایش کار های انجام نشده. از افزودن فیچر های غیر ضروری اجتناب کنید.
11- بهترین معماری ها و نیاز ها و طراح ها از تیم های خود سازمانده پدیدار میشوند. بجای اینکه در یک تیم یک نفر مسعول هدایت تیم باشد باید تمام اعضای تیم مشارکت داشته باشند و از ایده های اعضای تیم استفاده کنند.
12- در فواصل منظم اعضای تیم بر چگونگی موثر تر شدن همفکری میکنند و سپس تیم خود را بر اساس بازتاب این تفکر باید اصلاح کنند.
اجایل بر کوچک کردن بخش های پروژه و تسک های قابل مدیریت تمرکز میکند که بهشون استوری های یوزر میگویند.
اجایل از تیم های کراس-فانکشنال ( تیم هایی که اعضایی با مهارت های مختلف دارند)، همکاری اعضای تیم و مشارکت مکرر مشتری در طول فرایند توسعه نرم افزار حمایت میکند.
فریمورک هایی که بر اساس اصول اجایل ساخته شدند مانند اسکرام، کانبان، Extreme Programming (XP) و ... به طور گسترده ای در شیوه های توسعه استفاده میشوند.
اگر شما به اصول و ارزش های اجایل پایبند باشید، تیم شما بدون در نظر گرفتن فریمورک اجایل محسوب میشود و استفاده کردن از یک فریمورک خاص ضروری نیست.
#agile
#project_managment_system
@code_crafters
Agile (چابک)
اجایل یک رویکرد تکراری و افزایشی است که بر انعطاف پذیری، همکاری، و اراعه ارزش ها به مشتریان تاکید دارد.
اجایل برنامه ریزی انطباق پذیر، توسعه مداوم و چرخه های بازخورد سریع رو ترویج میدهد.
اجایل به افراد و تعاملات بیش از ابزار ها، به یک نرم افزار کار کننده بیش از مستندات جامع، به مشارکت مشتری بیش از قرارداد، و به پاسخ به تغییرات بیشتر از پیروی کردن از برنامه ارزش میدهد.
12 اصل اجایل پیشنهاد داده است که به شما برای حفظ این ارزش ها کمک کند :
1- رضایت مشتری در اولویت قرار داشته باشد. یک تیم توسعه نرم افزار باید پیوسته و به طور مداوم محصول خود را اراعه دهد.
2- از هر گونه تغییرات استقبال بشود، حتی اگر پروژه در مراحل پایانی قرار دارد.
3- تحویل زود به زود نرم افزار قابل استفاده به مارکت. طبق اصل 1و2 شما باید سریع نرم افزار رو اراعه بدید و تغییرات رو اعمال بکنید. اجایل به شما یک فاصله زمانی 2-3 هفته تا 2-3 ماهه پیشنهاد میدهد تا نرم افزار خود را در مارکت پابلیش کنید. ترجیح به فاصله زمانی کمتر است.
4- ذی‌نفعان کسب و کار و دولوپر ها باید به صورت روزانه با هم مشارکت داشته باشند.
5- مسئولیت پروژه را برعهده افراد با انگیزه بگذارید. به انها ازادی عمل دهید و انها به دلیل با انگیزه بودنشان بسیار جدی پیگیر پروژه خواهند بود.
6- تیم نرم‌افزار به صورت رو در رو اطلاعات را به همدیگر انتقال دهند زیرا بیشترین تاثیر را دارد.
7- معیار سنجش تیم، خروجی کار باشد.
8- توسعه پایدار به صورت ثابت و مداوم حامیان مالی و توسعه دهندگان.
9- توجه مداوم به برتری فنی و طراحی خوب چابکی رو افزایش میدهد.
10- سادگی – هنر افزایش کار های انجام نشده. از افزودن فیچر های غیر ضروری اجتناب کنید.
11- بهترین معماری ها و نیاز ها و طراح ها از تیم های خود سازمانده پدیدار میشوند. بجای اینکه در یک تیم یک نفر مسعول هدایت تیم باشد باید تمام اعضای تیم مشارکت داشته باشند و از ایده های اعضای تیم استفاده کنند.
12- در فواصل منظم اعضای تیم بر چگونگی موثر تر شدن همفکری میکنند و سپس تیم خود را بر اساس بازتاب این تفکر باید اصلاح کنند.
اجایل بر کوچک کردن بخش های پروژه و تسک های قابل مدیریت تمرکز میکند که بهشون استوری های یوزر میگویند.
اجایل از تیم های کراس-فانکشنال ( تیم هایی که اعضایی با مهارت های مختلف دارند)، همکاری اعضای تیم و مشارکت مکرر مشتری در طول فرایند توسعه نرم افزار حمایت میکند.
فریمورک هایی که بر اساس اصول اجایل ساخته شدند مانند اسکرام، کانبان، Extreme Programming (XP) و ... به طور گسترده ای در شیوه های توسعه استفاده میشوند.
اگر شما به اصول و ارزش های اجایل پایبند باشید، تیم شما بدون در نظر گرفتن فریمورک اجایل محسوب میشود و استفاده کردن از یک فریمورک خاص ضروری نیست.
#agile
#project_managment_system
@code_crafters
👍4❤2
در پست قبلی با عنوان اجایل موضوعی مطرح گردید و این سوال در ذهن شکل گرفت که آیا امروزه اجایل به ابزاری جهت مانیتورینگ و بهره وری کارمندان تبدیل شده؟؟؟
یکم شرح مسئله کنم
موضوع اصلی و ماجرا از جایی نشات میگیره که این سوال پیش میاد ، ایا اجایل در همه سازمان و تمام بخش‌ها و کارمندان اجرایی شده یا نه ، اگر بخشی یا کارمندی ازین متدلوژی دوری جسته باشه و پیاده سازی نشده باشه چه اتفاقی خواهد افتاد
علاوه بر این شناسایی کارمندان با استعداد و با پشتکار و خلاقیت بالا که برای سازمان سودمند خواهند بود چگونه صورت گیرد
بهتره با موضوع okr هم آشنا بشیم تا بتونیم در خصوص موضوعات بالا تصمیم گیری به عمل آوریم
لذا در چند پست بعدی در خصوص okr مطالبی رو با شما به اشتراک خواهیم گذاشت
در خصوص پیگیری این دست پست‌ها در کانال هشتگ زیر رو جستجو کنید
#project_managment_system
@code_crafters
یکم شرح مسئله کنم
موضوع اصلی و ماجرا از جایی نشات میگیره که این سوال پیش میاد ، ایا اجایل در همه سازمان و تمام بخش‌ها و کارمندان اجرایی شده یا نه ، اگر بخشی یا کارمندی ازین متدلوژی دوری جسته باشه و پیاده سازی نشده باشه چه اتفاقی خواهد افتاد
علاوه بر این شناسایی کارمندان با استعداد و با پشتکار و خلاقیت بالا که برای سازمان سودمند خواهند بود چگونه صورت گیرد
بهتره با موضوع okr هم آشنا بشیم تا بتونیم در خصوص موضوعات بالا تصمیم گیری به عمل آوریم
لذا در چند پست بعدی در خصوص okr مطالبی رو با شما به اشتراک خواهیم گذاشت
در خصوص پیگیری این دست پست‌ها در کانال هشتگ زیر رو جستجو کنید
#project_managment_system
@code_crafters
👍1
اسکرام :
اسکرام یک فریمورک مشخص بر پایه اصول و ارزش های اجایل هست. اسکرام یک رویکرد ساختار يافته برای مدیریت پروژه های پیچیده مخصوصا اون هایی که مرتبا نیاز به تغییر دارند، اراعه میدهد.
اسکرام پروژه را به بخش های کوچک تکرار شونده ای به نام اسپرینت که معمولا 1-4 هفته طول میکشد تقسیم میکند. هر اسپرینت شامل تعدادی تسک های از پیش تعیین شده است که باید در اون مدت زمانی تکمیل بشود.
در اسکرام 3 نقش کلیدی وجود دارد :
1- اسکرام مستر: رهبر پروژه هست و مسعول اموزش دادن شرکت هست. اسکرام مستر با مشخص کردن اهداف پروژه و اسپرینت ها به پروداکت اونر کمک میکنه. همچنین مسعولیت منیج کردن میتینگ ها با اسکرام مستر هست.
2- پروداکت اونر : صاحب محصول. مسعول به هدف رساندن محصول هست. یکی از کار های مهمی که انجام میدهد درست کردن بک‌لاگ هست.
3- دولوپمنت تیم : شامل دولوپرها، تستر ها، دیزاینر ها و ... .
در مورد نقش اسکرام مستر و پروداکت اونر در پست های بعدی بیشتر صحبت خواهیم کرد.
رویداد های اسکرام :
1- برنامه ریزی اسپرینت
برنامه ریزی کردن برای اسپرینت پیشِ رو برای تسک هایی قرار است انجام بشود
2- اسکرام روزانه
در ساعات شروع روز کاری یک میتینگ(انلاین یا حضوری) حداکثر 15 دقیقه ای بین اعضای تیم برگزار میشود و اعضای تیم باید به 3 پرسش پاسخ دهند. چه کاری دیروز انجام داده اند – امروز چه کار قرار هست انجام دهند – چه چیزی پروسه رو بلاک کرده
3- مرور اسپرینت
در پایان هر دوره اسپرینت تمام اعضای مجموعه اعم از تیم دولوپر، سرمایه گذاران و مشتریان دور هم جمع میشوند و درمورد کارهایی که در طول اسپرینت انجام شده صحبت میکنند و از همدیگر بازخورد دریافت میکنند و با توجه به این بازخورد ها تصمیم میگیریند ایا چیزی از برنامه و نقشه نیاز به تغییر داره یا خیر.
4- رترواسپکتیو
در پایان هر دوره اسپرینت برگزار میشود و اعضای تیم اسکرام باید حضور داشته باشند. هدف این میتینگ شناسایی نقاط قوت و ضعف پروژه و اعمال تغییراتی برای ایجاد اثربخشی بیشتر است. کلید خروجی این میتینگ مجموعه ای از تغییرات و پیشرفت های قابل اجرا در پروسس های تیم، همکاری و روش های انجام کار است.
بک‌لاگ – یوزر استوری – ریلیز بک‌لاگ :
بک‌لاگ مکانی است که تسک ها اولویت بندی میشوند و مدیریت این بخش با پروداکت اونر هست. در این بک‌لاگ یوزر استوری ها قرار دارند که از زبان کاربر هستند و از یک الگوی خاص پیروی میکنند : به عنوان (نقش)، من (هدف) میخواهم که (یک مشکل یا خواسته ای رفع) بشود. این یوزر استوری ها بعدا در یک جایی قرار میگیرند به اسم ریلیز بک لاگ و تعیین میکند چه فیچر هایی در چه ورژنی از برنامه قرار هست اضافه بشه، پس اولویت بندی تسک ها در این قسمت از اهمیت ویژه ای برخوردار هست. سپس در برنامه ریزی اسپرینت تعیین میکنید کدوم از تسک ها با توجه به اولویت ها باید انجام بشود.
استوری پوینت :
یسری واحد برای مشخص کردن بزرگی و سختی یوزر استوری ها هست که تیم دولوپمنت راجع به اون تصمیم میگیرد. برای هر دوره اسپرینت تیم دولوپ میداند که چقدر توانایی انجام کار دارد( با استفاده از ابزار هایی مانند نمودار burndown) و با توجه به ان، یوزر استوری های ریلیز بک‌لاگ در هر دوره اسپرینت تعریف میشوند. برای استوری پوینت ها معمولا از اعداد فیبوناچی استفاده میشود(1،2،3،5،8،13،21...).
نمودار burndown : یک بازنمایی بصری از پیشرفت تیم در یک دوره اسپرینت هست. نمایانگر کار باقی مانده در مقابل زمان هست. این نمودار به تیم و ذی‌نفعان کمک میکند تا متوجه بشوند تیم چقدر از برنامه، انحراف داشته است و تصمیمات اگاهانه ای با توجه به ان بگیرند.
#project_managment_system #scrum
@code_crafters
اسکرام یک فریمورک مشخص بر پایه اصول و ارزش های اجایل هست. اسکرام یک رویکرد ساختار يافته برای مدیریت پروژه های پیچیده مخصوصا اون هایی که مرتبا نیاز به تغییر دارند، اراعه میدهد.
اسکرام پروژه را به بخش های کوچک تکرار شونده ای به نام اسپرینت که معمولا 1-4 هفته طول میکشد تقسیم میکند. هر اسپرینت شامل تعدادی تسک های از پیش تعیین شده است که باید در اون مدت زمانی تکمیل بشود.
در اسکرام 3 نقش کلیدی وجود دارد :
1- اسکرام مستر: رهبر پروژه هست و مسعول اموزش دادن شرکت هست. اسکرام مستر با مشخص کردن اهداف پروژه و اسپرینت ها به پروداکت اونر کمک میکنه. همچنین مسعولیت منیج کردن میتینگ ها با اسکرام مستر هست.
2- پروداکت اونر : صاحب محصول. مسعول به هدف رساندن محصول هست. یکی از کار های مهمی که انجام میدهد درست کردن بک‌لاگ هست.
3- دولوپمنت تیم : شامل دولوپرها، تستر ها، دیزاینر ها و ... .
در مورد نقش اسکرام مستر و پروداکت اونر در پست های بعدی بیشتر صحبت خواهیم کرد.
رویداد های اسکرام :
1- برنامه ریزی اسپرینت
برنامه ریزی کردن برای اسپرینت پیشِ رو برای تسک هایی قرار است انجام بشود
2- اسکرام روزانه
در ساعات شروع روز کاری یک میتینگ(انلاین یا حضوری) حداکثر 15 دقیقه ای بین اعضای تیم برگزار میشود و اعضای تیم باید به 3 پرسش پاسخ دهند. چه کاری دیروز انجام داده اند – امروز چه کار قرار هست انجام دهند – چه چیزی پروسه رو بلاک کرده
3- مرور اسپرینت
در پایان هر دوره اسپرینت تمام اعضای مجموعه اعم از تیم دولوپر، سرمایه گذاران و مشتریان دور هم جمع میشوند و درمورد کارهایی که در طول اسپرینت انجام شده صحبت میکنند و از همدیگر بازخورد دریافت میکنند و با توجه به این بازخورد ها تصمیم میگیریند ایا چیزی از برنامه و نقشه نیاز به تغییر داره یا خیر.
4- رترواسپکتیو
در پایان هر دوره اسپرینت برگزار میشود و اعضای تیم اسکرام باید حضور داشته باشند. هدف این میتینگ شناسایی نقاط قوت و ضعف پروژه و اعمال تغییراتی برای ایجاد اثربخشی بیشتر است. کلید خروجی این میتینگ مجموعه ای از تغییرات و پیشرفت های قابل اجرا در پروسس های تیم، همکاری و روش های انجام کار است.
بک‌لاگ – یوزر استوری – ریلیز بک‌لاگ :
بک‌لاگ مکانی است که تسک ها اولویت بندی میشوند و مدیریت این بخش با پروداکت اونر هست. در این بک‌لاگ یوزر استوری ها قرار دارند که از زبان کاربر هستند و از یک الگوی خاص پیروی میکنند : به عنوان (نقش)، من (هدف) میخواهم که (یک مشکل یا خواسته ای رفع) بشود. این یوزر استوری ها بعدا در یک جایی قرار میگیرند به اسم ریلیز بک لاگ و تعیین میکند چه فیچر هایی در چه ورژنی از برنامه قرار هست اضافه بشه، پس اولویت بندی تسک ها در این قسمت از اهمیت ویژه ای برخوردار هست. سپس در برنامه ریزی اسپرینت تعیین میکنید کدوم از تسک ها با توجه به اولویت ها باید انجام بشود.
استوری پوینت :
یسری واحد برای مشخص کردن بزرگی و سختی یوزر استوری ها هست که تیم دولوپمنت راجع به اون تصمیم میگیرد. برای هر دوره اسپرینت تیم دولوپ میداند که چقدر توانایی انجام کار دارد( با استفاده از ابزار هایی مانند نمودار burndown) و با توجه به ان، یوزر استوری های ریلیز بک‌لاگ در هر دوره اسپرینت تعریف میشوند. برای استوری پوینت ها معمولا از اعداد فیبوناچی استفاده میشود(1،2،3،5،8،13،21...).
نمودار burndown : یک بازنمایی بصری از پیشرفت تیم در یک دوره اسپرینت هست. نمایانگر کار باقی مانده در مقابل زمان هست. این نمودار به تیم و ذی‌نفعان کمک میکند تا متوجه بشوند تیم چقدر از برنامه، انحراف داشته است و تصمیمات اگاهانه ای با توجه به ان بگیرند.
#project_managment_system #scrum
@code_crafters
پروداکت اونر یا صاحب محصول :
پروداکت اونر میانجی بین ذی‌نفع یا کسی که طالب یک چیزی هست و تیم توسعه محصول یا نرم افزار قرار میگیره و ایده هارو تبدیل میکنه به زبانی که گروه توسعه محصول بتونه درک کنه و تولید کنه.
پس پروداکت اونر باید یسری جلسات با هر دو گروه برگزار کند (ذی‌نفع – مدیران- بازار – مارکت) و (تیم توسعه) و به یسری نتایج میرسد طبق خواسته های ذی‌نفعان یا مشتری و تصمیم میگیرد که چه فیچر هایی نیاز به اضافه شدن دارد و باید این فیچر ها اولویت بندی بشوند.
یوزر استوری ها توسط پروداکت منیجر به تیم توسعه انتقال داده میشود و یکی از ویژگی های استوری ها، بیان کردن پرسونای (persona) اون هدف هست. پرسونا مجموعه ای از کابران هستند که نیاز و هدف مشترکی دارند. پرسونا به ما کمک میکند که متوجه شویم فیچر مورد نظر قرار است برای چه گروهی اماده شود و تصمیمات بهتری در این زمینه توسط تیم توسعه گرفته شود. داشتن پرسونا به ما کمک میکند تا سلایق مخاطب را بهتر بشناسیم و از این توی دیزاین و ... استفاده کنیم همچنین به پروداکت اونر کمک میکنه تا بتونه استوری هارو بهتر اولویت بندی بکنه. پرسونا به تیم کمک میکند تا همگی درک مشترک و کاملی از کاربر نهایی داشته باشد و با او همزاد پنداری کند.
حال برای رسیدن به پرسونای خاص، باید با کاربران مختلف مصاحبه کنید و مشترکات این کاربران مختلف، پرسونای مد نظر مارو خواهند ساخت. برای هر محصول یک الی دو پرسونا کافی است. برای مشخص کردن پرسونا، مصاحبه با 5 نفر کفایت میکند. پرسش هایی که باید در طی این مصاحبه از کاربر پرسیده شود، نباید پرسش های هدایت شونده باشد و نباید حرف تو دهن کاربر گذاشت. به عنوان مثال از چه وسیله ای برای رفتن به سر کار استفاده میکنید؟ - تایم خوابشون به چه شکل هست؟ - برند های مورد استفادشون چیا هست؟ و ...
از این قبیل سوالات که از کاربرهای مختلف بپرسیم یک سری مشترکات بدست می‌اید و میتوانیم متوجه بشویم که چیزهای موردعلاقه کاربر چیست یا به چه چیزهایی اهمیت میدهد. مثلا با دانستن ساعات کاری انها و ساعات استراحت میدونید که چه زمانی مناسب ارسال نوتیفیکیشن هست یا بقیه موارد.
نحوه اولویت بندی بک‌لاگ با استفاده از ماتریس 4 ربع :
دو محور X,Y از کم به زیاد برچسب میزنید.
محور X تلاش هست. مقدار سعی و تلاشی که مهندسان شما نیاز دارند تا اون فیچر رو انجام بدهند، چقدر سخت قرار هست باشه.
محور Y ارزش هست. چه مقدار ارزش اراعه میده به مشتری شما. ایا قرار هست مشتری شمارو خیلی خوشحال بکنه؟ قرار نحوه استفاده اونها از پروداکت شمارو تغییر بده؟ .
حالا فیچر هارو اولویت بندی میکنید با توجه به ماتریس و درون یکی از 4 خانه قرار میدید. حالا ممکنه یک فیچر خیلی با ارزش داشته باشید و در عین حال تلاش کمی رو میطلبه مثلا ممکنه در طول یک دوره اسپرینت تمام بشه[F1]. حالا ممکنه یک فیچری باشه که مشتری ها خیلی کم درخواست میکنند و زمان و انرژی زیادی بخواد[F2]. یک فیچر دیگه ارزش بسیار زیادی داره و میتونه کسب و کار شمارو زیر و رو بکنه[F3] و همینطور ادامه میدید.
بعد ازینکه ماتریس رو پر کردید ،اونهایی که ارزش پایینی دارند و تلاش بسیار زیادی میخواهند رو از لیست به طور کامل حذف میکنید[F2] مگر اینکه انجام ندادن ان تاثیر منفی روی پروداکت بگذارد .
فیچر های [F4] خوبه که باشند ولی یک تله ای در این قسمت وجود داره و به این صورت هست که اگر سعی کنید تمام کارهایی که تو این قسمت قرار گرفته اند رو انجام بدید زمان زیادی میبره ازتون و در قبالش میبینید ارزش خیلی چشمگیر و قابل توجهی نداشته و در اخر ماه سوپرایز میشیم که تاثیر انچنانی نگذاشته، پس مراقب ان باشید.
فیچر های قسمت [F3] درسته ارزش زیادی ایجاد میکنند ولی انجام دادن انها سخت است باید اگاه باشید که سود بردن ازین قسمت زمان زیادی رو نیاز داره.
فیچر های قسمت [F1]، خب انجام دادنشون کاملا خوب و درسته و این ها از اولویت بالایی برخوردارند. این بخش به قدری مهم هست که شما هنگامی که این بخش رو تشخیص بدید، انگاه ماموریت خود را به عنوان یک پروداکت اونر حرفه ای انجام داده اید، چون یکی از وظایف شما به حداکثر رساندن ارزش با کمترین هزینه است.
#po #product_owner #project_managment_system
@code_crafters
پروداکت اونر میانجی بین ذی‌نفع یا کسی که طالب یک چیزی هست و تیم توسعه محصول یا نرم افزار قرار میگیره و ایده هارو تبدیل میکنه به زبانی که گروه توسعه محصول بتونه درک کنه و تولید کنه.
پس پروداکت اونر باید یسری جلسات با هر دو گروه برگزار کند (ذی‌نفع – مدیران- بازار – مارکت) و (تیم توسعه) و به یسری نتایج میرسد طبق خواسته های ذی‌نفعان یا مشتری و تصمیم میگیرد که چه فیچر هایی نیاز به اضافه شدن دارد و باید این فیچر ها اولویت بندی بشوند.
یوزر استوری ها توسط پروداکت منیجر به تیم توسعه انتقال داده میشود و یکی از ویژگی های استوری ها، بیان کردن پرسونای (persona) اون هدف هست. پرسونا مجموعه ای از کابران هستند که نیاز و هدف مشترکی دارند. پرسونا به ما کمک میکند که متوجه شویم فیچر مورد نظر قرار است برای چه گروهی اماده شود و تصمیمات بهتری در این زمینه توسط تیم توسعه گرفته شود. داشتن پرسونا به ما کمک میکند تا سلایق مخاطب را بهتر بشناسیم و از این توی دیزاین و ... استفاده کنیم همچنین به پروداکت اونر کمک میکنه تا بتونه استوری هارو بهتر اولویت بندی بکنه. پرسونا به تیم کمک میکند تا همگی درک مشترک و کاملی از کاربر نهایی داشته باشد و با او همزاد پنداری کند.
حال برای رسیدن به پرسونای خاص، باید با کاربران مختلف مصاحبه کنید و مشترکات این کاربران مختلف، پرسونای مد نظر مارو خواهند ساخت. برای هر محصول یک الی دو پرسونا کافی است. برای مشخص کردن پرسونا، مصاحبه با 5 نفر کفایت میکند. پرسش هایی که باید در طی این مصاحبه از کاربر پرسیده شود، نباید پرسش های هدایت شونده باشد و نباید حرف تو دهن کاربر گذاشت. به عنوان مثال از چه وسیله ای برای رفتن به سر کار استفاده میکنید؟ - تایم خوابشون به چه شکل هست؟ - برند های مورد استفادشون چیا هست؟ و ...
از این قبیل سوالات که از کاربرهای مختلف بپرسیم یک سری مشترکات بدست می‌اید و میتوانیم متوجه بشویم که چیزهای موردعلاقه کاربر چیست یا به چه چیزهایی اهمیت میدهد. مثلا با دانستن ساعات کاری انها و ساعات استراحت میدونید که چه زمانی مناسب ارسال نوتیفیکیشن هست یا بقیه موارد.
نحوه اولویت بندی بک‌لاگ با استفاده از ماتریس 4 ربع :
دو محور X,Y از کم به زیاد برچسب میزنید.
محور X تلاش هست. مقدار سعی و تلاشی که مهندسان شما نیاز دارند تا اون فیچر رو انجام بدهند، چقدر سخت قرار هست باشه.
محور Y ارزش هست. چه مقدار ارزش اراعه میده به مشتری شما. ایا قرار هست مشتری شمارو خیلی خوشحال بکنه؟ قرار نحوه استفاده اونها از پروداکت شمارو تغییر بده؟ .
حالا فیچر هارو اولویت بندی میکنید با توجه به ماتریس و درون یکی از 4 خانه قرار میدید. حالا ممکنه یک فیچر خیلی با ارزش داشته باشید و در عین حال تلاش کمی رو میطلبه مثلا ممکنه در طول یک دوره اسپرینت تمام بشه[F1]. حالا ممکنه یک فیچری باشه که مشتری ها خیلی کم درخواست میکنند و زمان و انرژی زیادی بخواد[F2]. یک فیچر دیگه ارزش بسیار زیادی داره و میتونه کسب و کار شمارو زیر و رو بکنه[F3] و همینطور ادامه میدید.
بعد ازینکه ماتریس رو پر کردید ،اونهایی که ارزش پایینی دارند و تلاش بسیار زیادی میخواهند رو از لیست به طور کامل حذف میکنید[F2] مگر اینکه انجام ندادن ان تاثیر منفی روی پروداکت بگذارد .
فیچر های [F4] خوبه که باشند ولی یک تله ای در این قسمت وجود داره و به این صورت هست که اگر سعی کنید تمام کارهایی که تو این قسمت قرار گرفته اند رو انجام بدید زمان زیادی میبره ازتون و در قبالش میبینید ارزش خیلی چشمگیر و قابل توجهی نداشته و در اخر ماه سوپرایز میشیم که تاثیر انچنانی نگذاشته، پس مراقب ان باشید.
فیچر های قسمت [F3] درسته ارزش زیادی ایجاد میکنند ولی انجام دادن انها سخت است باید اگاه باشید که سود بردن ازین قسمت زمان زیادی رو نیاز داره.
فیچر های قسمت [F1]، خب انجام دادنشون کاملا خوب و درسته و این ها از اولویت بالایی برخوردارند. این بخش به قدری مهم هست که شما هنگامی که این بخش رو تشخیص بدید، انگاه ماموریت خود را به عنوان یک پروداکت اونر حرفه ای انجام داده اید، چون یکی از وظایف شما به حداکثر رساندن ارزش با کمترین هزینه است.
#po #product_owner #project_managment_system
@code_crafters
Telegram
Narcot
👍1
phind.com
یه موتور جستجو برای برنامه نویس ها است ... تلفیق جالبی از ریزالت گوگل و GPT که تمام چند صفحه اول رو میخونه و نتیحه رو برامون مینوسیه، کدش رو هم مینویسه،
https://zzzcode.ai/
این هم یه ابزار شدیدا باحاله که هم میتونه داکیومنت براتون درست کنه هم میتونه کد های هر زبانی رو به زبان دیگه تبدیل کنه و هم ....
گفتم شاید بد نباشه شیر کنم که شما هم استفاده کنید
@code_crafters
یه موتور جستجو برای برنامه نویس ها است ... تلفیق جالبی از ریزالت گوگل و GPT که تمام چند صفحه اول رو میخونه و نتیحه رو برامون مینوسیه، کدش رو هم مینویسه،
https://zzzcode.ai/
این هم یه ابزار شدیدا باحاله که هم میتونه داکیومنت براتون درست کنه هم میتونه کد های هر زبانی رو به زبان دیگه تبدیل کنه و هم ....
گفتم شاید بد نباشه شیر کنم که شما هم استفاده کنید
@code_crafters
🔥4
CodeCrafters
افزایش کارایی دیتابیس در پردازش کوئری های ما بسیار حائز اهمیت هست در لینک زیر مواردی ازش رو‌میتونید بخونید @code_crafters https://artarad.ir/%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1%D9%87%D8%A7-%D9%88-%D8%AA%DA%A9%D9%86%DB%8C%DA%A9%D9%87%D8%A7%DB%8C-performance…
در خصوص tune کردن دیتابیس این لینک رو بخونید
CodeCrafters
در خصوص tune کردن دیتابیس این لینک رو بخونید
برخی از مقالاتی که طی این میتینگ‌با دوستان مرور و بحث شد:
ایندکس و کلاسترد ایندکس ها
https://www.spotlightcloud.io/blog/when-to-use-clustered-or-non-clustered-indexes-in-sql-server
ابزار Load & RPS Test کامند لاین ساده اما کاربردی ای که برای تست فشار و ریکوئست استفاده کردیم:
https://github.com/codesenberg/bombardier
مطالب مربوط به Tuning و برخی راهکار های
SQL/MySQL Tuning:
https://www.turing.com/kb/best-practices-for-mysql-performance-tuning
https://www.devart.com/dbforge/mysql/studio/mysql-performance-tips.html
https://phoenixnap.com/kb/improve-mysql-performance-tuning-optimization
https://tecadmin.net/mysql-performance-tuning-tips/
برخی بهینه سازی های سمت سرور و تعدادی از فیچر های CDN ها مثل کلادفلیر:
- HTTP2 & HTTP3
https://www.section.io/engineering-education/http3-vs-http2/
- TLS 1.3 & HTTPS:
https://www.cloudflare.com/learning/ssl/why-use-tls-1.3/
- RTT:
https://developers.cloudflare.com/speed/optimization/protocol/0-rtt-connection-resumption/
- Compression:
https://blog.cloudflare.com/this-is-brotli-from-origin/
@code_crafters
#meeting
ایندکس و کلاسترد ایندکس ها
https://www.spotlightcloud.io/blog/when-to-use-clustered-or-non-clustered-indexes-in-sql-server
ابزار Load & RPS Test کامند لاین ساده اما کاربردی ای که برای تست فشار و ریکوئست استفاده کردیم:
https://github.com/codesenberg/bombardier
مطالب مربوط به Tuning و برخی راهکار های
SQL/MySQL Tuning:
https://www.turing.com/kb/best-practices-for-mysql-performance-tuning
https://www.devart.com/dbforge/mysql/studio/mysql-performance-tips.html
https://phoenixnap.com/kb/improve-mysql-performance-tuning-optimization
https://tecadmin.net/mysql-performance-tuning-tips/
برخی بهینه سازی های سمت سرور و تعدادی از فیچر های CDN ها مثل کلادفلیر:
- HTTP2 & HTTP3
https://www.section.io/engineering-education/http3-vs-http2/
- TLS 1.3 & HTTPS:
https://www.cloudflare.com/learning/ssl/why-use-tls-1.3/
- RTT:
https://developers.cloudflare.com/speed/optimization/protocol/0-rtt-connection-resumption/
- Compression:
https://blog.cloudflare.com/this-is-brotli-from-origin/
@code_crafters
#meeting
www.spotlightcloud.io
When to Use Clustered or Non-Clustered Indexes in SQL Server
What clustered and non-clustered index are, how they are created, and what the main differences between the two are. When to use clustered or non-clustered indexes in SQL Server.
❤3👍1