|
درباره وبلاگ  برای همه خوبی بخواه و خوش نیت باش تا بهترین ها نصیبت بشه صلوات صلوات صلوات علی محمد و ال محمد و عجل فرجهم 
آرشیو وبلاگ
لینک های ویژه لوگو 
آمار وبلاگ
 آقاشیر صلوات صلوات صلوات علی محمد و ال محمد و عجل فرجهم
روش SCRUM در روش‌های قدیمی و معمول ساخت نرم‌افزار، طراحان نرم‌افزار معمولاً ابتدا فرض می‌کنند که تمامی نیازهای کاربران سیستم را درک کرده‌اند. اما همیشه نیازهای کاربران سیستم در ابتدا مشخص نیست و کاربران ممکن است در همان مراحل ابتدایی، نیازهای خود را تغییر دهند و این چیزی است که برنامه‌نویسان و طراحان سیستم همیشه از آن شکایت می‌کنند و به دنبال راه‌حلی برای رفع این موضوع می‌گردند. به‌عنوان مثال مدل قدیمی آبشاری (waterfall) را در نظر بگیرید. این مدل حاوی مشکلات فراوانی است که به صورت مستقیم به غیرقابل انعطاف‌بودن این مدل ارتباط دارد. این مدل مانند یک جاده یک طرفه می‌باشد که وقتی اتومبیل در آن حرکت می‌کند، نمی‌تواند مسیر خود را تغییر دهد و در جهت دیگری حرکت کند. در ابتدای کار کاربر سیستم ممکن است نظراتی در مورد سیستم داشته باشد ولی نمی‌تواند ببیند که سیستم چگونه کار خواهد کرد و در نتیجه ممکن است وقتی که سیستم آماده شد، از ساختار و کارایی آن راضی نباشد و تقاضای تغییر در سیستم را بنماید. در نتیجه اگر بتوانیم کاربر را از ابتدا در جریان ساخت نرم‌افزار قرار دهیم، ممکن است که این مشکل حل شود؛ زیرا می‌تواند نظرات خود را در طول مدت ساخت و قبل از اتمام کار اعلام کنند و در نتیجه از نرم‌افزار تهیه شده راضی باشد. امروزه یکی از روش‌های تولید نرم‌افزار که به خصوص برای پروژه‌های نرم‌افزاری کوچک مورد استفاده قرار می‌گیرد و توسط بسیاری از اساتید و صاحب‌نظران مورد تأیید قرار گرفته است، روش SCRUM است. با استفاده از این روش که روشی به اصطلاح (iterative تکراری یا چرخشی) می‌باشد، می‌توان نرم‌افزارهای کوچک را با کیفیت بالا تهیه نمود. در این روش که به روش هوشمند یا Agile نیز مشهور است، مدیریت قوی تولید نرم‌افزار وجود دارد که به برنامه‌نویسان اجازه می‌دهد با استفاده از آن در پروژه‌ها به سرعت نرم‌افزار موردنظر را تهیه نمایند. اسم Scrum در حقیقت از بازی راگبی گرفته شده است (در بازی راگبی Scrum تیمی متشکل از هشت نفر است که با همکاری بسیار نزدیک با یکدیگر بازی می‌کنند). در این روش هر عضو از گروه موظف به درک وظیفه خود در پروژه است و باید یک هدف مشخص را در تمامی مراحل عملیاتی یا فازهای اجرایی دنبال کند. لازم به ذکر است که در Scrum هر فاز عملیاتی سیستم به Sprint مشهور است. روش Scrum همانند پروسه‌های دارای مرحله برنامه‌ریزی مقدماتی یا Initial Planning است. در این فاز اعضای تیم باید یک نقشه مقدماتی و یک معماری سیستم قابل تغییر به وجود آورند. بعد از این فاز یک سری از Sprintها به صورت مرتب و جزء جزء نرم‌افزار مورد نظر را به وجود میآورند. انجام دادن هر Sprint ممکن است از یک تا چهار هفته به طول بینجامد و مجموع این Sprintها نرم‌افزار کاملی را به‌وجود میآورند. فهرست تکالیف در هر Sprint به Backlog مشهور است که تکالیف تیم عملیاتی در هر Sprint را مشخص می‌کند. این Backlog در هر Sprint بروز می‌شود و هر تکلیف براساس اهمیتی که دارد در فهرست تکالیف تعیین اولویت می‌گردد. هر فرد در گروه یک کار یا تکلیف خاص از این فهرست را به عهده می‌گیرد و موظف می‌شود تا شروع Sprint بعدی آن را به اتمام برساند. وقتی که یک Sprint شروع شد، دیگر انجام هیچ تغییری در تکالیف امکان ندارد و حتی درخواست‌کننده نرم‌افزار نیز حق تغییر یا درخواست نیاز دیگری در نرم‌افزار را نخواهد داشت. البته درخواست‌کننده می‌تواند از قسمتی از نرم‌افزار که باید در هر مرحله تولید شود بکاهد، اما نمی‌تواند تاریخ تحویل آن قسمت را تغییردهد. شاید بتوان گفت که این کار باعث ایجاد نظم در گروه می‌شود و تاریخ تحویل نرم‌افزار به تعویق نخواهد افتاد. علاوه بر این، در طول هر Sprint گروه موظف است روزانه جلساتی جهت بررسی روند پیشرفت و قابلیت‌های نرم‌افزار داشته باشد که این نیز به هماهنگی بیشتر گروه کمک خواهد کرد. در این جلسات که معمولاً به صورت روزانه است، سه گروه می‌توانند شرکت کنند: گروه تهیه‌کننده نرم‌افزار، مدیریت، و درخواست‌کنندگان نرم‌افزار. در طول این جلسات مسئول جلسه که اغلب مدیر پروژه است، از تمامی اعضای تیم سه سؤال می پرسد: 1- مسئولیت شما (تکالیف) از جلسه قبلی تاکنون چه بوده است و آیا توانسته‌اید این تکالیف را به اتمام برسانید؟ 2- در طول این دوره به چه مشکلاتی برخورده‌اید؟ 3- بر طبق فهرست وظایف، مسئولیت شما از حالا تا جلسه بعدی چه خواهد بود؟ مدیر Scrum در حقیقت مسئولیت شناسایی تکالیف محوله به اعضا، بررسی روند تکمیلی ساخت نرم‌افزار، بررسی قابلیت‌های اعضای گروه و فعالیت در راستای کم کردن ریسک در پروژه را داراست. اما چه تفاوتی بین Scrum و دیگر روش‌های تولید نرم‌افزار وجود دارد؟ در جواب این سؤال باید یادآورشد که در Scrum هر مرحله یا Sprint قسمتی از نرم‌افزار را آماده می کند. در این روش می توان پیشرفت در تولید نرم‌افزار را در هر مرحله به خوبی احساس نمود. علاوه بر این، گروه می‌تواند پس از اتمام هر Sprint تصمیم‌گیری‌کند که آیا می خواهد به کار روی پروژه ادامه دهد یا انجام پروژه مذکور غیرممکن است. روش Scrum وقتی می‌تواند بیشتر مفید باشد که در ابتدای پروژه نیازهای کاربران به صورت دقیق مشخص نباشد و یک گروه کوچک مسئول پروژه نرم افزاری باشد. نتایج تحقیقاتی که اواخر سال 2005 روی چندین شرکت تولیدکننده نرم‌افزار در کشور انگلستان انجام دادم، نشان‌دهنده این بود که شرکت‌هایی که از Scrum استفاده کرده بودند با حدود چهارصددرصد افزایش در بهره‌وری کار مواجه بودند. البته این رقم در گروه‌های نرم‌افزاری مختلف متفاوت بود و می‌توان گفت عوامل انسانی از جمله مدیر پروژه نقش بسیار مهمی در افزایش یا کاهش راندمان پروژه ها دارند. شاید این سؤال در ذهن شما به وجود آید که چرا Scrum ممکن است برای تولید نرم‌افزارهای کوچک راه حل خوبی باشد؟ در جواب می‌توان گفت، از آن جایی که در تیم‌های کوچک، اعضای گروه باید از تمامی مسائل پروژه آگاه باشند و در Scrum تمامی مراحل ساخت توسط تمامی اعضای گروه قابل مشاهده است. لذا این روش می‌تواند روش مناسبی باشد. معایب روش Scram مزایای استفاده از Scrum بسیار است، اما این روش چند اشکال نیز دارد. از جمله: 1- Scrum روش جدیدی است و با روش‌های مرسوم تفاوت‌های زیادی دارد. 2- برخی از برنامه‌نویسان حرفهای ممکن است از تکالیفی که مدیر Scrum به ایشان می‌دهد راضی نباشند و بخواهند روش قدیمی خود را اجرا نمایند و در صورت اجبار، در روند اجرای پروژه کارشکنی کرده و مشکل‌آفرینی کنند. 3- از آنجا که مدیر Scrum هم از نظر کیفی و هم کمی باید پروژه را مدیریت کند، Scrum نیاز به مدیریت بسیار قدرتمند دارد. 4- Scrum را می‌توان به عنوان روش تولید نرم‌افزار نام برد، اما این روش بیشتر روش مدیریت پروژه هوشمند خوبی است و نمی‌توان آن را به صورت منفرد استفاده نمود و می‌توان گفت برای حصول اطمینان از موفقیت پروژه‌های نرم‌افزاری (به خصوص در سطح کوچک) باید این روش را با روش‌های دیگر ادغام نمود. Scrum را از آن جهت می‌توان روش خوبی برشمرد که روشی تحقیقی براساس تخمین، اولویت‌بندی، عملکرد گروه و بررسی نتایج است که اگر به صورت صحیح مورد استفاده قرار گیرد و قبل از استفاده به صورت کامل آموزش داده شود، می‌تواند راندمان پروژه‌های نرم‌افزاری، به خصوص تولید نرم‌افزارهای کوچک را به صورت بسیار محسوسی بالا ببرد. روش XP اشتباه نکنید! منظور از روش اکس‌پی، ویندوزاکس‌پی نیست. اکس‌پی مخفف Extreme Programming یا برنامه‌نویسی سریع می‌باشد که مانند Scrum روشی هوشمند در تولید نرم‌افزار است. در اکس‌پی دو برنامه‌نویس کار را انجام می‌دهند و قبل از اتمام برنامه آن را چندین‌بار امتحان می کنند. اکس‌پی در حقیقت روشی از تولید نرم‌افزار است که براساس آسانی، ارتباط، واکنش و تصمیم‌گیری سریع استوار است. شکل 2 اصول روش اکس‌پی را نشان می‌دهد. در روش اکس‌پی اعضای گروه (که کاربر سیستم نیز عضوی از آن است) در ابتدا جلسه‌ای تشکیل می‌دهند و اولویت‌های پروژه را مشخص می‌کنند. این گروه ممکن است از چند برنامه‌نویس، امتحان‌کننده نرم‌افزار یا Tester و تحلیلگر سیستم تشکیل شود که با هم از ابتدا تا انتهای پروژه همکاری می‌کنند. معمولاً در اکس‌پی برنامه‌نویسان در گروه‌های دوتایی قرار می‌گیرند و وظیفه تکمیل قسمتی از برنامه را برعهده می‌گیرند و هر دوی این برنامه نویسان در مورد هر کدام از نیازهای کاربران با هم بحث می کنند و قدم به قدم کلاس های برنامه را آماده می‌کنند. بدین ترتیب که در ابتدا کلاسی را به صورت ابتدایی و بدون هیچ طراحی اولیه به وجود میآورند و این کلاس را امتحان می‌کنند. در صورتی که این کلاس فاقد هر گونه اشکال باشد، کد اصلی برنامه را بر آن اساس می‌نویسند. وقتی یکی از برنامه‌نویسان مشغول نوشتن قسمتی از برنامه است، برنامه‌نویس دیگر وظیفه کنترل صحت این کدها را عهده‌دار است و در صورت مشاهده هر گونه اشکال، نویسنده کد را مطلع می‌کند. مانند Scrum، در اکس‌پی نیز اعضای گروه می‌توانند روند تکمیلی تولید نرم‌افزار را مشاهده کنند و در جریان کار قرار گیرند.اکس‌پی روش مناسبی برای مدیریت پروژه‌های کوچک می‌باشد که از دو تا ده برنامه‌نویس تشکیل شده است. اگر چه اصولاً اکس‌پی هیچ رویه خاص و مراحل پیوسته‌ای را مشخص نکرده اما می توان گفت که اکس‌پی داری چهار مرحله اصلی می باشد: الف: مرحله زمانبندی پروژه: در این مرحله اعضای گروه با توجه به اندازه نرم‌افزار و کارایی آن برنامه زمانبندی را با هم تنظیم می کنند. ب: طراحی ابتدایی ج: نوشتن کدهای برنامه د: امتحان‌کردن کدهای نوشته شده مطابق تحقیقاتی که توسط نویسنده انجام شد، مشخص گردید که اکس‌پی در پروژه‌های بزرگ با تعداد اعضای بالای ده نفر اصلاً موفق نخواهد بود و تنها می‌تواند برای پروژه‌های کوچک مفید باشد. دلیل آن را نیز می توان در طبیعت این روش دانست؛ زیرا مستندات چندانی برای نرم‌افزار وجود ندارد و فقط دو نفر یا حداکثر چهار نفر می‌توانند در مورد قسمتی از نرم‌افزار اطلاعاتی داشته باشند. همچنین نرم‌افزار تولیدشده توسط این روش هیچ‌گونه طراحی سازمان یافته‌ای ندارد که این موضوع می‌تواند برای مراحل پس از نصب یعنی تعمیرات و نگهداری سیستم باعث بروز مشکلاتی گردد. از جمله مزایای اکس‌پی می‌توان به این نکته اشاره نمود که از آن جایی که یک برنامه‌نویس به صورت مستقیم کدهای برنامه را کنترل می کند، می‌توان گفت که کیفیت نرم‌افزار تولیدی بالا می‌رود. همچنین می‌توان گفت از آن جایی که دو برنامه‌نویس با هم کار می‌کنند، آموزش کمتری نیاز است و در نتیجه هزینه تولید نرم‌افزار پایین خواهد آمد. اما این روش مشکلات خاص خود را نیز دارد. مثلاً تصورکنید اگر در یک گروه، یک برنامه‌نویس تمایلی برای کار با برنامه نویس دیگری را نداشته باشد یا در یک روز یکی از دو عضو گروه غایب باشد یا ... در نتیجه چون نمی‌توان با یک برنامه‌نویس به ادامه کار پرداخت، اتمام پروژه با تأخیر مواجه خواهد شد. طبق نتایج تحقیقات به عمل آمده، وقتی یک برنامه‌نویس در کدهای برنامه به دنبال اشکال می گردد، حداکثر می‌تواند ده تا پانزده‌درصد از اشکالات برنامه را پیدا کند. اما وقتی در روشی مثل اکس‌پی دو برنامه‌نویس با هم کار می کنند و یکی از این برنامه‌نویسان کدها را کنترل می‌کند، بیست تا چهل‌درصد از اشکالات ساختاری برنامه خود را نشان می‌دهد. اما با استفاده از روش‌های PSP و TSP که در ادامه این مقاله توضیح داده می‌شوند حتی می‌توان تا هشتاددرصد اشکالات برنامه (که رقم بسیار خوبی است) را قبل نهایی‌شدن برنامه شناسایی و رفع کرد. موضوع مطلب : |
||
 |
