اسکرام روشی برای شکست در حداکثر 30 روز یا کمتر

[Arash Milani]

سلام دوستان چابک من،

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

برای گوش دادن به پادکست به این برگه برید.

منتظر نظرات شما هستم دوستان :)

با سپاس،
آرش میلانی
ساماندهی اطلاعات نارمند | narmand.com

[Darioush Jalali]

سلام،

به نظر من، مقدمه‌ی خوبی بود و کلاً استفاده از این نوع اطلاع رسانی رو مفید می‌دونم. لذا، نکاتی که بیان می‌کنم، حاکی از دید منفی من نسبت به کلیت حرکت نیست؛

1. به نظر من، تا زمانی که سرعت (velocity) تیم محاسبه نشده باشه، سکرام تحقق نیافته است، و حتماً اشاره به این موضوع در معرفی سکرام لازمه از دید من. ضمناً به نظرم بهتره که در مورد شیوه‌ی تخمین اندازه‌ی هر واحد کاری صحبت می‌شد.

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

3. به نظرم، زمان جلسات رو بالا گفتی، 15 دقیقه واقعاً برای 3 نفر لازمه؟ 4 ساعت برنامه‌ ریزی اولیه؟ 2 ساعت نمایش محصول؟ 1.5 ساعت جلسه انتهیی؟ خودش می‌شه 10 ساعت، که با 10 روز کاری در 2 هفته، می‌شه بیشتر از 10% وقت همه‌ی اعضای تیم ایجاد. اگه بنا بود بیاییم انقدر جلسه بذاریم، اونم برای هماهنگی مثلاً 3 نفر، آیا واقعاً چابکی داره کمک می‌کنه؟ فکر می‌کنم اعدادی که شما گفتید بیشتر نزدیک به تیم ایجاد حدود 7 نفره هست.

4. به نظرم نشون دادن محصول به مشتری کافی نیست و برای تحقق چابکی، باید محصول در محیط اجرایی کاربر بشینه و به طور روزمره باهاش سر و کله زده بشه.

5. به نظرم استفاده از کلمه‌ی توسعه برای development خیلی بی‌معنی هست و این عبارت انگاری که از روی عبارت developing countries ترجمه شده. اما کار نرم‌افزار بیش‌تر کار «ایجاد» هست، لذا کلمه‌های تیم ایجاد، برنامه‌ساز و برنامه‌نویس رو به کلمه‌ای مثل توسعه دهندگان ترجیح می‌دم.

6. خیلی بهتره اگه پادکست این همه توش انگلیسی نباشه، استاد سکرام، صاحب کار (صاحب محصول)، پشته‌ی کاری، تکرار (iteration یا sprint)، جلسه‌ی برنامه‌ریزی، جلسه‌ی بازبینی خیلی کلماتی هستند که ساده به ذهن می‌رسند و مطمئنم اگر کسی روشون فکر کنه، کلمات بهتری هم تولید می‌شن.

دسته‌ی دیگر مشکلات هم که به وضعیت چابکی در ایران بر می‌گرده:

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

8. گفته شد که مشتری در دسترس باشه تا هر وقت ما خواستیم با اون تماس بگیریم و هر نیم ساعت یه بار و ... اما شرایط فعلی بازار نرم‌افزار ایران به گونه‌ای نیست که مشتری بخواهد وقت خودش (که معمولاً مدیر یه سازمان هست) یا کارمنداش رو به این شکل در اختیار شما بذاره. اگر چابکی بخواهد در ایران رشدی داشته باشه، باید بر این دو مشکل فائق بیاد.

و یک مورد هم کلاً مشکل سکرام و روش‌های چابک:

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

والسلام!

2012/1/17 Arash Milani <arash...@gmail.com>

[M.Jalilnejad]

به نام خدا

سلام داریوش عزیز،

شما نوشته بودید : 

به نظرم، زمان جلسات رو بالا گفتی، 15 دقیقه واقعاً برای 3 نفر لازمه؟ 4 ساعت برنامه‌ ریزی اولیه؟ 2 ساعت نمایش محصول؟

