بایگانی

Posts Tagged ‘مهندسی نرم افزار’

مشکل کار شرکت های توسعه نرم افزار کجاست؟

سپتامبر 11, 2010 4 دیدگاه

اگر وبلاگ دنیای چابک را دنبال کرده باشید حتما می دانید که یکی از دغدغه های اصلی من بررسی مشکلات شرکت های توسعه نرم افزار و توسعه گران نرم افزار می باشد . در این باب مطالبی گوناگونی را قبلا نوشته ام :https://sirasad.files.wordpress.com/2010/09/problem-behavior.jpg?w=300

بعد از این همه نوشتن واقعا مشکل کار شرکت های توسعه نرم افزار کجاست ؟  شاید بعضی دوستان بفرمایند که چه مشکلی ؟ شرکت ها نرم افزاری که مشکلی ندارند ؟ کدام مشکل ! از چه حرف می زنید ؟ به نظر من شاید مشکلات زیر وجود داشته باشند :

  • برگشت نشدن سرمایه در زمان معقول

یکی از مشکلاتی که برای شرکت های ایرانی می تواند اتفاق بیفتید ,  نبرگشتن سرمایه در یک زمان قابل قبول است . یعنی یک سرمایه ای که در یک شرکت نرم افزاری می خوابد باید در یک زمان پیش بینی شده برگشت شود و سازمان به سود آوری برسد . این عمل را معمولا بازاری ها با مقایسه بیان می کنند و به این طریق می گویند که شما با سرمایه گذاری در این بخش برده اید و یا باخته اید : فرض کنید که شرکتی با سرمایه ای در حدود 100 میلیون به راه می افتد . با اجاره مکان ,  تجهیزات و برنامه نویس و … . این گروه یک سال طول می کشد تا یک محصول را توسعه بدهند و آماده عرضه به بازار کنند .بعد از عرضه به بازار معمولا باید کم کم با درآمد زایی شروع برگشت سرمایه انجام شود ولی این پروسه معمولا برای شرکت ها خیلی طول می کشد . باید تبلیغات بشود ,  بازاریابی بشود ,  مشتری اعتماد بکند و … . شاید تا 5 سال سرمایه گذار نتواند که سرمایه اولیه خود را بردارد و به این ترتیب بازاری ها اذعان می کنند که اگر با این پول چند تن برنج پاکستانی می خریدید الان سرمایه چند برابر شده بود . حتی اگر سرمایه برگشت بشود و حتی سودآوری هم انجام شود ولی در برهه زمان طولانی باز ضرر حساب می شود . البته شاید سرمایه گذاری های طولانی مدت را بعضی از تاجران بپسندند ولی حداقل برای موارد دیگرکه بعدا عرض خواهد شد , سرمایه گذار از سرمایه گذاری در این حوزه امتناع می کند .

  • ریسک بالای سرمایه گذاری

سرمایه گذار معمولا در فکر برگشت سرمایه خود و سپس در فکر سودآوری می باشد . ولی سرمایه گذاران حتما ریسک کار را در نظر می گیرند . صنعتی مثل صنعت توسعه نرم افزارکه ریسک سرمایه گذاری در آن بسیار بالا است ,  حتما باعث خواهد شد که سرمایه گذاران در فکر گزینه های دیگر باشند . چرا ریسک کار بالا است ؟ بدلیل اینکه برگشت سرمایه انجام نمی شود .

  • نبود سرمایه مناسب دراین صنعت

زمانی که من به این حوزه توسعه نرم افزار صنعت اطلاق می کنم بعضی از دوستان نارحت می شوند و می فرمایند که این به هرچیزی شبیه است جز یک صنعت . بلی من هم این مورد را قبول دارم معمولا صنعت ترکیب فکر و ایده با سرمایه است ولی منتهی بدلیل ریسک بالای سرمایه گذاری در این حوزه شاهد این هستیم که سرمایه گذاری های بسیار کمی در این حوزه شده است . و البته شرکت ها مافیایی را در نظر نمی گیریم که شاید آنها یک درصد بازار باشند و همه می دانند که سرمایه های کلان آنها از چه طریقی تامیین شده است و چگونه برگشت سرمایه می کنند . منظور من شرکت های کوچک و متوسط و بخصوص شرکت های قارچی (شرکت هایی که هرازگاهی در یک جایی با رعد برقی تاسیس و با بادی منحل می شوند)  است . https://sirasad.files.wordpress.com/2010/09/making_money.gif?w=318

برای بخش اول بررسی مشکلات قابل نتیجه گیری است که بدلیل مشکلات سرمایه گذاری در این حوزه شاهد فقدان سرمایه گذار می باشیم . فقدان سرمایه گذار باعث فقدان سرمایه در این حوزه شده است . همانطور که قبلا اشاره شد ,  برای به وجو آمدن یک صنعت باید هم فکر باشد و هم سرمایه . ما یکی تا اینجا سرمایه نداریم چگونه می خواهیم اسم کاری که انجام می دهیم را صنعت بنامیم ؟

