رویکردهای بازپرداخت بدهی فنی
قبلا صحبت کردیم که بک‌لاگ بدهی فنی چیست، در این رویکرد هنگام انتخاب اقلام توسط تیم و همراه مالک این تابلو کنار تابلو اقلام قرار میگیرد و هنگام انتخاب هر قلم با توجه به تابلوی بدهی اگر قلمی در تابلوی بدهی وجود داشته باشد که مرتبط با قلم انتخاب شده بک‌لاگ محصول باشد برویده و در کنار آن جهت رسیدگی گذاشته میشود و این یک رویکرد ساده جهت همسو سازی است. تصویر اول در کامنت
#scrum
@code_crafters
۱-نیازی به بازپرداخت همه بدهی‌های فنی نیست
همه بدهی‌های فنی نیازی به بازپرداخت ندارند و حتی ممکن به تعویق بیافتند در اینجا سه درباره سه مورد آن بحث میکنیم: اواخر عمر محصول، نمونه اولیه دور ریختنی و محصول ساخته شده برای کوتاه مدت
۲- اجرای قانون پیشاهنگی(بازپرداخت بدهی هنگام کشف اتفاقی آن)
در هنگام توسعه ویژگی جدید ممکن است یک بدهی کشف شود که سریع آن را پرداخت خواهیم کرد و دنبال دلیل و یا نفر آن نمیگردیم این سیستم کمک میکند بدهی کمتری داشته باشد، کا انتظار نداریم که سیستم بدهی نداشته باشد اما پایین نگه داشتن آن بسیار الزامی است، انتظار از نداشتن بدهی یا بازپرداخت کامل آن منحر میشود به هدف اسپرینت نرسیم. در اسکرام تیم توسعه دو رویکرد برای آن دارد، رویکرد اول این است برای امتیازدهی به هر یک از اقلام اندکی امتیاز بیشتر می‌دهیم که برای بازپرداخت بدهی فنی استفاده میشود، رویکرد دوم این است بین ۵تا۳۳ درصد از هر اسپرینت را به بازورداخت بدهی صرف کنیم. بدهی اتفاقی بازپرداخت نشده باید سریعا بعنوان بدهی شناخته شده ثبت شود
۳-بازورداخت تدریجی بدهی فنی
بازپرداخت بدهی فنی بهتر است مطابق برنامه و اندک اندک در هر اسپرینت صورت گیرد، بازپرداخت کامل بدهی مانند بازپرداخت یکجای یک وام است. «اسپرینت‌های بدهی فنی» یا «اسپرینت‌های بازسازی» واژه‌های وحشتناکی است که تیم بجای توسعه ویژگی جدید محصول وادار میشود که بازپرداخت انجام دهد. ما این را می‌پذیریم اما تا جای ممکن از آن پرهیز کنید و بدهی را تدریجی در هر اسپرینت پرداخت نمایید، برنامه ریزی پرداخت بدهی توسط تیم اسکرام در طی برنامه ریزی اسپرینت صورت میگیرد که بخشی از بدهی شناخته شده را با عنوان بدهی فنی هدف کذاری شده برای بازپرداخت در اسپرینت بعدی انتخاب میکنیم
۴-ابتدا بدهی با بهره بالا را بازپرداخت کنید
بدهی‌های فنی ارزش یکسانی ندارند برخی بدهی‌ها مانند یک ماژول که در جاهای مختلفی استفاده شده ارزش بیشتری دارد لذا باید ابتدا این بدهی‌ها بازپرداخت شود مگر اینکه یک دلیل قانع کننده وجود داشته باشد برای مثال برخی سازمانها بدهی زیادی تولید میکنند و نمیدانند چگونه به آن رسیدگی کنند لذا جهت روی غلطک افتادن ابتدا از بدهی‌های کوچک شروع میکنند ما با هرچیزی که موجب افزایش دانش فنی شود موافق هستیم، فراموش نکنید در هر اسپرینت بخشی از بدهی را بازپرداخت نمایید
۵-بدهی فنی را همزمان با انجام کار با ارزش برای مشتری بازپرداخت کنید
یکی از از روش‌های بسیار عالی بازپرداخت بدهی هنگام توسعه اقلام بارارزش و ویژگی جدید برای مشتری است که موجب میشود بدهی با ارزش بالاتر پرداخت شود و همسو با ارزش محورست اسکرام میز پیش برو، این رویکرد موجب میشود تا از اختصاص یک اسپرینت برای بدهی جلوگیری شود. در این رویکرد ابتدا ما متعهد میشویم که بدهی ناشی از بی‌تجربگی اضافه نکنیم، ثانیا قانون پیشاهنگی را نیز انجام دهیم (کشف اتفاقی بدهی و پاکسازی کد و پرداخت آن) و ثالثا بدهی فنی هدف کذاری شده را از بخش‌هایی انتخاب میکنیم که در آینده روی آن کار میکنیم
مزیت‌های این رویکرد:
- همسو سازی کاهش بدهی و کار با ارزش برای مشتری، که موجب میشود مالک بهتر اولویت بندی کند
-گوشزد کردن به تیم که بدهی برای همه است و نه فرد یا تیم خاصی پس در بازپرداخت آن همه سهیم هستند
-موحب تقویت و افزایش مهارت‌های کاهش و حلوگیری از بدهی فنی میشود
-کمک به شناسایی بخش‌ها با بهره بالا که موجب میشود ما درک کنیم بخش توسعه داده شده همچنان در آینده ما با آن سروکار داریم
-جلوگیری از عدم بازپرداخت بدهی‌هایی که اجباری برای آن وجود ندارد
قبلا صحبت کردیم که بک‌لاگ بدهی فنی چیست، در این رویکرد هنگام انتخاب اقلام توسط تیم و همراه مالک این تابلو کنار تابلو اقلام قرار میگیرد و هنگام انتخاب هر قلم با توجه به تابلوی بدهی اگر قلمی در تابلوی بدهی وجود داشته باشد که مرتبط با قلم انتخاب شده بک‌لاگ محصول باشد برویده و در کنار آن جهت رسیدگی گذاشته میشود و این یک رویکرد ساده جهت همسو سازی است. تصویر اول در کامنت
#scrum
@code_crafters
❤6
مالک محصول
مرور
مالک کانون اصلی و قدرتمند محصول است که یکی از سه نقش اسکرام را برعهده دارد (استاد، تیم، مالک) مالک باید همزمان به دو سویه توجه داشته باشد از یک سو نیازها و اولویت‌های ذینفعان سازمانی، مشتریان و کاربران را به خوبی درک کند و صدای آنان باشد(بعنوانی مانند یک مدیر محصول عمل کرده و مطمئن شود راهکار درستی در حال توسعه است) و از سوی دیگر باید درباره محصول در حال ساخت و ترتیب ساخت آن با تیم توسعه در تعامل باشد (اطمینان از معیارهای پذیرش ویژگی‌های مشخص شده و آزمون‌هایی که این معیارها را تاید و صحه‌گذاری کند اجرا شده باشند) مالک آزمونهای جزئی نمی‌نویسد بلکه مطمئن میشود آزمونهای کلان بگونه‌ای نوشته شده باشد که تیم از روی آن بفهمد که ویژگی چه زمانی از نظر مالک تکمیل تلقی میشود
مالک هم تحلیلگر کسب و کار است هم آزمونگر
مسئولیت‌های اصلی
مالک دارای مسئولیت‌های بسیاری است که گاه به این فکر میکنیم که آیا یکنفر میتواند از عهده تمام آن بر بیاید یا همه خصوصیات لازم را داشته باشد. مالک محصول هر تیم تنها یکنفر است هرچند در شرایط خاص استفاده از تیم مالک یا نماینده مالک عملی‌تر است
#scrum
@code_crafters
مرور
مالک کانون اصلی و قدرتمند محصول است که یکی از سه نقش اسکرام را برعهده دارد (استاد، تیم، مالک) مالک باید همزمان به دو سویه توجه داشته باشد از یک سو نیازها و اولویت‌های ذینفعان سازمانی، مشتریان و کاربران را به خوبی درک کند و صدای آنان باشد(بعنوانی مانند یک مدیر محصول عمل کرده و مطمئن شود راهکار درستی در حال توسعه است) و از سوی دیگر باید درباره محصول در حال ساخت و ترتیب ساخت آن با تیم توسعه در تعامل باشد (اطمینان از معیارهای پذیرش ویژگی‌های مشخص شده و آزمون‌هایی که این معیارها را تاید و صحه‌گذاری کند اجرا شده باشند) مالک آزمونهای جزئی نمی‌نویسد بلکه مطمئن میشود آزمونهای کلان بگونه‌ای نوشته شده باشد که تیم از روی آن بفهمد که ویژگی چه زمانی از نظر مالک تکمیل تلقی میشود
مالک هم تحلیلگر کسب و کار است هم آزمونگر
مسئولیت‌های اصلی
مالک دارای مسئولیت‌های بسیاری است که گاه به این فکر میکنیم که آیا یکنفر میتواند از عهده تمام آن بر بیاید یا همه خصوصیات لازم را داشته باشد. مالک محصول هر تیم تنها یکنفر است هرچند در شرایط خاص استفاده از تیم مالک یا نماینده مالک عملی‌تر است
۱- مدیریت امور اقتصادی
مسئولیت از کسب اطمینان از درستی تصمیم اقتصادی که در اسپرینت و بک‌لاگ گرفته می‌شوند:
-امور اقتصادی در سطح انتشار: مالک با ورود اطلاعات مهم اقتصادی در طی توسعه به تیم، ما بین محدوده، تاریخ انتشار، بودجه و کیفیت تولزن برفگقرار میکند. مالک میتواند با توجه به دیدگاه اقتصادی توسعه محصول را برای اسپرینت بعدی متوقف کند. برای مثال عدم‌توجیه پذیر بودن هزینه اسپرینت بعدی، کافی بودن ویژگی‌های تا کنون محصول نسبت به بازار و نداشتن توجیه اقتصادی مابقی اقلام در بک‌لاگ(اقلام مهم در بالای بک‌لاگ قرار دارند)، تغییر وضعیت بازار به هر دلیلی مانند ثبت قانون حدید یا تغییر کلی وضعیت بازار و ...
-امور اقتصادی در سطح اسپرینت: مالک در سطح اسپرینت برای بازگشت سرمایه تصمیماتی میگیرد. مالک از میزان هزینه اسپرینت بعدی آگاه است (زمان و تعداد نفرات) و خود میپرسد آیا بصرفه است اینکار را انجام دهم
-امور اقتصادی در سطح بک‌لاگ:
مالک مسئول اولویت بندی اقلام در بک‌لاگ است و ممکن با توجه به شرایط اقتصادی اولویت بندی را تغییر یا اقلامی را حذف کند
۲- مشارکت در برنامه ریزی
مالک یکی از اعضای مهم در برنامه ریزی‌های سبد محصول،برنامه‌ریزی محصول،برنامه‌ریزی انتشار و برنامه‌ریزی اسپرینت است
در برنامه‌ریزی سبد محصول مالک با همکاری ذینفعان داخلی که کمیته تصمیم گیری یا نظارت هستند، جایگاه محصول در بک‌لاگ محصول و زمان شروع و پایان را تعیین میکند. در برنامه‌ریزی محصول چشم‌انداز محصول را با همکاری ذینفعان ترسیم میکند. در برنامه‌ریزی انتشار محتوای انتشار بعدی را با ذینفعان و تیم تعریف میکند. در برنامه ریزی اسپرینت هدف اسپرینت را تیم مشخص میکند. همچنین کمک میکند که تیم اقلام با ارزشی را بردارد که واقعا از عهده آن بر می‌آید
۳- آماده سازی بک‌لاگ محصول
مالک مسیولیت بک‌لاگ محصول را برعهده دارد که شامل فعالیت‌های ایجاد،اصلاح،برآورد و اولویت بندی اقلام است. مالک همه اینکارها را خود به تنهایی انجام نمی‌دهد در ممکن است همه اقلام را خود ننویسد یا در برآورد تیم اینکار انجام می‌دهد و مالک جهت شفاف سازی و پاسخ دهی حضور دارد. به هرحال مالک مسئول فعالیت‌های آماده سازی به شکلی که موجب افزایش سرعت جریان ارزش آفرینی است
۴- تعریف معیار پذیرش و تایید تحقق آن
مالک مسئول تعریف معیارهای پذیرش برای تک تک اقلام است تا در صورت تحقق مالک متقاعد شود. در این مسیر مالک از خبرگان موضوع یا تیم توسعه کمک میگیرد. مالک قبل از طرح قلم در جلسه برنامه ریزی اسپرینت باید مطمین باشد که معیارهای پذیرش و اکثر آزمونهای پذیرش مشخص و ثبت شده باشند. بدن این موارد قلم کامل و آماده ورود به اسپرینت نیست. وجود معیارهای شفاف به عنوان یکی از ردیف‌های چک لیست «تعریف آماده» است. مالک شخصا آزمونهای پذیرش را اجرا میکند یا از کاربران باتجربه کمک میگیرد تا تحقق شرط‌های رضایت‌مندی اقلام بک‌لاگ محصول را تایید کند. تیم زیرساختی را جهت اجرای آزمون‌ها در اختیار مالک یا خبرگان می‌گذارد. ازمون‌ها نباید به زمان بازنگری اسپرینت موکول گردد تا مالک با اجرای آن اشتباهات و برداشت‌های غلط را مشخص و در بازنگری اسپرینت مطرح کند. بدینگونه تیم تشخیص می‌دهد کدام یک از ویژگی‌ها واقعا با «تعریف انجام شده» مطابقت دارد
۵- همکاری با تیم توسعه
مالک باید حضوری تمام وقت و منظم با تیم داشته باشد. عدم ارتباط گیری با تیم موجب بازخوردهای منفی میشود و بازخوردهای مفید دیرتر به تیم می‌رسد. در توسعه سنتی الگوی مشارکت به شکل U است ابتدا سریع و کامل می‌ایند و در در میانه حضور ندارند تا پایان توسعه نیز باز نمیگردند
#scrum
@code_crafters
👍3
این موحب میشود محصولی ساخته شود که مطابق نیاز مشتریان نیست و اتهام زنی‌ها شروع می‌گردد. در اسکرام ما در هر مرحله در حال انجام یک کار نیستیم بلکه در حال توسعه ویژگی‌ها هستیم این بدین معناست تمامی فعالیت‌های ساخت یک ویژگی یعنی طراحی، کدنویسی، یکپارچه‌سازی و آزمون را در طول اسپرینت انحام می‌دهیم. به همین دلیل مشارکت بسیار زیاد و بی‌وقفه مالک ضروری است
۶- همکاری با ذینفعان
مالک باید صدای ذینفعان داخلی(صاحبان سیستم‌های کسب و کار، مدیریت اجرایی، مدیریت برنامه، بازاریابی و فروش ) و خارجی(مشتریان، کاربران، شرکتهای همکار، نهاذهای قانون گذار و ...) باشد. عدم رسیدگی کالک به وظایف از بابت مشغلگی زیاد، زیان اور است لذا مالک میتواند از دیگران برای انجام کارهایش کمک بگیرد
خصوصیت‌ها و مهارت‌ها
خصوصیت‌های مالک را میتوان به چهار گروه تقسیم کرد:مهارت‌های دامنه مسئله،مهارت‌های انسانی،قدرت تصمیم گیری و پاسخ گویی
مهارت‌های دامنه مسئله:
فردیست دوراندیش که قادر است چشم‌اندازی برای محصول تدوین کند و تیم را در جهت دستیابی به این چشم انداز هدایت نماید(این به معنای شفافیت کامل همه چیز نیست)،هر مالکی میداند که در ابتدا همه چیز مشخص و واضح نیست خود را آماده تغییر مناسب و ضروری میکند. مالک به منظور افزایش اثربخشی در تدوین و اجرای چشم انداز، باید دانش مناسب و قابل قبولی درباره کسب و کار و دامنه مسئله داشته باشد.فرد تازه کار در دامنه محصول به سختی مالک موفقی میشود. اگر موضوعی را ندانید چگونه میتوانید ویژگی‌های مربوط به آن را اولویت بندی کنید؟
مهارت‌های انسانی:
مالک باید صدای مشتری باشد که لازمه آن داشتن رابطه خوب با ذینفعان است. ذینفعان متعدد موجب نیازهای متناقض هستند لذا مالک باید مذاکره کننده ماهری باشد که بین ذینفعان اتفاق نظر و اجماع ایجاد کند و از سمت دیگر اتصال ذینفعان با تیم توسعه است به همین دلیل نیاز به مهارت ارتباطی قوی دارد تا اطلاعات را با زبانی مناسب بین دو گروه منتقل کند. فردی با مهارت ارتباطی قوی از خصلت‌های دیگر نیز برخوردار است از جمله: آماده است تا عقاید خود را حتی اگر با وضعیت موجود ناسازگار باشد با صدای بلند بیان کند، نسبت به ایده‌هایش اطمینان دارد، به موضوع مسلط است،میتواند اطلاعات را ساده، مختصر و قابل فهم بیان کند و قابل اعتماد است.و همچنین فردی توانا برای ایجاد انگیزه در افراد است.زمانیکه کارها خوب پیش نمی‌رود به افراد یاداوری میکند به چه علت کار میکنند و با تشریح مجدد آینده کسب و کار به آنها در داشتن نگاهی پرشور و حفظ آن کمک میکند
قدرت تصمیم گیری:
مالک باید قدرت تصمیم گیری داشته باشد در سازمانهای نوظهور چنین قدرتی به مالک نمی‌دهند. چنین فردی مالک نیست. مالک باید اماده تصمیم‌گیری‌های دشوار باشد که معمولا با سبک و سنگین کردن قیدهایی همچو زمان و بودجه همراه است.تصمیم‌هاباید بموقع گرفته و بدون دلیل لغو نگردند (تصمیم گیری قاطع و مصمم) در چنین تصمیم‌گیری‌هایی مالک باید بین نیازهای کسب و کار و واقعیت‌های فنی توازن برقرار کند. وقتی که سیستم در وضعیت غیرقابل قبول بدهی فنی قرار دارد کل تیم اسکرام مسئول است اما تصمیم‌های بدون دقت مالک محصول عامل تاثیرگذار و مهمی در ایجاد بدهی بشمار می‌رود بالاخص تصمیم‌هایی که قصور او و بدون توجه به اثرات آن در سیستم ایجاد شده است
پاسخ‌گویی:
مالک مسئول و پاسخگوی اصلی نتایج مطلوب برای کسب و کار است.اما این موجب نمیشود تا سایر اعضای اسکرام از بازگشت سرمایه معاف باشند.با این حال مالک مسئول کسب اطمینان از استفاده اقتصادی از منابع است و در غیر اینصورت باید پاسخگو باشد. مالک فرصت‌های زیادی برای تغییر بک‌لاگ، اولویت بندی یا حتی توقف توسعه را در اختیار دارد. مالک محصول فردی متعهد و در دسترس ذینفعان و اعضای تیم است. شغلی تمام وقت و انجام پاره وقت آن منحر به شکست میشود. مالک به گروه اسکرام معتقد است و با آنها با احترام برخورد کرده و میداند همه در دستیابی نتایج مطلوب شریک و تلاش میکنند
چه کسی باید مالک محصول باشد
مالک محصول باید همزمان دو سویه را در نظر بگیرد (ذینفعان و تیم فنی) لذت ترکیبی از اختیارات و مسئولیت‌های مختلف است که در چندین نقش وجود دارد:مدیر محصول، مدیر بازاریابی محصول، مدیر پروژه، مدیر تحلیلگر کسب و کار و آزمونگر پذیرش
اینکه چه کسی مالک باشد بستگی به نوع توسعه و سازمان دارد
۱-توسعه داخلی: یکنفر از اعضا که از توسعه سود میبرند و دارای قدرت و اختیارات است (توسعه سیستم برای بخش بازاریابی، یکنفر از بازاریاب‌ها)
۲-توسعه تجاری: یکی از کارمندان که بتواند صدای مشتریان باشد این فرد از بین مدیران محصول یا مدیران بازاریابی محصول انتخاب میشود
۳-پروژه برون سپاری: یکنفر نماینده از طرف شرکت درخواست کننده پروژه، یکنفر نماینده از شرکت انجام دهنده جهت ارتباط
#scrum
@code_crafters
👍3
اگر قرارداد بصورت مبلغ ثابت باشد کار مالک سخت و پیچیده میشود و شرکت انجام دهنده میداند که خود باید بیشتر مسئولیت‌های مالک را گردن بگیرد چونکه ریسک قرارداد را گردن گرفته، بهتر است قرارداد جوری باشد که شرکت درخواست کننده تیم و استاد را به از شرکت امجام دهنده به خدمت بگیرد و مالک محصول را از داخل انتخاب کند
۴-توسعه مولفه
برخی سازمانها از تیم‌های مولفه محور استفاده میکنند که آنها تنها بخشی از از راهکار مشتری را می‌سازند نه تمام آن را، هدف این تیم‌ها ساخت دارایی‌هایی است که برای همه تیم‌های دیگر با ارزش است در این تیم‌ها یکنفر با نگرش فنی نقش مالک را برعهده میگیرد که توانایی نوشتن اقلام و اولویت بندی بک‌لاگ را داشته باشد. برخلاف آن مالک تیم‌های ویژگی محور تخصص فنی کمتری دارد یا ندارد. تصویر اول در کامنت
ترکیب نقش مالک محصول با سایر نقش‌ها
طبیعی است که یکنفر مالک محصول چند تیم باشد اگر میزان فشار کاری کم باشد و اهداف تیم‌ها یکسان باشد، همچنینی مالک محصول میتواند عضوی از تیم فنی نیز باشد اما نمی‌تواند استاد هم باشد چونکه این دو نقش برای تعادل ایجاد شده و در صورت یکی شدن تضاد منافع صورت میگیرد
تیم مالک محصول
اساسا تشکیل تیم مالک محصول منتفی است مگر اینکه مالک مشغله داشته باشد و برخی از افراد را مسئول برخی وظایف خود کند. مالک محصول باید تنها یکنفر با قدرت و اختیار باشد و گروه قابل قبول نیست که جمعی تصمیم گیری کنند (اگر مالک ضعیفی دارید با ایجاد تیم درست نمیشود بلکه باید شغلش را تغییر دهید)، اگر چندین تیم دارید پس چندین مالک هم دارید، اگر چندین تیم با یک مالک دارید شاید مشکل از سازمان باشد که چند پروژه رو باهم شروع کرده است، اگر پروژه بزرگ باشد و به چندین بخش شکسته شده باشد باز هم یکنفر میتواند مالک همه آنها باشد و اگر تیم‌ها ضعیف چیده شده باشند یا بک‌لاگ درست تهیه نشده باشد ابتدا مطمئن شوید که هدف از تشکیل تیم مالک پنهان کردن یا سرپوش گذاری بر موضوع دیگری نیست چونکه تیم مالک در شرایط نا به سامان فقط منحر به از بین رفتن دستاوردها و پیچیده شدن بیشتر شرایط میشود
نماینده مالک محصول
زمانیکه افراد کسب و کار مشغله زیاد دارند، سازمانها علاقه دارند نفری فنی را مالک کنند که اختیار تصمیم گیری ندارد (یکی از ارکان مهم برای مالک بودن) لذا بهتر است او نماینده مالک شود و به مالک و تیم کمک کند، مالک نباید تصمیمات نماینده خود را بی دلیل رد کند که موجب صلب اعتماد نماینده خود شود همچنین مالک نمی‌تواند نتیجه نهایی درستی انجام کار به کسی حتی نماینده خود واگذار کند
مالک محصول ارشد
اگر یک محصول انقدری بزرگ باشد که با شکستن آن به چندین بخش (هر تیم نهایتا شامل مجموعه‌ای ده نفره است) تعداد زیادی از بخش‌ها را ایجاد کند که از عهده یک مالک مشترک بر نیاید در این مواقع مالک محصول تیم مالکان محصول را ایجاد کرده و این اطمینان را حاصل میکند وظایف و دسترسی و ... کامل شکل گرفته باشد که برای هرکاری لازم به ارجاع به بالاتر نباشد تصویر دوم در کامنت
#scrum
@code_crafters
👍3
👍8😁2💊1
مصاحبه فنی و hr بودم
شرکت از دید اولیه من عالی و خوب بود
هر شرکتی یکسری ضعف‌های خودش رو داره و یکسری خوبی خودش رو
قرار نیست همه اتوپیا باشه و باب میل و در حد غایی کمالگرایی خودش
بگذریم
تو مصاحبه قرار نیست سعی کنید همه سوالات رو جواب بدید میتونید بگید تا الان کار نکردم ولی فکر میکنم این قسمت رو به این شکل میتونیم هندل کنیم، یادتون نره نه شما کامل همه چی رو میدونید نه حتی طرف مصاحبه کننده شما، همونقدر که من از اون یاد گرفتم اونم از من یادگرفت و این تعامل چیز مفید قضیه هست نه بیشتر و همین تعامل عامل حس خوب در من شد. احتمالا رد بشم چرا؟؟؟ چون هرجایگاهی یه اندازه داره، ممکنه اندازه شما بزرگتر یا کوچیکتر از اون سایز باشید که تصمیمش برعهده سازمان هستش نه شما پس سایز خودتون رو کم و زیاد باد نکنید
سوالات حول محور
Tdd
Ddd
Ci/cd
Rest
Storage
Microservice
Sso
Documentaion
Agile
Scrum
Searching
Protocol
Docker
و چالش‌های سازمانی بود
#free
شرکت از دید اولیه من عالی و خوب بود
هر شرکتی یکسری ضعف‌های خودش رو داره و یکسری خوبی خودش رو
قرار نیست همه اتوپیا باشه و باب میل و در حد غایی کمالگرایی خودش
بگذریم
تو مصاحبه قرار نیست سعی کنید همه سوالات رو جواب بدید میتونید بگید تا الان کار نکردم ولی فکر میکنم این قسمت رو به این شکل میتونیم هندل کنیم، یادتون نره نه شما کامل همه چی رو میدونید نه حتی طرف مصاحبه کننده شما، همونقدر که من از اون یاد گرفتم اونم از من یادگرفت و این تعامل چیز مفید قضیه هست نه بیشتر و همین تعامل عامل حس خوب در من شد. احتمالا رد بشم چرا؟؟؟ چون هرجایگاهی یه اندازه داره، ممکنه اندازه شما بزرگتر یا کوچیکتر از اون سایز باشید که تصمیمش برعهده سازمان هستش نه شما پس سایز خودتون رو کم و زیاد باد نکنید
سوالات حول محور
Tdd
Ddd
Ci/cd
Rest
Storage
Microservice
Sso
Documentaion
Agile
Scrum
Searching
Protocol
Docker
و چالش‌های سازمانی بود
#free
👍12
تیم توسعه
مرور
در رویکردهای سنتی توسعه نرم‌افزار شغل‌های مختلفی مانند: معمار، برنامه‌نویس، آزمونگر،راهبر پایگاه داده، طراح رابط کاربری و موارد مشابه آن وجود دارد. اما در اسکرام یک نقش با عنوان تیم توسعه تعریف میشود که مجموعه‌ای چندتخصصی از این افراد است که یکی از سه نقش اصلی اسکرام است. ممکن است به آن تیم، تیم تحویل یا عناوین دیگری نیز اطلاق شود اما تیم توسعه توافق اکثریت است
تیم‌های نقش محور
در بسیاری از سازمانها نقش‌های کاری را به‌شکل تیم‌های تخصصی و چندمحور سازماندهی میکنند. این سازمانها تیمی از طراحان، تیمی از توسعه دهندگان و تیمی از آزمونگرها دارند. وقتی کار یک تیم تمام میشود آن را به تیم دیگر تحویل می‌دهد. تیم‌ها کم و بیش مستقل از یکدیگر کار میکنند.
در اسکرام، تیم توسعه در هر اسپرینت باید کارهای لازم برای تولید یک یا چند بخش از محصول را انجام دهد. این کارها شامل طراحی، توسعه، یکپارچه‌سازی و آزمون است. از این رو به تیمی نیاز داریم که مهارت‌های لازم برای انجام همه‌ی این کارها را داشته باشد.
در برخی سازمانها هنگام استفاده از اسکرام تیم آزمونگر جدا دارند. ممکن است یکی از الزامات قانونی این باشد و وجود تیم آزمونگر جدا مناسب باشد. اما در اسکرام آزمون باید در اسپرینت صورت گیرد. اسکرام با تیم‌های نقش محور ناسازگاری دارد
مسئولیت‌های اصلی
تصویر اول در کامنت‌ها، فعالیت‌ها و مسئولیت‌های اصلی تیم توسعه را نشان می‌دهد
خصوصیات و مهارت‌ها
تیم توسعه باید دارای خصوصیات و مهارت‌های زیر باشد
۱- خودسازمانده
اعضای تیم خود را بگونه‌ای سازماندهی میکنند تا بهترین روش دستیابی به هدف اسپرینت انتخاب شود. مدیر پروژه یا مدیر دیگری وجود ندارد که روش انجام کار تعیین کند و استاد نیز نباید تصور کند اینکار برعهده اوست. خودسازماندهی یکی از خصوصیات تکاملی و پایین به بالای سیستم است هیچ قدرت کنترل کننده بیرونی وجود ندارد که تیم را با استفاده از مدیریت سمتی بالا به پایین و فرماندهی کند. خودسازماندهی ویژگی پایین به بالای سیستم‌های تطبیق پذیر پیچیده است. در چنین سیستم‌هایی، تعداد زیادی از موجودیت‌ها با شیوه‌های گوناگونی با یکدیگر در تعامل هستند و این تعاملات تحت کنترل قواعدی ساده و محلی قرار دارند و در فضایی با بازخوردهای بی‌وقفه و مداوم انجام می‌شوند اینگونه سیستم‌ها پایداری قابل توجه و نوآوری شگفت‌انگیزی دارند. مدیران تنها محیط را برای تیم خودسازمانده فراهم یا بازسازی میکنند
#scrum
@code_crafters
مرور
در رویکردهای سنتی توسعه نرم‌افزار شغل‌های مختلفی مانند: معمار، برنامه‌نویس، آزمونگر،راهبر پایگاه داده، طراح رابط کاربری و موارد مشابه آن وجود دارد. اما در اسکرام یک نقش با عنوان تیم توسعه تعریف میشود که مجموعه‌ای چندتخصصی از این افراد است که یکی از سه نقش اصلی اسکرام است. ممکن است به آن تیم، تیم تحویل یا عناوین دیگری نیز اطلاق شود اما تیم توسعه توافق اکثریت است
تیم‌های نقش محور
در بسیاری از سازمانها نقش‌های کاری را به‌شکل تیم‌های تخصصی و چندمحور سازماندهی میکنند. این سازمانها تیمی از طراحان، تیمی از توسعه دهندگان و تیمی از آزمونگرها دارند. وقتی کار یک تیم تمام میشود آن را به تیم دیگر تحویل می‌دهد. تیم‌ها کم و بیش مستقل از یکدیگر کار میکنند.
در اسکرام، تیم توسعه در هر اسپرینت باید کارهای لازم برای تولید یک یا چند بخش از محصول را انجام دهد. این کارها شامل طراحی، توسعه، یکپارچه‌سازی و آزمون است. از این رو به تیمی نیاز داریم که مهارت‌های لازم برای انجام همه‌ی این کارها را داشته باشد.
در برخی سازمانها هنگام استفاده از اسکرام تیم آزمونگر جدا دارند. ممکن است یکی از الزامات قانونی این باشد و وجود تیم آزمونگر جدا مناسب باشد. اما در اسکرام آزمون باید در اسپرینت صورت گیرد. اسکرام با تیم‌های نقش محور ناسازگاری دارد
مسئولیت‌های اصلی
تصویر اول در کامنت‌ها، فعالیت‌ها و مسئولیت‌های اصلی تیم توسعه را نشان می‌دهد
۱-اجرای اسپرینت
اعضای تیم در طول اسپرینت با انجام خلاقانه طراحی، ساخت، یکپارچه سازی و آزمون اقلام بک‌لاگ محصول، بخش قابل عرضه‌ای از محصول را آماده میکنند و بصورت خودسازمانده و گروهی برنامه ریزی، مدیریت، انجام و اطلاع رسانی کارها تصمیم میگیری میکنند. تیم توسعه بیشتر وقت خود را صرف «اجرای اسپرینت» میکند
۲-بازرسی و تطبیق روزانه
همه اعضای تیم توسعه موظفند در اسکرام‌های روزانه شرکت کنند، و به شکل گروهی میزان پیشرفت کار را نسبت به هدف اسپرینت بررسی کنند و برنامه روز حاری را مطالق آن تغییر دهند. شرکت نکردن برخی از اعضای تیم در اسکرام مانع این دستیابی به هدف اسپرینت میشود
۳-آماده سازی بک‌لاگ محصول
بخشی از هر اسپرینت باید صرف ایجاد آمادگی برای اسپرینت بعدی شود. تمرکز بخش عمده‌ای از این کار بر آماده سازی بک‌لاگ محصول است که شامل فعالیت‌های ایجاد، اصلاح، برآورد و اولویت‌بندی اقلام بک‌لاگ محصول است حدود ده درصد از هر اسپرینت را تیم صرف کمک به مالک جهت آماده سازی بک‌لاگ محصول میکند
۴- برنامه ریزی اسپرینت
در ایتدای هر اسپرینت تیم توسعه در برنامه ریزی اسپرینت شرکت میکند و با همکاری مالک و با راهنمایی استاد هدف اسپرینت جاری مشخص میشود. و تیم تعیین میکند که هدف اسپرینت با ساخت کدام یک از اقلام با اولویت یک‌لاگ محصول محقق میشود برنامه ریزی هر اسپرینت دو هفته‌ای حدود نصف روز طول می‌کشد و چهارهفته‌ای یک روز کامل طول می‌کشد. تیم بجای ارائه یک برنامه کلی که غیرقطعی و بیش از حدتفصیلی در ابتدای توسعه، مجموعه‌ای از برنامه‌های کوچکتر، قطعی‌تر و تفصیلی‌تر در ابتدای هر اسپرینت تهیه میکند
۵- بازرسی و تطبیق محصول و فرآیند
در پایان هر اسپرینت تیم در دو فعالیت بازرسی و تطبیق شرکت میکند: بازنگری اسپرینت و بازاندیشی اسپرینت. در بازنگری اسپرینت تیم،مالک،استاد،ذینفعان،حامیان، مشتریان و علاقمندان سایر تیم‌ها ویژگی‌هایی را که در اسپرینت جاری تکمیل شده است بازنگری کرده و در مورد بهترین روش ادامه کار با یکدیگر بحث و گفتگو میکنند. در بازاندیشی تیم فرایند اسکرام و تحربه‌های فنی خود را مورد بازرسی و تطبیق قرار می‌دهد تا با بهبود روش استفاده از اسکرام، ارزش‌های بیشتری برای کسب‌وکار خلق نماید
خصوصیات و مهارت‌ها
تیم توسعه باید دارای خصوصیات و مهارت‌های زیر باشد
۱- خودسازمانده
اعضای تیم خود را بگونه‌ای سازماندهی میکنند تا بهترین روش دستیابی به هدف اسپرینت انتخاب شود. مدیر پروژه یا مدیر دیگری وجود ندارد که روش انجام کار تعیین کند و استاد نیز نباید تصور کند اینکار برعهده اوست. خودسازماندهی یکی از خصوصیات تکاملی و پایین به بالای سیستم است هیچ قدرت کنترل کننده بیرونی وجود ندارد که تیم را با استفاده از مدیریت سمتی بالا به پایین و فرماندهی کند. خودسازماندهی ویژگی پایین به بالای سیستم‌های تطبیق پذیر پیچیده است. در چنین سیستم‌هایی، تعداد زیادی از موجودیت‌ها با شیوه‌های گوناگونی با یکدیگر در تعامل هستند و این تعاملات تحت کنترل قواعدی ساده و محلی قرار دارند و در فضایی با بازخوردهای بی‌وقفه و مداوم انجام می‌شوند اینگونه سیستم‌ها پایداری قابل توجه و نوآوری شگفت‌انگیزی دارند. مدیران تنها محیط را برای تیم خودسازمانده فراهم یا بازسازی میکنند
#scrum
@code_crafters
👍4
۲- دارای تخصص‌های گوناگون و کافی
اعضای تیم توسعه باید تخصص‌های مختلفی داشته باشند، آنها در مجموع باید مهارت‌های لازم و کافی را داشته باشند. تیمی که بخوبی شکل گرفته باشد میتواند قلمی را از بک‌لاگ محصول بردارد و ویژگی با کیفیتی تولید کند که با تعریف انجام شده اسکرام مطابقت داشته باشد. تیم‌هایی که مهارت‌های مشابه دارند به روش سنتی در نهایت مجبورند که محصولات را دست به دست کنند که احتمال ایجاد اشتباهات پرهزینه و سوتفاهم دارد. وجود تیم‌هایی که که افراد آن دارای تخصص‌های مختلف هستند، تعداد ارجاع کارها را کمینه میکند. تنوع و چند تخصصی بودن تیم‌ها، مزایای متعددی دارد و منحر به نتایج بهتری میشود. اعضای هر تیم چند تخصصی، پیش زمینه و معلومات مختلفی دارند. هر عضو مجموعه‌ای از ابزارهای شناختی خود را برای حل مسئله همراه می‌آورد که میتواند شامل تفسیرهای مختلف از داده‌های یکسان، ابتکارها، راهبردهای حل مسئله مدل‌های ذهنی درباره عملکرد اشیا و سلیقه‌های مختلف در انتخاب رویکرد یا راهبردهای حل مسئله، مدل‌های ذهنی درباره عملکرد اشیا و سلیقه‌های مختلف در انتخاب رویکردها و راهکارها باشد که منجر به افزایش ارزش اقتصادی میشود تصویر اول در کامنت
سعی کنید ترکیب درستی از افراد با تجربه و تازه‌کار ایجاد کنید. وجود افراد با تجربه در کنار هم ممکن است موجب شلوغی غیرضروری و بی‌مورد گردد
مهارت‌های تی شکل T
تیم‌های توسعه انعطاف پذیر از اعضایی با مهارت‌های تی شکل تشکیل شده است. هر یک از اعضای تیم در تخصص اصلی خود عمیق و در برخی تخصص‌های دیگر گستردگی دارد. این افراد میتوانند در زمان‌های گلوگاه سازمان عملکرد جمعی بهتری از خود نشان داده و به تیم برای رفع مشکل پیش آمده کمک کنند. اینکه هر عضو تیم قادر به انجام هرکاری باشد، تصور واقع بینانه‌ای نیست و رسیدن به چنین شرایطی هدفی بلندپروازانه است.
ایا حضور متخصصان محض در تیم قابل قبول است؟ در چنین شرایطی برای مثال یک نفر نیروی متخصص زبردستی در طراحی رابط کاربری است و در کنار او چند عضو دیگر هم با تخصص کمتری در تیم هستند در این مواقع ما تنها از بخشی از توانایی و تایم او استفاده میکنیم بهتر است از او در چندین تیم مختلف استفاده کنیم اما مراقب باشید پر کردن تایم او میتواند باعث بریدن او از سازمان باشد. راه دیگر تشویق نیروی متخصص زبردست برای ارتقا دانش نیروهای دیگر است تا وابستگی به او کمتر شود. در نهایت هدف ما تشکیل تیم چندتخصصی با اشتراک مهارت‌های نسبتا مشابه است اکثر اعضای تیم باید مهارت‌های تی شکل داشته باشند ولی احتمال حضور چند متخصص نیز در این ترکیب وجود دارد
۴- نگرش تفنگ‌دار
تاکیدی بر این است که کل تیم مسئول انجام کارهاست. موفقیت و شکست برای کل تیم است. اعضای تیم باید بپذیرند که با یکدیگر همکاری کنند تا تعهدات مشترکشان انجام شود. داشتن مهارت تی شکل این نگرش را تقویت و قابل انجام میکند و منحر میشود روی بیش از یک نوع وظیفه کار کنند. حتی اگر محدودیت‌های مهارتی وجود داشته باشد افراد باید بگونه‌ای کارشان را سازماندهی کنند که در طول اسپرینت فشار زیادی به هیچ یک از اعضا وارد نشود. برای مثال عقب انداختن آزمون‌ها تا پایان اسپرینت از این بابت که آزمونگر وقتش خالی شود منجر به شکست میشود
۵-ارتباطات گسترده
افراد تیم همانطور که با مالک و استاد در ارتباط هستند باید با همدیگر نیز در ارتباط باشند. تا اطلاعات ارزشمند به سرعت، با کارایی بالا و با کمترین هزینه بین آنها ردوبدل شود که منحر میشود تیم اسکرام فرصت بیشتری برای بازرسی و تطبیق بدست بیاورند که منحر به تصمیم گیری بهتر و سریعتر میشود. اطلاعات فرسوده می‌شوند و افزایش سرعت در اشتراک ان منحر میشود که تیم در مصرف منابع در مسیرهای نادرست جلوگیری کند. بیانیه چابک ارتباط رو در رو را رویکرد برتر میداند. با استفاده از تکنولوژی میتوان تیم‌های توزیع شده داشت اما در نهایت برای تیم‌های چندتخصصی ارتباط حضوری بهتر است و نمی‌توان آنرا جایگزین کرد و باعث حذف بوروکراسی و افزایش سرعت میشود همچنین باید تشریفات را کاهش داد برای مثال جهت ارتباط با مشتری نباید از سه لایه درخواست و تایید عبور کرد که غیرضروری است به یاد داشته باشید افزایش تعداد نفرات سربار ارتباطی بیشتر و گستردگی ارتباطات کاهش می‌یابد
۶- روابط شفاف
روابط شفاف، درک روشنی از آنچه که واقعا در حال وقوع است فراهم می‌سازد تا مانع غافلگیری افراد شود و به افزایش اعتماد بین اعضای تیم نیز کمک میکند. همیشه اعتقاد داشتم که ارتباط اعضای تیم باید بگونه‌ای باشد که با اصل کمترین غافلگیری مطابقت داشته باشد
۷- اندازه مناسب
اسکرام طرفدار تیم‌های کوچک است. بعنوان یک قاعده‌ی کلی قبول میکنیم که تیم‌های پنج تا نه نفره ایده آل هستند. نتایج تحقیقات نشان داده تیم‌های کوچک کارآمدترند
#scrum
@code_crafters
اعضای تیم توسعه باید تخصص‌های مختلفی داشته باشند، آنها در مجموع باید مهارت‌های لازم و کافی را داشته باشند. تیمی که بخوبی شکل گرفته باشد میتواند قلمی را از بک‌لاگ محصول بردارد و ویژگی با کیفیتی تولید کند که با تعریف انجام شده اسکرام مطابقت داشته باشد. تیم‌هایی که مهارت‌های مشابه دارند به روش سنتی در نهایت مجبورند که محصولات را دست به دست کنند که احتمال ایجاد اشتباهات پرهزینه و سوتفاهم دارد. وجود تیم‌هایی که که افراد آن دارای تخصص‌های مختلف هستند، تعداد ارجاع کارها را کمینه میکند. تنوع و چند تخصصی بودن تیم‌ها، مزایای متعددی دارد و منحر به نتایج بهتری میشود. اعضای هر تیم چند تخصصی، پیش زمینه و معلومات مختلفی دارند. هر عضو مجموعه‌ای از ابزارهای شناختی خود را برای حل مسئله همراه می‌آورد که میتواند شامل تفسیرهای مختلف از داده‌های یکسان، ابتکارها، راهبردهای حل مسئله مدل‌های ذهنی درباره عملکرد اشیا و سلیقه‌های مختلف در انتخاب رویکرد یا راهبردهای حل مسئله، مدل‌های ذهنی درباره عملکرد اشیا و سلیقه‌های مختلف در انتخاب رویکردها و راهکارها باشد که منجر به افزایش ارزش اقتصادی میشود تصویر اول در کامنت
سعی کنید ترکیب درستی از افراد با تجربه و تازه‌کار ایجاد کنید. وجود افراد با تجربه در کنار هم ممکن است موجب شلوغی غیرضروری و بی‌مورد گردد
مهارت‌های تی شکل T
تیم‌های توسعه انعطاف پذیر از اعضایی با مهارت‌های تی شکل تشکیل شده است. هر یک از اعضای تیم در تخصص اصلی خود عمیق و در برخی تخصص‌های دیگر گستردگی دارد. این افراد میتوانند در زمان‌های گلوگاه سازمان عملکرد جمعی بهتری از خود نشان داده و به تیم برای رفع مشکل پیش آمده کمک کنند. اینکه هر عضو تیم قادر به انجام هرکاری باشد، تصور واقع بینانه‌ای نیست و رسیدن به چنین شرایطی هدفی بلندپروازانه است.
ایا حضور متخصصان محض در تیم قابل قبول است؟ در چنین شرایطی برای مثال یک نفر نیروی متخصص زبردستی در طراحی رابط کاربری است و در کنار او چند عضو دیگر هم با تخصص کمتری در تیم هستند در این مواقع ما تنها از بخشی از توانایی و تایم او استفاده میکنیم بهتر است از او در چندین تیم مختلف استفاده کنیم اما مراقب باشید پر کردن تایم او میتواند باعث بریدن او از سازمان باشد. راه دیگر تشویق نیروی متخصص زبردست برای ارتقا دانش نیروهای دیگر است تا وابستگی به او کمتر شود. در نهایت هدف ما تشکیل تیم چندتخصصی با اشتراک مهارت‌های نسبتا مشابه است اکثر اعضای تیم باید مهارت‌های تی شکل داشته باشند ولی احتمال حضور چند متخصص نیز در این ترکیب وجود دارد
۴- نگرش تفنگ‌دار
تاکیدی بر این است که کل تیم مسئول انجام کارهاست. موفقیت و شکست برای کل تیم است. اعضای تیم باید بپذیرند که با یکدیگر همکاری کنند تا تعهدات مشترکشان انجام شود. داشتن مهارت تی شکل این نگرش را تقویت و قابل انجام میکند و منحر میشود روی بیش از یک نوع وظیفه کار کنند. حتی اگر محدودیت‌های مهارتی وجود داشته باشد افراد باید بگونه‌ای کارشان را سازماندهی کنند که در طول اسپرینت فشار زیادی به هیچ یک از اعضا وارد نشود. برای مثال عقب انداختن آزمون‌ها تا پایان اسپرینت از این بابت که آزمونگر وقتش خالی شود منجر به شکست میشود
۵-ارتباطات گسترده
افراد تیم همانطور که با مالک و استاد در ارتباط هستند باید با همدیگر نیز در ارتباط باشند. تا اطلاعات ارزشمند به سرعت، با کارایی بالا و با کمترین هزینه بین آنها ردوبدل شود که منحر میشود تیم اسکرام فرصت بیشتری برای بازرسی و تطبیق بدست بیاورند که منحر به تصمیم گیری بهتر و سریعتر میشود. اطلاعات فرسوده می‌شوند و افزایش سرعت در اشتراک ان منحر میشود که تیم در مصرف منابع در مسیرهای نادرست جلوگیری کند. بیانیه چابک ارتباط رو در رو را رویکرد برتر میداند. با استفاده از تکنولوژی میتوان تیم‌های توزیع شده داشت اما در نهایت برای تیم‌های چندتخصصی ارتباط حضوری بهتر است و نمی‌توان آنرا جایگزین کرد و باعث حذف بوروکراسی و افزایش سرعت میشود همچنین باید تشریفات را کاهش داد برای مثال جهت ارتباط با مشتری نباید از سه لایه درخواست و تایید عبور کرد که غیرضروری است به یاد داشته باشید افزایش تعداد نفرات سربار ارتباطی بیشتر و گستردگی ارتباطات کاهش می‌یابد
۶- روابط شفاف
روابط شفاف، درک روشنی از آنچه که واقعا در حال وقوع است فراهم می‌سازد تا مانع غافلگیری افراد شود و به افزایش اعتماد بین اعضای تیم نیز کمک میکند. همیشه اعتقاد داشتم که ارتباط اعضای تیم باید بگونه‌ای باشد که با اصل کمترین غافلگیری مطابقت داشته باشد
۷- اندازه مناسب
اسکرام طرفدار تیم‌های کوچک است. بعنوان یک قاعده‌ی کلی قبول میکنیم که تیم‌های پنج تا نه نفره ایده آل هستند. نتایج تحقیقات نشان داده تیم‌های کوچک کارآمدترند
#scrum
@code_crafters
👍4
از جمله نکات مثبت تیم‌های کوچک
تیمی بسیار کوچک است که افراد کافی برای انجام کار نداشته باشد یا اعضا بقدری کم باشند که نتوانند به شکلی کارا و موثر کار کنند. این مسیله به معنای ناسازگاری اسکرام برای کارهای بزرگ نیست منتها بجای یک تیم ۳۶ نفره چهار تیم ۹ نفره خواهیم داشت.شاخص بزرگی پروژه‌های اسکرام،بزرگی تیم توسعه نیست بلکه تعداد تیم‌های اسکرام است.تیم‌ها میتوانند با رویکرد اسکرام اسکرام‌ها تعامل و جلسات روزانه برگذار کنند که اعضای تیم‌ها باهم جمع می‌شوند
۸-دارای تمرکز و تعهد
اعضا باید روی هدف تیم تمرکز داشته و به آن متعهد باشند. تمرکز بدان معناست که هر یک از اعضای تیم مشارکتی فعال و توجه خود را معطوف به هدف تیم کرده باشند. متعهد نیز یعنی اعضای تیم چه شرایط خوب و چه بد خود را وقف هدف تیم کرده کنند.این دو موضوع هنگام کار بر روی یک محصول امکان پذیر است اما اگر فرد روی چند محصول کار کند باید زمان خود را تقسیم کند و این موجب کاهش تمرکز و تعهد میشود.انجام کار با کیفیت برای کسی که از محصولی به محصول دیگر پرش میکند دشوار است و دشوارتر از آن تعهد واقعی و همزمان به چندین محصول است.داده‌ها نشان می‌دهد بهره‌وری بر روی دو پروژه بهتر و بیشتر است و زمانی که یک پروژه موقتا متوقف شود کار بر روی دومی موجب میشود که فرد بیکار نباشد.همچنین این داده‌ها نشان می‌دهد که کار بر روی بیشتر از ۳ پروژه یک تصمیم اقتصادی اشتباه است چونکه بیشتر تایم صرف یادآوری و هماهنگی و ... می‌گردد.پس تکلیف متخصصانی که معمولا باید بر روی چندین محصول کار کنند چه میشود اجازه بدهید که او خود تصمیم بگیرد و متعهد شود به انجام کار و اگر تصمیم رد کردن او از دیدگاه کسب و کار قابل قبول نباشد چند راهکار وجود دارد:اول اینکه پروژه‌های کمتری بگیرید، افراد بیشتری استخدام کنید، روی افزایش مهارت سایر افراد کار کنید و یا ترکیبی از این موارد را انجام دهید
۹-کار با آهنگی پایدار
یکی از اصول اسکرام کار با آهنگی پایدار توسط اعضا است که موجب محصولاتی در کلاس جهانی تولید کنند و محیطی سالم و شاد داشته باشند. در توسعه ترتیبی یکپارچه سازی و آزمون تا اواخر کار به تعویق می‌افتد که خود منجر به حجم فشار کار در فازهای بعدی میشود که برای جبران کار از شب بیداری و استفاده از تعطیلی های خود بهره میبرند.این مورد را با اسکرام مقایسه کنید که تمامی موارد باید در هر اسپرینت صورت گیرد و با توجه به تعریف ما از «انجام شده» مطابقت داشته باشد. فشار کار در هر اسپرینت باید شبیه اسپرینت قبلی باشد تا تضمینی بر آهنگ پایدار کار باشد که نتیجه آن کار با بسته‌های بزرگ با سرعت خیلی زیاد و مخصوصا خیلی دیر به تیم محول نمیشود و منجر میشود که در اسکرام اضافه کاری کمتری رخ دهد و تیم خسته و بریده نشود
۱۰- دیرپا
برای اثربخشی اسکرام تیم لازم است،نه گروه
دیرپا به تیمی گفته میشود که اعضای آن برای مدت طولانی تا جاییکه صرفه اقتصادی داشته باشند حفظ شوند. تیم دیرپا در مقابل تیم تازه کار صرفه اقتصادی بیشتر و بهره وری بهتری دارند و شناخت قبلی بین اعضا اثر مثبتی بر کارایی و کیفیت خروجی‌های تیم داشته باشد که منجر به افزایش دستاوردهای کسب و کار میشود. گروهی از افراد که از قبل همدیگر نمی‌شناسند نیاز به زمان و هزینه است جهت یک تیم واقعی شدن است که باید مراحلی از قبیل شکل‌گیری، تلاطم، قاعده‌مندی، و اجرا را طی کنند تا یک تیم شوند. تیم کارآمد دارایی واقعی کسب و کار است. اعضا می‌دانند چگونه باهم کار کنند و اعتماد هم را جلب کنند همچنین این تیم اطلاعات تاریخی از جمله سرعت و برآورد مشترک دارند، تیم منحل شده یا دچار تغییرات اساسی شده این اطلاعات را ندارد. سازمانهایی که جابجایی زیاد دارند یک اصل اسکرام را فراموش کرده‌اند مبنای چابکی تیم است یکی از ارزش‌های اصلی چابکی «افراد و تعاملات» است.سازمانها بهتر است سیاستی در ویش بگیرند که هسته تیم تا جای ممکن حفظ شود و بجای انتقال افراد تیم از محصولی به محصولی دیگر جابجا شود، جابجایی تیم خوش ترکیب صرفه اقتصادی بیشتری دارد تا افراد(انحلال تیم‌های که طبق انتظار یا بد کارند صرفه اقتصادی دارد) تحزیه تیم اسکرام خوب جهت گسترش اسکرام در سازمان وحود دارد. استراتژی «تقسیم و کاشتن»
#scrum
@code_crafters
-تنبلی اجتماعی کاهش می‌یابد.این تصور که یکنفر هست کارها را به هرحال انجام دهد
-تعاملات سازنده بیشتر است
-زمان کمتری صرف هماهنگی کارها میشود
-اعضای تیم‌های کوچک از سایر هم تیمی‌های خود رضایت بیشتری دارند
-احتمال انجام تخصصی بیش از حد بعضی کارها کاهش می‌یابد
تیمی بسیار کوچک است که افراد کافی برای انجام کار نداشته باشد یا اعضا بقدری کم باشند که نتوانند به شکلی کارا و موثر کار کنند. این مسیله به معنای ناسازگاری اسکرام برای کارهای بزرگ نیست منتها بجای یک تیم ۳۶ نفره چهار تیم ۹ نفره خواهیم داشت.شاخص بزرگی پروژه‌های اسکرام،بزرگی تیم توسعه نیست بلکه تعداد تیم‌های اسکرام است.تیم‌ها میتوانند با رویکرد اسکرام اسکرام‌ها تعامل و جلسات روزانه برگذار کنند که اعضای تیم‌ها باهم جمع می‌شوند
۸-دارای تمرکز و تعهد
اعضا باید روی هدف تیم تمرکز داشته و به آن متعهد باشند. تمرکز بدان معناست که هر یک از اعضای تیم مشارکتی فعال و توجه خود را معطوف به هدف تیم کرده باشند. متعهد نیز یعنی اعضای تیم چه شرایط خوب و چه بد خود را وقف هدف تیم کرده کنند.این دو موضوع هنگام کار بر روی یک محصول امکان پذیر است اما اگر فرد روی چند محصول کار کند باید زمان خود را تقسیم کند و این موجب کاهش تمرکز و تعهد میشود.انجام کار با کیفیت برای کسی که از محصولی به محصول دیگر پرش میکند دشوار است و دشوارتر از آن تعهد واقعی و همزمان به چندین محصول است.داده‌ها نشان می‌دهد بهره‌وری بر روی دو پروژه بهتر و بیشتر است و زمانی که یک پروژه موقتا متوقف شود کار بر روی دومی موجب میشود که فرد بیکار نباشد.همچنین این داده‌ها نشان می‌دهد که کار بر روی بیشتر از ۳ پروژه یک تصمیم اقتصادی اشتباه است چونکه بیشتر تایم صرف یادآوری و هماهنگی و ... می‌گردد.پس تکلیف متخصصانی که معمولا باید بر روی چندین محصول کار کنند چه میشود اجازه بدهید که او خود تصمیم بگیرد و متعهد شود به انجام کار و اگر تصمیم رد کردن او از دیدگاه کسب و کار قابل قبول نباشد چند راهکار وجود دارد:اول اینکه پروژه‌های کمتری بگیرید، افراد بیشتری استخدام کنید، روی افزایش مهارت سایر افراد کار کنید و یا ترکیبی از این موارد را انجام دهید
۹-کار با آهنگی پایدار
یکی از اصول اسکرام کار با آهنگی پایدار توسط اعضا است که موجب محصولاتی در کلاس جهانی تولید کنند و محیطی سالم و شاد داشته باشند. در توسعه ترتیبی یکپارچه سازی و آزمون تا اواخر کار به تعویق می‌افتد که خود منجر به حجم فشار کار در فازهای بعدی میشود که برای جبران کار از شب بیداری و استفاده از تعطیلی های خود بهره میبرند.این مورد را با اسکرام مقایسه کنید که تمامی موارد باید در هر اسپرینت صورت گیرد و با توجه به تعریف ما از «انجام شده» مطابقت داشته باشد. فشار کار در هر اسپرینت باید شبیه اسپرینت قبلی باشد تا تضمینی بر آهنگ پایدار کار باشد که نتیجه آن کار با بسته‌های بزرگ با سرعت خیلی زیاد و مخصوصا خیلی دیر به تیم محول نمیشود و منجر میشود که در اسکرام اضافه کاری کمتری رخ دهد و تیم خسته و بریده نشود
۱۰- دیرپا
برای اثربخشی اسکرام تیم لازم است،نه گروه
تیم: مجموعه‌ای از افراد با تخصص‌های مختلف که چشم اندازی مشترک و برای دستیابی به آن باهم کار میکنند
گروه: مجموعه از افراد که عنوان مشترکی دارند وجه اشتراک دیگری غیر از نام ندارند و نمی‌توانند مسئولیت تیم توسعه اسکرام را انجام دهند
دیرپا به تیمی گفته میشود که اعضای آن برای مدت طولانی تا جاییکه صرفه اقتصادی داشته باشند حفظ شوند. تیم دیرپا در مقابل تیم تازه کار صرفه اقتصادی بیشتر و بهره وری بهتری دارند و شناخت قبلی بین اعضا اثر مثبتی بر کارایی و کیفیت خروجی‌های تیم داشته باشد که منجر به افزایش دستاوردهای کسب و کار میشود. گروهی از افراد که از قبل همدیگر نمی‌شناسند نیاز به زمان و هزینه است جهت یک تیم واقعی شدن است که باید مراحلی از قبیل شکل‌گیری، تلاطم، قاعده‌مندی، و اجرا را طی کنند تا یک تیم شوند. تیم کارآمد دارایی واقعی کسب و کار است. اعضا می‌دانند چگونه باهم کار کنند و اعتماد هم را جلب کنند همچنین این تیم اطلاعات تاریخی از جمله سرعت و برآورد مشترک دارند، تیم منحل شده یا دچار تغییرات اساسی شده این اطلاعات را ندارد. سازمانهایی که جابجایی زیاد دارند یک اصل اسکرام را فراموش کرده‌اند مبنای چابکی تیم است یکی از ارزش‌های اصلی چابکی «افراد و تعاملات» است.سازمانها بهتر است سیاستی در ویش بگیرند که هسته تیم تا جای ممکن حفظ شود و بجای انتقال افراد تیم از محصولی به محصولی دیگر جابجا شود، جابجایی تیم خوش ترکیب صرفه اقتصادی بیشتری دارد تا افراد(انحلال تیم‌های که طبق انتظار یا بد کارند صرفه اقتصادی دارد) تحزیه تیم اسکرام خوب جهت گسترش اسکرام در سازمان وحود دارد. استراتژی «تقسیم و کاشتن»
#scrum
@code_crafters
👍4
خب تا اینجای کار که اومدیم
و طبق متن‌های بالا ما به تعریف از تیم پی بردیم و دید مهندسی نرم افزار مدرن الان میدونیم تیم به چه معناست
یکی از اصول میکروسرویس وجود تیم اجایل هستش و شما بدون اجایل درواقع میکروسرویس ندارین هرچقدر هم میکروسرویسی کد بزنید بازهم بدون تیم اجایل شما میکروسرویس ندارید و پروژه شکست خورده هستش
به چه دلایلی؟؟؟
ابتدا تعریف خود تیم و چندتخصصی بودن که منجر میشه ویژگی‌های خوب توسعه ندید و بدون ویژگی خوب شما فقط محصول تولید کردین، نه یک محصول درست رو
نبود دانش کافی و ناظر بر پروژه مطابق استانداردهای مختلف داخلی و بیرونی
نبود مدیران رده بالا در تعیین ابزارهای راهبردی و زیرساختی و از همه مهمتر تعیین سطح استاندارد ویژگی‌های پروژه
دیدگاه تک بعدی فقط فنی در پروژه که آفت و بلای هر پروژه و سازمان هستش، شما چه دوست داشته باشید چه نه کسب و کار مهمتر از بخش فنی هستش
درگیر سیستم سنتی شدن که در نهایت باعث میشه بدهی فنی بالا داشته باشید و یک محصول شبیه محصول صنعتی ارائه بدید نه یک محصول نرم افزاری
در هر صورت با هر قیمتی و هر زمان و تایمی که بر روی میکروسرویس نوشتن یک پروژه صرف کرده باشد (شما فرض بگیرید یکنفر در صد سال زندگیش) اگه خارج از اجایل بوده باشه در واقع شما یک محصول بر پایه معماری میکروسرویس ارائه ندادید، حتی اگر هم نوشته باشید هم چون معیارهای میکروسرویس رو به شکل کامل نداره پس این قضیه بصورت کامل کنسل هستش
#free
@code_crafters
و طبق متن‌های بالا ما به تعریف از تیم پی بردیم و دید مهندسی نرم افزار مدرن الان میدونیم تیم به چه معناست
یکی از اصول میکروسرویس وجود تیم اجایل هستش و شما بدون اجایل درواقع میکروسرویس ندارین هرچقدر هم میکروسرویسی کد بزنید بازهم بدون تیم اجایل شما میکروسرویس ندارید و پروژه شکست خورده هستش
به چه دلایلی؟؟؟
ابتدا تعریف خود تیم و چندتخصصی بودن که منجر میشه ویژگی‌های خوب توسعه ندید و بدون ویژگی خوب شما فقط محصول تولید کردین، نه یک محصول درست رو
نبود دانش کافی و ناظر بر پروژه مطابق استانداردهای مختلف داخلی و بیرونی
نبود مدیران رده بالا در تعیین ابزارهای راهبردی و زیرساختی و از همه مهمتر تعیین سطح استاندارد ویژگی‌های پروژه
دیدگاه تک بعدی فقط فنی در پروژه که آفت و بلای هر پروژه و سازمان هستش، شما چه دوست داشته باشید چه نه کسب و کار مهمتر از بخش فنی هستش
درگیر سیستم سنتی شدن که در نهایت باعث میشه بدهی فنی بالا داشته باشید و یک محصول شبیه محصول صنعتی ارائه بدید نه یک محصول نرم افزاری
در هر صورت با هر قیمتی و هر زمان و تایمی که بر روی میکروسرویس نوشتن یک پروژه صرف کرده باشد (شما فرض بگیرید یکنفر در صد سال زندگیش) اگه خارج از اجایل بوده باشه در واقع شما یک محصول بر پایه معماری میکروسرویس ارائه ندادید، حتی اگر هم نوشته باشید هم چون معیارهای میکروسرویس رو به شکل کامل نداره پس این قضیه بصورت کامل کنسل هستش
#free
@code_crafters
👍3👎1
CodeCrafters
Video
در مهندسی نرم افزار نوین بیشتر از هرچیزی به کار گروهی و مسئولیت تیمی اشاره شده است. یاد این بخش از سخنان ژیژک افتادم و مجدد این بخش از حرفاش رو نگاه کردم و نگاه عمیقتری به این مسئله انداختم که چرا کل تیم مسئولیت آنچه رخ می‌دهد (شکست و موفقیت) را باید بپذیرد
مدیران محترم، زمانیکه محیط رقابتی ایجاد می‌کنید آنچه ژیژک در این داستان گفته در سطح سازمان شما رخ می‌دهد
مهندسی نرم افزار نوین بدور از فلسفه و جامعه نیست بجای ایجاد محیط رقابتی، محیط مبتنی بر همکاری ایجاد کنید. در کنار تشویق و پیشرفت جایگاه فردی برای کسی که یک تنه عامل پیشرفت و پیشبرد اهداف سازمان است به همان اندازه نیرویی که به مابقی تیم جهت افزایش دانش و ایجاد محیط همکاری کمک میکند رو هم تشویق و پیشرفت جایگاه فردی بدهید با پیاده سازی چنین رفتارهایی در سطح سازمان خود به اعضا نشان دهید که در سازمان شما دسته‌های مختلفی از نیروهای برتر وجود دارد (این نظریه رو هم حتی میتوان در جامعه انسانی دید و تفاوت عمده جوامع جهان سومی و اولی بصورت بارز در تک قطبی بودن آلفای برتر و چندقطبی بودن آلفای برتر وجود دارد)
مراقب باشید که برخی از نیروهای شما از ایجاد چنین محیطی جهت منفعت شخصی سواستفاده نکنند
خودخواهی و فردطلبی را در سازمان شناسایی کنید و قاطعانه با آن برخورد کنید اجازه رشد چنین تفکراتی را ندهید و در صورت لزوم در سیاست نامه سازمانی خود قوانینی جهت مقابله با آن مشخص کنید
در صورت رخ داد هر مشکلی، یکی از اعضا رو مورد خطاب و یا مسیول نبینید بلکه تیم را جمع کرده و در سطح تیم بررسی کنید موضوع رو
#free
@code_crafters
مدیران محترم، زمانیکه محیط رقابتی ایجاد می‌کنید آنچه ژیژک در این داستان گفته در سطح سازمان شما رخ می‌دهد
مهندسی نرم افزار نوین بدور از فلسفه و جامعه نیست بجای ایجاد محیط رقابتی، محیط مبتنی بر همکاری ایجاد کنید. در کنار تشویق و پیشرفت جایگاه فردی برای کسی که یک تنه عامل پیشرفت و پیشبرد اهداف سازمان است به همان اندازه نیرویی که به مابقی تیم جهت افزایش دانش و ایجاد محیط همکاری کمک میکند رو هم تشویق و پیشرفت جایگاه فردی بدهید با پیاده سازی چنین رفتارهایی در سطح سازمان خود به اعضا نشان دهید که در سازمان شما دسته‌های مختلفی از نیروهای برتر وجود دارد (این نظریه رو هم حتی میتوان در جامعه انسانی دید و تفاوت عمده جوامع جهان سومی و اولی بصورت بارز در تک قطبی بودن آلفای برتر و چندقطبی بودن آلفای برتر وجود دارد)
خودخواهی و فردطلبی را در سازمان شناسایی کنید و قاطعانه با آن برخورد کنید اجازه رشد چنین تفکراتی را ندهید و در صورت لزوم در سیاست نامه سازمانی خود قوانینی جهت مقابله با آن مشخص کنید
در صورت رخ داد هر مشکلی، یکی از اعضا رو مورد خطاب و یا مسیول نبینید بلکه تیم را جمع کرده و در سطح تیم بررسی کنید موضوع رو
#free
@code_crafters
👍3
ساختارهای تیم اسکرام
مرور
اگر در حال توسعه یک پروژه کوچک هستید فقط کافیست تیم چندتخصصی به همراه یک مالک و استاد داشته باشید. اما کار بر روی پروژه‌های بزرگ و سازمانها با نیروی زیاد نیاز به ایجاد هماهنگی بین تیم‌ها دارد چونکه کار اشتراک صورت میگیرد. نحوه سازماندهی این تیم‌ها که کارایی بالایی داشته باشند رو با در نظر گرفتن چند عامل پاسخ می‌دهیم. اول اینکه از بین تیم‌های ویژگی محور یا مولفه محور کدام یک برای شما مناسب است دوم اینکه برای هماهنگ کردن فعالیت‌های بین چند تیم از چه رویکردهایی میتوانید استفاده کنید
مقایسه تیم‌های ویژگی محور با مولفه محور
تیم ویژگی محور تیمی چندتخصصی و چند مولفه‌ای است که میتواند ویژگی‌ها را از یک‌لاگ برداشته و تکمیل نماید، در حالیکه تیم مولفه محور مسئول توسعه یک مولفه یا زیرسیستم است و فقط میتواند قسمتی از ویژگی درخواستی و نه همه آن را تکمیل نماید.
به تیم‌های مولفه محور، تیم‌های دارایی محور یا تیم‌های زیرسیستم هم گفته میشود که از افرادی با تخصص‌های مشابه و مهارتی ویژه تشکیل شده‌اند. گزارش خود را به یک مدیر وظیفه‌ای گزارش داده و بعنوان منبعی مشترک و متمرکز برای سایر تیم‌ها کار میکند. نمونه این تیم‌ها واحد متمرکز «طراحی تجربه کاربر» است که رابط کاربر را برای سایر تیم‌ها طراحی میکند. اسکرام طرفدار تیم‌های ویژگی محور است اما سازمانها علاقه به مولفه محور دارند با این دیدگاه که یک تیم متخصص توسعه قسمت خود را برعهده گرفته و مسئولیت آن را برعهده بگیرد تا تیم چندتخصصی که ممکن است کد را بهم بزند. تصویر اول در کامنت
در این نمونه تیم ویژگی محور وجود ندارد لذا اقلام از بک‌لاگ برداشته شده و به تیم‌های مولفه محور سپرده میشود. تقسیم بندی توسط تیم‌های مولفه محور به صورت دسته جمعی یا احتمالا توسط یک معمار انجام میشود. سپس هر قلم در بک‌لاگ محصول یکی از تیم‌ها قرار میگیرد و شروع به اجرای بک‌لاگ میکنند اما تکمیل نمی‌کنند. تکمیل ان با روش اسکرام اسکرام‌ها در نهایت تکمیل می‌گرد. چنین رویکردی که یک کانال برای ورود درخواست‌های محصول به تیم‌های مولفه محور وجود داشته باشد. تجربه نشان داده است که سازمانها بعد از روی زمین ماندن ویژگی پی میبرند که چنین تیم‌هایی کاربرد ندارند. تعداد نقاط شکست در تیم‌های مولفه محور به اندازه تعداد تیم‌های موجود است برخلاف آن در تیم‌های ویژگی محور یک نقطه شکست وجود دارد. در تیم‌های مولفه محور نمی‌توان زمان قطعی ارائه داد و انجام شدن یا نشدن یک ویژگی را مشخص کرد. در تیم‌های ویژگی محور خوش ترکیب باشند و به مرور زمان مالکیت مشترکی نسبت به کد پیدا کنند و بتوانند در قالب یک گروه به متولیان قابل اعتمادی برای کد تبدیل شوند، مشکلاتی از قبیل بهم‌ریختگی کد و بدهی فنی و ... برطرف خواهد شد. یکی از رویکردهای موقتی در دستیابی به تیم‌های ویژگی محور که مالکیت مشترکی بر کد داشته باشند در تصویر دوم در کامنت می‌بینید. در اینجا یک تیم ویژگی محور داریم که میتواند اقلام با ارزش را از بک لاگ برداشته و تکمیل نماید، مسئولیت و مدیریت جزییات برعهده این تیم است. تیم‌های مولفه محور مورد اعتماد همچنان باقی می‌مانند تا به حفظ یکپارچگی مولفه‌ها کمک کنند. بک‌لاگ آنها حاوی کارهای فنی است در هر یک از مولفه‌ها انجام شوند. از هر تیم مولفه محور یکنفر در تیم‌ویژگی محور حصگضور دارد. این موجب رویکرد بذرافشان و دروگر میشود. فرد در تیم ویژگی محور دانش خود را به تیم انتقال می‌دهد جهت مالکیت مشترک کد (بذرافشانی)، تیم مولفه محور هم تغییرات مورد نیاز تیم ویژگی محور گردآوری کرده و با همکاران خود در خصوص آن گفتگو کرده و هرکدام نیز به نوبه خود از تیم‌های دیگر گرداوری کرده‌اند. تیم مولفه محور مطمئن میشود که تغییرات در مولفه‌ها برای رفع نیازهای تیم‌های ویژگی محور انجام خواهد شدهماهنگ و تحت کنترل، که منجر به تغییرات به شیوه منسجم و بدون تعارض تا از یکپارچگی مفهومی آن مطمئن گردند. یکی از مشکلات در شرکتهای بزرگ برای مثال که ۵۰ تیم مولفه محور دارند در چنین مواقعی چندتیم ویژگی محور ساخته میشود و اعضای هر تیم متشکل از اعضای مولفه‌هایی است که بیشتر باهم در ارتباط هستند و جهت هماهنگی بین آنها از تیم‌های چندگانه بهره میبریم، یکی دیگر از مشکلات این است که ممکن است یکی از تیم‌های مولفه محور تنها ۴ عضو داشته باشد که نمیتوانیم آنها را بشکنیم در این مواقع افراد با مهارت بالاتر استخدام میکنیم یا تعداد محصولات در حال توسعه را کاهش می‌دهیم یا اموزش مولفه به تعداد بیشتر یا بهتر از همه ارتقا سطح مالکیت مشترک کد. هیچ راه حل جامعی برای ترکیب دو تیم وجود ندارد اما بهتر است تیم ویژگی محور داشته باشیم و در کنارش تیم مولفه محور به شرط توجیه اقتصادی داشتن اما تجربه نشان داده اکثر سازمانها خلاف ان را انجام می‌دهند
#scrum
@code_crafters
مرور
اگر در حال توسعه یک پروژه کوچک هستید فقط کافیست تیم چندتخصصی به همراه یک مالک و استاد داشته باشید. اما کار بر روی پروژه‌های بزرگ و سازمانها با نیروی زیاد نیاز به ایجاد هماهنگی بین تیم‌ها دارد چونکه کار اشتراک صورت میگیرد. نحوه سازماندهی این تیم‌ها که کارایی بالایی داشته باشند رو با در نظر گرفتن چند عامل پاسخ می‌دهیم. اول اینکه از بین تیم‌های ویژگی محور یا مولفه محور کدام یک برای شما مناسب است دوم اینکه برای هماهنگ کردن فعالیت‌های بین چند تیم از چه رویکردهایی میتوانید استفاده کنید
مقایسه تیم‌های ویژگی محور با مولفه محور
تیم ویژگی محور تیمی چندتخصصی و چند مولفه‌ای است که میتواند ویژگی‌ها را از یک‌لاگ برداشته و تکمیل نماید، در حالیکه تیم مولفه محور مسئول توسعه یک مولفه یا زیرسیستم است و فقط میتواند قسمتی از ویژگی درخواستی و نه همه آن را تکمیل نماید.
به تیم‌های مولفه محور، تیم‌های دارایی محور یا تیم‌های زیرسیستم هم گفته میشود که از افرادی با تخصص‌های مشابه و مهارتی ویژه تشکیل شده‌اند. گزارش خود را به یک مدیر وظیفه‌ای گزارش داده و بعنوان منبعی مشترک و متمرکز برای سایر تیم‌ها کار میکند. نمونه این تیم‌ها واحد متمرکز «طراحی تجربه کاربر» است که رابط کاربر را برای سایر تیم‌ها طراحی میکند. اسکرام طرفدار تیم‌های ویژگی محور است اما سازمانها علاقه به مولفه محور دارند با این دیدگاه که یک تیم متخصص توسعه قسمت خود را برعهده گرفته و مسئولیت آن را برعهده بگیرد تا تیم چندتخصصی که ممکن است کد را بهم بزند. تصویر اول در کامنت
در این نمونه تیم ویژگی محور وجود ندارد لذا اقلام از بک‌لاگ برداشته شده و به تیم‌های مولفه محور سپرده میشود. تقسیم بندی توسط تیم‌های مولفه محور به صورت دسته جمعی یا احتمالا توسط یک معمار انجام میشود. سپس هر قلم در بک‌لاگ محصول یکی از تیم‌ها قرار میگیرد و شروع به اجرای بک‌لاگ میکنند اما تکمیل نمی‌کنند. تکمیل ان با روش اسکرام اسکرام‌ها در نهایت تکمیل می‌گرد. چنین رویکردی که یک کانال برای ورود درخواست‌های محصول به تیم‌های مولفه محور وجود داشته باشد. تجربه نشان داده است که سازمانها بعد از روی زمین ماندن ویژگی پی میبرند که چنین تیم‌هایی کاربرد ندارند. تعداد نقاط شکست در تیم‌های مولفه محور به اندازه تعداد تیم‌های موجود است برخلاف آن در تیم‌های ویژگی محور یک نقطه شکست وجود دارد. در تیم‌های مولفه محور نمی‌توان زمان قطعی ارائه داد و انجام شدن یا نشدن یک ویژگی را مشخص کرد. در تیم‌های ویژگی محور خوش ترکیب باشند و به مرور زمان مالکیت مشترکی نسبت به کد پیدا کنند و بتوانند در قالب یک گروه به متولیان قابل اعتمادی برای کد تبدیل شوند، مشکلاتی از قبیل بهم‌ریختگی کد و بدهی فنی و ... برطرف خواهد شد. یکی از رویکردهای موقتی در دستیابی به تیم‌های ویژگی محور که مالکیت مشترکی بر کد داشته باشند در تصویر دوم در کامنت می‌بینید. در اینجا یک تیم ویژگی محور داریم که میتواند اقلام با ارزش را از بک لاگ برداشته و تکمیل نماید، مسئولیت و مدیریت جزییات برعهده این تیم است. تیم‌های مولفه محور مورد اعتماد همچنان باقی می‌مانند تا به حفظ یکپارچگی مولفه‌ها کمک کنند. بک‌لاگ آنها حاوی کارهای فنی است در هر یک از مولفه‌ها انجام شوند. از هر تیم مولفه محور یکنفر در تیم‌ویژگی محور حصگضور دارد. این موجب رویکرد بذرافشان و دروگر میشود. فرد در تیم ویژگی محور دانش خود را به تیم انتقال می‌دهد جهت مالکیت مشترک کد (بذرافشانی)، تیم مولفه محور هم تغییرات مورد نیاز تیم ویژگی محور گردآوری کرده و با همکاران خود در خصوص آن گفتگو کرده و هرکدام نیز به نوبه خود از تیم‌های دیگر گرداوری کرده‌اند. تیم مولفه محور مطمئن میشود که تغییرات در مولفه‌ها برای رفع نیازهای تیم‌های ویژگی محور انجام خواهد شدهماهنگ و تحت کنترل، که منجر به تغییرات به شیوه منسجم و بدون تعارض تا از یکپارچگی مفهومی آن مطمئن گردند. یکی از مشکلات در شرکتهای بزرگ برای مثال که ۵۰ تیم مولفه محور دارند در چنین مواقعی چندتیم ویژگی محور ساخته میشود و اعضای هر تیم متشکل از اعضای مولفه‌هایی است که بیشتر باهم در ارتباط هستند و جهت هماهنگی بین آنها از تیم‌های چندگانه بهره میبریم، یکی دیگر از مشکلات این است که ممکن است یکی از تیم‌های مولفه محور تنها ۴ عضو داشته باشد که نمیتوانیم آنها را بشکنیم در این مواقع افراد با مهارت بالاتر استخدام میکنیم یا تعداد محصولات در حال توسعه را کاهش می‌دهیم یا اموزش مولفه به تعداد بیشتر یا بهتر از همه ارتقا سطح مالکیت مشترک کد. هیچ راه حل جامعی برای ترکیب دو تیم وجود ندارد اما بهتر است تیم ویژگی محور داشته باشیم و در کنارش تیم مولفه محور به شرط توجیه اقتصادی داشتن اما تجربه نشان داده اکثر سازمانها خلاف ان را انجام می‌دهند
#scrum
@code_crafters
👍3
ایجاد هماهنگی بین چند تیم
با افزایش تعداد اعضای تیم‌های توسعه ابعاد استفاده از اسکرام افزایش نمی‌یابد بلکه باید تعداد تیم‌هایی که اندازه مناسبی دارند افزایش یابد. داشتن بیش از یک تیم چالش هماهنگی ایجاد میکند که دو رویکرد برا آن داریم «اسکرام اسکرام‌ها» و «قطار انتشار»
اسکرام اسکرام‌ها
در اسکرام روزانه اعضای تیم حضور دارند. یکی از روش‌های متداول هماهنگی بین چند تیم اسکرام اسکرام‌ها (SoS) این است که از هر تیم یکنفر نماینده که میتواند با بقیه ارتباط گرفتن و کارها را گزارش دهد در جلسه SoS حضور یابد (بهتر است این نفر ثابت باشد)، در برخی تیم‌ها استاد مشترک چندتیم را هم به همراه نماینده می‌فرستند اما مراقب هستند تعداد زیاد نشود تعیین استاد اسکرام اسکرام‌ها هم بسیار منطقی است. جلسات مربوط به ان چند روز در هفته برگذار میشود نه هر روزه و نحوه برگذاری آن هم رویکردهای خاص خودش را دارد اما سوالات زیر مطرح است
جلسات آن ۱۵ دقیقه است و بحث در خصوص مسایل را بعد از ان انجام می‌دهند تا افراد علاقمند و مورد نیاز حضور داشته باشند. اگر گروه‌های مختلف در اسکرام اسکرام را خوشه بندی کنیم.
قطار انتشار
رویکردی جهت همسو کردن چشم انداز، برنامه ریزی و ارتباط بین تیم‌ها به کمک ایجاد هماهنگی بین آنها و بر اساس راه اندازی آهنگی مشترک است که هدف آن ایجاد روندی سریع و منعطف برای محصولات بزرگ است. تمام تیم‌ها در این رویکرد موظف هستند که کار خود را در زمانی مشخص تحویل دهند، که قواعدی دارد:
قطار انتشار شامل سبد محصول و سطوح انتشار میشود که دارای سه سطح است: بک لاگ سبد محصول(اپیک‌هایی که مالکیت آن با مدیریت آن است)، بک لاگ برنامه(ویژگی‌هایی که مالکیت آن با مدیرت آن است)، بک لاک تیم(داستان‌های کاربر قابل انجام در یک اسپرینت که با ماک محصول است)می‌باشد تصویر اول در کامنت
۹ تیم در قالب ۳ خوشه که با اسکرام اسکرام‌ها پیش می‌روند.در هر زمان ممکن باید ازمون و یکپارچه سازی سیستم به نحوی انجام شود که همه ویژگی‌های ویژگی را در بر بگیرد. مدت اسپرینت برای تمام تیم‌ها یکسان است که موجب ایجاد هماهنگی در تمامی تیم‌ها میشود. هر PSI (هر انتشار بعد از تعداد معینی اسپرینت که معمولا ۴ اسپرینت است) آماده میشود. این زمان بندی به سازمان کمک میکند هماهنگی اتی خود را انجام دهد که در زمان تعیین شده انتشار میتواند:
را داشته باشد
هر قطار انتشار با برگزاری جلسه برنامه ریزی انتشار آغاز میشود که همه تیم‌هایی که روی PSI کار میکنند در ان حاضرند.
در یک اتاق بزرگ مالک ارشد PSI را ارائه داده و هر تیم کنار هم نشسته و تیم‌هایی که در یک گروه ویژگی قرار دارند نزدیک هم می‌نشینند تیم‌های حاضر در یک گروه دور هم جمع شده و مالکان آنها تصویر مربوط به به خود برای انتشار بعدی را ارائه می‌دهند و تیم‌ها نگاشت اسپرینت (قراردادن ویژگی‌ها در اسپرینت‌ها) میکنند جهت هماهنگی بیشتر هرزگاهی یکی از اعضای تیم به تیم‌های دیگر رفته و از انها میپرسد آیا میتوانند این ویژگی را در همین قطار انتشار انجام دهند و با دریافت تایید تیم متعهد به انجام آن میشود. جهت اطمینان از درک بیشتر قطار انتشار مالک ارشد، مالکان گروه ویژگی و معماران به میان تیم‌های دیگر می‌روند البته تیم‌ها نیز میتوانند درخواست کمک از آنها را ارائه دهند. پس از پایان اسپرینت‌ها به نقطه انتشار PSI میرسیم. در این نقطه فعالیت بازرسی و تطبیق در سطح قطار انتشار را انجام می‌دهیم اولین فعالیت بازبینی کل بار قطار انتشار و دومی بازاندیشی در سطح قطار انتشار است
#scrum
@code_crafters
با افزایش تعداد اعضای تیم‌های توسعه ابعاد استفاده از اسکرام افزایش نمی‌یابد بلکه باید تعداد تیم‌هایی که اندازه مناسبی دارند افزایش یابد. داشتن بیش از یک تیم چالش هماهنگی ایجاد میکند که دو رویکرد برا آن داریم «اسکرام اسکرام‌ها» و «قطار انتشار»
اسکرام اسکرام‌ها
در اسکرام روزانه اعضای تیم حضور دارند. یکی از روش‌های متداول هماهنگی بین چند تیم اسکرام اسکرام‌ها (SoS) این است که از هر تیم یکنفر نماینده که میتواند با بقیه ارتباط گرفتن و کارها را گزارش دهد در جلسه SoS حضور یابد (بهتر است این نفر ثابت باشد)، در برخی تیم‌ها استاد مشترک چندتیم را هم به همراه نماینده می‌فرستند اما مراقب هستند تعداد زیاد نشود تعیین استاد اسکرام اسکرام‌ها هم بسیار منطقی است. جلسات مربوط به ان چند روز در هفته برگذار میشود نه هر روزه و نحوه برگذاری آن هم رویکردهای خاص خودش را دارد اما سوالات زیر مطرح است
-تیم من از آخرین جلسه قبلی چه کاری انجام داده است که ممکن است تیم‌های دیگر را تحت تاثیر قرار دهد؟
-تیم من تا جلسه بعدی چه کاری انجام می‌دهد که احتمالا تیم‌های دیگر را تحت تاثیر قرار می‌دهد؟
-تیم من چه مشکلاتی دارد و برای حل آنها ممکن است به کمک تیم‌های دیگر نیاز داشته باشد؟
جلسات آن ۱۵ دقیقه است و بحث در خصوص مسایل را بعد از ان انجام می‌دهند تا افراد علاقمند و مورد نیاز حضور داشته باشند. اگر گروه‌های مختلف در اسکرام اسکرام را خوشه بندی کنیم.
قطار انتشار
رویکردی جهت همسو کردن چشم انداز، برنامه ریزی و ارتباط بین تیم‌ها به کمک ایجاد هماهنگی بین آنها و بر اساس راه اندازی آهنگی مشترک است که هدف آن ایجاد روندی سریع و منعطف برای محصولات بزرگ است. تمام تیم‌ها در این رویکرد موظف هستند که کار خود را در زمانی مشخص تحویل دهند، که قواعدی دارد:
-تاریخ‌های برنامه ریزی و تاریخ انتشارهای متناوب و دوره‌ای راهکار تعیین شده باشند
-مدت تکرار در تیم‌ها یکسان است
-مایلستونهای میانی و کلی با هدفی تعیین شده باشند
-یکپارچه سازی علاوه در سطح ویژگی و مولفه، در سطح کلان یا سیستم نیز انجام شود
-بخش‌های قابل انتشار که به آن PSI گفته میشود در فواصل زمانی ۳ یا ۴ ماه جهت نمایش برای مشتری، تضمین کیفیت در سطح سیستم و بازنگری داخلی آماده باشند
-از تکرار تثبیت جهت کاهش بدهی فنی و اختصاص زمان برای ازمون و اعتبارسنجی خاصی در انتشار استفاده شود
-جهت کار تیم‌ها در بستری یکسان مولفه‌های زیرساختی مشخصی همچو رابط‌ها، بسته‌های توسعه سیستم، ابزارهای نصب و محوزدهی، تحربه کاربر و خدمات پایه اینترنتی در دستور کار قرار گیرند
قطار انتشار شامل سبد محصول و سطوح انتشار میشود که دارای سه سطح است: بک لاگ سبد محصول(اپیک‌هایی که مالکیت آن با مدیریت آن است)، بک لاگ برنامه(ویژگی‌هایی که مالکیت آن با مدیرت آن است)، بک لاک تیم(داستان‌های کاربر قابل انجام در یک اسپرینت که با ماک محصول است)می‌باشد تصویر اول در کامنت
۹ تیم در قالب ۳ خوشه که با اسکرام اسکرام‌ها پیش می‌روند.در هر زمان ممکن باید ازمون و یکپارچه سازی سیستم به نحوی انجام شود که همه ویژگی‌های ویژگی را در بر بگیرد. مدت اسپرینت برای تمام تیم‌ها یکسان است که موجب ایجاد هماهنگی در تمامی تیم‌ها میشود. هر PSI (هر انتشار بعد از تعداد معینی اسپرینت که معمولا ۴ اسپرینت است) آماده میشود. این زمان بندی به سازمان کمک میکند هماهنگی اتی خود را انجام دهد که در زمان تعیین شده انتشار میتواند:
-تصمیم گیری بر اساس منافع کسب و کار جهت استقرار PSI
-فرصت برای تایید صحت یکپارچگی و آزمون کارهای گروه‌های مختلف
-درخواست بازنگری داخلی
را داشته باشد
هر قطار انتشار با برگزاری جلسه برنامه ریزی انتشار آغاز میشود که همه تیم‌هایی که روی PSI کار میکنند در ان حاضرند.
در یک اتاق بزرگ مالک ارشد PSI را ارائه داده و هر تیم کنار هم نشسته و تیم‌هایی که در یک گروه ویژگی قرار دارند نزدیک هم می‌نشینند تیم‌های حاضر در یک گروه دور هم جمع شده و مالکان آنها تصویر مربوط به به خود برای انتشار بعدی را ارائه می‌دهند و تیم‌ها نگاشت اسپرینت (قراردادن ویژگی‌ها در اسپرینت‌ها) میکنند جهت هماهنگی بیشتر هرزگاهی یکی از اعضای تیم به تیم‌های دیگر رفته و از انها میپرسد آیا میتوانند این ویژگی را در همین قطار انتشار انجام دهند و با دریافت تایید تیم متعهد به انجام آن میشود. جهت اطمینان از درک بیشتر قطار انتشار مالک ارشد، مالکان گروه ویژگی و معماران به میان تیم‌های دیگر می‌روند البته تیم‌ها نیز میتوانند درخواست کمک از آنها را ارائه دهند. پس از پایان اسپرینت‌ها به نقطه انتشار PSI میرسیم. در این نقطه فعالیت بازرسی و تطبیق در سطح قطار انتشار را انجام می‌دهیم اولین فعالیت بازبینی کل بار قطار انتشار و دومی بازاندیشی در سطح قطار انتشار است
#scrum
@code_crafters
❤3
مدیران
مرور
یکی از ترس‌های مانع اجرای اسکرام از دست دادن کنترل مدیریتی است، اسکرام به مدیریت اشاره نکرده اما این به این معنا نیست که سیستم مدیریتی در آن وجود ندارد. در هر سازمان اسکرامی مدیران کماکان مسئولیت‌های مهمی برعهده دارند. مدیران وظیفه ساماندهی و پرورش تیم‌ها، هماهنگی و تطبیق با محیط بیرونی و مدیریت جریان ایجاد ارزش را برعهده دارند. تصویر اول در کامنت
ساماندهی تیم‌ها
مدیران با فرآیندی که شامل تعیین مرزهای، تعیین اهداف شفاف، شکل دادن تیم‌ها، تغییر ترکیب و توانمندسازی آنها تیم ها را سازماندهی میکنند
پرورش تیم
بعد از تشکیل تیم مدیران باید روی به افراد انگیزه و انرژی بدهند بر روی توسعه توانایی‌ها و شایستگی‌های انها کار کنند، تیم را در حوزه وظیفه‌ای رهبری و یکپارچگی و انسجام آن را حفظ کنند
#scrum
@code_crafters
مرور
یکی از ترس‌های مانع اجرای اسکرام از دست دادن کنترل مدیریتی است، اسکرام به مدیریت اشاره نکرده اما این به این معنا نیست که سیستم مدیریتی در آن وجود ندارد. در هر سازمان اسکرامی مدیران کماکان مسئولیت‌های مهمی برعهده دارند. مدیران وظیفه ساماندهی و پرورش تیم‌ها، هماهنگی و تطبیق با محیط بیرونی و مدیریت جریان ایجاد ارزش را برعهده دارند. تصویر اول در کامنت
ساماندهی تیم‌ها
مدیران با فرآیندی که شامل تعیین مرزهای، تعیین اهداف شفاف، شکل دادن تیم‌ها، تغییر ترکیب و توانمندسازی آنها تیم ها را سازماندهی میکنند
-تعیین مرزها
تیم خودسازمانده میداند که بدون مدیر چگونه مسئولیت خود را زیر نظر مدیران انجام دهد. اما بندرت پیش می‌آید در خصوص تولید چه محصولی تصمیم بگیرد، این برعهده مدیران است و تیم در مرزی محدود فعالیت و خودسازمانده است. برای مثال سازمانی که سیستم حسابداری انجام می‌دهد مدیران تعیین میکنند چه نوع برنامه‌ای باشد و برای تعیین مرزها یکی از دو گزینه را انتخاب میکنند: تیم توسعه محصول را به تیم استقرار تحویل می‌دهد تا بعد از اسپرینت مستقر شود یا تیم استقرار ان را بعنوان بخشی از اسپرینت انجام دهد
-تعیین اهداف شفاف
مدیران تعیین کننده اهداف تیم هستند که موجب میشود تیم انگیزه و جهت بگیرد. مالک مسئول تعریف دقیقتر آن است
-تشکیل تیم
مدیران تعیین میکنند چه کسی عضو تیم باشد و ترکیب تیم را مشخص میکنند تیم تنها مشارکت میکند در مصاحبه با نفر جدید اما تصمیم نهایی را مدیران متناسب با نیازها و محدودیت‌های کسب و کار میگیرن. مدیران وظیفه‌ای نمایندگی بخش‌های مختلف فنی یا گروه‌های تخصصی را برعهده دارند و به کمک همدیگر، اعضای تیم‌های چندتخصصی را انتخاب میکنند که ساختار تی شکل دارند. تصویر دوم در کامنت
-تغییر ترکیب تیم
اگر مدیران به این نتیجه برسند که با تغییر ترکیب تیم شرایط و کارایی تیم یا سازمان بهتر میشود موظفند که ترکیب را تغیرر دهند. برای مثال فرد ناسازگار در تیم ابتدا گروه سعی میکنند او را بهتر کنند در غیر اینصورت استاد این تلاش را میکند و در غیر این صورت مدیری که فرد به او مستقیم گزارش می‌دهد را مطلع میکنند و او با هماهنگی منابع انسانی سعی در بهبود او با توجیه بچیا جابجایی انجام می‌دهند در غیر این صورت سازمان را ترک میکند. استاد و اعضا توان عزل و نصب ندارند اما در آن مشارکت میکنند. مورد دیگر فردی با توانایی بالاست که برای انتقال دانش خود بین تیم‌های مختلف جابجا میشود در این خصوص مدیران باید دقت کنند چون جابجایی روی هردو تیم تاثیر می‌گذارد
-تفویض اختیار
مدیران برای حفظ خودسازماندهی تیم برخی اختیارات مدیریتی را با تعیین سطح اختیارات به آنها می‌سپارد که در هفت سطح می‌باشد تصویر سوم در کامنت، مدیران بعد از سپردن اختیارات به تیم اجازه ندارند خلاف آن تصمیم بگیرند. مدیران باید کمک کنند که اعضای تیم به یکدیگر اعتماد کنند. لذا نیازمند مشخص کردن محدوده مناسب فعالیتی استکه منجر به اعتماد بین اعضا میشود. از سوی دیگر چون تیم‌ها مدیری ندارند که آنها را موظف به انجام کار کنند، باید به اعضا کمک کنند تا اخمیت انجام تعهدات خود را داشته باشند
پرورش تیم
بعد از تشکیل تیم مدیران باید روی به افراد انگیزه و انرژی بدهند بر روی توسعه توانایی‌ها و شایستگی‌های انها کار کنند، تیم را در حوزه وظیفه‌ای رهبری و یکپارچگی و انسجام آن را حفظ کنند
-انرژی دادن به افراد
مدیران باید مدام به دنبال راه‌هایی برای افزایش انگیزه افراد باشند تا کارها بصورت فوق العاده انجام گیرند. در سایه مدیریت درست، مدیران میتوانند بر انکیزه درونی افراد تاثیر مثبتی بگذارند. در مقابل مدیران وظیفه‌ای از قدیم عادت دارند که کارها را شکسته و به افراد زیردست جهت انجام در حد وظیفه بسپارند این کار در اسکرام به دلیل از بین بردن پایه‌های خودسازماندهی و زیرسوال بردن توانایی تیم در ایجاد ارزش، انرژی اعضای تیم را کاهش می‌دهد
-توسعه شایستگی
در اسکرام افراد تیم مدام گزارش به مدیران وظیفه‌ای ارائه می‌دهند که استاد و مالک نیستند. و مدیران با بازخورد مستمر خود به آنها در نقش مربیگری و دستیابی آنان به اهداف شغلی نقش فعالی دارند. مدیران محیطی ایجاد میکنند که افراد در آن مدام در حال یادگیری و افزایش مهارت هستند. مدیران خیلی شفاف باید بیان کنند که یادگیری مورد تشویق و از اولیت‌های افزاد و تیم و سازمان است. در سازمانها بازخورد معمولا بصورت سالیانه صورت میگیرد که این خلاف ذات اسکرام و بسیار مضر است، بازخورد باید در پایان هر حلقه یادگیری (پایان هر اسپرینت) یعنی زمانی که اعضا به آنها گزارش می‌دهند مناسب و هماهنگ باشد
#scrum
@code_crafters
👍3
-رهبری در حوزه وظیفه‌ای
مدیران وظیفه‌ای، رهبری حوزه عملکردی را برعهده دارند. انها به اعضا نمی‌گویند کار چگونه انجام دهند این منحر به تضعیف تیم خودسازمانده میشود. منتها کار اعضای خود را بازنگری کرده و در تدوین برنامه عملکردی آنها متفکر قضیه است. مدیران وظیفه‌ای خود افراد ماهر و با تجربه در حوزه وظیفه‌ای خودشان هستند. رهبری حوزه را برعهده گرفته تا اطمینان حاصل شود نتایج بارارزش و منسجمی خلق شوند. برای مثال مدیر تضمین کیفیت برای خودکارسازی آزمون‌ها به افراد حوزه خود که عضو تیم‌های اسکرام مختلفی هستند می‌خواهد که در انتخاب ابزار همکاری کنند
-حفظ یکپارچگی
تیم مبنای اصلی سنجش ارزش در چابکی است(تیم به عنوان واحد ظرفیت جایگزین افراد میشود) مدیران باید فعالانه در حفظ یکپارچگی تیم تلاش کنند (نباید افراد را در میانه اسپرینت برای انجام کاری از تیم خارج کنند یا بی‌جهت افراد را وادار بکار در چند تیم کنند) در پایان کار توسعه، مدیران باید کل تیم را یکجا به کار بعدی منتقل کنند
-همسو سازی و تطبیق محیط
برای دستیابی به مزایای اسکرام تمام زنحیره از تامین کننده‌ها تا مشتریان باید چابکی را بپذیرند و این کار با ترویج ارزش‌های چابکی، رفع موانع سازمانی، همسو کردن گروه‌های داخلی و شرکای تجاری انجام میشود
-ترویج ارزش‌های چابک
مدیران باید ارزش‌ها و اصول چابکی را بپذیرند. آنها را بفهمند و باور داشته باشند(پذیرش سختی‌ها و دشواری‌های آن)و دیگران را ترغیب به این کار کنند.
-رفع موانع سازمانی
مدیران باید پا به پای استاد برای رفع موانع سازمانی تلاش کنند. گاها برخی از موانع محیطی است و استاد بدون کمک مدیران نمی‌تواند آنها را رفع کند
-همسو کردن گروه‌های داخلی
اگر در سازمان بخشی اسکرام را پذیرفته و بخشی دیگر نپذیرفته باشد نمی‌توان از تمام مزایای اسکرام استفاده کرد و بهره برد. برای مثال واحد توسعه اسکرام را پذیرفته، اما واحد منابع انسانی نیرو با مهارت تی شکل استخدام نمی‌کند یا گروه استقرار بر پایه ارزش مستقر کردن بخش توسعه بر مبنای اسکرام پیش نمی‌رود. در این مواقع مدیران باید کل سازمان را در نظر داشته باشند و همه را با اصول چابک همسو کند
-همسو کردن شرکای تجاری
مدیران باید به سازمان کمک کنند تا رویکرد چابکتری را در حوزه مدیریت تامین کنندگان و برونسپاری در پیش بگیرد. اگر شیوه مشارکت به سبک سنتی باشد (قراردادهای سنگین و طولانی) نمی‌توان از پتانسیل اسکرام بهره برد. مدیران باید بیشتر از شیوه چابکی در روابط تجاری بهره ببرند. برای مثال بجای قرارداد تحویل و دریافت پروژه، تیم اسکرام از قبل آماده شده سازمان را اجاره کنند.
-مدیریت جریان خلق ارزش
در محیط اسکرامی مدیران مسئول تعیین مسیرهای استراتژیک و کسب اطمینان از تخصیص اقتصادی منابع سازمان برای رسیدن به اهداف استراتژیک هستند. جریان خلق ارزش با تکیه بر دیدگاه سیستمی، مدیریت امور اقتصادی، اندازه گیری و گزارش دهی مدیریت میشود
-اتخاذ دیدگاه سیستمی
جهت مدیریت موثر خلق ارزش، مدیران باید دیدگاه سیستمی داشته باشند.یک چالش اصلی عدم دیدگاه سیستمی مدیران است که علاقه دارند روی حوزه یا روی زمینه مورد علاقه خود تمرکز کنند که موجب میشود از تمام مزایای اسکرام بهره نگیرند، مدیران باید دیدگاه کل نگر داشته باشند
-مدیریت امور اقتصادی
از مدیران انتظار می‌رود در قبال منابع مالی امین و قابل اعتماد باشند.مدیران ارشد در اسکرام کماکان مسیولیت سود و زیان را برعهده دارند. مدیران وظیفه‌ای نیز در قبال چگونگی مصرف منابع مالی تحت اختیارشان مسئول هستند. از مدیران انتظار می‌رود بر امور اقتصادی در سطوح بالاتر سازمان نظارت کنند که در قالب مشارکت آنها در مدیریت سبد محصول و حاکمیت شرکتی نمود پیدا میکند.در هنگام مدیریت سبد محصول تعیین کنند که سرمایه گذاری روی کدام یک از فعالیت‌های توسعه و به چه مقدار انجام شود و ترتیبشان.مدیران مدام بازخوردهای آنی را مبتنی بر توسعه تکراری و تدریجی بازنگری میکنند و نسبت به آن عکس العمل نشان می‌دهند و اگر فعالیتی صرفه اقتصادی نداشته باشد آن را متوقف میکنند
-پایش معیارها و گزارش‌ها
گزارش‌های زیادی جهت بررسی به دست مدیران می‌رسد این فرصتیست که فقط معیارهایی که به جریان خلق ارزش کمک میکنند گرداوری و گزارش شوند.چند نمونه از این گزارش‌ها:
۱- تمرکز بر کارهای نیمه تمام تا افراد بیکار. اندازه گیری تعداد توقف جریان کار بجای موفقیت در مشغول نگه‌داشتن کارمندان.اگر زمان چرخه(زمان شروع و خاتمه کار)در حال افزایش باشد درباره دلایل ان تحقیق کنید
۲-اندازه گیری پیشرفت با دارایی‌هایی که کار میکنند و اعتبارسنجی شده‌اند اما چشم از تاثیرگذاری زمان و محدوده و بودجه و کیفیفت برندارید
۳-ایجاد سازوکاری جهت دریافت سریع بازخوردها.تعیین معیارهایی که موحب اندازه کیری سرعت تکمیل حلقه یادگیری باشد
#scrum
@code_crafters
👍2
مدیران پروژه
نقش مدیران پروژه چیست؟ آیا این نقش در سازمانهای اسکرامی وجود دارد؟
مسیولیت‌های مدیر پروژه در تیم اسکرام
استاد اسکرام با مدیر پروژه متفاوت است، کار هر دوی آنها رفع موانع است اما استاد در نقش خدمتگزار قرار دارد. وظایف ان بر اساس جدول تصویر اول در کامنت است. در صورت نبود مدیر پروژه وظایف آن مطابق جدول تصویر دوم در کامنت است
مدیر پروژه میتواند بر اساس میل و توانایی یکی از نقش‌های اسکرام را بگیرد، اگر انها بتوانند عادت فرماندهی و کنترل را کنار بگذارند استادان اسکرام ممتازی می‌شوند. همانطور که در جداول می‌بینید مالک بیشترین وظایف مدیریت پروژه را برعهده دارد اگر مدیر پروژه دانش کافی در دامنه مساله داشته باشد میتواند نقش مالک را بگیرد و بندرت اگر دانش فنی داشته باشد میتواند عضو تیم توسعه باشد
حفظ نقش مدیر پروژه
در سازمانهایی که بر روی محصولات بزرگ و لجستیکی کار میکنند حضور مدیر پروژه جهت ایحاد هماهنگی مفید است. هرچند که بهتر است تیم‌ها خود آن را انجام دهند چون حضور یکنفر برای اینکار موجب میشود که تیم از مسئولیت خود در این بخش سر باز بزند. در سازمانهای بزرگ با استفاده از اسکرام اسکرام‌ها هماهنگی صورت میگیرد و ارتباطات داخل خوشه توسط تیم انجام میشود اما مابین خوشه‌ای به درستی صورت نمیگیرد مدیر پروژه بعنوان یک خدمتگزار در اینجا مفید است و همچنین جهت ارتباط بین بخش اسکرامی و غیر اسکرامی سازمان، یا ارتباط با بخش بیرون از سازمان. جهت از حفظ مدیر پروژه نگه داشتن نقش او نیست بلکه کسب اطمینان از فهم درست وابستگی‌های موجود بین حوزه‌ها و شکل گیری ارتباط درست بین تیم‌هاست به گونه‌ای که هر تیم بتواند کارش را با سایر تیم‌ها به بهترین شکل ممکن هماهنگ کند. تصویر سوم در کامنت
#scrum
@code_crafters
نقش مدیران پروژه چیست؟ آیا این نقش در سازمانهای اسکرامی وجود دارد؟
مسیولیت‌های مدیر پروژه در تیم اسکرام
استاد اسکرام با مدیر پروژه متفاوت است، کار هر دوی آنها رفع موانع است اما استاد در نقش خدمتگزار قرار دارد. وظایف ان بر اساس جدول تصویر اول در کامنت است. در صورت نبود مدیر پروژه وظایف آن مطابق جدول تصویر دوم در کامنت است
مدیر پروژه میتواند بر اساس میل و توانایی یکی از نقش‌های اسکرام را بگیرد، اگر انها بتوانند عادت فرماندهی و کنترل را کنار بگذارند استادان اسکرام ممتازی می‌شوند. همانطور که در جداول می‌بینید مالک بیشترین وظایف مدیریت پروژه را برعهده دارد اگر مدیر پروژه دانش کافی در دامنه مساله داشته باشد میتواند نقش مالک را بگیرد و بندرت اگر دانش فنی داشته باشد میتواند عضو تیم توسعه باشد
حفظ نقش مدیر پروژه
در سازمانهایی که بر روی محصولات بزرگ و لجستیکی کار میکنند حضور مدیر پروژه جهت ایحاد هماهنگی مفید است. هرچند که بهتر است تیم‌ها خود آن را انجام دهند چون حضور یکنفر برای اینکار موجب میشود که تیم از مسئولیت خود در این بخش سر باز بزند. در سازمانهای بزرگ با استفاده از اسکرام اسکرام‌ها هماهنگی صورت میگیرد و ارتباطات داخل خوشه توسط تیم انجام میشود اما مابین خوشه‌ای به درستی صورت نمیگیرد مدیر پروژه بعنوان یک خدمتگزار در اینجا مفید است و همچنین جهت ارتباط بین بخش اسکرامی و غیر اسکرامی سازمان، یا ارتباط با بخش بیرون از سازمان. جهت از حفظ مدیر پروژه نگه داشتن نقش او نیست بلکه کسب اطمینان از فهم درست وابستگی‌های موجود بین حوزه‌ها و شکل گیری ارتباط درست بین تیم‌هاست به گونه‌ای که هر تیم بتواند کارش را با سایر تیم‌ها به بهترین شکل ممکن هماهنگ کند. تصویر سوم در کامنت
#scrum
@code_crafters
👍2❤1
آدم‌ها وارد زندگی ما نمیشن
بلکه ما از همان دوران کودکی انتخاب میکنیم چه کسانی رو در آینده ملاقات کنیم
جمله‌ای از یونگ هستش که اخیرا ذهنم رو مشغول کرده به خودش
هر چقدر عمیقتر بهش فکر میکنم میزان ترسناک بودن این جمله بیشتر میشه
ما بر اساس مشکلات روانی که داریم از بین انسان‌هایی که در اطرافمان هستند انتخاب میکنیم با چه کسانی باشیم یا شاید ساده‌تر بگم بر اساس میزان سلامت روان خود انتخاب میکنیم با چه کسانی ارتباط بگیریم و چکاری با آنها صورت بدهیم
شاید این جمله که اطرافیان شما آیینه تمام قد از شما هستند یک واقعیت باشد بهتره بگیم هر یک از اطرافیان شما یک نماد از بخشی از روان شما هستند (یکبار دیگه جمله رو بخونید تا به عمق فاجعه آن پی ببرید در واقع این روان شماست که اجازه میده شما از دیگران آسیب ببینید)
شاید برخی از شما بگید اطرافیان من آدم‌های خوب و سالم و تندرستی هستند اگه با این تفکر برخورد کردید بهتره از خود بپرسید چقدر در خصوص سلامت روان خود مطمئن هستید
اما مسئله مورد طرح شاید این باشد، پس ما در مقابل آسیب‌ها بی دفاع هستیم؟ پس چاره‌ای جز پذیرش آسیب دیدن نداریم؟
تنها چیزی که به شما کمک خواهد کرد در این خصوص شناخت خود و آگاهی از خویشتن است، بدون شناخت خود ما یک سیبل برای اطرافیانمان هستیم نه بیشتر (تفکر انتقادی همان سپریست که نیاز دارید )
#free
بلکه ما از همان دوران کودکی انتخاب میکنیم چه کسانی رو در آینده ملاقات کنیم
جمله‌ای از یونگ هستش که اخیرا ذهنم رو مشغول کرده به خودش
هر چقدر عمیقتر بهش فکر میکنم میزان ترسناک بودن این جمله بیشتر میشه
ما بر اساس مشکلات روانی که داریم از بین انسان‌هایی که در اطرافمان هستند انتخاب میکنیم با چه کسانی باشیم یا شاید ساده‌تر بگم بر اساس میزان سلامت روان خود انتخاب میکنیم با چه کسانی ارتباط بگیریم و چکاری با آنها صورت بدهیم
شاید این جمله که اطرافیان شما آیینه تمام قد از شما هستند یک واقعیت باشد بهتره بگیم هر یک از اطرافیان شما یک نماد از بخشی از روان شما هستند (یکبار دیگه جمله رو بخونید تا به عمق فاجعه آن پی ببرید در واقع این روان شماست که اجازه میده شما از دیگران آسیب ببینید)
شاید برخی از شما بگید اطرافیان من آدم‌های خوب و سالم و تندرستی هستند اگه با این تفکر برخورد کردید بهتره از خود بپرسید چقدر در خصوص سلامت روان خود مطمئن هستید
اما مسئله مورد طرح شاید این باشد، پس ما در مقابل آسیب‌ها بی دفاع هستیم؟ پس چاره‌ای جز پذیرش آسیب دیدن نداریم؟
تنها چیزی که به شما کمک خواهد کرد در این خصوص شناخت خود و آگاهی از خویشتن است، بدون شناخت خود ما یک سیبل برای اطرافیانمان هستیم نه بیشتر (
#free
❤5👍2
یمدته دارم روی یک پروژه سنگین کار میکنم
قراره با مجموعه‌ای از پروژه‌های open source یک پلتفرم سازمانی و enterprise رو با تجمیع انواع سرویس‌ها و پروژه‌ها جهت نمونه اولیه بالا بیاریم و به نمایش جهت جذب سرمایه گذاری هندل کنیم
فعلا نمیتونم راجبش بهتون بگم برخلاف اصول اخلاقی هست ولی منتها بعد اینکه جذب سرمایه شد و یا حتی شکست خورد ذره ذره راجب اون پروژه‌های open source پست میزارم
حجم کانتینرها خیلی بالا رفته بود، حدود شصت کانتینر شده بود که مدیریت و مانیتور اونها داخل سرور و با bash خیلی سخت شده بود برام
به پیشنهاد یکی از دوستان (جا داره اینجا ازش تشکر کنم) یک کانتیر بالا آوردم portainer
یک پلتفرم تحت وب که میتونی باهاش کانتینرهات رو راحت مدیریت و مانیتورینگ کنی و تسلط یکپارچه قوی و خوبی از وضعیت موتور داکر هم داشته باشی رابط کاربری ساده و شیکی داره و بعنوان یک ابزار کمک دست بشدت مناسب هست
با دستور زیر رانش کنید
در اولین درخواست پیوستن بهش ازتون نام کاربری و پسورد میخواد جهت یوزر ادمین حتما حتما یک نام و پسورد سخت انتخاب کنید چون میتونه براتون دردسرساز بشه اگه کوتاهی کنید
#free
#docker
@code_crafters
قراره با مجموعه‌ای از پروژه‌های open source یک پلتفرم سازمانی و enterprise رو با تجمیع انواع سرویس‌ها و پروژه‌ها جهت نمونه اولیه بالا بیاریم و به نمایش جهت جذب سرمایه گذاری هندل کنیم
فعلا نمیتونم راجبش بهتون بگم برخلاف اصول اخلاقی هست ولی منتها بعد اینکه جذب سرمایه شد و یا حتی شکست خورد ذره ذره راجب اون پروژه‌های open source پست میزارم
حجم کانتینرها خیلی بالا رفته بود، حدود شصت کانتینر شده بود که مدیریت و مانیتور اونها داخل سرور و با bash خیلی سخت شده بود برام
به پیشنهاد یکی از دوستان (جا داره اینجا ازش تشکر کنم) یک کانتیر بالا آوردم portainer
یک پلتفرم تحت وب که میتونی باهاش کانتینرهات رو راحت مدیریت و مانیتورینگ کنی و تسلط یکپارچه قوی و خوبی از وضعیت موتور داکر هم داشته باشی رابط کاربری ساده و شیکی داره و بعنوان یک ابزار کمک دست بشدت مناسب هست
با دستور زیر رانش کنید
sudo docker run -d -p 9000:9000 --name portainer_ce --restart always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data docker.arvancloud.ir/portainer/portainer-ce:latest
در اولین درخواست پیوستن بهش ازتون نام کاربری و پسورد میخواد جهت یوزر ادمین حتما حتما یک نام و پسورد سخت انتخاب کنید چون میتونه براتون دردسرساز بشه اگه کوتاهی کنید
#free
#docker
@code_crafters
👍8
اصول برنامه ریزی اسکرام
در اسکرام برنامه ریزی در سطوح مختلفی از جزییات و در مقاطع زمانی متعددی انجام میشود. بخش عمده برنامه ریزی بجای زودهنگام و در ابتدا، بموقع و در زمان مناسب انجام میشود.
بیایید یکبار آنچه را که قبلا درباره برنامه ریزی خواندیم مرور کنیم و در بخش‌های بعدی به تشریح بهتر از برنامه ریزی های سبد محصول، محصول و انتشار بپردازیم
نگاه کلی
انچه قبلا راجب اصول کلیدی اسکرام گفته شد
۱-نمی‌توان در ابتدا طرح‌هایی درست و کامل تهیه کرد
۲- برنامه ریزی زودهنگام اگر بدون افراط باشد میتواند مفید باشد
۳- انتخاب‌های برنامه ریزی را تا اخرین لحظه مسئولیت پذیری باز نگهدارید
۴- به تطبیق و برنامه‌ریزی مجدد بیش از پای‌بندی به طرح توجه کنید
۵- موجودی برنامه‌ریزی را درست مدیریت کنی
۶-طرفدار انتشارات زود به زود و کوچکتر باشید
#scrum
@code_crafters
در اسکرام برنامه ریزی در سطوح مختلفی از جزییات و در مقاطع زمانی متعددی انجام میشود. بخش عمده برنامه ریزی بجای زودهنگام و در ابتدا، بموقع و در زمان مناسب انجام میشود.
بیایید یکبار آنچه را که قبلا درباره برنامه ریزی خواندیم مرور کنیم و در بخش‌های بعدی به تشریح بهتر از برنامه ریزی های سبد محصول، محصول و انتشار بپردازیم
نگاه کلی
انچه قبلا راجب اصول کلیدی اسکرام گفته شد
۱-نمی‌توان در ابتدا طرح‌هایی درست و کامل تهیه کرد
در رویکرد سنتی برای تولید محصول یک طرح تفصیلی با این عنوان که پوششی جامع برآنچه لازم است صورت میگیردد بدون چنین طرحی نمی‌دانیم قرار است بکجا رسیده و نمیتوانیم افراد را در گروه‌های چند تیمی هماهنگ کنیم، این درست است. در اسکرام معتقدیم که نمی‌توان در ابتدا همه‌ی کارها را به درستی انجام داد. به همین خاطر سعی نمی‌کنیم همه فرآورده‌ها را در ابتدا و زودهنگام تهیه کنیم. اما جهت ایجاد تعادل بین برنامه ریزی زودهنگام و به‌موقع، بخشی از فرآورده‌های برنامه ریزی را در ابتدا تولید میکنیم
۲- برنامه ریزی زودهنگام اگر بدون افراط باشد میتواند مفید باشد
هیچگاه نمی‌توانید یک طرح تفصیلی کامل و با جزییات برای محصول بنویسید. اینکار جز اتلاف وقت و ضرف هزینه نیست. در طی اجرای پروژه شما با حالت‌ها و اتفاقات غیرقابل پیش بینی روبرو هستید که باید سریع خود را با آن تطبیق دهید. شما باید بین پیش بینی زودهنگام و تطبیق بموقع تعادل برقرار کنید
۳- انتخاب‌های برنامه ریزی را تا اخرین لحظه مسئولیت پذیری باز نگهدارید
از این اصل برای برنامه ریزی زودهنگام و برنامه ریزی بموقع استفاده کنید. توقف برنامه ریزی بر اساس رویکرد به‌موقع تا زمانیکه اطلاعات کامل‌تری در اختیار داشته باشیم و آن را در بهترین شکل انجام دهیم
۴- به تطبیق و برنامه‌ریزی مجدد بیش از پای‌بندی به طرح توجه کنید
تایید بیش از حد بر طرح اولیه و توجه ناکافی به برنامه ریزی مستمر، یکی از مسائل رایج در توسعه محصول است. اگر زمان زیادی را در ابتدا جهت ایجاد طرح اولیه جامع صرف کنیم، در هنگام نیاز به تغییر، کمتر انعطاف پذیر بوده و سعی در اجرای طرح خود میکنیم. در حالیکه اگر به باور اسکرام در ابتدا نمی‌توان یک طرح جامع را برنامه ریزی کرد و در صورت نیاز به تغییرات و برنامه ریزی مجدد نسبت به طرح اولیه ارزش بیشتری قائل میشویم. اعتقاد بیش از به طرح اولیه در هنگامیکه پروژه انحراف میشود موجب میشود تا کمتر به اشتباه بودن طرح مشکوک شویم. هرچند در اسکرام به برنامه ریزی اولیه معتقدیم اما اگر بدانید در هنگام تدوین طرح‌های زودهنگام، اطلاعات کمی درباره محصول وجود دارد، آنگاه چنین باوری خردمندانه است. طرح زودهنگام، جهالت و بی دانشی ما در ابتدای کار را با ظرافت خاصی پنهان میکند. در اسکرام همانگونه که فرضیات را زود به زود اعتبارسنجی میکنیم، برنامه ریزی را هم زود به زود انجام می‌دهیم. از یادگیری معتبر برای تهیه طرح‌های بهتر و مفیدتر استفاده میکنیم. اگر اشکالی در طرح وجود داشته باشد نگران نیستیم چون می‌دانیم بزودی آن را با طرح دقیقتری جایگزین خواهیم کرد. و چون از اسپرینت‌های کوتاه استفاده میکنیم اگر اشتباهی در طرح باشد نیز می‌دانیم که زمان زیادی را هدر نداده‌ایم. در اسکرام برنامه ریزی را در چند سطح از جزییات انجام می‌دهیم
۵- موجودی برنامه‌ریزی را درست مدیریت کنی
در پست‌های قبلی به موضوع مهمی با عنوان مدیریت کار در جریان اشاره کردیم. باید باور داشته باشیم هنگام اسجاد تعادل بین برنامه ریزی ژودهنگام و برنامه ریزی بموق، تولید انبوهی از مستندات در برنامه ریزی پیش‌بینانه اعتبارسنجی نشده کار بیهوده‌ای است. به یک نمودار گانت بزرگ توجه کنید که در طول توسعه محصول و ارزیابی فرضیات اولیه با کسب دانش جدید از سوی دیگر به این نتیجه میرسیم که طرح اولیه اشتباه بوده است. و اکنون باید بپذیریم طرح دور ریخته و اتلاف ناشی از دور ریختن و تهیه طرح جدید را بپذیریم. اینکار سه نوع اتلاف ایجاد میکند:
۱- کار بیهوده‌ای که صرف تهیه طرحی شده است که حالا باید دور ریختن شود
۲- کار قابل توجهی که احتمالا صرف به روزرسانی طرح شده است
۳-فرصت‌هایی که می‌توانست صرف فعالیت‌های ارزشمندتری شود
یا توجه به وجود چنین ریسک‌های در ارائه طرحی برای آینده خیلی دور تنها دلیل ما پاسخ به سوالاتی از قبیل زمان تحویل پروژه و تعداد نیروهای مورد نیاز است
۶-طرفدار انتشارات زود به زود و کوچکتر باشید
اسکرام طرفدار انتشارات کوچکتر و زود به زود است زیرا این شیوه باعث میشود بازخوردها سریعتر دریافت شده و بازگشت سرمایه محصول نیز بهبود یابد
#scrum
@code_crafters
👍4