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

مثال کاربردی و واقعی : چند سال قبل در یکی از بانک های بزرگ و دولتی کشور قرار بود نرم افزار مدیریت املاک و مستقلات بانک تولید شود تا بتوان لیست جامعی از املاک برای بانک درست کرد با هدف مدیریت بهینه مستغلات بانک. مثلا شاید  همین بانک در یک گوشه از کشور ملک یا مغازه ای دارد که آن اجاره داده شده است، اما سالها فراموش شده و شاید هم از آن سواستفاده می شود، یا در سالهای اخیر فشار زیادی بر روی بانک ‌ها هست که املاک خود را واگذار کنند، اما کدام ملک باید واگذار شود؟ این باعث شد که نیاز به یک نرم افزار جامع مدیریت املاک حس شود.

بعد از آن یک پروژه ای بنام مدیریت جامع املاک در بانک مورد اشاره تعریف شد و یک تیم نرم افزاری کار را بر روی آن شروع کرد. این تیم بر اساس روش اسکرام کار  خورد را شروع نکرد و  بالعکس سراغ روش آبشاری رفت که در شکل این روش را در زیر  میتوانید مشاهده می کنید. این مدل آبشاری دو فاز اساسی دارد: فاز اول، برنامه ریزی شامل: گرد آوری نیازمندی، تحلیل نیازمندی ها و طراحی، که در این فاز ابتدایی ما وارد اجرا نمی شویم و خروجی این فاز بیشتر مستندات و خوراک فاز بعدی است. در فاز بعدی، ما وارد فاز اجرا و نظارت و نهایتا تحول خواهیم شد.

مدل آبشاری

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

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

 

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

پروژه‌ها یا مسئله‌های طیف مشخص و طیف پیچیده با هم فرق دارند

اکثر پروژه های نرم افزاری در طیف پیچیده دسته بندی می شوند، از این لحاظ که نه سمت مشتری “دقیقا” میدانند چه نیازمندی دارند و معمولا با دیدن خروجی، قطعیت پیدا می‌کنند(آها ما این رو میخواهیم). هم سمت اجرا کننده پروژه، روشهای و ابزارها، طرح ها و … قطعیت ندارند، مثلا شاید از یک دیتابیس برای ذخیره سازی اطلاعات استفاده کنیم که در ادامه به این نتیجه برسیم که انتخاب بهتری هم هست. از طرف دیگر، شرایط بازار و رقابت نیز باعث می شود ما در برنامه اجرایی قطعیت کامل نداشته باشیم.

مدل آبشاری در طیف مسئله های مشخص عالی عمل می‌کند
مدل آبشاری در مسئله های پیچیده کاربردی نیست و موجب ایجاد محصولات بدردنخور و اتلاف منابع خواهد شد

ذات مسئله‌های پیچیده

 ما در پروژه ها یا مسئله های پیچیده به چند چیز یقین داریم:

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

  • ما قطعا میدانیم که روش اجرایی که از اول برنامه ریزی کردیم، چیزهایی پدید خواهد آمد که نمی دانستیم. پس برنامه اجرایی و روش انجام نیز قطعیت ندارد.

  • موارد ۱ و ۲ باعث می شود که مطمئن شویم، که تغییر در مسئله های پیچیده، امری اجتناب ناپذیر بوده و به جای دوری از آن باید راهی پیدا کنیم که پذیرای آن باشیم.

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

به تفکر “پاسخگویی سریع به تغییرات” چابک یا چابکی گفته می شود.

اسکرام روشی برای حل مسئله های پیچیده

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

اسکرام با استفاده از یک روش چرخشی افزایشی باعث کاهش ریسک و افزایش میزان پیش بینی پذیری می شود.

آیا ما “محصول درستی” می سازیم؟
آیا ما محصول را به “شیوه درستی” میسازیم؟

اگر به تازگی با اسکرام آشنا شدید این دوره آنلاین بهترین پیشنهاد برای شما است

