تمرین تغییر مداوم و تست واحد

یکی از مهم‌ترین جنبه‌های روش‌های جدید مبتنی بر agile توسعه نرم‌افزار بر اساس نیاز محدود فعلی و تغییرات مداوم آن بر اساس تغییر نیازمندی‌های مشتری یا تغییر درک تیم از نیازمندی‌هاست. روش‌های جدید به ما می‌گویند هیچ چیزی را از همان اول به طور کامل نسازیم. اول یک تیکه کوچک از آن را به طور کامل بسازیم و بعداً در صورت نیاز آن را تغییر دهیم.

تغییرات مداوم نرم‌افزار از آن چیزهایی است که برنامه‌نویس‌ها همیشه از آن گریزان بوده و آن را سخت می‌دانند. این سختی چیزی است که نمی‌توان از آن فرار کرد. برای زنده ماندن در دنیای پر تغییر و پر رقابت امروز باید به این سختی تن داده و به تغییر مداوم نرم‌افزار عادت کرد.

در همین راستا سعی کردم تغییر مداوم را در پروژه «کارویس» تمرین کنم. باید اذعان کنم آنقدرها هم سخت نبود. در واقع تغییر مداوم چیزی است که می‌توان تا اندازه‌ای به آن عادت کرد. یعنی اگر شما به این دیدگاه عادت کنید خود به خود در برنامه‌هایی که می‌نویسید موارد لازم را تا انداره‌ای رعایت خواهید کرد. خوشبختانه پیروی از الگوی تغییر مداوم در صورتی که اصولی انجام شود باعث افزایش سرعت در پیاده‌سازی تیکه تیکه‌های نرم‌افزار هم می‌شود.

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

‫Green Hopper، ابزار مدیریت پروژه Agile در JIRA

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

در نسخه‌های اخیر JIRA یک Add-in برای مدیریت پروژه به سبک Agile/Scrum اضافه شده به نام Green Hopper. اگر کمی با اسکرام و Task Board آشنا باشید و نگاهی به عکس‌ها و ویدئوهای Green Hopper بیندازید متوجه خواهید شد که با کمک این ابزار چقدر اسکرام در JIRA راحت شده است.

جهت کسب اطلاعات بیشتر:

۱- ویدیوی معرفی Green Hopper

۲- Green Hopper
۳- جیرا
۴- چند نمونه عکس

تجاربی از اسکرام

همان طور که می‌دانید اسکرام یکی از متودولوژی‌های جدید توسعه نرم‌افزار از خانواده Agile است. این روش مزایای زیادی، اقلاً برای ما، دارد و روز به روز رواج بیشتری در دنیا پیدا می‌کند. ما هم در مدت اخیر تصمیم گرفتیم از این روش برای یکی دو تا از پروژه‌های جدید استفاده کرده و مزایا و معایبش را به طور عملی لمس کنیم. یکی از این پروژه‌ها، پروژه‌ی کوچکی با ASP.NET بود که تعداد افراد درگیر با آن چه در نقش برنامه‌نویس چه در نقش Product Owner کمتر از ۵ نفر بوده و انجام فاز اول آن چیزی حدود ۱۰ هفته طول کشید. انجام این پروژه با اسکرام برای من که اسکرام را با کتاب Scrum and XP from the Trenches یاد گرفته بودم نکات و تجاربی را با خود به همراه داشت که ذیلاً می‌آیند:

۱- قوانین اسکرام برای غربی‌های منظم نوشته شده نه کشورهایی مثل ما. در نتیجه نمی‌توان از مثلاً افرادی مثل Product Owner انتظار داشت همیشه فهرست PBIهایش را به طور کامل و منظم به همراه داشته باشد.

۲- Self Organized بود تیم در اسکرام خیلی مورد توجه قرار گرفته ولی عموماً ایرانی‌ها عادت دارند یک نفر همیشه کارهایشان را به آنها یادآوری کرده و یک نفر دیگر انجام آن کارها را مدام چک کند. ضعف این خصیصه در افراد برنامه‌نویس خیلی از کیفیت کار در اسکرام کم می‌کند.

