جستجو برای:
سبد خرید 0
  • مسترکلاس WPD
  • دوره های آموزشی
    • اسکرام مستر
    • مالک محصول
    • دولوپر
    • مدیران
    • مشترک برای همه نقش ها
    • سازمانی و تیمی
  • آکادمی
  • باشگاه پیشرفت
  • مدرسان
  • تماس با ما
  • سبد خرید

ورود

رمز عبور را فراموش کرده اید؟

هنوز عضو نشده اید؟ عضویت در سایت
  • پشتیبانی: 09386596030
  • info@scrumschool.ir
  • تدریس در مدرسه اسکرام
  • لیست علاقه‌مندی‌ها
مدرسه اسکرام
  • مسترکلاس WPDداغ
  • دوره های آموزشی
    • اسکرام مستر
    • مالک محصول
    • دولوپر
    • مدیران
    • مشترک برای همه نقش ها
    • سازمانی و تیمی
  • آکادمی
  • باشگاه پیشرفت
  • مدرسان
  • تماس با ما
  • سبد خرید
ورود / عضویت

وبلاگ

مدرسه اسکراممقالاتبدون دسته بندیآیا در جلسه برنامه ریزی اسپرینت، بدهی فنی ایجاد می کنید؟

آیا در جلسه برنامه ریزی اسپرینت، بدهی فنی ایجاد می کنید؟

7 مرداد 1399
ارسال شده توسط کسری طوفانی
بدون دسته بندی
آیا در جلسه برنامه ریزی اسپرینت، بدهی فنی ایجاد می کنید؟

بدهی فنی

 

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

تیم توسعه به معنای تیمی متشکل از دولوپرها و یا توسعه دهنده هاست که خودکفا و خود سازمانده (cross-functional and self-organizing) می باشد. اما توسعه دهنده کیست؟ آیا هر کسی را که به توسعه نرم افزار کمک می کند نمی تواند شامل شود؟ برنامه نویس ، آنالیزور، dba، طراح UI، نویسنده محتوا و تحلیلگر کسب و کار؟ حالا به تیم خود نگاه کنید. آیا خودکفا است؟ بله، به دلیل این که شما تکنسین هایی برای همه مهارت ها دارید، اما آیا این تکنسین ها توسعه دهنده هستند؟ شاید نه. آنها فقط برنامه نویس، تستر، dba و طراحان UI هستند و منتظر کارهای مربوط به مهارت خود هستند. آنها به عنوان توسعه دهنده هایی که قصد توسعه نرم افزار را دارند کار نمی کنند، اما بر اساس مهارت های خود وظایف خود را انجام می دهند.

 

موارد کلیدی که به شما در درک ویژگی های تیم توسعه کمک خواهد کرد.

فرض کنید L&D (گروه یادگیری و توسعه) در حال برگزاری چند آموزش مانند موارد زیر است.

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

اطلاعیه دیگر “ما در حال برگزاری کارگاه تست اجایل هستیم، بنابراین تمایل خود را برای شرکت در آن به ما ارسال کنید.” این بار فقط تسترها مشارکت می کنند. همین اتفاق در مورد تجزیه و تحلیل کسب و کار Agile و آموزش UI / UX نیز رخ می دهد.

چه چیزی در بالا منعکس می شود؟ این تیم هنوز بر اساس مهارتهای برنامه نویسی، تجزیه و تحلیل، UI / UX و تست تقسیم شده است. تستر احساس می کند هر چیزی مربوط به تست در حوزه مسئولیت آنهاست و به همین ترتیب کد نویسان فکر می کنند تمام کارهای کدنویسی بخشی از کار آنها است.

“در واقعیت، تست کنندگان برای تست کدهای مرحله تولید کد می نویسند و کدنویس ها برای انجام تست های واحد و یکپارچگی کد (unit and integration tests)، تست می نویسند.”

 

بیایید نگاه دیگری داشته باشیم

در طول جلسه برنامه ریزی اسپرینت، تیم اسپرینت بک لاگ زیر را آماده کرده است.

 

بدهی فنی

 

چه چیزی برداشت می شود؟ وظایفی وجود دارد، اما آن وظایف مبتنی بر مهارت است و مبتنی بر جزء (component)  نیست. آیا این روشی اشتباه برای ایجاد کارهای فرعی نیست؟ اگر موافق نیستید پس شرایط زیر را بخوانید.

فرض کنید الکس (کدنویس) و مارتا (تستر) روی این سه استوری (آیتم های اسپرینت بک لاگ) کار می کنند.

الکس قسمت برنامه نویسی استوری اول را در 2 روز به پایان رساند، و مارتا تست را شروع کرده است، پس الکس بعد از آن چه خواهد کرد؟

به احتمال زیاد الکس کار خود را روی قسمت کدنویسی استوری 2 شروع خواهد کرد. اما آیا این روش درست است؟ چرا الکس نمی تواند کار دیگری را از همان استوری انتخاب کند؟ یا چرا مارتا منتظر بود تا الکس کدنویسی را برای تکمیل تست انجام دهد؟ چرا او نمی تواند با الکس هماهنگ شود تا به صورت موازی تست انجام شده یا حداقل تست API ها را شروع کند؟

بسیاری از مردم از من پرسیدند که اگر الکس کار بر روی قسمت برنامه نویسی استوری 2 را شروع کند چه اشتباهی روی داده است؟ بیایید وضعیت زیر را ببینید.

