راز تولید چابک در دل بزرگ‌ترین بانک ایران

اسد صفری؛ ماهنامه عصر تراکنش / بام یکی از بهترین و متفاوت‌ترین اینترنت‌بانک‌های ایرانی است که به‌صورت چابک تولید شده است. صحبت از 60 میلیون حساب در بانک ملی ایران است، از 1700 نفر نیروی شرکت سداد، حدود 200 پروژهٔ تعریف‌شدهٔ همزمان در این شرکت و همکاری بیش از 22 برنامه‌نویس و طراح روی یک پروژه، همهٔ این اعداد نشان از بزرگی موجودیتی دارد که می‌خواهد حرکت کند اما حرکت در آن به‌مراتب کندتر از حرکت در شرکت‌های کوچک و پویا است.

«بام» که نام جدیدترین پروژهٔ فناورانه بانکی ملی است در چنین محیطی متولد شد و رشد کرد. بام نسل جدید سامانه «بانک اول من» یا همان بانکداری اینترنتی بانک ملی است که با فضایی کاملاً متفاوت از آنچه تاکنون مشتریان از اینترنت بانک ملی می‌شناختند، به مشتریان بانک ملی سرویس می‌دهد. داستان تولد بام و چالش‌های پیش روی آن را باید از زبان کسانی شنید که از نزدیک شاهد این تولد و رشد بوده‌اند. اسد صفری، مدیر دفتر تحول چابک شرکت سداد، در نوشتاری که خواهید خواند، تجربه‌های پیاده‌سازی این سامانه را از زوایای مختلف و به‌خصوص از نظر پیاده‌سازی فرآیندهای چابک نوشته است.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]سامانه بام: یا همان بانک اول من، تولید سال 94، بانکداری همراه و اینترنتی بانک ملی است که به مشتری امکان شخصی‌سازی خدمات دریافتی را تا سطح تعیین‌شده می‌دهد.[/mks_pullquote]

 

موانع حقوقی

یکی از موانع حقیقی استفاده از فرآیندهای چابک، مباحث حقوقی و قراردادهاست. بدین‌صورت که طرح پروژه در قالب یک RFP آماده می‌شود و کسانی که RFP را آماده می‌کنند، از ترس این‌که فردا مورد اتهام قرار نگیرند، معمولاً آن را حداکثری در نظر می‌گیرند؛ حداکثری یعنی این‌که با در نظر گرفتن همه‌چیز و از همه‌چیز، انتخاب بهترین.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]RFP: مستند رسمی و فنی است که توسط کارفرما یا نمایندگان فنی کارفرما تهیه می‌شود. این مستند شامل تعریف دقیق بخش‌های پروژه نرم‌افزاری موردنظر، همراه با شرایط و مقرراتی است که پیمانکار برای اجرای پروژه باید رعایت کند.[/mks_pullquote]

 

چنین روندی در RFP پروژه بام نیز بود، اما چگونه با این وضعیت می‌توان چابک بود؟ چگونه با وجود یک قرارداد که ضمیمه آن لیستی از قابلیت‌های لازم و غیرلازم است، می‌توان چابک بود؟

نکته در رعایت همان ارزش سوم چابک است؛ «مشارکت مشتری در انجام کار بالاتر از قرارداد کار.» ارائه نسخهٔ اول و زودهنگام بام موجب جلب رضایت ذی‌نفعان اصلی سیستم و ایجاد اعتماد نسبی شد که در ادامه با حضور مدیران بانک در جلسات بازبینی، دیگر پایبند بودن به لیست ویژگی‌های اولیه، ضروری به نظر نمی‌آمد. از آن‌جا که خود مشتری در فرآیند تولید مشارکت داشت، تیم توانایی این را داشت که از او بخواهد به ازای اضافه کردن نیازمندی‌های جدید پیش‌بینی‌نشده، از آیتم‌های کم‌اهمیت بک‌لاگ کم کند.

اصولاً وجود موارد کم‌اهمیت در بک‌لاگ محصول صرفاً برای چانه‌زنی است، نه برای انجام دادن.

 

تیم‌ها چطور شکل گرفتند؟

سازمان‌دهی اولیهٔ تیم‌ها از مدل سازمان ماتریسی اسپاتیفای وام گرفته شده بود اما بر اساس نیاز با وضعیت سازمان انطباق داده شد. در هر تیم بین 6 تا 8 نفر حضور داشتند؛ تحلیل‌گر، توسعه‌دهندگان سمت بَک‌اِند و فرانت‌اِند و آزمایشگر. ساختار داخل تیم‌ها نیز به‌صورت کراس فانکشنال (فراوظیفه‌ای) بود یعنی به‌صورتی که تیم‌ها بدون وابستگی به تیم‌های دیگر می‌توانستند کارها را انجام دهند.

