انجمن انفورماتیک ایران انجمن انفورماتیک ایران انجمن انفورماتیک ایران
گزارش کامپیوتر شماره 234, ویژه مرداد و شهریور ماه 96 منتشر شد. يکشنبه  ٢٨/٠٨/١٣٩٦ ساعت ١٣:٥٥
 

معرفی استاندارد 26515: توسعه مستندسازی کاربری

 در یک محیط توسعه نرم‌افزار چابک

 

 


 

مقدمه

به اهمیت مستندسازی در پروژه‌های نرم‌افزاری و همچنین ابعاد مستندسازی به عنوان بخشی از هر پروژه (مستقل از اندازه و پیچیدگی و روشگان توسعه)، در قسمت‌های قبلی پرداخته شد. همان‌گونه که بیان شد، چند استاندارد به این موضوع اختصاص یافته است:

  • استاندارد ISO/IEC/IEEE 26511:2012 (با عنوان «مهندسی سامانه‌ها و نرم‌افزار- الزاماتی برای مدیران مستندسازی کاربری»)
  • استاندارد ISO/IEC/IEEE 26512:2011 (با عنوان «مهندسی سامانه‌ها و نرم‌افزار- الزاماتی برای کارفرمایان و تامین‌کنندگان مستندسازی کاربری»)
  • استاندارد ISO/IEC 26513:2009 (با عنوان «مهندسی سامانه‌ها و نرم‌افزار- الزاماتی برای آزمون‌گران و بازنگران مستندسازی کاربری»)
  • استاندارد ISO/IEC 26514:2008 (با عنوان «مهندسی سامانه‌ها و نرم‌افزار- الزاماتی برای طراحان و توسعه‌دهندگان مستندسازی کاربری»)
  • استاندارد ISO/IEC/IEEE 26515:2011 (با عنوان «مهندسی سامانه‌ها و نرم‌افزار- توسعه مستندسازی کاربری در یک محیط چابک»)

در شماره 224 نشریه گزارش کامپیوتر، استاندارد ISO/IEC 26512:2011 ، و در شماره 223 استاندارد ISO/IEC/IEEE 26511:2012 به اجمال بررسی شد. در این شماره، تلاش شده تا اهّم موضوعات مطرح شده در استاندارد ISO/IEC/IEEE 26515:2011 ، که به اختصار به آن «استاندارد» اطلاق می‌شود، بیان شده تا متخصصین توسعه نرم‌افزار در محیط‌های چابک ، دیدگاهی را از نحوه پیاده‌سازی فرآیند مستندسازی کاربری داشته باشند.
توسعه چابک، روشگانی است تکرارشونده و با تاکید بر توسعه نیازمندی‌های با اهمیت کاربر به عنوان یک الویت، و همچنین یافتن زودهنگام نواقص در چرخه توسعه؛ زمانی که کشف و رفع آن‌ها بسیار ارزان‌تر از مراحل بعدی است. روشگان‌های توسعه چابک بر روی ارائه ارزش کارکردی (Functional ) به کاربران و کاهش هزینه‌ها تمرکز دارد. رو‌شگان‌های توسعه چابک مشوق اطلاع‌رسانی شفاف و منظم بوده، و تمامی طرف‌های علاقه‌مند ممکن است در تمام مراحل توسعه درگیر باشند. از آنجا که روش‌های توسعه چابک بر دوره‌های زمانی ثابت، که اسپرینت نام دارد، تمرکز دارد، مخاطره‌های مربوط به عدول از ظرف بودجه‌ای و زمانی پروژه کاهش می‌یابد. 
شایان ذکر است که توسعه چابک فرآیندی منفرد یا مجموعه‌ای از روشگان‌های تعریف شده نیست؛ بلکه مجموعه‌ای  از اصول و روشگان‌های مرتبط است. روشگان‌های متفاوت توسعه چابک (مانند اسکرام یا اکس‌.پی )، هر کدام اصطلاحات متفاوتی دارند. این تفاوت‌ در اصطلاحات، توسط این استاندارد توصیف نشده و مد نظر آن نیست. به بیان دیگر، آنچه در این استاندارد مورد توجه بوده، ارائه اصولی برای توسعه مستندسازی کاربری در محیط چابک، مستقل از یک روشگان خاص، است.

 

 