مشکل اصلی این حوزه این است که توسعه نرم افزار صنعت نشده است . مگر شرکت قارچی می تواند اسم خود را صنعت گر بنامد ؟ مگر شرکتی که جمعا با سرمایه 2 میلیون شروع می کند می تواند خود را جزوی از یک صنعت بداند ؟ مگر 4 نفر دانشجو می تواند آغازگر یک صنعت باشند ؟ پس صنعت نیاز به سرمایه دارد و سرمایه هم نیاز به سرمایه دار دارد .

ولی چقدر سرمایه نیاز است ؟ 10 میلیون بس است ؟ یا 100 میلیون ؟به نظر من در وحله اول خود سرمایه دار مهمتر از سرمایه اش هست . نه مبلغ سرمایه  ,  یک Business Man  یا تاجر می داند که کی باید چقدر خرج کند پس به موقع خرج خواهد کرد البته اگر نیاز باشد . این مورد را بذکر یک مثال ساده عرض می کنم :

بنده خدایی که فارغ التحصیل رشته گرامی نرم افزار از دانشگاه معتبر کشور می باشد (از همان هایی که در استخدام در اولویت می باشند)  قصد در آمدزایی از آموخته های خود را دارد . با 6 میلیون سرمایه ای که دارد می خواهد یک محصول حسابداری تولید کند زیرا او حساب و کتاب کرده است که اگر او بتواند در عرض 3 ماه یک نرم افزار حسابداری تولید کند حداقل می تواند هر نسخه آن را 50 هزار تومان بفروشد . اگر هر ماه 10 عدد بفروشد یعنی در یک سال خواهد توانست سرمایه خود را بردارد و بقیه فروش ها هم سود خالص خواهد بود . با این خیال وارد حوزه (نه صنعت ) نرم افزار می شود و با استخدام چند نفر برنامه نویس (اغلب دانشجو و ناکارآمد و حتما خانم ) دستمزد پایین شروع به پروسه توسعه نرم افزار می کنند . برای شروع چندی از نرم افزار های موجود در بازار را خریداری و از آنها الگوبرداری (یا همان کپی برداری ) می کنند . بعد به طور رعد سا شروع به پیاده سازی می کنند . دقیقا سر 3 ماه کل نرم افزار تکمیل می شود و نرم افزار آماده فروش می شود . اولین ورژن برای دایی و یا عمو و یا همسایه ای که مغازه ای دارد نصب می شود . نتیجه ؟ نرم افزار آنقدر باگ دارد , آنقدر اشکال حسابداری دارد ,  آنقدر ویژگی کم دارد که دایی هم از استفاده از این نرم افزار سر باز میزند . نرم افزار به شرکت بر میگرد و طی جلسه ای  تیم متحد می شود که هر چه زودتر اشکالات و کمبود های نرم افزار رفع شود . ولی این رفع کردن حداقل 1 سال به طول می انجامد ؟ چرا ؟ بدلیل اینکه برنامه نویس کدی که خودش نوشته را قبول ندارد ! بدلیل اینکه خیلی از جاها باید بازنویسی شود ؟ بدلیل اینکه برنامه نوشته شده Reusable  نیست ؟ بدلیل اینکه برنامه اتوماتیک تست ندارد ؟ بدلیل اینکه برنامه نویس ناکار بلد بوده است  و به صد ها دلیل دیگر … . این پروسه رفع اشکال و بده به مشتری و مشتری ناراحت بشه و دوباره رفع اشکال و … تکرار می شود که مجبورا این شرکت قارچی تعطیل می شود و همه به خانه ها خود عظمیت می کنند .

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

پس برای نتیجه قابل عرض است : برای موفقیت باید شرکت تبدیل به یک صنعت شود . گفته شد صنعت شامل سرمایه و ایده و فکر می باشد . سرمایه هم باید به اندازه مناسب  و کافی برای نیل به هدف در زمان تعیین شده توسط یک  یا چند سرمایه گذار مناسب تامیین شود .  اما سوالی که شاید برای شما ایجاد شود این است که : سرمایه مناسب و کافی یعنی چقدر ؟

سرمایه مناسب و کافی مقداری است که بتوانیم با آن  نیروی انسانی مناسب پروژه را به تعداد کافی استخدام نماییم و بتوانیم ابزار ,  تجهیزات و تکنولوژی های لازم را برای آنها فراهم کنیم . اگر سرمایه در این حد باشد کاملا کافی است . و من این صنعت را قبول دارم که یک سرمایه گذار پیدا شود و به مقدار لازم برای یک ایده خرج کند تا آن ایده پیاده سازی شود .

https://sirasad.files.wordpress.com/2010/07/childlabour_brasil_ana.jpg?w=350تا اینجا ما تعریفی از صنعت نرم افزار داشتیم که در واقع این برای توسعه نرم افزار خوب و کارا یک بستر حساب می شود . و البته اشتباه نشود که صنعت نرم افزار فقط یک شروع است و نه بهشت برین . ما تازه با این همه مقدمه به این رسیدیم که بستر لازم برای ایجاد نرم افزار هیا خوب , داشتن یک صنعت می باشد . بعد از داشتن این صنعت و بستر تازه شروع به توسعه خواهیم کرد و البته مشکلات توسعه را هم تجربه خواهیم کرد ولی نه به شدت قبل .  شاید داشتن این صنعت ما را گول بزند همانند تیم رئال مادرید که بسیار برای تیم خود سرمایه گذاری کرد و بهترین بازیکنان را جذب کرد و بهترین امکانات را در اختیار آنان گذاشت ولی اصلا موفق نبودند .

