یادگیری دیدن اتلافات اولین گام در توسعه پیشرفت با تفکر ناب است. اگر چیزی به طور مستقیم بر اساس درک مشتری ارزش افزوده نداشته باشد، اتلاف است. در سال 1970 وینستون رویس نوشت که مراحل اساسی توسعه نرم افزار تجزیه و تحلیل و کدگذاری است. “[در حالی که] بسیاری از مراحل توسعه اضافی مورد نیاز است، هیچ یک به طور مستقیم به محصول نهایی به عنوان تجزیه و تحلیل و کدگذاری کمک نمی کند، و همه هزینه های توسعه را افزایش می دهند.” هر مرحله در فرآیند آبشاری به جز تجزیه و تحلیل و کدگذاری ضایعات است.
شیوه های توسعه نرم افزار چابک به دنبال حذف اتلافات هستند. برای این کار ابتدا لازم است این موارد را ببینید و رویس مکان خوبی را برای شروع جستجو پیشنهاد می کند. آیا همه این فرآیندها واقعاً برای مشتریان ارزش افزوده می‌کنند؟
Shigeo Shing، یکی از مغز متفکران سیستم تولید تویوتا، هفت نوع ضایعات تولیدی را شناسایی کرد. فهرست او به بسیاری از مدیران تولیدی کمک کرده است تا اتلافاتی را پیدا کنند که هرگز فکرش را هم نمی‌کردند. حال برای برای کمک به مدیران توسعه نرم‌افزار هفت اتلاف تولید نرم افزار ارائه می شود تا با حذف تدریجی یا کاهش آن ها به سمت تولید و توسعه نرم افزار ناب گام بر داریم.
در ادامه هفت اتلاف مربوط به توسعه نرم افزار را مرور می نماییم:
کار نیمه تمام انجام شده: (Partially Done Work)
مشکل بزرگ نرم افزار نیمه کاره این است که ممکن است هیچ ایده ای نداشته باشید که آیا در نهایت کار می کند یا خیر. مطمئناً، شما مجموعه ای از الزامات و اسناد طراحی دارید. حتی ممکن است یک انبوه کد داشته باشید که حتی ممکن است واحد تست شود. اما تا زمانی که نرم افزار با بقیه محیط ادغام نشود، شما واقعا نمی دانید چه مشکلاتی ممکن است در کمین باشد، و تا زمانی که نرم افزار واقعاً در حال تولید نباشد، واقعاً نمی دانید که آیا مشکل تجاری را حل می کند یا خیر.
توسعه نسبی انجام شده منابع را در سرمایه گذاری هایی که هنوز به نتیجه نرسیده اند پیوند می دهد. در توسعه نرم‌افزار، این سرمایه‌گذاری‌ها گاهی سبب شروع استهلاک زمانی می‌شود که نرم‌افزار وارد مرحله تولید شود. اگر سیستم هرگز آن را به تولید نرساند چه؟ سپس یک سرمایه گذاری بزرگ برای حذف وجود دارد. توسعه نسبی نرم افزار می تواند خطرات مالی زیادی را به همراه داشته باشد. به حداقل رساندن توسعه نرم افزار نیمه انجام شده یک استراتژی کاهش ریسک و همچنین یک استراتژی کاهش ضایعات است.
فرآیندهای اضافی: (Extra Processes)
آیا تا به حال از خود پرسیده اید که آیا این همه مدارک واقعا ضروری است؟ کاغذبازی منابع را مصرف می کند. کاغذبازی زمان پاسخگویی را کاهش می دهد. کاغذبازی مشکلات کیفی را پنهان می کند. کاغذهایی که هیچ کس به خواندن آنها اهمیتی نمی دهد ارزشی اضافه نمی کند.
بسیاری از فرآیندهای توسعه نرم‌افزار برای امضای مشتری، یا ارائه قابلیت ردیابی یا دریافت تأییدیه برای تغییر نیاز به کاغذبازی دارند. آیا مشتری شما واقعاً متوجه می شود که این باعث می شود محصول برای آنها ارزشمندتر شود؟ فقط به این دلیل که کاغذبازی یک تحویل الزامی است به این معنی نیست که ارزش افزوده دارد. اگر باید اسنادی تولید کنید که ارزش کمی برای مشتری ایجاد کند، سه قانون وجود دارد که باید به خاطر بسپارید: کوتاه نگه دارید. سطح آن را بالا نگه دارید. به صورت افلاین انجام دهید.
سیستم‌های حیاتی اغلب به الزامات مکتوب و قابل ردیابی به کد نیاز دارند. در این مورد، قالب‌بندی نیازمندی‌ها به گونه‌ای که بتوان آنها را به راحتی ارزیابی کرد و از نظر کامل بودن بررسی کرد، ممکن است به عنوان یک فعالیت ارزش افزوده واجد شرایط باشد. به دنبال یک قالب جدول محور یا قالب محور باشید که الزامات را به یک قالب فشرده کاهش می دهد که هم کاربران و هم توسعه دهندگان بتوانند به سرعت آن را درک و تأیید کنند.
یک آزمون خوب برای ارزش اسناد این است که ببینیم آیا کسی منتظر چیزی است که تولید می شود یا خیر. اگر یک تحلیلگر الگوها را پر کند، جداول بسازد یا موارد استفاده بنویسد که دیگران مشتاق استفاده از آن هستند – برای کدنویسی، آزمایش و نوشتن کتابچه راهنمای آموزشی – احتمالاً اینها ارزش افزوده دارند. با این حال، باید جستجوی مداوم برای کارآمدترین و مؤثرترین ابزار برای انتقال اطلاعات وجود داشته باشد. به جای الزامات، تست های مشتری را بنویسید. به طور کلی، مستندسازی جزئیات ویژگی‌های مورد نظر را تا تکراری که در آن پیاده‌سازی می‌شوند به تأخیر بیندازید.
ویژگی های اضافی: (Extra Features)
ممکن است ایده خوبی به نظر برسد که برخی از ویژگی های اضافی را در یک سیستم فقط در صورت نیاز قرار دهید. توسعه دهندگان ممکن است بخواهند یک قابلیت فنی جدید اضافه کنند تا ببینند چگونه کار می کند. این ممکن است بی ضرر به نظر برسد، اما برعکس، ضایعات جدی است. هر بیت کد موجود در سیستم باید با هر بار لمس کد ردیابی، کامپایل، ادغام و آزمایش شود و سپس باید برای تمام عمر سیستم نگهداری شود. هر بیت کد پیچیدگی را افزایش می دهد و یک نقطه شکست بالقوه است. احتمال زیادی وجود دارد که کد اضافی قبل از استفاده منسوخ شود. پس از همه، در وهله اول هیچ تماس واقعی برای آن وجود نداشت. اگر اکنون به کد نیاز نیست، قرار دادن آن در سیستم هدر است. در برابر وسوسه مقاومت کنید.
تعویض وظیفه: (Task Switching)
انتساب افراد به پروژه های متعدد منبع ضایعات است. هر بار که توسعه‌دهندگان نرم‌افزار بین کارها جابه‌جا می‌شوند، زمانی که آنها افکار خود را جمع‌آوری می‌کنند و وارد جریان کار جدید می‌شوند، زمان تغییر قابل توجهی متحمل می‌شود. تعلق به چندین تیم معمولا باعث وقفه های بیشتر و در نتیجه تعویض کار بیشتر می شود. این زمان تعویض کار اتلاف است.
سریع‌ترین راه برای تکمیل دو پروژه که از منابع یکسانی استفاده می‌کنند، انجام آنها در یک زمان است. فرض کنید دو پروژه دارید که هر کدام باید دو هفته طول بکشد. اگر یکی از آنها را شروع کنید، باید در عرض دو هفته انجام شود. وقتی کار تمام شد، می توانید پروژه دوم را شروع کنید و باید تا دو هفته دیگر انجام شود. اگر هر دو پروژه را با هم شروع کنید و انتظار داشته باشید که مردم بین آنها جابجا شوند چه؟ اولاً هیچ کدام در دو هفته انجام نمی شود، اما آیا هر دو در چهار هفته انجام می شود؟ وقتی زمان تعویض را اضافه می کنید، احتمالاً نزدیک به پنج هفته طول می کشد. مقاومت در برابر وسوسه شروع چندین پروژه به طور همزمان دشوار است، اما انتشار کار بیش از حد در یک سازمان توسعه نرم‌افزار، ضایعات زیادی ایجاد می‌کند، زیرا در واقع سرعت کار را کاهش می‌دهد.
در انتظار: (Waiting)
یکی از بزرگترین ضایعات در توسعه نرم افزار معمولاً انتظار برای اتفاقات است. تأخیر در شروع پروژه، تأخیر در تأمین نیروی انسانی، تأخیر به دلیل مستندسازی بیش از حد نیازها، تأخیر در بررسی و تأیید، تأخیر در آزمایش و تأخیر در استقرار ضایعات است. تأخیرها در اکثر فرآیندهای توسعه نرم‌افزار رایج هستند، و به نظر می‌رسد که این تأخیرها به‌عنوان اتلاف در نظر گرفته شود. به نظر می رسد که در بدترین حالت، تاخیرها خنثی هستند.
پس انتظار چه اشکالی دارد؟ تاخیر مشتری را از درک هر چه سریعتر ارزش باز می دارد. هنگامی که یک نیاز حیاتی مشتری به سازمان توسعه شما می رسد، سرعتی که می توانید با آن پاسخ دهید مستقیماً با تاخیرهای سیستمیک در چرخه توسعه شما مرتبط است.
برای برخی از محیط‌ها، تاخیر ممکن است به بزرگی مشکلات دیگر نباشد. با این حال، اگر در حال توسعه نرم افزار برای یک دامنه در حال تکامل هستید، تاخیر در توسعه جدی تر است. یک اصل ناب اساسی این است که تصمیمات را تا آخرین لحظه ممکن به تاخیر بیندازید تا بتوانید آگاهانه ترین تصمیم ممکن را بگیرید. این یک رویکرد مبتنی بر گزینه‌ها برای توسعه نرم‌افزار است، و بهترین راه برای مقابله با عدم قطعیت است، همانطور که در فصل 3، “تصمیم‌گیری تا حد امکان دیرتر” بحث کردیم. با این حال، اگر پس از اتخاذ تصمیم نتوانید به سرعت آن را اجرا کنید، نمی توانید تصمیمات را به تعویق بیندازید.
حرکت اضافی: (Motion)
وقتی یک توسعه‌دهنده سؤالی دارد، چقدر حرکت برای یافتن پاسخ لازم است؟ آیا افرادی برای کمک به مشکل فنی در دسترس هستند؟ آیا مشتری یا نماینده مشتری برای پاسخ به سؤالی در مورد ویژگی ها به راحتی در دسترس است؟ آیا توسعه دهنده می تواند بدون راه رفتن در سالن از نتایج آزمایشات مطلع شود؟ توسعه فعالیتی است که به تمرکز زیادی نیاز دارد، بنابراین راه رفتن در سالن بسیار بیشتر از آنچه فکر می کنید زمان می برد. احتمالاً چندین برابر زمانی که برای پاسخ به سؤال طول کشید، ایجاد مجدد تمرکز توسط توسعه دهنده طول خواهد کشید. به همین دلیل است که شیوه‌های توسعه نرم‌افزار چابک معمولاً توصیه می‌کنند که یک تیم در یک اتاق کار واحدی کار کنند که در آن همه به توسعه‌دهندگان، آزمایش‌کنندگان و مشتریان یا نمایندگان مشتری دسترسی دارند.
انسان ها تنها چیزهایی نیستند که حرکت می کنند – مصنوعات مختلف نیز حرکت می کنند. الزامات ممکن است از تحلیلگران به طراحان منتقل شوند و سپس اسناد طراحی از طراحان به برنامه نویسان منتقل شوند و سپس کد از کدگذار به تستر و غیره منتقل شود. هر دستیابی از یک مصنوع مملو از فرصت هایی برای ضایعات است. بزرگترین اتلاف در انتقال اسناد این است که اسناد – واقعاً نمی توانند – حاوی تمام اطلاعاتی باشند که فرد بعدی در صف باید بداند. مقدار زیادی از دانش ضمنی نزد سازنده سند باقی می ماند و هرگز به گیرنده واگذار نمی شود. انتقال مصنوعات از یک گروه به گروه دیگر منبع عظیمی از ضایعات در توسعه نرم افزار است.
عیوب: (Defects)
مقدار ضایعات ناشی از یک نقص محصول، زمانی است که شناسایی نشده است. یک نقص جزئی که برای هفته ها کشف نمی شود، ضایعات بسیار بزرگتری است. راه کاهش تأثیر عیوب، یافتن آنها به محض وقوع است. بنابراین، راه کاهش ضایعات ناشی از نقص، آزمایش فوری، تست های اتومات و تست پذیرش در اسرع وقت است.
و اما….
و اما موردی دیگر که می بایست به آن توجه نمود ولی در این دسته بندی 7 گانه قرار نمی گیرد، فعالیت های مدیریتی می باشد. فعالیت های مدیریتی (Management Activities) به طور مستقیم به یک محصول ارزش اضافه نمی کنند، اما تأثیر زیادی بر ضایعات یک سازمان دارند. به عنوان مثال، فرآیند اولویت بندی پروژه و سیستم انتشار کار را در نظر بگیرید. به حداقل رساندن ضایعات به معنای به حداقل رساندن میزان کار ناتمام در Pipeline است و این معمولاً نتیجه روش اولویت بندی و ریلیز کار است.
جمع بندی:
یادگیری دیدن ضایعات فرآیندی مداوم برای تغییر طرز فکر شما در مورد آنچه واقعاً ضروری است است. یکی از راه‌های کشف اتلافات این است که به این فکر کنید که اگر مجبور به خلاص شدن از شر کل چمدان‌های اضافی در یک پروژه مشکل شوید، چه چیزی را رها می‌کنید. معمولاً دیدن ضایعات در یک بحران آسانتر است.
چابک باشید
پی نوشت:
برای تهیه این مقاله از کتاب Lean Software Development: An Agile Toolkit کمک گرفته شده است.
دیدگاهتان را بنویسید