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

ورود

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

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

وبلاگ

مدرسه اسکراممقالاتبدون دسته بندی5 تمرینی که به توسعه نرم افزار چابک کمک می کند

5 تمرینی که به توسعه نرم افزار چابک کمک می کند

26 بهمن 1399
ارسال شده توسط کسری طوفانی
بدون دسته بندی
5 تمرینی که به توسعه نرم افزار چابک کمک می کند

اغلب ما در تیم های اسکرام سخت کار می کنیم، اما نه لزوما هوشمندانه تر. بنابراین نحوه کار ما باید تغییر کند. پنج نکته برای کار چابک موثرتر.

من به عنوان یک استاد فنی اسکرام و مربی فنی چابک ، زیاد تیم ها را در ماجراجویی هایشان همراهی می کنم. این ماجراجویی شامل تحویل منظم نرم افزارهای ارزشمند برای توسعه موثر محصول است.

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

 

آیا می دانید چه چیزی در چابک بودن موثر است؟

چیزی که من اغلب می توانم مشاهده کنم این است که تیم ها در حالت آبشار کوچک (mini-waterfall) کار می کنند.
یعنی در اسپرینت اسکرام آنها در چهار یا پنج مرحله کار می کنند.

این چیزی شبیه به چنین طرحی است:

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

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

بیایید روی “تست کردن” تمرکز کنیم. این بدان معنی است که تیم ها در مورد “تست کردن” (نقش تست کننده) و “تست کردن” به عنوان مرحله ای از توسعه نرم افزار یا مأموریت و تسک صحبت می کنند.
این رویکرد شبیه این طرح است:

 

آیا شباهت با رویکرد آبشاری را می بینید؟
و آیا مشکلی که معمولاً بعد از آن بروز می کند را متوجه می شوید؟

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

“آه … ما هنوز کار توسعه رو کامل نکردیم.”
“می تونید تست رو متوقف کنید؟”
“نمیشه اسپرینت بعدی بطور کامل فقط تست رو انجام بدین؟ ما هنوز مشغول کاریم!”

این باید زنگ خطر باشد.

این معمولاً همان چیزی است که مجسم می شود:

 

 

این بدین معنی است که زمان تست بسیار کوتاه خواهد بود. به ندرت، بعداً انجام می شود یا در دسته های بزرگ تست می شود (خیلی زیاد به یک باره و دسته جمعی)، و این منجر به سرزنش، شب های طولانی تست، ادغام دیرهنگام، استقرارهای یک ماه در میان و ناامیدی عمومی می شود.

بنابراین چگونه می توانیم آن را برطرف کنیم؟

 

نحوه رسیدن از رویکرد آبشاری به اسپرینت های 1 هفته ای

آنچه تجربه من در موردش خوب کار می کند، موارد زیر است (شاید بتوان گفت پیشرفت در تیم):

1. ما بر روی جریان تک قطعه ای تمرکز می کنیم
این یک تفکر از فلسفه Lean است، جایی که ما یک کار کوچک را به پایان می رسانیم و فقط پس از آن کار بعدی را می گیریم.

2. ما از ابتدا محصول با کیفیت می سازیم
فقط کیفیت بالا به ما اجازه می دهد تا با گذشت زمان سریعتر شویم و ما از این رویکرد برای توسعه بلند مدت استفاده می کنیم.

3. ما تست های زیادی را خودکار انجام می دهیم
… و این می تواند ما را به عنوان انسان در تست های اکتشافی دستی (manual exploratory tests) که جذاب هم هستند متمرکز کند. انسان ها ماشین های خودکار بدی هستند. نرم افزارها و ماشین ها در بررسی موارد خودکار خسته کننده بسیار بهتر عمل می کنند.

4. ما تست محور کار می کنیم
یک تست قرمز این دید را به ما می دهد که باید یک فیچر را اضافه کنیم یا دوباره بسازیم. ما از تست ها به عنوان شاخص استفاده می کنیم: تست ها نشان می دهند که کارهایی برای تکمیل و Done شدن وجود دارد.

5. ما به ساخت بهترین سیستم کمک می کنیم
… از طریق ارتباط اولیه با سوالات و تمرکز بر کیفیت. اکنون تیم وقت بیشتری برای برقراری ارتباط با دنیای خارج و به چالش کشیدن، مدل سازی و اعتبار سنجی ایده ها، فرضیه ها و الزامات دارد. دنیای خارج از “ذینفعان” (stakeholders) تشکیل شده است: کاربران، مدیران و سایر طرف های درگیر.

اگر مطابق آنچه در موارد 1 تا 5 گفته شده است کار می کنید، روند شما معمولاً به این شکل است:

 

چگونه می توان در مورد آن تجدید نظر کرد:
• تست یک فعالیت است. (نه یک فاز جداگانه در انتهای کار)
• تست کردن در تمام طول فرآیند توسعه و مکرراً انجام می شود.

کاری که باید متفاوت انجام دهید:
• تست های خودکار ما چیزی است که فرآیند توسعه را پیش می برد.
• تست های خودکار ما معماری را پیش می برد.
• تمام تست های سبز به معنای آن است که “کار ما تمام شده (Done)” .

 

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

https://www.scrum.org/resources/blog/5-practices-help-agile-software-development

 

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

بعدی فعلاً از آبنباتت لذت ببر!
قبلی سودای خودمدیریتی: آیا در حال اختراع مجدد چرخ نیستیم؟

2 دیدگاه

به گفتگوی ما بپیوندید و دیدگاه خود را با ما در میان بگذارید.

  • علی بخشی گفت:
    6 اردیبهشت 1400 در 12:05 ب.ظ

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

    برای پاسخ دادن وارد شوید
    • کسری طوفانی گفت:
      9 اردیبهشت 1400 در 9:22 ب.ظ

      ممنون از پیشنهادتون جناب بخشی

      برای پاسخ دادن وارد شوید

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

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

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

توجه
مدرسه اسکرام هیچ گونه وابستگی به موسسه 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=7739
    مرورگر شما از HTML5 پشتیبانی نمی کند.