الکس کدنویسی استوری 1 را به پایان رساند و برنامه نویسی استوری 2 را شروع کرد. مارتا در استوری 1 اشکالی پیدا کرده است. او باید چه کند؟ او پیش الکس رفت و می خواست درباره آن بحث کند، اما الکس بسیار شلوغ است و از او خواست که بعداً بیاید.

 

برای ورود به دنیای اسکرام می توانید از دوره غیرحضوری “آشنایی مقدماتی با اسکرام” شروع کنید

دوره غیرحضوری آشنایی مقدماتی با اسکرام

 

مارتا اکنون چه خواهد کرد؟ به احتمال زیاد، او یک ابزار ردیابی اشکال را باز کرده و اشکال تازه یافته را آنجا وارد می کند. این کار درست است؟ نه ، اما چرا نه؟ من در مورد چالش های ورود به سیستم به طور جداگانه خواهم نوشت، اما در حال حاضر به جنبه های دیگر آن توجه کنید.

الکس کدنویسی استوری 2 را به پایان می رساند و سپس شروع به بررسی اشکالاتی می کند که توسط مارتا ثبت شده است.  او پی می برد که ریشه اصلی پروژه (root) علت بروز برخی مشکلات شده است و برای برطرف کرن آن تغییرات کد فریمورک نیاز است. اما این روی کدی که او تازه برای استوری 2 تکمیل کرده است نیز تأثیر می گذارد؟

الکس چه خواهد کرد؟ اگر او هر آنچه را که برای رفع مشکلات ریشه لازم است تغییر دهد، باعث تولید مجدد و تأخیر در تحویل محصول خواهد شد. گزینه دیگر میانبر برای رفع اشکال است  (patchwork) ، بنابراین نباید روی کد استوری دوم تأثیر بگذارد.

اکثر برنامه نویسان امروزی گزینه 2 را انتخاب می کنند زیرا کدنویس ها نسبت به کد خود بسیار احساساتی هستند (صرفا جنبه شوخی). دلایل مختلفی برای انتخاب گزینه 2 وجود دارد، اما نتیجه آن “بدهی فنی” خواهد بود.

 

چه چیز دیگری وجود دارد؟

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

اولا کارهای فرعی مانند بالا ایجاد نکنید بجای آن سعی کنید استوری را به اجزاء مشخص (component-based) بشکنید. بهترین کار، ایجاد کارهای فرعی و کوچک نگه داشتن استوری ها نیست. با همکاری هم روی یک استوری کار کنید به جای اینکه مدام از یک استوری به استوری دیگر بروید. تیم باید روی اتمام کارها تمرکز کند و نه صرفاً شروع کار جدید.

 

لینک مقاله اصلی:

https://www.scrum.org/resources/blog/are-you-planning-technical-debt-sprint-planning

 

مدرسه اسکرام ، مرجع حرفه ای آموزش اسکرام

برچسب ها: آموزش_اسکراماسکراماسکرام_چیستبدهی_فنیتیم_توسعه
بعدی ده نکته برای مالکان محصول در رابطه با چشم انداز محصول
قبلی افراد در اسکرام یک تیم نامیده می شوند، اما آیا واقعا یک تیم هستند؟

دیدگاهتان را بنویسید لغو پاسخ

برای نوشتن دیدگاه باید وارد بشوید.

جستجو برای:
  • محبوب
  • جدید
  • دیدگاه ها
پشتیبانی

توجه
مدرسه اسکرام هیچ گونه وابستگی به موسسه Scrum.org ندارد و ادعا هم نمی کند که محتواهایی که تولید و ارائه می کند و کلاسهایی که برگزار می نماید، مورد تایید موسسه مذکور است. با اینحال مدرسه اسکرام بطور کامل دنباله رو موسسه Scrum.org است و تمام تلاش خود را بکار میگیرد تا محتواهایی که تولید می کند منطبق بر سطوح کیفیت این موسسه باشد.
در ضمن تمامی کلمات مخفف ، عبارتها و سرنامهایی که در ادامه آمده جزء داراییهای فکری و حقوق معنوی موسسه Scrum.org می باشد و مدرسه اسکرام صرفا از آنها به عنوان مرجع و برای ارجاع استفاده می کند و در مورد مالکیت آنها هیچگونه ادعایی ندارد.

Awareness
We are not affiliated with Scrum.org and do not claim that our contents and classes are endorsed and confirmed by Scrum.org. Furthermore, we are not a representative of Scrum.org.
NOTE: All following words, acronyms, and phrases are trademarks belonging to Scrum.org:
PSM I, PSM II, PSM III, PSPO I, PSPO II, PSPO III, PSD I, SPS, PAL I, PSK I, PSU I, Professional Scrum Master, Professional Scrum Product Owner, Professional Scrum Developer, Scaled Professional Scrum, Professional Agile Leadership, Professional Scrum with Kanban, Professional Scrum with User Experience.

خبرنامه

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

    Scrum School 2025 © | کلیۀ حقوق برای مدرسه اسکرام محفوظ است و استفاده از مطالب در جاهای دیگر صرفا با ذکر منبع و لینک به سایت مدرسه اسکرام بلامانع است.
    اشتراک گذاری در شبکه های اجتماعی
    ارسال به ایمیل
    https://scrumschool.ir/?p=5646
    مرورگر شما از HTML5 پشتیبانی نمی کند.