در یک صنعت و برای موفقیت یک صنعت حتما نیاز به یک مدیریت منسجم و خوب می باشد . این مدیریت باید بتواند از سرمایه گذاری انجام شده به خوبی استفاده کند و منابع موجود را در جهت نیل به اهداف سازمانی مدیریت نماید . پس در یک صنعت توسعه نرم افزار با وجود یک مدیر با درایت و خوب , خواهیم توانست با داشتن منابع انسانی ,  مالی و تجهیزاتی مناسب  و با استفاده از یک پروسه توسعه نرم افزار مانند (Agile) در یک زمان معقول به اهداف خود ,  که همانا برگشت سرمایه و رسیدن به سودآوری می باشد ,  برسیم .

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

یاشیاسیز

Advertisements

CSM در ایران برای اولین بار

ژوئن 12, 2010 25 دیدگاه

با هماهنگی انجام گرفته با اساتید گرامی و بین المللی Scrum و Agile  از کشور سوئد خواهان برگزاری یک دوره CSM یا Certificated Scrum Master برای اولین بار در ایران و کشور های همجوار هستم . این دوره شامل آموزش کامل متد اسکرام طی 2 روز و اعطای مدرک CSM خواهد بود . امید است که بتوانیم این دوره را به نحو احسنت در ایران برای بار اول برگزار کنیم .البته این دوره در شرایطی برگزار خواهد شد که تعداد شرکت کننده در این دوره به حد نصاب برسد .

CSMhttps://sirasad.files.wordpress.com/2010/06/logo-certified-scrum-master-seal.jpg?w=260 چیست ؟

CSM مخفف Certificated Scrum Master می باشد و به کسی اطلاق می شود که مدرک Scrum Master بودن را داشته باشد . Scrum Master شخص اول و در واقع  برپا کننده و گرداننده اسکرام در تیم های توسعه نرم افزا می باشد و کل اسکرام بر پایه این اسکرام مستر خواهد بود  . CSM یک مدرک بین المللی و معتبر برای کسانی خواهد بود که می خواهند به عنوان اسکرام مستر در تیم های توسعه نرم افزار فعالیت داشته باشند .

مدرک CSM از طرف تشکل معتبر Agile Alliance به اسکرام مستر های عزیز اعطا خواهد شد و بدلیل معتبر بودن این مدرک در تمام جهان ,  شما به راحتی خواهید توانست در این رشته شغلی در هر کجای این کره خاکی مشغول به کار شوید .

مزیت این دوره چه می تواند باشد  ؟

  • آموزش کامل متد اسکرام طی کلاس ها ,  سمینار ها و کارگاههای عملی
  • رفع اشکال در مورد Agile و اسکرام به همراه اساتید جهانی این حوزه
  • دریافت مدرک بین المللی Scrum Mater
  • امکان اشتغال زایی به عنوان Scrum Master در تیم های توسعه نرم افزار

CSM در کشورهای دیگر چگونه است ؟

این مدرک در اکثر کشورهای پیشرفته جهان توسط تشکل Agile Alliance ارائه می گردد ولی در منطقه کشور ما فقط در کشور ترکیه و کشور هند ارائه می شود . منتهی در هر دو کشور با هزینه گزافی روبرو خواهید شد . برای مثال فقط خود دوره CSM در کشور ترکیه معادل مبلغ 1500 دلار آمریکا هزینه در بر خواهد داشت . این مبلغ را باید بعلاوه هزینه سفر (رفت و برگشت به ترکیه) و بعلاوه هزینه اقامت به مدت چند  روز و بعلاوه هزینه های متفرقه که در چنین کشورهایی خرج می شود باید بکنید .

فرق این دوره با دوره های کشور های همجوار چه خواهد بود ؟

دو فرق اساسی این دوره با دوره های کشورهای خارجی خواهد داشت :

  1. هزینه پایین: به خواهش بنده حقیر و بدلیل اولین برگزاری این دوره در ایران و با مساعدت  Agile Alliance این دوره با هزینه بسیار کم و شاید یک دهم کشورهای دیگر برگزار خواهد شد و تمام در آمدهای حاصله , خرج سفر اساتید گرامی ,  هزینه اقامت آنها  ,  هزینه محل برگزاری دوره و هزینه های متفرقه خواهد شد و به صراحت عرض می کنم بدلیل علاقه بنده به Scrum و تمایل به نهادینه کردن آن در ایران , بنده قصد درآمدزایی از این دوره را ندارم و فقط قصدم برگزاری این دوره در ایران می باشد .
  2. مدرسین : به جرات می توانم عرض نمایم مدرسینی که به امید خدا در خدمت آنها در ایران خواهیم بود ,  جزو اساتید جهانی و معروف حوزه Agile و Scrum  می باشند . ولی در کشورهای همجوار این دوره توسط اساتید بومی آنجا و با سطح بسیار نازل برگزار می شود .

در مورد اساتید دوره :