به نظر من هم، زمان زیادیه برای یه تیم 3 نفره. البته تو چند تکرار اولی طبیعیه. بعد از چند تکرار درست می‌شه. در این مورد 2 تا لینک دارم که دوستان می‌تونن مطالعه کنن.

• یکی مربوط به یه تاپیک تو گروه ScrumDevelopment هست . کل تاپیک رو پیگیری کنید تا ببینید پاسخ دهندگان در مورد زمان جلسات چی گفته‌اند
• و این یکی مربوط به یه پست تو وبلاگ Charles Bradley در مورد تجربه‌ی خودش در جلسات برنامه‌ریزی تو یه تیمه

موفق باشید،
M.Jalilnejad

[Hamidreza Motaghian]

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

موفق باشید

On 1/18/12, M.Jalilnejad <m.jali...@gmail.com> wrote:
> به نام خدا
> سلام داریوش عزیز،
> شما نوشته بودید :
>
>> به نظرم، زمان جلسات رو بالا گفتی، 15 دقیقه واقعاً برای 3 نفر لازمه؟ 4 ساعت
>> برنامه‌ ریزی اولیه؟ 2 ساعت نمایش محصول؟
>
> به نظر من هم، زمان زیادیه برای یه تیم 3 نفره. البته تو چند تکرار اولی
> طبیعیه. بعد از چند تکرار درست می‌شه. در این مورد 2 تا لینک دارم که دوستان
> می‌تونن مطالعه کنن.
>

> - یکی مربوط به یه تاپیک تو گروه <goog_2022045043> <goog_2022045043>
>
> ScrumDevelopment<http://tech.groups.yahoo.com/group/scrumdevelopment/message/50532>هست

> . کل تاپیک رو پیگیری کنید تا ببینید پاسخ دهندگان در مورد زمان جلسات چی
> گفته‌اند

> - و این یکی مربوط به یه پست تو وبلاگ Charles
> Bradley<http://scrumcrazy.wordpress.com/2011/05/05/sprint-tasking-tip-dont-give-up/>

> در
> مورد تجربه‌ی خودش در جلسات برنامه‌ریزی تو یه تیمه
>
>
> موفق باشید،
> M.Jalilnejad
>

--
*Regards,
H.R.Motaghian
CSM | MCP *
* My Personal Website <http://hamidreza.info>*

[M.Jalilnejad]

به نام خدا

سلام،

برای آنکه زودتر به شکست در روش چابک نائل شوید توصیه می‌کنم کتاب How To Fail With Agile: Twenty Tips to Help You Avoid Success را مطالعه کنید.

در این کتاب 20 نکته‌ی طلایی ارائه شده که اگر آنها رو دقیق و درست اجرا کنید به صورت تضمینی ، 100٪ ، به شکست دست پیدا خواهید کرد

موفق باشید، (نه در دستیابی به شکست)
M.Jalilnejad

[Arash Milani]

در پاسخ به داریوش جلالی عزیز،

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

1- در این مورد که گفتین تا موقعی که سرعت تیم محاسبه نشده باشه اسکرام تحقق نیافته، به نظر من و حتی کن شوییبر تعیین سرعت تیم جزو تعریف اسکرام نیست. تجربه من نشون می ده که معمولا عددی که به عنوان سرعت تیم 

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

2- در مورد "شیوه تخمین زمانی هر واحد کاری" هم که اشاره کردید، دقیقا در پادکست اشاره شده بود که چه چبزی برای تیم ما بهترین راه حل بوده. روش های مختلفی مثل پلانینگ پوکر و ... وجود داره که باز هم با اعداد بی مفهوم سر و کار دارند. به جای این کار به حس ششم تیم و احساس اونها نسبت به این سوال احترام بزارید. "چه تعداد از این آیتم ها رو می تونید در عرض اسپیرینت بعدی انجام دهید؟" تجربه ی من میگه که همین سوال کافی است.

3- در مورد زیاد بودن زمان گردهمایی ها یا به قولی *جلسات* . اول اینکه سعی من این بود که این اعداد با راهنمای اسکرام که توسط کن شوییبر و جف سادرلند تدوین شده هست اش هماهنگ باشه تا ابهامی برای خواننده پیش نیاد. در 

