بایگانی

Archive for the ‘Project Management’ Category

Agile دارویی برای تمام امراض

مارس 18, 2011 7 دیدگاه

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

https://sirasad.files.wordpress.com/2010/04/agile-pills.png?w=228&h=152یکی از مشکلاتی که در جوامع تازه آشنا با Agile یا متعلقات گرامی مانند اسکرام می تواند اتفاق بیفتد جو زدگی می باشد. برای مثال مدیر شرکتی با خواندن یک مقاله یا کتاب در مورد Agile  به این فکر می افتد که :»این همونه – این خودشه – همینه یا …» و سریعا اقدام به چابک سازی شرکت با معلومات یک مقاله ای یا کتابی می کند.مشکل از آنجایی حادث می شود که در مقالات یا کتاب های Agile (مانند منابع بنده) , Agile به گونه ای تشریح می شود(یا شده است) که اصطلاحا آب از دهن خواننده سرازیر می کند یا به عبارت رسمی تر خواننده را به سمتی هدایت می کند تا سریعا چابک شود. من به اینگونه چابک سازی ها ,  چابک سازی بی فکر می گویم.

اما مشکل چابک سازی بی فکر چیست ؟

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

بنابر وظیفه تاریخی خودم (من از 200 سال بعد اومدم 🙂 لازم دانستم در این پست اشاره ای بر بعضی از مسائل شاید نهان استفاده و یا عدم استفاده از متد ملت پسند Agile نمایم.

آیا Agile در هر سازمانی و یا در هر پروژه ای جوابگو می باشد؟

مسلما نه !

در چه نوع  Agile ایزه شدن احتمالا با مشکل مواجه خواهیم شد؟

  • چابک سازی های بدون فکر.
  • سطح فنی نفرات پیاده (نیروی کار) پایین باشد.

همان بحث معروف Technical  Excellence که در پست هایی به صورت مفصل شرح داده شده است.

  • پروژه های با قراردادهای بسته.

قرارداد بسته از نظر قیود هزینه و زمان .

  • عدم چابک سازی جامع و سازمانی.

https://sirasad.files.wordpress.com/2011/03/kicking_out.jpg?w=425برای مثال در بعضی از سازمان ها تیم توسعه چابک شده است ولی تیم رهبری و یا رده های بالا میلی به چابک شدن یا به قولی جنگولک بازی ها ندارند. چنین چابک سازی های غیر جامعی پایدار نخواهند بود.

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

و چندین مورد دیگر که می تواند مانع چابک سازی کامل و درست سازمان باشد. مهمترین مورد در این جا این است که چابک سازی باید اولا بر اساس دانش و آگاهی باشد دوما چابک سازی نباید یکباره و یکدفعه ای باشد و بالعکس باید به صورت inspect and adapt اجرا شود.

من به عنوان یک مربی Agile زمانی که درخواستی از سازمانی در باب چابک سازی سازمان دریافت می کنم ,  نخستین کار ارزیابی سازمان می باشد به طوری که با بررسی وضع سازمان و یا پرسش و پاسخ می خواهم به سوال «چرا باید این سازمان چابک شود؟ » جواب دهم یا به عبارت ساده تر مشکل این سازمان چیست که می خواهد  چابک شود؟ (اگر همه چیز در جای خود باشد و کامل و درست ,  چه نیازی است که سازمان چابک شود؟) . پس در اولین کار بدنبال کاستی ها می گردیم :

1- سرعت توسعه محصول کند است

2- محصول نهایی پر از باگ است

3- بهره وری نیروی انسانی پایین است

4- مشتری ناراضی است

و …

پس از اینکه ملاحظه کردیم که بلی سازمان دچار کاستی هایی می باشد و یا اصلا دچار کاستی نیست بلکه نیازمند بهبود بخشی هایی (مانند تسریع پروسه ارائه محصول) می باشد شروع به امکان سنجی Agile می کنیم که آیا شلوار Agile در قواره این سازمان با این وضع و با این درخواست ها می باشد؟ این سنجش را هم مانند قسمت اول که بیان شد انجام می دهیم : مثلا آیا برنامه نویس ها توانایی بحث Technical Excellence  را دارا می باشند؟ یا آیا مدیریت مایل به تغییر روند مدیریت به بحث خود سازماندهی می باشد و یا … .

نهایتا با توجه به کمبود ها و نیازهای سازمان جهت دست یابی به قله های رفیع موفقیت برنامه ریزی با عنوان برنامه چابک سازی انجام می دهیم که این برنامه با توجه به روند inspect and adapt بودنش متغییر می باشد. معمولا در این برنامه شاهد وجود برنامه های آموزشی – نظارتی – مشاوره ای و … خواهیم بود.

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

یاشیاسیز

Advertisements
دسته‌ها:Agile, Project Management, Scrum

مدیریت نسل سوم

فوریه 3, 2011 ۱ دیدگاه

برادر گرامی Jurgen Appelo به تازگی اقدام به نگارش و انتشار کتاب خوبی در زمینه مدیریت چابک با نام Management 3.0 کرده اند. این کتاب که به تازگی و از اوایل سال میلادی جدید در دسترس همگان قرار گرفته است که با استقبال خوبی از طرف مدیران و علاقمندان به مبحث Agile مواجه شده است.

در این کتاب بحث شیرین مدیریت به 3 نسل اولیه و اولیه تکمیل شده و مدیریت قرن 21 یا همان 3.0 تقسیم شده است که همان مدیریت Agile گذری از مراحل 1 و 2 به دوران مدیریت جدید می باشد.

همانطور که ذکر شد ورود به دنیای مدیریت Agile نیازمند گذر از دو مرحله پیشین مدیریت می باشد که در این کتاب به  خوبی این مهم شرح داده شده است. علاوه بر این به خوبی نیازهای یک سازمان به مدیریت چابک و نحوه تحول سازمان به این نوع مدیریت نوین نیز کاملا با بیانی کمی تا حدودی سخت شرح داده شده است.

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

ولی باز با این حال کتاب ,  کتاب بسیار خوب و عالی و کم نظیری می باشد که برای مدیران چابک و یا کسانی که می خواهند از تحول سازمانی چابک بهره مند شوند بسیار توصیه می شود.

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

  • Getting beyond “Management 1.0” control and “Management 2.0” fads
  • Understanding how complexity affects your organization
  • Keeping your people active, creative, innovative, and motivated
  • Giving teams the care and authority they need to grow on their own
  • Defining boundaries so teams can succeed in alignment with business goals
  • Sowing the seeds for a culture of software craftsmanship
  • Crafting an organizational network that promotes success
  • Implementing continuous improvement that actually works

یاشیاسیز

آیا شلوار Agile هنوز برای سازمان های ایرانی گشاد است؟

دسامبر 31, 2010 4 دیدگاه

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

https://sirasad.files.wordpress.com/2010/12/happyman.jpg?w=274به طور خلاصه نرم افزار کارآ به محصولی اطلاق می شود که نیازهای جاری مشتری را رفع نماید و قابل گسترش برای پوشش نیازهای بعدی او نیز باشد. اما آیا واقعا در ایران هدف صنعت نرم افزار برآورد کردن نیازهای مشتری است! آیا خروجی های ما در طی این مدت (مثلا 10 سال گذشته) کارآ بوده اند؟

بزرگترین مانع در دست یابی به یک محصول کارآ به نظر من قراردهای بسته می باشد. قراردادهایی وابسته به یک نیاز سنجی اولیه و تخمین زمانی اغلب نادرست. مثلا Aو B را باید در 1 ماه انجام بدهید. انجام A و B در یک ماه حالا با یک تلرانس 1 هفته ای طی یک پروژه , عرضه کننده محصول کارآ نخواهد بود زیرا ما مکلف به تکمیل درخواست ها هستیم و نه ارائه محصول کارآ.  همین دید باعث می شود اگر زمانی نیاز باشد B به C تبدیل شود شاهد اختلافات بزرگی باشیم.

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

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

اما بحث قرارداد بیشتر یک بحث فرهنگی می باشد تا یک بحث فنی. همیشه در قرارداد باید حداقل دو طرف وجود داشته باشند : 1- مشتری 2-مجری قرارداد. هر دو طرف این قرارداد باید به یک سطح فرهنگی و شعوری برسند که من مشتری برای رسیدن به خروجی کارآ باید هزینه کنم و من مجری باید خروجی کارآ ارائه نمایم و اسم این سطح شعوری را می توان چابکی نامید.مشتری چابک و مجری چابک خواهند توانست آغاز گر یک پروژه با خروجی کارآ باشند.

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

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

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

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

چابک شوید و چابک بمانید.

یاشیاسیز

خروجی کارآ در Agile

دسامبر 13, 2010 8 دیدگاه

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

حال سوالی مهمی که قابل طرح است این می باشد که : در محیط های Agile یا چابک چگونه می توان به نرم افزار کارآ دست یافت؟ و پروسه های قدیمی چگونه بودند که نمی توانستد به این مهم دست یابند؟

شکل های زیر جوابگوی این سوالات خواهند بود :

https://sirasad.files.wordpress.com/2010/12/dsc00003.jpg?w=592

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

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

اما در محیط Agile برای این که بتوانیم همان محصول را به گونه کارآ توسعه دهیم می توانیم به گونه زیر عمل نماییم:

https://sirasad.files.wordpress.com/2010/12/dsc00004.jpg?w=592

همانطور که کاملا واضح است پروژه با Vision محصول A شروع می شود ولی در انتها مشتری صاحب محصول B است زیرا تیم توسعه و مشتری طی تعاملات دائمی در طول Iteration ها دائما در حال یادگیری هستند (یادگیری اینکه Business Value در چه سمتی و با چه محصولی به حداکثر خود خواهد رسید؟). اگر در شکل دقت نمایید متوجه می شوید  طی Iteration  ها به جای اینکه به جلو برویم (به طرف A ) کم کم به طرف B متمایل می شویم (محصول کارآ) . حتی در Iteration های آخر شاهد یک ثبات حرکتی هستیم که فقط و بدون تغییر جهت به سمت هدف حرکت می کنیم(بالاترین حد یادگیری).

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

البته با مقایسه اشکال بالا به نکات موثرتری پی خواهید برد.

یاشیاسیز

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

نوامبر 17, 2010 15 دیدگاه

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

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

ISDA یا Iran Software Development Alliance یا تشکل صنعت توسعه نرم افزار ایران

مشکلاتی که در ISDA قابل حل خواهند بود :

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

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

خلاصه ای از سامانه ISDA در شکل زیر :

https://sirasad.files.wordpress.com/2010/11/isda_overview.jpg?w=592

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

شرح پیشنهاد :

هدف : ایجاد سامانه تشکل صنعت توسعه نرم افزار ایران(ISDA System) جهت ایجاد حلقه اتصال مابین صنایع توسعه نرم افزار , نیروی متخصص و مشتری محصولات نرم افزاری

Elevator Statement

  1. این سامانه برای صنایع توسعه نرم افزار ایران می باشد برای اینکه آنها بتوانند :
     

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

وجه تمایز این سامانه با سیستم های مشابه

  • این یک سیستم کاریابی و یا تبلیغات صرف نخواهد بود.
  • سامانه توسط یک تشکل غیر انتفاعی و Non-Profit اداره خواهد شد.
  • سامانه بدنبال ایجاد و یا کسب درآمد نیست.
  • تمام خدمات سامانه رایگان و قابل دسترس همه خواهد بود.
  • اولویت اصلی سامانه ایجاد حلقه های منطقه ای و سپس حلقه فرا منطقه ای می باشد.
  • سامانه یک سامانه عمومی با مالیکت عمومی خواهد بود.

این سامانه یک برنامه تحت وب خواهد بود که همه باید بتوانند به راحتی نیازهای خود را برطرف نمایند (به صورتی که قبلا این امکان میسر نبود).

آفت این سامانه

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

نقش تشکل در سامانه

تشکل ISDA در واقع راهبر و تصمیم گیرنده سامانه ISDA خواهد بود. اما در زیر می توان به تعدادی از نقش های کلیدی این تشکل اشاره کرد :

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

مافیا و سامانه

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

مالک سامانه کیست؟

  • مالک سامانه تشکل ISDA خواهد بود .

اعضای ISDA چه کسانی خواهند بود؟

  • اعضای این تشکل جمعی از توسعه دهندگان سامانه  بعلاوه تعدادی از متخصصین و صاحبین صنایع توسعه نرم افزار خواهند بود که اعضا به صورت دوره ای تعویض خواهند شد (مانند اصناف).

تشکل ISDA چگونه تشکیل خواهد شد؟

  • این تشکل در حین و بعد از ایجاد سامانه به صورت رسمی تشکیل خواهد شد.

ایجاد سامانه چگونه انجام خواهد شد؟

  • این سامانه توسط تعدادی از متخصصین توسعه نرم افزار به صورت داوطلبانه شروع و ایجاد خواهد شد. اما جزئیات فنی پروژه بعد از تشکیل تیم توسعه سامانه اعلام خواهد شد.

بستر و تکنولوژی سامانه

  • سامانه یک برنامه تحت وب خواهد بود که این سامانه با یکی از زبان های ASP.net و یا PHP پیاده سازی خواهد شد که انتخاب آن با تیم توسعه خواهد بود.

چه کسانی می توانند برای پیاده سازی این پروژه داوطلب شوند ؟

  • روحیه کار تیمی و کارهای عام المنفعه داشته باشند.
  • در یکی از مقوله های Asp.net و یا PHP و یا تخصص های مورد نیاز مانند طراحی رابط کاربری و یا امثالهم متبحر باشند.
  • این یک پروژه آموزشی نیست پس از پذیرش افراد مبتدی و … معذور خواهیم بود.
  • صاحب نظران عزیز

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

یاشیاسیز

Agile Pack

نوامبر 14, 2010 دیدگاه‌ها غیرفعال

جهت گسترش و آموزش هر چه بیشتر متد Agile و Scrum در ایران اقدام به ایجاد یک بسته آموزشی با عنوان Agile Pack کردیم که امیدواریم باعث رشد سطح چابکی و دانش متخصصین و سازمان ها توسعه نرم افزاز شود .

https://sirasad.files.wordpress.com/2010/11/agilepack.gif

محتوای داخل این بسته آموزشی

قیمت پکیج

29 هزار تومان

مخاطبین اثر

  • مدیران پروژه های نرم افزاری و صنایع مربوطه
  • مدیران شرکت های توسعه نرم افزار
  • توسعه گران نرم افزار
  • مدیران اسکرام

پیش نیاز

  • آشنایی با مفاهیم توسعه نرم افزار

نحوه تهیه این پکیج

با ایمیل asad.safari[at]gmail[dot]com تماس بگیرید {عنوان ایمیل Agile Pack انتخاب کنید}

یاشیاسیز

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

اکتبر 30, 2010 3 دیدگاه

جان وودن(John Wooden)  ملقب به مربی وودن (Coach Wooden)  یک بازیکن و مربی بسکتبال در سال های گذشته آمریکا بوده است. به عقیده  بسیاری از بسکتبالیست ها او بهترین مربی بسکتبال در طول تاریخ می باشد. البته نه به این خاطر که او خوب بسکتبال می دانست بلکه او یک رهبر و مربی به معنای واقعی کلمه بوده است. توانایی تیم سازی او زبان زد خاص و عام بود . بسیاری از بازیکنان مطرح لیگ NBA فقط به خاطر نام مربی وودن به تیم دبیرستانی او می آمدند. علت اینکه این مربی بسکتبال در دنیای خارج ازورزش نیز شناخته می شود به خاطر قدرت رهبری وی می باشد.

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

https://sirasad.files.wordpress.com/2010/10/pyramid_lg.jpg?w=592

شکل بالا شامل 3 جز اصلی می باشد. 1- تعریف دقیق از موفقیت 2-هرم موفقیت 3- 12 درس رهبری

اگر به کتابخانه های محل زندگی خودتان مراجعه کنید , شاهد این خواهید بود که صد ها و شاید هزاران کتاب با عناوینی مانند»چگونه در 2 ثانیه موفق شویم»  یا «چگونه 1 روزه میلیونر شویم» یا «همه را تحث نفوذ خود قرار دهید» و یا … بر روی قفسه ها موجود می باشند . شاید به طور فیزیکی هزاران کتاب از صد ها نویسنده موجود باشد ولی ذاتا همه آنها یکی هستند. به صراحت می توانم عرض کنم که : عکس بالا چکیده این هزاران کتاب می باشد. یعنی اگر ما بدنبال دست یابی به مفهوم موفقیت هستیم این یک شکل ما را کفایت می کند. به قول استاد گرامی آقای قمشه ای , انسان در عمر خود چند کتاب مفید را بخواند برای تمام عمر او کافی خواهد بود. https://sirasad.files.wordpress.com/2010/10/515r62yff7l-_sl500_aa300_.jpg?w=300این عکس از آنهایی است که باید طلا گرفته شود و به جای بعضی چیزها بر روی دیوار ها نصب شود.

اما اگر در درک شکل بالا با مشکل مواجه شدید , می توانم کتاب Coach Wooden’s Leadership Game Plan for Success را معرفی کنم.یک کتاب با حجم کم و متن انگلیسی روان و سرتاسر شکل و داستان و نکته.

در واقع این کتاب (به کوشش فکر کنم نیویرک تایمز) به صورت چیکده به یک شکل بصری گویا تبدیل شده است. هر چقدر که در این کتاب به جلو میروید شکل و هرم را بهتر متوجه خواهید شد.

مربی وودن علاوه بر این کتاب , کتاب های دیگری نیز دارد که خواندن آنها هم خالی از لطف نیست. البته این کتاب وی از طرف استفان کاوی (نویسنده کتاب معروف هفت عادت مردمان موثر) مورد تایید قرار گرفته است.

مربی وودن بعد از اخذ جایزه های متعدد در تیم های متعدد بسکتبال در سن 99 سالگی دار فانی را ودا گفت . روحش شاد.

یاشیاسیز