به احتمال زیاد ما در ایران در این دوره در خدمت دو تن از اساتید سوئدی اسکرام خواهیم بود  که هر دوی آنها کاربلد و در این حوزه از چهره های سرشناس جهانی می باشند . یکی از این برادران دوست عزیز Henrik Kniberg می باشد . این برادر پیشینه عریض و طویلی در زمینه اسکرام و Agile دارد ,  کتاب Scrum and XP from the Trenches او به جرات می توان گفت بهترین و روانترین کتاب در زمینه اسکرام می باشد . برای اطلاعات بیشتر در زمینه وی می توانید به این لینک مراجعه کنید .

هزینه دوره :

همانطور که در بالا عرض شد این دوره به دلیل اولین بار بودن آن با هزینه بسیار کم برگزار خواهد شد (شاید در دفعات بعدی بدین گونه نباشد) . این دوره در کشورهای مختلف با هزینه های مختلفی برگزار می شود : برای مثال این دوره در کشور سوئد با مبلغ 1500 یور برای هر نفر و یا در کشور ترکیه با مبلغ 1500 دلار آمریکا برای هر نفر برگزار می شود : ولی این دوره با حسن نیت دوستان به مبلغ 600-750 دلار کاهش یافت که مبلغ نهایی مابین این رنج خواهد بود .

ظرفیت دوره :

به دلیل اینکه دوره شامل کارگاههای آموزشی هم خواهد بود پس امکان حضور تعداد زیادی از دوستان نخواهد بود . حداکثر 20- 30 نفر قابل پذیرش خواهیم بود . اما اگر تعداد ثبت نام کننده بیش از این تعداد شد و به حد نصاب دو گروه برسد ,  این دوره در دو گروه مجزا برای رفاه حال دوستان برگزار خواهد شد .

محل برگزاری دوره :

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

زمان برگزاری :

زمان برگزاری دوره در اوایل دی یا اوایل بهمن خواهد بود و مدت دوره 2 روز می باشد .

چه کسانی می توانند در این دوره شرکت کنند ؟

پیش نیاز خاصی برای حضور در این دوره وجود ندارد ولی بهتر است کسانی در این دوره حضور بعمل بیاورند که درگیر در زمینه توسعه نرم افزار می باشند :

  • مدیران شرکت های توسعه نرم افزار
  • متخصصان توسعه نرم افزار(برنامه نویس ,  تحلیل گر , آزمایشگر و… )
  • مدیران پروژه

نحوه شرکت در این دوره :

بدلیل اینکه این دوره برای اولین بار در ایران برگزار خواهد شد و بدلیل معلوم نبودن بازخورد ملت در مورد این دوره ,  فعلا این مسئله در حد اعلان عمومی می باشد . از دوستانی که مایل به شرکت در این دوره می باشد خواهش می شود که بوسیله کامنت تمایل خود را برای شرکت در این دوره اعلام نمایند در صورت رسیدن به حد نصاب و مقبولیت کلی با این دوستان تماس گرفته خواهد شد و البته اعلانات بعدی به صورت عمومی را خواهند توانست دنبال نمایند . لطفا در هنگام ثبت کامنت , شهری را که مایل به برگزاری دوره در آنجا می باشد را معلوم نمایید.

پ . ن : از یکی از دوستان عزیز ساکن در تهران که توانایی رزرو مکان برگزاری این دوره را در یکی از هتل های خوب تهران با امکانات لازم برای این دوره را دارا می باشد وتمایل همکاری دارند لطفا با بنده با ایمیل safari_asad[at]yahoo[dot]com مکاتبه نمایند ,  بدیهی می باشد که در هزینه دوره این عزیز تخفیف ویژه ای در نظر خواهیم گرفت .

یاشیاسیز

چابک سازی سازمان و چرا ها

مه 18, 2010 5 دیدگاه

https://sirasad.files.wordpress.com/2010/05/agile.jpg?w=592طی درخواست یکی از مدیران شرکت توسعه نرم افزار پ .س (اسم نبردم شاید علاقمند نباشند) در مورد امکان مشاوره و مربی گری Agile بنده برای آن شرکت , 3 سوال اساسی توسط ایشان مطرح گردید که در این پست قصد طرح و جواب دادن این سوالات را دارم  . به این دلیل که شاید دیگر مدیران و یا اشخاص که علاقمند به دانستن و آشنایی با این مسئله باشند این جواب به صورت سرگشاده ارائه گردید .

سوالات مطرح شده به قرار زیر می باشد :

  • یک سازمان چه پیش فرض ها و نیازمندی هایی برای Agile شدن نیازدارد؟
  • برنامه من برای Agile کردن سازمان چیست ؟
  • عواید و منافع این کار برای سازمان چه چیز می باشد و چگونه می توان آن را اندازه گرفت؟

امیدوارم که حق مطلب را به جا آورده باشم و سوالات را عین پرسش مدیر گرامی مطرح کرده باشم . به دلیل اینکه سوالات به هم ربط دار می باشند همه آنها را به صورت یکجا و کلی جواب خواهم داد و در خواست من این خواهد بود که  اگر نوشته بنده جوابگو سوالات نبود تذکری داده شود تا کمی واضح تر و ریزتر جواب داده شود .