ضمن در اغلب موارد این مقدار زمان بله نیاز هستش. حتا گاهی ممکن هستش که زمان کم بیارید. البته اگه شما زمان زیاد آوردید لازم نیست منتظر بمونید تا زمان گرد هم آیی ها تموم بشه برید سراغ کار بعدی. من در پادکست *ماکزیمم* زمان ها رو اشاره کردم. 

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

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

6- فکر نکنم کسی بخواد که در پروژه هاشون از ترجمه هایی که ما اینجا ازشون استفاده کردیم استفاده کنه. این مثل این هست اش که بخوایم خود واژه ی اسکرام رو ترجمه کنیم. داشتن واژه نامه یکسان در یه تیم بسیار مهم هست اش. در تمام دنیا این واژه ها استفاده میشه و من با ترجمه این واژه ها به دلیل ایجاد ابهام و کاهش شفافیت بین اعضای تیم مشکل دارم.

7- مشکل "قراردادها" بله مشکلی هست اش که وجود داره ولی دلیل ای برای توقف استفاده از روش های اجایل نمی شه. در مورد قرارداد ها یه پست یا پادکست رو قرار هست اش در آینده داشته باشم که بخث اش رو اونجا انجام بدیم.

8- در مورد همکاری مشتری هم باید بگم که این هنر یه تیم اسکرام هست اش که بتونه همکاری مشتری رو با خودش بیشتر کنه. ما مشتری های دولتی هم داشتیم و داریم و تا حدودی بر این مشکل فایق اومدیم. مشتری اگه می خواد 

محصول درستی تحویل بگیره باید همکاری نزدیکی داشته باشه این یکی از اصول اجایل هست اش. و این وضیفه ماست که اون رو در این مورد آگاه کنیم. می دونم کار ساده ای نیست ولی شدنی هست اش.

9- شاید تو یه تیم توسعه نیاز باشه که "خبره‌ترین برنامه نویس تیم بشینه سعی کنه از اصول ترکیب بندی رنگ‌ها سر در بیاره". شاید یه روز از اون خواسته بشه که در نبود طراح تیم یه طراحی کوچیک انجام بده. این بدین معنا نیست که نباید 

کارها تخصصی باشه. باید باشن. ولی نباید کارهای تبم متکی به *یک* نفر باشه. حتی اگه کیفیت انجام کار مقداری هم کاهش پبدا کنه باید کار انجام بشه. همیشه فرصت هست برای بهتر کردن کیفیت یه طرح گرافیکی. حتی یه مورد بالاتر ممکن هست اش که برنامه نویس ارشد تیم کاری نداشته باشه و بخواد به تستر ها کمک کنه. شاید حتی کمک اش در حد آوردن یه استکان چایی برا تستر باشه :)

شاد باشین،

آرش میلانی

نارمند | narmand.com

2012/1/18 Darioush Jalali <darious...@gmail.com>

[Arash Milani]

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

شاد باشین،

آرش میلانی

نارمند | narmand.com

2012/1/18 Hamidreza Motaghian <m.ham...@gmail.com>

[asad....@gmail.com]

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

Asad safari

[Arash Milani]

به نظر *من* اینکه روشی در *عمل* و همینطور *تعریف* بسیار پیچیده باشه خودش باعث رو آوردن اون به شکست میشه. حتی در مورد اسکرام هم همینطور هست. با اینکه تعریف ساده ای داره ولی انجامش فوق العاده سخت هست اش.

با سپاس،
آرش میلانی
ساماندهی اطلاعات نارمند | narmand.com

2012/1/22 asad....@gmail.com <asad....@gmail.com>

[Darioush Jalali]

سلام،

2012/1/22 Arash Milani <arash...@gmail.com>

در پاسخ به داریوش جلالی عزیز،

داریوش جان یه نکته که تو پست های قبلی تون در انجمن دیدم این بود که اصرار دارین که به جای لفظ "اسکرام" از "سکرام" استفاده کنید، که دلیلش رو نتونستم حدس 

بزنم و خوشخال می شم برامون توضیح بدی. 

