چارچوب گسترش‌یافته چابک
چارچوب گسترش یافته چابک (به اختصار 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.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Athrow, Desiree (29 January 2015). "Why Continuous Delivery is key to speeding up software development". TechRadar. Retrieved 2017-11-27.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Linders, Ben (January 22, 2015). "Scaling Agile with the Disciplined Agile Delivery Framework". InfoQ. Retrieved 2017-11-27.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ van Haaster, K (2014). Agile in-the-large: Getting from Paradox to Paradigm. Unpublished paper from Charles Sturt University.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ "Permissions FAQ". Scaled Agile. Retrieved 13 July 2018.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ "چارچوب چابک مقیاس". ویکی‌پدیا، دانشنامهٔ آزاد. 2019-06-01.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Bridgwater, Adrian (August 7, 2013). "Real Agile Means Everybody Is Agile". Dr. Dobb's. Retrieved 2017-11-27.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Linders, Ben (August 28, 2014). "Death by Planning in Agile Adoption". InfoQ. Retrieved 2017-11-27.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Leffingwell, Dean (2007). Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley. ISBN 978-0321458193.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Cleveland, Regina. "Scaled Agile, Inc. Releases SAFe® 4.5". prweb.com. Retrieved 2017-09-11.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ "Welcome to SAFe 4.6 for Lean Enterprises". Retrieved 2019-01-30.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ "13th Annual State of Agile Report". State of Agile Survey. CollabNet VersionOne. 2019. Retrieved 2019-08-27.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Link, P; Lewrick, M (29 September 2014). "Agile Methods in a New Area of Innovation Management" (PDF). Science to Business Marketing Conference.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Baptista, Roberto (28 January 2015). "Profissionais brasileiros e o interesse por treinamentos de especialização". Computerworld Brazil. Retrieved 28 January 2015.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Schwaber, Ken (2013-08-06). "unSAFe at any speed". Telling It Like It Is. Retrieved 2017-11-11.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ 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.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Heusser, Matt (23 September 2014). "Agile testing methods for multiple teams". SearchSoftwareQuality. Retrieved 2017-11-27.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ 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.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Laanti, M (2014). Characteristics and Principles of Scaled Agile. XP 2014 Workshops. Springer International Publishing.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Elssamadisy, Amr. "Has SAFe Cracked the Large Agile Adoption Nut?". InfoQ. Retrieved 2017-11-11.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ ۲۱٫۰ ۲۱٫۱ 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.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ ۲۲٫۰ ۲۲٫۱ Maximini, Dominik (11 September 2013). "A critical view on SAFe - Scrumorakel - Blog". Scrum Oracle. Retrieved 2017-11-27.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Stafford, Jan (December 9, 2013). "Scaling Agile development calls for defined practices, consultant says". SearchSoftwareQuality. Retrieved 2017-11-27.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ 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.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ "SAFe Lean-Agile Principles". Retrieved 19 February 2016.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Rose, Doug (2018). Enterprise Agility For Dummies (به English). John Wiley & Sons. pp. 87–89. ISBN 9781119446095.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ "Certification". Scaled Agile. Retrieved 19 February 2016.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
خواندن بیشتر[ویرایش]
- Heusser, Matthew (17 June 2015), Introducing the scaled agile framework, CIO, pp. 1–2صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد. — 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صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- Linders, Ben (15 January 2015), Lean and Agile Leadership with the Scaled Agile Framework (SAFe), InfoQصفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
لینک‌های اضافی[ویرایش]
This article "چارچوب گسترش‌یافته چابک" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:چارچوب گسترش‌یافته چابک. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.
