چگونه بهترین استفاده را ببریم MotioCI در حمایت از شیوه های اثبات شده
MotioCI دارای افزونه هایی برای نگارش گزارش Cognos Analytics است. گزارشی را که روی آن کار می کنید قفل می کنید. سپس، وقتی جلسه ویرایش خود را تمام کردید، آن را بررسی می‌کنید و یک نظر برای ثبت کارهایی که انجام می‌دهید اضافه می‌کنید. شما می توانید در کامنت اشاره ای به بلیط در سیستم ردیابی نقص خارجی یا درخواست تغییر در نظر بگیرید.
می توانید جزئیات بیشتری در مورد نحوه تنظیم اتصال بین پیدا کنید MotioCI و سیستم فروش بلیط شخص ثالث شما در MotioCI راهنمای مدیر در زیر استفاده MotioCI با سیستم های فروش بلیط شخص ثالث یک کلمه کلیدی (رفع، بستن) با شماره بلیط، بلیط را می بندد. یا با استفاده از کلمه کلیدی مانند منابع به علاوه شماره بلیط، نظر ورود را به سیستم بلیط می نویسد و بلیط را باز می گذارد.
استفاده از سیستم فروش بلیط - مانند Atlassian® JIRA، Microsoft Windows™ Trac یا بسیاری دیگر - با ردیابی وظایف خاص، مسائل و حل آنها به مدیریت پروژه کمک می کند. بلیط ها وسیله ای برای ارتباط بین نویسندگان یا توسعه دهندگان گزارش و کاربران نهایی، تیم آزمایش و سایر ذینفعان فراهم می کنند. یک سیستم فروش بلیط همچنین روشی برای ردیابی عیوب و اطمینان از رسیدگی به آنها قبل از ارائه گزارش به تولید ارائه می دهد.
گردش کار معمولی برای توسعه گزارش
برای روشن شدن، ادغام از MotioCI با سیستم فروش بلیط تنها راهی نیست که تیم شما با سیستم بلیط فروشی تعامل داشته باشد. به طور معمول، همانطور که در نمودار گردش کار همراه نشان داده شده است، روند توسعه گزارش در یک محیط Cognos Analytics با MotioCI ممکن است چیزی شبیه به این باشد: 
- جمع شدن. یک بلیط جدید ایجاد می شود. یک تحلیلگر کسب و کار الزامات کسب و کار را برای یک گزارش جدید مستند می کند و با ایجاد یک بلیط مستقیماً آن را وارد سیستم فروش بلیط می کند. او بلیط را در عقب افتادگی دولت است.
- پروژه. بلیط های عقب افتاده را می توان به روش های مختلف اولویت بندی کرد، اما در نهایت بلیط به یک توسعه دهنده گزارش اختصاص داده می شود و با نام او برچسب گذاری می شود. وضعیت بلیط ممکن است تغییر کند in_dev. او یک گزارش جدید ایجاد خواهد کرد. همانطور که او گزارش را در Cognos Analytics توسعه می دهد، تغییرات خود را بررسی می کند و به بلیط در نظر ورود اشاره می کند، مانند «گزارش جدید ایجاد شد. نسخه اولیه؛ صفحه سریع و پرس و جوهای پشتیبانی را اضافه کرد، مراجع #592 ". یا، «پرس و جو واقعیت و زبانه متقاطع را اضافه کرد. فیلترها و قالب بندی، مراجع #592" (که در MotioCI، شماره هشتگ مستقیماً به یک لینک به بلیط تبدیل می شود.) او ممکن است گزارش را بررسی کند، تغییراتی ایجاد کند و آن را چندین بار در طی چند روز با مرجع بلیط بررسی کند.
- توسعه تکمیل شد. پس از اینکه توسعه‌دهنده گزارش گزارش را تکمیل کرد و بنچ آن را آزمایش کرد، در بلیط در سیستم فروش بلیط یادداشت می‌کند که آماده آزمایش توسط QA است و وضعیت را از تغییر می‌دهد. in_Dev به آماده_برای_QA. این ایالت پرچمی برای MotioCI مدیر، یا نقش مسئول ارتقای گزارش‌های Cognos، که گزارش آماده مهاجرت به محیط QA برای آزمایش است.
- در هرmotion به QA. مدیر گزارش را تبلیغ می کند و وضعیت را به آن تغییر می دهد in_QA. این حالت به تیم QA اطلاع می دهد که گزارش آماده آزمایش است.
- آزمایش کردن. تیم QA گزارش را با الزامات تجاری آزمایش می کند. این گزارش یا در تست ها موفق می شود یا مردود می شود. اگر گزارش در تست QA ناموفق باشد، بلیط با برچسب نشان می شود در Dev وضعیت، برای رفع مشکل به توسعه‌دهنده گزارش باز می‌گردد.
- تست موفقیت آمیز اگر گزارش تصویب شود، تیم QA به مدیر می‌گوید که آماده است تا با برچسب‌گذاری آن را به تولید ارتقا دهد. آماده برای تولید دولت است.
- در هرmotion به تولید. پس از آماده شدن گزارش برای تولید، می‌توان تأییدیه‌های نهایی را دریافت کرد و برای انتشار برنامه‌ریزی کرد، شاید همراه با سایر گزارش‌های تکمیل‌شده. مدیر گزارش را به محیط تولید Cognos ارتقا می دهد. او بلیط را در آن قرار می دهد انجام شده بیان می کند که توسعه و آزمایش کامل شده و به تولید منتقل شده است. با این کار بلیط بسته می شود.
مدیریت فرآیند توسعه گزارش
این فرآیند مدیریت بلیط مستلزم و روش های اثبات شده است که:
- هر گزارش جدید باید دارای یک بلیط با الزامات تجاری برای طراحی گزارش باشد.
- هر نقص باید یک بلیط برای ثبت هر گونه اشکال یا مشکل در یک گزارش داشته باشد.
- هر بار که یک گزارش ویرایش می شود، MotioCI نظر ورود باید شامل شماره بلیطی باشد که آدرس داده شده است.
- هر گزارشی که از Dev به QA ارتقا می‌یابد باید یک بلیط مرتبط داشته باشد که یک مدیر می‌تواند تأیید کند که توسعه کامل شده است و آماده انتقال به محیط QA است.
- هر گزارشی که از QA به تولید ارتقا می‌یابد باید دارای یک تیکت باشد که دارای سابقه باشد که نشان دهد توسعه کامل است، QA را پشت سر گذاشته است، تمام تاییدیه‌های مدیریتی مورد نیاز را دریافت کرده و ارتقا یافته است.
- هر گزارش در محیط تولید باید دارای یک digital دنباله کاغذ از مفهوم تا آزمایش تا تثبیت به وضوح تا تایید و حرفه ایmotion.
این نکته آخر مورد علاقه حسابرسان برای تأیید اعتبار است. او ممکن است بپرسد، "آیا می توانید به من نشان دهید که چگونه تأیید می کنید که همه گزارش های موجود در محیط تولید مطابق با روند مستند شما برای تهیه بلیط و تایید هستند؟" یکی از راه‌های پاسخگویی به حسابرس ممکن است ارائه فهرستی از تمام گزارش‌هایی باشد که منتقل شده‌اند و از او بخواهید در بلیط‌ها قدم بزند تا به دنبال گزارشی باشد که با فرآیند شما مطابقت ندارد.
روش دیگر، و ایده آل تر، می توانید فهرستی از گزارش هایی که انجام می دهند ارائه دهید نه به فرآیند توسعه و فروش بلیط که تعریف کرده اید پایبند باشید. اینجاست که این گزارش مفید خواهد بود:گزارش‌هایی که بدون بلیط تبلیغ می‌شوند". این یک گزارش استثنایی از فهرستی از گزارش‌هایی است که دارند نه به بهترین شیوه های مرتبط کردن هر تغییر گزارش به بلیط پایبند بود. این یکی از معدود گزارش‌هایی است که می‌خواهید خالی باشد. اگر همه گزارش‌هایی که تبلیغ می‌شوند دارای یک بلیط مرتبط با آن باشند، هیچ سابقه‌ای نخواهد داشت. به عبارت دیگر، یک گزارش تنها در صورتی در لیست ظاهر می شود که در محیط تولید باشد و گزارشی که تبلیغ شده است به شماره بلیط در کامنت اشاره نکرده باشد. 
فرآیند با مزایا
مزایای این فرآیند چیست یا چرا باید این کار را در سازمان خود انجام دهید؟
- بهبود همکاری تیمی: سیستم فروش بلیت در واقع ممکن است افرادی را در نقش هایی گرد هم آورد که معمولاً ممکن است ارتباط برقرار نکنند. به عنوان مثال، نویسندگان و کاربران نهایی، یا مدیر پروژه و تیم QA را گزارش دهید. مسیر بلیط مکانی مشترک برای برقراری ارتباط در مورد یک منبع مشترک، گزارش در دست توسعه، فراهم می کند.
- هزینه های کاهش یافته:
- عیوبی که زودتر شناسایی و رفع شوند، بسیار ارزان تر از زمانی هستند که به تولید برسند.
- بهره وری بهبود یافته - نویسندگان گزارش همیشه از یک بلیط کار می کنند که یک بیانیه کار کاملاً تعریف شده است.
- کاهش زمان از طریق اتوماسیون فرآیندهای دستی
- مستندسازی بهبودیافته: این فرآیند به یک پایگاه دانش خود مستندسازی از نقص ها و نحوه رفع آنها تبدیل می شود.
- پیش بینی و تجزیه و تحلیل بهبود یافته: اکنون می توانید شاخص های کلیدی عملکرد را ردیابی کرده و آنها را با توافق نامه های سطح خدمات مقایسه کنید. اکثر سیستم های فروش بلیط این نوع تجزیه و تحلیل ها را ارائه می دهند.
- پشتیبانی داخلی بهبود یافته: تیم پشتیبانی شما، سایر توسعه دهندگان گزارش (و حتی خود آینده شما!) می توانند بررسی کنند که چگونه نقص های مشابه در گذشته برطرف شده است. این پایگاه دانش مشترک می تواند به رفع سریع نقص ها منجر شود.
- بهبود رضایت کاربر نهایی: با دسترسی مستقیم به توسعه دهندگان از طریق سیستم بلیط، کاربران می توانند انتظار رفع سریع نقص ها و همچنین نظارت بر پیشرفت گزارش درخواستی را از طریق سیستم داشته باشند.
نتیجه
این نمونه ای از بازدهی غنی برای پیروی از شیوه های اثبات شده و ارزش پیروی از فرآیندهای کاملاً تعریف شده است. علاوه بر این، جدید MotioCI گزارش، «گزارش‌هایی که بدون بلیط تبلیغ می‌شوند» می‌تواند کمک بزرگی در پاسخگویی به سؤالات حسابرس، یا صرفاً نظارت داخلی برای پایبندی به استانداردهای شرکت باشد.