https://sirasad.files.wordpress.com/2010/05/a305-distributed-agile-development.jpg?w=280خوب بیان این مسئله و جواب سوال , » برای اینکه Agile بشویم چه چیز می خواهد»  در واقع بسیار سخت و مشکل می باشد بدلیل اینکه شرایط از هر تیم به تیم دیگر متفاوت خواهد بود و نمی توان یک نسخه واحد پیچید . ولی می توان گفت که Agile شدن برای تیم ها سختی و راحتی خواهد داشت . یعنی اینکه یک تیم با شرایط راحت تر و کم هزینه تر خواهد توانست Agile شود و یک تیم سخت و پر هزینه تر Agile خواهد شد . پس می توان گفت همه تیم ها و سازمان ها  شاید  توانایی Agile شدن را خواهند داشت ولی با درجه سختی متفاوت .

خوب شاید سوال کنید که این درجه سختی را چگونه می توان تعیین کرد . این درجه سختی را نمی توان جز با بررسی و ارزیابی  سازمان و اعضای سازمان تعیین کرد . باید تمام سازمان مورد ارزیابی قرار گیرد و بعد از ارزیابی می توان گفت که سازمان در چه وضعی است . در ارزیابی مهمترین مسئله توانایی و زمان Agile شدن است .

برای درک مسئله بهتر است یک مثال زده شود . فرض کنید بنده در تلویزیون مسابقه دو (دوندگی) را می بینم و مشاهده می کنم که به فرد برنده 400 میلیون دلار جایزه می دهند . با توجه به جایزه خوب وسوسه می شوم فردا در دوی مارتن شرکت کنم ولی بدون آمادگی و ارزیابی توانایی ها و ظرفیت های خودم . زمان مسابقه چند صد متر ندویده خسته می شوم و خواهم ماند . در این حالت دو حالت خواهم داشت :1- خواهم توانست تا به خانه برگردم و از دیدن مسابقه در تلویزیون لذت ببرم  2- ایست قلبی می کنم  و خداحافظ.

برای سازمان ها و شرکت های توسعه نرم افزار هم بدینگونه است . نمی توان با عجله و بدون ارزیابی توانایی سازمان و افراد شروع به چابک شدن کرد . مثلا فردا روز آقای مدیر از راه  می رسد و همه کارکنان رو جمع می کند و بعد از نطق در مورد فواید Agile می فرماید : «دوستان امروز می خواهیم Agile بشویم و سعی کنید تا امروز عصر کار را تمام کنید  ,  اینم مقالات وبلاگ دنیای چابک ,  زود بخونید تا شروع کنیم . هی ممد تو اسکرام مستر , خانم منشی به اون کاظمی (مشتری) زنگ بزن بیاد که اون Product owner ماست , دوستان زود باشید که سود ها و پول های کلان منتظر ما هستند و دیر بجنبیم از کف رفتند » .  و اینگونه خواهد بود که شاید بر خواهیم گشت به متد قبلی و یا ایست قلبی .

در مورد مثال دونده یک راه سومی هم وجود دارد و آن هم این است که من به موقع و در زمان مناسب در مارتن شرکت کنم . خوب عرض شد زمان مناسب ؟ زمان مناسب در این مثال این است که بنده به پیش یک مربی  دومیدانی بروم و او بنده را عرض یابی نماید و با توجه به توانایی جسمانی و روحانی بنده  ,  بنده را مورد آموزش و تمرین قرار دهد . زمانی که به توانایی لازم رسیدم می توانم در مارتن شرکت کنم . پس منتظر زمان مناسب خواهم بود .https://sirasad.files.wordpress.com/2010/05/tired_runner-758783.jpg?w=200

در مورد Agile هم باز بدینگونه است . اول سازمان باید مورد ارزیابی قرار بگیرد . باید (و دوباره باید) وضع و اوضاع فعلی سازمان استخراج و مستند سازی شود . به طور ساده باید فهمید که سازمان هم اکنون چگونه کار می کند و چگونه توسعه می دهد,  وضع ارتباطی آن با مشتری چگونه است اصلا چگونه مدیریت می شود و … . سپس با توجه به نقاط ضعف و کاستی های موجود , آموزش ها و توصیه های لازم باید اتخاذ شود .

شاید بپرسید شما که می خواهید Agile را پیاده سازی کنید چه کاری با وضع گذشته سازمان دارید ؟ درست است ما می خواهیم Agile را پیاده سازی کنیم ولی نه یک باره( تا سازمان سکته کند) . اصلاحا ما Agile را در کالبد تیم و پروسه قبلی تزریق خواهیم کرد و نه جایگزین . برای تزریق یک آمپول پنی سیلین باید آزمایش بدهید تا معلوم شود بدنتان حساسیت ندارد در صورت نداشتن حساسیت تزریق می شود در غیر اینصورت داروی جایگزین تجویز می شود .

ولی شاید توضیحات بالا تعدادی از مدیران را قانع نکند و آنها به دنبال فهمیدن و نام بردن چند عامل به صورت موردی می باشند .  خوب من می توانم چند مورد عمومی زیر را نام ببرم :