بخش دوم – اجزا و نحوه کار اسکرام

 

PO یا Product Owner یا مالک محصول نماینده گروه ذینفعان محصول است. PO  به عنوان یکی از نقش های اصلی در محیط اسکرام به حساب می آید . مسلما هر نقشی باید یک سری وظیفه داشته باشد که وظایف PO عبارت است از :

  • تعیین هدف و چرایی آن برای تیم؟ (او مقصد نهایی را نشان می دهد ولی به این کار نخواهد داشت که چگونه تیم می خواهد به آنجا دست یابد)
  • اولویت بندی نیازمندی ها موجود در بک لاگ محصول(جایی که نیازمندی های محصول نگه داری می شوند)

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

از آنجایی که فقط ۲۰% (قانون بیست-هشتاد)از ویژگی‌های ارائه شده در قالب محصول برای مشتری، مهم و با ارزش هستند چرا نباید این ویژگی ها را قبل از دیگر ویژگی های غیر ضروری ارائه داد. به این عمل در واقع تضمین بازگشت سرمایه می گویند. هر چقدر زودتر نیازهای اصلی مشتری را رفع کنید برگشت سرمایه زودتر انجام خواهد شد.

اما علاوه بر مالک محصول نقشی به نام تیم توسعه وجود دارد که کار او توسعه محصول مورد نظر خواهد بود. این تیم می تواند شامل تمام نقش های توسعه نرم افزار مانند برنامه نویس , تحلیل گر و طراح  DBA و … باشد. تیم در صورت وجود نفرات زیاد می تواند به چندین تیم مجزا نیز تقسیم شود. تعداد ۳-۹ نفر برای هر تیم ترجیح داده می شوند.

 

تیم های اسکرام بر خلاف دیگر تیم ها دو ویژگی اساسی دارند :

  • Self-Organize یا خود سازمانده هستند:  از متد مدیریت Micromanagement   یا مدیریت دستور-کنترل برای این تیم ها استفاده نمی شود و این تیم ها خود-سازمانده است. در واقع به این تیم ها فقط گفته می شود که می خواهیم چه کاری انجام دهیم و چگونگی نحوه انجام به خود تیم سپرده شده است.
  • Cross-Functional کار می کنند : تمامی تخصص های لازم در تیم وجود دارند که بدون وابستگی به بیرون از خودشان بتوانند یک محصول کارکننده را تولید، تست و ارائه کنند.

از جمله وظایف این نقش می توان به موارد زیر اشاره کرد :

  • تعیین مقدار کاری که باید در طی یک اسپرینت (۲-۴ هفته) انجام دهند .
  • چگونه باید کارها را انجام دهند .

اسپرینت در اسکرام همان چرخش‌هایی هست که بالاتر گفته شد. طول این چرخش‌ها معمولا در اسکرام بین ۲-۴ هفته است. در شروع هر اسپرینت مقداری درخواست مشتری (که معمولا به اسم User Story شناخته می شوند) با توجه به ظرفیت تیم (سرعت تیم یا  Velocity) انتخاب می شوند و در لیست بک لاگ اسپرینت قرار می گیرند. این لیست شامل تمام درخواست های مشتری می شود که تیم متعهد شده تا در این اسپرینت پیاده سازی کند.

 

برای اینکه بتوان میزان ظرفیت تیم را سنجید میتوان به هر داستان کاربر یک وزن داده شود . واحد این وزن Story Point است. اما درباره نحوه وزن دادن به هر داستان : ساده ترین درخواست مشتری را انتخاب کنید . به آن   Story Point 3 بدهید.  موارد دیگر باید بر اساس رابطه سختی آن ها با این داستان وزن دهی شوند. مورد بعدی را انتخاب کنید اگر دو برابر سخت تر از این داستان بود به آن ۵ و اگر کمی سخت بود به آن ۳ بدهید.

