یکی از استدلال ها و تفکرات غلط رایجی که درباره اسکرام وجود دارد این است که در اسکرام کیفیت برای به دست آوردن سرعت فدا می شود. من به عنوان مدرس رسمی مؤسسه Scrum.org با سالها تجربه در تضمین کیفیت تصمیم گرفتم این افسانه را به چالش بکشم. من اعتقاد دارم و بارها دیده ام که شیوه صحیح اجرای اسکرام منجر به تولید محصولات با کیفیت بالاتر نسبت به روش های به اصطلاح سنتی سریعتر می شود. من به بیان دلایلی برای ایده های کم کیفیت در اسکرام می پردازم. سپس ایده کیفیت را بررسی می کنم. سرانجام توضیح خواهم داد که چگونه اسکرام از محصولات با کیفیت بالا پشتیبانی می کند.

سرچشمه افسانه کیفیت پایین

بگذارید لحظه ای فکر کنیم که افسانه از کجا می آید. با نگاهی به تجربه خود به عنوان مربی و مشاور ، می توانم دو منبع را ببینم ، یکی نظری و دیگری عملی.

در تئوری به دنبال کیفیت پایین می گردید

من می توانم ببینم که چگونه شخصی با یادگیری اسکرام و طرز فکر اجایل می تواند با پیوند دادن زمینه فعلی خود به ارزش ها ، اصول و قواعد پیشنهادی، نتیجه گیری نادرست انجام دهد. در کنار اسکرام مستر و مالک محصول در تیم اسکرام، تیم توسعه ای داریم که از توسعه دهندگان تشکیل شده است. نتیجه گیری اشتباه این است که “من یک تیم تست و آزمایش کننده ها را در تیم توسعه نمی بینم، بنابراین تست در اسکرام وجود ندارد.” حقیقت این است که تیم توسعه خودکفا (cross-functional) باید مهارت های تست را نیز داشته باشند. چه کسی تستر است؟ تستر یک حرفه ای در فرآیند توسعه نرم افزار است که وظیفه انجام فعالیت های تست را دارد، ما همچنین متخصصانی را که دارای مهارت تست هستند در تیم داریم. در اسکرام ما نمی خواهیم نقشی به نام تستر در تیم توسعه داشته باشیم زیرا منجر به این می شود که یک شخص صرفاً مسئولیت تست را بر عهده بگیرد. تمام تیم توسعه مسئولیت کیفیت محصول را بر عهده داشته و هر یک از اعضای تیم بدون در نظر گرفتن تخصص خود مسئولیت مساوی دارند. ترکیب تیم توسعه باید بهینه باشد تا فرآورده بالقوه قابل انتشار را ارائه دهد. بنابراین توسعه دهندگان باید مهارت تست داشته باشند که البته برخی از آنها در تست بهتر هستند، برخی از آنها نیز تخصص کمتری دارند اما با این وجود مهارت های تست در تیم خواهد بود.

فرآورده بالقوه قابل انتشار باید در حالت قابل استفاده باشد و با فرآورده هایی که قبلاً تحویل داده شده اند به خوبی کار کند. بنابراین همه کارها باید در مورد الزامات تجاری و ادغام آزمایش شوند. این فرآورده باید Done شود و این بدان معنی است که باید با “تعریف انجام شده” (Definition of Done) مطابقت داشته باشد. بدین ترتیب می توانیم اطمینان حاصل کنیم که برای همه افراد درگیر در پروژه، اینکه منظور از Done چیست واقعاً شفاف است و به چه معنی است که یک مورد از بک لاگ محصول Done شده است.

با استفاده از مفهوم “تعریف انجام شده” برداشت غلط دیگری به وجود می آید. چه کسی در مورد محتوای “تعریف انجام شده” تصمیم می گیرد؟ تیم توسعه در مورد “تعریف انجام شده” مناسب برای محصولی که می سازند تصمیم می گیرد. می توان نتیجه گرفت که در این صورت تیم توسعه آسانترین و راحت ترین تعریف را از دیدگاه خود ارائه می دهد. آنها قسمت سخت را خارج می کنند. اما چرا متخصصان نرم افزار چنین کاری را انجام می دهند؟ بگذارید این سؤال را برای بررسی خودتان بگذاریم. من یک سوال بهتر برای شما دارم “تعریف انجام شده” از کجا می آِید یا بر چه اساس است؟ باید برخی قراردادهای موجود، استانداردهای صنعت و سیاست های شرکت در آن لحاظ شود و آنها سنگ بناهایی هستند که تیم توسعه باید “تعریف انجام شده” را بر روی آن بنا کند. علاوه بر این، استانداردها و کارهایی که در “تعریف انجام شده” شرح داده شده است باید منعکس کننده حالت بالقوه قابل انتشار در فرآورده محصول باشد. ما می خواهیم آماده باشیم تا محصول را در هر اسپرینت منتشر کنیم. به این ترتیب “تعریف انجام شده” از دستورالعمل قبلی استفاده شده قوی تر خواهد بود و به جای انتهای پروژه، هر اسپرینت را موظف می کند.

برای ورود به دنیای اسکرام می توانید از دوره غیرحضوری “آشنایی مقدماتی با اسکرام” شروع کنید

در عمل به دنبال کیفیت پایین می گردید

