بیان مناسب داستانهای کاربری، کار ساده ای نیست. گاهی نویسندگان داستانهای کاربری در دام داستانهای کاربری بزرگ گرفتار می شوند. داستانهای کاربری بزرگ ، باعث ایجاد مشکلاتی در سطح برنامه ریزی، اجرا و تحویل می شوند و قاعده INVEST را مکررا نقض می کنند. اما چه کنیم که داستانهای کاربری بزرگ را به داستانهایی کوچکتر تقسیم کنیم؟ نوشتار زیر 15 پیشنهاد است برای همین منظور.
قبل از پاسخ به این سوال مختصرا توضیح میدهم که DDD رویکردی برای طراحی و مدل سازی دامینهای پیچیده است. دامینهایی که نیازمندیها در ابتدای پروژه شفاف نیستند و به مرور و به واسطهی کسب آموختههای جدید، کشف و ظاهر میشوند.
هر چند در سالیان اخیر، توسعه به سبک چابک در بین توسعه دهندگان نرم افزار از اقبال بیشتری برخوردار شده است، اما کمتر دیدهام که مفاهیم و اصولی که میتوانند به یک تیم اجایل قدرت بیشتری بدهند، به اندازه کافی مورد بررسی و توجه قرار بگیرند و این باعث میشود که متدولوژیهای چابک، به تدریج ناکارآمد جلوه کنند و به یک شیر بی یال و دم تبدیل شوند.
استفاده از پیشنهادهای Domain Driven Design در مدلسازی و توسعه محصول در دامین های پیچیده، از موضوعاتی است که میتواند یک تیم اجایل را اجایلتر کند و به تقویت میزان پایداری به اصول و شاخصهای چابکی در تیم، بیانجامد. ولی چگونه؟ فرهنگ و زمینههای فکری چابکی، با فضای فکری DDD چه خویشاوندی دارند؟ ارتباط آنها چیست؟
در جلسهی برنامهریزی اسپرینت (Sprint Planning)، اعضای تیم تعدادی از آیتمهای سبد محصول (Product Backlog) را به ترتیب اولویت برای کار در اسپرینت بعدی انتخاب میکنند. در همین جلسه، بسیاری از تیمها وظایفی را که برای تکمیل هر آیتم (Product Backlog Item) ضروری است، مشخص میکنند و در همان جلسه با ذکر نام تعیین میکنند که هر فرد چه کاری را باید انجام دهد.
علاوه بر این، خیلی از تیمها مقدار تلاش (Effort) مورد نیاز برای انجام هر وظیفه را هم مشخص میکنند. نهایتاً آنچه که به عنوان بکلاگ اسپرینت (Sprint Backlog) به دست میآید چیزی شبیه جدول زیر خواهد بود:
امروزه "مدیریت ذره بینی" به شیوه ای از مدیریت تبدیل شده که فریاد خیلی ها را به آسمان بلند کرده و از آن گریزانند. اگر نمی دانید مدیریت ذره بینی چیست این جا را بخوانید اما به طور خلاصه این سبکی از مدیریت است که مدیر، نظارت و کنترل دقیق و موشکافانهای بر عملکرد کارمندان و مجموعهی تحت مدیریت خود دارد. معمولاً هم مدیریت ذره بینی و چابکی را دو سر متضاد یک طیف میدانند و معتقدند که این دو سبک مدیریت در تضاد با هم قرار دارند. اما در واقع این دو سبک مدیریت بسیار بیشتر از آنچه که به نظر میرسد، خویشاوند و نزدیکاند.
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
پرسش یک توسعه دهنده: رفتار استاد اسکرام (Scrum Master) با ما کاملاً مثل رفتار مدیران است و فرقی نکرده. بیشتر کارهای ما زیر ذره بین او قرار دارد. برگزاری جلسات و هماهنگیها با اوست و تقسیم وظایف را هم خودش انجام میدهد. قبل از اسکرام هم، کارها به همین شکل انجام میشد. مگر نه اینکه اسکرام به "تیم" و فعالیت تیمی اهمیت میدهد؟
اگر بپذیریم که افراد و تعاملات آنها در میزان موفقیت کار تیمی، مهم و اثر گذار است، آنگاه لازم است تا تعاملات و ارتباطات درون تیمی و فرا تیمی را بشناسیم و وضعیت موجود را ارزیابی کنیم. در این میان ارتباط مدیر/رییس/رهبر تیم با دیگر اعضای تیم از اهمیت فوق العادهای برخوردار است. در مطلب قبلی به تفاوت گروه و تیم اشاره کردم. اینجا میخواهم به تفاوت "رییس" و "رهبر" اشاره کنم.
رییس کارمندان را به جلو رفتن وادار میکند. <> رهبر مانند یک مربی، راه پیشرفت را به ایشان میآموزد.
بر مبنای اقتدار رفتار میکند. <> بر مبنای حسن نیت متقابل رفتار میکند.
رعب و ترس ایجاد میکند. <> شور و اشتیاق ایجاد میکند.
میگوید "من". <> می گوید "ما".
در هنگام اشتباه، سرزنش، ملامت و تنبیه میکند. <> اشتباه را تصحیح میکند.
میداند کار را چگونه باید انجام داد. <> چگونگی انجام کار را نشان میدهد.
کارمندان را به کار وادار میکند. <> کارمندان را در انجام کارهایشان توانمند میکند.
پاداش میگیرد. <> پاداش میدهد.
دستور میدهد. <> درخواست میکند.
میگوید بروید و انجامش دهید. <> میگوید برویم و انجامش دهیم.
بند اول بیانیه چابک بیان می کند که افراد و تعاملات آنها به نسبت ابزارها و فرآیندها از ارزش و اهمیت بیشتری برخوردارند.
“Individuals and interactions” over processes and tools.
برداشت من از این بند بیانیه: