اجایل چیست؟ – راهنمای کامل متدولوژی Agile – به زبان ساده
وقتی کلمه «چابک» به گوشتان میخورد، با خود چه فکری میکنید؟ ممکن است کلماتی مانند «انعطافپذیری» و «تطبیقپذیری» در ذهن متبادر شوند. تیمهای چابک یا اجایل (Agile) هم بهگونهای طراحی شدهاند که سریع عمل کرده و بدون هیچ مشکل، خودشان را با تغییرات تطبیق میدهند. به همین خاطر هم هست که روششناسی اجایل به یکی از رویکردهای محبوب مدیران پروژه تبدیل شده. طی دو دهه اخیر، بسیاری از شرکتها دریافتهاند که رویکردهای سنتی دیگر نیازهای جهان مدرن را پوشش نمیدهند. درحالی که روششناسی «آبشاری» دیگر به خوبی قبل جواب نمیداد، بسیاری به سراغ رویکرد اجایل رفتهاند. اما اصلا اجایل چیست و به درد کدام شرکتها میخورد؟
باید این نکته را در نظر داشت که تنها غولهای تکنولوژی نیستند که از این رویکرد انعطافپذیر نفع میبرند. شرکتهای گوناگون در صنایع مختلف متوجه پتانسیلهای مدیریت چابک شدهاند تا بتوانند در برهههای زمانی کوتاه، شرایط را در بازار زیر و رو کنند. در این مقاله قصد داریم به شکلی مفصل از این بگوییم که اجایل چیست، چه قواعد و ارزشهایی را دنبال میکند و چه مزایا و معایبی در مدیریت پروژه به همراه میآورد. از سوی دیگر، نگاهی دقیقتر به نحوه کارکرد تیمهای اجایل و روشهای مورد استفاده از سوی آنها میاندازیم. در نهایت نیز نحوه ساخت اپیکها، یوزر استوریها و استوری پوینتها را فرا خواهید گرفت.
مانیفست یا بیانیه اجایل چیست؟
بیانیه اجایل (Agile Manifesto)، سندی است که ارزشها و قواعد مرکزی توسعه محصول چابک را تشریح میکند. این سند که به صورت رسمی تحت عنوان «مانیفستی برای توسعه نرمافزار چابک» شناخته میشود، مدلی موثر را به تیمها میشناساند که با بهرهگیری از آن و تطبیق یافتن با فلسفههای مدیریت پروژه اجایل، قادر به بهبود فرایندهای کاری خود خواهند بود.
چارچوب سبک و شستهرفتهای که در مانیفست اجایل ترسیم میشود، به گونهای طراحی شده که فرایندهای پیشین توسعه نرمافزار را که پیچیدهتر و نیازمند انبوهی سندسازی بودند، بهبود میدهد. خالقین این رویکرد میخواستند به فرایندها سرعت ببخشند و یک مدل کاری بهینهتر برای تیمهای مختلف تدارک ببینند. در نهایت اگر بخواهیم به شکلی ساده بگوییم، مانیفست اجایل یک جایگزین برای روشهای سنتی توسعه نرمافزار است.
چه کسی بیانیه اجایل را نوشت؟
مانیفست اجایل در ماه فوریه سال ۲۰۰۱ میلادی و در یک پیست اسکی در ایالت یوتا شکل گرفت. ۱۷ نماینده با پسزمینههای شغلی در حوزه برنامهنویسی و توسعه گرد هم آمدند تا تصمیم بگیرند که روششناسی اجایل چیست و راهکارهایی تازه برای فرایندهایی قدیمی بیابند که در گذر زمان، ناامیدکننده ظاهر شده بودند. عقیده کلی بر اینست که با امضا شدن بیانیه اجایل، نویسندگان این مانیفست اساسا دنیای توسعه نرمافزار را دگرگون کردند.
این گروه از افراد بعدا تحت عنوان «ائتلاف اجایل» (Agile Alliance) شناخته شدند. بعد از عرضه بیانیه اجایل، این ائتلاف به شکل یا سازمان بینالمللی و غیر انتفاعی درآمد، سازمانی که اکنون بیش از ۷۲ هزار عضو در سراسر جهان دارد. Agile Alliance اکنون کنفرانسهایی را به صورت سالانه برگزار کرده و در صدد پشتیبانی از گروههای محلی برمیآید.
اکنون که این مقاله را میخوانید، بیش از دو دهه از زمان تولد مانیفست اجایل میگذرد. در این مدت، تیمهایی که در اقصی نقاط جهان فعالیت میکنند، همگی به پیروی از ۴ ارزش و ۱۲ اصلی که در بیانیه آمده مشغول شدهاند. بنابر چهاردهمین گزارش سالانه وضعیت اجایل، بیش از ۹۵ درصد از شرکتکنندگان در نظرسنجی تایید میکند که سازمانشان به سراغ روشهای توسعه محصول چابک رفته است. اگرچه بیانیه اجایل در اصل برای جامعه توسعه نرمافزار طراحی شده بود، اما اکنون به منبعی کلیدی برای هرجور پروژهای که بتوان تصور کرد، تبدیل شده است. در گزارش وضعیت اجایل آمده که اکنون در حوزه فناوری اطلاعات، بازاریابی، منابع انسانی و فروش هم به اصول اجایل توجه میشود.
اما این رویکردهای برتری که در بیانیه اجایل آمدهاند چه شمایلی دارند؟ بیایید از نزدیکتر ببینیم که ارزشها و قواعد اجایل چیست.
ارزشها در بیانیه اجایل
بیانیه اجایل بر مبنای ۴ ارزش کلیدی تهیه شده که در ادامه به بررسی آنها میپردازیم:
۱. اشخاص و تعاملات در جایگاهی بالاتر از فرایندها و ابزارها
نخستین ارزش، ماهیت غایی روششناسی اجایل را به خوبی نشان میدهد: تمرکز باید بر انسانها باشد. میتوانید از بهترین فرایندها و ابزارهای در دسترس برای پیشبرد پروژه خود استفاده کنید، اما این کار تنها زمانی به ثمر مینشیند که انسانها بهترین عملکرد خود را به نمایش بگذارند. تیم شما، ارزشمندترین چیزی است که در اختیار دارید. ارتباطات موثر هم نقشی کلیدی در اینجا ایفا میکنند: در واقع وقتی انسانها به تعامل و اشتراکگذاری دائمی ایدهها با یکدیگر مشغول میشوند، محصولات بهتری هم میسازند.
۲. نرمافزار کاربردی در جایگاهی بالاتر از مستندات جامع
پیش از اینکه رویکردهای اجایل به صورت کامل پیادهسازی شوند، تیمها ساعتها روی نوشتن مستندات خستهکننده وقت میگذاشتند که شامل مشخصات فنی، پیشنیازها و موارد این چنینی بودند. این فهرستها باید پیش از فرایند کدنویسی آماده میشدند و بنابراین همینطور که تدوین اسناد زمان زیادی میبرد، فرایند توسعه هم به تعویق میافتاد.
فلسفه اجایل اینست که از خیر چنین اسنادی گذشته و اطلاعات را درون یوزر استوری به کار ببندیم. این استوریها (یا داستانها)، تمام جزییاتی که لازم است به هنگام کار روی نرمافزار و آمادهسازی آن برای عرضه بدانید را در اختیارتان میگذارند. ایده کلی اینست که فرایند عرضه شتاب بگیرد، تغییرات در همان مراحل نخست توسعه محصول پیادهسازی شوند و نرمافزار نیز در برهههای توسعه آتی بهبود یابد.
۳. همکاری با مشتری در جایگاهی بالاتر از مذاکرات قراردادی
سومین ارزش در بیانیه اجایل بر اهمیت مشارکت و همکاری با مشتری تاکید دارد. این رویکردی است که در جایگاهی برتر از مذاکرات بر سر قرارداد قرار میگیرد. در حالت سنتی، پیشنیازهای محصول قبل از شروع فرایند توسعه به مشتری اعلام میشوند و سپس در مراحل بعدی، بر سر آنچه قرار است تحویل شود، بحث صورت میگیرد. مشکل این روند آن است که مشتری مشارکتی در چرخه توسعه ندارد و بنابراین خبری از بازخورد مورد نیاز برای بهبود محصول نخواهد بود.
وقتی مشتریان را وارد فرایند توسعه میکنید، میتوانید به صورت مداوم خواستار نظرات آنها شوید و پیشنهاداتشان را با تیم توسعه و ذینفعان به اشتراک بگذارید. با خبردار شدن از نیازهای بهخصوص مشتری، آن هم زمانی که نرمافزار هنوز در دست توسعه است، توسعهدهندگان میتوانند دانشی عمیق به دست آورده و بهترین تجربه کاربری ممکن را رقم بزنند.
۴. واکنش به تغییرات در جایگاهی بالاتر از دنبال کردن برنامه
روششناسیهای سنتی، کسبوکارها را به دست زدن به کمترین تغییرات ممکن ترغیب میکردند، چرا که پیادهسازی تغییرات بنیادین به معنای پرداخت بهای مالی و زمانی کلان بود. هدف این بود که برنامهای جامع تدارک دیده شود که مسیری ساختارمند و خطی برای تیم ترسیم میکند و در مواقع ضروری نیز، از موانع مختلف اجتناب میشود.
اما ذهنیت اجایل کاملا معکوس است و این بحث پیش کشیده میشود که تغییر به نفع فرایند توسعه نرمافزار تمام خواهد شد. وقتی تغییر را در آغوش میگیرید، خودتان را در معرض احتمالات و روشهای تازه برای بهبود قرار میدهید. تیمهای چابک در چرخههای کوتاه و تکرارشونده مشغول به کار میشوند و این یعنی میتوانند واکنشهایی سریع داشته و تغییرات را به صورت مداوم پیادهسازی کنند. این رویکرد در نهایت به خلق محصولاتی بهتر منجر میشود.
اصول در بیانیه اجایل
چهار ارزشی که در بالا به سراغ آنها رفتیم، توسط ۱۲ اصل مختلف در مانیفست اجایل پشتیبانی میشوند:
- بالاترین اولویت ما کسب رضایت مشتری، از طریق عرضه زودهنگام و مداوم نرمافزار ارزشمند است. میدانید قانون نخست در دنیای توسعه محصول اجایل چیست؟ مشتریان را راضی نگه دارید. هدف باید این باشد که نرمافزار را به صورت مداوم و در برهههای مختلفی از چرخه عمر محصول به دست مشتریان برسانید و آنها را تا عرضه یک محصول غایی منتظر باقی نگه ندارید.
- از تغییرات، حتی در مراحل پایانی توسعه استقبال کنید. فرایندهای اجایل میتوانند تغییر را به مزیت رقابتی شما تبدیل کنند. توسعهدهندگان نرمافزار باید قادر به رسیدگی به تغییرات لحظه آخری در یک پروژه باشند. آنها باید آنقدر از خود انعطافپذیری نشان دهند که به سرعت این تغییرات را به شکل بهبود درآورند، تاخیر در امور را کاهش دهند و از پیشرفت جریان کارها به شکلی بیوقفه اطمینان حاصل کنند.
- نرمافزار را به صورت مداوم عرضه کنید، در برهههای چند هفتهای تا چند ماهی و ترجیح بر زمانبندیهای کوتاهتر است. تیمهای اجایل پروژههای بزرگ را تبدیل به قطعاتی کوچکتر با برنامه زمانی کوتاهتر میکنند تا قادر به تضمین عرضه آنها باشند. در روششناسی اسکرام، به این برهههای زمانی «اسپرینت» گفته میشود که معمولا بین یک الی چهار هفته به طول میانجامند.
- تاجران و توسعهدهندگان باید در سراسر پروژه و به صورت روزمره با یکدیگر همکاری کنند. همانطور که پیشتر نیز اشاره کردیم، مشارکت یکی از کلیدیترین ویژگیهای مدیریت پروژه چابک است. وقتی ذینفعان پروژه به شکلی روزمره با یکدیگر ارتباط برقرار میکنند، احتمال گیج شدن اعضا کاهش مییابد و تمام افراد، اهدافی یکسان را در پیش میگیرند.
- پروژه را پیرامون افراد باانگیزه پیش ببرید، محیط و حمایت لازم را در اختیارشان بگذارید و به آنها در رسیدگی به امور اعتماد کنید. وقتی افراد درست را برای رسیدگی به وظایف در اختیار داشته باشید، شانس بالاتری هم برای موفقیت خواهید داشت. زمان خود را صرف یافتن تیمی بینقص کنید، منابع لازم را در اختیارش بگذارید و به اعضا در دستیابی به نتایجی بینظیر اعتماد کنید.
- بهینهترین و موثرترین روش انتقال اطلاعال به تیم و میان اعضای تیم، مکالمات رو در رو است. وقتی اعضای تیم به صورت حضوری مکالمه میکنند، بسیاری از موانع از پیش رو برداشته میشوند. نقاطی که از نظر برقراری ارتباط موثر جای کار دارند را بهبود دهید و گردش اطلاعات را به جریان بیندازید. در حالتی که کارمندان دورکاری میکنند، اپلیکیشنهای کنفرانس ویدیویی مانند Zoom و Skype میتوانند جایگزینی عالی برای تماس تلفنی یا ایمیل باشند و امکان برقراری ارتباط موثرتر از طریق دوربین را مهیا میسازند.
- کارکرد نرمافزار، اصلیترین واحد اندازهگیری پیشرفت است. برای اینکه مشتریان خود را راضی نگه دارید، باید نرمافزاری واقعا با کیفیت به دست آنها برسانید. این اولویت غایی شما و همینطور اصلیترین معیار موفقیت شماست - هرچیز دیگری در جایگاهی و اولویتی پایینتر قرار میگیرد.
- فرایندهای اجایل، توسعه پایدار را تشویق میکنند. اسپانسرها، توسعهدهندگان و کاربران باید قادر به حفظ شتاب خود باشن. تیمهای اجایل باید در سراسر چرخه عمر پروژه باثبات باقی بمانند و با سرعتی یکسان پیش بروند. این یعنی آنها میتوانند محیطی برای تکامل دائمی فراهم آورند و به تاخیرهای مداوم تن ندهند.
- توجه دائمی به برتری فنی و طراحی صحیح، چابکی را افزایش میدهد. در روششناسی اجایل، شما صرفا به عرضه یک محصول خوب و به پایان رساندن کارها مشغول نمیشوید. در واقع تمرکز شما باید بر بهبود و نوآوری دائمی باشد. هر برهه توسعه باید بهروزرسانیها، قابلیتها و یا هر نوع پیشرفت دیگری را با خود به همراه آورد.
- سادگی - هنر بیشینهسازی کارهایی که انجام نمیشوند - ضروری است. رویکرد اجایل تمام راجع عدم پیچیدهسازی امور است: پیشنیازها را برآورده سازید و تنها به مقدار لازم برای تمام شدن وظایف کار کنید. زمان خود را با گامهای اضافهای هدر ندهید که هیچگونه ارزش حقیقی به محصول نمیآورند.
- بهترین معماریها، پیشنیازها و طراحیها از تیمهای خودسازمانده برمیخیزند. وقتی اعضای تیم از مهارتهای لازم برای رسیدگی به امور خود برخوردار هستند، چرا خردترین مسائل را مدیریت کنیم؟ وقتی به تیمها اجازه میدهید که با ساختارهای خاص خود پیش بروند، فضای بیشتری برای شکلگیری ایدهها و در نتیجه، ارائه نتایج بهتر فراهم میآورید.
- تیم به صورت دائمی راجع به نحوه دستیابی به بهینگی بیشتر بحث و سپس رویکردهای خود را مطابق گفتگوها دستخوش تغییر میکند. وقتی به صورت مداوم به سنجش عملکرد تیم مشغول میشوید، مشکلات را پیش از اینکه شکلی بحرانی به خود بگیرند شناسایی خواهید کرد. همین موضوع راجع به نقاط قابل بهبود هم مصداق میکند. یک تیم اجایل سالم، تیمیست که عملکرد خودش را پایش میکند تا به کنار گذاشتن رویکردهای ناکارآمد و بهبود مهارتها مشغول شود.
اهمیت بیانیه اجایل چیست؟
مانیفست یا بیانیه اجایل منبعی ارزشمند برای تیمهای توسعه نرمافزار به حساب میآید، چرا که دانش لازم برای ساخت فریمورکی انعطافپذیر را در اختیار آنها میگذارد و اعضای تیم را با بهترین رویکردها و فرایندهای اجایل آشنا میسازد. در این بیانیه، راجع به آنچه در مدیریت پروژه اجایل مهم است نیز صحبت شده و بنابراین تیمهای توسعه قادر به اولویتبندی فعالیتها و همسو کردن اهداف خود با آنها خواهند بود. برای مثال، توسعهدهندگان نرمافزار میدانند که رضایت مشتری از بالاترین اولویت برخوردار است و بنابراین تمام برنامههای خود را پیرامون این قاعده کلی میچینند.
با این حال تیمها باید مراقب پدیدهای باشند که تحت عنوان «عقده صنعتی اجایل» (Agile Industrial Complex) شناخته میشوند. این عبارت به وضعیتی اشاره دارد که سازمانها، بهترین رویکردهای اجایل را به تیمها تحمیل میکنند و اجازه نمیدهند آنها خود راجع به آنچه جواب میدهد تصمیم بگیرند. باید در نظر داشت که هیچ رویکرد جهانشمولی در مدیریت پروژه وجود ندارد که همواره جواب بدهد و بنابراین تحمیل کردن روششناسیهای نامناسب، نتایج مطلوب را به همراه نخواهد آورد. مارتین فولر، یکی از موسسین مکتب اجایل میگوید که «حتی مدافعان اجایل هم نمیگویند که اجایل لزوما بهترین گزینه برای استفاده در هر شرایطی به حساب میآید».
به صورت خلاصه، بیانیه اجایل سندی بسیار مهم برای آن دسته از تیمهای توسعه است که میخواهند روششناسی اجایل را به شکلی پایدار در سازمان خود پیادهسازی کنند.
مزایای اجایل
از دو دهه پیش که بیانیه اجایل نوشته شد، تیمهای توسعه در سراسر جهان به استقبال از آن پرداخته و اجایل را در فرایندهای مدیریت پروژه و مدیریت محصول خود پیادهسازی کردهاند. بنابر چهاردهمین گزارش وضعیت اجایل، ۹۵ درصد از ۴۰ هزار مشارکتکننده در نظرسنجی میگویند که سازمان آنها روشهای توسعه اجایل را در پیش گرفته و ۶۱ درصد هم میگویند که برای بیش از سه سال در حال استفاده از اجایل بودهاند.
آنهایی که رویکردهای اجایل را در پیش میگیرند، خیلی زود متوجه مزایای آن نسبت به رویکردهای مدیریت پروژه سنتی میشوند. در واقع اگر بپرسید علت محبوبیت اجایل چیست، دقیقا میتوان به همین مزایا به عنوان علت اصلی اشاره کرد.
علت محبوبیت اجایل چیست؟
پژوهشها و آمارها نشان میدهند که رویکردهای اجایل به شکلی انفجاری مورد استقبال قرار گرفتهاند، چرا که سازمانها قادر به درک مزیتهای آن در عصر مدرن بودهاند. رشد سریع تکنولوژی در قرن بیست و یکم سپس شده که چشمانداز بسیاری از مشاغل به کل دگرگون شود و این موضوع، اثر خود را روی تقریبا تمام صنایع جهان گذاشته است.
مزایای بالقوه راهکارهای اجایل، ابتدا از سوی آن دسته از تیمهای توسعهای کشف شد که میخواستند سرعت پیشرفت پروژهها را بالا ببرند و زمان بین ایدهپردازی تا عرضه محصول را کاهش دهند. اکنون، بسیاری از شرکتهای جهان از رویکردهای اجایل برای سرعت بخشیدن به جریان کاری خود و همینطور همگام ماندن با رقبا استفاده میکنند. بنابر پژوهشی که توسط Organize Agile در ۱۹ کشور جهان انجام شده، تقریبا نیمی از سازمانها برای سه سال یا بیشتر در حال استفاده از روششناسی اجایل بودهاند.
اما برای اینکه درکی عمیقتر از این به دست آوریم که علت محبوبیت اجایل چیست، بیایید نگاهی عمیقتر به برخی از منافع آن بیندازیم.
منافع اجایل
منافعی که اجایل با خود به همراه میآورد، بسته به ماهیت سازمان، تیم توسعه و همینطور رویکردهای پیادهسازیشده، متغیر خواهد بود. اما به صورت کلی، با درپیشگیری رویکرهای اجایل، میتوانید منتظر منافعی باشید که در ادامه به آنها اشاره میکنیم:
۱. رضایت مشتریان
با دخیل کردن مشتریان در فرایند توسعه، تیمهای اجایل نشان میدهند که برای نظرات آنها ارزش قائل میشوند. ذینفعان پروژه دوست دارند که در سراسر چرخه عمر پروژه دخیل باشند تا به ارائه بازخورد مشغول شوند و اطمینان حاصل کنند که محصول نهایی با نیازها و خواستههای آنها سازگار است. ویژگیهایی که به صورت سفارشی برای مشتریان تدارک دیده میشوند، نرخ رضایت و همینطور وفاداری آنها را افزایش میدهند.
۲. کیفیت بالاتر محصول
روششناسیهای اجایل از رویکردی تکرار شونده و برههای در مدیریت پروژه برخوردا هستند و این یعنی، هر بار که برهه توسعه از سر گرفته میشود، فرصتی برای بهبود فرایندها و محصول خواهید داشت. این تمرکز دائمی بر بهبود و کنترل کیفیت یکی از بنیادینترین اصول اجایل است و به شما در ساخت محصولاتی برتر یاری میرساند.
۳. تطبیقپذیری
اصلیترین مساله در فرایندهای اجایل، انعطاف پذیری است. تیمهای اجایل باید قادر به واکنش نشان دادن به تغییرات باشند و بدون هیچ اختلالی در عملکرد، خودشان را با شرایط جدید تطبیق دهند. حتی اگر تغییرات در دقایق پایانی از راه رسیده باشند. وظایف تعیین شده برای پروژه حکم وحی منزل را ندارد و بنابراین تیمها قادر به بازنگری در برنامههای خود و اولویت بندی توسعه محصول براساس اهداف بهروزرسانی شده هستند. تطبیقپذیری بدین معناست که تیمها میتوانند پیشنیازهای متغیر مشتریان را مدیریت کرده و آنها را به شکلی موثر، پیادهسازی کنند.
۴. پیشبینیپذیری
تیمهای اجایل در برهههای زمانی کوتاهمدت مشغول میشوند که گاهی به آنها «اسپرینت» میگویند. این بازههای زمانی مشخص (مثلا دو هفتهای) باعث میشوند مدیران پروژه به شکلی آسانتر قادر به سنجش عملکرد تیم و تخصیص منابع باشند. از سوی دیگر، برهههای کوتاهمدت باعث میشوند که پیشبینی هزینهها نسبت به پروژههای طولانیمدت راحتتر باشد. بنابراین فرایند تخمین زدن هزینهها کاملا سرراست میشود.
۵. ریسک کمتر
توسعهدهندگان به صورت مداوم به سنجش عملکرد خود در اسپرینتهای مختلف میپردازند و این یعنی هم بهتر قادر به دیدن وضعیت پروژه هستند و هم میتوانند موانع بالقوه را به سرعت شناسایی کرده و از میان بردارند. بخش اعظمی از مشکلات کوچک را میتوان پیش از اینکه تبدیل به چالشی بزرگ شوند رفع و رجوع کرد. بدین ترتیب فرایندی موثر برای مقابله با ریسک خواهید داشت و شانس موفقیت پروژه را بالاتر میبرید.
۶. ارتباطات بهتر و موثرتر
تیمهای اجایل، ارتباطات رو-در-رو و تعاملات پیوسته را در اولویت قرار میدهند. آنها به برگزاری جلساتی روزمره میپردازند تا اطمینان حاصل شود که همه ذهنیتی یکسان را دنبال کرده و به سمت هدفی واحد حرکت میکنند. با برقراری ارتباط مداوم با یکدیگر، اعضای تیم قادر به از بین بردن سردرگمیهای احتمالی و رسیدگی به وظایف خود خواهن بود.
تا به اینجای کار کاملا واضح است که روششناسی اجایل منافع فراوانی با خود به همراه میآورد. اما مزایای اجایل در قیاس با دیگر روششناسیهای مدیریت پروژه چیست؟
مزایای اجایل
رویکرد اجایل معمولا رویکردی بهتر از دیگر روششناسیهای مدیریت پروژه تلقی میشود.
بیایید دلایل پشت این ماجرا را با چند مثال بررسی کنیم:
مدیریت اجایل در برابر مدیریت آبشاری
مدیریت «آبشاری» (Waterfall) احتمالا شناختهشدهترین رویکرد سنتی در قبال مدیریت پروژه باشد. در این سبک، فرایندهایی ساختارمند و خطی را دنبال میکنید و هر وظیفه باید به صورت کامل به پایان برسد تا بتوان به سراغ وظیفه بعدی رفت. اگرچه این روششناسی گزینهای کاملا مناسب برای پروژههای طولانیمدت (مثلا ساختوساز) است، اما در دنیای سریع و پرتنش توسعه نرمافزار جواب نمیدهد. مشتریان چنین نرمافزارهایی دائما ذهنیتهای خود را دگرگون کرده و به دنبال ویژگیها و قابلیتهایی تازه میگردند.
به عنوان مثال میتوانیم به غول رسانهای آمریکایی، یعنی NPR نگاه کنیم. این شرکت از مدیریت آبشاری به سراغ مدیریت اجایل رفت تا از وقوع «پیامدهای ناخواسته» جلوگیری کند، پیامدهایی مانند تفاوت چشمگیر اهداف پایانی پروژه نسبت به اهدافی که در ابتدای پروژه ترسیم شدهاند. با توجه به اینکه حتی نسبت به ماهیت پروژههای خود مطمئن نبود، روش آبشاری که نیازمند نقشهای کاملا فکر شده از نقطه آغاز تا پایان است، خیلی ساده گزینهای مطلوب به حساب نمیآید. به همین خاطر آنها به سراغ رویه اجایل رفتند تا انعطافپذیری بیشتری در فرایندهای خود به دست آورند.
مدیریت اجایل در برابر مدیریت ناب
روششناسی «ناب» (Lean) رویکردی سرراست در پیش گرفته و هدفش، از میان برداشتن ضایعات و هدررفتهای غیر ضروری است. شباهتهای زیادی میان اجایل و ناب وجود دارد و برای مثال میتوان به تمرکز هر دو بر رضایت مشتری و ارائه سریع محصول اشاره کرد. با این حال میتوان بحث کرد که از نظر ساختار کلی، اجایل در جایگاهی برتر قرار میگیرد.
همانطور که پیشتر بارها اشاره کردیم، اجایل انعطافپذیری بیشتری نسبت به همتایان سنتی خود دارد، اما کماکان نوعی حس ساختارمندی را به سازمان میآورد، چرا که شاهد نقشهای کاملا تعریق شده، جلسات دائمی و ارزیابیهای سامانیافته هستیم. این سطح از نظاممندی باعث میشود پیادهسازی رویکردهای اجایل آسانتر از رویکردهای لین باشد که روی تفکر فرهنگی درون سازمان متمرکزتر است. نظریه ناب، ساختاری به محسوسی ساختار اجایل ندارد و عملی کردن آن چالشهای بیشتری به همراه خواهد آورد.
مدیریت اجایل در برابر مدیریت PRINCE2
PRINCE2 (مخفف Projects In Controlled Environment) یا «پروژهها در محیطهایی کنترل شده» روششناسی بهخصوصی است که عمدتا به خاطر برنامهریزیهای مبتنی بر محصول شناخته میشود. در این روش، از یک برد پروژه ساختارمند برای فعالیتهای سطح بالا استفاده میشود و یک مدیر پروژه نیز بر عملیاتهای روزمره نظارت دارد. PRINCE2 گزینهای ایدهآل برای مدیران ردهبالایی به حساب میآید اما در خبری از تاکید اجایل بر ارائه سریع محصول نیست.
برخلاف PRINCE2، در اجایل روشی پیشبینیپذیر و برنامهمحور در پیش گرفته نمیشود. در عوض تیمهای اجایل روی ارائه نرمافزاری کارآمد در پایان هر اسپرینت تمرکز دارند و از بازخورد دریافتی از مشتریان برای بهبود فرایند توسعه بهره میگیرند. این رویکرد کوتاهمدت سبب میشود اجایل تطبیقپذیری به مراتب بیشتری با نیازهای مشتریان داشته باشد.
به عنوان جمعبندی این بخش از مقاله اجایل چیست باید بگوییم که منافع و مزایای این روششناسی را میتوان به وضوح مشاهده کرد. اما تصمیم راجع به اینکه کدام روششناسی همسویی بیشتری با فرایندهای کاری تیم و اهداف سازمان دارد، برعهده مدیر پروژه است.
عملیاتهای اجایل چیست؟
«عملیاتهای اجایل» (Agile Operations) که در محاوره تحت عنوان «اجایل آپس» (Agile Ops) هم شناخته میشوند، عبارتی برای توصیف پیادهسازی اصول و روششناسیهای اجایل در فرایندهای عملیاتی یک تیم است.
تیمها به کمک این عملیاتها قادر به تطبیق یافتن با تغییرات و همینطور تغییر مسیر در زمان مواجهه با مشکلات گوناگون خواهند بود. تیمهای توسعه نرمافزار معمولا از اجایل آپس برای رسیدگی به سیستمهای خود و حفظ آنها کمک میگیرند، اما این عملیاتها میتوانند برای تیمهای دیگر مانند واحد فناوری اطلاعات هم مناسب باشند.
تاریخچه عملیاتهای فناوری اطلاعات (IT) در اجایل
در سالهای ابتدایی دهه ۲۰۰۰ میلادی، فلسفه اجایل به محبوبیتی گسترده میان تیمهای توسعه نرمافزار دست یافت. در نتیجه، تیمهای «فناوری اطلاعات» یا «آیتی» به سختی با خروجیها همگام میماندند و محیطی امن برای کدنویسی سطح بالا فراهم میآوردند. میخواهید بدانید راهکار چه بود؟ اینکه تیمهای آیتی هم رویکردهای اجایل را در پیش بگیرند تا عملکردی همانقدر سریع به نمایش بگذارند.
با این حال، موضوع به همین سادگی نبود. تیمهای آیتی کارهای بسیار متفاوتی نسبت به تیمهای توسعه نرمافزار انجام میدهند و روششناسی اجایل را نمیشد به همان شکل به کار بست. در واقع از نظر سمتهای شغلی و اولویتها، داریم درباره دو فرهنگ کاملا متفاوت حرف میزنیم. برای مثال توسعهدهندگان چابک روی سرعت و تداوم کار تمرکز میکنند، اما برای متخصصان حوزه آیتی، بالاترین اولویت در اختیار امنیت است.
برای برقراری ارتباطی صحیح میان این دو، مفهوم «DevOps» شکل گرفت. عبارت DevOps که در سال ۲۰۰۹ میلادی از سوی پاتریک دوبوا و اندرو کلی شیفر شکل گرفت، به ترکیبی از عملیاتهای آیتی و توسعه نرمافزار اشاره دارد. این دو گروه کاملا متفاوت، میتوانند زیر چتر اجایل به صورت موازی پیش بروند. به این ترتیب تیمهای آیتی میتوانند در مراحل آزمایش نرمافزار به کدنویسی مشغول شوند و توسعهدهندگان هم بیشتر در فرایند تعمیر و نگهداری دخیل خواهند بود.
مزایای عملیاتهای آیتی اجایل
بیایید در ادامه ببینیم برخی از مزایای عملیاتهای آیتی اجایل چیست.
۱. یکپارچگی بهتر تیم
اجایل آپس باعث میشوند شاهد مشارکت بیشتری میان متخصصان حوزه آیتی و توسعهدهندگان نرمافزار باشید. این دو تیم پیشتر به صورت کاملا ایزوله از یکدیگر کار میکردند و تا زمان عرضه محصول، ارتباطی با یکدیگر نداشتند. در مدل عملیاتی اجایل اما تعامل میان این دو واحد افزایش مییابد و اهداف شرکت شکلی همسو به خود میگیرند تا سردرگمیهای غیر ضروری در چرخه عمر پروژه از بین برون.
۲. خطای کمتر
تیمهای اجایل رویکردی تکرارشونده در قبال وظایف خود در پیش میگیرند و چرخههایی مداوم از توسعه، تست و صیقل دادن محصول را پشت سر میگذارند. تست دائمی بدین معناست که باگها در همان مراحل ابتدایی شناسایی و رفع و رجوع میشوند. با کمینهسازی خطاها پیش از اینکه نرمافزار به صورت گسترده در دسترس قرار بگیرد، تیمهای آیتی قادر به کم کردن بار کاری خود در دوران پسا عرضه خواند بود.
۳. هزینههای کمتر
وقتی تیمهای اجایل مشکلاتی را شناسایی کرده و به افزودن قابلیتهای جدید در هر برهه توسعه مشغول میشوند، میتوانند هزینههای خود را نیز به شکل چشمگیری کاهش دهند. روششناسی چابک به این تیمها اجازه میدهد که پیش از عرضه، بهترین محصول ممکن را بسازند و بنابراین هیچگونه پول یا منبع ارزشمند دیگری صرف بازطراحیهای گرانقیمت نمیشود.
۴. بهرهوری بالاتر
فلسفه اجایل تاکیدی شدید بر تعاملات رو-در-رو دارد که باعث افزایش بهرهوری در میان تیمهای آیتی خواهد شد. گزارشها و پژوهشها نشان میدهند که رویکرد اجایل باعث میشود تیمهای آیتی در برهههای شش الی ۱۸ ماهه، بهرهوری خود را بین ۲۵ الی ۳۰ درصد افزایش دهند.
۵. اولویتبندیهای واضح
یک اولویت کلیدی در مدل اجایل آپس، رسیدگی به نیازهای تجاری در برهههای زمانی کوتاهمدت است. اگرچه تیمهای آیتی باید به جای سرعت بر ثبات تمرکز کنند، رویکرد اجایل میتواند اولویتهای آنها را بسط داده و منجر به شکلگیری نقطهنظرهایی جدید راجع به ارزشسازی برای مشتریان شود.
چطور عملیاتهای آیتی اجایل را پیادهسازی کنیم؟
حالا که میدانید مزایای این رویه اجایل چیست، احتمالا این پرسش مطرح شود که چطور میتوان فلسفه اجایل را در عملیاتهای آیتی به کار گرفت؟ همانطور که پیشتر هم اشاره کردیم، روششناسیهای اجایل به شکل خام در تیمهای آیتی پیادهسازی نمیشوند و باید از پیش ملاحظاتی راجع به تفاوتهای فرهنگی داشته باشید.
پیش از هرچیز باید وقت گذاشته و به بررسی این مشغول شوید که کدام روششناسی مدیریت پروژه اجایل برای تیم آیتی شما مناسبتر خواهد بود. کانبان گزینهای محبوب برای تیمهای DevOps است، چرا که میتوانند شکلی بصری به وظایف خود ببخشند و میزان پیشرفت را روی برد پروژه ببینند. از سوی دیگر نیز رویه اسکرام را داریم که گزینهای مطلوب برای تیمهای بزرگتری به حساب میآید که نوآوریهایی طولانیمدت میطلبند، چرا که پروژه به برهههای زمانی کوتاهتری به نام اسپرینت در اسکرام تقسیم میشود.
بعد از این باید به ارزیابی نقشها و بهکارگیری بهترین رویکردهای موجود در روششناسی اجایل مد نظرتان مشغول شوید. برای مثال نقشهای اسکرام مستر یا مالک محصول را داریم که شاید سازگاری چندانی با ساختار کنونی تیم آیتی شما نداشته باشند. به صورت مشابه، اعضای تیم آیتی شاید با بهترین رویکردهای اجایل و نحوه عملکرد تیمهای چابک آشنا بناشند. فرصتی برای آموزش سازمانی در اختیار تیم آیتی بگذارید و به سوالات آنها پاسخ دهیم. از سوی دیگر، افراد درست را دستچین کنید تا در ساختار اجایل، رهبری را به دست بگیرند.
در مرحله آخر نیز باید بهترین ابزازهای مدیریت پروژه را در اختیار تیم بگذارید. سیستمهای فعلی آنها ممکن است با مدل عملیاتی انعطافپذیر اجایل سازگار نباشد، بنابراین نیاز به راهکارهای نرمافزاری دارند تا وظایف و پیشرفت را پایش کنند و نتایج را با ذینفعان به اشتراک بگذارند.
چرخه عمر توسعه نرمافزار اجایل چیست؟
چرخه عمر توسعه نرمافزار اجایل (Agile Software Development Life Cycle) به مجموعهای از مراحل ساختارمند گفته میشود که محصول با عبور از آنها، مسیر توسعه را از ابتدا تا انتها طی میکند. این چرخه حاوی شش فاز است: مفهوم (Concept)، تکوین (Inception)، تکرار (Iteration)، عرضه (Release)، نگهداری (Maintenance) و بازنشستگی (Retirement).
چرخه عمر جایل میتواند بسته به روششناسی مدیریت پروژه منتخب تیم شما دچار تغییرات اندک شود. برای مثال تیمهای اسکرام باید در برهههای کوتاهی به نام اسپرینت کار کنند که مشابه به فاز «تکرار» است. از سوی دیگر، در آنها شاهد نقشهایی واضح مانند اسکرام مستر هستیم. از سوی دیگر، تیمهای کانبان جریانی مداوم را دنبال میکنند و نقش بهخصوصی ندارند. یک مثال دیگر هم روششناسی Extreme Programming است که در آن، تیمها به سراغ برهههای تکرارشونده کوتاهتر رفته و تمرکز بیشتری بر رویکردهای مهندسی دارند.
با این همه باید افزود که هدف غایی تمام تیمهای توسعه نرمافزار یکسان است: ارائه نرمافزاری به مشتری که به خوبی کار میکند و در زمان درست از راه میرسد.
شش مرحله در چرخه عمر اجایل
همانطور که بالاتر اشاره کردیم، چرخه عمر توسعه نرمافزار اجایل از شش مرحله تشکیل شده است. بیایید هر یک از این مراحل را با جزییات بیشتر بررسی کنیم.
۱. مفهوم
اولین مرحله، «مفهوم» (Concept) است. در این مرحله، مالک محصول به تعیین ابعاد پروژه خود میپردازد. اگر نیاز به چندین پروژه باشد، مهمترین موارد اولویتبندی میشوند. مالک محصول راجع به پیشنیازهای کلیدی با مشتری صحبت میکند و اسناد لازم را فراهم میآورد، اسنادی راجع به قابلیتهای مورد پشتیبانی و نتایج پایانی پیشنهادی. معمولا پیشنهاد میشود که پیشنیازها در کمترین مقدار ممکن باقی بمانند تا امکان افزودن پیشنیازهای بیشتر در مراحل بعدی فراهم باشد. در مرحله مفهوم، مالک محصول به تخمین مدتزمان و هزینه لازم برای پروژه نیز مشغول میشود. این تحلیل عمیق به او اجازه میدهد که از امکانپذیری پروژه اطمینان حاصل کند.
۲. تکوین
وقتی مفهوم اولیه شکل گرفت، نوبت به تشکیل تیم توسعه نرمافزار میرسد. مالک محصول میزان دسترسی به همکاران را بررسی کرده و بهترین افراد را برای پروژه برمیگزیند. سپس ابزارها و منابع ضروری را در اختیار آنها میگذارد. بدین ترتیب فرایند طراحی آغاز میشود. تیم به ساخت ماکتی از رابط کاربری مشغول میشود و معماری پروژه را پیادهسازی میکند. مرحله «تکوین» (Inception) شامل دریافت بازخورد از ذینفعان هم میشود تا تمام پیشنیازها و به تبع آنها، کارکردپذیری محصول مشخص شود. بازنگریهای دائمی باعث حصول اطمینان از این میشود که آیا تمام پیشنیازها در فرایند طراحی به کار بسته شدهاند یا خیر.
۳. تکرار
بعد از اینها نوبت به فاز «تکرار» (Iteration) میرسد که به عنوان فاز «ساختوساز» (Construction) هم شناخته میشود. این طولانیترین فاز است و بخش اعظمی از کارها را در بر میگیرد. توسعهدهندگان به همکاری با متخصصان طراحی تجربه کاری مشغول میشوند تا قادر به ادغام تمام پیشنیازها و بازخوردهای مشتریان و سپس تبدیل کردن آنها به کد باشند. هدف این است که کارکردهای بنیادین محصول تا پیش از انتهای نخستین برهه تکرار یا اسپرینت، ساخته شوند. بنابراین داریم راجع به مرحلهای صحبت میکنیم که سنگ بنای توسعه نرمافزار اجایل به حساب میآید و به توسعهدهندگان اجازه میدهد به سرعت نرمافزاری کاربردی بسازند و آن را مطابق میل مشتری، بهبود دهند.
۴. عرضه
محصول ما اکنون تقریبا برای عرضه آماده است. اما ابتدا باید تیم کنترل کیفیت وارد میدان شده و تستهای مختلف را برای حصول اطمینان از کارکرد کامل نرمافزار، پشت سر بگذارد. اعضای این تیمها وضعیت تمیز بودن کدها را بررسی میکنند و اگر باگ یا مشکلی به چشمشان بخورد، آن را فورا به توسعهدهندگان گزارش میدهند. آموزش کاربر نیز در این مرحله اتفاق میافتد که نیازمند سندسازی هرچه بیشتر است. وقتی تمام این کارها انجام شوند، آخرین برهه تکرار را هم پشت سر گذاشتهایم و محصول برای «عرضه» (Release) آماده است.
۵. نگهداری
نرمافزار اکنون به صورت تمام و کمال عرضه شده و در دسترس مشتریان قرار گرفته. بدین ترتیب وارد فاز «نگهداری» (Maintenance) میشویم. در این فاز، تیم توسعه نرمافزار به ارائه پشتیبانی مداوم مشغول میشود تا سیستم را به شکلی روان به اجرا درآورد و هر باگ جدیدی را برطرف سازد. از سوی دیگر، همچنان برای تمرین دادن کاربران و حصول اطمینان از اینکه نحوه کار با محصول را میدانند، به تیم توسعه دسترسی خواهید داشت. در این بازه، میتوان برهههای توسعه هرچه بیشتری را پشت سر گذاشت تا محصول کنونی ارتقا یابد و از ویژگیهای جدید بهرهمند شود.
۶. بازنشستگی
یک محصول به دو دلیل میتواند وارد فاز بازنشستگی (Retirement) شود: یا به خاطر اینکه جایش را به نرمافزاری جدید میدهد و یا منقضی شده و در گذر زمان، سازگاری چندان با سازمان ندارد. تیم توسعه نرمافزار ابتدا خبر بازنشستگی قریبالوقوع نرمافزار را به کاربران میدهد. اگر جایگزینی برای آن باشد، کاربران به مهاجرت به سیستم جدید تشویق میشوند. در نهایت نیز کارهای باقی مانده برای اتمام چرخه حیات نرمافزار و کنار گذاشتن پشتیبانی آن انجام میشوند.
هر فاز از چرخه عمر اجایل از چندین برهه تکرار شونده تشکیل شده است تا بتوان به نتایجی معرکه دست پیدا کرد. بیایید ببینیم که این جریان کاری متکی بر برهههای تکرار شونده، چطور کار میکند.
ساختار جریان کاری تکرار شونده اجایل چیست؟
برهههای توسعه تکرار شونده در اجایل معمولا بین دو الی چهار هفته زمان میبرند و تاریخی از پیش مقرر برای پایان یافتن دارند. جریان کاری چنین برههای، معمولا از ۵ گام تشکیل شده است:
- برنامهریزی برای پیشنیازها
- توسعه محصول
- تست نرمافزار
- اتمام برهه تکرار شونده
- بهکارگیری بازخوردها
هر فاز اجایل شامل چندین برهه تکرار میشود و توسعهدهندگان نرمافزار، فرایندهای خود را تکرار میکنند تا قادر به صیقل دادن محصول و ساخت بهترین نرمافزار ممکن باشند. اساسا میتوان گفت که این برهههای توسعه تکرار شونده صرفا چرخههایی کوچکتر در چرخه عمر اجایل به حساب میآیند.
چرخه عمر اجایل مدلی کلیدی برای ساختاربخشی به تیمهای توسعه نرمافزار است که به آنها اجازه میدهد از لحظه ایدهپردازی تا بازنشستگی، در مسیر درست باقی بمانند. برای پشتیبانی صحیح از تمام فعالیتهای صورت گرفته در چرخه اجایل، اعضای تیم باید به منابع و ابزارهای مناسب کار خود دسترسی داشته باشند.
ساختار تیم اجایل چیست؟
ساختار تیم اجایل (Agile Team Structure) بستری است که از آن برای سامان دادن به عناصر مختلف تیمی که روی پروژه اجایل کار میکند، استفاده میشود. از جمله این عناصر میتوان به فعالیتهای مربوط به پروژه، جریانهای کاری و نقشها در تیم اشاره کرد. چنین ساختاری اساسا فونداسیونی است که تیمهای اجایل به کمک آن قادر به نظم دادن به رویههای عملیاتی خود خواهند بود.
در سال ۱۹۶۵ میلادی بود که بروس تاکمن، روانشناس آمریکایی، مدلی برای مراحل توسعه گروهی پیشنهاد داد:
شکلگیری (Forming) ← ایدهپردازی (Storming) ← عادیسازی (Norming) ← اجرا (Performing)
این بستر یا فریمورک انعطافپذیر حسابی به مذاق مدیران پروژه اجایل خوش آمده، چرا که میتوان از آن برای هدایت کردن تیمها در پروژههای گوناگون استفاده کرد. هر بار که یک عضو از تیم جدا میشود یا به تیم میپیوندد، میتوانند به مرحله «شکلگیری» بازگردند و همهچیز را از نو شروع کنند. یک ساختار درست باعث شکل گرفتن وضوح در امور میشود و هرکسی میداند چه مسئولیتهایی برعهده دارد. لایه اجایل اضافی نیز باعث حصول اطمینان از این میشود که تیم به اندازه کافی انعطافپذیر است و واکنشی سریع و موثر به تغییرات نشان میدهد.
ویژگیهای ساختار تیم اجایل چیست؟
- عملکرد گروهی: ساختار تیم اجایل بهگونهای است که عملکرد گروهی را پدید میآورد. هر یک از اعضای تیم مهارتهای خاص خود را دارند، اما همگی به سمت هدفی مشترک حرکت میکنند: ارائه ویژگیها در زمان درست تا رضایت مشتری کسب شود.
- مشارکت: در یک تیم اجایل شاهد انبوهی مشارکت و ارتباط آزادانه خواهید بود. برخی اعضای تیم حتی در برنامههای آموزشی شرکت کرده و دوشادوش همکاران خود کار میکنند تا هم از آنها بیاموزند و هم مهارتهای تازه کسب کنند. این اعضای تیم با صفت «T-شکل» توصیف میشوند: خط افقی نشاندهنده درک عمومی آنها نسبت به مهارتهای مختلف است و خط عمودی نیز نشاندهنده اصلیترین تخصص آنها.
- غیر سلسلهمراتبی: یک ویژگی کلیدی دیگر در ساختار تیم اجایل این است که شکلی کاملا غیر سلسلهمراتبی دارد. تیمهای اجایل ساختار تخت را ترجیح میدهند، یعنی وضعیتی که تمامی افراد از استقلال لازم برای رسیدگی به امور به شیوه خود برخوردار هستند. هر یک از اعضای تیم، سمت و مسئولیتی مشخص دارد. اما برخی لایههای مدیریتی غیر ضروری از میان برداشته شدهاند تا اعضا قادر به خود ساماندهی باشند. این رویکرد در گروههای کوچک حسابی جواب میدهد. برای مثال، پیشنهاد میشود که تیمهای اسکرام بین سه الی نه عضو داشته باشند، پس منطقی است که تمام اعضا در جایگاهی یکسان قرار بگیرند.
ساختار تیم: سنتی در برابر اجایل
نبود سلسهمراتب که پیشتر به آن اشاره کردیم، اصلیترین وجه تمایز ساختار تیم اجایل از تیمی سنتی به حساب میآید که رویکرد مدیریت پروژه بالا به پایین را در پیش میگیرد.
در این فضای سنتی، مدیر است که وظایف را تعیین و نحوه رسیدگی به آنها را دیکته میکند. گرچه این ساختار ممکن است برای سازمانهای بزرگتر جواب دهد، به هیچ وجه به تیمهای چابک پیشنهاد نمیشود. در واقع فایننشال تایمز میگوید که «ساختار سلسهمراتبی میتواند با ترغیب کارمندان به سیاسیکاری و رقابتهای بیحاصل، به سدی در راه تیم تبدیل شود». در محیط اجایل ایدهآل، خبری از رقابت نیست. تیمهای اجایل رقابت داخلی بر سر ارتقای شغلی را تشویف نمیکنند و در عوض به شکلی متحد، اهدافی مشترک را در پیش میگیرند.
حالا که میدانیم در بنیادینترین حالت، ساختار تیم اجایل چیست و چگونه است، بیایید انواع تیمها را از نظر رد کنیم.
انواع ساختار تیم اجایل چیست؟
ساختار در پیش گرفته شده از سوی یک تیم اجایل به فاکتورهای مختلفی مانند هزینه، منابع در دسترس و جنس پروژه وابسته است. هیچ ساختار بهخصوصی نداریم که برای همه مناسب باشد، در عوض چارچوبهایی متفاوت برای تیمهای متفاوت داریم و هر انتخاب هم مزایا و معایب خاص خود را به همراه میآورد.
برخی از مثالهای کلیدی ساختارهای تیم اجایل به شرح زیر است:
عامگرایی
همانطور که از نامش پیداست، ساختار عامگرایی بهگونهای است که هر یک از اعضای تیم درکی عمومی از گستره وسیعی از موضوعات دارند، بدون اینکه عمیقا روی موردی خاص تمرکز کرده باشند. به عبارت دیگر، ساختار عامگرایی به دنبال «آچار فرانسه» میگردد، افرادی که اندکی راجع به هرچیزی میدانند. به خاطر همین همهفنحریفی، اعضا میتوانند روی وظایف مختلفی کار کنند و خیلی راحت جایشان را به همکاران بدهند. این ساختار اجایل عمدتا در تیمهای کوچکتر دیده شده و در صنعت فروش جواب میدهد. در این صنعت، متخصصان باید از دانش بنیادین خود برای فروش محصولات در انواع و اقسام بازارها استفاده کنند.
خاصگرایی
در طرف متضاد عامگرایی، ساختار خاصگرایی به دنبال افرادی میگردد که تخصصهایی مشخص دارند. در این ساختار، هرکسی در حوزه خاص خود کار میکند و مسئولیت وظایفی که در همان دامنه قرار میگیرند را برعهده دارد. این «گوروها» اعضایی بسیار ارزشمند برای تیم به حساب میآیند، چرا که دانش خود در حوزههای پیچیده را به کار میگیرند و در نتیجه، محصولی با کیفیتتر حاصل میشود. این ساختار بیشتر در تیمهای بزرگتر اجایل رایج است که نیروی انسانی به اندازه کافی برای پوشش دادن تمام حوزهها وجود دارد. از جمله افراد متخصص میتوان به برنامهنویسان، مدیران پایگاه داده و توسعهدهندگان محصول اشاره کرد.
هیبرید
ساختار هیبرید در واقع ترکیبی از دو ساختار عامگرایی و خاصگرایی است. در چنین تیمی، هر متخصص بر ساختن اجزای پیچیده خود در پروژه متمرکز است و آچار فرانسهها هم این اجزا را به یکدیگر پیوند زده و اطمینان حاصل میکنند که تمام پروژه منطقی باقی میماند. انعطافپذیری ناشی از ساختار هیبرید نیز کاملا با ارزشهای اجایل سازگاری دارد. این یعنی تیمهای اجایل میتوانند آموزههای رویکردهای عامگرا و خاصگرا را یکجا فرا بگیرند. از جمله مزایای ساختار هیبرید میتوان به کار تیمی بهبودیافته، دستاوردهای با کیفیت و حس مالکیت بیشتر اشاره کرد.
موازی
در ساختار موازی، اعضای تیم اجایل وظایف خود را بعد از هر برهه توسعه تغییر میدهند. برای مثال اگر همه در یک اسپرینت مشغول کار روی توسعه نرمافزار باشند، در اسپرینت بعدی به سراغ تست نرمافزار خواهند رفت. به این ترتیب، تیمها میتوانند کارهای نرمافزار را به صورت موازی پیش ببرند. این رویکرد البته نیازمند آموزش سازمانی گسترده و اعضایی مجرب در تیم است که بتوانند فورا خودشان را با سمتهای تازه تطبیق دهند.
خرده تیم
در این ساختار اساسا شاهد شکلگیری تیمی در بطن یک تیم دیگر هستیم. خرده تیمها را میتوان واحدهایی مستقل به حساب آورد که درون تیمهای اجایل بزرگتر شکل میگیرند. این تیمها روی حوزهای بهخصوص تمرکز میکنند که در نهایت با سایر دستاوردهای پروژه ادغام میشود. ساختار خرده تیم زمانی به کار گرفته میشود که میخواهید پروژههای بزرگ را به قطعاتی کوچکتر و قابل هضم تقسیم کنید.
تیم اجایل: نقشها و مسئولیتهای کلیدی در اجایل چیست؟
ساختار تیم اجایل معمولا بهگونهای است که نقشهایی مشخص برای هر عضو تیم دارد. اگرچه تمرکز عمدتا بر مجموعه مهارتهای فردی است و نه سمت شغلی صرف، اما نقشهای از پیش تعریف شده میتوانند وضوح را به جریانهای کاری اجایل بیاورند.
این نقشها بسته به روششناسی مدیریت پروژه منتخب تیم، متغیر خواهند بود. در محیط اسکرام، نقشهایی از پیش تعریف شده داریم. اما تیمهای کانبان از طرف دیگر میتوانند رویکردی منعطفتر در پیش بگیرند و خبری از سمتهای شغلی اجباری و ضروری نیست.
بیایید ببینیم برخی از نقشهای کلیدی در ساختار تیم اجایل چیست.
رهبر تیم (Team Lead)
رهبر تیم مسئولیت هماهنگسازی امور مربوط به تیم و حصول اطمینان از پیشروی امور به شکلی روان را برعهده دارد. او درخواستهای دریافتی را سامان میدهد، به مدیریت وظایف میپردازد، جریانهای کاری را پایش میکند و به میزبانی انواع جلسات اسکرام مشغول میشود. او ضمنا باید اطمینان یابد که تیم در حال پیروی از اصولی است که در مانیفست اجایل به آنها پرداخته شده. در اسکرام، تیم لید یا رهبر تیم تحت عنوان «اسکرام مستر» شناخته میشود.
مالک محصول (Product Owner)
مالک محصول کسی است که به نمایندگی نیازهای مشتری مشغول میشود. وظیفه او این است که پیشنیازهای مشتری را به شکلی واضح ترسیم کند و به حصول اطمینان از این بپردازد که تمامی آنها در چرخه عمر پروژه اجایل مورد توجه قرار میگیرند. مالک محصول ارتباطی مداوم با تیم برقرار میکند و به اعضا راهنمایی میرساند: مثلا راجع به اینکه باید به سراغ کدام ویژگیها رفت و چه چیزهایی را اولویتبندی کرد.
عضو تیم (Team Member)
«عضو تیم» عبارتی گسترده است که میتواند مجموعهای عظیم از نقشهای مختلف را در بر بگیرد. برای مثال یک تیم توسعه اجایل از برنامهنویسان، طراحان تجربه کاربری، توسعهدهندگان نرمافزار و تسترهای کنترل کیفیت تشکیل شده است. از سوی دیگر، یک تیم دیجیتال مارکتینگ میتواند سمتهایی مانند کپی رایتر، ادیتور، مدیر تبلیغات کلیکی، سئو کار و مواردی از این دست را شامل شود.
ذینفع (Stakeholder)
ذینفع کسی است که مشارکت مستقیم در فعالیتهای مربوط به پروژه ندارد، اما نقشی مهم در تعیین دستاوردهای نهایی ایفا میکند. ذینفعان ارتباطی مداوم با رهبر تیم، مالک محصول و اعضای تیم برقرار کرده و بازخوردهای خود را راجع به فرایند توسعه ارائه میکنند. بازخورد این افراد میتواند تاثیری شگرف روی پروژه گذاشته و خروجی آن را دگرگون سازد. از جمله مثالهای افراد ذینفع میتوان به کاربران نهایی، سرمایهگذاران شرکت و مدیران ردهبالای شرکت اشاره کرد.
چطور به ساختار تیم اجایل شکل بدهیم؟
میخواهید به ساختار تیم اجایل خود شکل بدهید و نمیدانید کار را از کجا شروع کنید؟ کافیست گامهای زیر را در پیش بگیرید:
- مدل خود را برگزینید: پروژه شما در حالت عامگرایی بهتر پیش خواهد رفت یا در حالت خاصگرایی؟ آیا به منابع لازم برای ساختار هیبرید دسترسی دارید؟ آیا پروژه شما آنقدر بزرگ هست که نیازمند خرده تیمها باشد؟ این فاکتورها را تحلیل کنید تا قادر به انتخاب بهترین ساختار ممکن برای خود باشید.
- نقشها را واگذار کنید: اندکی وقت گذاشته و پیش از واگذاری سمتهای شغلی، ببینید مهارتهای اعضای تیم اجایل چیست. اطمینان حاصل کنید که هر یک از اعضا از ظرفیتهای لازم برای رسیدگی به نقش و مسئولیت خود برخوردار هستند.
- تطبیقپذیر باقی بمانید: به خاطر داشته باشید که ساختار تیم اجایل باید انعطافپذیر و با نیازهای شما تطبیقپذیر باشد. به سخنان تیم خود توجه نشان دهید و وقتی چیزی به خوبی کار نمیکند، تغییرات لازم را پیادهسازی کنید.
چارچوب چابک مقیاس پذیر (SAFe) چیست؟
شاید عبارت «SAFe» به گوشتان خورده باشد و ندانید معنای آن در دنیای اجایل چیست. SAFe مخفف «Scaled Agile Framework» به معنای «چارچوب چابک مقیاسپذیر» است و دانشی بنیادین به حساب میآید که تیمهای توسعه از آن برای پیادهسازی قواعد اجایل در سازمانهای بزرگ استفاده میکنند. در این چارچوب، بهترین رویکردهای مدیریت پروژه اجایل بهگونهای دچار تغییر میشوند که این روششناسی را به گزینهای مناسب برای تیمهای بزرگتر تبدیل کنند.
SAFe برای نخستین بار در سال ۲۰۱۱ میلادی از راه رسید و از آن موقع، محبوبیتاش صرفا بیشتر و بیشتر شده است. نظرسنجی KPMG Global Agile در سال ۲۰۱۹ میلادی نشان داد که SAFe رایجترین چارچوب مورد استفاده برای اجایل مقیاسپذیر است. ناگفته نماند که SAFe دانش به دست آمده از چهار حوزه مختلف را با هم در میآمیزد: توسعه اجایل، توسعه محصول ناب (Lean)، تفکر سیستمی و DevOps. در واقع رویکردهای اجایل و لین با یکدیگر ترکیب شده و در سطحی از سازمان به کار گرفته میشوند که چابکی تجاری افزایش یابد و سازمان قادر به افزایش ابعاد خود باشد.
SAFe در مجموع به سه بخش مختلف تقسیم میشود: تیم، برنامه و سبد محول. این چارچوب در هر سه سطح باعث قرارگیری سازمان در مسیر صحیح میشود.
ارزشهای بنیادین SAFe
درست مانند مانیفست اجایل، چارچوب چابک مقیاسپذیر هم براساس چهار ارزش بنیادین شکل گرفته است که در ادامه به سراغ آنها خواهیم رفت.
- همسویی: وقتی شرکتها در حال افزایش مقیاس اجایل هستند، تمام تیمها در سراسر سازمان باید شکلی همسو به خود گرفته و هدفی مشترک را دنبال کنند. این موضوع به خصوص برای تیمهایی که از نظر جغرافیایی با یکدیگر فاصله دارند ضروری است، چرا که عدم همسویی میان آنها میتوان تواناییهای شرکت در واکنش نشان دادن به تغییر را مختل کند. SAFe با فراهم آوردن همسویی، مشخص کردن نقشهای تیمی و همگامسازی فعالیتها به سازمانها اجازه میدهد که در رقابت باقی بمانند.
- درونیسازی کیفیت: SAFe تمام سازمان را به ارائه بالاترین استانداردهای کیفی تشویق و اطمینان حاصل میکند که این موضوع، اصلیترین اولویت تیمها باشد. پیادهسازی این استانداردهای کیفی در چرخه عمر توسعه بسیار مهم است، خصوصا در سیستمهایی با ابعاد بزرگ که کارهای عقب افتاده میتوانند خیلی سریع تلنبار شوند. SAFe منجر به درونسازی کیفیت در پنج دستهبندی مختلف میشود: جریان، کیفیت معماری و طراحی، کیفیت کد، کیفیت سیستم و کیفیت عرضه.
- شفافیت: برای اینکه بتوان در تیمها اعتمادسازی کرد و محیطی آزاد درون سازمان فراهم آورد، باید شفافیت را در اولویت قرار دهید. SAFe با حصول اطمینان از اینکه همه به بک لاگ محصول دسترسی دارند، اهدافی واضح را دنبال و وظایف بزرگ را به تعهدهای کوتاهمدت بدل میکنند، سطح شفافیت را بالا میبرد و بنابراین، موانع بالقوه هم به سرعت شناسایی میشوند.
- پیادهسازی برنامه: ساختن نرمافزارهایی که به خوبی کار میکنند یکی از اصلیترین اهداف SAFe و همینطور روششناسی اجایل است. تیمها باید قادر به پیادهسازی موفقیتآمیز برنامهها باشند تا ارزش تجاری حقیقی خلق کنند. به همین خاطر است که SAFe تاکیدی شدید بر سیستمهای قابل اتکا دارد که به صورت مداوم، خروجیهای سودمند به همراه میآورند.
۱۰ اصل SAFe
گذشته از ارزشهای بنیادینی که به آنها اشاره کردیم، چارچوب چابک مقیاسپذیر ۱۰ اصل کلیدی نیز دارد که به شرح زیر هستند.
۱. ذهنیت اقتصادی
داشتن ذهنیت اقتصادی یکی از اصلیترین عناصر روششناسی ناب یا لین به حساب میآید. مدل SAFe هم ارائه زودهنگام و مداوم نرمافزار و همینطور فراهم آورن چارچوبهای صحیح اقتصادی را تشویق میکند. بدین شکل تاخیرها کاهش مییابند و در نتیجه، هزینهها هم کمتر میشود.
۲. تفکر سیستمی
تفکر سیستمی سه مفهوم کلیدی را دنبال میکند: راهکار یک سیستم است، سازمانی که سیستم میسازد نیز خود یک سیستم است و در نهایت باید به بهینهسازی تمام جریان امور مشغول شد. با سادهسازی این سه مفهوم، SAFe اجازه میدهد نمایی همهجانبه از راهکارهای در دست توسعه داشته باشید.
۳. گذاشتن فرض بر تغییرپذیری و حفظ گزینهها
تغییرپذیری اتفاقی است که به شکلی اجتنابناپذیر در دنیای اجایل رخ میدهد. اما به جای اجتناب از آن، توسعهدهندگان باید مدیریت موثر تغییرات را آموخته و گزینههای خود را حفظ کنند. این رویه شامل فراهم آوردن چندین طراحی مختلف در ابتدا، ارزیابی مداوم آنها و سپس حذف کردن موارد ناخواسته میشود.
۴. توسعه تدریجی با چرخههای یادگیری سریع
این اصل هم به دنبال کاهش ریسکها است و از شما میخواهد به جای تنها یک گزینه، چندین طراحی اولیه داشته و دست خود را باز بگذارید. در سراسر فریند توسعه میتوان به ساخت تدریجی نرمافزار مشغول شد و هر برهه توسعه نیز، فعالیتهای برهه قبلی را بهبود میبخشد.
۵. تعیین دستاوردها براساس ارزیابی عینی سیستمهای در حال کار
با استفاده از سیستمی در حال کار به عنوان یک مدل، تیمها میتوانند تصمیماتی بهتر اتخاذ رده و به برنامهریزی برای دستاوردهای خود مشغول شوند. از جمله مثالهای دستاورد میتوان به طراحی، توسعه و تست اشاره کرد. بازخورد دائمی ذینفعان نیز اهمیت و ارزش فراوان دارد و باعث حصول اطمینان از بازگشت سرمایه میشود.
۶. تصویرسازی و محدودسازی کارهای در جریان، کاهش ابعاد وظایف و مدیریت کارهای باقیمانده
برای اینکه جریان کارها بهبودی چشمگیر داشته باشد، SAFe پیشنهاد میکند که به سه عنصری که بالاتر به آنها اشاره کردیم توجه داشته باشید. تیمها میتوانند با استفاده از برد کانبان، شفافیت کار را بالا ببرند، ابعاد وظایف را کوچکتر کنند تا هزینهها کاهش یابد و نرخ پردازش را بالا ببرند تا مدتزمان معلق باقی ماندن کارهای بعدی کوتاه شود.
۷. همگامسازی ریتم با برنامهریزیهای چند دامنهای
«الگوی موزون رخدادها» باعث شکلگیری روتین و ساختار در بطن فرایند توسعه میشود. وقتی این ریتمها با یکدیگر همگام شوند، رخدادهای مختلف به صورت همزمان به وقوع میپیوندند و بنابراین نقطهنظرهایی هر چه بیشتر برای اتخاذ تصمیمات صحیح خواهید داشت.
۸. بهرهگیری از انگیزههای ذاتی کارمندان
با استفاده از مدل SAFe، رهبران میتوانند به روشهای مختلف انگیزه موجود در کارمندان را افزایش دهند: چه با ارائه پاداش، چه گوش سپردن به آنها و ارائه بازخورد مداوم و چه فراهم آوردن استقلال لازم برای اینکه خودشان به امور رسیدگی کنند.
۹. تصمیمگیری غیر متمرکز
اگرچه تصمیمات استراتژیک کماکان باید از سوی رهبران سازمان اتخاذ شوند، سایر تصمیمات را میتوان به اعضای تیم واگذار کرد. بدین ترتیب، این اعضای تیم توسعه هستند که تصمیمات مداوم و حساس از نظر زمانی را اتخاذ میکنند و رهبران هم قادر به تمرکز بر اولویتهای بزرگتر خواهند بود.
۱۰. سازمانیافتگی پیرامون ارزشها
با بهرهگیری از الگوهای سازمانی بهخصوصی که در مدل SAFe تشریح شدهاند، سازمانها قادر به دستیابی به دستاوردهای گوناگون بوده و به سرعت به نیازهای در حال تغییر مشتریان واکنش نشان میدهند. این رویکرد باعث میشود در محیط اجایل شاهد ساختار بیشتری باشیم و به شکلی بهینه به ارزشسازی مشغول شویم.
مزایای مدل SAFe
راهنمایی و دانشی که چارچوب چابک مقیاسپذیر با خود به همراه میآورد، منافع فراوانی برای تیمهای اجایل دارد. برخی از این منافع را در بطن همان چهار ارزش بنیادین مشاهده کردیم: همسویی بیشتر، محصولات با کیفیت، شفافیت افزایشیافته و پیادهسازی موفقیتآمیز.
از دیگر مزایا میتوان به موارد زیر اشاره کرد:
- تعامل بهتر: SAFe باعث میشود تیمهای اجایل به شکلی موثر بر سر پروژهای واحد همکاری کنند و بنابراین نرخ تعامل و بهرهوری کارمندان افزایش مییابد.
- ساختار ساده: خط قرمزها و تعاریف ارائه شده از سوی مدل SAFe نوعی حس ساختارمندی به سازمان میآورد.
- ورود سریعتر به بازار: با بهینهسازی جریان ارزش، مدل SAFe باعث کاهش مدتزمان رسیدگی به پیشنیازها و شتاب گرفتن عرضه محصول میشود.
در نهایت باید افزود که منافع SAFe کاملا واضح هستند، اما این لزوما بدان معنا نیست که راجع به بهترین چارچوب برای تیم شما صحبت میکنیم. در ادامه مقاله اجایل چیست، در این زمینه راهنماییتان خواهیم کرد.
آیا مدل SAFe برای تیم شما مناسب است؟
پیش از هرچیز و مهمتر از هر چیز باید گفت که چارچوب چابک مقیاسپذیر برای پروژههایی در ابعاد بزرگ مناسب است. اگر شرکت بخواهد مقیاس رویکردهای اجایل را در میان تیمها، سبد محصولات و برنامههای مختلف گسترش دهد، در آن صورت SAFe گزینهای کاملا ایدهآل خواهد بود.
یک سنایو دیگر میتواند زمانی باشد که افزایش مقیاس را پیشتر در سازمان خود آزمودهاید، اما شاهد یکپارچگی، همسویی و ثبات قدم نبودید. SAFe به شما کمک میکند این موانع را با یک استراتژی سازمانی درست و حسابی که تمام تیمها را با یکدیگر متحد میسازد، از میان بردارید.
SAFe ضمنا گزینهای مناسب برای شرکتهایی است که در حال گذار به اجایل هستند. اگر در زمینه اجایل تازهکار به حساب میآیید، احتمالا تردیدهای خودتان را راجع به ارزشها، اصول و نقشهای مدیریتی مختلف داشته باشید. SAFe با ارائه چارچوبی از پیش تعریف شده این مشکل را برطرف میکند و به شما در مسیر ساختار دادن به تیمها و تطبیق یافتن با روششناسی اجایل کمک میکند.
تم، اپیک، استوری و وظایف در اجایل چیست ؟
در بخش پایانی مقاله اجایل چیست از شما میخواهیم به یک داستان معمولی فکر کنید. چنین داستانی یک بخش اولیه، یک بخش میانی و یک بخش پایانی دارد، مگر نه؟ این مسیر خطی، بیشباهت به روششناسیهای سنتی مدیریت پروژه، مانند رویکرد آبشاری نیست. تمام رخدادها باید به ترتیب به وقوع بپیوندند تا همهچیز شکلی منطقی به خود بگیرد.
مدیریت پروژه اجایل اما اندکی متفاوت است. همانطور که تا این لحظه متوجه شدیم، اجایل مجموعهای از ارزشها و اصول را دنبال میکند، نیازمند ساختاری تیمی است و انعطافپذیری به مراتب بالاتری هم به نمایش میگذارد. بنابراین پروژه اجایل را میتوان به داستانی غیر خطی تشبیه کرد که اجازه میدهد انتخابهای خودتان را داشته باشید. تیمهای خودسامانده به پیشنیازهای بنیادین دسترسی یافته و سپس باید از مسیر رسیدن به محصول نهایی سر در بیاورند.
شاید بپرسید رویکرد تیمهای اجایل چیست؟ در پاسخ باید گفت آنها کارهای خود را به «مضامین» یا «تمها» (Themes)، «حماسهها» یا «اپیکها» (Epics)، «داستانهای کاربر» یا «یوزر استوری ها» (User Stories) و «وظایف» (Tasks) تقسیم میکنند. این کلمات احتمالا شما را یاد داستانهای دوران کودکی بیندازند و باید گفت که داستانسرایی واقعا هم نقشی کلیدی در دنیای اجایل ایفا میکند. تیمها بدین طریق قادر به درک پیشنیازها خواهند بود و به چارچوب خلاقانه مورد نیاز برای رسیدن به نقطه پایانی دسترسی خواهند یافت. ائتلاف اجایل میگوید که مربیان اجایل باید «روی تیمها اثر بگذارند و کاری کنند که به جهان از لنزی تازه نگاه کنند، و داستانسرایی یکی از قدرتمندترین ابزارهای در دسترس برای تحقق این مهم است».
بیایید شرایط را دقیقتر بررسی کرده و ببینیم معنی تمام این عبارات در جهان اجایل چیست.
ساختار کاری اجایل
همانطور که پیشتر در جریان مقاله اجایل چیست اشاره شد، در مدیریت پروژه اجایل شاهد چهار دستهبندی کلی هستیم: تمها، اپیکها، استوریها و وظایف.
- تمها: تم به معنای حیطه وسیعی از تمرکز است که به تیم اجایل در پایش اهداف سازمانی یاری میرساند. میتوانید به آن به چشم برچسبی نگاه کنید که روی مجموعهای از فعالیتهای مشابه زده میشود. تم به ما کمک میکند که مشخصههای مشابه را در حیطههای گوناگون یافته و آنها را زیر چتری واحد بیاوریم.
- اپیکها: اپیک یا حماسه به معنای مجموعهای از داستانهای کوچکتر است که با دیگری ترکیب شده و داستانی بزرگ را میسازند. اپیک را نمیتوان در یک برهه اجایل (یا اسپرینت در اسکرام) به پایان رساند. عنصر کلیدی اپیک این است که زمان زیادی میطلبد.
- استوریها: استوری یا داستان که تحت عنوان «یوزر استوری» هم شناخته میشود، خواستهای کوچک است که میتواند در یک اسپرینت برآورده شود. این خواسته از نقطهنظر کاربر و با زبانی ساده نوشته میشود. استوری پوینتها برای اندازهگیری میزان پیچیدگی یک داستان به کار گرفته میشوند. هدف غایی استوری، ارزشسازی برای کاربر است، آنهم در بازه زمانی مشخصی.
- وظایف: وظیفه یکی از زیر مجموعههای استوری است که به ما در خرد کردن داستان و تعیین نحوه به پایان رساندن آن یاری میرساند. وظایف معمولا به شکلی فنیتر نوشته میشوند، چرا که از سوی تیم توسعه مورد استفاده قرار میگیرند (مثلا تسترهای کنترل کیفیت) و مشتریان نهایی را درگیر خود نمیکنند.
- ابتکارها (Initiatives): ابتکار به معنای مجموعهای از اپیکها است. در واقع میتواند حاوی اپیکهای گوناگونی از تیمهای مختلف باشد، اما همه آنها هدفی یکسان را دنبال خواهند کرد. ابتکار طبیعتا هم نیازمند زمان بیشتری نسبت به اپیک است.
- قابلیتها (Features): قابلیت به معنای هر کارکرد یا خدمتی استی که نیاز ذینفعان را برطرف میکند. هر قابلیت باید بسته به معیارهای مختلفی شکل گرفته باشد و ارزش تجاری بهخصوصی به ارمغان بیاورد.
اپیک در برابر استوری
هر استوری در واقع یک پیشنیاز واحد به حساب میآید و اپیک هم مجموعهای از داستانهای مختلف است. پروژهای را تصور کنید که انبوهی فولدر یا پوشه دارد. این فولدرها هرکدام داستانی مجزا به حساب میآیند که به البته به طریقی به یکدیگر مرتبط میشوند. در واقع همه همگی ترکیب میشوند تا پروژهای بزرگتر را بسازند که همان اپیک است.
تفاوت کلیدی دیگر میان اپیک و استوری، مدتزمان لازم برای رسیدگی به هرکدام است. استوری در جریان یک اسپرینت به پایان میرسد که میتواند چیزی بین یک یا دو هفته طول بکشد. از طرف دیگر، هر اپیک احتمالا نیازمند یک الی سه ماه باشد تا تکمیل شود.
تم در برابر وظیفه
تمها و وظایف بیشباهت به یکدیگر نیستند و هر دو به دستهبندی کردن امور و فراهم آوردن نوعی حس نظم و مدیریت کمک میکنند. با این حال، تم مجموعهای از اپیکها یا ابتکارها را گرد هم میآورد تا زیر چتری واحد و مرتبط جمع شوند. وظایف از طرف دیگر به خرد کردن داستان میپردازند.
تمها ضمنا گستردهتر بوده و میتوانند در سراسر شرکت و برای رسیدگی به هرچیزی از جمله اپیکها و استوریها و ابتکارها به کار بسته شوند. وظایف از طرف دیگر مقاصدی بسیار مشخصتر را دنبال میکنند. از وظایف فقط درون استوریها استفاده میشود و طراحی نشدهاند تا با کاربران نهایی به اشتراک شوند.
مطلب کامل و مبسوطی است. فقط نیاز به ویرایش داره چون ایرادات نگارشی زیادی داشت متاسفانه.
با سلام؛
از ارائه بازخورد شما بسیار سپاسگزاریم. این مورد را حتما در دستور کار قرار خواهیم داد.
با تشکر از همراهی شما با مجله فرادرس
خیلی عالی و جامع توضیح داده شد. البته به شخصه دوست دارم وقتی از اجایل صحبت میشه، به صورت عمومی تر صحبت بشه تا محدود بشه به پروژه های نرم افزاری