(مالک محصول)
اسکرام متد چابکی است که به طور گسترده مورد استفاده قرار می گیرد و نقش مالک محصول در این متد به طور منحصر به فرد تعریف می شود. در اسکرام، مالک محصول وظیفه مشخص کردن و اولویت بندی نیازمندی های کاربر و همچنین نگهداری بک لاگ محصول را بر عهده دارد. با توجه به اصل بیانیه چابک«افراد کسب و کار و توسعه دهنده ها باید به طور روزانه در طول عمر پروژه با یکدیگر کار کنند»، با توجه به این اصل، مالک محصول به طور ایده آل در کنار تیم قرار دارد و به طور روزانه در فعالیت های آن ها مشارکت می کند.
(مجموعه ای از تیم های چابک)
در سازمان های بزرگ تیم های چابکِ بیشتری (سه تا ده تیم یا حتی بیشتر) برای تحویل ویژگی ها، سیستم ها یا زیرسیستم های بزرگ همکاری می کنند(سطح برنامه در تصویر کلان). تجربه نشان داده است که حتی برای سازمان های خیلی بزرگ نیز تقسیم بندی منطقی تیم ها به وسیله سیستم یا معماری محصول باعث شده است تا مجموعه ای از توسعه دهنده ها حول دامنه های پیاده سازی مختلفی سازماندهی شوند. این موضوع به این نکته اشاره می کند که شاید 50 تا 100 نفر برای ساختن «چیز بزرگ تر بعدی» خود که ما آن را «برنامه» می نامیم به شدت با یکدیگر همکاری کنند. همان طور که بعداً خواهیم دید، این موضوع در مورد اندازه بیشینه «برنامه ریزی انتشار» رو در رو و همکارانه نیز مطرح هست. احتمالا برای سازمان های بزرگ تر تعداد بیشتری از این «برنامه ها» وجود خواهد داشت که هر کدام از آن ها بر روی محصول مشخصی متمرکز هستند.
خط مقدم توسعه نرم افزار شامل تعدادی «تیم چابک» است که وظیفه پیاده سازی و آزمون کد را بر عهده دارند و برای ساختن سیستم های بزرگتر با یکدیگر همکاری می کنند. هر تیم چابک حداکثر دارای 5 تا 9 عضو است و شامل نقش هایی است که برای تعریف/ساخت/آزمون «ویژگی ها» و «اجزاء» نرم افزار ضروری هستند.نقش های موجود در تیم چابک شامل استاد اسکرام/چابک ، مالک محصول و تیم کوچکی از توسعه دهندگان آزمون گران، متخصصان آزمون خودکار و احتمالا رهبر فنی می باشد. تیم چابک در کار روزانه خود توسط معماران، منابع تضمین کیفیت خارجی، متخصصان مستندسازی، متخصصان پایگاه داده، پرسنل پشتیبانی مدیریت مخزن کد/ساخت/زیرساخت، تکنولوژی اطلاعات داخلی و ... پشتیبانی می شود تا با کمک آن ها بتواند بتواند به تعریف، توسعه، آزمون و تحویل نرم افزار قابل استفاده و آزمون شده بپردازد.
بسیاری از سازمان های نرم افزاری که دارای اندازه متوسط با صد یا بیش از صد کارمند هستند و آن هایی که یک یا دو محصول را توسعه و مدیریت می کنند، مدل تیم(شامل داستان های کاربر، وظیفه ها و آزمون های پذیرش) به اضافه مدل برنامه(شامل ویژگی ها و نیازمندهای غیرکارکردی) چیزهایی هستند که تیم برای مدیریت نیازمندی های سیستم به روش چابک نیاز دارد. در این شرایط، «هدایت نمودن انتشارها با چشم انداز ویژگی محور» و «هدایت نمودن تکرارها با داستان های ایجاد شده توسط تیم»، تمام آن چیزهایی است که تیم نیاز دارد. علاوه براین، سازمان هایی با رده دیگری وجود دارند که صدها تا هزاران کارمند را به کار گرفته و محصولات بسیار زیادی دارند. در این سازمان ها، مدل حکومتی و مدیریتی توسعه نرم افزار جدید نیازمند دستاوردها و سطح بالاتری از انتزاع است. در تصویر کلان، این سطح انتزاع همان «سبد محصول» است. در این سطح، در مورد ترکیبی از «تم های سرمایه گذاری» صحبت می کنیم که برای هدایت اولویت های سرمایه گذاری سازمان استفاده می شوند. مفهوم «تم های سرمایه گذاری» برای تضمین اینکه کار انجام شده کاری ضروری در جهت تحویل استراتژی کسب وکار سازمان است، مورد استفاده قرار می گیرند. تم های سرمایه گذاری چشم انداز سبد محصول را هدایت می کنند و به صورت مجموعه ای از «اپیک ها» بیان می شوند. به گونه ای که، در طول زمان به قطارهای انتشار مختلفی تخصیص داده می شوند.
در این سطح، کارکرد سیستم های با مقیاس بزرگ توسط چند تیم در «قطار انتشار چابک» توسعه داده می شود. قطار انتشار چابک ریتمی استاندارد از «تکرارها» و «نقاط عطف» زمان ثابت هست که در آن ها زمان و کیفیت ثابت، اما محدوده پروژه قابل تغییر است. قطار انتشار چابک، «انتشارها» یا «بخش های قابل عرضه» را به طور مکرر در زمان های حدودا 60 تا 120 روزه ایجاد می کند. بخش های قابل ارزیابی را می توان بر مبنای ظرفیت جذب محصول جدید توسط مشتری و رویدادهای خارجی موثر بر زمانبندی انتشار داد. در این سطح «مدیر محصول» وظیفه تعریف ویژگی ها را بر عهده دارد.
(تصویر کلان سازمان چابک)
پیاده سازی موثر مجموعه ای از اصول و تجارب نیازمندی های چابک و ناب در سطوح تیم، برنامه و یا سازمان با وجود ادبیات و زبان متفاوت در آن ها، شاهکار کوچکی نیست (داستان های کاربر، اسپرینت ها، امتیاز داستان، اپیک ها، بک لاگ؟). به علاوه، در ناب کردن سازمان ها اغلب نیازمند حذف یا کاهش مشخصات نیازمندی ها، مشخصات طراحی و مدل های مرحله-دروازه (که در آن نیازمندهای نرم افزار باید بازبینی شوند)، تایید سلسله مراتب سازمان (که باعث ایجاد تاخیر می شود)، پیاده سازی محدویت های کار در جریان (که ممکن است از دیدگاه افرادی که بهره وری را اندازه گیری می کنند تاثیر عکس داشته باشد) و ... هستیم. بنابراین، برای چابک و ناب کردن سازمان ها چالش های فراوانی وجود خواهد داشت.
حتی برای معرفی و پیاده سازی تجارب ابتدایی در سازمان، مدت زمانی در حدود شش ماه تا یک سال نیاز است. به طوری که برای بدست آوردن چندین نتیجه موفقیت آمیز که باعث ایجاد رضایت مشتریان، کسب درآمد و سهم بیشتری از بازار می گردد، به زمانی بیش از یک سال نیاز است. برای دستیابی به این مزایا، باید چیزهای زیادی از قبیل تجربه های مدیریت نیازمندی های قبلی تغییر کنند. هر چند، بسیاری از دستاوردهای الزامی موجود، نقاط عطف و ... به عنوان محافظی برای اجتناب از بروز انواع مسائلی که اغلب پروژه های نرم افزاری تجربه می کنند، مورد استفاده قرار می گیرد. بنابراین ما با معمای دشواری روبرو هستیم (چگونه بر روی این بند«بندی که بندباز در سیرک بر روی آن راه می رود» بدون داشتن تور ایمن حرکت کنیم و آن را تجربه نمایم، به طوری که خود این تور ایمن بخش اعظمی از مساله است؟)
خوشبختانه، در نقطه ای قرار داریم که تعدادی از سازمان ها این گذار را قبل از ما طی کرده اند و در این راستا چندین الگوی رایج برای موفقیت فرایند نرم افزار چابک و ناب ایجاد شده است. به دلیل بحث هایی که با تیم ها، مدیران و هیئت رئیسه در طول این گذار داریم، تلاش کردیم یک زبان مشترک که شامل مجموعه ای از مفاهیم انتزاعی و تصاویر گرافیکی مناسب است پیدا کنیم تا قادر به توصیف سریع موضوع «سازمان شما پس از تحول چابک شبیه چه چیزی می شود و چگونه کار می کند» باشیم. برای انجام این کار، نیازمند توصیف مکانیزم های جدیدی برای توسعه نرم افزار و فرایند تحویل، تیم های جدید، واحد های سازمانی و نقش هایی که افراد مهم در الگوی چابک جدید بازی می کنند، هستیم. نهایتا و با راهنمایی دیگران به چیزی رسیدم که در دستیابی به اهدافش به طرز معقولی خوب عمل می کند. ما آن را «تصویر کلان سازمان چابک» می نامیم. همان طوری که در شکل بالا قابل مشاهده است.