روی تیم‌ها نام رشته‌کوه‌های ایران گذاشته شده بود، نام‌هایی مانند بینالود، سهند و الوند. هرکدام از تیم‌ها نیز روی قسمت‌های خاصی از محصول که از نظر کسب‌وکاری به هم نزدیک هستند، فعالیت می‌کردند، مثلاً مأموریت تیم بینالود مدیریت انتقال پول مانند انتقال پول داخلی، پایا، ساتنا بود. بر اساس همین مأموریت، ویژگی‌های جدیدی که توسط مالک محصول تعریف می‌شد به‌صورت خودکار به بک‌لاگ این تیم منتقل می‌شد.

 

مالک محصول

همه تیم‌ها زیر نظر یک مالک محصول فعالیت می‌کردند. به دلیل وسعت پروژه، مالک محصول برخی از کارهای خود را به تحلیلگرها سپرده بود و بیشتر تصمیم‌گیری‌های کلان و ارتباط با ذی‌نفعان بر عهده او بود، مثلاً تعریف ویژگی‌های اصلی سیستم را بر عهده داشت اما جزئیات این کار بر عهده تحلیلگرها بود، تحلیل‌گرها نیز در صورت لزوم تصمیم‌های خود را با او هماهنگ می‌کردند.

راحت‌ترین کار برای یک مدیر یا مالک محصول این است که دقیقاً آن چیزی را که در RFP نوشته شده است، انجام دهد یا در بهترین حالتِ خود، محصولات مشابه را نگاه کند و کپی از آن‌ها با یک UI خوب انجام دهد؛ اما در مالکیت محصول بام، مالک محصول وظیفه صرفاً پاس کردن قرارداد را نداشت و سعی می‌کرد بهترین تجربهٔ کاربری را برای مشتریان بام ایجاد کند.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]مالک محصول: مالک محصول وظیفه به حداکثر رساندن نرخ بازگشت سرمایه در محصول را دارد، با شناسایی و اولویت‌بندی مداوم ویژگی‌های جدید برای محصول این کار را انجام می‌دهد.[/mks_pullquote]

 

برای مثال، شما در اکثر اینترنت‌بانک‌های دیگر گزینه پرداخت از طریق ساتنا و پایا را می‌بینید. بسیاری از مشتریان فرق این دو را نمی‌دانند؛ بنابراین مالک محصول بام تصمیم گرفت این‌ها را در بام نداشته باشد مگر این‌که بعداً درخواستی روی آن‌ها داشته باشند. حمیدرضا مختاریان، مدیر محصول این پروژه می‌گوید: «اگر شخص از طریق شبا بخواهد انتقال را انجام دهد، بر اساس مبلغ انتقالی موردنظرش ما انتقال پایا یا ساتنا انجام می‌دهیم. نکته مثبت ماجرا این است که دیگر لازم نیست کسی بداند پایا یا ساتنا چیست و چه فرقی می‌کنند. البته در مرحله آخرِ انتقال به مشتری اعلام می‌کنیم که این انتقال پول مثلاً به شکل ساتنا یا پایا انجام خواهد شد و این‌که با چه شرایط زمانی انجام می‌شود.»

تحلیلگرها

تحلیلگران تیم، نمایندگان مالک محصول در تیم‌ها بودند، این نفرات نیازمندی‌ها را از مالک محصول دریافت می‌کردند و پس از شفاف‌سازی این نیازمندی‌ها در قالب نوشتن شرایط پذیرش و شاید حتی کشیدن Mockup آن را آمادهٔ انجام می‌کردند. اصولاً انتظار این بود که تحلیلگرها یک اسپرینت از تیم توسعه جلوتر حرکت کنند. در طول اسپرینت نیز، کارها بر اساس شرایط توافق‌شده، تحویل گرفته شوند.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]اسپرینت: یک بازه زمانی کوتاه بین دو تا چهار هفته[/mks_pullquote]

 

کمیته‌ها

هدف کمیته‌ها تصویب قوانین و دستورالعمل‌هایی است که تیم‌های مختلف باید آن‌ها را رعایت کنند. ویژگی کمیته‌ها از این قرار بود:

تخصصی: کمیته معماری در حوزه معماری صحبت می‌کردند و اعضای آن از افرادی بود که در این خصوص تخصص داشتند.

حضور یک نماینده از هر تیم در کمیته: حضور یک نماینده از هر تیم در هر کمیته باعث می‌شد که مصوبات کمیته به گوش تیم‌ها برسد؛ یعنی نمایندهٔ هر تیم، مشکلات تیم خود را در این خصوص بازگو می‌کرد و نتیجه حاصل‌شدهِ کمیته نیز از طریق نماینده به اطلاع اعضای تیم می‌رسید.

در نظر گرفته شدن مصوبات کمیته‌ها به‌عنوان استاندارد: اصولاً اعضای کمیته برای ایجاد یک استاندارد دور هم جمع شده بودند، استانداردی که اولاً قابل‌اجرا باشد و ثانیاً در طول زمان بهبود پیدا کند.

 

مدیریت پروژه و منتور

در این پروژه از چارچوب اسکرام برای مدیریت پروژه استفاده می‌شد ولی نقش مدیریت پروژه بین سه نقش دیگر یعنی مالک محصول، اسکرام مسترها و مدیر فنی تقسیم شده بود. هر یک از این نقش‌ها، یک بخش از وظایف مدیر پروژه را بر عهده داشتند. مثلاً وظیفه مدیریت ذی‌نفعان پروژه و ارتباط با آن‌ها بر عهده مالک محصول بود، یا بحث‌های انگیزشی منابع انسانی بر عهده اسکرام مسترها بود.

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

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]چارچوب اسکرام: چارچوبی تکرارپذیر و افزایشی برای کنترل پروژه که معمولاً در زیرشاخه مدل فرآیند تولید نرم‌افزار چابک و سریع است و یک نوع مدل تولید نرم‌افزار در مهندسی نرم‌افزار به‌شمار می‌آید.[/mks_pullquote]

 

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

 

ساختارشکنی در محیط فیزیکی

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

البته این ساختار هم دردسرهایی داشت مثلاً سروصدای موجود در این فضای بزرگ که تمرکز را از بین می‌برد ولی تعامل و همکاری بالای نفرات تیم باعث می‌شد که سروصدا به‌عنوان یک مشکل تلقی نشود.

 

ساختار نیازمندی‌های محصول و WRS

پروژه از یک RFP شروع شد که اولین نسخه بک‌لاگ محصول تلقی می‌شد، اما هر تیم یک زیرمجموعه از بک‌لاگ کلی را داشت. مالک محصول به بک‌لاگ اصلی کارها را وارد می‌کرد و تیم‌ها از آن‌جا کار را وارد بک‌لاگ تیم خود می‌کردند.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]

بک‌لاگ

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

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

ساختار ماتریسی پیاده‌شده در شرکت اسپاتیفای

[/mks_pullquote]

 

با توجه به ساختار فنی پروژه همه ویژگی‌ها در قالب یک ویجت ارائه می‌شدند، یعنی ویژگی در قالب یک ویجت توصیف شد، پس یک سند استاندارد بین تحلیلگرها رواج پیدا کرد با عنوان WRS یا Widget Requirement Specification.

در ضمیمه داستان‌های کاربری که در بک‌لاگ موجود بود، معمولاً یک WRS استاندارد نیز بود. وجود چنین سند استانداردی باعث می‌شد یک زبان مشترک بین تحلیلگران و توسعه‌دهندگان ایجاد شود.

 

تیم‌ها به چه صورتی کار می‌کردند؟

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

در انتهای هر اسپرینت نیز جلسات دمو و بازنگری انجام می‌شود. در جلسات دمو معمولاً خود مالک محصول و دیگر ذی‌نفعان سیستم نیز حضور دارند. جلسات بازنگری برای هر تیم به‌صورت مستقل و با مدیریت اسکرام مسترهای هر گروه برگزار می‌شود؛ اما با توجه به وجود کمیته‌ها و جلسات هفتگی آن‌ها موارد بسیار کمی برای بررسی در جلسه بازنگری اسپرینت باقی می‌ماند و بعضی از تیم‌ها لزومی به برگزاری آن نمی‌دیدند.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]معماری مایکرو سرویس: در این معماری، برنامه سمت سرور به سرویس‌های مختلفی تقسیم می‌شود، مثلاً یک سرویس وظیفه پرداخت‌ها را به عهده دارد و دیگری به‌طور مستقل برای مدیریت حساب‌ها استفاده می‌شود.[/mks_pullquote]

 

ابعاد فنی

در اصول بیانیه چابک آمده است: «توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می‌شود.» کارشناسان می‌گویند بام از نظر فنی یکی از بهترین پروژه‌هاست. با طراحی سرویس‌گرا و حتی معماری مایکروسرویس، این امکان در پروژه به وجود آمده بود که تیم‌ها بدون وابستگی به هم بتوانند ویژگی‌ها یا ویجت‌ها را توسعه دهند و به‌تنهایی آن را منتشر کنند.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]اصول بیانیه چابک: این بیانیه سال 2001 توسط 17 استاد معتبر جهانی صنعت توسعه نرم‌افزار تنظیم شد. این بیانیه بر اساس 12 اصل تعریف شده و هدف آن ارائه نرم‌افزار کارا یا محصول کارا به مشتری است.[/mks_pullquote]

 

کسانی که در این‌گونه پروژه‌ها کار کرده‌اند می‌دانند وقتی چندین تیم روی یک سورس کار می‌کنند، زمانی که یک تیم نتواند ویژگی خود را در انتهای اسپرینت آماده کند، وابستگی‌های شدید پروژه باعث خواهد شد تیم‌های دیگر نیز با مشکل مواجه شوند؛ اما در این‌جا به دلیل طراحی مناسب، تیم‌ها قادر بودند به‌تنهایی و بدون وابستگی، ویجت خود را توسعه دهند و آن را منتشر کنند.

 

فرهنگ DevOps

یکی از مسائل شرکت‌های توسعه نرم‌افزار، جدا بودن واحد پشتیبانی از تیم توسعه است. تیم توسعه سعی در تولید کد بیشتر دارد و تلاش تیم پشتیبانی پایدار نگه داشتن وضعیت سیستم‌هاست. به همین دلیل معمولاً بین این تیم‌ها اختلاف به وجود می‌آید. در پروژه بام فرهنگ DevOps حاکم بود، یعنی دیوار بین تیم توسعه و پشتیبانی شکسته شد. تیم توسعه به پایداری سیستم‌ها اهمیت می‌داد و تیم پشتیبانی به فرآیند تند شدن تولید ویژگی‌ها.

به همین منظور روال خودکار شدن Build – Publish انجام شده است؛ یعنی کدهای داخل مخزن Git به‌راحتی توسط ابزار Jenkins Build می‌شود، تست‌ها پاس می‌شود و سپس محیط تست با نسخه جدید محصول به‌روزرسانی می‌شود.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]Git: یک نرم‌افزار آزاد و متن‌باز برای بازنگری کد منبع توزیع‌شده و مدیریت منبع کد است که روی سرعت تأکید می‌کند.[/mks_pullquote]

 

ارزش‌های و قوانین

نه به وابستگی: در جلسات برنامه‌ریزی، بیشترین تلاش می‌شود که وابستگی فراتیمی به حداقل خود برسد؛ یعنی هر تیم برای انجام کارهای خود به تیم‌های دیگر وابسته نشود. وجود وابستگی‌ها باعث کندی تیم‌ها و دست نیافتن به نتیجه مورد انتظار در انتهای اسپرینت می‌شود.

تجربه کاربری و طراحی کاربرپسند: با این‌که شرکت سداد پیمانکار محصول بام است، تیم‌های برنامه‌نویسی تأکید ویژه بر تجربه کاربری داشتند؛ یعنی شعار «ما می‌خواهیم بهترین بانکداری اینترنتی را داشته باشیم» حاصل نمی‌شود مگر با بررسی رفتار واقعی کاربر. به عبارتی در بام سعی شده است کاربر بهترین تجربه را داشته باشد و برای انجام فعالیت‌های بانکی خود سردرگم نشود.

برای همین در سیستم، قابلیت‌هایی برای پیگیری رفتار کاربر در نظر گرفته شده است تا با بررسی آن‌ها بتوان بهترین خدمات و ویژگی‌ها را برای آن‌ها توسعه داد.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]ژل شدن: بلوغ تیم و توانایی کار تیمی با بازده بالا[/mks_pullquote]

 

ثبات در چینش تیم‌ها: ثبات در چینش نفرات تیم‌ها باعث کمک به ژل شدن نفرات اعضای تیم شده است. تغییرات زیاد در نفرات تیم‌ها باعث از بین رفتن همگرایی آن‌ها می‌شود. برای همین یکی از تأکیدات در پروژه ثابت نگه داشتن اعضای تیم در طول اسپرینت‌های مختلف بود.

خرد جمعی بالاتر از ناهبم: «ناهبم» یا «نظر اونی که از همه بیشتر می‌گیره» در بسیاری از اوقات در این‌جا کاربردی نداشت. اصلاً وجود کمیته‌های مختلف برای دست یافتن به خرد جمعی بود. وقتی نظرات به ناهبم سپرده می‌شود، یکی از مشکلات معمولاً نفرمحور شدن پروژه‌ها است؛ یعنی گرفتن تمامی تصمیم‌ها بر عهده یک نفر خاص است و این امر، نخست باعث می‌شود فشار زیادی روی نفر وارد شود، دوم ریسک پروژه، با رفتن آن نفر از پروژه، بالا می‌رود و سوم، دیگر نفرات تیم احساس مسئولیت زیادی در قبال پروژه نمی‌کنند.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]ابزار اسلک: ابزاری ابری برای همکاری بین اعضای تیم است که سال 2013 راه‌اندازی شد. این اپلیکیشن امکان ایجاد گروهی از همکاران در دسته‌های مختلف برای تبادل‌نظر و به اشتراک گذاشتن فایل را فراهم می‌کند.[/mks_pullquote]

 

توجه مداوم به برتری فنی و طراحی خوب: با توجه به فرهنگ بهبود مداوم طراحی‌ها در اعضای تیم‌ها، ابزار اِسلَک به‌عنوان ابزار ارتباطات فراتیمی توسط اعضا انتخاب شد و با اشتراک‌گذاری مطالب مفید فنی به‌صورت مستمر و بحث و گفت‌وگو در خصوص تکنولوژی‌های نوظهور باعث افزایش روحیه و انرژی اعضا برای یادگیری شد.

ستاره؛ ابزار ترغیب روحیه تیمی: برای کل اعضای این پروژه ستاره‌های فیزیکی تهیه شد و برای هر نفر یک رنگ مشخص که در صورت رضایت از اقدام عضو دیگر پروژه به وی اعطا کند، این رضایت می‌توانست با ارزیابی شخصی فرد موردنظر به هر دلیلی اعطا شود مانند کمک در حل یک مشکل کاری، ارائه پیشنهاد خوب در طراحی، کمک در تسهیل وظایف محوله یا حتی برخورد خوب و انتقال انرژی مثبت.

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

 

محصول چگونه تست می‌شود؟

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

برخی تست‌ها هم تست‌های دستی توسط تحلیلگرها است. در طول اسپرینت هر توسعه‌دهنده که کارش روی ویژگی تمام شد، تحلیلگر مربوطه با استفاده از سند WRS اقدام به تست ویژگی می‌کند، اگر نتیجه کار درست بود، یک نسخه به دست واحد کنترل کیفیت می‌رسد.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]

ابزار Jenkins

Jenkins به تیم‌های نرم‌افزاری کمک می‌کند مراحل متعدد ساخت و ارزیابی کیفیت محصول را با هر تغییر در متن برنامه اجرا کنند.

[/mks_pullquote]

 

دوستان در کنترل کیفیت قبلاً با استفاده از همان WRS اقدام به نوشتن تست کیس کرده‌اند که با رسیدن کار برای تست، اقدام به تست تک‌تک تست کیس‌های خود می‌کنند. علاوه بر تست کیس‌های معمول، محصول از نظر مسائل امنیتی و دیگر مسائل کیفی که در قرارداد پروژه درج شده است، موردبررسی قرار می‌گیرد.

[mks_pullquote align=”left” width=”600″ size=”18″ bg_color=”#444444″ txt_color=”#ffffff”]تست کیس: در برنامه‌نویسی به نوشتن متدهایی برای آزمودن قسمت‌های پروژه به‌صورت جزءبه‌جزء گفته می‌شود. یک تست کیس با دادن متغیرها و به وجود آوردن شرایط واقعی برای متدهای عملیاتی پروژه باعث تحت آزمون قرار گرفتن متدها می‌شود و قابل‌اتکا بودن کد پروژه را می‌آزماید.[/mks_pullquote]

 

پس از تأیید این واحد، محصول قابل‌انتقال به محیط عملیاتی است که با نظر مالک محصول در زمان مناسب به این محیط منتقل می‌شود. کار انتقال نیز یک فرآیند زمان‌بر نیست و تنها با اجرای یک اسکریپت این کار انجام می‌شود.

 

گام بعدی چیست؟

مسلماً در پروژه بام، گام بعدی این است که با گرفتن بازخوردهای کاربران، اقدام به بهبود ویژگی‌های سیستم و تجربه کاربری شود؛ اما برای کل مجموعه سداد این تجربه گران‌بها، آغاز دورانی جدید است، دورانی که شاهد ارائه خدمات نوین و چابک‌تر از این مجموعه خواهیم بود.