مشخصات

مشخصات این استاندارد در جدول شماره 1 نشان داده شده است.
جدول 1: مشخصات استاندارد


شماره:

26515

قسمت:

-

نوع سند:

استاندارد بین‌المللی

عنوان لاتین:

Systems and software engineering - Developing user documentation in an agile environment

عنوان فارسی:

مهندسی سامانه‌ها و نرم‌افزار- توسعه مستندسازی کاربری در یک محیط توسعه نرم‌افزار چابک

تعداد صفحات:

27

سال چاپ:

2011

زبان:

تک زبانه، انگلیسی

شماره ویرایش:

ندارد

متمم و اصلاحیه:

ندارد

استاندارد(های) جایگزین شده:

ندارد

کد رده‌بندی استانداردی (ICS ):

35.080

نهاد استانداردگذار:

ایزو

لازم به ذکر است که فرآیند تدوین استاندارد ملی متناظر، در حال انجام بوده و پیش‌بینی می‌شود اولین نسخه آن خرداد ماه 1395 توسط سازمان ملی استاندارد ایران منتشر شد.

ساختار

ساختار این استاندارد به شرح زیر است:

فرآیندهای مستندسازی کاربری در یک محیط توسعه نرم‌افزار چابک

فرآیندهایی که برای مستندسازی کاربری در یک محیط توسعه نرم‌افزار چابک باید مد نظر قرار گیرد، سه موضوع زیر است:

برای هر کدام از این فرآیندها ملاحظاتی وجود دارد، که در ادامه آمده است.

ارتباطات بین کاربر و فرآیندهای مستندسازی چرخه‌عمر

طبق این استاندارد، تیم استفاده‌کننده از روشگان توسعه چابک، باید فعالیت‌های زیر را انجام دهد:

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

اقلام اطلاعاتی زیر در مستندات توسعه یافته هم با استفاده از روش توسعه سنتی و چابک، به کار می‌رود:

  • توصیف
  • طرح
  • خط‌مشی
  • رویه
  • گزارش
  • درخواست
  • ویژگی

فرآیندهای پیاده‌سازی نرم‌افزار، بین پروژه‌ها با استفاده از روش‌های توسعه نرم‌افزار چابک و سنتی یکسان بوده، ولی برخی یا تمامی آن‌ها ممکن است در هر اسپرینت تکرار شود:

  • پیاده‌سازی نرم‌افزار
  • تحلیل نیازمندی‌های نرم‌افزار
  • طراحی معماری‌گونه نرم‌افزار
  • طراحی تفصیلی نرم‌افزار
  • ساخت نرم‌افزار
  • یکپارچگی نرم‌افزار
  • آزمون صلاحیت نرم‌افزار

در برخی پروژه‌ها، فرآیند طراحی تفصیلی نرم‌افزار ممکن است به شکل مختصر یا پراکنده‌ای مستند شود.

مستندسازی چرخه‌عمر نرم‌افزار در یک محیط چابک

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

