شاخص Velocity و تیم های متغیر با پروژه های متغیر
soheil samadzadeh
سوال اول
Hamidreza Motaghian
شما میخواین زمان تقریبی انجام پروژه جدید رو براساس تجربه برنامه زمانی پروژه قبلی برآورد کنید؟ اگر منظورتون این هست چون همونطور که خودتون هم اشاره کردید شرایط پروژه ها عموماً با هم متفاوت هست برنامه زمانی پروژه های قبلی نمیتونه معیار دقیقی برای برآورد زمانی در لحظه شروع پروژه جدید باشه. البته در بعضی مواقع قطعاً کمک می کنه ولی کافی نیست. به نظر من تنها کاری که میشه انجام داد اینه که چند تا اسپرینت رو بگذرونید و طبق شرایط این پروژه تخمین زمان پایان پروژه رو بزنید. مستقل از اسکرام در متدولوژی های دیگه هم به همین صورت هست یعنی شما تا در پروژه نفوذ نکنید و شناخت نسبی اولیه پیدا نکنید و حتی تا حدودی معماری رو بررسی نکنید و ... نمیشه برآورد کرد. اگر می بینید خیلی شرکت ها برآورد میکنن با تقریب 30 الی 40 درصد هست و اگر دقت کنین شاید نیمی از تخمین ها اشتباه از آب دربیاد. اون تخمین هایی هم که نسبتاً خوب میشه بخاطر تجربه بالای مدیر پروژه هست. من تاحالا ندیدم و نشنیدم از کسی که شرکتی حتی بزرگترین شرکت های نرم افزاری ایرانی در یک دومین جدید تخمین درستی داشته باشن همه افتضاح. بخاطر همین اون تقریب رو همیشه در نظر بگیرین و ترجیحاً در دومین های جدید از کسانی که قبلا تجربه اون دومین رو داشتن مشاوره بگیرین
موفق باشید
--
Regards,
H.R.Motaghian
CSM | MCP
--
http://hamidreza.info
soheil samadzadeh
انشایی که بکار بردم تفکرات خودم بود و چلنج های فکریم
Best Regards,
S Samadzadeh
Mahdi Fahmideh
|
اساسا سوال شما مستقل از متدولوژی مورد استفاده است. تخمین اندازه پروژه به دو روش کلی میتونه انجام بشه. روش آماری و روش قیاسی یا تجربی. در روش آماری مبنای کار این هست که سازمان توسعه نرم افزاز مخزنی از اطلاعات آماری سیستم های قبلی رو داشته باشه و بر اساس داده های قبلی بتونه اندازه پروژه جاری رو تخمین بزنه. مخزنی که عرض میکنم باید مخزن عملیاتی باشه و شرکت نرم افزاری باید قبلش متریک هایی رو تدارک دیده باشه. لذا بلوغ خاصی در سازمان لازم هست و نوعا سازمان باید از سطح سوم مدل بلوغ قابلیت رو پاس کرده باشه. علاوه بر این اگه جستجوی در وب انجام بدهید عده ای محقق آمده اند دسته بندی روی دامین های مختلف نرم افزار مثلا دامین پزشکی، یا حسابداری یا آرشیو اسناد انجام دادند و با توجه به اطلاعات آماری پروژه های انجام شده تخمینی زده اند که مثلا فلان تیپ از سیستم ها چقدر زمان میبره. لذا یک قدم مساله تخمین زدن صحیح رو جلو برده اند. در رویکرد قیاسی مدیر پروژه با تجربه قبلی، کار جدید رو پیش بینی میکنه. هر چقدر پروژه مشابه با پروژه قبلی باشه یا به اصطلاح دامین قبلی به دامین جدید نزدیک تر باشند به طبع تخمین صحیح تر است. این تخمین میتونه به صورت حدسی باشه. مثلا مدیر پروژه با توجه به اطلاعات پروژه قبلی استنتاج میکنه که سیستم جدید 70 تا فرم ورود اطلاعات لازم داره و یا 50 جدول نیاز است. به طبع اندازه پروژه و آشنایی قبلی بسیار مهم است و تصمیم گیری ذاتا دراین روش شهودی است. دو مورد بالا همانطور که عرض کردم مستقل از متدولوژی مورد استفاده است. اما اگر مشخص تر بخواهیم بررسی کنیم دو نکته باید در نظر گرفته بشود. اولا اینکه نوعا متدولوژی های چابک برای توسعه سیستم هایی با اندازه کوچک استفاده میشوند. مثلا فرض کنید برای یک فروشگاه میخواهید سیستم ثبت سفارش تحت وب داشته توسعه بدهید. نوعا سیستم هایی از این دست کوچک هستند. یعنی فرایند محور یا داده محور نیستند و میشه سر و ته اونها رو طی چند هفته انجام داد. در این نوع سیستم ها معماری آنچنانی که برای یک سازمان اداری نیاز داریم لازم نیست. حتی دوره مسولیت سیستم هایی که با رویکرد چابک توسعه می یابند خیلی طولانی نیست و بعد مدتی دور انداخته میشوند. بنابراین توجه کنید به طور شهودی سیستم هایی که با رویکرد چابک توسعه می یابند کوچک هستند و به قول معروف ابعاد مختلفشون در همون ابتدای کار قابل دسترسی است. گرچه هر یک از دو روش فوق، آماری یا قیاسی، ما رو یک قدم جلو میبرد ولی باز هم نمیشه تخمینی دقیق زد. برای اینکه یک قدم جلوتر بریم در عمل شرکت نرم افزاری یک قرارداد اولیه به منظور تحلیل مقدماتی و نه تحلیل تفصیلی با کارفرما تهیه کرده و طی چند هفته و به صورت خیلی سریع اندازه پروژه رو تخمین میزنند. ممکن است در انتهای این تخمین اولیه، پروژه متوقف شود یا کار ادامه یابد. در هر صورت تحلیل گران پول دریافت خواهند کرد!. بنابراین این نکته مکمل دو روش قبلی است. بنابراین با توجه به توضیحات بالا پروژه خورد خورد یا همان تکراری تدریجی جلو میرود و ممکن است در جایی متوقف شود. البته در کشور ما چنین دیدی چندان وجود نداره و در مناقصه ها که زمان پروژه از سوی کارفرما تعریف شده کل پروژه تحویل پیمانکار داده می شود که با طبع زمانبندی ها با مشکل مواجه میشود. ببینید واقعیت ماجرا این مواردی هست که عرض کردم ولی در عمل ممکنه به این صورت عمل نشود و مدیر پروژه این دیدگاه رو نداشته باشه.
--- On Thu, 4/5/12, soheil samadzadeh <s.sama...@gmail.com> wrote: |
Hamidreza Motaghian
هم توضیحات سهیل عزیز و هم توضیحات مهدی عزیز بسیار مفید بود.
این تاپیک، تاپیک خیلی خوبی هست چراکه در آینده میتونه برای خیلی از افرادی که همیشه این سوال رو بعنوان یک دغدغه ذهنی دارن جوابگو باشه. این موضوع خیلی مهمی هست که باید حتماً و بعنوان یک ضرورت قبل از بکارگیری هر متدولوژی بهش پرداخته بشه.
من با نظرات هر دوی دوستان موافق هستم. چالش های مهدی کاملاٌ ملموس هست. پروژه های فیکسد تایم و فیکسد پرایس خیلی با اسکرام جور در نمیاد. البته این موضوع نسبی هست. اینکه راهکار چی هست به نظر من نیاز به تحقیق و مطالعه بیشتری داره و نظر شخصی نمیتونم بدم. بله متاسفانه من هم خیلی جاها دیدم که اسکرام رو معجزه ای در موفقیت پروژه های نرم افزاری میدونن و متاسفانه این ذهنیت کاملاً غلط هست و باید اصلاح بشه.
همونطور که سهیل هم گفت به نظر من بهترین روش تخمین زمان و قیمت در قالب قراردادی تحت همین عنوان میتونه باشه. که این بحث هم کاملاً مستقل از روش انجام پروژه هست. البته سوال تاپیک دقیقا روی خود روش اسکرام هست ولی خوب میشه از مسیر دیگه ای هم به جواب رسید.
البته من در چند تا پروژه این روش رو پیشنهاد کردم. شاید از دو سال پیش تا حالا. متاسفانه شرکت های دیگه حاضرن به هر قیمتی کار رو بگیرن و جالب اینه که خیلی راحت و سریع زمان و قیمت رو پیشنهاد می دن و جالب تر اینه که اصلاً تو این دومین تجربه قبلی نداشتن. کارفرما هم میبینه از بین 10 تا شرکت 9تاشون قیمت دادن فقط من اینجوری گفتم پیش خودش فکرهای دیگه میکنه. اگر بشه این طرح رو جا انداخت بطوریکه اکثر شرکت ها پیشنهاد اولیه شون همین قرارداد تخمین باشه دیگه این موضوع برای کارفرما هم پذیرفته میشه و به مرور زمان جا میفته. حالا من پیشنهادم به دوستان اینه این مساله رو پیشنهاد بدن شاید بشه این روال غلط رو اصلاح کرد و کم کم حداقل گوش کارفرما با این پیشنهاد آشنا بشه آدمو چپ چپ نگاه نکنه. البته ذکر این نکته هم مهم هست که مستنداتی که جمع آوری میشه رو نباید در اختیار کارفرما قرار داد. چون من یه تجربه ای داشتم. خروجی قرارداد صرفاً خلاصه ی بسته ای از مستندات باشه و ترجیحاً موارد اضافی فقط در جلسات بصورت شفاهی گفته شه. مساله دیگه دومین پروژه هست، نمیشه در هر پروژه ای این پیشنهاد قرارداد تخمین رو بدین. این نکته هم مهم هست.
این طرح مسلماً به موفقیت پروژه هم کمک میکنه. اگر در یه پروژه مثلاً 100 میلیونی، کارفرما 5 میلیون خرج این کنه که سه تا قرارداد اولیه با سه تا شرکت مختلف ببنده تا برآورد اولیه کنن این هم میتونه به انتخاب یک شرکت بهتر از بین اونا کمک کنه چون بالاخره نحوه کارکرد شرکت ها رو مقایسه میکنه و هم میتونه ریسک پروژه رو به مراتب پایین بیاره. این احتمال داره تا بجای 105 میلیون 150 میلیون بده و پروژه با تاخیر یک ساله به پایان برسه.
البته بحث تاپیک رو کمی منحرف کردم ولی دیدم شاید زمان خوبی باشه تا این موضوع بیان شه.
موفق باشید.
Mahdi Fahmideh
| فرمایش شما صحیح. با این حال برای اینکه به سمت قراردادهای پیش تولید یا تحلیل مقدماتی حرکت بشود باید این دغدغه در ذهن تصمیم گیرندگان کلیدی صنف نرم افزار شکل بگیره. یعنی به عنوان یک دیسپلین منظور شود. در مورد اینکه میفرمایید اسکروم چه روشی برای تخمین دارد باید عرض کنم از نقطه نظر فرایندی عموم متدولوژی های چابک فرایند ندارند. یعنی اگر به مستندات متدولوژی مراجعه شود فرایند توصیف شده ای نمی بینید. در واقع متدولوژی های چابک مجموعه ای پراکتیس هستند که میتونند به متدولوژی های سنگین وزن اضافه بشوند. به خصوص که اسکروم یک نوعا یک چارچوب مدیریت پروژه است. هرچند اگر به سایت های حمایت کننده اونها مراجعه کنید واریانت هایی از فرایند متدولوژی اسکروم رو ببینید با این حال جزییات انجام کارها را ذکر نمی کنند. مثلا متدولوژی در مورد اینکه تحلیلگر چه تکنیکی برای تبدیل موارد کاربرد به کلاس های تحلیل اتخاذ کند، ساکت است. به طور خاص در متدولوژی اسکروم، اسکروم مستر مسوول این است که چه تکنیکی را برای فعالیت خاصی تجویز کند. از این نقطه نظر در خانواده متدولوژی های چابک ما نوعی درز (Seamless) بین فعالیت های توسعه نرم افزار مشاهده میکنیم. |
------------------------------------------------------------------ Mahdi Fahmideh Gholami Automated Software Engineering Research Group http://aser.sbu.ac.ir Shahid Beheshti University Evin, Tehran
|
| --- On Fri, 4/6/12, Hamidreza Motaghian <m.ham...@gmail.com> wrote: |
soheil samadzadeh
اون جور که من از لابلای نوشته های مهدی متوجه شدم این بود که اسکرام برای پروژه های کوچک هست، که بشه اون رو در ابتدا بشناسیم، خب اگر اینجور هست چرا اسکرام، سیستم آبشاری رو برای این پروژه ها پیشنهاد کنیم بهتر نیست؟
اگر اسکرام برای پروژه های کوچک هست، چرا این رو اعلام نمیکنند، اصولا پروژه کوچک چهجور پروژه ایه؟
موضوع دیگه که توی صحبت های حمیدرضا و مهدی وجود داشت، بحث قرارداد هست، در زاویه دیدی که من توصیف کردم شما به عنوان مدیر پروژه در یک شرکت استخدام هستید، و پروژه های گوناگونی رو قراره مدیریت کنید، نه اینکه بخواین قراردادی رو بگیرید یا چیز دیگه ...
من چیزهایی رو که متوجه شدم از بحث، اینهاست، دوستان اگر اشتباه میکنم تذکر بدند:
1- اسکرام برای پروژه های کوچک طراحی شده
2- اسکرام رو باید با متدلووژی ها سنگین وزن مثل آر.یو.پی ترکیب کرد، گرچه در بخش هایی مجبوری که اسکرام رو انقدر تغییر بدی که دیگه اسکرام نیست میشه یه چیز دیگه که مانیفست این رو منع میکنه
4- ما همیشه برای پروژه های نرم افزاری باید تحلیل آپ-فرونت داشته باشیم، یا حد اقل فاز شناختی که زمانبندی نداره داشته باشیم، چیزی که اسکرام و سیستم های چابک این روش جلو جلو تحلیل کردن رومنع میکنه
5- همه چیز در ابتدای شروع مقایسه ای ست - مقایسه ای ضمنی،
ممنون ولی مشکل همچنان باقیست :)
Asad Safari
اسکرام یک چارچوب براي توسعه و نگهداري محصولات پیچیده می باشد.
اسکرام یک فرآیند و یا تکنیک براي ساخت محصول نمی باشد. در عوض ، اسکرام چارچوبی است که می توانید در آن از تکنیک ها و فرآیندهاي وسیعی استفاده نمایید.
Agile Coach/Trainer - Certified Scrum Master
Twitter : asadsafari
Cell No : (+98) 914 912 0914
http://www.irscrum.com
http://blog.irscrum.com
soheil samadzadeh
در خصوص این تفکر غلط که ولاسیتی معیاری است برای براوردهای فراپروژه ای، چندین جا که معتبر هم هستند، مثبت بودن این تفکر رو القا میکنند البته سعی میکنم لینک ها رو پیدا کنم
ولی فک میکنم سپردن پروژه به دست اسکرام و رها کردن اون کاری بسیار خطرناک هست، باید از اون به عنوان یک جعبه ابزار استفاده کرد که این اصلا به مفهوم بد بودن یا کوچک بودن اسکرام نیست :)
ممنونم
Asad Safari
soheil samadzadeh
ولی همچنان نمیشه گفت که مثلا روش تولید نرم افزارم من، اسکرام هست، چون اون رو میشکنیم و ضعف هایی که توی پروژه باهاش برمیخوریم و اسکرام بهمون پاسخ نمیده از روش های دیگه برای حلشون کمک میگیریم
ولی حداقل توی ایران و من فکر میکنم توی تمام دنیا ارضای تیم توسعه برای استفاده از اسکرام یک چالش بزرگ هست
و تا وقتی نتونیم به ابهاماتش پاسخ روشنی بدیم نمیتونیم ازش به صورت دقیق استفاده کنیم
یکی از این ابهامات استفاده از تجربیات بدست آمده در یک پروژه موفق اسکرام در پروژه های دیگه ست که من شخصا دچارش هستن :)
من فکر میکنم قبل از وارد کردن یک روش جدید باید فرهنگش جا بیافته حداقل برای خود اسکرام مسترها و مدیران پروژه
ممنونم
Mahdi Fahmideh
|
سهیل عزیز یه مقدار مفاهیم "متدولوژی توسعه نرم افزار" و "چرخه حیات توسعه نرم افزار" با هم مخلوط شده که لازم این دو از هم تفکیک شوند. چرخه حیات مفهومی انتزاعی تر از متدولوژی است. در واقع متدولوژی های توسعه نرم افزار، رویکردهای مختلف چرخه حیات توسعه نرم افزار رو جزیی تر یا اصطلاحا کانکریت می کنند. یا به بیان دیگر متدولوژی های توسعه نرم افزار از چرخه حیات نرم افزار مشتق می شوند. عموم متدولوژی شیی گرا که چابک ها نیز در این گروه قرار میگرند مشتق شده از چرخه حیات تکراری- تدریجی هستند. بدین معنا که محصول نهایی به صورت خرد خرد توسعه پیدا میکنه. بنابراین اینکه میفرمایید آبشاری سیستم توسعه دهیم به نوعی رویکرد توسعه نرم افزار رو تغییر میدهید و باید به دنبال متدولوژی هایی باشیم که رویکرد آبشاری دارند. اگه اشتباه نکنم متدولوژی جکسون متدولوژی از گونه ساختاری و آبشاری است. به طبع رویکرد آبشاری مشکلات خود را در خصوص برخی پروژه دارد. اینکه میگم برخی پروژه ها در واقع بدین معناست که رویکرد آبشاری توسعه نرم افزار، رویکردی منسوخ شده نیست و سازمان هایی همچنان از آن استفاده می کنند (الان ریفرنسری دم دست ندارم که معرفی کنم) در مورد قرارداد، اگر شما کارمند هستید که باید انچه که از سمت مدیریت می آید انجام بشود و چاره ای نیست ولی بهرطریق نظر کارشناسی خودتون رو بدهید. کمی سازی یا عددی کردن مفهوم کوچک بودن پروژه رهنمود هایی وجود دارد. عموم متدولوژی های چابک مقیاس پذیر نیستند. لذا در پروژه های بزرگ قابل بکارگیری نیستند. به بیان دقیق تر از آنجا که مدل سازی نیازمندی ها به صورت فیس تو فیس و در قالب صحبت های محاوره ای منعکس می شود ( یا در حد یوزر هیستوری) و وجه مدل سازی چندان پر رنگ نیست به طبع پروژهایی با متدولوژی های چابک قابل انجام است که بتوان مهندسی نیازمندی را با گفتگوهای شفاهی را شناسایی و نگهداری کرد. با در نظر گرفتن این ضعف میشه پی برد برای یک سیستم سازمانی فرایند محور پیچیده، صحبت شفاهی جوابگو نیست و باید موارد کاربرد به سیستماتیک استخراج شده، بازنمایی و تایید شود. به عبارت دیگر فاز مهندسی نیازمندی حجم قابل توجهی از محصولات کاری تولید میشود. میخوام عرض کنم خود پروژه ما رو به این سمت میبره که از چه متدولوژی استفاده کنیم. ضعف دیگر متدولوژی های چابک عدم قابلیت بکارگیری در سیستم های بحرانی است. یعنی چابک ها Criticality حمایت نمیکنند. به عنوان مثال شما نمیتوانید یک سیستم پیچیده نظامی رو با متدولوژی چابک توسعه بدهید. متدولوژی لازم است وجوه فرمال سیستم را حمایت کند. با در نظر داشتن عدم خاصیت مقیاس پذیری و حمایت از سیستم های بحرانی، قلمرو عملکردی متدولوژی های چابک روشن تر میشود. سوال اول- بله سوال دوم – ببینید متدولوژی های چابک فقط یکسری پراکتیس هستند نه چرخه حیات توسعه نرم افزار نیستند. حتی بکارگیری لفظ متدولوژی برای اونها چندان صحیح نیست. چون متدولوژی تعریف رسمی دارد. شما این پراکتیس ها رو در متدولوژی های مختلف میتوانید اعمال کنید. اگر قدری تخصصی تر بخواهیم بحث کنیم شما باید به ازای هر پروژه در شرکت خود یک متدولوژی سفارشی بسازید. فعالیت های این متدولوژی سفارشی میتواند از متدولوژی های مختلف به عاریت گرفته شود. مثلا مفهوم Daily stand up meeting را از متد اسکروم، برنامه نویسی دو نفره رو از متد ایکس پی، فیلتر پروژه را از متدولوژی دی اس دی ام، سند معماری نرم افزار رو از راپ، پس شرط ها و پیش شرط های عملیات رو از متدولوژی بن و ... بگیرد. من بعید میدونم در پروژه گفته شود به طور خاص متدولوژی ایکس رو اجرا کردیم. سوال سوم- اگر شما یک مخزن آماری در مورد خروجی های خود نگهداری کنید از اطلاعات آماری این پروژه برای اسپرینت بعدی یا پروژه های دیگر می توانید استفاده کنید. سوال چهارم – بله باید باشد ولی باید طی دو یا سه هفته تحلیل مقدماتی انجام شود. خیلی سریع چون مساله منابع پروژه مطرح است. سوال پنجم – بله ضمنا بحث کوبیدن متدولوژی نیست. از نقطه نظر متدولوژیکی ما معیارهایی داریم که متدولوژی ها رو باهاشون می سنجیم و تحلیل میکنیم. |
|
| --- On Fri, 4/6/12, soheil samadzadeh <s.sama...@gmail.com> wrote: |
Mahdi Fahmideh
|
نکته اینجاست اگر میبینید که متدولوژی مبنایی که باهاش کار میکنید وجوهی را حمایت نمیکنه، باید از متدولوژی های دیگر و پراکتیس های مهندسی نرم افزار وام بگیرید و به متد اضافه کنید. تحلیل مقدماتی یک پرکتیس مهندسی نرم افزار است که به اسکرام میتواند اضافه شود. |
--- On Fri, 4/6/12, soheil samadzadeh <s.sama...@gmail.com> wrote: |
|
soheil samadzadeh
مجددا از تشریک مساعی و همفکریت ممنونم همینطور از دوستان دیگر
تاپیک همچنان بازه ها، نبندینش یه وقت :o)
soheil samadzadeh
با نگاهی که آموزه ها و مانیفست و پراکتیسهایی که اسکرام در اختیار ما میزاره خصوصیات یک فرآیند توسعه و تولید رو داره چون دارای شاخص ها و عناصر زیر هست
1- نقش ها
3- دیسیپلین ها
4- مصنوعات
پس اگه اون رو یک فرآیند توسعه ببینیم باید پاسخگوی مسائل ذکر شده باشه به نوعی واگر نیست و یا ما براش جوابی پیدا نمیکنیم، عنوان اینکه اسکرام صرفا یک چهارچوب توسعه نرافزار هست، یک نوع فرار به جلوست ...
منظورم اینه که اسکرام رو باید تقویت کرد نه اینکه ماموریتش رو تغییر داد
اگر ترجیح میدید میتونیم تاپیک جدیدی براش ایجاد کنیم چون این بحث ها فرای موضوع اصلی تاپیک هست
ممنون