آیا اسکرام مستر باید از مهارتهای فنی برخوردار باشد؟ چرا بعضی اوقات تیمها از اسکرام مستر حرف شنوی ندارند؟
از جمله ی مفاهیمی که در DDD مطرح شده است مفهومی است با عنوان Ubiquitous Language. معادل فارسی آن را می توانید به دلخواه از این موارد انتخاب کنید: "زبان فراگیر" ، "زبان عام"، "زبان مشترک" و یا "زبان غالب".انتخاب من "زبان مشترک" است. اما این اصطلاح دربرگیرنده چه مفهومی است و هدف از طرح آن در DDD چیست؟
در جلساتی که توسعه دهندگان نرم افزار با متخصصین حوزه کاری (Domain)، برگزار می کنند، طیف وسیعی از واژگان و اصطلاحات هم توسط توسعه دهندگان و هم توسط متخصصین دامین، بکار گرفته می شود. بسیار پیش آمده که هر چند هر دو گروه از واژه مشترکی استفاده می کنند، اما آن چیزی که در ذهنشان نسبت به آن واژه وجود دارد، متفاوت از یکدیگر است.
در جلساتی که توسعه دهندگان نرم افزار با متخصصین حوزه کاری (Domain)، برگزار می کنند، طیف وسیعی از واژگان و اصطلاحات هم توسط توسعه دهندگان و هم توسط متخصصین دامین، بکار گرفته می شود. بسیار پیش آمده که هر چند هر دو گروه از واژه مشترکی استفاده می کنند، اما آن چیزی که در ذهنشان نسبت به آن واژه وجود دارد، متفاوت از یکدیگر است.
بیان مناسب داستانهای کاربری، کار ساده ای نیست. گاهی نویسندگان داستانهای کاربری در دام داستانهای کاربری بزرگ گرفتار می شوند. داستانهای کاربری بزرگ ، باعث ایجاد مشکلاتی در سطح برنامه ریزی، اجرا و تحویل می شوند و قاعده 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.
برداشت من از این بند بیانیه:
- قبل از اینکه تصمیم بگیریم فرآیند را تصحیح کنیم یا تغییر دهیم، به بررسی این بپردازیم که تعاملات اعضای تیم به چه شکل است و آیا این تعاملات/ارتباطات/همکاری‌ها به نحو مطلوبی در جریان است یا خیر؟ ذره بین مدیران باید روی افراد، انگیزه‌ها و محرک‌های ایشان، مهارتهای کار تیمی و مطالعه الگوی ارتباط بین آنها قرار بگیرد.
- باور من این است که تا پیش از اینکه مطمئن شویم که کار تیمی را آموخته و قواعد آن را بلدیم و پایند آنیم، استفاده از فرآیندهای چابک و ابزارهای مدرن، دردی دوا نمی‌کند، بلکه بر پیچیدگی‌ها می‌افزاید.
- باید تیم بسازیم. حق انتخاب ابزار و فرآیند و مسئولیت استفاده از آن را می‌شود به تیم واگذار کرد.
۱۹
خرداد