همانطور که در بالا ذکر شد “در شروع هر اسپرینت مقداری درخواست مشتری (User Story) با توجه به ظرفیت تیم انتخاب می شوند” . ظرفیت تیم همان سرعت تیم خوانده می شود . به عبارت ساده تر تیم در طی اسپرینت ۴ هفته ای چند Story point می تواند انجام بدهد؟ تعیین این میزان برای هر تیم به دو روش امکان دارد :

  • تعیین ظرفیت اسپرینت با توجه به عملکرد تیم در اسپرینت های قبلی
  • تعیین ظرفیت تیم بر اساس توان نیروی کار موجود و میزان توجه آن ها به کار

به طور خلاصه تیم بر اساس ظرفیت و یا سرعت خود و رعایت اولویت های مالک محصول تعدادی User Story  را از داخل بک لاگ محصول انتخاب و به داخل بک لاگ اسپرینت انتقال می دهد. این فعالیت در طی جلسه برنامه ریزی اسپرینت انجام و جلسه در ابتدای هر اسپرینت برگزار می شود.

در گام بعدی تیم شروع به پیاده سازی هر یک از اقلام موجود در بک لاگ اسپرینت خواهد کرد . برای اینکه اعضای تیم اعلام کنند که چه کاری را انجام داده اند و چه کاری را می خواهند انجام دهند جلسه ای با عنوان جلسه روزانه اسکرام و یا جلسه سرپایی روزانه در هر روز معمولا در شروع روز کاری به مدت حداکثر ۱۵ دقیقه برگزار می شود . در این جلسه هر کس ۳ سوال اصلی مطرح و به آن ها جواب می دهد :

  • با توجه به هدف اسپرینت، دیروز چه کاری انجام دادم؟
  • امروز چه کاری می خواهم انجام بدهم
  • چه موانعی در پیش رو دارم و با چه موارد پیش بینی نشده ای برخورد کرده ام؟

طرح این سوالات برای ایجاد شفافیت و وضوح عملکرد تیم می باشد . این عمل باعث ژل شدن بیشتر تیم می‌شود.

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

آخرین جلسه بعد از اتمام هر اسپرینت , جلسه Scrum Retrospective یا بازبینی عملکرد است. این جلسه فرصتی با ارزش برای بهبود عملکرد تیم می باشد. در این جلسه عملکرد اسپرینت بررسی و برای آینده توافقی از نقاط بهبود استرخاج می شود. در این جلسه معمولا سوال هایی مانند زیر مطرح می شود :

  • چه مواردی در اسپرینت قبل خوب بود؟
  • کدامیک از عملکردهای ما نیاز به اصلاح دارد؟
  • چه بهبودهایی را می توان برای آینده در نظر گرفت؟

بهبود های کشف شده در این جلسه ۲ ساعته به مرور در اسپرینت های بعدی اعمال می شوند.

علاوه بر خود تیم نقشی به نام Scrum master در داخل تیم اسکرام وجود دارد . همانطور که از عنوان این نقش قابل ملاحظه  است کار این نقش مدیریت پروسه اسکرام است. اولا او پروسه اسکرام را در سازمان کلید می زند و ثانیا کنترل می کند که آیا تیم و مالک محصول ,اسکرام را درست انجام می دهند؟ علاوه بر این ها وظیفه حذف موانع از سر تیم در راه فرآیند اسکرام نیز بر عهده اسکرام مستر است .برای هر تیم باید یک SM و یک PO مجزا وجود داشته باشد .

برای اطلاع از دوره های آموزشی ما از سطح مبتدی تا پیشرفته میتوانید با پشتیبانی آنلاین ما در ارتباط باشید 

(با کلیک بر روی هر یک از دوره های زیر می توانید توضیحات مربوط به آن ها را مشاهده کنید )

دوره مجازی اسکرام مقدماتی 

دوره مجازی برنامه ریزی و تخمین چابک 

ورکشاپ آنلاین اسکرام کاربردی (اسکرام مستر حرفه ای )

ورکشاپ آنلاین مدیریت محصول چابک 

ورکشاپ آنلاین تحول چابک با مدل اجایل فلوئنسی

 