اصراری که نیست! اما scrum واژه‌ی انگلیسی هست و درسته که به طور رایج اول چنین کلمات کسره باشه، اما خوب این کسره اصولاً وجود نداره. (خصوصاً که نصف حرف‌هامون به هر حال انگلیسی هست و با تلفظ انگلیسی هم بیان می‌کنیم)

1- در این مورد که گفتین تا موقعی که سرعت تیم محاسبه نشده باشه اسکرام تحقق نیافته، به نظر من و حتی کن شوییبر تعیین سرعت تیم جزو تعریف اسکرام نیست. تجربه من نشون می ده که معمولا عددی که به عنوان سرعت تیم 

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

2- در مورد "شیوه تخمین زمانی هر واحد کاری" هم که اشاره کردید، دقیقا در پادکست اشاره شده بود که چه چبزی برای تیم ما بهترین راه حل بوده. روش های مختلفی مثل پلانینگ پوکر و ... وجود داره که باز هم با اعداد بی مفهوم سر و کار دارند. به جای این کار به حس ششم تیم و احساس اونها نسبت به این سوال احترام بزارید. "چه تعداد از این آیتم ها رو می تونید در عرض اسپیرینت بعدی انجام دهید؟" تجربه ی من میگه که همین سوال کافی است.

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

تا جایی هم که اطلاع دارم و در جاهایی مثل http://www.scrumalliance.org/pages/scrum_101 دیده می‌شه، نمودار پیشرفت کار یکی از 3 دستاورد بنیادی سکرام حساب می‌شه. البته این اصل که بدونیم چقدر از کار رو در چه واحد زمانی انجام می‌دیم، در تمام متدولوژی‌های چابک دیده می‌شه و یکی از اختلاف‌های روش‌های چابک با بی‌نظمی مطلق هست و من نمی‌دونم که شما چطوری این رو لازم نمی‌دونید.

3- در مورد زیاد بودن زمان گردهمایی ها یا به قولی *جلسات* . اول اینکه سعی من این بود که این اعداد با راهنمای اسکرام که توسط کن شوییبر و جف سادرلند تدوین شده هست اش هماهنگ باشه تا ابهامی برای خواننده پیش نیاد. در 

ضمن در اغلب موارد این مقدار زمان بله نیاز هستش. حتا گاهی ممکن هستش که زمان کم بیارید. البته اگه شما زمان زیاد آوردید لازم نیست منتظر بمونید تا زمان گرد هم آیی ها تموم بشه برید سراغ کار بعدی. من در پادکست *ماکزیمم* زمان ها رو اشاره کردم. 

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

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

این صحبت یه جورایی بی ربطه چون واژه‌ی developer معمولاً تنها به coder یا tester اطلاق می‌شه و من تاحالا ندیدم کسی به گرافیست یا مهندس برق بگه developer. 

6- فکر نکنم کسی بخواد که در پروژه هاشون از ترجمه هایی که ما اینجا ازشون استفاده کردیم استفاده کنه. این مثل این هست اش که بخوایم خود واژه ی اسکرام رو ترجمه کنیم. داشتن واژه نامه یکسان در یه تیم بسیار مهم هست اش. در تمام دنیا این واژه ها استفاده میشه و من با ترجمه این واژه ها به دلیل ایجاد ابهام و کاهش شفافیت بین اعضای تیم مشکل دارم.

7- مشکل "قراردادها" بله مشکلی هست اش که وجود داره ولی دلیل ای برای توقف استفاده از روش های اجایل نمی شه. در مورد قرارداد ها یه پست یا پادکست رو قرار هست اش در آینده داشته باشم که بخث اش رو اونجا انجام بدیم.

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

 

8- در مورد همکاری مشتری هم باید بگم که این هنر یه تیم اسکرام هست اش که بتونه همکاری مشتری رو با خودش بیشتر کنه. ما مشتری های دولتی هم داشتیم و داریم و تا حدودی بر این مشکل فایق اومدیم. مشتری اگه می خواد  

محصول درستی تحویل بگیره باید همکاری نزدیکی داشته باشه این یکی از اصول اجایل هست اش. و این وضیفه ماست که اون رو در این مورد آگاه کنیم. می دونم کار ساده ای نیست ولی شدنی هست اش.