Agile می تواند در محیط ها و شرایط  زیر راحت ترو بهتر اعمال شود (و Agile کلا مناسب حال شرایط زیر می باشد) :

  • ارائه های اورژانسی : در بعضی از موارد هنگام توسعه نرم افزار باید نرم افزار به صورت زود به زود به مشتری ارائه شود در غیر اینصورت مشتری لنگ خواهد ماند . یعنی هم نرم افزار توسعه یافته می شود و هم توسط مشتری استفاده می شود .
  • کمبود اطلاعات و نیازمندی های پروژه یا محصول  در هنگام شروع پروژه و در فاز برپایی یا Initiate پروژه
  • در دسترس بودن همیشگی مشتری
  • نیروی انسانی سازگار
  • نیروی های انسانی در یک جا مستقر باشند
  • تیمی که واقعا تیم باشد

برای موانع در مورد  اعمال Agile هم می توان به موارد زیر اشاره کرد :

  • کمبود دانش Agile
  • تیم های بسیار بزرگ
  • توسعه به صورت توزیعی و گسترده به صورت فرا محلی
  • قراردادهای بسته (از نظر قیمتی و دامنه پروژه)
  • نیروی کار نابلد و یا نیروی کار تازه وارد و تازه تیم شده
  • حرکت به صورت سریع

موارد بالا شاید فقط تعدادی از موانع پیش روی تیم های و سازمان ها Agile هستند و برای اطلاعات بیشتر باید سازمان مورد بررسی قرار بگیرد .

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

اما در مورد سوال دوم . سوال شده است که برنامه بنده برای انتقال سازمان ها به Agile چه می باشد؟

برنامه و طرح بنده برای ارائه و کمک به سازمان ها برای انتقال به Agile شامل موارد زیر می تواند باشد:

  • بررسی سازمان و تعیین وضعیت فعلی سازمان
  • آموزش و نهادینه سازی ارزش ها و اصول Agile
  • آموزش اسکرام
  • برگزاری کارگاههای آموزشی در مورد متد اسکرام و XP
  • برپایی و استارت Agile در سازمان
  • بررسی وضع و نظارت بر عملکرد
  • برگزاری جلسات بازبینی عملکرد و تعیین روش های بهبود وضعیت

در حالت کلی برنامه در 4 سطح قابل تعریف خواهد بود : 1- بررسی 2- آموزش 3- اجرا 4- بازبینی

اما این طرح به صورت 100% نیست زیرا تیم ها و شرایط فرق می کنند و باید موارد و طرح هایی بعد از انجام کاری هایی پیش بینی شوند . یعنی آموزش به صورت 100% نیست . شاید در هنگام اجرا نیاز به آموزش دوباره تیم باشد . شاید بعضی از اصول Agile را باید فراموش کرد و شاید … و اینها همه به شرایط سازمان و افراد بستگی دارند. بدلیل اینکه عکس العمل و رفتار افراد در مقابل تغییرات قابل پیش بینی نیست ,  باید برنامه هایی در مورد عکس العمل های نشان داده شده بعد از اجرای Agile  طرح ریزی کرد .

ولی در کل هدف ما ارائه و عمل به مفهوم زیر در هر سازمان Agile خواهد بود :

https://sirasad.files.wordpress.com/2010/05/agilegoal.jpg

از طریق انجام و عمل به مفاهیم و اصول اصلی Agile خواهیم توانست به استراتژی درون سازمانی برسیم . مثلا با عمل به اصل «قبول و پذیرایی از تغییرات » که یکی از اصول Agile می باشد و در برنامه ما هم خواهد بود خواهیم توانست به یکی از استراتژی های اصلی سازمان که «ابقاء مشتریان » می باشد دست بیابیم  , که تحقق هر استراتژی سازمان مصادف با نزدیکی به هدف سازمان می باشد ,  که هدف سازمان شامل سود و منافع بیشتر می باشد .

اما در مورد سوال سوم . پرسیده شده است : «عواید و منافع Agile شدن  برای سازمان چه چیز می باشد و چگونه می توان آن را اندازه گرفت؟»

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

https://sirasad.files.wordpress.com/2010/05/agilechart.jpg?w=592

خوب همانطور که در مورد A مشاهده می کنید تیم در اواسط انتقال فرق زیادی نکرده است به این دلیل که در این بازه زمانی تیم در حال آموزش و یادگیری هست.  بعد تیم وارد دوره مقاومت شده است . در این دوران بهره وری به سرعت در حال  پایین  آمدن است . در دوران  مقاومت تیم از یاد گیری و اجرای متد جدید خودداری یا مقاومت می کنند . دوران بعدی دوران آشفتگی است . این دوران را می توان دوران بحرانی تیم ها و یا سازمان های Agile نام برد زیرا که سازمان در حال تجربه و پیاده سازی یک اندیشه جدید است و هنوز پخته نشده است  و بهروری پایین است .دوره بعدی پیش بسوی پختگی او دست یابی به منافع بهتر از قبل است و بهره وری را مشاهده می کنید که بسیار بالاتر رفته است .

دانشی که از نمودارهای بالا حاصل شد گواه این قضیه خواهد بود که نباید انتظار داشته باشیم در چند روز به بهره وری مناسب  و بالا برسیم  . حتی باید منتظر پایین آمدن بهره وری هم باشیم . در همین باب در کتاب پنج دشمن کار تیمی می خوانیم :» برای جوش خوردن درست استخوان شکسته یک انسان ,  شاید لازم باشد دوباره آن راشکست و دوباره به هم متصل کرد و این درد آور خواهد بود ولی لازم است » .

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