من کاملاً آگاه هستم که شما می توانید تیم هایی را ملاقات کنید که ادعا می کنند اسکرام را انجام می دهند و محصولات کم کیفیت دارند. من تیم هایی را دیده ام که کار جدید را با اسکرام شروع کرده اند و خیلی سریع به مشکلات مربوط به تعمیر و یا رفع اشکال می پردازند. من همچنین تیم هایی را دیده ام که پروژه فعلی را به روش کار اسکرام تبدیل کرده اند و نتوانسته اند محصول مناسبی را برای بسیاری از اسپرینت ها ارائه دهند. بنابراین خیلی آسان است که نتیجه گیری کنیم با بکارگیری اسکرام کیفیت از دست می رود. بله، من نیز آن را دیده ام. با این وجود هنوز یک جهش بسیار بلند است که اسکرام را مقصر بدانیم. آیا مطمئن هستید که همان تیم با استفاده از روشی متفاوت برای کار بهتر عمل می کند؟ آیا آنها کارهای اضافی انجام نمی دهند که اسکرام انجام دهند؟ از کجا می دانید کاری که آنها انجام می دهند اسکرام است؟ شاید اسکرام باشد اما با از بین بردن رویدادها، نقش ها یا مصنوعات ایجاد شده است؟ انجام اسکرام در عمل دشوار است و تلاش زیادی لازم است تا با زنده نگه داشتن ارزش های اسکرام از تئوری فراتر بروید. اسکرام متعهد نمی شود که همه مشکلات را در تیم یا سازمان حل کند. اسکرام نمایانگر آن است که شیوه های فعلی آنها در ایجاد نتایج مطلوب تا چه اندازه مؤثر است. این انتخاب آنها است که عملیات را بهبود دهند و یا اسکرام را اصلاح کنند تا کمتر به چشم بیاید.

چه کیفیتی و چگونه

هنگامی که ما قبلاً از تعریف درست استفاده کرده ایم دیگر نیازی به شروع یک بحث و ادامه به سمت یک مشاجره بی پایان نداریم. پس از استاندارد IEEE 610 کیفیت، درجه ای است که یک جزء ، سیستم یا فرآیند نیازهای مشخص شده و / یا نیازها و انتظارات کاربر / مشتری را برآورده می کند. اطمینان از کیفیت بالا چیزی بیش از تست و رفع اشکالات و باگ ها هنگام اجرای نیازمندی ها است. ما باید برای ایجاد کیفیت بالا و با کمترین نقص ممکن کل فرآیند را بهینه کنیم.

کیفیت مطابق با نیازمندی ها

بسیاری از پروژه ها به دلیل اینکه کسی در مورد چیزهای مهم حرفی نزد یا سوء تفاهم شده بود، شکست خورد. یکی از زمینه هایی که مسائل مرتبط با ارتباطات قابل مشاهده است نیازمندی ها هستند. بهترین الزاماتی که به صورت انفرادی نوشته شده است، همواره مورد تفسیر آزاد توسط کسی است که آنها را اجرا می کند. ارتباطات مستقیم و حلقه های بازخورد کوچک تنها روش مؤثر برای اطمینان از ارائه خروجی درست توسط تیم توسعه است.

الزامات مشخص شده در اسکرام چگونه است؟ یک نفر می تواند فریاد بزند “یوزر استوری!” در حالی که نوشتن یوزر استوری ها با اسکرام متداول است، این کار یک الزام نیست. از آنجا که بک لاگ محصول تنها منبع کار در اسکرام است، نیازمندی های عملیاتی و غیر عملیاتی باید در آنجا به هر شکلی که بتواند برای همه ذینفعان راحت باشد، قرار داده شود. چرا فرم مهم است؟ زیرا در اسکرام می خواهیم همه ذینفعان بدانند که چه چیزی در بک لاگ محصول وجود دارد و در مورد الزامات همکاری می کنند. آیتم های بک لاگ محصول با تلاش مشترک توسط مالک محصول و تیم توسعه تصفیه می شوند. این روشی است که ما اطمینان حاصل می کنیم همه برداشت یکسانی دارند و ایده ها را از چندین منظر جمع آوری می کنیم.

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

کیفیت به وسیله کار با کیفیت بالا

همه ما محصولاتی را دیده ایم که در محیط تولید عملکرد مطلوبی نداشته و یا توسعه و گسترش بیشتر آن دشوار است. انجام کار درست کافی نیست. ما به محصول نیاز داریم تا کار درست را نمایش دهد. مشکلات مربوط به نگهداری و عملکرد با ایجاد و رشد بدهی های فنی بروز می کند. راه اصلی مقابله با بدهی، تعریف شفاف از معیارها، قواعدی برای برآورده شدن و کار برای تکمیل هر آیتم بک لاگ محصول قبل از اینکه ما آن را انجام دهیم صورت می گیرد. البته این با شفافیت در “تعریف انجام شده” بدست می آید که بسیار مهم تلقی می شود. آیتم بک لاگ محصول در انتهای اسپرینت Done می شود و یا اگر Done نشده باشد به بک لاگ محصول باز می گردد. چندین تیم اسکرام که روی یک محصول کار می کنند به یک “تعریف انجام شده” مشترک خواهند رسید ، بنابراین سطح کیفیت در کل محصول پایدار خواهد بود.

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

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

حقیقت در مورد سرعت در اسکرام

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

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

https://www.scrum.org/resources/blog/scrum-myths-quality-traded-speed-scrum

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