© تمامی حقوق این سایت برای دکتر محمد احمدزاده محفوظ است .
مدیریت چابک توانایی ایجاد و پاسخ به تغییر است. این راهی برای مقابله و در نهایت موفقیت در یک محیط نامطمئن و متلاطم است.
نویسندگان مانیفست چابک “چابک” را به عنوان برچسب برای کل این ایده انتخاب کردند زیرا این کلمه نشان دهنده سازگاری و واکنش به تغییر است که برای رویکرد آنها بسیار مهم بود .
این واقعاً به این فکر است که چگونه میتوانید بفهمید در محیطی که امروز در آن هستید چه میگذرد، شناسایی کنید که با چه عدم اطمینانی روبرو هستید، و بفهمید که چگونه میتوانید با آن سازگار شوید.
توسعه نرم افزار چابک فراتر از چارچوب هایی مانند Scrum ، Extreme Programming یا Feature-Driven Development (FDD) است.
توسعه نرمافزار چابک بیشتر از تمرینهایی مانند برنامهنویسی زوجی ، توسعه آزمایشمحور ، استندآپها ، جلسات برنامهریزی و دوی سرعت است.
توسعه نرمافزار چابک اصطلاحی فراگیر برای مجموعهای از چارچوبها و شیوههای مبتنی بر ارزشها و اصول بیانشده در Manifesto for Agile Software Development و 12 اصل پشت آن است. وقتی به روشی خاص به توسعه نرمافزار نزدیک میشوید، عموماً خوب است که بر اساس این ارزشها و اصول زندگی کنید و از آنها برای کمک به کشف کارهای درست با توجه به شرایط خاص خود استفاده کنید.
چیزی که Agile را از سایر رویکردهای توسعه نرم افزار جدا می کند، تمرکز بر افرادی است که کار را انجام می دهند و نحوه کار آنها با یکدیگر. راه حل ها از طریق همکاری بین تیم های متقابل خودسازماندهی با استفاده از شیوه های مناسب برای زمینه خود تکامل می یابند.
تمرکز زیادی در جامعه توسعه نرم افزار Agile بر روی همکاری و تیم خودسازماندهی وجود دارد.
مدیریت چابک یک رویکرد تکراری برای مدیریت پروژه و توسعه نرمافزار است که به تیم ها کمک میکند تا ارزش را سریعتر و با درد سر کمتری به مشتریان خود ارائه دهند. یک تیم چابک به جای اینکه همه چیز را روی یک پرتاب “بیگ بنگ” شرط بندی کند، کار را با تغییرات کوچک اما قابل مصرف ارائه می دهد.
در مدیریت چابک برنامه ها و نتایج به طور مداوم مورد ارزیابی قرار می گیرند تا تیم ها مکانیزم طبیعی برای واکنش سریع به تغییرات داشته باشند.
این بدان معنا نیست که مدیرانی وجود ندارند. این بدان معناست که تیمها این توانایی را دارند که بفهمند چگونه میخواهند خودشان به مسائل برخورد کنند.
این بدان معناست که آن تیم ها متقابل هستند. لازم نیست آن تیمها نقشهای خاصی داشته باشند، زیرا وقتی تیم را گرد هم میآورید، مطمئن میشوید که همه مجموعه مهارتهای مناسب را در تیم دارید.
هنوز جایی برای مدیران هست. مدیران مطمئن می شوند که اعضای تیم مجموعه مهارت های مناسبی را دارند یا به دست می آورند. مدیران محیطی را فراهم می کنند که به تیم اجازه می دهد تا موفق شود. مدیران عمدتاً عقبنشینی میکنند و به تیمشان اجازه میدهند بفهمند که چگونه محصولات را ارائه میکنند، اما زمانی وارد عمل میشوند که تیمها تلاش میکنند اما قادر به حل مشکلات نیستند.
هنگامی که اکثر تیم ها و سازمان ها شروع به توسعه Agile می کنند، روی روش هایی تمرکز می کنند که به همکاری و سازماندهی کار کمک می کند، که بسیار عالی است. با این حال، مجموعه کلیدی دیگری از شیوههایی که بهطور مکرر دنبال نمیشوند، اما باید رعایت شوند، شیوههای فنی خاصی هستند که مستقیماً با توسعه نرمافزار سروکار دارند، به گونهای که به تیم شما کمک میکند تا با عدم قطعیت مقابله کند. این اقدامات فنی ضروری هستند و چیزی که نباید نادیده بگیرید.
در اینجا نگاهی داریم به چگونگی ظهور Agile، چگونه برچسب Agile را به دست آورد، و از آنجا به کجا رسید. مهم است که نگاهی به توسعه نرم افزار Agile بیندازیم تا درک درستی از وضعیت امروز داشته باشیم.
در نهایت، چابک ذهنیتی است که از ارزش ها و اصول مانیفست چابک آگاه شده است. این ارزشها و اصول راهنمایی در مورد چگونگی ایجاد و واکنش به تغییر و نحوه برخورد با عدم قطعیت ارائه میکنند.
می توانید بگویید که اولین جمله مانیفست چابک کل این ایده را در بر می گیرد: “ما راه های بهتری برای توسعه نرم افزار با انجام آن و کمک به دیگران در انجام آن کشف می کنیم.”
وقتی با عدم قطعیت مواجه می شوید، چیزی را که فکر می کنید ممکن است کارساز باشد را امتحان کنید، بازخورد بگیرید و بر اساس آن تنظیم کنید.
هنگام انجام این کار، ارزش ها و اصول را در ذهن داشته باشید. اجازه دهید زمینه شما راهنمایی کند که از چه چارچوبها، شیوهها و تکنیکهایی برای همکاری با تیم خود و ارائه ارزش به مشتریان خود استفاده میکنید.
اگر Agile یک ذهنیت است، پس آن در مورد ایده روششناسی Agile چه میگوید؟ برای پاسخ به این سوال، ممکن است داشتن یک تعریف روشن از روش شناسی مفید باشد.
آلیستر کاکبرن پیشنهاد کرد که روش شناسی مجموعه ای از قراردادهایی است که یک تیم موافقت می کند از آنها پیروی کند. این بدان معناست که هر تیم متدولوژی مخصوص به خود را خواهد داشت، که در ابعاد کوچک یا بزرگ با روششناسی تیمهای دیگر متفاوت خواهد بود.
بنابراین متدولوژی های چابک قراردادهایی هستند که یک تیم برای پیروی از روشی انتخاب می کند که از ارزش ها و اصول چابک پیروی کند.
احتمالاً میگویید: «صبر کنید، من فکر میکردم Scrum و XP متدولوژیهای Agile هستند.» آلیستر اصطلاح چارچوب را برای آن مفاهیم به کار برد. آنها مطمئناً از متدولوژی یک تیم زاده شدهاند، اما زمانی که برای استفاده توسط تیمهای دیگر تعمیم داده شدند، به چارچوبهایی تبدیل شدند. این چارچوبها به شما کمک میکنند تا بفهمید یک تیم با روششناسی خود از کجا شروع میکند، اما آنها نباید متدولوژی تیم باشند. تیم همیشه باید استفاده خود از یک چارچوب را به گونه ای تطبیق دهد که به درستی در زمینه خود قرار گیرد.
با محبوبیت بیشتر Agile Software Development، افرادی که درگیر فعالیتهای توسعه نرمافزار بودند، اما شخصاً نرمافزار توسعه نمیدادند، به دنبال راهی بودند تا دریابند که این ایدههای Agile چگونه در خط کار خود کاربرد دارند.
Manifesto Agile و 12 Principles توسط گروهی از توسعه دهندگان نرم افزار (و یک آزمایش کننده) برای رسیدگی به مشکلاتی که توسعه دهندگان نرم افزار با آن مواجه بودند نوشته شده است. هنگامی که Agile را به عنوان یک ذهنیت در نظر می گیرید، این طرز فکر می تواند در سایر فعالیت ها نیز اعمال شود.
وقتی این کار را انجام می دهید، Agile به یک صفت تبدیل می شود. نحوه انجام برخی فعالیت ها را شرح می دهد. به دلایلی که در بالا توضیح داده شد، روش جدیدی ایجاد نمی کند.
وقتی میخواهید مدیریت پروژه Agile را درک کنید، بپرسید “چگونه میتوانیم مدیریت پروژه را به گونهای انجام دهیم که به ما اجازه ایجاد و پاسخ به تغییرات و مقابله با عدم قطعیت را بدهد؟” اتحاد چابک و موسسه مدیریت پروژه (PMI) این سوال را از طریق تلاش مشترک برای ایجاد راهنمای تمرین چابک (در دسترس اعضای اتحاد چابک) بررسی کردند.
وقتی میخواهید تحلیل کسبوکار چابک را درک کنید، بپرسید: «چگونه میتوانیم تحلیل کسبوکار را بهگونهای انجام دهیم که به ما امکان ایجاد تغییرات و واکنش به تغییرات و مقابله با عدم قطعیت را بدهد؟» اتحاد چابک و مؤسسه بینالمللی تجزیه و تحلیل کسبوکار (IIBA) این سؤال را از طریق تلاش مشترک برای ایجاد افزونه چابک برای مجموعه دانش تحلیل تجاری (در دسترس اعضای اتحادیه چابک) بررسی کردند.
دو مفهوم ذکر شده در بالا نمونههایی از تلاش برای حرکت Agile «خارج از نرمافزار» هستند. این تلاشها اخیراً به جنبش چابکی تجاری منجر شده است.
اگر ایده مدیریت چابک را به عنوان یک ذهنیت بسط دهید، آنگاه افرادی که به دنبال چابکی تجاری هستند از خود می پرسند: “چگونه می توانیم سازمان خود را به گونه ای ساختار و اداره کنیم که به ما امکان ایجاد و پاسخ به تغییرات و مقابله با عدم قطعیت را بدهد؟”
ممکن است بگویید چابکی کسب و کار تشخیص این است که برای اینکه افراد در یک سازمان با طرز فکر چابک کار کنند، کل سازمان باید از این طرز فکر حمایت کند. توسعه نرم افزار چابک هرگز واقعا چابک نبود تا زمانی که سازمان ساختار و عملیات خود را تغییر داد تا در یک محیط نامشخص کار کند.
امروزه سازمان ها دائماً به دنبال راه هایی برای همگام شدن با سرعت سریع تغییر فناوری و بازارهای در حال تحول هستند. و هنگامی که نام بازی سرعت است، تیم های توسعه باید بیشتر از همیشه چابک و انعطاف پذیر باشند.
اینجاست که متدولوژی مدیریت چابک Agile وارد می شود.
در ادامه بخوانید تا بیاموزید متدولوژی توسعه Agile چیست و چگونه میتواند به تیم شما کمک کند هر بار محصولات سریعتر، بهتر و قویتر ارائه دهد.
متدولوژی Agile توسط گروهی از توسعه دهندگان نرم افزار ایجاد شد که می خواستند رویکرد بهتری به فرآیند توسعه سنتی داشته باشند، که به نظر آنها بسیار پیچیده و با الزامات مستندسازی سنگین شده بود.
در یک سند تأسیسی به نام مانیفست چابک ، این گروه 4 ارزش و 12 اصل را که فلسفه چابک را هدایت میکنند، بیان کردند:
این ارزش ها با پاسخ به نیازهای مشتری و انطباق با تغییرات کارآمدتر، به هدایت فرآیند توسعه ای کمک می کند که محصولات با کیفیت و مشتریان راضی را به طور قابل اعتماد ارائه دهد.
این ارزشها و اصول Agile نشاندهنده فلسفهای است که میتواند (و شده است) در چارچوبها و روششناسیهای متعدد هم در توسعه نرمافزار و هم در سایر فرآیندهای مدیریت پروژه اعمال شود.
با پیروی از این ارزشها و اصول راهنما، ذهنیت چابک انعطافپذیری را در اولویت قرار میدهد و سازگاری را برای تغییر در یک محیط نامشخص امکانپذیر میسازد. این امر Agile را به یک فلسفه محبوب تبدیل میکند، زیرا به تیمها کمک میکند تا محصولات را سریعتر تحویل دهند و در عین حال نیازهای مشتری، کاربر و کسبوکار را بهتر برآورده کنند.
روش چابک به عنوان یک انتخاب برتر برای رهبران و توسعه دهندگان به طور یکسان شتاب زیادی به دست آورده است. و جای تعجب نیست که چرا.
در اینجا فقط چند مزیت کلیدی مدیریت پروژه Agile و توسعه Agile آورده شده است:
مشارکت و همکاری بیشتر ذینفعان
Agile درجه بالایی از ورودی و همکاری بین مشتری و تیم توسعه را تشویق می کند. این منجر به مشتریان راضیتر میشود، زیرا در طول فرآیند شفافیت وجود دارد و توسعهدهندگان بهتر از نیازها و خواستههای مشتری مطلع میشوند.
هزینه های قابل پیش بینی و برنامه ریزی
با تقسیم فرآیند توسعه به سرعتهای تکراری، مدیران پروژه میتوانند با دقت بیشتری هزینهها را تخمین بزنند و جدولهای زمانی واضح و قابل پیشبینی را تعیین کنند. این باعث خوشحالی ذینفعان می شود زیرا آنها می دانند که باید چه انتظاراتی داشته باشند و می توانند بودجه و استراتژی های بازاریابی را با دقت بیشتری برنامه ریزی کنند. همچنین فرآیند توسعه را برای تیمها آسانتر میکند، زیرا آنها میتوانند روی ارائه سریع و قابل اعتماد تمرکز کنند و نرمافزار را به طور منظم برای کیفیت و کارایی آزمایش کنند.
انعطاف پذیری در میان تغییرات
مدیریت پروژه چابک همه چیز در مورد چابک بودن است تا تیم ها بتوانند به سرعت با تغییرات سازگار شوند و در عین حال هزینه های غرق شده را کاهش دهند. Agile به تیم ها اجازه می دهد تا به دلیل تغییر نیازهای مشتری، تغییر در تقاضاهای بازار یا در پاسخ به نیازهای محصول در حال تحول، چرخش کنند. این به تیمها انعطافپذیری میدهد تا محصول عقب مانده را اصلاح و اولویتبندی کنند تا همیشه محصولات با کیفیت بالا و مرتبط را به موقع و با بودجه ارائه کنند.
محصولات با کیفیت بالاتر
توسعه محصول چابک آزمایش منظم را در فرآیند توسعه ادغام می کند. این کار باعث میشود مالک محصول زودتر هر مشکلی را شناسایی کند و در صورت نیاز تغییراتی را اعمال کند. نتیجه محصولات با کیفیت بالاتری است که مرتبط و به طور کامل بررسی شده اند.
کاهش ریسک و ROI سریعتر
چابک ریسک را کاهش می دهد زیرا به طور مرتب آزمایش می کند و امکان تغییر در اواسط رشد را فراهم می کند. با تکرار یک پروژه گام به گام (به جای حرکت رو به جلو با یک طرح سفت و سخت پروژه پایان به انتها)، تیم ها قادر به تولید محصولات قابل پیش بینی هستند. اگر آنها مشکلی را در اواسط پروژه کشف کنند، می توانند به سرعت مسیر را تنظیم کنند تا اینکه در پایان کل پروژه متوجه شوند که مشکلاتی وجود دارد.
علاوه بر این، از آنجایی که Agile بیشتر بر کاربر متمرکز است، تیم های Agile بر اساس داستان های کاربر، بازخورد آزمایش و ورودی مشتری در طول فرآیند تصمیم گیری می کنند. این تضمین می کند که هر ویژگی فقط یک جزء کاربردی فناوری اطلاعات نیست، بلکه یک محصول ارزشمند برای کاربران نهایی است.
این فرآیندها با هم ریسک را به حداقل میرسانند و به تیمها کمک میکنند تا ارزش را سریعتر ارائه دهند و در نتیجه بازگشت سرمایه سریعتر را به همراه داشته باشند.
6 مرحله چرخه حیات چابک وجود دارد:
اولین مرحله از روش چابک، تعیین محدوده و اولویت بندی پروژه ها است. با تیم و سهامداران خود بنشینید تا به طوفان فکری بپردازید و فرصت های تجاری را شناسایی کنید و زمان و هزینه های تکمیل هر پروژه را تخمین بزنید. سپس میتوانید تعیین کنید که کدام پروژهها قابل اجرا و با ارزشتر هستند و پروژههای عقب مانده خود را از آنجا اولویتبندی کنید.
هنگامی که می دانید پروژه شما چیست، گام بعدی این است که بفهمید چگونه آن را تکمیل می کنید. به چه کسانی در تیم خود نیاز دارید؟ نیازهای اولیه مشتری چیست؟ یک نمودار برای تعریف مسئولیت های تیم ایجاد کنید و کارهایی را که باید در هر دوی سرعت انجام دهید را مشخص کنید.
با تعریف و تایید پروژه اولیه شما، تیم توسعه می تواند روی اولین تکرار کار کند.
گردش کار اصلی در این مرحله شامل موارد زیر است:
پس از چندین بار تکرار، نوبت به عرضه محصول نهایی می رسد. در مرحله انتشار، تست نهایی و تضمین کیفیت را برای شناسایی هر گونه اشکال، رفع نقص، و نهایی کردن اسناد کاربر قبل از عرضه به تولید انجام خواهید داد.
محصول شما در جهان منتشر شد! مرحله تولید به این معنی است که ویژگی شما فعال است. از تیم خود بخواهید نظارت و پشتیبانی مستمری را ارائه دهد تا سیستم به خوبی کار کند و اطمینان حاصل شود که کاربران نحوه استفاده از آن را درک می کنند.
زمانی که سیستم شما قدیمی، غیر ضروری یا آماده جایگزینی است، وارد مرحله بازنشستگی می شود. این مرحله شامل تمام فعالیت های پایان عمر می شود، مانند اطلاع رسانی به مشتریان و انتقال سیستم به خارج از تولید.
Agile یک فلسفه راهنما است که می تواند در مدل های مختلف توسعه اعمال شود. در اینجا چهار مورد از محبوب ترین روش های Agile آورده شده است:
اسکرام یک چارچوب چابک است که بر کار تیمی متقابل، مسئولیت پذیری و تکرار به منظور توسعه، ارائه و پشتیبانی از محصولات پیچیده تمرکز دارد. در درجه اول برای توسعه نرم افزار استفاده می شود، اما اصول آن را می توان در سایر تیم های مدیریت پروژه نیز اعمال کرد.
چارچوب اسکرام در نقش ها، رویدادها و مصنوعات کلیدی سازماندهی شده است:
نقش های اسکرام:
رویدادهای اسکرام:
مصنوعات اسکرام:
تیم های اسکرام از ابزارهایی مانند تابلوهای وظیفه اسکرام برای کمک به سازماندهی وظایف و اسپرینت ها برای کمک به اعضای تیم برای تجسم وضعیت فعلی پروژه ها استفاده می کنند.
Kanban یک مدل چابک است که برای کمک به تیم ها برای همکاری موثرتر با یکدیگر طراحی شده است. از سه اصل راهنما پیروی می کند:
برخلاف اسکرام، کانبان نقش های تجویز شده یا سرعت های زمان بندی شده ندارد. در عوض، کانبان بر چرخههای کوتاهتر برای تحویل سریعتر و شفافیت در طول توسعه تمرکز میکند تا همه بفهمند چه کسی مسئول چه چیزی و چه زمانی است.
ابزارهایی مانند هیئت مدیره Kanban آنلاین به اعضای تیم این فرصت را می دهد که با ایده ها همکاری کنند، وضعیت وظایف را تغییر دهند و پیشرفت خود را پیگیری کنند تا همه با هم کارآمدتر و مؤثرتر کار کنند.
تجسم فرآیند به همه کمک میکند تا در همان صفحه باقی بمانند و اطمینان حاصل شود که تلاشها بر روی کارهایی متمرکز میشود که دارای اولویت و تأثیر بالا هستند.
XP خاص ترین فریم ورک Agile برای شیوه های توسعه نرم افزار است. هدف آن نه تنها تولید نرمافزار با کیفیت بالا، بلکه آسانتر کردن کل فرآیند برای خود تیم توسعه است. XP برای ارتباط، بازخورد، سادگی، شجاعت و احترام ارزش قائل است.
بهترین زمان استفاده از آن زمانی است
توسعه ویژگی محور (FDD) یک ابزار متدولوژی چابک مشتری محور است که بر توسعه تدریجی و گزارش وضعیت در همه سطوح تمرکز دارد. این رویکرد به جلوگیری از دو مورد از بزرگترین موانع در توسعه نرم افزار کمک می کند: سردرگمی و دوباره کاری.
FDD پنج مرحله اساسی را دنبال می کند:
FDD یک مدل مقیاس پذیر است که ویژگی ها را در بازه زمانی بسیار کوتاه تری نسبت به سایر فریم ورک های Agile ارائه می دهد. به عنوان مثال، به جای یک چرخه تکرار معمولی 4 هفته ای در Scrum، FDD قصد دارد هر 2 تا 10 روز یک بار ویژگی ها را ارائه دهد. این امر باعث میشود تیمها ردیابی و رسیدگی به خطاها، سازگاری با درخواستهای مشتری و بهروزرسانی سریع اعضای تیم جدید را آسانتر کنند.
نکته مهم در مورد Agile این است که بیشتر یک دستورالعمل است تا یک قانون واقعی. بنابراین از هر روشی که پیروی میکنید، مطمئن شوید که نیازهای تیم و مشتریان شما را برآورده میکند. به هر حال، هدف Agile این است که به تیم ها کمک کند تا کار بهتر و سریعتر ارائه دهند. بنابراین آنچه را که برای شما بهتر است پیدا کنید و با آن بدوید.
تحت یک مدل DevOps، تیمهای توسعه و عملیات دیگر «Siloed» نیستند. گاهی اوقات، این دو تیم در یک تیم واحد ادغام می شوند که در آن مهندسان در کل چرخه عمر برنامه، از توسعه و آزمایش گرفته تا استقرار تا عملیات، کار می کنند و طیف وسیعی از مهارت ها را توسعه می دهند که محدود به یک عملکرد واحد نیست.
در برخی از مدلهای DevOps، تیمهای تضمین کیفیت و امنیت نیز ممکن است به شدت با توسعه و عملیات و در طول چرخه عمر برنامه یکپارچه شوند. هنگامی که امنیت تمرکز همه در یک تیم DevOps است، گاهی اوقات به آن DevSecOps می گویند.
این تیمها از شیوههایی برای خودکارسازی فرآیندهایی استفاده میکنند که از لحاظ تاریخی دستی و کند بودهاند. آنها از پشته فناوری و ابزارهایی استفاده می کنند که به آنها کمک می کند تا برنامه ها را سریع و قابل اعتماد اجرا کنند و تکامل دهند. این ابزارها همچنین به مهندسان کمک میکنند تا به طور مستقل وظایفی را انجام دهند (مثلاً استقرار کد یا زیرساختهای تامین) که معمولاً به کمک سایر تیمها نیاز دارند و این باعث افزایش سرعت تیم میشود.
در حالی که مدیریت چابک جدید نیست، زیرا از اوایل دهه 2000 استفاده شده است، بسیاری از سازمان ها به تازگی شروع به استفاده از این رویکرد تحویل برای پروژه های حیاتی کرده اند. دیگر میدریت چابک به عنوان “رویکرد جدید جالبی برای آزمایش و آزمایش روی پروژه های غیر مهم” در نظر گرفته نمی شود.
بنابراین، چه چیزی در آن برای شما؟ مقدار زیادی. این یک فرصت عالی برای پذیرش یک رویکرد تحویل “جدید” است و به همه نشان می دهد که در مورد تکنیک های مدیریت پروژه پیشرو و فعلی هستید. چگونه می توانید در این گروه موسیقی سوار شوید؟ شروع به خواندن و مطالعه کنید! در اینجا، در CBT Nuggets ما چندین دوره آموزشی داریم که می تواند به شما کمک کند در مسیر چابک حرکت کنید.
در اینجا پنج دلیل اصلی من برای استفاده از مدیریت چابک آورده شده است:
برای چابک شدن آماده اید؟ عالی! این یک سفر هیجان انگیز و پر ارزش است که مطمئنم از آن لذت خواهید برد.