https://virgool.io/feed/@imehrzadm از موسسین و رییس هیئت مدیره شرکت نرم‌افزاری طراحی بدون مرز. Full-Stack developer , Server-Master fa 2026-06-07 15:33:12 https://files.virgool.io/upload/users/1192/avatar/avatar.png?height=120&width=120 https://virgool.io/@imehrzadm https://virgool.io/@imehrzadm/%DA%86%D9%86%D8%AF-%D9%86%DA%A9%D8%AA%D9%87-%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87-%D9%85%D8%AA%D8%AF%D9%88%D9%84%D9%88%DA%98%DB%8C-%DA%86%D8%A7%D8%A8%DA%A9-scrum-ovjcay4rzx4c تیم‌های توسعه نرم‌افزاری که مدت طولانی از متدولوژی Agile (چابک) علی‌الخصوص Framework (چارچوب) Scrum استفاده می‌کنن نکات زیر رو کامل می‌دونن و با پوست و گوشت و استخونشون درکش کردن اما تیم‌هایی که تازه تصمیم گرفتن از این متدولوژی استفاده کنن بهشون پیشنهاد می‌کنم که به این نکات دقت کنن.Scrum Tips- اول Story‌هاتون رو بنویسید، یک راست نرید سر نوشتن و انجام دادن Taskهاوقت بگذارید و Stroyهارو با دقت بنویسید، ممکنه تو همین نوشتن Storyها خیلی مشکلاتی که در آینده قراره باشون دست و پنجه نرم کنید، حل بشن.چارچوب نوشتن User Story- حتما هرجور شده صبحِ هر روز کاری، ۱۵ دقیقه وقت بذارید با بچه‌های تیم صحبت کنید (stand-up meeting)حتما باید صبح باشه؟ از نظر من آره، هم خوابتون می‌پره، هم با همکارا درباره مشکلات و موفقیت‌های روز گذشتتون می‌گید و پر انرژی می‌رید برای شروع یه روز کاری پر چالش جدید.اعضای تیم همکاری نمی‌کنن؟ یه راه حل خیلی خوب دارم براش، به همه اعضای تیم بگید براتون بنویسن که دوست دارن روزشون رو با خوردن یا نوشیدن چی شروع کنن، شما هم به عنوان مسئول تیم براشون فراهم کنید.یک نکته خیلی مهم در مورد stand-up meeting، مطمئنم می‌دونید ولی دلم می‌خواد باز هم بتون تذکرش بدم؛ حتما این جلسه رو بصورت ایستاده و طی حداکثر ۱۵ دقیقه انجام بدید، چون بیشتر شدنش ممکنه باعث خسته شدن بعضی از همکاران و شروع بحث‌های بی‌اهمیت بشه.scrum stand-up meeting- پوینت‌هایی که به Storyهاتون (story point) می‌دید رو یک پله بیشتر بگیریدبذارید یکم راحت‌تر توضیح بدم که کامل درک کنید حرفم‌رو؛ بیاید فرض کنیم story pointهامون قراربه ۲، ۴، ۸، ۱۶ و ۲۴ باشه، اگر فکر می‌کنید story به اندازه ۸ پوینت ازتون زمان می‌گیره، حتما ۱۶ رو بهش بدید، چرا ؟اینم چند دلیل خوبوقت برای تست نتیجه و دیباگ توسط خودتون قبل از اینکه به مرحله تست بفرستیدشاستوری‌ای که از نظر شما ۸ پوینت نیاز داره حتما، به ۸ پوینت دیگه هم نیاز پیدا می‌کنه که به بهترین شکل بهینه بشهکسی به افرادی که پوینت‌های کم میدن جایزه نمی‌ده (بعضی‌ها فکر می‌کنن هرچی پوینت کمتر بدن یعنی حرفه‌ای‌ترن)- اگر تیم توسعه‌ای هستید که قراره Scrum Master از بین خودتون باشه، سعی کنید هر دو اسپرینت، این وظیفه رو به شخص دیگه‌ای بسپارید؛ تا همه بتونن مدیریت تیم توسعه چابک رو تجربه کنن و توی کارشون حرفه‌ای تر بشن.- تست قبل از تحویل به تیم تستهمه‌مون می‌دونیم حس بدیه که کاری رو که انجام دادیم رو تحویل تیم تست بدیم و تیم تست برش‌گردونه و Done نکنه، خب عزیز من برادر من خواهر من لطفا اون کاری که انجام دادی رو بگو یه نفر دیگه از تیم توسعه دهنده‌ها تست کنه (غرور اصلا چیز خوبی نیست.حتی تست کارهای خیلی کوچیک، روحیه تیم توسعه رو خیلی بهتر می‌کنه، خودتونم انرژی‌تون برای انجام کارهای بیشتر، زیاد میشه)اینم چندتا نکته از تجربه‌های من در ارتباط با چارچوب توسعه چابک Scrum :-)Kanbanش هم بزودی می‌ذارم P-:خیلی خوشحال می‌شم نکات شما هم بشنوم؛ همیشه موفق و پیروز باشید.منبع تصاویر: TOTANGO, PEXELS مهرزاد موسوی‌پور مهرزاد موسوی‌پور Tue, 10 Sep 2019 11:40:16 +0430 https://virgool.io/Rocket/%D9%85%D9%82%D8%A7%DB%8C%D8%B3%D9%87-%D9%81%D8%B1%D8%A2%DB%8C%D9%86%D8%AF-%D9%85%D8%AF%D9%84-scrum-%D8%A8%D8%A7-kanban-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85---%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-kanban-bm2ix67rthje توی نوشته‌ قبلی کمی در مورد Scrum توضیح دادیم و چند خصوصیت اصلی Scrum که به مدل Kanban می‌تونن مرتبط باشن رو بررسی کردیم، خب تا الان همش در مورد Scrum صحبت کردیم، حالا بریم سراغ دوست جدیدمون، یعنی مدل توسعه پروژه Kanban.مقایسه مدل Scrum و Kanban (بخش دوم - بررسی Kanban)توی مدل توسعه پروژه Kanban مثل مدل Scrum، سه بخش زیر رو داریم:Backlog (دقیقا مثل مدل اسکرام)Agile Board (Kanban Board)Done Pileبخش‌های اصلی مدل توسعه پروژه Kanbanدرون این مدل دیگه خبری از Sprintها نیست، کارت‌های مورد نظرمون رو طبق الویت و روند وارد Board می‌کنیم و پس از گذشت روند توسعه، کارت‌ها بین ستون‌های مختلف Board جابجا می‌شن تا فرآیند تولید و تستشون تمام بشه و به ستون Release برسن و همچنین تاریخ مشخصی برای انتشار وجود نداریم.تاریخ انتشار نداریم ؟ پس کی باید نسخه‌های جدید ارائه بدیم ؟؟توی مدل توسعه پروژه Kanban معیار انتشار نسخه جدید، وجود داشتنِ قابلیتی (Feature) جهت ارائست. به همین دلیل در هفته ممکنه یک تا دو بار انتشار نسخه جدید داشته باشیم که این مسئله باعث میشه دو سه برابر مدل Scrum نسخه جدید ارائه بدیم.روند کلی مدلبیایم یه جمع بندی بکنیم.بخش‌های اصلی Kanban به ترتیب روند عملکرد، بصورت زیر هستن:BacklogKanban BoardDone PileKanban Meeting (Daily)Package + Release (بیشتر از مدل اسکرام)پس روند مدل Kanban سه بخش کمتر از روند مدل Scrum داره; Sprint planning، Sprint و Retrospective (جلسه جهت اسپرینت‌های آینده). توی این نوشته یک نگاه کلی به چارچوب مدیریت پروژه Kanban داشتیم ( به جزییات کاری نداریم چون خیلی جزییات Kanban مثل Scrum هست و فقط قسمت‌هایی رو مورد بررسی قرار می‌دیم که درون این دو چارچوب متفاوت هستن ). توی نوشته بعدی میریم نقاط ضعف هر کدوم از این دو مدل رو بررسی کنیم.موفق و پیروز باشید :-) مهرزاد موسوی‌پور مهرزاد موسوی‌پور Thu, 19 Oct 2017 02:22:15 +0330 https://virgool.io/Rocket/%D9%85%D9%82%D8%A7%DB%8C%D8%B3%D9%87-%D9%81%D8%B1%D8%A2%DB%8C%D9%86%D8%AF-%D9%85%D8%AF%D9%84-scrum-%D8%A8%D8%A7-kanban-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84---%D8%AA%D8%B9%D8%B1%DB%8C%D9%81-scrum-i6onfmejbvrd با اطمینان میشه گفت امروزه درصد بالایی از پروژه‌های نرم‌افزاری موفق از متدولوژی‌های مدیریت و توسعه پروژه Agile (چابک) استفاده می‌کنن. Framework (چارچوب) های مختلفی جهت این متدولوژی تعریف و توسعه پیدا کرده که از بین اونها میشه به Scrum و Xp اشاره کنیم که از مابقی framework ها محبوب‌تر هستن.چارچوب‌های مدیریت پروژه Scrum و Kanban در مقابل یکدیگربیایم XP رو بذاریم کنار و تمرکزمون رو بذاریم روی محبوب‌ترین framework مدیریت پروژه یعنی Scrum، خب پس Kanban کجا رفت ؟! در اصل میشه گفت Kanban یک نسخه ویرایش شده از Scrum هستش.خب بیایم در مورد تفاوت این دو چارچوب مدیریت پروژه صحبت بکنیم. اگر بخوایم توی جمله خیلی ساده تفاوت این دو رو توضیح بدیم، می‌تونیم بگیم :توی Scrum در مورد کار حرف می‌زنیم اما در Kanban کار می‌کنیم.خیلی ناشیانه بنظر می‌رسه آره ؟ خب بذارید براتون کم کم توضیح بدم تا خودتون هم به جمله بالا برسید. توی این نوشته و نوشته‌های بعدی خصوصیات هر دو چارچوب رو باهم مقایسه می‌کنیم و نقاط ضعف و قدرت هر کدوم رو بررسی می‌کنیم.فرض کنید پروژه‌ای داریم که قراره با چارچوب Scrum پیش ببریم و طبق تجربمون بهتره که هر Sprint رو طی دو هفته انجام بدیم.Sprint plan - طی دو هفتهنیازمندی‌های مشتری رو استخراج می‌کنیم، تبدیل می‌کنیم به Story card و توی Backlog قرار می‌دیم، حالا که کارت هامونو ساختیم و Backlog آماده شده، بریم که شروع کنیم پروژه رو پیش ببریم.board و spring planطبق روند اصولی چارچوب Scrum، کارت‌ها به ترتیب اهمیت و الویت وارد Board میشن و پس از اتمام برنامه‌نویسی و تست وارد ستون Release میشن تا به یک محصول قابل انتشار برسن (Shippable Product).تیم برنامه‌نویسی و مدیریت پروژه هر روز صبح قبل از شروع کار یک جلسه ۱۵ دقیقه‌ای تشکیل می‌دن و در مورد روند پیشرفت پروژه، کارهایی که می‌خوان اون‌روز انجام بدن، کارهایی که روز قبل انجام دادن، مشکلاشون، چالش‌هاشون و این جور موارد با هم بصورت ایستاده حرف میزنن که به این جلسه اصطلاحا می‌گن Stand up meeting. خب حالا چرا ایستاده ؟ برای اینکه نباید این جلسه زیاد طول بکشه، یک جلسه مختصر و مفید.پایان هفته دوم مربوط به Sprintپس از پایان هفته دوم ممکنه یک سری فرآیند مونده باشه که هنوز برنامه‌نویسی‌شون تمام نشده و توی ستون‌هایی غیر از ستون Release مونده باشن، این کارت‌ها می‌مونن برای Sprint بعدی.خب الان دیگه تیم یک Sprint رو به پایان رسونده و یک محصول قابل انتشار داره، پس از پایان هر Sprint اعضا تیم یک جلسه میگیرن و در مورد Sprint گذشته صحبت می‌کنن تا با آینده نگری و تجربیات جدیدشون روند Sprint بعدی رو بهبود ببخشن.نگاه کلی به روند تا به اینجا توی چارچوب Scrum به ترتیب روند عملکرد، قسمت‌های زیر رو داشتیم:BacklogSprint PlanningSprintScrum Meeting (Daily)Done PilePackage ReleaseRetrospective (جلسه جهت اسپرینت‌های آینده)توی این نوشته یک نگاه کلی به چارچوب مدیریت پروژه Scrum داشتیم ( به جزییات کاری نداریم چون خیلی جزییات Kanban مثل Scrum هست و فقط قسمت‌هایی رو مورد بررسی قرار می‌دیم که درون این دو چارچوب متفاوت هستن ).توی نوشته بعدی میریم سراغ بررسی Kanban.موفق و پیروز باشید :-) مهرزاد موسوی‌پور مهرزاد موسوی‌پور Mon, 16 Oct 2017 16:53:22 +0330