تسکولو!
مدیریت پروژهها
مدیریت تیم
سطوح دسترسی
ساخت دیتابیس sqlite با EF6 Code First
PM> update-package
ب) همچنین رشتهی اتصالی آن باید به محل دقیق قرارگیری فایل phonebook.sqlite اشاره کند.
ج) نام بستههای موجود در فایل packages.config خودتان را با نمونهی پروژهی پیوستی مطابقت دهید.
این موارد را بررسی کنید؛ وگرنه EF 6x در حال توسعهی پیوسته نیست و تغییر خاصی از زمان نگارش این مطلب نداشتهاست.
+ اگر میخواهید نسخهی EF Core آنرا بررسی کنید:
- نیاز است سری EF Core را در سایت از ابتدا مطالعه کنید.
- VS 2015 دیگر برای کار با NET Core. مناسب نیست. حتما نیاز است VS 2017 را نصب کنید. اطلاعات بیشتر
- پیشنیازهای جدید کار با SQLite در فایل csproj آن برای VS 2017 و EF Core 1.1.1 به صورت ذیل هستند:
<Project Sdk="Microsoft.NET.Sdk.Web"> <ItemGroup> <PackageReference Include="Microsoft.EntityFrameworkCore" Version="1.1.1" /> <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.1.1" PrivateAssets="All" /> <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="1.1.1" /> <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite.Design" Version="1.1.1" /> <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="1.1.0" PrivateAssets="All" /> </ItemGroup> <ItemGroup> <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.*" /> </ItemGroup> </Project>
EF Code First #2
بنده طبق مثال مقاله پیش رفتم و متادیتاهای Key و Required را اضافه کردم اما با متادیتای MaxLength به مشکل خوردم .
ویژوال همچین پیغامی میده :
/* The type 'System.ComponentModel.DataAnnotations.MaxLengthAttribute' exists in both
'c:\Program Files\Microsoft ADO.NET Entity Framework 4.1\Binaries\EntityFramework.dll'
and
'c:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.ComponentModel.DataAnnotations.dll' */
stackoverflow ایرانی
ویژگیهای یک مایکرو سرویس چیست؟
Componentization via Services
Technology Heterogeneity
یک سیستم را در نظر بگیرید که از همکاری چندین سرویس تشکیل شدهاست. ما میتوانیم تصمیم بگیریم که برای هر کدام از سرویسها از تکنولوژی متفاوتی استفاده کنیم. این امر به ما اجازه میدهد برای حل هر مشکل، از بهترین ابزار و تکنولوژی استفاده کنیم. این امر بر خلاف سیستمهایی که تنها باید از تکنولوژی بکار رفته در سیستم استفاده کنند، انعطاف پذیری سیستم را بسیار بالا میبرد.برای روشن شدن موضوع فرض کنید میخواهیم در بخشی از سیستم، performance را افزایش دهیم. برای این امر میتوانیم از هر تکنولوژی که به ما کمک میکند، استفاده کنیم. برای نمونه در یک سیستم شبکه اجتماعی، میتوانیم اطلاعات مربوط به کاربران و ارتباطات آنها را در یک دیتابیس مبتنی بر گراف و اطلاعات مربوط به پستها و نظرات کاربران را در یک دیتابیس سندگرا ذخیره کنیم. به این ترتیب مشاهده میکنیم که وابستهی به تکنولوژی خاصی نمیباشیم و میتوانیم بر اساس نیاز خود، از تکنولوژی مورد نظر بهره ببریم.
مایکرو سرویسها به ما این اجازه را میدهند تا در انتخاب تکنولوژیها نهایت دقت را انجام دهیم و متوجه شویم که تکنولوژیهای جدید چگونه میتوانند به ما کمک کنند.
یکی از بزرگترین موانع در استفاده و انتخاب یک تکنولوژی جدید، ایجاد وابستگی سیستم به آن میباشد. در یک سیستم یکپارچه چنانچه قصد تغییر زبان مورد استفاده یا دیتابیس یا فریمورک مورد استفاده را داشته باشیم، سیستم هزینهی سنگینی را متحمل میشود. در حالیکه در مایکرو سرویسها میتوانیم این تغییرات را با کمترین هزینه انجام دهیم. البته باید توجه داشت که استفاده از تکنولوژی جدید چالشها و سربارهای خودش را دارد و انتخاب یک تکنولوژی جدید نیازمند بررسی کارشناسانه و دقیق میباشد.
Resilience
چنانچه یکی ازسرویسها دچار اشکال شود و این مسئله بصورت زنجیروار برای تمام سرویسها رخ ندهد، با جدا شدن آن سرویس، درروند کار سیستم خللی بوجود نمیآید و سیستم بدون کمترین مشکلی به ادامه کار خود میپردازد. یعنی محدوده یک سرویس، دیوار حائلی میشود تا سایر بخشها تاثیر نپذیرند. در سیستمهای یکپارچه چنانچه یک سرویس دچار اشکال شود، سایر بخشهای سیستم نیز غیر قابل استفاده میشوند. البته میتوان با نصب نسخههای متفاوتی بر روی ماشینهای متفاوت (Scale out)، تاثیر اینگونه اختلالات را تا حدودی کاهش داد. اما بوسیله مایکرو سرویسها میتوانیم سیستمهایی را بسازیم که قادرند با خطاهای بوجود آمده در سرویسها بهدرستی رفتار کنند؛ تا خللی در کار سیستم ایجاد نشود.Scaling
Gilt یک خرده فروش آنلاین در صنعت مد میباشد که بخاطر مسائل Performance به معماری مایکروسرویسها روی آورد. آنها در سال 2007 با یک نرم افزار یکپارچه شروع به کار کردند. اما بعد از دوسال سیستم آنها قادر به مقابله با ترافیک سایت نبود. آنها با تقسیم بندی قسمتهای اصلی سیستم خود به مایکرو سرویسها، توانستند خیلی بهتر و موثرتر با ترافیک رسیده مقابله کنند و قابلیت دسترسی پذیری سیستم را افزایش دهند. در حال حاضر سیستم آنها از حدود 450 مایکرو سرویس تشکیل شده که هر کدام روی چندین ماشین مختلف در حال اجرا میباشند.
Ease of Deployment
Organizational Alignment
Composability
Optimizing for Replaceability
EF Code First #1
- برای مثال خروجی کامل بحث Entity Framework در پوشهی Tags واقع شده: (^)
- بانک اطلاعاتی سایت هم برای دریافت موجود است؛ به همراه Viewer آن: (^)
- در پوشهی LearningPaths، خروجیهای اختصاصیتری تهیه شدهاند. برای مثال این خروجی اختصاصی و انتخابی EF Code First است: (^)
داستانهای کاربر
توسعهدهندگان، ویژگیهای مورد نظر پروژه را با جمعآوری نیازمندیها، در قالب داستانهای کاربر احصاء میکنند و به هرکدام متناسب با پیچیدگیاش امتیازی اختصاص میدهند. با لیستی از داستانهای دارای ابعادی مشخص و بودجه و زمان مورد نیاز برای هرکدام، مشتریان قادر به این انتخابند که کدام ویژگیها در تکرار (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 یک تابلوی وظیفه را نمایش میدهد.
به عنوان مثال وظایف میتوانند شامل ایجاد طرح یک بانک اطلاعاتی برای یک داستان یا یکپارچهسازی آن با بخشی موجود در سیستم باشند. وظایف شامل مؤلفههای فنی مانند تهیۀ گزارش از زیرسیستمها یا چارچوب مدیریت استثنائات نیز میباشد. اغلب اینگونه وظایف نادیدهگرفته میشود. یک داستان کاربر با وظایف گوناگونی گره خورده است. مثلاً:
داستان کاربر : به عنوان یک کاربر میخواهم بتوانیم یک کاربر را مدیریت کنم.
وظایف زیر از این داستان قابل استخراج است:
- طرحی برای بانک اطلاعات جهت ذخیرهسازی اطلاعات کاربر ایجاد کن.
- یک کلاس کاربر، برای مدیریت کاربر از درون برنامه ایجاد کن.
هر عضو تیم میتواند بر روی هر وظیفهای که بر روی تخته است، کار کند. هنگامیکه یک عضو گروه، وظیفهای را برمیدارد، باید نشانی از خود روی کارت آن وظیفه قراردهد ( مثلاً حروف اوّل اسمش) تا بقیۀ افراد بدانند که وی بر روی آن وظیفه، مشغول به کار است. معمولاً اما نه همیشه، یک توسعهدهنده همۀ وظایف مربوط به یک داستان را برمیدارد. این کار بدین معناست که آن توسعهدهنده با پشتیبانی تیم، مسؤول اتمام آن کار است.
در طول یک تکرار، هر روز باید گفتگوهایی سرپایی با حضور همۀ اعضای تیم انجام شود و مشکلاتی که ممکن است باعث به تأخیر افتادن ارائه کار شود، مورد بحث و بررسی قرار گیرد و همچنین تیم، لیست وظایف و تخته آن را بهروز کرده تا پیشرفت یا موانع آن به وضوح قابل رؤیت باشند.
با تشکر از آقای سید مجتبی حسینی