۳- روی برنامه و اصول پیش رفتن در نظر خیلی افراد یک کار لوکس (قرتی‌بازی) به نظر می‌رسد. مثلاً شکستن یک PBI به چند Task و یادداشت آن در Task Board یکی از آن کارهاست.

۴- به طور کلی نوسان کاری و عوض شدن مداوم اولویت‌ها در زندگی ما خیلی زیاد است. در اسکرام گفته شده وقتی یک اسپرینت شروع شد دیگر نمی‌توان Backlogهای موجود در آن را عوض یا حذف کرد یا تغییر اولویت داد. اما وفاداری ماها به این طور قوانین خیلی سخت است. مثلا خیلی زیادی پیش می‌آید چند روز بعد از شروع اسپرینت، مشتری یا مدیریت از تیم بخواهد فلان Backlog را کنار گذاشته و به جای آن به یک موضوع جدید بپردازد.

۵- ایرانی‌ها به طور کلی عاشق Customize کردن هستند. مثلاً دوست دارند موتور پیکان را روی بدنه پژو بگذارند و به اسم پژو آر-دی به بازارا بفرستند. یا این که مدام در فکر بومی‌سازی علوم و فناوری خارجی بپردازند. متاسفانه اسکرام هم از این قاعده سرطانی مستثنی نیست و افراد عاشق دستکاری قوانین آن هستند. مثلا در اسکرام گفته شده طول اسپرینت‌ها باید یکسان باشد ولی ما هم اسپرینت‌های یک هفته‌ای داشتیم و هم اسپرینت‌های دو هفته‌ای.

۶- …

توجه: اگر کسی از همکاران شرکتی بنده این متن را می‌خواند یا کسانی این متن را می‌خوانند که فکر می‌کنند در تیم آنها چنین مشکلاتی به وجود نخواهد آمد متوجه باشند که بیشتر این مشکلات از نحوه کار تیمی ما ایرانی‌ها و خصوصیات اجتماعی/فرهنگی ما سرچشمه می‌گیرد و چندان ربطی به این شرکت و آن شرکت ندارد.

استفاده از مفاهیم جدید تولید نرم‌افزار

روند طراحی و توسعه نرم‌افزار طی ده سال گذشته حتی در همین ایران خودمان هم تغییرات زیادی داشته. آن زمان یعنی حدود سال ۷۹ شمسی مردم تازه از شر FoxPro خلاص شده و به دیتابیس‌های مدرن‌تری مثل Access، MS SQL Server و Oracle رو آورده بودند. برنامه‌نویسی در عصر ویندوز راحت‌تر و منظم‌تر شده بود. تا قبل از آن عموماً کسی لذت Foreign Key و Delete/Update Cascade را کشف نکرده بود. طی این ده سال استفاده از Database Driver و ADO رواج زیادی پیدا کرد. در این دوره آنها که منظم‌تر بودند از نمودارهای ERD برای بیان ساختار دیتابیس، نرمال‌سازی، کلاس‌های مجزا برای دسترسی به دیتابیس (معماری سه لایه) و… استفاده می‌کردند.

اما اکنون آن دوران به سر آمده و ما خیلی وقت است که وارده دوران Domain Driven Design یا همان DDD شده‌ایم. در عصر DDD هیچکس مستقیماً به دیتابیس وصل نمی‌شود بلکه از ORM‌ استفاده می‌کند. روابط بین entityها به جای ERD با UML Class Diagram تعریف می‌شود و معماری‌های چندلایه‌ای با استفاده از DDD خیلی راحت‌تر شده و…

حال سوال این است که آیا لازم است ما هم صرفاً به خاطر همراهی با زمان یه سمت Domain Driven Design و Object Oriented برویم یا این که واقعاً نفعی برای ما و شرکت‌مان در آن وجود دارد؟ جواب این سوال هر دو است. چون اولاً وقتی که همه دنیا به این سبک جدید رو آورده‌اند خیلی سخت است که ما همان روش‌ها و ابزارهای قدیمی را نگه داریم و خلاف جریان آب شنا کنیم. ثانیاً عصر جدید امکانات بسیار خوبی را با خود به همراه آورده است و نباید آن را به این سادگی از دست بدهیم.