اوه بله؛ گفتن این موضوع خیلی ساده‌اس و من منکر این نیستم که شما به طور موردی تونستید مشکل بالا یا قرارداد رو حل کنید. منظور من اشاره به مشکل فرهنگی هست که غالبه و 

1. باید موقع معرفی روش‌های چابک منصف بود و گفت ممکنه به چنین مشکلاتی بخورید

2. راهکارهایی بهتر از «هنرمندی» تیم برای این موضوع ارائه بشه. 

9- شاید تو یه تیم توسعه نیاز باشه که "خبره‌ترین برنامه نویس تیم بشینه سعی کنه از اصول ترکیب بندی رنگ‌ها سر در بیاره". شاید یه روز از اون خواسته بشه که در نبود طراح تیم یه طراحی کوچیک انجام بده. این بدین معنا نیست که نباید 

کارها تخصصی باشه. باید باشن. ولی نباید کارهای تبم متکی به *یک* نفر باشه. حتی اگه کیفیت انجام کار مقداری هم کاهش پبدا کنه باید کار انجام بشه. همیشه فرصت هست برای بهتر کردن کیفیت یه طرح گرافیکی. حتی یه مورد بالاتر ممکن هست اش که برنامه نویس ارشد تیم کاری نداشته باشه و بخواد به تستر ها کمک کنه. شاید حتی کمک اش در حد آوردن یه استکان چایی برا تستر باشه :)

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

نکته‌ی کلی اینه که روش‌های چابک (خصوصاً سکرام) محدودیت‌های بسیار بسیار زیاد دارند و تنها در داخل چهارچوبی که جواب می‌دن جواب می‌دن،

اما تبلیغاتی که برای این روش‌ها صورت می‌گیره چیزیه در حد مافوق طییعی. 

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

از صدها ابزار که در اختیار مهندسین نرم‌افزار قرار داره و هر ابزار هم حوزه‌ی کاربردی خودش رو داره و استفاده نابجا از ابزار منجر به خسارت می‌شه.

[Arash Milani]

2012/1/23 Darioush Jalali <darious...@gmail.com>

سلام،

2012/1/22 Arash Milani <arash...@gmail.com>

در پاسخ به داریوش جلالی عزیز،

داریوش جان یه نکته که تو پست های قبلی تون در انجمن دیدم این بود که اصرار دارین که به جای لفظ "اسکرام" از "سکرام" استفاده کنید، که دلیلش رو نتونستم حدس 

بزنم و خوشخال می شم برامون توضیح بدی. 

اصراری که نیست! اما scrum واژه‌ی انگلیسی هست و درسته که به طور رایج اول چنین کلمات کسره باشه، اما خوب این کسره اصولاً وجود نداره. (خصوصاً که نصف حرف‌هامون به هر حال انگلیسی هست و با تلفظ انگلیسی هم بیان می‌کنیم)

همونطور که گفتین اول این کلمه به هیچ وجه  "کسره" نیست و "اس" هست اش. /skrʌm/

1- در این مورد که گفتین تا موقعی که سرعت تیم محاسبه نشده باشه اسکرام تحقق نیافته، به نظر من و حتی کن شوییبر تعیین سرعت تیم جزو تعریف اسکرام نیست. تجربه من نشون می ده که معمولا عددی که به عنوان سرعت تیم 

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

2- در مورد "شیوه تخمین زمانی هر واحد کاری" هم که اشاره کردید، دقیقا در پادکست اشاره شده بود که چه چبزی برای تیم ما بهترین راه حل بوده. روش های مختلفی مثل پلانینگ پوکر و ... وجود داره که باز هم با اعداد بی مفهوم سر و کار دارند. به جای این کار به حس ششم تیم و احساس اونها نسبت به این سوال احترام بزارید. "چه تعداد از این آیتم ها رو می تونید در عرض اسپیرینت بعدی انجام دهید؟" تجربه ی من میگه که همین سوال کافی است.

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

