اسکرام - متد های چابک (اجایل)
اسلاید های کارگاه تفکر چابک و اسکرام برگزار شده در مرکز علم و فناوری خلیج فارس
- اصول و قواعد چابکی و اسکرام
- چگونگی تشکیل تیم اسکرام
- مفهوم ارتباطات و مستند سازی در اسکرام
- چگونگی رویارویی با تغییرات در سازمان در چارچوب اسکرام
اسکرام چارچوبی برای توسعه، تحویل و نگهداری محصولات پیچیده است. این راهنما شامل تعریفِ اسکرام است. این تعریف دربرگیرنده نقشها، رویدادها، مصنوعاتِ اسکرام به همراه قوانینی است که آنها را به هم گره میزند.
این پرزنت شامل بیانه چابک و 12 اصول چابک میباشد و در ادامه گزیده ای از مباحث کلیدی راهنمای اسکرام آورده شده است تا خواننده بتواند به سرعت به یک دید کلی از بیانیه چابک و اسکرام دست پیدا بکند.
اسکرام - متد های چابک (اجایل)
اسلاید های کارگاه تفکر چابک و اسکرام برگزار شده در مرکز علم و فناوری خلیج فارس
- اصول و قواعد چابکی و اسکرام
- چگونگی تشکیل تیم اسکرام
- مفهوم ارتباطات و مستند سازی در اسکرام
- چگونگی رویارویی با تغییرات در سازمان در چارچوب اسکرام
اسکرام چارچوبی برای توسعه، تحویل و نگهداری محصولات پیچیده است. این راهنما شامل تعریفِ اسکرام است. این تعریف دربرگیرنده نقشها، رویدادها، مصنوعاتِ اسکرام به همراه قوانینی است که آنها را به هم گره میزند.
این پرزنت شامل بیانه چابک و 12 اصول چابک میباشد و در ادامه گزیده ای از مباحث کلیدی راهنمای اسکرام آورده شده است تا خواننده بتواند به سرعت به یک دید کلی از بیانیه چابک و اسکرام دست پیدا بکند.
در پروژه های بزرگ وب و نرم افزارهای تحت وب مدرن، ساخت ظاهر زیبا، کاربرپسند و کاربردپذیر، جز لاینفک دل مشغولی های صاحبان پروژه و مدیران فنی است.به همین دلایل استفاده از پیش پردازنده هایی مانند SCSS، LESS و غیره بسیار متداول شده اند که در حین رفع برخی مشکلات باعث ایجاد پیچیدگی ها و معضلات جدیدی شده اند که به برخی از آنها خواهیم پرداخت که برای این منظور یک مدل واقعی از مجموعه پروژه ها و وب سایت های یک شرکت فعال را از بدو ساخت تاکنون بعلاوه برنامه ریزی های آینده برای آن بررسی خواهیم کرد.
Scrum based methodology for distributed software developmentNavid Sedighpour
This presentation is in Farsi
Presented by Me in 24th May 2016 in AmirKabir University of Technology
Navid Sedighpour
--------------------------------------------------------------------------
ارائه به زبان فارسی است
چهارم خرداد سال 1395 در دانشگاه صنعتی امیرکبیر
نوید صدیق پور
ارائه پایان نامه:بهبود روش ارزیابی معماری نرم افزار از دید مدیریت برون سپاریArash Bande Khoda
اسلاید پایان نامه بهبود روش ارزیابی معماری نرم افزار از دید مدیریت برون سپاری
Improving Software Architecture Evaluation Method based on Outsourcing Management Approach
توسعه نرمافزارهای مقیاسپذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...Web Standards School
معماری ریزسرویسها رویکردی در جهت ماژولار کردن نرم افزار است. یک مفهوم قدیمی اما با تعاریف جدید و مدرن. در این ارائه به معرفی این معماری، مزایا و چالشهای آن، نحوه پیادهسازی، تست و استقرار آن در بستر ابری خواهم پرداخت.
در پروژه های بزرگ وب و نرم افزارهای تحت وب مدرن، ساخت ظاهر زیبا، کاربرپسند و کاربردپذیر، جز لاینفک دل مشغولی های صاحبان پروژه و مدیران فنی است.به همین دلایل استفاده از پیش پردازنده هایی مانند SCSS، LESS و غیره بسیار متداول شده اند که در حین رفع برخی مشکلات باعث ایجاد پیچیدگی ها و معضلات جدیدی شده اند که به برخی از آنها خواهیم پرداخت که برای این منظور یک مدل واقعی از مجموعه پروژه ها و وب سایت های یک شرکت فعال را از بدو ساخت تاکنون بعلاوه برنامه ریزی های آینده برای آن بررسی خواهیم کرد.
Scrum based methodology for distributed software developmentNavid Sedighpour
This presentation is in Farsi
Presented by Me in 24th May 2016 in AmirKabir University of Technology
Navid Sedighpour
--------------------------------------------------------------------------
ارائه به زبان فارسی است
چهارم خرداد سال 1395 در دانشگاه صنعتی امیرکبیر
نوید صدیق پور
ارائه پایان نامه:بهبود روش ارزیابی معماری نرم افزار از دید مدیریت برون سپاریArash Bande Khoda
اسلاید پایان نامه بهبود روش ارزیابی معماری نرم افزار از دید مدیریت برون سپاری
Improving Software Architecture Evaluation Method based on Outsourcing Management Approach
توسعه نرمافزارهای مقیاسپذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...Web Standards School
معماری ریزسرویسها رویکردی در جهت ماژولار کردن نرم افزار است. یک مفهوم قدیمی اما با تعاریف جدید و مدرن. در این ارائه به معرفی این معماری، مزایا و چالشهای آن، نحوه پیادهسازی، تست و استقرار آن در بستر ابری خواهم پرداخت.
14. Methodology؟ چیست
A methodology is a formalized process or set of practices for creating software
• A set of rules you have to follow
• A set of conventions the organization decides to follow
• A systematical, engineering approach for organizing software projects
گزارشات بسیاری تایید میکنند که بیش از 80 درصد از پروژه های نرم افزاری با شکست مواجه میشوند؛
در سال 2005 موسسه
IEEE
برآورد زده است که بیش از 60 بیلیون دلار صرف پروژه های نرم افزاری شکست خورده شده است.
Method روش را «شکل ویژه ای از رویۀ بخشی از یک فعالیت فکری » تعریف کرده است .
پسوند «اولوژی» به معنی علم است .
بنابراین تعریف متدولوژی عبارتست از : علم روشها یا بخشی از دانش که روی روشها تمرکز می کند
7/7/201707/16/96
افراد مهمترین نقش را در پیروزی یک پروژه دارند
یک نیروی قوی لازم نیست که برنامه نویسی عالی باشد، بلکه کافیست که یک برنامه نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد.
نرم افزار بدون مستندات، فاجعه است.
تیم باید مستندات قابل فهم مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است
نرم افزار نمیتواند مثل یک جنس سفارش داده شود.
شما نمی توانید یک توصیف از نرم افزاری که می خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم افزاری است.
وقتی که طرحی را میریزیم باید مطمئن شویم که به اندازه کافی انعطاف پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد.
مسیر یک پروژه نرم افزاری نمیتواند برای بازه زمانی طولانی برنامه ریزی شود.
اولا احتمالا محیط تغییر میکند و باعث تغییر در نیازمندی ها میشود.
ثانیا همین که سیستم شروع به کار کند مشتریان نیازمندیهای خود را تغییر می دهند
اجایل توسعه تدریجی و تکاملی را پیشنهاد می کند
به تدریج بسازید
هر بار بیشتر کاملش کنید
برگردیم به دلایل اصلی شکست پروژه های نرم افزاری
مشتری پادشاه است!
برای رفع مشکل عدم همکاری کاربر نهایی یا مشتری، Agile مشتری را عضوی از تیم توسعه میکند. به عنوان عضوی از تیم، مشتری با تیم توسعه کار میکند تا مطمئن شود که نیازمندها به درستی برآورده میشوند. مشتری همکاری میکند در شناسایی نیازمندیها، تایید میکند نتیجه نهایی را و حرف آخر را در اینکه کدام ویژگی به نرم افزار اضافه شود، حذف شود و یا تغییر کند، را میزند.
نیازمندی ها به صورت تستهای پذیرش نوشته میشوند
برای مقابله با مشکل عدم درک درست نیازمندیها، Agile تاکید دارد که نیازمندیهای کسب شده باید به صورت ویژگیهایی تعریف شوند که بر اساس معیارهای مشخصی قابل پذیرش باشند. این معیارهای پذیرش برای نوشتن تستهای پذیرش به کار میروند. به این ترتیب قبل از اینکه کدی نوشته شود، ابتدا تست پذیرش نوشته میشود. این بدین معنی است که هر کسی باید اول فکر کند که چه میخواهد، قبل از اینکه از کسی بخواهد آن را انجام دهد. این راهکار فرایند کسب نیازمندیها را از بنیاد تغییر میدهد و به صورت چشم گیری کیفیت برآورد و زمان بندی را بهبود میدهد.
زمانبندی با مذاکره بین تیم توسعه و سفارش دهنده تنظیم میشود
برای حل مشکل زمان بندی غیر واقعی، Agile زمان بندی را به صورت یک فرآیند مشترک بین تیم توسعه و سفارش دهنده تعریف میکند. در شروع هر نسخه از نرم افزار، سفارش دهنده ویژگی های مورد انتظار را به تیم توسعه میگوید. تیم توسعه تاریخ تحویل را بر اساس ویژگیها برآورد میزد و در اختیار سفارش دهنده قرار میدهد. این تعامل تا رسیدن به یک دیدگاه مشترک ادامه مییابد.
هیچ چیزی روی سنگ حک نشده است، مگر تاریخ تحویل
برای رفع مشکل ضعف در مدیریت تغییرات، Agile اصرار دارد که هر کسی باید تغییرات را بپذیرد و نسبت به آنها واقع بین باشد. یک اصل مهم Agile میگوید که هر چیزی میتواند تغییر کند مگر تاریخ تحویل! به عبارت دیگر همین که محصول به سمت تولید شدن حرکت میکند، مشتری (در تیم محصول) میتواند بر اساس اولویتها و ارزشهای خود ویژگیهای محصول را کم یا زیاد کرده و یا تغییر دهد. به هر حال او باید واقع بین باشد. اگر او یک ویژگی جدید اضافه کنید، باید تاریخ تحویل را تغییر دهد. به این ترتیب همیشه تاریخ تحویل رعایت میگردد.
تستها قبل از کد نوشته میشوند و کاملا خودکار هستند
برای رفع مشکل کمبود تست، Agile تاکید میکند که ابتدا باید تستها نوشته شوند و همواره ارزیابی گردند. هر برنامه نویس باید اول تست را بنویسد، سپس کد لازم برای پاس شدن آن را. همین که کد تغییر میکند باید تستها دوباره اجرا شوند. در این راهکار، هر برنامه نویس مسئول تستهای خود است تا درستی برنامه از ابتدا تضمین گردد.
مدیریت پروژه یک فعالیت جداگانه نیست
برای رفع مشکل فرآیندهای غیر منعطف و باددار، Agile مدیریت پروژه را درون فرآیند توسعه میگنجاند. وظایف مدیریت پروژه بین اعضای تیم توسعه تقسیم میشود. برای مثال هر 7 نفر در تیم توسعه نرم افزار (متدولوژی اسکرام) زمان تحویل را با مذاکره تعیین میکنند. همچنین کد برنامه به صورت خودکار اطلاعات وضعیت پروژه را تولید میکند. به عنوان مثال نمودار burndown ، تستهای انجام نشده، پاس شده و رد شده به صورت خودکار تولید میشوند.
به کار گیری توسعه چابک
یکی از مشکلات توسعه چابک این است که شما اول باید به خوبی آن را درک کنید تا قادر به پیاده سازی درست آن باشید. این درک هم باید کلی باشد (مانند Scrum و XP) و هم جزئی (مانند TDD و جلسات روازنه). اما چگونه باید به این درک برسیم؟ کتابها و مقالات انگلیسی زیادی برای یادگیری توسعه چابک و پیاده سازی آن در سازمان وجود دارند، ولی متاسفانه منابع فارسی کمی در این زمینه است.
اسکرام چارچوبی برای فرآیند است که به منظور مدیریت توسعۀ محصولات پیچیده از اوایل دهه نود میلادی به کار گرفته شد
اسکرام به خودی خود یک فرآیند و یا شگرد ساخت محصول نیست؛
بلکه چارچوبی است که در آن میتوانید شگردها و فرآیندهای گوناگونی را بکار ببندید.
قوانین اسکرام نقشها، رویدادها و مصنوعات آن را به هم متصل کرده و در مورد تعاملات بین آنها تصمیم گیری میکند.
شالوده اسکرام بر پایه نظریه کنترل فرآیند تجربی یا تجربه گرایی بنانهاده شده است. نظریه تجربه گرایی تأکید میکند که دانش از تجربه حاصل میشود و تصمیمگیری بر اساس دانسته ها است. اسکرام به منظور بهینه سازی قدرت پیش بینی و کنترل ریسک از یک روش تکرارشونده ، افزایشی استفاده میکند.
Artifact :
مصنوعات
خروجی یک فرآیند است. مثلا خروجی طراحی شیءگرا، نمودارهای UML است.
رابطه بین انتشار های کوچک و زود به زود با بازگشت سرمایه
کلا در اسکرام نگاه ما به برنامه ریزی اینه که
با هدف یادگیری سریع، برنامه ریزی کنید و در صورت لزوم مسیر را تغییر دهید
برای اجایل بودن اسکرام کافی نیست
TFS is a lot more than just version control
TFS will not solve all your problem
TFS will help you trace and streamline what you need to do