پروسه تولید نرم افزار

۱http://www.hydramotion.com/images/XL7/process%20viscometer.jpg– برنامه نویس کدهایی رو تولید میکنه که فکر میکنه کدها عاری از هر نوع خطا و باگی است .

۲- محصول تست میشه و ۲۰ تا باگ پیدا میشه .

۳- برنامه نویس ۱۰ تا از اون خطاها رو حل میکنه و برای بخش تست نرم افزار هم توضیح میده که اون ۱۰ تای دیگه واقعا باگ نیستند .

۴- بخش تست در هنگام تست محصول ۵ تا باگ دوباره از اون ۱۰ تایی که حل شده بود پیدا میکنه و علاوه بر اون ۱۵ تا باگ جدید دیگه .

۵- مرحله ۳و۴ سه بار تکرار میشه .

۶-بخش فروش به برنامه نویس ها و تسترها فشار میاره که زودباشید نرم افزار رو Release کنید و این گونه میشه نرم افزار به دست کاربر میرسه .

7-کاربر 137 تا باگ جدید پیدا میکنه .

8-برنامه نویس های اصلی تولید این محصول باهاشون تسویه میشه و همشون از کار برکنار میشند .

9-تیم برنامه نویسی جدید تقریبا تمام اون 137 تا باگ رو رفع میکنند اما باعث به وجود اومدن 456 تا باگ جدید میشند.

10-شرکت مجبور میشه از یه شرکت دیگه برنامه نویس قرض کنه تا این 738 تا باگ رو رفع بکنند .

11-برنامه نویس خبره که از اون یکی شرکت اومده این کدها رو قبول نداره و میگه باید از اول بنویسه .

12-برنامه نویس کدهایی رو تولید میکنه که فکر میکنه کدها عاری از هر نوع خطا و باگی است .

و این جریان ادامه دارد…

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

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

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

اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، انیستیتو ایزایران، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر و صنایع ارتباطی آوا، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

8 دیدگاه

  1. بهروز   •  

    سلام همشهري
    واقعا علي بود، ما در تيم خودمان هميشه اين مشكل را داريم نرم افزار بدون باگ افسانه نانوشته است

  2. GAME4ir   •  

    سیزدهمین و نحس ترین مرحله هم اینه که یک نفر پیدا می شه برنامه را هک می کنه
    😉
    😮

    • sirasad   •  

      راه حل این است که تمام میکند ها را نمی کند بکنید , برای مثال : برنامه نویس کدهایی رو تولید نمی کند که فکر میکنه کدها عاری از هر نوع خطا و باگی است و محصول تست میشه و ۲۰ تا باگ پیدا میشه .

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

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

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

  3. SMAH1   •  

    سلام
    خیلی جالب بود و کلی خندیدم.
    با این حال به نظر من برای حل اینگونه مشکلات باید این مراحل رو رفت (من مستقل کار می کنم و تا حالا تیمی کار نکردم ولی با این حال در برنامه های خودم معمولا اینگونه رفتار می کنم):
    1) مستند سازی،هر چقدر هم که کم باشد.این یعنی تجربه،یعنی آماده ی ایجاد یک نرم افزار بهتر در نوبت های بعدو ..
    2) به قول دوستمون باید از TDD استفاده کرد (هرچند من اسمش رو نمی دونستم ولی سالهاست از روشی شبیه به این استفاده کرده ام).اما باز هم اگر نتوانیم tester خوبی بنویسیم،یعنی باگ ها ممکنه پیدا نشه.این یعنی تجربه لازم داریم و خودش یعنی تجربه.
    3) برخی باگ ها رو واقعا نمیشه حل کرد (یه جوری با اصل برنامه ناسازگارند و فقط یه جوری برنامه رو وصله پینه می کنیم نه اینکه واقعا راه حال سیستماتیک برای عدم ورود به حالت ایجاد باگ در برنامه ایجاد کنیم).این گونه کار ها،مسکن موقتند و باید در بلند مدت یه کاری کرد.من وقتی تعداد اینگونه باگ ها زیاد باشن (توی هر کلاس حداقل یکی داشته باشم یا کلاسی داشته باشم که به اندازه همه کلاسهای دیگه اینگونه باگ داشته باشه)،دوباره اقدام به پیاده سازی برنامه (از اول + هر چی کد کاملا سالم از قبلی مونده و پایه ای است و ناسازگاری توش ندارم + همون تجره شماره 1 + تجربه شماره 2) می کنم.
    4) باید شی گرایی رو خوب بدونیم،خوب بنویسیم و خوب رعایت کنیم (این آخری از دوتای اول مهم ترند).
    در ضمن این فقط نظریات من هستند و حاصل تجربه شخصی!
    موفق باشید

  4. الیاس   •  

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

پاسخ دهید

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