اگر سازمان بتواند دوران بحران را به سلامت بگذراند خواهد توانست به منافع خوبی دست بیابد : اعم از رضایت مشتری ,  سود بیشتر و … . برای باور بهتر این قضیه بهتر است دست به دامن آمار و ارقام شویم و مشاهده کنیم که کشورهای موفق و پیشرفته جهان با Agile به چه دستاوردهایی دست یافتده اند .

شرکت  VersionOne در سال 2007 آمارگیری در زمینه Agile انجام داد . در این آمارگیری 1500 نفر از 71 کشور مختلف حضور داشته اند . در این آمارگیری VersionOne خواسته تا بداند این 1500 نفر در شرکت هایشان که با Agile کار می کنند تا چه حد موفق بوده اند و نتیجه آمارگیری به صورت زیربوده است : (شاید قابل باور نباشد)

https://sirasad.files.wordpress.com/2010/05/agilebenefit.jpg

هر یک از ستون ها یک شاخص بسیار مهم برای یک شرکت توسعه نرم افزار می باشد . مثلا شرکت ها اذعان داشته اند که بعد استفاده از Agile  توانسته اند 90%  به بهروری خود بیفزایند که بسیار گام خوبی می باشد یا 66% در هزینه ها کاهش داشته اند که بسیار عالی است . البته این اعداد در بهترین حالت ها و در کشورهای متمدن جهان با فرهنگی بالا در زمینه توسعه نرم افزار جمع آوری شده است و در ایران هم می توان به متوسط  این اعداد دست یافت (فردا روز یقه ما رو نگیرید که چرا ما به 90% بهروری بیشتر نرسیدیم ) .

در مورد اندازه گیری موفقیت هم می توان گفت که هر یک از شاخص های بالا قابل اندازه گیری هستند و می توان موفقیت  یا عدم موفقیت یک سازمان را بعد از تبدیل به Agile با آن سنجید و درصد پیشرفت را مشخص کرد .

البته برای هر یک از سوالات می توان چندین سمینار ارائه کرد و یا  کتاب نوشت ولی در این نوشتار امیدوارم توانسته باشم به سوالات مطرح شده  اندکی جواب بدهم .

یاشیاسیز

تست نرم‌افزار در Agile Software Development

ژانویه 13, 2010 بیان دیدگاه

همان‌طور که می‌دانید Unit Testing به معنای تست کردن قسمت کوچکی از برنامه است که ماجول یا یونیت برنامه نام دارد و می‌تواند در پیدا کردن اشکالات برنامه بسیار مؤثر واقع شود، اما در حقیقت نوشتن یک Unit Test بیشتر عملی است که در قسمت طراحی نرم‌افزار به کار می‌رود تا در قسمت Verification یا اشکال‌یابی، و می‌تواند نظرات کاربران را بگیرد.  به این معنا که وقتی کاربری در مورد سیستم نظر داد که مشکلی در Unit وجود دارد و آن مشکل در Unit Testing حل شد، در قسمت‌های بعدی نمی‌توان از او برای آن قسمت از برنامه نظرخواهی کرد. علاوه بر آن، عملکرد صحیح تمام Unit Testها نمی‌تواند بدین معنا باشد که همه سیستم خوب کار می‌کند؛ زیرا ممکن است در ارتباط اجزای سیستم مشکلی پیش آمده باشد.

https://i0.wp.com/leonmeijer.nl/images/leonmeijer_nl/WindowsLiveWriter/TestdrivendevelopmentUni.NETwhatsallthis_D86E/sw_testing.jpg

Test Driven Development

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

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

یکی از مهم‌ترین مزایای این روش این است که برنامه ما آزمون‌پذیر یا Testable است. از دیگر مزایای نوشتن تست قبل از نوشتن برنامه این است که می‌توانیم مستندات خود را از روی این تست‌ها داشته باشیم. مثلاً اگر می‌خواهید بدانید که یک Object چگونه فراخوانی می‌شود و چه پارامترهایی باید به آن فرستاد، کافی است به تست آن کلاس نگاهی بیندازیم. این مستندات همیشه بروزند و حتی قابل اجرا نیز هستند.

شکل 1 دیاگرام UML قسمتی از سیستم حقوق دستمزد را نشان می‌دهد. کلاس payroll از کلاسEmployeeDatabase برای گرفتن objectهای کارمندان یا Employee استفاده می‌کند. در حقیقت این کلاس از کلاسEmployee درخواست می‌کند که حقوق کارمند را حساب کند. سپس این حقوق را به شیء CheckWriter جهت چاپ چک کارمند ارسال می‌کند. در آخر نیز این پرداخت را به کلاس Employee جهت پست کردن چک ارسال می‌کند و object مربوطه را به  دیتابیس پاس می‌دهد.

شکل 1