مستندسازی چرخه‌عمر در توسعه چابک

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

  • طرح‌های پروژه؛
  • طرح‌های اسپرینت؛
  • مستندات نیازمندی‌ها، (بیان شده در داستان‌های کاربر ، فرانامه‌ها
  • پیشنهادهای طراحی سطح بالا (ممکن است برای توسعه نرم‌افزار چابک لازم نباشد)؛
  • طراحی‌های آزمون (رویه آزمون)؛
  • بیانیه‌های مخاطرات (ثبت مخاطره)؛
  • داستان‌های کاربر؛
  • موارد کاربرد ؛
  • توصیف‌ پِرسوناها ؛
  • نمودارهای Burndown ؛
  • فهرست‌ وظیفه‌ها؛
  • گزارش‌های اسکرام؛ و
  • گزارش‌ درس‌آموخته‌های پایان اسپرینت.
مدیریت توسعه اطلاعات در یک محیط توسعه نرم‌افزار چابک

موضوع مدیریت توسعه اطلاعات در یک محیط توسعه نرم‌افزار چابک بخش مهمی از استاندارد را به خود اختصاص داده است. مواردی که ذیل این موضوع به آن پرداخته شده، عبارت است از:

هر کدام از موارد فوق در ادامه به اجمال بیان شده است.

ملاحظات مدیریت مستندسازی برای توسعه چابک

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

مدیریت تغییر هنگام حرکت به سوی یک فرآیند توسعه چابک

برای حرکت به سوی یک فرآیند توسعه چابک، این استاندارد توصیه‌هایی را ارائه کرده که عمدتاً باید توسط مدیران پروژه (سازمان توسعه) مد نظر قرار گیرد:

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

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

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

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

مدیریت وظایف در کل اسپرینت‌ها

در یک پروژه چابک، به شکل ایده‌آل، مستندسازی کاربر به‌طور موازی و با همان زمان‌بندی تولید نرم‌افزار، توسعه می‌یابد. در این شرایط، نرم‌افزار قادر است تا به‌طور منظم با مستندات کافی به مشتریان عرضه شود. ارائه هر چه زودتر مستندات کاربر در یک اسپرینت، زمانی را برای بازنگری و آزمون مستندسازی به‌طور موازی با نرم‌افزار، فراهم می‌کند. فواید نویسنده فنی از این کار عبارت است از:

  • دسترسی سریع به ویژگی‌های تحت توسعه؛
  • اطلاع‌رسانی به توسعه‌دهندگان، ضمن این‌که ویژگی‌ها تحت توسعه هستند؛
  • استفاده زودهنگام از کارکرد، به منظور یافتن نواقص؛
  • همکاری بالقوه در طراحی و کاربردپذیری ویژگی‌ها.

برای این منظور، این استاندارد موارد زیر را مد نظر قرار می‌دهد:

پایش و تحلیل پیشرفت در محیط نرم‌افزار چابک

ردیابی پیشرفت، بخش مهمی از توسعه چابک است که اطمینان می‌دهد اقلام تعهد شده به‌طور موفق در اسپرینت تکمیل شده، و هر اشکال یا موانع بالقوه‌ای در اولین زمان و با سرعت ممکن، کشف و رفع شده است.
سازوکارهایی که این استاندارد برای این منظور پیش‌بینی کرده، به شرح زیر است:

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

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

بهبود فرآیند مستندسازی کاربر در یک محیط چابک

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

توسعه مستندسازی کاربر در محیط چابک

این بند از استاندارد موضوعات فنی مرتبط با مستندسازی کاربر را در یک محیط چابک تشریح می‌کند. اهّم سرفصل‌هایی که ذیل این بند آمده، به قرار زیر است:

این سرفصل‌ها در ادامه به اختصار توضیح بیان شده است:

توسعه چابک چه معنایی برای توسعه اطلاعات دارد؟

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

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

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

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

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

طراحی و توسعه مستندسازی کاربر در محیط توسعه نرم‌افزار چابک

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

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

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

آزمون و بازنگری مستندسازی در محیط توسعه چابک

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

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

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

  • آیا مستندسازی کاربر نیاز به ترجمه برای هر اسپرینت دارد یا خیر؛
  • آیا مستندسازی کاربر برای کاربر هر تکرار منتشر شود؛
  • زمان لازم برای ترجمه و بومی‌سازی؛
  • زمان لازم برای بسته‌بندی و مدیریت ارجاع مستندسازی ترجمه شده یا بومی‌شده؛
  • زمان لازم برای آزمون مستندسازی ترجمه شده یا بومی‌شده؛
  • ترجمه محلی، نیازمندی‌های محلی، و مقررات.

راهبردی که برخی سازمان‌ها برای ترجمه و بومی‌سازی اتخاذ می‌کنند، بسته‌بندی و ارسال برای ترجمه در انتهای هر اسپرینت، و تلفیق موارد بازگشتی در تکرارهای بعدی است.

فرآوری برای چرخه‌های تولیدی

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

جمع‌بندی

در این مقاله، و در ادامه قسمت‌های قبلی، تلاش شد تا موضوع مستندسازی کاربری در محیط توسعه نرم‌افزار چابک، بیان شود. این استاندارد سرفصل‌های مرتبط را به شرح زیر تشریح می‌کند:

  • فرآیندهای مستندسازی کاربر در یک محیط توسعه نرم‌افزار چابک
  • مدیریت توسعه اطلاعات در یک محیط توسعه نرم‌افزار چابک
  • توسعه مستندسازی کاربر در محیط نرم‌افزار چابک

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