متدولوژی های توسعه نرم افزار

سلام. در دو مصاحبه آخر از من در مورد روش شناسی سوال شد. این مهم ترین یا سخت ترین سوال نیست، اما داشتن یک برگه تقلب برای پاسخ خوب خواهد بود. در این مقاله سعی خواهم کرد ایده ای از روش توسعه ارائه دهم و آنهایی را که شخصاً ملاقات کرده ام یا از آنها سؤال شده است مقایسه کنم. روش‌شناسی توسعه نرم‌افزار فرآیندی است برای توصیف چگونگی توسعه یک محصول خاص، یعنی یکی از راه‌های سازماندهی توسعه تیم. مدل‌های مختلفی از چنین فرآیندی وجود دارد که هر کدام رویکرد خاص خود را توصیف می‌کنند و نمی‌توان گفت که در بین آنها یکی وجود دارد که باید در هر پروژه استفاده شود، همه چیز کاملاً موقعیتی است. من پیشنهاد می کنم سه مورد از آنها را با جزئیات بیشتر در نظر بگیرم.

آبشار

آبشار (آبشار، آبشار) یکی از قدیمی‌ترین روش‌ها است و مستلزم اجرای متوالی دقیق تمام مراحل است که هر یک باید قبل از شروع مرحله بعدی تکمیل شود. یعنی انتقال به مرحله بعدی به معنای تکمیل کامل کار روی مرحله قبلی است. تصویر نشان می دهد که ابتدا کار را تجزیه و تحلیل می کنیم (وظایف را مستند می کنیم، مشکلات را مورد بحث قرار می دهیم)، سپس طراحی رخ می دهد (در این مرحله ساختار پروژه شکل می گیرد)، سپس کدگذاری و آزمایش می شود. برای مراحل بعدی هیچ بازپرداختی وجود ندارد. استفاده از چنین سیستمی در پروژه های کوچکی که الزامات آن از قبل مشخص است و احتمال تغییر آنها کم است، توصیه می شود. مزایای:

• مستندات کامل و منسجم در هر مرحله؛
• راحتی در استفاده؛
• الزامات پایدار
• بودجه و ضرب الاجل از قبل تعیین شده است

ایرادات:

• حجم زیادی از اسناد؛
• یک سیستم بسیار انعطاف پذیر نیست.
• مشتری نمی تواند نسخه آزمایشی محصول را مشاهده کند.
• هیچ راهی برای بازگشت به یک قدم وجود ندارد.

اسکرام

اسکرام یک سیستم توسعه نرم افزاری است که بر اساس تقسیم کل فرآیند به تکرارها است که در پایان هر یک از آنها تیم آماده ارائه یک نسخه آزمایشی از محصول است. تصویر نشان می دهد که تیم تمام مراحل توسعه را به صورت موازی طی می کند، که به ما امکان می دهد در پایان هر تکرار یک قسمت تمام شده از پروژه را داشته باشیم. من سعی خواهم کرد به طور خلاصه ماهیت روش شناسی را با کلمات ساده توضیح دهم، اما در اینجا اصطلاحات زیادی وجود دارد. من فکر می کنم مهم ترین چیز درک اصل است و اصطلاحات با تجربه به یاد می آیند. تمام رشد به دوی سرعت (اغلب 2-3 هفته) تقسیم می شود. یک بک لاگ (لیست وظایف) برای کل دوره توسعه و برای هر سرعت به طور جداگانه وجود دارد . هر وظیفه نقطه داستانی خاص خود را دارد (رده بندی دشواری). هر شرکت کننده در فرآیند نقشی دارد:

• تیم اسکرام تیمی است که روی یک پروژه کار می کند (توسعه دهندگان، آزمایش کنندگان، طراحان).
• اسکرام مستر شخصی است که از رعایت اصول اسکرام اطمینان می دهد.
• صاحب محصول - مشتری.

از آنجایی که در این سیستم تاکید بر ارتباطات است، تعداد زیادی تجمع وجود دارد:

• استند آپ یک جلسه کوتاه است که هر روز برگزار می شود، همه اعضای تیم شرکت می کنند و هر شرکت کننده به 3 سوال پاسخ می دهد: چه کار کردید؟ چه خواهد کرد؟ و مسدود کننده ها چیست؟
• برنامه ریزی – در ابتدای اسپرینت برگزار می شود و در این جلسه مشخص می شود که در اسپرینت بعدی چه کارهایی باید انجام شود.
• گذشته نگر در پایان دوی سرعت برگزار می شود و ماهیت آن این است که بفهمیم چه کاری به خوبی انجام شده است و چه چیزی می تواند بهبود یابد.

مزایای:

• مشتری می تواند نتیجه را در طول فرآیند توسعه مشاهده کند.
• کنترل روزانه بر روند توسعه.
• توانایی انجام تنظیمات در طول توسعه.
• ارتباطات خوب با تمام اعضای تیم.
• مقدار کمی از اسناد.

ایرادات:

• برآورد نیروی کار و هزینه مورد نیاز برای توسعه مشکل است
• تعیین بزرگترین تنگناها قبل از شروع توسعه دشوار است.
• نیاز به مشارکت همه در توسعه سایر اعضای تیم.

کانبان

Kanban سیستمی است که بر روی تجسم فرآیند تکمیل وظایف تیمی ساخته شده است. ایده اصلی در این سیستم کاهش تعداد کارهایی است که در حال حاضر در حال انجام هستند (در ستون "در حال پیشرفت"). خوب برای پروژه هایی که در مرحله پشتیبانی هستند، جایی که عملکرد اصلی قبلا توسعه یافته است و حداقل پیشرفت ها و رفع اشکال باقی مانده است. در کانبان، وظایف به صورت جداگانه ارسال می شوند. وظیفه بدون توجه به سایر وظایف، تمام مراحل روی برد را طی می کند و به محض اتمام می تواند به مشتری نشان داده شود. یک تابلوی کانبان از ستون هایی تشکیل شده است که هر کدام نشان دهنده یک فرآیند توسعه جداگانه است. برخی از ستون‌ها (مثلاً در حال انجام) محدودیت‌هایی را برای تعداد کارهایی که می‌توانند وجود داشته باشند، اعمال می‌کنند. این کمک می کند تا به راحتی و به سرعت مناطق مشکل را در توزیع وظایف پیدا کنید. تصویر نمونه ای از چنین تخته ساده ای را نشان می دهد. تعداد ستون ها و نام ها ممکن است متفاوت باشد، اما من رایج ترین آنها را نام می برم:

• برای انجام - لیستی از کارهایی که باید انجام شوند
• در حال انجام - کارهایی که در حال حاضر روی آنها کار می شود
• بررسی کد - وظایفی که تکمیل شده و برای بررسی ارسال شده است
• در تست - وظایف آماده برای آزمایش
• انجام شد - کارهای انجام شده

مزایای:

• راحتی در استفاده.
• تجسم (به یافتن تنگناها کمک می کند، درک را ساده می کند)
• مشارکت بالای تیم در خود فرآیند.
• انعطاف پذیری بالا در توسعه

ایرادات:

• لیست وظایف ناپایدار
• استفاده از آن در پروژه های بلند مدت مشکل است.
• بدون ضرب الاجل سخت

در پایان در مورد متدولوژی توسعه نرم افزار

به نظر من، افرادی که پست های مدیریتی دارند یا آرزوی آن را دارند باید درک کاملی از متدولوژی های توسعه نرم افزار داشته باشند، اما برای همه توصیه می شود که حداقل اصول اولیه را بدانند. این بخشی جدایی ناپذیر از فرآیند توسعه است و نه تنها در زمینه فناوری اطلاعات استفاده می شود. از اینکه وقت گذاشتید و مقاله من را خواندید متشکرم، امیدوارم برایتان مفید بوده باشد. من سعی کردم فقط نکات کلیدی را تا حد امکان واضح و مختصر شرح دهم، بنابراین مقاله جامع نیست. خوشحال می شوم نظر شما را در مورد آن بشنوم و به سوالات شما پاسخ دهم. بهترین ها!