تصور کنید که تا به حال هیچ کدی برای این سیستم ننوشته‌ایم و این دیاگرام تنها چیزی است که ما در جلسه اولیه شناخت سیستم داریم. اولین قدم برای ایجاد چنین سیستمی، نوشتن تست‌هایی است که عملکرد شیءpayroll را مشخص کند. ممکن است از خود سؤال کنید: ما که هنوز نمی‌دانیم از چه پایگاه اطلاعاتی استفاده می‌کنیم. آیا می‌خواهیم در سیستم خود از Sql Server استفاده کنیم یا از  اوراکل؟ شاید هم سؤال کنید که چگونه می‌توانیم بفهمیم که چک کارمندی واقعاً چاپ شده است یا خیر؟

شکل 2

چون اطلاعاتی که در دست داریم کم است، می‌توانیم از Mock Object یا شیء ظاهری استفاده کنیم. راه حل این است که از اینترفیس استفاده نماییم. برای این کار می‌توانیم همان‌طور که در شکل 2 مشاهده می‌کنید، اینترفیس‌هایی بین کلاس‌های مرتبط در سیستم payroll قرار دهیم و تست مربوط به این اینترفیس‌ها را بنویسیم. هم‌اکنون از اینترفیس‌های EmployeeDatabase و CheckWriter و Employee جهت برقراری ارتباط بین شیء‌ها استفاده می‌شود. اضافه بر این، سه Mock Object هم ایجاد شده است که با اینترفیس‌ها ارتباط برقرار می‌کند. اینMock Objectها توسط شیء payrollTest مورد جست‌وجو قرار می‌گیرند تا صحت کار شیء payroll را تضمین کنند.
تست زیر می‌تواند برای این کار مورد استفاده قرار گیرد:

Public void testPayRoll()
{
MockEmplyeeDatabase db=new MockEmplyeeDatabase();
MockCheckWriter w=new MockcheckWriter();
Payroll p=new Payroll(db,w);
p.payEmployees();
assert(W.checksWereWrittenCorrectly());
assert(db.paymentsWerePostedCorrectly());
}


همان‌طور که در این کدها مشاهده می‌کنید، شیء‌های Mock به وجود میآیند و آن‌ها را به شیء Payroll ارسال می‌کنیم و به شیء payroll می‌گوییم که پرداخت به تمام کارمندان را انجام دهد. بعد از آن از شیء Mock در مورد صحت عملیات انجام شده سؤال خواهد شد. کاری که این تست انجام می‌دهد، در حقیقت این است که چک کند که شیء payroll رویه‌های صحیح و با اطلاعات صحیح را فراخوانده است یا خیر. ولی این بررسی نمی‌تواند تست کند که آیا چک‌ها درست نوشته شده‌اند یا خیر. به ‌علا‌وه، نمی‌تواند بررسی کند که پایگاه اطلاعاتی بروزآوری شده است یا خیر؟  کاری که این تست انجام می‌دهد این است که کلاس ‌Payroll را به تنهایی چک کند.

Acceptance Test
Unitتست‌ها در حقیقت ابزاری ضروری برای تست کردن سیستم به شمار می‌روند، ولی کارایی خوبی ندارند؛ زیرا نمی‌توانند صحت کارایی کل سیستم را تضمین نمایند. Unit Testها در واقع تست‌های جعبه سفید (White box)  هستند که در آن تنها مکانیزمی خاص در سیستم چک می‌گردد. برای این‌که بتوانیم نیازهای کاربران سیستم خود را چک کنیم، به تست Black box یا Acceptance Test نیاز داریم. این تست‌ها نیازهای کاربران را در قسمت‌هایی از برنامه چک می‌کنند و ما را از این‌که نیاز کاربران از سیستم بر آورده شده است یا خیر، مطلع می‌کنند. این تست‌ها معمولاً توسط کسانی نوشته می‌شوند که هیچ اطلاعاتی از مکانیزم سیستم و اجزای داخلی آن ندارند و معمولاً توسط کاربران سیستم تهیه می‌شوند Acceptance Testها برنامه‌هایی هستند که حتی می‌توان آن‌ها را اجرا نمود و اغلب با استفاده از Scripting Languageها نوشته می‌شوند.

وقتی مشتری سیستم این تست‌ها را نوشت، برنامه نویسان می توانند برای این‌که از نیاز کاربران آگاه شوند، آن تست‌ها را بخوانند. برای مثال، سیستم حقوق و دستمزد را در نظر بگیرید. در مرحله اول ما باید بتوانیم کارمندی را به سیستم اضافه نماییم یا او را از دیتابیس حذف کنیم. به کدهای زیر که قسمتی از این تست هستند نگاه کنید:

‌در این تست ما کارمندی را با شماره 1256، نام Amin Safaei و حقوق دو میلیون در بانک اطلاعاتی وارد کرده‌ایم. سپس به سیستم می‌گوییم وقت پرداخت است و باید حقوق کارمند را پرداخت کنیم. سپس تست می‌کنیم که چک آن کارمند با مقداری که وارد کرده‌ایم، چاپ شده است.

Public void testPayRoll()
{
 MockEmplyeeDatabase db=new MockEmplyeeDatabase();
MockchekWriter w=new MockCheckWrit();
}


همان‌طور که مشاهده می‌کنید، نوشتن این تست برای کارفرمای سیستم کار آسانی است. اضافه کردن امکانات جدید به این قطعه کد نیز کار سختی به نظر نمی‌رسد.

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

منبع : مجله شبکه

یاشیاسیز