تا جایی هم که اطلاع دارم و در جاهایی مثل http://www.scrumalliance.org/pages/scrum_101 دیده می‌شه، نمودار پیشرفت کار یکی از 3 دستاورد بنیادی سکرام حساب می‌شه. البته این اصل که بدونیم چقدر از کار رو در چه واحد زمانی انجام می‌دیم، در تمام متدولوژی‌های چابک دیده می‌شه و یکی از اختلاف‌های روش‌های چابک با بی‌نظمی مطلق هست و من نمی‌دونم که شما چطوری این رو لازم نمی‌دونید.

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

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

در ضمن در اسکرام برای ما مهم نیست چه مقدار کار انجام شده، بلکه آنچه که مهم هست اش (و نمودار هایی که اشاره کردید به اونها به ما نشون می دن) مقدار کار *باقی مانده* هست اش.

 

3- در مورد زیاد بودن زمان گردهمایی ها یا به قولی *جلسات* . اول اینکه سعی من این بود که این اعداد با راهنمای اسکرام که توسط کن شوییبر و جف سادرلند تدوین شده هست اش هماهنگ باشه تا ابهامی برای خواننده پیش نیاد. در 

ضمن در اغلب موارد این مقدار زمان بله نیاز هستش. حتا گاهی ممکن هستش که زمان کم بیارید. البته اگه شما زمان زیاد آوردید لازم نیست منتظر بمونید تا زمان گرد هم آیی ها تموم بشه برید سراغ کار بعدی. من در پادکست *ماکزیمم* زمان ها رو اشاره کردم. 

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

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

این صحبت یه جورایی بی ربطه چون واژه‌ی developer معمولاً تنها به coder یا tester اطلاق می‌شه و من تاحالا ندیدم کسی به گرافیست یا مهندس برق بگه developer. 

6- فکر نکنم کسی بخواد که در پروژه هاشون از ترجمه هایی که ما اینجا ازشون استفاده کردیم استفاده کنه. این مثل این هست اش که بخوایم خود واژه ی اسکرام رو ترجمه کنیم. داشتن واژه نامه یکسان در یه تیم بسیار مهم هست اش. در تمام دنیا این واژه ها استفاده میشه و من با ترجمه این واژه ها به دلیل ایجاد ابهام و کاهش شفافیت بین اعضای تیم مشکل دارم.

7- مشکل "قراردادها" بله مشکلی هست اش که وجود داره ولی دلیل ای برای توقف استفاده از روش های اجایل نمی شه. در مورد قرارداد ها یه پست یا پادکست رو قرار هست اش در آینده داشته باشم که بخث اش رو اونجا انجام بدیم.

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

نه در اینجا منظور من این هست اش که قراردی به روش قدیمی بسته شده و پروژه ای وجود داره. اگه فرارداد اجایل نیست دلیل نمیشه که ما سعی نکنیم که توسعه پروژه رو با تفکر اجایل جلو نریم.

 

 

8- در مورد همکاری مشتری هم باید بگم که این هنر یه تیم اسکرام هست اش که بتونه همکاری مشتری رو با خودش بیشتر کنه. ما مشتری های دولتی هم داشتیم و داریم و تا حدودی بر این مشکل فایق اومدیم. مشتری اگه می خواد  

محصول درستی تحویل بگیره باید همکاری نزدیکی داشته باشه این یکی از اصول اجایل هست اش. و این وضیفه ماست که اون رو در این مورد آگاه کنیم. می دونم کار ساده ای نیست ولی شدنی هست اش.

 

اوه بله؛ گفتن این موضوع خیلی ساده‌اس و من منکر این نیستم که شما به طور موردی تونستید مشکل بالا یا قرارداد رو حل کنید. منظور من اشاره به مشکل فرهنگی هست که غالبه و 

1. باید موقع معرفی روش‌های چابک منصف بود و گفت ممکنه به چنین مشکلاتی بخورید

2. راهکارهایی بهتر از «هنرمندی» تیم برای این موضوع ارائه بشه. 

اگه بزرگنمایی نکرده باشم، تنها راهکاری که میشه در اولین فرصت در اختیار افراد گذاشت "هنرمندی" اونهاست. اسکرام نمی گه که چه جوری به این مشکل فایق بیایین. مشکل شما با مشتری خاص شماست و باید راه حل اون رو با هنر خودتون بدست بیارین...

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

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

