نمی توان گفت دلیل عدم موفقیت برخی از شرکتها پاسخ ندادن به سوالات فوق است اما میتوان ادعا کرد که دلیل عدم موفقیت،ممکن است عدم طرح شدن سوالات فوق باشد. پروژه به یک تلاش موقت برای خلق یک خروجی یکتا گفته میشود اما محصول هر موجودیتی است که شما برای برآورده کردن نیاز یا خواسته وارد بازار میکنید. مدیر پروژه مسئول برآورده کردن اهداف از پیش تعیین شده با استفاده از تیم توسعه است و مدیر محصول، مسئول برآورده شدن تمامی نیازیها مشتریان، سود اقتصادی سازمان و مزیتهای رقابتی پایدار محصول است.
شما در حال توسعه کدام یک هستید؟ محصول یا پروژه؟
- بلاکهای جزئی با عنوان اسپرینت
- ویژگیهای جزئی
- تیمهای کوچک
- product backlog : مجموعهای اولویت بندی شده از نیازمندیهای سطح بالای سیستمی که در نهایت بایستی تحویل داده شود.
- sprint backlog : مواردی از product backlog که قرار است در یک sprint انجام شوند.
- نمودار burn-down :هدف نمودار burn-down، نمایش روند پیشرفت پروژه به صورت نموداری به اعضای تیم توسعه است که حاوی اطلاعاتی دربارۀ کل زمان انجام کار، زمان تخمینزده شده، مقدار کارانجام شده و عقبماندگیهای پروژه است.
- مستقل (Independent): باید خودبسنده باشد و به سایر داستانها وابسته نباشد.
- قابل مذاکره (Negotiable): داستانهای کاربری که بخشی از یک اسپرینت هستند همیشه قابل تغییر و بازنویسی هستند.
- با ارزش (Valuable): یک داستان کاربر باید به کاربر نهایی، ارزشی را ارائه دهد.
- قابل برآورد (Estimable): همیشه باید بتوان اندازۀ داستان کاربر را تخمین زد.
- اندازۀ مناسب (Sized appropriately): داستانهای کاربر نباید آن قدر بزرگ باشند که تبدیلشان به یک طرح یا وظیفه یا امر اولویتبندی شده با درجۀ مشخصی ممکن نباشد.
- قابل آزمون (Testable): داستان کاربر یا توصیفات مربوط به آن باید اطلاعات ضروری برای آزمودن آن را فراهم کنند.
معیار پذیرش
اگرچه product backlog ، sprint backlog و نمودار burn-down بخشهای اصلی اسکرام هستند، معیار پذیرش خروجی جانبی بسیار مهمی از فرآیند اسکرام است. بدون معیار پذیرش خوب، یک پروژه محکوم به شکست است.
معیار پذیرش ضرورتاً شفاف کنندۀ داستان است. چنین معیاری مجموعهای از گامهای مختلف را در اختیار توسعه دهنده میگذارد که پیش از آنکه کار تمام شده تلقی شود، باید انجام دهد. معیار پذیرش، توسط صاحب محصول ( product owner ) به کمک مشتری ایجاد میشود. این معیار انتظار از داستان کاربر را تنظیم میکند. استفاده از این معیار درجای خود نقطۀ شروع خوبی برای نوشتن تستهای خودکار یا حتی توسعۀ آزمون محور توسط توسعهدهنده است. بدین طریق، توسعهدهنده چیزی را تولید میکند که مشتری بدان نیاز داشته و آن را میخواهد.
دیگر مزیت معیار پذیرش وقتی آشکار میشود که یک ویژگی در طول یک اسپرینت کامل نشده و نیاز است تا از اسپرینتها خارج شود. در چنین موردی تیم میتواند معیار پذیرش را به عنوان ابزاری به کار گیرد تا بفهمد که داستان کاربر چگونه به قطعات کوچکتری تقسیم شود تا کماکان ارزشی را برای مشتری فراهم کرده تا بتواند در یک اسپرینت کامل شود.
- Scrum Master
- Product Owner
- Delivery Team
- Scrum Master
- شما چه چیزی را از دیروز تا حالا انجام دادهاید؟
- شما چه برنامهای برای امروز دارید؟
- آیا شما مشکل دیگری که مانع رسیدن به هدفتان باشد، ندارید؟ چه جریانی باعث ایجاد این موانع شدهاند؟ آیا میتوان مانع را حذف کرد یا باید تشدید شود؟
خیلی از ما با کابوس پروژه ای که هیچ تجربه ای در انجام آن نداریم روبرو شده ایم. نبودن تجربه موثر منجر به خطاهای تکراری و غیر قابل پیش بینی شده و تلاش و وقت ما را به هدر میدهد. مشتریان از کیفیت پایین، هزینه بالا و تحویل دیر هنگام محصول ناراضی هستند و توسعه دهندگان از اضافه کارهای بیشتر که منجر به نرم افزار ضعیتتر میگردد، ناخشنود.
همین که با شکستی مواجه میشویم از تکرار چنین پروژه هایی اجتناب میکنیم. ترس ما باعث میشود تا فرآیندی بسازیم که فعالیتهای ما را محدود نموده و ایجاد آرتیفکتها[۱] را الزامی کند. در پروژه جدید از چیزهایی که در پروژههای قبلی به خوبی کار کردهاند، استفاده میکنیم. انتظار ما این است که آنها برای پروژه جدید نیز به همان خوبی کار کند.
اما پروژهها آنقدر ساده نیستند که تعدادی محدودیت و آرتیفکت ما را از خطاها ایمن سازند. با بروز خطاهای جدید ما آنها را شناسایی و رفع میکنیم. برای اینکه در آینده با این خطاها روبرو نشویم آنها را در محدودیتها و آرتیفکتهای جدیدی قرار میدهیم. بعد از انجام پروژههای زیاد با فرآیندهای حجیم و پر زحمتی روبرو هستیم که توانایی تیم را کم کرده و باعث کاهش کیفیت تولید میشوند.
فرآیندهای بزرگ و حجیم میتواند مشکلات زیادی را ایجاد کند. متاسفانه این مشکلات باعث میشود که خیلی از افراد فکر کنند که علت مشکلات، نبود فرآیندهای کافی است. بنابراین فرآیندها را حجیمتر و پیچیدهتر میکنند. این مسئله منجر به تورم فرآیندها میگردد که در محدوده سال ۲۰۰۰ گریبان بسیاری از شرکتهای نرم افزاری را گرفت.
اتحاد چابک
در وضعیتی که تیمهای نرم افزاری در بسیاری از شرکتها خود را در مردابی از فرآیندهای زیاد شونده میدیدند، تعدادی از خبرههای این صنعت که خود را اتحاد چابک[۲] نامیدند در اویل سال ۲۰۰۱ یکدیگر را ملاقات کرده و ارزش هایی را معرفی کردند تا تیمهای نرم افزاری سریعتر نرم افزار را توسعه داده و زودتر به تغییرات پاسخ دهند. چند ماه بعد، این گروه ارزشهایی تعریف شده را تحت مانیفست اتحاد چابک در سایت http://agilemanifesto.org منتشر کردند.
مانیفست اتحاد چابک
ما با توسعه نرم افزار و کمک به دیگران در انجام آن، در حال کشف راههای بهتری برای توسعه نرم افزار هستیم. از این کار به ارزشهای زیر میرسیم :
۱- افراد و تعاملات بالاتر از فرآیندها و ابزارها
۲- نرم افزار کار کننده بالاتر از مستندات جامع
۳- مشارکت مشتری بالاتر از قرارداد کاری
۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.
افراد و تعاملات بالاتر از فرآیندها و ابزارها
افراد مهمترین نقش را در پیروزی یک پروژه دارند. یک فرآیند عالی بدون نیروی مناسب منجر به شکست میگردد و بر عکس افراد قوی تحت فرآیند ضعیت ناکارآمد خواهند بود.
یک نیروی قوی لازم نیست که برنامه نویسی عالی باشد، بلکه کافیست که یک برنامه نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران، تعامل درست و سازنده با سایر اعضای تیم خیلی مهمتر از این که یک برنامه نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفقتر هستند از تعداد برنامه نویسی عالی که قدرت تعامل مناسب با یکدیگر را ندارند.
در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال میتوانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گرانقیمت از برنامه رایگان کد باز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفا به آنها به عنوان امکانی جهت تسهیل فرآیندها نگاه کنید.
نرم افزار کار کننده بالاتر از مستندات جامع
نرم افزار بدون مستندات، فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم افزاری نیست. تیم باید مستندات قابل فهم مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را میگیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم میشوند.
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نماید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نماید.
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه میتوانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال میدهیم. ما آنها را بخشی از تیم میکنیم و با تعامل نزدیک و رو در رو به آنها آموزش میدهیم.
مشارکت مشتری بالاتر از قرارداد کاری
نرم افزار نمیتواند مثل یک جنس سفارش داده شود. شما نمیتوانید یک توصیف از نرم افزاری که میخواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده میکند، بسازند. اما این تعامل به کیفیت پایین نرم افزار و در نهایت شکست آن میانجامد. پروژههای موفق بر اساس دریافت بازخورد مشتری در بازههای زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به طور تنگاتنگ با تیم توسعه کار کرده و مرتبا اعمال نظر میکند.
قراردادی که مشخص کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساسا نقص دارد. بهترین قرارداد این است که تیم توسعه و مشتری با یکدیگر کار کنند.
پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم افزاری است. وقتی که طرحی را میریزیم باید مطمئن شویم که به اندازه کافی انعطاف پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد.
مسیر یک پروژه نرم افزاری نمیتواند برای بازه زمانی طولانی برنامه ریزی شود. اولا احتمالا محیط تغییر میکند و باعث تغییر در نیازمندیها میشود. ثانیا همین که سیستم شروع به کار کند مشتریان نیازمندیهای خود را تغییر میدهند. بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمیکنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.
یک استراتژی خوب برای برنامه ریزی این است که یک برنامه ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه ریزی کلی برای سه ماه بعد.
اصول چابک
۱- بالاترین اولویت ما عبارت است از راضی کردن مشتری با تحویل سریع و مداوم نرم افزار با ارزش. تحویل نرم افزار با کارکردهای کم در زود هنگام بسیار مهم است چون هم مشتری چشم اندازی از محصول نهایی خواهد داشت و هم مسیر کمتر به بیراهه میرود.
۲- خوش آمدگویی به تغییرات حتی در انتهای توسعه. اعضای تیم چابک، تغییرات را چیز خوبی میبینند زیرا تغییرات به این معنی است که تیم بیشتر یاد گرفته است که چه چیزی مشتری را راضی میکند.
۳- تحویل نرم افزار قابل استفاده از چند هفته تا چند ماه با تقدم بر تحویل در دوره زمانی کوتاهتر. ما مجموعه از مستندات و طرحها را به مشتری نمیدهیم.
۴- افراد مسلط به بیزنس و توسعه دهندگان باید روزانه با یکدیگر روی پروژه کار کنند. یک پروژه نرم افزاری نیاز به هدایت مداوم دارد.
۵- ساخت پروژه را بر توان افراد با انگیزه بگذارید و به آنها محیط و ابزار را داده و اعتماد کنید. مهمترین فاکتور موفقیت افراد هستند، هر چیز دیگر مانند فرآیند، محیط و مدیریت فاکتورهای بعدی محسوب میشوند که اگر تاثیر بدی روی افراد میگذارند، باید تغییر کنند.
۶- بهترین و موثرترین روش کسب اطلاعات در تیم توسعه، ارتباط چهره به چهره است. در تیم چابک افراد با یکدیگر صحبت میکنند. نامه نگاری و مستند سازی فقط زمانی که نیاز است باید صورت گیرد.
۷- نرم افزار کار کننده معیار اصلی پیشرفت است. پروژههای چابک با نرم افزاری که در حال حاضر نیازهای مشتری را پاسخ میدهد، سنجیده میشوند. میزان مستندات، حجم کدهای زیر ساخت و هر چیز دیگری غیره از نرم افزار کار کننده معیار پیشرفت نرم افزار نیستند.
۸- فرآیندهای چابک توسعه با آهنگ ثابت را ترویج میدهد. حامیان، توسعه دهندگان و کاربران باید یک آهنگ توسعه ثابت را حفظ کنند که بیشتر شبیه به دو ماراتون است یا دوی ۱۰۰ متر. آنها با سرعتی کار میکنند که بالاترین کیفیت را ارائه دهند.
۹- توجه مداوم به برتری تکنیکی و طراحی خوب منجر به چابکی میگردد. کیفیت بالاتر کلیدی برای سرعت بالا است. راه سریعتر رفتن این است که نرم افزار تا جایی که ممکن است پاک و قوی نگهداریم. بنابراین همه اعضای تیم چابک تلاش میکنند که با کیفیتترین کار ممکن را انجام دهند. آنها هر آشفتگی را به محض ایجاد برطرف میکنند.
۱۰- سادگی هنر بیشینه کردن مقدار کاری که لازم نیست انجام شود، است. تیم چابک همیشه سادهترین مسیر که با هدف آنها سازگار است را در پیش میگیرند. آنها وقت زیادی روی مشکلاتی که ممکن است فردا رخ دهد، نمیگذارند. آنها کار امروز را با کیفیت انجام داده و مطمئن میشوند که تغییر آن در صورت بروز مشکلات در فردا، آسان خواهد بود.
۱۱- بهترین معماری و طراحی از تیمهای خود سازمان ده بیرون میآید. مدیران، مسئولیتها را به یک فردی خاصی در تیم نمیدهند بلکه بر عکس با تیم به صورت یک نیروی واحد برخورد میکنند. خود تیم تصمیم میگیرد که هر مسئولیت را چه کسی انجام دهد. تیم چابک با هم روی کل جنبههای پروژه کار میکنند. یعنی یک فرد خاص مسئول معماری، برنامه نویسی، تست و غیره نیستند. تیم، مسئولیتها را به اشتراک گذاشته و هر فرد بر کل کار تاثیر دارد.
۱۲- در بازهای زمانی مناسب تیم در مییابد که چگونه میتواند کاراتر باشد و رفتار خود را متناسب با آن تغییر دهد. تیم میداند که محیط دائما در حال تغییر است، بنابراین خود را با محیط تغییر میدهد تا چابک بماند.
ضرورت توسعه چابک
امروزه صنعت نرم افزار دارای سابقه بدی در تحویل به موقع و با کیفیت نرم افزار است. گزارشات بسیاری تایید میکنند که بیش از ۸۰ درصد از پروژههای نرم افزاری با شکست مواجه میشوند؛ در سال ۲۰۰۵ موسسه IEEE برآورد زده است که بیش از ۶۰ بیلیون دلار صرف پروژههای نرم افزاری شکست خورده شده است. عجب فاجعهای؟
شش دلیل اصلی شکست پروژههای نرم افزاری
وقتی که از مدیران و کارکنان سوال میشود که چرا پروژههای نرم افزاری با شکست مواجه میشوند، آنها به موضوعات گسترده ای اشاره میکنند. اما شش دلیل زیر بارها و بارها تکرار شده است که به عنوان دلایل اصلی شکست نرم افزار معرفی میشوند:
۱- درگیر نشدن مشتری
۲- عدم درک درست نیازمندها
۳- زمان بندی غیر واقعی
۴- عدم پذیریش و مدیریت تغییرات
۵- کمبود تست نرم افزار
۶- فرآیندهای غیر منعطف و باد دار
چگونه چابکی این مشکلات را رفع میکند؟
با آنکه Agile برای هر مشکلی راه حل ندارد ولی برای مسائل فوق بدین صورت کمک میکند:
مشتری پادشاه است!
برای رفع مشکل عدم همکاری کاربر نهایی یا مشتری، Agile مشتری را عضوی از تیم توسعه میکند. به عنوان عضوی از تیم، مشتری با تیم توسعه کار میکند تا مطمئن شود که نیازمندها به درستی برآورده میشوند. مشتری همکاری میکند در شناسایی نیازمندیها، تایید میکند نتیجه نهایی را و حرف آخر را در اینکه کدام ویژگی به نرم افزار اضافه شود، حذف شود و یا تغییر کند، را میزند.
نیازمندیها به صورت تستهای پذیرش[۳] نوشته میشوند
برای مقابله با مشکل عدم درک درست نیازمندیها، Agile تاکید دارد که نیازمندیهای کسب شده باید به صورت ویژگیهایی تعریف شوند که بر اساس معیارهای مشخصی قابل پذیرش باشند. این معیارهای پذیرش برای نوشتن تستهای پذیرش به کار میروند. به این ترتیب قبل از اینکه کدی نوشته شود، ابتدا تست پذیرش نوشته میشود. این بدین معنی است که هر کسی باید اول فکر کند که چه میخواهد، قبل از اینکه از کسی بخواهد آن را انجام دهد. این راهکار فرایند کسب نیازمندیها را از بنیاد تغییر میدهد و به صورت چشم گیری کیفیت برآورد و زمان بندی را بهبود میدهد.
زمانبندی با مذاکره بین تیم توسعه و سفارش دهنده تنظیم میشود
برای حل مشکل زمان بندی غیر واقعی، Agile زمان بندی را به صورت یک فرآیند مشترک بین تیم توسعه و سفارش دهنده تعریف میکند. در شروع هر نسخه از نرم افزار، سفارش دهنده ویژگیهای مورد انتظار را به تیم توسعه میگوید. تیم توسعه تاریخ تحویل را بر اساس ویژگیها برآورد میزد و در اختیار سفارش دهنده قرار میدهد. این تعامل تا رسیدن به یک دیدگاه مشترک ادامه مییابد.
هیچ چیزی روی سنگ حک نشده است، مگر تاریخ تحویل
برای رفع مشکل ضعف در مدیریت تغییرات، Agile اصرار دارد که هر کسی باید تغییرات را بپذیرد و نسبت به آنها واقع بین باشد. یک اصل مهم Agile میگوید که هر چیزی میتواند تغییر کند مگر تاریخ تحویل! به عبارت دیگر همین که محصول به سمت تولید شدن حرکت میکند، مشتری (در تیم محصول) میتواند بر اساس اولویتها و ارزشهای خود ویژگیهای محصول را کم یا زیاد کرده و یا تغییر دهد. به هر حال او باید واقع بین باشد. اگر او یک ویژگی جدید اضافه کنید، باید تاریخ تحویل را تغییر دهد. به این ترتیب همیشه تاریخ تحویل رعایت میگردد.
تستها قبل از کد نوشته میشوند و کاملا خودکار هستند
برای رفع مشکل کمبود تست، Agile تاکید میکند که ابتدا باید تستها نوشته شوند و همواره ارزیابی گردند. هر برنامه نویس باید اول تست را بنویسد، سپس کد لازم برای پاس شدن آن را. همین که کد تغییر میکند باید تستها دوباره اجرا شوند. در این راهکار، هر برنامه نویس مسئول تستهای خود است تا درستی برنامه از ابتدا تضمین گردد.
مدیریت پروژه یک فعالیت جداگانه نیست
برای رفع مشکل فرآیندهای غیر منعطف و باددار، Agile مدیریت پروژه را درون فرآیند توسعه میگنجاند. وظایف مدیریت پروژه بین اعضای تیم توسعه تقسیم میشود. برای مثال هر ۷ نفر در تیم توسعه نرم افزار (متدلوژی اسکرام) زمان تحویل را با مذاکره تعیین میکنند. همچنین کد برنامه به صورت خودکار اطلاعات وضعیت پروژه را تولید میکند. به عنوان مثال نمودار burndown ، تستهای انجام نشده، پاس شده و رد شده به صورت خودکار تولید میشوند.
به کار گیری توسعه چابک
یکی از مشکلات توسعه چابک این است که شما اول باید به خوبی آن را درک کنید تا قادر به پیاده سازی درست آن باشید. این درک هم باید کلی باشد (مانند Scrum و XP) و هم جزئی (مانند TDD و جلسات روازنه). اما چگونه باید به این درک برسیم؟ کتابها و مقالات انگلیسی زیادی برای یادگیری توسعه چابک و پیاده سازی آن در سازمان وجود دارند، ولی متاسفانه منابع فارسی کمی در این زمینه است. هدف این کتاب رفع این کمبود و آموزش عملی توسعه چابک و ابزارهای پیاده سازی آن است.
برای این یک توسعه دهنده چابک شوید، باید به مهارتهای فردی و تیمی چابک برسید. در ادامه این مهارتها معرفی میشوند.
مهارتهای فردی
قبل از هر چیز شما باید یک برنامه نویس باشید و مقدمات برنامه نویسی مانند الگوریتم و فلوچارت، دستورات برنامه نویسی، کار با متغیرها، توابع و آرایهها را بلد باشید. پس از تسلط به مقدمات برنامه نویسی میتوانید مهارتهای برنامه نویسی چابک را فرا بگیرید که عبارتند از:
- برنامه نویسی شیءگرا
- توسعه تست محور
- الگوهای طراحی
در ادامه نحوه کسب این مهارتها بیان میشوند.
برنامه نویسی شیءگرا
اساس طراحی چابک بر تفکر شیءگرا استوار است. بنابراین تسلط به مفاهیم و طراحی شیءگرا ضروری است.
توسعه تست محور
مهمترین و انقلابیترین سبک برنامه نویسی از دهه گذشته تا به امروز، توسعه یا برنامه نویسی تست محور است. این سبک بسیاری از ارزشهای توسعه چابک را فراهم میکند و یادگیری آن برای هر توسعه دهنده چابک ضروری است.
الگوهای طراحی
الگوهای طراحی راه حلهای انتزاعی سطح بالا هستند. این الگوها بهترین تکنیکهای[۴] طراحی نرم افزار هستند و بسیاری از مشکلاتی که در طراحی نرم افزار رخ میدهند با استفاده از این الگوها قابل حل هستند.
مهارتهای تیمی
انجام پروژه نرم افزاری یک کار تیمی است. شما پس از یادگیری مهارتهای فردی باید خود را آماده حضور در تیم توسعه چابک کنید. برای این منظور باید با مهارت تیمی مانند آشنایی با گردشکار تولید نرم افزار، حضور موثر در جلسات، قبول مسئولیتها و غیره آشنا شوید.
اسکرام
تمامی مهارتهای تیمی توسعه چابک توسط اسکرام آموزش داده میشوند. اسکرام فریم ورکی برای توسعه چابک است که با تعریف فرآیندها، نقشها و آرتیفکتهای مشخص به تیمهای نرم افزاری کمک میکند تا چابک شوند.
[۱] Artifact : خروجی یک فرآیند است. مثلا خروجی طراحی شیءگرا، نمودارهای UML است.
[۲] Agile Alliance
[3] Acceptance Tests
با توجه به آخرین نگارشهای موجود Angular و React، انتخاب شما برای انجام یک پروژه بزرگ کدام است؟
- محبوبیت و پرطرفداری در بازار کار ( سمت مشتری یا اذهان عمومی )
- تعداد افراد و نیروی کار و در دسترس بودن آنها
- راحتی راه اندازی و پشتیبانی در توسعه
- قابلیتهای رقابتی فریمورک
چیزی که خیلی از مدیر پروژهها و برنامه نویسها به آن احتیاج دارند
MBTI برای هر مدیر پروژه ای و هر سرپرست تیم نرم افزاری ای میتونه مفید باشه
همچنین اگر مسئول سرو کله زدن با مشتری هم باشد
www.iranmbti.ir
راهنمایی در مورد تحلیل محصول و قیمت
آقای ربال ، ببینید در مورد محصول و قیمت درست متوجه شدم ؟
یک رابطه یک به چند بین محصول و قیمت وجود دارد که یکی از مزیتهای این میتونه نمودار بالا پایین تغییرات قیمت محصول باشه . آیا آخرین قیمت رو شما در جدول Product ذخیره میکنید ؟ به نظر شما بهتر است در جدول Product ذخیره شود و یا در جدول Price ؟
ممنون
- شماره تلفن، به صورت رشته کاراکتری
- آدرس، به عنوان رشته کاراکتری
- نام مسئول رسیدگی به تیکت، به صورت رشته کاراکتری
اما بعد از سپری شدن مدتی از توسعه محصول ممکن است اقلام اطلاعاتی خاصی بر روی هر یک از آیتمهای بالا نیاز شود. به طور مثال برای آدرس نیاز باشد اطلاعات استان و شهر جداگانه قابل ذخیره سازی و گزارش گیری باشند و یا در کنار نام مسئول رسیدگی به تیکت، شماره تلفن او نیز وجود داشته باشد.
در چنین شرایطی، یک اقدام ممکن، افزودن اقلام اطلاعاتی مورد نیاز در همان مکان آیتم قبلی است؛ به طور مثال اگر نام مسئول بر روی موجودیت تیکت باشد، شماره تلفن مسئول نیز در همان موجودیت تیکت اضافه شود.
راه حل مناسبتر برای حل این نوع مشکلات ایجاد کلاس خاص آیتم اطلاعاتی و استفاده از شیء آن بهجای مقدار مربوطه است. به طور مثال به طراحی زیر دقت نمایید. در طراحی زیر کلاس دیگری به نام Agent ایجاد و در کلاس تیکت از آن استفاده کردهایم.
این بازسازی کد دو مزیت کلی دارد:
- راه را برای توسعه آینده آیتمهای دادهای باز میکند
- از تکرار آیتمهای دادهای جلوگیری میکند (به طور مثال زمانیکه از پایگاه دادههای رابطهای جهت ذخیره سازی، استفاده شود)
داستانهای کاربر
توسعهدهندگان، ویژگیهای مورد نظر پروژه را با جمعآوری نیازمندیها، در قالب داستانهای کاربر احصاء میکنند و به هرکدام متناسب با پیچیدگیاش امتیازی اختصاص میدهند. با لیستی از داستانهای دارای ابعادی مشخص و بودجه و زمان مورد نیاز برای هرکدام، مشتریان قادر به این انتخابند که کدام ویژگیها در تکرار (iteration) بعدی باقی بماند. مشخصکردن بودجه و زمان، یعنی تعیین حجم کاری که تیم توسعه برای انجام آن ویژگی، نیاز میداند. برآورد بودجۀ مورد نیاز تکرار اول به صورت تجربی خواهد بود و ممکن است این تخمین در ابتدا نادرست باشد؛ اما با شروع تکرار بعدی درست خواهد شد. در پایان هر تکرار، امتیازات به دست آمده از داستانهای کامل شده را جمع کنید. مجموع این امتیازات، نشانگر سرعت شما خواهد بود. این سرعت شاخص خوبی جهت چگونگی بودجهبندی مرحلۀ بعد است. هنگامیکه امتیازات جمعآوری شده به حد مطلوبی رسید، «سرعت پیشرَوی»، شاخص مناسب دیگری برای بودجهبندی است که عبارت است از متوسط سرعت سه تکرار آخر.
با این کار شما به دیدگاه مناسبی از فاز برنامهریزی دست پیدا میکنید. حال اجاز دهید نگاه دقیقتری به شیوههای برنامهریزی داشته باشیم.
برنامهریزی (planning game) دو فاز دارد: فاز شناسایی و فاز برنامهریزی. در فاز شناسایی، توسعهدهندگان و مشتریان را دور هم جمع میکنند تا دربارۀ نیازمندیهای سیستم در حال طراحی، گفتگو کنند. به خاطر داشته باشید که این کار تا وقتی انجام میشود که به ویژگیهایی (features) کافی برای شروع انجام کار برسیم و البته واضح است که چنین لیستی از ویژگیهای احصاء شده، هرچقدر هم که تلاش شود، کامل نخواهد بود. مشتریان اغلب اوقات، خواستهی خود را یا نمیدانند یا نمیتوانند به خوبی توضیح دهند. بنابراین معمولاً این لیست به مرور تغییر میکند. در ضمن آنکه برخی ویژگیها دقیقتر میشود، مواردی نیز ممکن است به لیست افزوده شوند یا حتی میتوان برخی ویژگیهای نامربوط را از لیست حذف کرد. در مرحلۀ شناسایی، ویژگیها به داستانهای کاربر تجزیه شد و ثبت میشوند.
یک داستان کاربر عبارت است از توصیفی کوتاه از یک ویژگی که نمایانگر یک واحد ارزش کسب و کار برای مشتری است. داستانهای کاربر از زبان کاربر بیان شدهاند و قالب نوشتاری زیر را دارند:
به عنوان «نوع کاربر»، من میخواهم «یک فعل» تا «منفعتی برای کسب و کار»
یا به صورت:
به منظور «یک دلیل» به عنوان «نقش کاربر» من میخواهم «یک فعل»
داستانهای کاربر معمولاً در جلسهی گفتگو با مشتری بر روی کارتهای راهنما نوشته شده و در آن از واژگان و ادبیاتی استفاده میشود که برای مشتری قابل فهم باشد. ممکن است چنین بیاندیشید که ثبت نیازمندیها، خلاف مزیتهای چابکسازی است؛ چرا که تولید نرمافزار کارآمد و چابک مبتنی بر مستندسازی گسترده و فراگیر خواهد بود. در واقع، داستانهای کاربر به طور ساده فقط یادآورندۀ جزئیات بیشتری از گفتگوی انجام شدهاند که به عمد بهصورت کوتاه و دقیق نوشته شدهاند. فهم دقیقتر جزئیات کار، مستلزم ارتباط بیشتر میان توسعهدهندگان و مشتری است. در واقع همسو با این اصل چابک که میگوید: «مؤثرترین و کارآمدترین شیوۀ انتقال اطلاعات در میان تیم توسعه و به خارج از آن، گفتگوی چهره به چهره است.»
هنگام احصاء ویژگیهای پروژه تحت عنوان داستانهای کاربری، از اصول INVEST (که پیشتر گفته شد) جهت کنترل مناسب بودن این داستانها استفاده کنید. شکل 2-3 مثالی از یک داستان کاربر را که توصیفکنندۀ ویژگی «افزودن یک بن تخفیف به سبد خرید» است، نشان میدهد. «تخفیف گرفتن»، یک منفعت کسب و کار است برای عامل (actor) اصلی، یعنی مشتری. «یک بن تخفیف به سبد بیفزا» نام فرآیند یا «use case» مربوط است.
معیار پذیرش همچنین به تشخیص جزئیات بیشتر یا شناسایی وابستگیها کمک میکند. مثلاً در شکل 3-3 تعریف «in date» چیست و چه چیزی حدود یک بن تخفیف را مشخص میکند؟ معمولاً باید حداقل سه معیار پذیرش وجود داشته باشد. در فصل بعد در یک مطالعۀ موردی، مطالب بیشتری را دربارۀ داستانهای کاربر خواهید آموخت.
هنگامیکه تیم و مشتریان حسکنند که حدود 75 درصد از ویژگیهای اصلی احصاء شده است، توسعهدهندگان ابعاد داستانها را تخمین زده و آنها را برای اولویتبندی توسط مشتری آماده میکنند.
تخمین
شکی در آن نیست که تخمینزدن کار سختی است. تخمینزدن هم دانش است هم هنر. تخمینزدن در یک پروژۀ تازه شروع شده، بسیار سخت است زیرا مجهولات بسیاری در آن وجود دارد.
یکی از روشهای تخمین گروهی، روش «Planning Poker» نام دارد. در این روش همهی اعضای فنی تیم، متشکل از توسعهدهندگان نرمافزار، تحلیلگران، متخصصان امنیت و زیرساخت، مشارکت میکنند. نقش مشتری در این حالت پاسخگویی به سؤالات احتمالی اعضای تیم است تا ایشان بهتر بتوانند تخمین بزنند.
شیوۀ انجام کار به این صورت است که عضوی از تیم، یک داستان کاربر را برداشته و آن را برای تیم توضیح میدهد. تیم دربارۀ آن ویژگی با مشتری گفتگو کرده تا جزئیات بیشتری را دریابد. وقتی که تیم به درک خوبی از آن رسید، رأیگیری آغاز میشود. هر عضو تیم با یک کارت، از مجموعهای ازکارتهایی با شمارههای 0، 1 ، 2، 3، 5، 8، 13، 20، 40 و 100 رأی خود را اعلام میکند.
تیم باید از داستانی شروع کند که نسبتاً کوچک و ساده باشد. این داستان به عنوان مبنا انتخاب میشود. هر تخمین داستان کاربر، باید به نسبت این داستان کوچک انجام شود. اگر داستان مبنا به خوبی انتخاب نشود، بقیۀ تخمینها نادرست خواهد بود.
اگر همهی اعضای تیم به یک صورت رأی دهند، آن رأی، تخمین آن داستان خواهد شد. اگر اختلاف آراء وجود داشت، ناظر یعنی کسی که رأی نمیدهد، از افرادی که بالاترین و پایینترین امتیاز را دادهاند، میخواهد که علل خود را توضیح دهند. سپس تیم مجدداً گفتگو کرده و دوباره رأیگیری میکند. طبق تجربه، خوب است که زمان معقولی، برای هر گفتگو در نظر گرفته شود.
اگر تخمین یک داستان به دلیل فقدان دانش فنی، بسیار سخت بود، مناسب است که این داستان کنار گذاشته شود و داستان دیگری برای برطرف کردن مشکل ناآشنایی با دانش فنی مورد نظر فراهم شود. بدین ترتیب تیم توسعه در موقعیت بهتری میتواند نسبت به داستان جدید تخمین بزند.
داستانهایی که بیش از یک هفته کار نیاز داشته باشند با عنوان داستانهای حماسی (epic stories) شناخته میشوند و معمولاً برای تخمین بسیار بزرگ هستند. در واقع، این داستانها به چند داستان کوچکتر که قابل فهمتر و به آسانی قابل تخمین باشند، تجزیه میشوند. این بدان معناست که ایجاد یک داستان کاربر از تعداد انبوهی ویژگی موجب کاهش کارآیی خواهد شد.
تخمین در تیمی که افراد آن تاکنون با همدیگر سابقۀ همکاری نداشته باشند، خیلی پایین یا خیلی بالاست. اما با استمرار هر تکرار و تجربه و دانش بیشتر افراد، تخمین داستانها بهتر میشود.
استفاده از ابزار Planning Poker مزایای بسیاری دربردارد. دقت تخمین بالا میرود؛ زیرا مسأله از منظر تخصصهای گوناگون مورد بررسی قرار گرفته است. همچنین به تیم کمک میکند که هم رأی شوند و گفتگو میان اعضاء را تسهیل میکند. پس از آنکه داستانها تخمین زده شدند، مشتری و صاحب محصول با تیم توسعه در تولید چگونگی انتشار نسخهها، همکاری میکنند.
برنامه انتشار
اگرچه کدهای قابل ارسال، قابلیت انتشار در پایان هر تکرار را دارند، اما یک پروژه XP در چند سری منتشر شده است. یک نسخۀ منتشرشده، متشکل از تعداد مناسبی داستان برای عرضۀ ارزش کسب وکاری است که به کوچک نگه داشتن آن کمک میکند. بسیار مناسب است که یک موضوع یا هدف خاص را در ضمن هرنسخۀ انتشار، مد نظر قرار داد تا کمک کند که هر نسخۀ انتشار بر برخی ارزشهای کسب و کاری متمرکز شده و آن را هدایت کند. معمولاً یک نسخۀ انتشار، متشکل از چهار تکرار است؛ همانطور که در شکل 4-3 نشان داده شده است.
در برنامهریزی نسخههای انتشار، طول یک تکرار نیز تعیین میشود که معمولاً بین دو تا چهار هفته است. مطابق تجربه، اگر محیط کار شما دچار بینظمی و اختلالات دائمی است، میتوانید دورۀ تکرار را به یک هفته محدود کنید.
یکی از پروژههایی که ما بر روی آن کار میکردیم، برنامهای بود که نگهداری آن بسیار سخت و فوقالعاده ناپایدار بود. مشتری مکررا با تیم تماس گرفته و اشکالات بحرانساز و ایراداتی را که مخل برنامه بودند، گزارش میکرد. در ابتدای کار دوره، تکرار ما هفتگی بود. به همین دلیل چون حلقۀ بازخوردگیریمان کوچک بود، میتوانستیم بر پایدارسازی پروژه در هر دوره کاری تمرکز کنیم. هنگامی که محصول به پایداری مناسبتری رسید و تماسهای مشتری کم شد، قادر شدیم تا در هر دوره، دقت بیشتری بر روی مسائل به خرج دهیم.
اگر قصد دارید به صورت دقیق بر روی حلقۀ بازخورد متمرکز شوید، دورهی تکرار یک هفتهای، مدل خوبی است. اما این مدل سربار زیادی را به دلیل ضرورت تقسیم داستانهای کاربر باید به بخشهای کوچکتری تا آن اندازه که در یک دوره تکمیل شوند، بر پروژه تحمیل میکند. در ادامه خواهیم گفت که هر تکرار شامل برنامۀ ملاقات و بازبینی نیز هست.
بعد از مدتی که تیم با فرآیند کار آشناتر شد و نوبت به مشکلات با اولویت کمتر رسید، میتوان دورۀ تکرار را دو هفتهای در نظر گرفت. اما اگر پروژه به گونهای است که ویژگیهای بزرگتر را نمیتوان به موارد کوچکتری که قابل انجام در دورههای یک هفتهای باشد، تجزیه کرد و تیم هنوز در حال یادگیری است، دورههای بلندمدتتر قابل پذیرش است.
مشتری با توجه به طول دورۀ تکرار و بودجۀ داستان آغازین، انتخاب میکند که کدام داستان در هنگام انتشار نسخۀ اوّل، در تکرار اوّل کامل شود.
این مشتری است که داستانها را به گونهای اولویتبندی میکند تا مشخص شود که کدامیک بیشترین ارزش کسب و کار را فراهم میکند. از آنجایی که مشتری مسؤول داستانهای کاربر است، تیم باید به وی توضیح دهد که داستانهایی وجود دارند که صرفاً باید به جهت دلایل فنی ایجاد شوند.
معمولاً باید به داستانهای کاربریای که مستلزم ریسک بالا بوده یا دربرگیرندۀ مجهولات زیادی باشند، بیش از یک یا دو تکرار اختصاص داد.
برنامۀ تکرار
مشتری داستانهایی را که میخواهد در تکرار باشند، انتخاب میکند. برای هر داستان کاربر، مجموعهای از معیارهای پذیرش، تعریف شده است. همان طور که متوجه شدهاید ما در هر فاز، وقت بیشتر و بیشتری را صرف جمعآوری جزئیات هر داستان کاربر کرده و بصورت عمیقتری در آن غور میکنیم. این کار مفید است، زیرا اگر یک داستان کاربر ایجاد شده در ابتدای پروژه، ممکن است بعداً به عنوان داستانی کم اهمیت یا غیر مهم دیدهشود و بدون آنکه وقت خاصی برای آن صرف شده باشد، کنار گذاشته شود. اما اگر در ابتدای کار وقت زیادی صرف دقیقتر کردن داستانهای کاربر شود و بعداً بعضی از آنها کنار گذاشته شوند، در واقع وقت تلف شده است. بنابراین دقیقتر کردن یک داستان در جایی که مورد نیاز است، باید اتفاق بیفتد. در سطح برنامۀ تکرار، مجموعهای از معیارهای پذیرش را برای هر داستان کاربر تعریف میکنیم. معیار پذیرش به توسعهدهنده کمک میکند تا بداند که یک داستان کاربر به طور کامل انجام میشود. این معیارها به صورت مؤلفههایی از بافرض/هنگامی که/درنتیجه، نوشته میشود.
مثالهای زیر چگونگی انجام این کار را توصیف میکند:
عنوان ویژگی: افزودن کالایی به سبد
به عنوان یک مشتری میخواهم بتوانم کالایی را به سبدم اضافه کنم؛ به نحوی که قادر باشم به خرید خود ادامه دهم.
سناریو: سبد خالی
با فرض اینکه یک سبد خالی دارم، در نتیجه جمع تعداد کالایی که برای سفارش در سبد من وجود دارد، صفر است.
سناریو: افزودن یک کالا به سبد
با فرض اینکه یک سبد خالی دارم هنگامی که کالایی با شناسۀ 1 به سبدم اضافه میکنم، در نتیجه جمع کالاهای قابل سفارش در سبدم 1 میشود.
سناریو: افزودن کالاهایی به سبد
با فرض اینکه یک سبد خالی دارم، هنگامی که کالایی با شناسۀ 1 و کالایی با شناسۀ 2 به سبدم اضافه میکنم، در نتیجه جمع کالاهای قابل سفارش در سبدم 2 میشود.
سناریو: دو بار افزودن یک کالا
با فرض اینکه یک سبد خالی دارم هنگامی که کالایی با شناسۀ 1 به سبدم اضافه میکنم و هنگامی که کالایی با شناسۀ 1 را مجدداً به سبدم اضافه میکنم، در نتیجه تعداد کالاهای با شناسۀ 1 در سبد من باید 2 باشد.
سناریو: افزودن یک کالای تمام شده به سبد
با فرض اینکه یک سبد خالی دارم و کالایی با شناسۀ 2 در انبار وجود نداشته باشد، هنگامی که من کالایی با شناسۀ 2 را به سبد خودم اضافه میکنم، در نتیجه جمع تعداد کالای قابل سفارش در سبد من باید 0 باشد و به کاربر، موجود نبودن آن کالا را هشدار دهد.
یک آزمون پذیرش (acceptance) به زبان متعارف در قوانین کسب و کار نوشته میشود. در مثال سبد خرید، این سؤال پیش میآید که چگونه میتوان یک محصول را از سبد کالا، حذف کرد و اگر یک جنس اکنون در انبار نیست و کاربر پیام هشدار دریافت کرده است، در ادامه چه اتفاقی باید بیفتد؟ سناریوها به تیم در کشف ملزومات کسب و کار و تصریح آنها کمک میکند.
این سناریوها توسط توسعهدهنده به عنوان نقطۀ شروع آزمونهای واحد در توسعۀ آزمون محور و رفتار محور استفاده میشود. سناریوها همچنین در آزمودن معیارهای پذیرش به توسعهدهنده کمک کرده و توسعهدهنده و تستکننده را قادر میسازند که بر روی اتمام داستان اتفاق نظر داشته باشند.
بعد از آنکه سناریوهای معیار پذیرش تعیین شد، تیم توسعه، هر داستان را به تعدادی وظیفه تقسیم میکند و وظایف مرتبط به یک داستان، در تابلوی وظایف قرارگرفته و تیم توسعه تخمینهای خود را در قالب یکی از واحدهای اندازهگیری، مثلاً نفرساعت اعلام میکند. شکل 5-3 یک تابلوی وظیفه را نمایش میدهد.
به عنوان مثال وظایف میتوانند شامل ایجاد طرح یک بانک اطلاعاتی برای یک داستان یا یکپارچهسازی آن با بخشی موجود در سیستم باشند. وظایف شامل مؤلفههای فنی مانند تهیۀ گزارش از زیرسیستمها یا چارچوب مدیریت استثنائات نیز میباشد. اغلب اینگونه وظایف نادیدهگرفته میشود. یک داستان کاربر با وظایف گوناگونی گره خورده است. مثلاً:
داستان کاربر : به عنوان یک کاربر میخواهم بتوانیم یک کاربر را مدیریت کنم.
وظایف زیر از این داستان قابل استخراج است:
- طرحی برای بانک اطلاعات جهت ذخیرهسازی اطلاعات کاربر ایجاد کن.
- یک کلاس کاربر، برای مدیریت کاربر از درون برنامه ایجاد کن.
هر عضو تیم میتواند بر روی هر وظیفهای که بر روی تخته است، کار کند. هنگامیکه یک عضو گروه، وظیفهای را برمیدارد، باید نشانی از خود روی کارت آن وظیفه قراردهد ( مثلاً حروف اوّل اسمش) تا بقیۀ افراد بدانند که وی بر روی آن وظیفه، مشغول به کار است. معمولاً اما نه همیشه، یک توسعهدهنده همۀ وظایف مربوط به یک داستان را برمیدارد. این کار بدین معناست که آن توسعهدهنده با پشتیبانی تیم، مسؤول اتمام آن کار است.
در طول یک تکرار، هر روز باید گفتگوهایی سرپایی با حضور همۀ اعضای تیم انجام شود و مشکلاتی که ممکن است باعث به تأخیر افتادن ارائه کار شود، مورد بحث و بررسی قرار گیرد و همچنین تیم، لیست وظایف و تخته آن را بهروز کرده تا پیشرفت یا موانع آن به وضوح قابل رؤیت باشند.
با تشکر از آقای سید مجتبی حسینی
var image = document.createElement("img"); image.setAttribute("src", "logo.png"); React.createElement("img", { src : "logo.png" });
Virtual DOM
تفاوت در ساخت تگهای HTML به صورت مجازی بین JavaScript و React این است که React وضعیت تگهایی را که میسازد دنبال میکند. برای مثال فرض کنید نام سه محصول را در یک تگ < ul > نشان دادهایم. React وضعیت اصلی این تگ را که به مرورگر فرستاده، در حافظه دارد و همچنین در اثر تغییر منبع دادهای که برای < ul > مشخص کردهایم (که میتواند ورود اطلاعات به صورت Ajax باشد (مثلا اضافه شدن یک محصول جدید)) وضعیت جدیدی را برای تگ < ul > در حافظه ایجاد میکند. با وجود دو وضعیت برای یک تگ در حافظه، React میتواند تفاوت بین آنها را تشخیص داده و تگ را به روز کند. به این حالت عملکرد React ، اصطلاحا Virtual DOM میگویند.
React رابط کاربری را به صورت یک مدل میبیند و این مدل را با توجه به وضعیت اصلی آن در حافظه دوباره میسازد. برای React مهم نیست که ماهیت تغییر چیست. فقط وضعیتها را مثل دو عکس میبیند و میفهمد که آیا چیزی عوض شدهاست یا نه. دیالوگ React با مرورگر اینطور است: ای تگ < ul > این لیست را نشان بده (لیستی با سه محصول)، و بعد میگوید: ای تگ < ul > این لیست را نشان بده (لیستی با چهار محصول)!
کامپوننتهای React
<a href = “http://google.com”> <img src=”google.png”/> </a> // Components <clickableimage/> <linkimage/>
در کد بالا، بخش اول واضح است. عکسی که قابلیت کلیک شدن را دارد. حال فرض کنید یکی از کامپوننتهای <clickableimage/> یا <linkimage/>، همان تصویر قابل کلیک را ایجاد کنند. با نام گذاری واضح کامپوننتها، خوانایی برنامه بهتر میشود. یعنی میدانیم هر کامپوننت چه کاری را برای ما انجام میدهد. با این تصور که اگر تگهای زیاد و طولانی را در بخش رابط کاربری داریم، ارزش استفاده از کامپوننتهای React مشخص میشود.
قابلیت استفاده مجدد
در React کامپوننتها برای اساس توابع ساخته میشوند. یعنی وقتی یک کامپوننت را صدا بزنیم، در واقع یک تابع را اجرا میکنیم. در نتیجه کامپوننتها رفتار توابع را دارند؛ ورودی میگیرند و خروجی که یک DOM مجازی است را تحویل میدهند. اگر تابعی که مسئول ساخت کامپوننت است وابستگی به توابع یا متغیرهای بیرونی نداشته باشد، میتواند در جای دیگری از برنامه یا برنامهای دیگر مجددا استفاده شود. کد زیر نشان میدهد که چطور کامپوننتهای React ساخته میشوند.var ClickableImage = function(props) { return ( <a href={props.href}> <img src={props.src} /> </a> ); }; ReactDOM.render( <ClickableImage href="http://google.com" src="logo.png" />, document.getElementById("targetDivId"));
اپل به تازگی هدست AR/VR خود را با نام Apple Vision Pro عرضه کرده است.
اپل یک هدست واقعیت افزوده به نام Apple Vision Pro را معرفی کرده است که "به طور یکپارچه" دنیای واقعی و دیجیتال را با هم ترکیب میکند.
تیم کوک، مدیر عامل شرکت اپل در مورد این دستگاه که شبیه یک عینک اسکی به نظر میرسد، گفت: «این اولین محصول اپل است که شما از طریق آن نگاه میکنید و نه همانطور که شایعه شده است، دارای یک بسته باتری جداگانه است و با چشم، دست و صدا کنترل میشود. قیمت آن از 3499 دلار شروع میشود و اوایل سال آینده عرضه میشود و در بازار ایالات متحده با کشورهای بیشتری در اواخر سال عرضه میشود.