بیشتر سازمان ها تحت فشار فزاینده ای برای ارائه ارزش بیشتر، در زمان کمتر و با هزینه کمتر هستند. این هدف که همان توسعه چابک است در بسیاری از سازمان ها بسیار موفق بوده است. خواه اینکه سازمان شما چابکی را پذیرفته باشد یا خیر، در اینجا دوازده ایده نوآورانه برای تحلیلگران کسب و کار وجود دارد که ممکن است بخواهید برای ارائه ارزش بیشتر در مدت زمان کمتر آنها را در نظر بگیرید.
- از ویژگی‌ها استفاده کنید: پروژه خود را با توجه به ویژگی‌ها تقسیم کنید، ویژگی‌ها را اولویت‌بندی کنید و ابتدا روی ویژگی‌هایی کار کنید که بالاترین ارزش را ارائه می‌دهند. این رویکرد مزایای بسیاری از جمله توسعه الزامات بهتر، ارائه سریع‌تر ارزش و حذف عملکردهای کم ارزشی را که هرگز واقعاً استفاده نمی‌شوند، ارائه می‌کند.
- اندازه‌گیری، اندازه‌گیری و اندازه‌گیری: اگر تا به حال این کار را نکرده‌اید، بسیار مهم است که فرآیند خود را اندازه‌گیری کنید. برای شروع، روزی که ایده اولیه شناسایی شد، زمانی که برای توسعه آماده شد، زمانی که توسعه شروع شد، زمانی که توسعه به پایان رسید، زمانی که به QA رفت و زمانی که به کار گرفته شد را ثبت کنید. با استفاده از این اعداد، می توانید زمان پیشروی خود را از ایده تا اجرای زنده محاسبه نمایید. همچنین می توانید مدت زمان بافرهای خود را محاسبه کنید: قبل از اینکه یک ویژگی برای توسعه برود، یا قبل از اینکه برای QA برود چقدر باید منتظر بماند. اندازه‌گیری زمان از لحظه ایده‌پردازی ویژگی ها تا تحویل اقلام برای کوتاه کردن زمان تولید، امری ضروری است.
- استفاده از ویژگی‌ها برای ترویج موازی‌سازی: مجموعه‌های مختلفی از ویژگی‌ها اغلب به متخصصان موضوع متفاوتی نیاز دارند. به عنوان مثال، پیاده سازی یک سیستم منابع انسانی جدید را در نظر بگیرید . SMEها برای پردازش حقوق و دستمزد احتمالاً بسیار متفاوت از آنهایی هستند که در استخدام یا ردیابی متقاضیان دخیل می باشند. تفکیک ویژگی‌ها به مجموعه ویژگی‌ها، فرصت کار بر روی الزامات مربوط به ویژگی‌های چندگانه را به طور همزمان با استفاده از چندین تیم SME فراهم می‌کند، در نتیجه زمان ایده‌سازی تا اجرا را کاهش می‌دهد.
- قابلیت استفاده مجدد: استفاده مجدد از الزامات می تواند به میزان قابل توجهی در زمان صرفه جویی کند. برای مثال، بهتر است الزامات غیرعملکردی را زودتر به عنوان یک ویژگی جداگانه تعریف نمایید و سپس از آنها در همه ویژگی‌های دیگر استفاده مجدد کنید. بسیاری از زمینه های دیگر وجود دارد که در آنها می توان از الزامات استفاده مجدد کرد و به این وسیله کارایی را افزایش و زمان چرخه را کاهش داد.
- بسته‌های الزامات: ویژگی‌ها برای مدیریت ارزش کسب وکار و برای توسعه الزامات بسیار خوب هستند. با این حال، توجه صرف به ویژگی ها ممکن است بهترین راه برای ساختن سیستم نباشد. ارائه الزامات در قالب بسته‌ها برای توسعه یافتن(یعنی گروه‌هایی از الزامات که با تکرار توسعه، سازماندهی شده‌اند) فرصت‌هایی را برای توسعه سریع و ایجاد و حفظ شتاب فراهم می‌نمایند. همانطور که در زیر نشان داده شده است، مدیریت ویژگی ها به کنترل ورودی به بک لاگ کمک می کند در حالی که مدیریت بسته ها به کنترل خروجی برای پیاده سازی کمک خواهد کرد.
- ارائه الزامات به صورت الکترونیکی و نه از طریق کاغذ: بسیاری از سازمان ها هنوز از Microsoft Word برای ایجاد الزامات استفاده کرده و اسناد کاغذی بزرگی برای الزامات خود ایجاد می نمایند. تلاش برای نگهداری نسخه های مختلف این اسناد و ارائه تمام جزئیات مربوط به آن می تواند یک کابوس واقعی باشد. حرکت به سمت نگهداری ، ردیابی و ارائه الکترونیکی الزامات می‌تواند تا حد زیادی در زمان صرفه‌جویی کند و اجازه دهد تمام اطلاعات مربوط به الزامات مانند تاریخچه تغییرات، مکالمات، تجسم‌ها و قوانین مرتبط با کسب و کار در دسترس باشند. بازتولید یک سند جدید برای یک الزام هر بار که تغییر کوچکی در یک نیاز ایجاد می شود، در محیط امروزی به خوبی کار نمی کند.
- اعتبارسنجی و بررسی الزامات به صورت مشترک: الزامات می بایست همینکه ایجاد شدند بررسی و اعتبارسنجی گردند؛ نه اینکه منتظر بمانند تا همه آنها در یک سند بزرگ کاغذی مربوط به الزامات اعتبارسنجی شوند. استفاده از ابزار همکاری الزامات مانند Enfocus Requirements Suite (http://www.EnfocusSolutions.com) زمان چرخه بررسی و اعتبارسنجی الزامات را کوتاه می کند. دریافت زودهنگام الزامات می تواند در زمان صرفه جویی کرده و الزامات محصول بسیار بهتری ارائه دهد و منجر به رضایت بیشتر جامعه کاربر گردد.
- ارائه به موقع الزامات و در سطح مناسبی از جزئیات: سطح جزئیات مورد نیاز برای الزامات یک سوال دشوار است که پاسخ آن بر اساس تعدادی از مسائل مختلف متفاوت خواهد بود. مسائلی مانند: آیا توسعه برون سپاری شده است؟ توسعه‌دهندگان در طول توسعه چقدر به SMEها دسترسی خواهند داشت؟ ج. توسعه دهندگان چقدر دانش دامنه دارند؟ توسعه الزامات در سطح دقیقی از جزئیات امری بسیار مهم است. جزئیات اگر بیش از حد باشند، گران تمام خواهد شد و گاهی اوقات ممکن است برای توسعه دهندگان گیج کننده باشد. جزئیات بسیار کم نیز باعث می شوند توسعه دهندگان وادار شوند مفروضاتی بسازند، اشتباه کنند و عملکرد را کاهش دهند، باعث دوباره کاری و تاخیر یا هر دو شوند و همچنین منجر به نارضایتی کاربران گردند. برای به حداقل رساندن این خطر، در مورد سطح جزئیات باید از قبل توافق شود. باید از توسعه دهندگان خواسته شود که الزامات اولیه را بررسی کنند تا اطمینان حاصل شود که آنها در سطحی از جزئیات هستند که نیاز به توسعه دارد. بازنگری‌های گذشته باید پس از تحویل هر بسته از الزامات به تیم توسعه انجام شود تا مشخص گردد که آیا تنظیم سطح جزئیات در الزامات مورد نیاز، برای پشتیبانی از پروژه ضروری است یا خیر.
- مدیریت الزامات گذشته نگر: الزامات باید به‌صورت تدریجی توسعه یافته و در قالب بسته‌های الزامات ارائه شوند. پس از تحویل هر بسته از الزامات، می بایست یک نوع بررسی گذشته نگر انجام شود تا مشخص گردد که چه چیزی خوب عمل کرده و چه چیزی نیاز به بهبود دارد. از گذشته نگرها در توسعه چابک استفاده می شود، اما به ندرت برای توسعه الزامات نیز از آنها استفاده می گردد. در فرآیندهای توسعه الزامات، ایجاد تنظیمات به صورت مستمر کمک قابل توجهی به تولید الزاماتی عالی در سطح دقیقی از جزئیات و حذف ضایعات فرآیند می نماید.
- حذف عملکردهای غیر ضروری: همانطور که مطالعات نشان داده است، قانون ۸۰/۲۰ برای توسعه نرم افزار صادق است. یعنی با پیاده سازی ۲۰ درصد توسعه، ۸۰ درصد از نیازهای مشتریان خود را برآورده خواهید کرد. با توجه به این، مهم است که ۲۰٪ از نیازهای خود را که ۸۰٪ ارزش فراهم می کنند، شناسایی نمایید. فهرست ویژگی‌ها یا الزامات را به ۲۰ درصدی که بیشترین ارزش را ارائه می‌دهند خلاصه کنید و به این ترتیب زمان ارائه ویژگی‌ها به طور چشمگیری کاهش می‌یابد (در حالت بهینه تا ۵ برابر). همچنین به خاطر داشته باشید که مطالعات نشان داده اند که ۶۴ درصد از ویژگی ها هرگز استفاده نشده و یا به ندرت استفاده می شوند. این ویژگی‌ها مسیر توسعه شما را مسدود می‌کنند، زمان ارائه را برای همه ویژگی‌های دیگر افزایش می‌دهند و توسط کاربران شما نیز استفاده نمی‌شوند!
- انتشارات مکرر: بزرگترین بافر اغلب بافر انتشار است، بنابراین قبل از همه بافرهای دیگر در مورد آن صحبت خواهیم کرد. اگر چرخه انتشار ۶ ماهه داشته باشید، به این معنی است که بیشتر ویژگی های شما توسعه یافته، آزمایش شده و شروع به ارائه ارزش می کنند، اما برای انتشار باید چندین ماه صبر کنید. لذا در نظر داشته باشید که چرخه انتشار خود را به ۲ یا ۳ ماه کاهش دهید. سپس، اگر با این کار راحت بودید، زمان چرخه را به یک ماه کاهش دهید.
- حذف یا کوتاه کردن جلسات: یکی از ضایعات بزرگی که توسعه دهندگان را از توسعه کدها باز می دارد جلسات هستند. توسعه‌دهندگان می‌توانند با محدود کردن تعداد جلساتی که در آن شرکت می‌کنند، کارهای بیشتری انجام دهند. ابزار الزامات مشترک می تواند به حذف بسیاری از جلسات کمک کند. توسعه‌دهندگان می‌توانند به‌جای شرکت در جلسات، از طریق ابزارهای همکاری، شفاف‌سازی و اطلاعات اضافی مورد نیاز را درخواست کنند.
- اجازه دهید توسعه دهندگان شما کد بنویسند و روی ارزش مشتری کار کنند. اگر نگاهی به اسکرام بیاندازید احتمالا به شما در این زمینه کمک خواهد کرد. اسکرام به عنوان یک متدولوژی چابک دارای مجموعه ای از جلسات از پیش تعریف شده است که همگی با نتایج قابل اجرا و با زمان مشخصی همراه هستند. این امر تعداد جلسات برگزار شده را که به نظر می رسد بی انتها و بدون نتایج واضح ادامه می یابند، به حداقل می رساند.