ولی تنها جایی که می دونستم می تونم نقد بگیرم همینجا بود. کلا انجمن نقادی هستیم اینجا :)

9- شاید تو یه تیم توسعه نیاز باشه که "خبره‌ترین برنامه نویس تیم بشینه سعی کنه از اصول ترکیب بندی رنگ‌ها سر در بیاره". شاید یه روز از اون خواسته بشه که در نبود طراح تیم یه طراحی کوچیک انجام بده. این بدین معنا نیست که نباید 

کارها تخصصی باشه. باید باشن. ولی نباید کارهای تبم متکی به *یک* نفر باشه. حتی اگه کیفیت انجام کار مقداری هم کاهش پبدا کنه باید کار انجام بشه. همیشه فرصت هست برای بهتر کردن کیفیت یه طرح گرافیکی. حتی یه مورد بالاتر ممکن هست اش که برنامه نویس ارشد تیم کاری نداشته باشه و بخواد به تستر ها کمک کنه. شاید حتی کمک اش در حد آوردن یه استکان چایی برا تستر باشه :)

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

دقیقا، همانطور که اول پادکست هم اشاره کردم اسکرام مرهم همه ی درد های ما نیست. اسکرام فقط یه چهارچوب هست اش اون رو قهرمان نکنیم! :) اگه اسکرام نمی تونه برای تیم شما جواب بده روش های دیگه ای هست. برای ما با این نوع تیم ها که جواب داد. آیا برای شما هم جواب می ده؟ باید امتحان کنید.

 

نکته‌ی کلی اینه که روش‌های چابک (خصوصاً سکرام) محدودیت‌های بسیار بسیار زیاد دارند و تنها در داخل چهارچوبی که جواب می‌دن جواب می‌دن،

اما تبلیغاتی که برای این روش‌ها صورت می‌گیره چیزیه در حد مافوق طییعی. 

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

از صدها ابزار که در اختیار مهندسین نرم‌افزار قرار داره و هر ابزار هم حوزه‌ی کاربردی خودش رو داره و استفاده نابجا از ابزار منجر به خسارت می‌شه.

فکر می کنم تا به حال فهمیده باشید که تو کدوم جبهه هستم. از تبلیغ اسکرام یه ریال هم به جیب من نمی ره (بر خلاف وب سایت های مثل اسکرام الیانس)

اسکرام فقط یه *چهارچوب* هست اش. ابزارهایی داره برای عمل در اون چهارچوب. یه خواهش از طرف آرش میلانی کوچک :) اسکرام رو به اندازه ی یه *ابزار* پایین نیارید. نمودار پیشرفت کار یه ابزار هست اش ولی اسکرام بیشتر از یه ابزار هست اش. چهارچوبی است که سعی کرده به انسان ها و تعاملات بین اونها بیشتر از ابزارها بها بده. ولی با شما *کاملا* موافقم که اون رو تبدیل به بُت خدمون هم نکنیم. :)

[M.Jalilnejad]

به نام خدا

سلام به داریوش و آرش عزیز،

در خصوص پاسخ آرش در پاسخ به داریوش ، درباره‌ی پاسخ داریوش به آرش در "در پاسخ به داریوش عزیز" ، باید بگم که: 

1.

همونطور که گفتین اول این کلمه به هیچ وجه  "کسره" نیست و "اس" هست اش. /skrʌm/

این قدر روی تلفظ کلمات کلید نکنید، اگه بخوایم تلفظ اصلی رو بکار ببریم که باید به جای "استوری" هم بگیم "ستوری". تو زبون ما اینجوری میچرخه که اول کلمات کسره بذاریم. خیلی سخت نگیرید. هر جور دوست دارید تلفظ کنید

2.

داریوش جان من منکر تخمین توسط تیم نشدم

گاهی وقت‌ها می‌بینم که بعضیا به جای ساعت از عباراتی مثل : very easy, easy, hard یا tiny, small, medium, large برای تخمین اندازه‌ی آیتم‌ها استفاده می‌کنن 