عصر جدید یعنی دنیای Domain Driven Design و Object Oriented که با استفاده از ORMها و UML محقق می‌شود به شما کمک می‌کند که:
‫۱- کد شما قابلیت نگهداری بالایی داشته باشد.
‫۲- پیدا کردن و برطرف کردن باگ‌ها راحت‌تر باشد.
‫۳- اگر طراحی درست انجام شده باشد، برنامه‌نویسی راحت‌تر خواهد بود.
‫۴- مزایای معرفی شده در Object Oriented به طور ملموسی در دسترس قرار خواهد گرفت. مفاهیمی مثل Inheritance باعث می‌شود حجم کد کاهش یابد.
‫۵- کدهای DDD خیلی منظم‌تر از کدهای تولید شده در دوران قبل هستند.
‫۶- تولید نرم‌افزارهای DDD هم‌خوانی بسیار بیشتری با متودولوژی‌های جدید اسکرام، XP و… دارد.
‫۷- …

در بین شرکت‌ها و تیم‌های نرم‌افزاری ایرانی تعداد قابل توجهی به روش‌های عصر جدید رو آورده‌اند. یعنی از ORM استفاده می‌کنند، کل کار را به صورت Object Oriented جلو می‌برند، Documentation آنها بر اساس UML است و … اما متاسفانه هنوز خیلی‌ها هستند که خود را از لذت و کارایی عصر جدید محروم کرده‌اند. به نظر من تنها عاملی که باعث می‌شود این طور افراد همچنان به استفاده از روش‌های قدیمی ادامه دهند عدم آگاهی نسبت به روش‌های جدید است. چون هیچ مدیر پروژه یا رییس شرکتی دوست ندارد کاری را که می‌شود در شش ماه انجام داد در هشت ماه انجام دهد و نهایتاً هم کدی را تحویل بگیرد که نگهداری و توسعه آن خیلی هم سخت باشد. به همین خاطر به این طور افراد توصیه می‌گردد اگر هم از روش‌های قدیمی خیلی هم راضی هستند اقلاً مطالعه‌ای در مورد روش‌های جدید و مزایای آن داشته باشند.

‫ کتاب Scrum and XP from the Trenches

اگر می‌خواهید اسکرام یاد بگیرید و پروژه‌هایتان را با روش اسکرام مدیریت کنید، اگر می‌خواهید در تولید نرم‌افزار از روش‌های جذاب XP استفاده کنید و اگر نمی‌خواهید درگیر مسائل تئوری شوید و می‌خواهید مستقیماً از روش اسکرام استفاده کنید، یک منبع خوب وجود دارد: خواندن و به کار بردن کتاب Scrum and XP from the Trenches. این کتاب به کار بردن اسکرام و XP را با زبانی بسیار ساده به شما توضیح می‌دهد. کتاب حجم بسیار کمی دارد. این موضوع برای کسانی که کمبود دائمی وقت دارند و کسانی که حوصله خواندن کتاب‌های حجیم را ندارند خیلی مفید است. علاوه بر این، کتاب انگلیسی بسیار ساده و روانی دارد و اصلاً خواننده غیر انگلیسی زبان را اذیت نمی‌کند.

کتاب تمامی جزییات اسکرام را از جمله جلسات، جزییات آنها، تقسیم کار، نقش‌ها، نمودارها، نحوه تست و روش ترکیب XP با اسکرام را به خوبی پوشش می‌دهد. کتاب حتی موضوعات ریزی مثل چگونگی انتخاب Backlog Itemها برای یک اسپرینت نوعی را هم تشریح می‌کند. خواندن کتاب علاوه بر Scrum Masterها نکات خوبی را به دیگر اعضای تیم نیز یاد می‌دهد.

من اسم این کتاب را خیلی جاها شنیدم. در واقع خواندن این کتاب در بسیاری منابع توصیه شده است. فرض کتاب است این است که خواننده یک شناخت کلی از اسکرام و XP دارد و به دنبال یک نقطه شروع می‌گردد. برای شخص من که آشنایی چندانی با اسکرام و خصوصاً XP نداشتم، خواندن مقالات ویکی‌پدیا راجع به اسکرام و XP کاملاً کفایت کرد و مقدمه بسیار خوبی شد برای مطالعه این کتاب. این کتاب به صورت رایگان از سایت InfoQ قابل دریافت است. هر چند که نسخه چاپی آن هم قابل خریداری می‌باشد.

سورپرایز آخر این که نویسنده کتاب یعنی «هنریک نیبرگ» علی‌الظاهر اواخر سال میلادی جاری (۲۰۱۰) برای برگزاری یک سری دوره Scrum Mastering به ایران خواهد آمد.

گاو و مرغ

صبح یک روز بهاری یک مرغ و یک گاو در مزرعه‌ای در کنار هم راه می‌رفتند. مرغ به گاو گفت بیا با هم یک رستوران راه بیندازیم. گاو گفت باشه ولی اسمشو چی بذاریم؟ مرغ گفت اسمشو بزاریم رستوران «کباب و نیمرو». گاو گفت: نه من موافق نیستم. چون من باید از جونم بگذارم تا کباب درست بشه ولی تو فقط ی تخم می‌زاری و همین.

بی‌مزه بود نه؟ این داستان در واقع برگردان یک جوک کلاسیک انگلیسی است به اسم The Chicken and the Pig. این جوک مبنای دسته‌بندی نقش افراد تیم در روش Scrum است. نقش‌های مهم، یعنی نقش‌هایی که مستقیماً در تولید محصول دخالت دارند مثل ScrumMaster جز نقش‌های «گاو» یا همان Pig محسوب می‌شوند و نقش‌هایی مثل «سهام داران» که نقش مستقیم کمتری در تولید محصول دارند جز نقش‌های «مرغ» یا همان Chicken محسوب می‌شوند.

‫Agile و استفاده از آن

اگر بخواهیم Agile را خیلی ساده و بدون استفاده از لغات دقیق و فنی و مرزبندی‌های مربوطه تعریف کنیم، آن وقت Agile یعنی یک نوع روش تولید نرم‌افزار که در آن عمده توجه به انعطاف‌پذیری تیم تولید در پذیرش تغییرات مداوم نیازمندی‌های اولیه نرم‌افزار است. این انعطاف‌پذیری در اثر iterative و incremental بودن این روش به وجود آمده است.

Agile در مجموعه مفاهیم مهندسی نرم‌افزار، هم‌خانواده مفاهیمی مثل RUP و SSADM است با این توضیح که این سال‌ها هم‌زمان با پیشرفت بحث‌های شی‌گرایی، Agile هم حسابی رواج پیدا کرده و در خیلی از پروژه‌ها جای RUP را گرفته است. Agile در مقایسه با متودولوژی‌هایی مثل RUP که predictive هستند، با اصطلاح adaptive توصیف می‌شود. adaptive یعنی این که روش مورد نظر می‌تواند خودش را به راحتی با تغییرات نیازمندی‌های تطبیق دهد. درست به همین دلیل هم است که نمی‌توان روند پیشرفت پروژه‌های Agile را با دقت پیش‌بینی کرد. از سویی دیگر روش‌هایی مثل RUP انطباق‌پذیری کمتری دارند ولی در مقابل چون تغییرات کمی دارند به خوبی predictive (قابل پیش‌بینی) هستند. Agile فقط شامل Scrum و XP نمی‌شود بلکه هر روشی را که با مانیفست Agile مطابقت داشته باشد را می‌توان Agile نامید، از جمله روش‌هایی که توسط مایکروسافت و بقیه ارائه شده‌اند.

