اشتباهات رایج در درک متدولوژیهای توسعه نرمافزار – قسمت 1
مستند سازی
در یک پروژه توسعه نرمافزار مستند سازی در مراحل و بخشهای مختلفی ممکن است مورد نیاز باشد. از جمعآوری نیازمندیها و تحلیل و طراحی تا برنامه نویسی و حتی مستند نمودن کدهای برنامه، از استقرار نرمافزار تا تهیه راهنمای کاربری، از استاندارد نمودن فرآیندهای مدیریتی تا تضمین کیفیت. ولی وقتی صحبت از مستند سازی و تهیه مستندات در پروژههای توسعه نرمافزار میشود بسیاری از اعضای تیم و برنامهنویسها و حتی مدیر پروژه سعی میکنند از انجام آن شانه خالی کنند.
قریب به اتفاق شرکتهای توسعه نرمافزار نیز به بهانه هزینهبر بودن، مخالف مستند سازی میباشند. مخصوصا از زمانی که متدهای اجایل معرفی و فراگیر شدهاند، این طور مینماید که انگار دلیل علمی عدم مستند سازی به دست همگی افتاده است. من در طول سالهای اخیر بسیار زیاد به این جمله برخوردهام، “تیم ما از روش اجایل برای مدیریت پروژه استفاده میکند، بنابراین ما چیزی را در پروژه مستند سازی نمیکنیم”. در ادامه دیدگاه روشهای پراستفاده در مدیریت پروژه توسعه نرمافزار را درباره این مسئله بررسی میکنیم.
1- دیدگاه RUP درباره مستند سازی
متدولوژی RUP برای مستند سازی پروژه توسعه نرمافزار اهمیت بسیار زیادی قائل شده است. به طوری که برای تمامی فازها و فرآیندهایی که در طی این فازها طی میشود دستورالعمل مستند سازی، مثال، روش و قالب معرفی کرده است. با این حال با معرفی تکنیک Tailoring تاکید زیادی کرده است که فرآیندها و مستندات باید به اندازه نیاز واقعی پروژه تهیه گردد و از غرق شدن در مستند سازی اجتناب گردد. علاوه بر اینها این متدولوژی پروژهها را به دو دسته کلی “پروژههای بزرگ” و “پروژههای کوچک” تقسیمبندی کرده و برای پروژههای کوچک برخی مستندات و فرآیندها را خلاصهتر نموده است. در عین حال RUP با معرفی برخی از قالبها به عنوان “قالب مستندات غیررسمی” یا Informal سعی نموده تا در پروژههای کوچک حداقل مستند سازی مورد نیاز را برای پروژه فراهم آورد. درکتاب ارزشمند Rational Unified Process Made Easy نویسنده کتاب، توضیحات کاملی درباره پروژه دیموس (Project Deimos) یک پروژه یک نفره که در یک هفته انجام میشود آورده است. در این مثال مستند سازیهای انجام شده برای نرمافزار، برای جلوگیری از اتلاف وقت، همگی به صورت دستی و با قلم و کاغذ انجام شده است و تمام اینها نشان از اهمیت مستند سازی در پروژههای توسعه نرمافزار دارد.
2- دیدگاه روشهای اجایل درباره مستند سازی
در نظر بسیاری از افراد تفکر چابک به معنی سرعت در انجام پروژه به هر قیمتی است. یعنی به اشتباه متد چابک را متد عجله میدانند و معتقدند در این روش برای جلوگیری از پایین آمدن سرعت تیم، به بسیاری از فرآیندهای مهندسی مانند مستند سازی و طراحی نیازی نمیباشد. در حالی که این برداشت از معنی کلمه چابک فقط ترجمه لغت به لغت این کلمه و کاملا سطحینگر و اشتباه است. در حقیقت روش اجایل به معنی سریع بودن و عجله کردن نیست، بلکه به معنی هوشمندانه سریع بودن و توسعه هوشمندانه است! در ارزش دوم از بیانیه چابک آمده است
Working software over comprehensive documentation
این جمله به این معنی نیست که وقتی نرمافزار به درستی کار میکند نیازی به مستند سازی نیست! بلکه به این معنی است که ارزش نرمافزار به درست کار کردن آن است نه به جامع بودن مستند سازی آن. همچنین در اصول این بیانیه آمده است
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
به این معنی که موثرترین روش برای انتقال اطلاعات بین اعضای تیم گفتگوی چهره به چهره است، این جمله به این معنی نیست که انتقال اطلاعات بین اعضای تیم از طریق مستندات روشی غلط است. همچنین معنی این جمله این نیست که تجارب به دست آمده توسط تیم پروژه نباید مستند شود. به طور مثال در جایی که نیاز است کارکرد نرمافزار مدلسازی شود و اعضای تیم مدل را مطالعه نمایند و برای بهبود کارکرد نرمافزار راه بهتری پیدا کنند آیا مستند سازی و مدلسازی بخشی از متد چابک نیست؟
3- دیدگاه استاندارد PMBOK درباره مستند سازی
استاندارد PMBOK که یکی از معتبرترین استانداردهای عمومی و رایج مدیریت پروژه میباشد نیز بر مستند سازی روشها، فرآیندها و استانداردها و لزوم طراحی پروژه تاکید دارد. این استاندارد مستند سازی را آنقدر ضروری میداند که برای تمامی فرآیندها و گامهای اجرایی فرآیندها قالب و دستورالعمل مستند سازی در نظر گرفته است. با این حال بر لزوم Customise نمودن فرآیندها و مستندات نیز تاکید دارد. به این معنی که نیازی نیست تمامی مستندات و فرآیندها را مو به مو به همان صورت که در استاندارد مطرح شده است اجرا نمود. بلکه باید با رعایت نمودن اصول پایه، فرآیندها و مستندات را به گونه ای طراحی و اجرا نمود که به موفقیت پروژه دست یافت.
یکی از مستنداتی که این استاندارد بر تولید آن تاکید شده است سندی است به نام “دروس آموخته” و این استاندارد معتقد است فاز و یا چرخه (Iteration) پروژه زمانی به پایان میرسد که درسهای فراگرفته شده و تجربیات حاصل شده از آن مستند سازی گردد. تجربیات حاصل شده را میتوان یکی از نتایج ارزشمند در پایان هر فاز و یا تکرار دانست که مستند سازی و به اشترا ک گذاری آن بین افراد و تیمهای مختلف موجب صرفهجویی زمان و جلوگیری از هدر رفتن آن برای بدست آوردن مجدد آن تجربه میگردد. در نتیجه سرعت توسعه در تیمهای مختلف افزایش مییابد.
نتیجهگیری
مستند سازی در پروژههای توسعه نرمافزار یکی از بخشهای جدا نشدنی از پروژه میباشد، چه پروژه در یک سازمان بزرگ و چه در یک شرکت نوپا و استارتآپ. بنابراین مستند سازی را به عنوان یکی از بخشهای توسعه نرمافزار جدی تلقی نمائید و حتی در صورت کافی نبودن زمان سعی نمائید آنرا به سریعترین روش که میتوانید (حتی با استفاده از قلم و کاغذ) انجام دهید و یا در فرصتی مناسب که فشار تحویل پروژه کاهش یافته است و امکان تغییرات پایین آمده است. با گذشت زمان منافع مستند سازی را شاهد خواهید بود.
0 پیام