در ادامه چه بخوانیم؟

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

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

برای راحتی ارتباط با دیگر متخصصین چابکی از راههای ارتباطی زیر میتوانید استفاده کنید:

مقالات کاربردی

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

اطلاعات بیشتر در مورد این کتاب

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

توضیحات بیشتر و دریافت کتابچه

    Comments

  1. صمد کوشان
    سپتامبر 28, 2012

    سلام
    توضیحات بسیار روشن و خلاصه و در عین حال مفید بود، ممنون و خسته نباشید

    پاسخ
  2. نوامبر 7, 2012

    مطلب بسیار مفیدی است؛ فقط عکسهایش لود نمی شوند.

    پاسخ
  3. محمود اسدی
    دسامبر 3, 2012

    سلام
    ممنون از مطلب خوبتون.
    لینکهای داخل مطلب کار نمی کنه.

    پاسخ
    • آواتار کاربر
      admin
      دسامبر 3, 2012

      ممنون
      لینک ها و عکس ها اصلاح شد

      پاسخ
  4. مصطفی
    ژانویه 30, 2013

    سلام ممنون مقاله بسیار خوبی

    پاسخ
  5. شهریار
    آوریل 10, 2013

    salam
    mamnoon az matalebeton
    dost daram bedonam dar morede modiriyate yek mohit shabake ham
    mishe az scrum baraye nahveye estefadeh az nirohaye motekhases estefadeh kard ?

    پاسخ
    • ramin
      فوریه 7, 2019

      Doste Aziz, baraye in Kar shoma kare modiriate Project ra ba Prince2 wa ghesmate operativ ra agile anjam dahid. Baraye agile ham scrum wa ham kanban ghabele estefade hast. Ja hagh

      پاسخ
  6. ساینا
    آوریل 23, 2013

    عالی بود. واقعا ممنون

    پاسخ
  7. آواتار کاربر
    علی
    ژوئن 5, 2013

    فوق العاده عالی و کاربردی بود. ممنون

    پاسخ
  8. سلام
    سپتامبر 3, 2013

    سلام
    مطالب
    کاربردی بود.
    متشکرم

    پاسخ
  9. رسول
    سپتامبر 11, 2013

    مطالب خوبی بود . ممنون

    پاسخ
  10. احمد
    ژوئن 9, 2015

    سلام، مطلب خوبی بود، فقط وفتشو بیشتر کنید لطفا

    پاسخ
  11. مهدی
    سپتامبر 14, 2015

    سلام
    ممنون از مطالب خویتون.

    پاسخ
  12. مجید
    اکتبر 16, 2015

    سلام.
    مطلب بسیار خوبی بود و برای من تازگی داشت. میخواستم بدونم کس از این Framework در جائی استفاده عملی کرده و اگه جواب مثبته دوست دارم بدونم چقدر تونسته با اجرا مطابقت بده؟

    پاسخ
  13. مهدی
    نوامبر 28, 2015

    خیلی عالی بود. یه سوال دارم po نمیتواند مالک چند پروژه باشد که هر پروژه بوسیله چند تیم در حال انجام است؟
    یه سوال دیگه. آیا sm باید برای هر تیم باشد یا کل سیستم اسکرام یک sm میخواهد؟

    پاسخ
    • آواتار کاربر
      Asad Safari
      آوریل 5, 2016

      معمولا ترجیح داده میشه PO برای هر محصول یا پروژه مستقل باشه اما در مورد اسکرام مستر نه، او میتونه همزمان در چند تیم باشه

      پاسخ
  14. محمودی
    دسامبر 31, 2015

    دوستان کامپیوتر ارشدی اهواز ۹۴
    لطفا اسکرام رو برای اینجانب بزارید
    و از موضاعت دیگه ای که استاد داده واسه مروری استاد فطانت استفاده کنید
    ببینید تا کجاها اومدمه…

    پاسخ
  15. الهام
    آوریل 5, 2016

    سلام
    ممنون از مطالبتون
    به نظر شما product owner بهتر است در کدام واحد سازمانی فعالیت داشته باشد؟ در واحد امور مشتریان یا در تیم فنی؟

    پاسخ
    • آواتار کاربر
      Asad Safari
      آوریل 5, 2016

      سلام،
      بستگی به پروژه دارد، ولی در هر صورتی باید با هر دو واحد هم ارتباط داشته باشد

      پاسخ
  16. جولای 15, 2016

    عالی و مفید
    تشکر

    پاسخ
  17. sara
    اکتبر 2, 2016

    سلام . در اجرای روش اسکرام از نرم افزاری هم استفاده می شود یا همین در حد تئوری است؟
    میشه یک مثال از اسکرام هم بزنید

    پاسخ
  18. هدی
    اکتبر 10, 2016

    سپاس، توضیحات بسیار مفید و واضح بود

    پاسخ
  19. سمپای صالح
    نوامبر 4, 2016

    با سلام
    لطفا در صورت امکان یه نمونه پروژه که با اسکرام انجام شده رو بگین. ک به صورت عملی بدونیم یه پروژه رو چطور باید انجام داد

    پاسخ
  20. علیرضا
    فوریه 27, 2017

    بسیار مفید بود ، شرکت ما هم تقریبا طبق همچین روشی داره پروژه ها رو پیش میبره ئلی نمیدونستم همچین ساختار سازمان یافته ای هم وجود داره !
    ممنون از شما

    پاسخ
  21. ارسلان فرید
    آوریل 8, 2017

    درود و سپاس از ارائه محتوای مفید فارسی برای گسترش این نوع نگرش و چارچوب مدیریت پروژه.
    در متن حاضر در توضیح قسمت وزن دهی Story Point به داستان مشتری، اگر اشتباه نکنم نیاز به یک اصلاح مختصر بصورت زیر باشد؛
    “اگر به سختی این داستان بود به آن ۱ بدهید .”
    اصلاح شده:
    “اگر به سختی این داستان نبود به آن ۱ بدهید .”

    با سپاس

    پاسخ
  22. مسعود
    سپتامبر 15, 2017

    سلام
    ضمن سپاس از توضیحاتتون
    ی سوال دارم. اگه تیم اسکرام با ظرفیت کمتر از توانشون کار کنن چه باید کرد؟ من میبینم که بیکار هستن اما در جلسه اسپرینت پلنینگ با هم هماهنگ می کنند و تعدا بسیار کمی استوری بر می دارند. در اینجور مواقع po چه می تواند بکند؟

    پاسخ
  23. سید محمد حسین
    اکتبر 30, 2017

    تشکر عالی بود فقط بعضی کلمات تخصصیش مثل iNTERATIVE ها توضیحات میتونست کامل تر باشه. ممنون

    پاسخ
  24. mostafa borjali
    نوامبر 19, 2017

    سلام
    خلاصه و مفید بود
    تشکر

    پاسخ
  25. alireza
    ژانویه 9, 2018

    خیلی مفید و عالی بود کلی لذت بردیم دمتون گرم

    پاسخ
  26. احمدرضا شمیمی
    می 5, 2018

    من با روش اسکرام یک تیم و کنترل کردم و با تیمی که داشتم و یک دل بودن این اپلیکیشن را برای معرفی به سبیت بردم.
    روش عالی است که در همه حال و در هرشرکتی میتوان از آن استفاده کرد
    با تشکر از مطلب مفیدتون

    پاسخ
  27. آگوست 31, 2018

    واقعا عالی بود
    خلاصه و مفید

    پاسخ
  28. نوامبر 13, 2018

    مطبتون کامل و جامع بود ممنونم. میشه لطفا مطالبی هم در رابطه با اجرایی کردن این پروسه بذارید؟

    پاسخ
  29. ژانویه 27, 2019

    ممنون از مطلبتون.شما دوره های اسکرام هم برگزار می کنید؟

    پاسخ
    • آواتار کاربر
      Asad Safari
      ژانویه 27, 2019

      بله،
      بخش دوره های آموزشی رو چک بفرمائید.

      پاسخ
  30. فوریه 9, 2019

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

    پاسخ
  31. فوریه 17, 2019

    تشکر از مطلب مفیدتون.
    ارادتمند . . .

    پاسخ
  32. فوریه 18, 2019

    ممنون از شما برای مطلب خوبتون

    پاسخ
  33. فوریه 25, 2019

    بسیارهم عالی و مفید. چطور از برگذاری دوره های اسکرام با خبر شیم ؟

    پاسخ
  34. آوریل 18, 2019

    سلام برای شرکت در دوره هاتون پیش نیاز لازم هست؟ یعنی باید از قبل اطلاعات بخصوصی داشته باشیم؟

    پاسخ
  35. حمید
    می 10, 2019

    بنده بشکل غیر آکادمیک برنامه نویسی یاد گرفتم و محصول دارم.پروژه ای مربوط به محل کارم رو به برنامه نویسی سفارش دادیم و ایشون از متد اجایل استفاده میکنند.۸۰ درصد درخواستها رو به علت استاندارد نبودن غیرقابل اجرا عنوان کردند و از آنها ۲۰درصدرو با تغییرات اساسی انجام دادندهمون پروژه رو بنده برای خودم انجام دادم.ایشون قرار بود۳ماهه تحویل بدهند ولی بعد از یکسال هنوز تحویل ندادند ولی پروژه من ۷ ماهه تکمیل شده.برنامه نویسی متد شده بیشتر وقتگیره و اکثر درخواستها رو رد میکنه.

    پاسخ
  36. جولای 28, 2019

    سلام
    آیا میشه این فریم ورک یا متد رو در کارهای دیگر که ماهیت فعالیت تیمی دارند هم انجام داد ؟

    پاسخ
    • آواتار کاربر
      Asad Safari
      آگوست 25, 2019

      سلام
      بله می توان استفاده کرد

      پاسخ
  37. سپتامبر 15, 2019

    سلام وقت شما بخیر باشه. تشکر از محتواتون
    یک سوال داشتم از این فریم وورک فقط برای نرم افزارها استفاده میشه؟ اگر نه میشه مثال غیرمحصولی بزنید. تشکر

    پاسخ
  38. بهزاد
    سپتامبر 18, 2019

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

    پاسخ
    • آواتار کاربر
      niloufar
      دسامبر 28, 2019

      سپاس از توجه شما

      پاسخ
  39. ابراهیم
    سپتامبر 20, 2019

    سلام. ممنون به خاطر مطالب خوبتون. بزرگواری میکنید بفرمایید در این روش تولید محصول نرم افزاری، فاز طراحی پروژه اصلا وجود داره؟اگر وجود داره کجاست و به چه شکلی انجام میشه؟منظورم ایجاد کلاس دیاگرام ها، آبجکت دیاگرام ها، دیاگرام های توالی و امثالهم…
    با این روش مستند سازی و تست به چه شکلی انجام می شوند؟

    پاسخ
  40. مهرناز
    اکتبر 4, 2019

    واقعا عالی بود !

    پاسخ
    • آواتار کاربر
      niloufar
      دسامبر 28, 2019

      سپاس از توجه شما

      پاسخ
  41. حميد
    اکتبر 24, 2019

    این مقاله با توضیحات جامع بسیار عالی بود.

    پاسخ
    • آواتار کاربر
      niloufar
      دسامبر 28, 2019

      سپاس از توجه شما

      پاسخ
  42. محمد
    ژوئن 11, 2023

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

    پاسخ
  43. آگوست 1, 2023

    خوب و عالی .تشکر

    پاسخ
  44. Navid
    اکتبر 23, 2023

    سلام لینک گروه تلگرام انجمن چابک ایران منقضی شده ممکنه مجدد ارسال کنید؟

    پاسخ

Leave A Reply

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *