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

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

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

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

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

‫Burn down chart دقیق در TFS

Burn down chart یکی از ابزارهایی است که در اسکرام برای مشاهده و پیش بینی روند پیشرفت اسپرینت به کار برده می‌شود. اگر برای اسکرام از TFS 2010 و قالب Scrum for Team System استفاده می‌کنید، رعایت نکات زیر لازم می‌شود تا نمودار دقیقی داشته باشید.

۱- قبل از شروع هر اسپرینت، یعنی قبل از این که وضعیت آن از Not Started به In Progress تغییر کند، زمان‌های Estimation effort و Remaining Work را در تک تک SBTها به طرز صحیح وارد کنید و سعی کنید آنها را تغییر ندهید. در غیر این صورت نمودار شما به جای این که رو به پایین باشد رو به بالا خواهد بود:

۲- وارد کردن درست تاریخ‌ها و دیگر اطلاعات اسپرینت هم فراموش نشود.

۳- اعضای تیم نباید یادشان برود که وضعیت PBI/SBTها را از حالت Not Started خارج کرده و به وضعیت‌های In Progress یا Done ببرند. در غیر این صورت نمودار هرگز به روز نشده و فقط یک خط افقی را نمایش خواهد داد.

۴- اعضای تیم باید وضعیت هر PBI/SBT را درست همان موقع که شروع می‌کنند یا به پایان می‌رسانند به روز رسانی کنند. در غیر این صورت نمودار Burn down chart غیر واقعی خواهد بود.

۵- گزارش Burn down chart تا زمانی که تاریخ شروع اسپرینت فرا نرسیده و وضعیت اسپرینت مورد نظر از حالت Not Started خارج نشده باشد چیز مفهومی را نشان نخواهد داد. چه شیب صحیح و چه مجموع ساعات کاری:

۶- هر چقدر که PBIها به SBTهای ریزتری شکسته شده باشند، دقت Burn down chart بالاتر خواهد رفت.

۷- در نهایت اگر موارد نیاز رعایت شده باشد نموداری شبیه به نمودار زیر به دست خواهد آمد:

پ.ن.: در اسکرام هر پروژه به تعدادی اسپرینت معمولاً دو هفته‌ای، هر اسپرینت به تعداد Backlog Item یا PBI و هر PBI به تعداد Task یا SBT تقسیم می‌شود. هر PBI نمایانگر یکی از سناریوهای مشتری مثل «مدیریت کاربران» یا «پرداخت وام» است و معمولاً پیاده‌سازی آن ۲ تا ۳ روز طول می‌کشد. هر SBT هم معمولاً ۴ تا ۶ ساعت زمان می‌برد.

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

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

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

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

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

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

‫ایجاد پروژه در TFS به روش اسکرام

یکی از کارهایی که همیشه انجام می‌دهم ایجاد یک پروژه در TFS 2010 به روش اسکرام است. بد ندیدم که بعضی از مراحل آن را در اینجا بیاورم:

۱- کسب اطمینان از نصب SfTS در TFS. این ابزار امکانات اسکرام را در TFS و Visual Studio فراهم می‌کند.

۲- اجرای ویژوال استودیو در حالت Admin.

۳- انتخاب گزینه New Team Project…‎ از پنجره Team Explorer.

۴- نام گذاری پروژه و انتخاب Template با نام Scrum for Team System و ادامه همه مراحل.

۵- راست کلیک روی اسم پروژه در Team Explorer و انتخاب گزینه‌های Team Project Settings و Group Membership.

۶- دابل کلیک روی گروه دلخواه و اضافه کردن کاربران مورد نظر از طریق Windows User or Group.

۷- باز کردن آدرس وبی TFS که معمولاً به صورت http://servername:8080/tfs/web/‎ است.

از اینجا به بعد باید مراحل مخصوص اسکرام دنبال شود. یعنی اسپرینت‌ها، Backlog Itemها، Taskها و… تعریف شوند. هر اسپرینتی هم باید به صورت work item ثبت شود و هم به صورت ساختار داخلی Iteration.

۸- اضافه کردن iterationهای مورد نظر بر اساس تعداد اسپرینت‌ها. دقت شود که برای تیم‌های کوچک فقط Team Sprint مهم است.

۹- بعد از مشخص کردن همه Iterationها چیزی شبیه به عکس زیر دیده خواهد شد.

۱۰- تعریف Releaseها، Sprintها و Team Sprintها بر اساس درخت Iterartion. وارد شدن تاریخ‌ها نباید فراموش شود. از این سه تا work item فقط نوع Team Sprint برای ما اهمیت دارد.

۱۱- تعریف رابطه Implemented by و Implements بین Releaseها، Sprintها و Team Sprintها.

۱۲- تعریف Backlogها (PBI) و  Taskها (SBT) و روابط بین خودشان و Team Sprintها.

۱۳- استفاده از Queryهای موجود برای مشاهده Work Itemهای تعریف شده.

۱۴- تکمیل تدریجی اطلاعات Work Itemها.

۱۵- استفاده از Sprint Burndown Chart و دیگر گزارشات برای کسب اطلاعات بیشتر از وضعیت پروژه.

۱۶- از Portal پروژه هم می‌توان استفاده کرده و به خیلی از اطلاعات و امکانات پروژه دسترسی پیدا کرد.

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

همان طور که می‌دانید اسکرام یکی از متودولوژی‌های جدید توسعه نرم‌افزار از خانواده 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