به نظر می‌رسد Agile (با تکیه بر Scrum/XP) با همه راحتی‌هایی که دارد، برای اجرا در شرکت‌های ایرانی دچار مشکلات خاصی هم بشود:
۱- Agile اشتباهاً زیادی لوکس به نظر می‌رسد. مدیران شرکت‌ها دید خیلی خوبی نسبت به تشریفات آن نداشته و فکر می‌کنند یک جور کار غیر ضروری است. مثلاً Standingها (جلسات سرپایی مرور) یکی از آن موارد است.
۲- Agile اشتباهاً بی‌نظم و بی‌برنامه به نظر می‌رسد، چون Agile یک روش Adaptive است و نمی‌توان طرح‌های کاملاً دقیقی از روند پیشرفت کار ارائه داد. این موضوع می‌تواند بهانه خوبی در دست مخالفان Agile باشد. خصوصاً آنها که عاشق Gantt chart هستند. این طور افراد با اعمال گانت چارت و عدم تغییر گانت چارت عملاً Agile را از یک روش iterative و incremental به یک روش آبشاری مثل SSADM تبدیل می‌کنند.
۳- Agile اشتباهاً غیر مستند به نظر می‌رسد. بله درست است که Agile نسبت به روش‌هایی مثل RUP مستندات کمتری تولید می‌کند ولی این به خاطر تمرکز بیشتر بر ارائه خود محصول است نه بی‌اهمیتی آن نسبت به documentation.‏
۴- پایبندی به Agile اشتباهاً سخت به نظر می‌رسد. در Scrum که یکی از رایج‌ترین روش‌های Agile است، همه افراد تیم ملزم به تطبیق خود با بازه زمانی ۲ تا ۴ هفته‌ای به نام sprint هستند. در هر sprint ممکن است اولویت کارها عوض شود و taskهایی که در sprintهای قبلی با جدیت دنبال می‌شد کنار گذاشته شوند. در جلسات مابین sprint احتیاج به حضور و تعامل جدی نماینده کارفرما (product owner) هست. این‌ها باعث می‌شود تا بعضی افراد فکر کنند اجرای Scrum خیلی سخت است. ولی خوشبختانه واقعیت این است که با تعهد به این وظایف محصولی بهتر در زمانی کمتر تولید خواهد شد.

————–
منبع: مقالات و نوشته‌های مربوط به Agile و Scrum در ویکی‌پدیا و StackOverflow

‫مقایسه روش‌های MSF Agile و MSF CMMI

توسعه نرم افزار این یک مقایسه سریع السیر بین این دو روش یا متودولوژی توسعه نرم افزار است که یکی از آنها در آخر کار بیشتر بررسی شده است. سریع السیر بودن یعنی این که ممکن است خیلی چیزها از قلم افتاده یا اشتباه کوچکی رخ داده باشد. از آنجا که وقت خیلی زیادی برای انجام این کار نداشته و فعلا تمرکزم بر روی خود برنامه نویسی و تکنولوژی‌های روز است بررسی چندان عمیقی انجام نداده و سعی کرده‌ام که کار را به طور خلاصه و نقل قول از سایت‌های دیگر انجام داده و صرفا نتیجه گیری کلی خودم را در پایان بیاورم. این نتیجه گیری تحت تاثیر دانسته‌ها و گرایش‌های قبلی من در این موضوع هم بوده است. در صورت تمایل به مطالعه دقیق‌تر، لینک‌ها را دنبال کنید. همان طور هم که قابل حدس است هر دوی این روش‌ها به قصد استفاده در Team Foundation Server بررسی شده‌اند.
  • هر دو Process نشات گرفته از MSF هستند و به طور مادرزاد در TFS قرار داده شده‌اند. هر چند که می‌توان پروسس‌های دیگری را به TFS اضافه و از آنها استفاده کرد.
  • CMMI فقط خاص نرم افزار نیست بلکه در خیلی از صنایع دیگر مثل تولیدات الکترونیکی هم استفاده می‌شود.
  • توضیحی در سایت برنامه نویس (agile خلاصه‌تر از CMMI است): http://barnamenevis.org/forum/showthread.php?t=92169
  • جدالی بر سر تعاریف مربوط به agile و rup در سایت برنامه نویس: http://barnamenevis.org/forum/showthread.php?t=59278
  • در این مقاله سایت برنامه نویس گفته شده که agile سرعت بیشتری دارد و در پروژه‌های زیر ۳۰ نفر خیلی بهتر از RUP عمل می‌کند: http://www.barnamenevis.org/forum/showthread.php?t=20625
  • ظاهرا در متودولوژی‌هایی مثل xp نیازی نیست که همه دیاگرام‌های یوام‌الی از قبل در بیاید. و عملا کار برنامه نویس و تحلیل‌گر و… با هم پیش می‌رود. علی الظاهر agile نام یک مجموعه از روش‌های توسعه سریع نرم افزار است که یکی از مثال‌هایش xp (و حتی شاید MSF for Agile) است. http://www.barnamenevis.org/forum/showthread.php?t=67708
  • در اینجا هم گفته شده که MSF Agile تنها روش Agile Software Development نیست بلکه می‌شود از SCRUM، XP، Crystal Clear و Lean هم استفاده کرد. همچنین معلوم است که MSF Agile و MSF CMMI تنها قالب‌های قابل استفاده در TFS نیستند، بلکه می‌توان از قالب‌هایی که اشخاص دیگر هم تهیه کرده‌اند استفاده کرد. مثلا از قالب‌های Agile مثل XP یا SCRUM: باز هم گفته شده که افراد تیم باید راجع به روش‌های Agile مطالعه کرده و آموزش ببینند. و این طور نیست که هر کس با TFS MSF Agile کار کرد یعنی Agile Software Development بلد است!http://blogs.neudesic.com/blogs/phil_scott/archive/2005/12/16/14.aspx
  • مقایسه توضیحات ویکی‌پدیا راجع به agile software development: http://en.wikipedia.org/wiki/Agile_software_development و CMMI: http://en.wikipedia.org/wiki/CMMI هم نشان می‌دهد که CMMI خیلی عمومی و جنرال است و در صنایع غیر نرم افزار هم کاربرد دارد. در حالی که Agile فقط برای مباحث توسعه نرم افزار و احتمالا صنایعی کاربرد دارد.
  • اینجا گفته شده که MSF Agile زیرمجموعه‌ای از MSF CMMI هست به عبارت دیگر هر چیزی که در MSF Agile وجود دارد در MSF CMMI هم وجود دارد یعنی این که MSF CMMI همان MSF Agile است ولی گسترده‌تر و بزرگ‌تر. باز هم آمده که MSF CMMI برای پروژ‌های بزرگ‌تر و طولانی‌تر کاربرد دارد و MSF Agile برای پروژه‌های بین ۳ تا ۱۰ نفره خوب است. در حالی که MSF CMMI برای یکی تیم اقلا ۲۰ نفره مناسب است.  http://social.msdn.microsoft.com/Forums/en-US/vstsmsf/thread/f8e3d872-d815-4be6-96ff-fdefdaad1b47/
  • مقایسه RUP و MSF در یک نوشته فارسی http://www.nfgp.com/Portals/0/Download/Comparing%20the%20Rational%20Unified%20Process%20(RUP)%20and%20Microsoft%20Solutions%20Framework%20(MSF).pdf
  • مقایسه CMMI و Agile که فرصت خواندن آن را نداشتم: http://somamos.blogfa.com/post-254.aspx
  • دو منبع تکمیلی:http://msdn.microsoft.com/en-us/library/ms400752(vs.80).aspx و http://msdn.microsoft.com/en-us/vsts2008/aa718795.aspx

خلاصه این که با توجه به توضیحات و لینک‌های بالا و زیر ۲۰ نفر بودن تیم توسعه نرم افزار ما و اکثر قریب به اتفاق تیم‌های برنامه نویسی ایران و مبتذل شدن نام RUP در بین خیلی از هم سنگران، استفاده از یکی از متدولوژی‌ها (روش‌های) Agile توصیه می‌شود. از بین روش‌های توسعه نرم افزار چابک (Agile) هم با توجه به دم دست بودن مایکروسافت، ویژوال استودیو، TFS و علاقه و راحتی خیلی از تیم‌های ایرانی و خود ما، روش MSF Agile توصیه می‌گردد. امید آنکه بتوانم مطالعه کاملی راجع به این نکات کرده و بتوانم نرم افزار بهتری تولید کنم.
و حالا نکاتی راجع به خود Agile و MSF Agile:

  
پ. ن. ۱: ممکن است من مفاهیمی مثل پروسس، روش، متود، متودولوژی و temaplte را به خاطر کم آگاهی اشتباها به جای یکدیگر به کار برده باشم.
پ. ن. ۲: خیلی دوست بدانم که آیا هیچ جایی در ایران به طور واقعی و -نه خالی‌بندی- از روش‌های Agile برای توسعه نرم افزار استفاده کرده است یا نه.