متدلوژی های موفق طراحی سایت (قسمت دوم)
ادامه از قسمت اول
Agile
حالا به سراغ تعریف پروسه ای مخصوص به خود میرویم که تمامی نیازهای ما را پاسخگو باشد و ازطرفی نیز ساده و دم دستی باشد . این روش امروزه با نام agile شناخته میشود که در این مورد خاص بنام Feature Driven Development یا به اختصار FDD نامیده میشود ; دیگر شاخه های مشهور agile عبارتند از XP , Scrum , Crystal و DSDM . واضح است که روش FDD به نسبت سایر روشهای مطرح شده با فاصله بهترین متدلوژی ساخت وب سایت است بنابراین تصمیم گرفتم تا با بررسی بیشتر توانایی این روش را برای مطابقت با نیازهای سازندگان وب سایت بسنجم . فقط در ابتدا این را بگویم که منتظر عصای معجزه گر موسی نباشید .
بررسی اجمالی FDD
FDD یک متدلوژی ساخت بر اساس AGILE است که توسط جف دلیوچا طراحی شده ، او مقصودش از ساخت آن را چنین شرح میدهید : " پیش برد و انجام مراحل ساخت نرم افزار با رعایت زمان بندی ، همراه با آگاهی دقیق و موثر از تمامی قوائد کلیدی داخل و خارج پروژه " ( نگران نشید ، منم نفهمیدم چی گفته ، احتمالا خودش هم ! . مترجم ) بصورت خلاصه ، FDD به روشنی شامل 5 پروسه واضح است که قابلیت توضیح در 5 صفحه کاغذ را داراست . هسته FDD بر اساس مفهوم عملکرد مورد انتظار مشتری بنا نهاده شده است . مراحل FDD به این صورت طراحی شده که تک تک اجزا پروژه را بعنوان ویژگیهای آن تعریف می کنیم ، سپس این ویژگیها را با روش های تکراری طراحی کرده و می سازیم . ساختار سطح بالای متدلوژی FDD بصورت دیاگرام زیر است :
فرایند 1 : یک مدل کلی بسازید
این مرحله ، پروسه ابتدایی انجام پروژه است که همراه با اعضاء اجرایی و زیر نظر و با هدایت یک طراح شیء گرا با تجربه به عنوان معمار ارشد است .
فرایند 1 شامل ایجاد مدلی از خصوصیات مورد نیاز توسط تیم پروژه است ، مدلی که کاملتر از طرح ذهنی اولیه است . این مدل قرار نیست با همه روشها و مشخصاتش کاملا توصیف شود بلکه این مرحله صرفا مخصوص ایجاد شکلی کلی اما صحیح از نحوه ارائه پروژه بصورت یک مدل است نه با جزییات کامل .
این مرحله باید با مشارکت حداکثری همه اعضاء تیم انجام شود . ساخت این مدل بصورت مرحله به مرحله امکان پذیر است . در ابتدا یک متخصص راه حل های تجاری ، قسمتی از خصوصیت را توضیح میدهد سپس تیم پروژه به چند گروه تقسیم میشوند ( ترجیحا گروههای 3 نفره ) تا آن قسمت پروژه را مدل سازی کنند . سپس گروهها مدل خود را ارئه می کنند و برای استفاده از یکی از مدل ها به توافق می رسند . سپس برای سایر قسمتهای پروژه مورد نظر این پروسه تکرار می شود . نتیجه نهایی مدل کامل راه حل پروژه است .
فرایند 2 : لیستی از امکانات تهیه کنید
این مرحله نیز جزو مراحل اولیه اجرا پروژه است که به شناسایی تمامی امکانات مورد نیاز برای پشتیبانی از نیازهای پروژه می پردازد .
تهیه این لیست بر عهده برنامه نویس ارشد مسوول در مرحله مدلینگ است . بر خلاف مرحله 1 نیازی به حضور کارفرما و ذی نفعان در این مرحله نیست . اکنون زمان ایجاد لیست نیازمندی های پروژه است : نیازی به همفکری و همکاری نیست ، در این مرحله ایجاد گروههای کاری سازنده نیست .
نکته کلیدی در این مرحله تعریف پروژه به زبان بازاراست و این بدان معنیست که کارفرما بتواند منفعت دقیق هر ویژگی و ارزش آن را در مقابل هزینه های آن درک کند و همینطور باعث ایجاد درکی متقابل بین کارفرما و تیم میشود و خطر بدفهمی و یا احساس مغبون شدن را از بین میبرد.
ارتباطات ضعیف پایه و اساس بیشتر مشکلات در این کسب و کار است . کلماتی که ما بکار میبریم موثرترین عامل تاثیرگزاری بر دیگران است . در این مرحله مهمترین نکته اینست که ما چطور هزینه ها را برای کارفرما توجیح می کنیم و چقدر میتوانیم به زبان او منابع را درخواست کنیم . ممکن است این مرحله خیلی ساده و سرراست به نظر برسد اما مطلقا آن را دست کم نگیرید چون خیلی روی کل پروژه تاثیر گذار است .
تعریف کردن همه چیز بر اساس ویژگی از اشتباهاتی که ممکن است در اثر بدفهمی کارفرما و تیم سازنده بوجود آید جلوگیری می کند و در این موقعیت نقش مدیرپروژه برای تفسیر و ترجمه زبان بین این دو بسیار سازنده وحیاتیست . در صورتی که مدیر پروژه به درستی نتواند ارتباط بین کارفرما و تیم اجرایی را برقرار کند مشکلات شروع به خود نمایی می کنند . البته از مدیر پروژه نباید انتظار معجزه داشته باشید !
فرایند 3 : برنامه ریزی کنید
این پیش مرحله به چگونگی ایجاد برنامه کاری پروژه می پردازد.
این مرحله در امتداد و ادامه مرحله 2 است و ابزاری است برای مشخص کردن مراحل ساخت سایت که چه برای کارفرما و چه برای سازندگان بسیار مفید و کاربردی است . در این مرحله مدیر پروژه و برنامه نویس ارشد باید در مواردی مانند کدام خصوصیات در چه زمانی ساخته شود ، محول وظایف به اعضاء و ایجاد استراتژی برای ارائه دمو به کارفرما های کم تحمل با یکدیگر شورت کنند.
فرایند 4 : بر اساس ویژگیها طراحی کنید
فرایند چهار شامل فعالیت هایی بر اساس ویژگیهای مطلوب است تا بتوان پروژه را بر اساس یک بسته طراحی ویژگیها تعریف کرد . این پروسه را می توان به سه بخش تقسیم کرد : بررسی کلی ، طراحی و بازرسی .
در بخش بررسی کلی ، برنامه نویسان پیش از شروع کار با نقش کلی خود در انجام پروژه آشنا میشوند سپس در بخش طراحی نقش آنان به دقت و با جزییات ترسیم شده و سپس نکات و ابهامات بازرسی دقیق می شود .این بخش باعث میشود که اگر تعارض و یا مشکلی وجود داشته باشد قبل از اینکه کارکنان حتی یک خط کد بنویسند خود را نشان دهد و میتوان با هزینه ای اندک آن را برطرف کرد .
خیلی بدیهی بنظر می رسد که قبل از انجام پروژه ای باید آن را طراحی و یا بازرسی کرد اما نتیجه تحقیقات نشان می دهد که معمولا این مراحل نادیده گرفته می شود . در خیلی از صنایع ایده ساخت پیزی قبل از اینکه به دقت تعریف ، طراحی و یا برنامه ریزی شده باشد اجرا نمی شود و متاسفانه وضعیت در صنعت طراحی سایت نیز همین گونه است . اولین کار یک سازنده سایت پس از قبول پروژه معمولا باز کردن ادیتور و شروع به کد نویسی است . مقدار ریسک در پروژه ای که بدین صورت انجام شود فوق العاده بالاست . اما دقت شود که در انجام این مراحل نیز نباید افراط شود زیرا تلاش برای طراحی همه چیز و بدون ایراد بودن ممکن است به فلج تحلیلی منتج شود.
اینکه در این مرحله چقدر به دقت و وسواس نیاز است موضوعی مورد مناقشه در میان متدلوژیست ها می باشد. رویکرد FDD مرز مشخصی میان پروسه 1 و پروسه 4 قائل می شود . همانطور که دیدیم پروسه 1 شامل طراحی اولیه بدون است که جزییات را نادیده می گیرد و تمرکز بر جزییات به فرایند 4 محول شده است . قراردادن طراحی جزییات در این مرحله و قبل از کد نویسی به زیرکی انجام شده است . همچنین این پروسه ، پروژه را بر اساس تک تک جزییات به قطعات کوچک و مستقل تقسیم بندی می کند . به محض پایان یافتن طراحی ، کد نویسی آغاز می شود .
فرایند 5 : بر اساس ویژگی ها شروع به ساخت کنید
پروسه 5 انجام عملیات اجرایی برای ایجاد پروژه بر اساس ویژگیهای مطلوب کارفرماست.
پروسه 5 را می توان به 3 بخش تقسیم کرد : کد نویسی ، بررسی کدها ، ارتقاء به محصول . مانند پروسه 4 ، استفاده از هم فکری اعضاء و همچنین مزایای نظارت غیر قابل کتمان است . چیزی که این مرحله را منحصر به فرد می سازد بخش " ارتقاء به محصول " است.
برای اینکه مجموعه ای از کدها به مرحله " ارتقاء به محصول " برسد در وهله اول باید به پایان رسیده باشد . نکته اصلی در اینجا تعریف عبارت " به پایان رسیدن " است . پروژه تا وقتی که کاری باقی مانده است به پایان نرسیده . راه فهمیدن این موضوع اینست که مدیر پروژه باید از برنامه نویسان یک سوال ساده بپرسد ; " آیا کار به پایان رسیده ؟ " اگر جواب برنامه نویسان " بله " بود ، سوال دیگری باید پرسیده شود ; " کار دیگری برای انجام دادن باقی مانده ؟ " . این سوال واکنشهای متفاوتی ممکن است ایجاد کند ، دلیل این سوال ، گمراه کردن و یا گیر انداختن برنامه نویسان نیست بلکه سنجش وضعیت است چون بعضی برنامه نویسان تمایل دارند که تا ابد به ارتقاء ، بهبود و بهتر کردن کدهای خود ادامه دهند که البته در صورت وجود زمان کافی این امر بدون ایراد است اما در صورتی که با زمان بندی مواجه باشیم ، مدیر پروژه باید برنامه نویسان را به کامل کردن و تحویل کار در زمان معین وادار کند . این پروسس بهترین راه حل برای انجام این کار است.
مزیت دیگر این فرایند اینست که مدیر پروژه بصورت کامل در جریان میزان پیشرفت کار و همچنین قابلیت های عملی هر برنامه نویس پی می برد . بر طبق گفته " جرالد واینبرگ " نویسنده کتاب مدیریت کیفی نرم افزار ، به قابلیت های عملی برنامه نویسان میتوان از 1 تا 20 نمره داد . مسئله اصلی در اینجا نحوه ارزیابی این قابلیت است .فرقی نمی کند که بازه زمانی برای سنجش کیفیت برنامه نویسان 2 ساعت و یا 2 هفته باشد ، یک مدیر پروژه با احتساب حجم کار محوله به یک برنامه نویس می تواند بازدهی او را بدقت محاسبه کند.
بکار بردن روش FDD برای ساختن سایت
اجرای یک روش جدید برای ساختن سایت سخت تر از چیزیست که بنظر می رسد. آدمها از تغییر گریزانند و حتی کسانی که معمولا از نوآوریها استقبال می کنند به سرعت و با اولین سختی ها روی به روش های قدیمی می آورند . بنا براین برای ارزیابی روش FDD ، آن را روی تیم خود آزمودیم .
مرحله بعدی موضوعاتی مانند تطبیق سیاست های داخلی و مجتمع کردن سیاست گزاران تیم بود. روش FDD ساده و زود فهم است و برای مدیران افزایش بازدهی ایجاد شده با استفاده از این متدلوژی ملموس است . بر این اساس توانستیم بودجه لازم برای برگزاری یک دوره آموزشی را دریافت کنیم . شرکت کنندگان این دوره تمامی کسانی بودند که به نحوی اجرا FDD بر کار آنان تاثیر گزار است از جمله : برنامه نویسان ، تحلیل گران کسب و کار ، مدیر پروژه ها ، یک طراح و یک تست کننده .
در پایان دوره ، اشتیاق شرکت کنندگان ملموس بود . جنبه های شاخص FDD که به نظر بسیار جالب و کاربردی هستند عبارتند از :
- قابلیت های برنامه ریزی و گزارش گیری
- منظم و شفاف بودن
- مطابق با نیازهای کارفرما بودن
- کاهش ریسک با :
طراحی مداوم و ساخت بصورت مرحله مرحله
شفافیت منابع مورد نیاز
فهم بهتر از پروژه
عدم نیاز با بازنگری های متعدد
ما همپنین دریافتیم که متد FDD پاسخی کامل و بی نقص به نیازهای ما نخواهد بود . FDD مراحل برنامه نویسی را بدقت تحت پوشش قرار می دهد اما در رابطه با مواردی مانند جمع آوری اطلاعات ، طراحی رابط کاربری ویا تست نهایی هنوز کامل نیست . نقاط ضعف FDD از نظر ما عبارتند از :
وابستگی فراوان به رهبری تکنیکی
مسکو ماندن رابط کاربری و ساخت آن
بر روی پروژه های بزرگ بهتر جواب گو است
تست نهایی و عرضه را پوشش نمی دهد
ودر نهایت بدانید که FDD معجزه نمی کند ! و طبیعتا ما مجبوریم که آن را با نیازهایمان مطابقت دهیم.
مدیریت گذار
مرحله بعدی چکش کاری و مطابقت دادن روش FDD با بیزینس طراحی و ساخت سایت است . ما روی پروژه های زیادی کار می کنیم و طبیعتا نمیتوانیم وسط کار متدلوژی اجراء را تغییر دهیم .بنابراین شروع کردیم به اجرا و پیاده کردن مرحله به مرحله FDD .
ما شروع به اجرا متدلوژی از چند جنبه متفاوت بر روی یک پروژه جدید کردیم:
تعریف پروژه بر اساس ویژگیها ( از منظر کارفرما )
ایجاد نقشه کاری بر اساس ویژگیها
پیاده کردن ساختار جدیدی برای تیم ، طراحی و بررسی کدها
برپایی جلسات بررسی پروژه بصورت هفتگی
سپس ، یک پروژه آزمایشی داخلی بر اساس متد را اجرا کردیم . اینترانت موسسه نیاز به یک باز طراحی داشت و ما این چالش را فرصت مناسبی برای امتحان متد خود یافتیم و البته تست کردن مواردی که در FDD بر روی آنان کار نشده مانند ایجاد رابط کاربری . و نتیجه آن این شد که مدیرپروژه و یک برنامه نویس تصمیم گرفتند که FDD را بر روی پروژه بعدیشان نیز اجرا کنند.
پروژه اینترانت به دلایل زیادی به نتیجه مطلوب نرسید و البته این دلایل مطلقا به FDD مربوط نبود . این پروژه دچار مشکلاتی شد که تقریبا همه پروژه های داخلی دچار آن می شوند : بصورت خلاصه نبود حامی مالی و انگیزه . اگرچه ما مرحله بررسی نیازمندی های پروژه را بخوبی اجرا کردیم نبود انگیزه مالی به ما ضربه زدو این موضوع درس بزرگی به ما داد و آن این بود که مهم نیست که شما از چه متدلوژی استفاده می کنید ، در صورت نبود انگیزه کافی ، پروژه حتما به مشکل خواهد خورد . و اما نکته مثبت این بود که به این نتیجه رسیدیم که در صورت نیازها به دقت تعریف شوند FDD به خوبی از عهده وظایفش بر می آید .
و اما برویم به سراغ پروژه بعدی که توسط برنامه نویس خبره ما و بر اساس متدلوژی FDD اجرا شد . نتایج خارق العاده بود ، برنامه نویس ما به خوبی از عهده ایجاد دامنه کاری برامد و همینطور مدیر پروژه به سادگی می توانست مراحل کار را زیرنظر داشته باشد هرچند تیم سازنده با چالش هایی مواجه شد .در تعریف مدل کلی پروژه ، FDD از تکنیکی بنام color modelling استفاده کرد .( رجوع شود به کتاب Java Modelling IN Color With UML )
بطور معمول فرایند مدل سازی برای کارفرما نامانوس است بنابراین ، نیاز است که او در مورد این تکنیک توجیح شود و البته به این معنی نیست که او باید در زمینه UML متخصص شود بلکه باید اطلاعات کلی در این رابطه را به او ارائه کرد . تفسیر و توجیه این موضوع برای کارفرما چالش برانگیز است . در رابطه با اکثر کارفرما ها ما دریافتیم که در صورت توجیح مناسب ، حس بسیار خوبی در مورد این روش پیدا خواهند کرد .
هنگامی که تیم پروژه کوچک است و مثلا شامل یک برنامه نویس ، یک طراح و یک مدیر پروژه است ، راه کمی هموارتر می شود . نیازی به ایجاد تیمهای مختلف ، تقسیم وظایف ، نظارت بر پیشرفت کار تک تک افراد و چیزهایی از این قبیل نخواهد بود . یکی از مسائلی که در کارگاه توجیحی پس از معرفی FDD ایجاد شد ، وابستگی شدید پروسه به معمار ارشد بود . این موضوع میتواند مشکل ساز باشد ، زیرا اگر او کار خود را بخوبی بلد نباشد پروژه دچار مشکلات اساسی می شود . اگرچه این موضوع در تمام پروژه های کوچک صدق می کند : اگر شما در تیمتان برنامه نویسی حاذق نداشته باشید حتما دچار مشکل می شوید.
در نهایت ، ما شاهد پیشرفت های قابل توجهی در تمامی قسمتهای پروژه بودیم که بعضی از آنها واقعا غیر قابل باور بودند . هدف ما استفاده از این متدلوژی برای بهبود پروسه انجام پروژه بود اما تاثیری که این روش بر روی بهبود روحیه اعضاء تیم گذاشت غیر منتظره بود. این حقیقت ساده که ما می خواستیم کارکردنمان را ساده تر و موثر تر کنیم تاثیر فوق العاده ای داشت . اعضاء تیم خوشحال تر بودند زیرا میدیدند که روش جدید راه حل مناسبی برای رفع مشکلات ناراحت کننده همیشگی آنان است . این متد جدید همچنین باعث شد که مدیر پروژه و مدیر توسعه نرم افزار که معمولا زبان مشترکی با یکدیگر ندارند بتوانند با یکدیگر تعامل سازنده ای برقرار کنند زیرا احساس می کردند برای هدفی مشترک و با روشی یکسان می جنگند.
در زمینه اجرا پروژه نیز با پیشرفت های خوبی روبرو بودیم . اگرچه هنوز با مشکلاتی دست و پنجه نرم می کردیم اما تعدادشان کاهش یافته بود و آسانتر مدیریت می شد . بررسی وضعیت پیشرفت کار و مراحل انجام شده نیز به سرعت و سادگی قابل انجام بود. مثلا ، سوال کردن از برنامه نویسان در مورد وضعیت پیشرفت بهینه سازی بانک اطلاعاتی منتج به یکی از این عکس العمل ها خواهد شد ، بعض از آنان به این سوال کارفرما که چه زمانی کار به پایان می رسد اصولا جوابی نمی دهند ، نه به این دلیل که تعمدا قصد فرار از زیر بار مسوولیت را دارند بلکه بیشتر اوقات جواب به این سوال که زمان دقیق پایان کار را مورد سنجش قرار می دهد کار بسیار سختی است .
ولی می توان گفت که یکی از مزایای کلیدی متدلوژی های مبتنی بر ویژگی همین است که وقتی یک پروژه بر اساس ویژگی هایش تعریف شود ، بعضی از پیچیدگیهایی که مورد سوال کارفرماست خود بخود ساده می شود . بر اساس قرار ، هر ویژگی باید طوری تعریف شود که بیش از 2 هفته برای انجامش نیاز به زمان نباشد ، بنابراین هنگامی که از سازنده در مورد زمان اتمام یک ویژگی سوال می شود ، او باید یک " عدد " بین یک روز تا هفته را اعلام نماید . این روش بصورت موثری به مدیریت کار توسط خود سازندگان کمک خواهد کرد و بجای گفتن چیزی که مدیر پروژه را خوشحال می کند ، حقیقت را علام می کنند.
متاسفانه زمان ما برای رصد تاثیرات بلند مدت اجراء روش FDD کافی نبود زیرا 6 ماه بعد بدلیل پدیده سقوط دات کام ، شرایط آزمایش از حالت کنترل شده خارج شد و نتایج غیر قابل استناد شدند.
ادامه قسمت سوم مقاله
