پیش‌نویس:چارچوب گسترش‌یافته چابک
چارچوب گسترش یافته چابک (به اختصار SAFe ) مجموعه ای از الگوهای سازمانی و جریان‌کاری است که برای هدایت شرکت‌ها در مقیاس های کوچک و چابک در نظر گرفته شده است. [۱] [۲] درکنار روش هایی مانند: Scrum در مقیاس بزرگ (LeSS) ، تحویل نظم و انضباط چابک (DAD) و Nexus ،چارچوب گسترش یافته چابک(SAFe) یکی از چارچوب های روبه رشدی است که درصدد برطرف کردن مشکلات پیش آمده در هنگام توسعه دادن یک تیم است. [۳] [۴] SAFe توسط شرکت Scaled Agile ، که قوانین حق نشر و علائم تجاری ثبت شده را حفظ می کند، به صورت آزاد(رایگان) ساخته شده است. [۵]
SAFe هماهنگی ، همکاری و تحویل تعداد زیادی از تیم‌های چابک را ارتقا می بخشد. این روش توسط متخصصان و با استفاده از سه بدنه اصلی دانش توسعه یافته است: توسعه نرم افزار چابک ، توسعه محصول‌های کوچک و تفکر سیستمی[۶].
ریشه اولیه چارچوب گسترش یافته چابک در ابتدا به صورت توسعه‌ی ایجاد یک تصور بزرگ(دورنما) در مورد چگونگی پیشرفتن کار ناشی از مدیریت محصول (یا سایر ذینفعان ) از طریق مدیریت ، برنامه و تیم های توسعه به مشتریان بود ، [۷] [۸] که با همکاری دیگران در جامعه چابک ، این روند به تدریج بهبود داده شد و سپس به طور رسمی ابتدا در یک کتاب در سال 2007 توضیح داده شده بود. [۹] این چارچوب همچنان به طور عمومی توسعه و به اشتراک گذاشته می شود. با یک آکادمی و یک طرح اعتباربخشی ، از کسانی که به دنبال پیاده سازی ، پشتیبانی یا آموزش دیگران در استفاده و پذیرش SAFe هستند ، پشتیبانی کند. نسخه 4.5 ، در ژوئن سال 2017 منتشر شد [۱۰] در حالی که آخرین نسخه ، نسخه 4.6 ، در اکتبر 2018 منتشر شده است. [۱۱]
در حالی که SAFe همچنان به عنوان متداولترین رویکرد جهت گسترش دادن رویه های چابک (با 30 درصد و در حال رشد) شناخته می شود ، [۱۲] [۱۳] [۱۴] ،با این وجود به این روش این ایراد وارد است که بیش از حد سلسله مراتبی و انعطاف ناپذیری است. [۱۵]
چالش های گسترش‌دادن اصول و روش های چالاک[ویرایش]
مقابله با چشم‌انداز(دورنما) برنامه ریزی بلندمدت‌تر[ویرایش]
تیم های توسعه معمولاً میزان کارهای انباشه شده خود را تا دو یا سه دوره(چرخه) در آینده تصحیح می کنند ، اما در سازمان های بزرگتر تیم بازاریابی محصول نیاز دارد تا برای تعهدات خود در زمینه بازار و بحث و گفتگو با مشتریان ، برنامه ریزی بیشتری انجام دهد. [۱۶] آنها غالباً با طرح‌های بسیار سطح بالا ، 12 تا 18 ماه از مسیری که باید طی شود، کار خواهند کرد ، سپس برای سه ماه کار با تیم ها همکاری می کنند. [۱۷] تیم های توسعه همچنان برای 2-3 دوره(چرخه)ای که در پیش رو دارند جزییات را تصحیح می کنند و فقط درمورد وظایف برای دوره بعدی وارد جزییات می‌شوند. [۱۸]
چابک نگه داشتن در سطوح انتزاعی مسئولیت[ویرایش]
در حالی که تیم های توسعه تعدادی چارچوب دارند که چگونگی چابک بودن آنها را تعیین می کنند ، اما چارچوبی که این کارها را برای مدیریت توصیف کند بسیار کم است. SAFe بسیاری از همان اصول ، مانند تیم های متقابل عملکردی را به گروه هایی تحویل می دهد که سطوح انتزاعی تر از مسئولیت و برنامه ریزی (محصول و نمونه کارها) را بر عهده دارند. [۱۹] SAFe همچنین به دلیل تجمع بیش از حد بسیاری از اقدامات ناسازگار مورد انتقاد قرار گرفته است. [۲۰]
برخورد با مرجع تفویض شده[ویرایش]
در اسکرام ، از صاحب محصول انتظار می رود که مسئولیت چرخه کامل محصول(طول عمر محصول) ، شامل بازده سرمایه گذاری تصمیمات توسعه و همچنین عملکرد در بازار را بر عهده بگیرد. در مورد تحولات در ابعاد بزرگ ، سازمان می‌خواهد که یک دید ای در مورد کارهای عقب افتاده(انبارشده ) در تیم های مختلف ، که برای مثال توسط یک مدیر محصول ارائه می‌شود را داشته باشد. [۲۱] اگرچه SAFe فرض می کند که نقش صاحب محصول با مدیریت محصول یکسان و منطبق است ، اما با این وجود به دلیل جدایی صاحبان محصول در سازمان توسعه مورد انتقاد قرار گرفته است. [۲۲]
تحویل همزمان[ویرایش]
چارچوب های چابک به گونه ای طراحی شده اند که تیم‌های توسعه دهنده بتواند خودمختار و آزاد باشد تا بتواند نحوه و چگونگی کار خود را طراحی کند. SAFe اذعان می کند که ، در اندازه‌های ده‌ها یا صدها تیم توسعه دهنده، تیم ها کاملاً آشفته و بی‌نظم خواهند شد. [۲۳] بنابراین برخی از محدودیت ها را در این نوع موارد اعمال می کند ، به طوری که در مواردی که تیم ها روی یک محصول یکسان کار می کنند ، می توان تحویل ها(کارهای انجام شده)ی آنها را برای جمع آوری بهتر هماهنگ کرد ، اگرچه این یکی از حوزه هایی است که SAFe مورد انتقاد قرار گرفته است. [۲۱] [۲۲]
زمان کافی برای نوآوری و برنامه ریزی[ویرایش]
چرخه برنامه ریزی SAFe توصیه می کند که یک دوره(چرخه) اضافی بعد از انتشار نیز داشته باشد ، تا تیم ها بتوانند کارها و وظایف محول شده خود را بهبود ببخشند و برای برنامه ریزی و طرح ریزی دوره بعدی آماده شوند. نسخه های اولیه SAFe نیز این کار را به عنوان یک دوره تثبیت کننده ، یعنی تثبیت یا سخت تر کردن محصول قبل از انتشار آن ، طراحی کرده بودند. این در مورد عوارض کار با محیط هایی که میزان سرهم‌سازی(یک‌پارچگی) آنها در ابعاد بزرگ است پیش بینی شده بود و این که وابستگی به این معنی است که شما نمی توانید همه چیز را تا انتها تست کنید. SAFe ببه دلیل آن که یک روش ضد چابک یا روش آبشاری محسوب می شود ، مورد انتقاد قرار گرفته است. [۲۴] این در ویرایش‌های اخیر SAFe گنجانده نشده است.
پیاده سازی[ویرایش]
اصول اساسی SAFe[ویرایش]
به گفته نویسندگان آن ، SAFe بر پایه نه مفهوم اساسی بنا شده است که از اصول کوچک و چابک(سریع) موجود و همچنین مشاهده برگرفته شده است: [۲۵]
- نگاه اقتصادی داشته باشید
- تفکر سیستمی را اعمال کنید
- تنوع را نیز در نظر بگیرید; گزینه‌ها را حفظ کنید
- با چرخه های یادگیری سریع یکپارچه بصورت تدریجی بسازید
- نقاط عطف پایه در ارزیابی عینی سیستم های کاری
- در حال پیشرفت کار را تجسم و محدود کنید ، اندازه های دسته ای را کاهش داده و طول صف را مدیریت کنید
- اعمال کادر (زمان بندی) ، هماهنگ سازی با برنامه ریزی متقابل دامنه
- انگیزه ذاتی کارگران دانش را باز کنید
- تصمیم گیری به صورت غیر متمرکز
چارچوب SAFe[ویرایش]
در نسخه SAFe 4.5 ، چهار حالت تنظیم وجود دارد: حالت ضروری ، نمونه کارها ، راه حل بزرگ و کامل: [۲۶]
- SAFe ضروری اساسی ترین تنظیمات است. این مهمترین عناصر مورد نیاز را توصیف می کند و هدف آن ارائه اکثر مزایای این چارچوب است. این شامل سطح تیم و برنامه است (که آن را قطار آزاد سازی چابک یا ART می نامند).
- نمونه کارها SAFe شامل نگرانی هایی در مورد جهت استراتژیک ، بودجه سرمایه گذاری و حاکمیت لاغر است.
- راه حل بزرگ SAFe امکان هماهنگی و همگام سازی را در چندین برنامه فراهم می کند ، اما بدون ملاحظات نمونه کارها. در نسخه های اولیه SAFe ، این سطح به عنوان جریان ارزش گفته می شود .
- SAFe کامل سه سطح دیگر را ترکیب می کند.
گواهینامه ها[ویرایش]
چابک گسترش پذیر گواهینامه هایی که حوزه های مختلف و سطح‌های مختلف دانش را شامل می شود. [۲۷]
همچنین ببینید[ویرایش]
منابع[ویرایش]
- ↑ Hayes, Will; Lapham, Mary Ann; Miller, Suzanne; Wrubel, Eileen; Capell, Peter (2016). Scaling Agile Methods for Department of Defense Programs. Software Engineering Institute. CMU/SEI-2016-TN-005.
- ↑ Athrow, Desiree (29 January 2015). "Why Continuous Delivery is key to speeding up software development". TechRadar. Retrieved 2017-11-27.
- ↑ Linders, Ben (January 22, 2015). "Scaling Agile with the Disciplined Agile Delivery Framework". InfoQ. Retrieved 2017-11-27.
- ↑ van Haaster, K (2014). Agile in-the-large: Getting from Paradox to Paradigm. Unpublished paper from Charles Sturt University.
- ↑ "Permissions FAQ". Scaled Agile. Retrieved 13 July 2018.
- ↑ "چارچوب چابک مقیاس". ویکی‌پدیا، دانشنامهٔ آزاد. 2019-06-01.
- ↑ Bridgwater, Adrian (August 7, 2013). "Real Agile Means Everybody Is Agile". Dr. Dobb's. Retrieved 2017-11-27.
- ↑ Linders, Ben (August 28, 2014). "Death by Planning in Agile Adoption". InfoQ. Retrieved 2017-11-27.
- ↑ Leffingwell, Dean (2007). Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley. ISBN 978-0321458193.
- ↑ Cleveland, Regina. "Scaled Agile, Inc. Releases SAFe® 4.5". prweb.com. Retrieved 2017-09-11.
- ↑ "Welcome to SAFe 4.6 for Lean Enterprises". Retrieved 2019-01-30.
- ↑ "13th Annual State of Agile Report". State of Agile Survey. CollabNet VersionOne. 2019. Retrieved 2019-08-27.
- ↑ Link, P; Lewrick, M (29 September 2014). "Agile Methods in a New Area of Innovation Management" (PDF). Science to Business Marketing Conference.
- ↑ Baptista, Roberto (28 January 2015). "Profissionais brasileiros e o interesse por treinamentos de especialização". Computerworld Brazil. Retrieved 28 January 2015.
- ↑ Schwaber, Ken (2013-08-06). "unSAFe at any speed". Telling It Like It Is. Retrieved 2017-11-11.
- ↑ Eklund, U; Olsson, H; Strøm, N (2014). Industrial challenges of scaling agile in mass-produced embedded systems. Agile Methods. Large-Scale Development, Refactoring, Testing, and Estimation. Springer International Publishing. ISBN 9783319143583.
- ↑ Heusser, Matt (23 September 2014). "Agile testing methods for multiple teams". SearchSoftwareQuality. Retrieved 2017-11-27.
- ↑ Stettina, C; Horz, J (2015). "Agile portfolio management: An empirical perspective on the practice in use". International Journal of Project Management. 33 (1): 140–152.
- ↑ Laanti, M (2014). Characteristics and Principles of Scaled Agile. XP 2014 Workshops. Springer International Publishing.
- ↑ Elssamadisy, Amr. "Has SAFe Cracked the Large Agile Adoption Nut?". InfoQ. Retrieved 2017-11-11.
- ↑ ۲۱٫۰ ۲۱٫۱ Vaidya, A (2014). Does DAD Know Best, Is it Better to do LeSS or Just be SAFe? Adapting Scaling Agile Practices into the Enterprise. Excerpt from PNSQC 2014 Proceedings. pp. 8–9.
- ↑ ۲۲٫۰ ۲۲٫۱ Maximini, Dominik (11 September 2013). "A critical view on SAFe - Scrumorakel - Blog". Scrum Oracle. Retrieved 2017-11-27.
- ↑ Stafford, Jan (December 9, 2013). "Scaling Agile development calls for defined practices, consultant says". SearchSoftwareQuality. Retrieved 2017-11-27.
- ↑ Killick, Neil (21 March 2012). "The Horror Of The Scaled Agile Framework". Agile, Scrum, Kanban, Lean, and everything that's in between. Retrieved 2017-11-27.
- ↑ "SAFe Lean-Agile Principles". Retrieved 19 February 2016.
- ↑ Rose, Doug (2018). Enterprise Agility For Dummies (به انگلیسی). John Wiley & Sons. pp. 87–89. ISBN 9781119446095.
- ↑ "Certification". Scaled Agile. Retrieved 19 February 2016.
خواندن بیشتر[ویرایش]
- Heusser, Matthew (17 June 2015), Introducing the scaled agile framework, CIO, pp. 1–2 — contains a review of the pros and cons of the methodology and concludes it is a half-way-house to a fully agile system.
- Leffingwell, Dean (2011), Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley Professional, ISBN 978-0321635846
- Linders, Ben (15 January 2015), Lean and Agile Leadership with the Scaled Agile Framework (SAFe), InfoQ