در مورد Burn down من فکر می‌کنم *تجربه* ی شما ارزشمندتر از چیزیه که صرفا تو scrum-guide نوشته، گرچه خود guide هم اشاره کرده که :

Various trend burndown, burnup and other projective practices have been used to forecast 

progress. These have proven useful. However, these do not replace the importance of 

empiricism. In complex environments, what will happen is unknown. Only what has happened 

may be used for forward-looking decision-making.

آرش جان برای پادکست "انعقاد قرارداد" آیا می‌تونی مطالبی که تو http://www.agilecontracts.org نوشته رو برای ما شرح و بسط بدی که مطلب رو شیرفهم بشیم ؟ هر چی باشه شما تجربه‌ی قرارداد بستن رو دارید.

موفق باشید،
M.Jalilnejad

پی‌نوشت : آرش جان، این جمله "داریوش جان فکر نکنم آرش میلانی تو این پادکست خواسته باشه که ..." رو خودت تو ایمیل‌ات نوشته بودی؟ ;-)

[morteza adi]

 ما در ترجمه اسامی به فارسی 2 نوع روش داریم در یک روش تکیه بر آوای کلمه است که مقبول تره و در روش دوم تکیه بر حروف نوشتاری کلمه است یعنی عینا چیزی که نوشته شده رو مینویسیم با همون حروف!

مثلا اسم petit کهخونده میشه /peti/

هم میشه نوشت پتی وو هم میشه نوشت پتیت ! که البته نوشتن پتی بسیار بسیار صحیح تره!

در مورد کلمه اسکرام هم خوشبختانه چه بنویسیم سکرام و چه اسکرام هر دو روش اول مد نظر بوده که خوبه اما !!....

ما در زبان فارسی بهیچ وجه دو حرف صامت کنار هم نداریم !! برای همین ما ایرای ها به Print یا میگیم /pirint/ یا /perint/

یا وقتی از یه ایرانی بپرسی strength چند بخش داره فکر میکه 3 بخش داره در صورتی که در زبان انگلیسی یک بخش بیشتر نداره!

و این اصلا ضعف زبان قلمداد نمیشه! قرض گرفتن واژه ای از زبانی به زبان دیگه یک روش گسترش اون زبان هست که بهش میگن word borrowing 

و در این وام گیری بیشتر اوقات اوای کلمات عوض میشه تا تلفظ لغت در زبان مقصد راحت تر بشه!

خود انگلیسی ها هم خدا هزار لغت دارند که از ملل مختلط به عاریه گرفتند و تلفظش رو عوض کردن مثلا همه شنیدیم cave میشه غار که از واژه عربی کهف گرفته شده.

یا آرش کمانگیر ما که شده arch یعنی کمان یا مخزن ما که شده magazine

پس تغییر آوا اصلا چیز عجیب و غریبی که نیست بسیار بسیار رایج هم هست! میتونم بگم 99 درصد کلمات که از زبانی قرض گرفته میشوند آوای متفاوتی در زبان مقصد پیدا میکنند.

پس در نتیجه به نظر حقیر کلمه اسکرام بهترین و مناسبترین نوع نوشتن Scrum در زبان فارسی است.


در مورد دقیق نبودن تخمین فکر میکنم شما مختارید هر روشی که مناسب تر باشه رو برای تیم خودتون بکار ببرید ولی برام یه سوالی پیش اومده چطوری میتونید با یوزر استوری ها

مقدار پیشرفت پروژه رو بررسی کنید؟ اخه همه بکلاگ ها که به یک  اندازه نیستند؟؟ مثلا اگه از 60 تا بک لاگ 10 تاشو انجام داده باشید و ندونید اندازه یک بک لاگ  چقدر هست چطور زمان باقی مونده را تخمین میزنید؟

[Asad Safari]

دوستان گرامی ،  

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

با تشکر 

اسد صفری

[Arash Milani]

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

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

همین. "تا چه قبول افتد و چه در نظر آید." :)

شاد باشین،
آرش میلانی
نارمند | narmand.com

2012/1/23 M.Jalilnejad <m.jali...@gmail.com>