https://virgool.io/feed/@sara.reshadi روزانه‌های یک اسکرام‌مستر fa 2026-04-15 01:18:38 https://files.virgool.io/upload/users/10576/avatar/Qdh10y.png?height=120&width=120 https://virgool.io/@sara.reshadi https://virgool.io/@sara.reshadi/%D8%A7%D8%B3%D8%A8%D8%A7%D8%A8-%DA%A9%D8%B4%DB%8C-%D8%A8%D9%87-%D8%B3%D8%A8%DA%A9-%D8%A7%D8%AC%D8%A7%DB%8C%D9%84-yaz68nimmevt در دو ماه اخیر خانواده دو نفره ما به شدت درگیر اسباب کشی بود. از اونجایی که در صفر تا صد این پروسه، هر دو تنها بودیم و این اولین پروژه مستقل و مشترک اسباب کشی ما به حساب می‌اومد، خیلی به این فکر کردم چطور می‌تونم از مهارت اسکرام مستری خودم در اسباب کشی استفاده مفید کنم.اسباب کشی ابزار کنترل پروژهاول از همه رفتم سراغ یه ابزار ساده برای مدیریت پروژه و گوگل شیت رو به دلیل کاربری آسون و دسترس پذیری انتخاب کردم.ابزارهای دیگه‌ای هم می‌شد انتخاب کرد، اما من با گوگل شیت خیلی راحتم. به خصوص اینکه روی گوشی و لپتاپ هم در دسترسم هست.فازبندی، تعریف استوری و تسکبعد فیچر بزرگ «اسباب کشی» رو به سه فاز کلی تقسیم کردم:۱ فاز آماده‌ سازی خونه جدید۲ فاز بسته بندی و اسباب کشی۳ فاز تحویل خونه قبلینکته جالب اینکه این سه فاز به طور کامل از واترفال و مدل آبشاری پیروی نمی‌کردن و گاهی کاملا اجایل بودن.مثلا برای کامل کردن فاز آماده سازی خونه جدید، باید فرش‌ها شسته می‌شد و این کار در فاز سه (تحویل خونه قبلی) انجام شد و بعد اومد توی لیست کارهای فاز یک، تیک خورد.یعنی باید به صورت چرخه‌ای می‌رفتیم یه چیزهایی رو در خونه جدید آماده می‌کردیم، بعد می رفتیم سراغ فاز بسته بندی و در نهایت یه چیزی رو از خونه قبلی می‌آوردیم تا دوباره بتونیم ادامه فاز یک رو داشته باشیم.هر فاز برای من یه استوری بود که باید میت می‌کردم، پس برای میت کردنش باید برای هر استوری چند تا تسک ریزتر تعریف می‌شد.پروداکت بک لاگ و اولویت‌بندیمرحله بعدی پروداکت بک لاگ بود. (بخش کوچکی رو به عنوان سمپل واستون گذاشتم که ببینید)پروداکت بک لاگبرای این کار، بعد از اینکه لیست تسک‌ها مشخص شد، شروع کردیم به اولویت بندی کردن هر کاراولویت‌بندی‌هامون رو به ترتیب براساس سه فاکتور زیر مرتب کردیم:بودجه و هزینهنیازهای ضروری خانهعلایق شخصیتسک‌های هر فاز رو مشخص کردیم و مسئولیت پیگیری هر کدوم به یکی از ما دو نفر اساین شد.البته خیلی‌ وقت‌ها زمان کم می‌آوردیم و به عنوان یه تیم دو نفره، هوای همدیگه رو داشتیم و جای همدیگه رو پر می‌کردیم.سعی کردیم به لیست کارها وفادار باشیم و همه رو میت کنیم.برای هر موردی که می‌شد پیش‌بینی انجام داد، تاریخ شروع نوشتیم و پیش‌بینی اینکه چند روز طول می‌کشه رو هم نوشتیم.همچنین اینکه چقدر پول پرداخت کردیم و چقدر باقی مونده رو هم نوشتیم که یادمون بمونه.ادهاک‌ وارد می‌شود!این وسط بعد از استارت پروژه متوجه شدیم یه سری موارد رو ندیدیم یا حتی به دلیل کارهای باز قبلی (به اصطلاح، ادهاک وارد شد)مثلا متوجه شدیم کمدهای خونه جدید قفسه ندارن و باید قبل از هر کاری، قفسه‌بندی انجام بدیم.مواردی که جلوشون عدد یا پروایوریتی نداره، ادهاک هستن که قبلا پیش‌بینی نکرده بودیم و بعدا لازم شد.مدیریت بودجههمزمان با پیش بردن این اولویت‌بندی‌ها، یک شیت دیگه برای تخصیص بودجه درست کردم و هر منبع درآمدی رو نوشتم تا ببینم در چه تاریخی، چقدر پول به دستمون می‌رسه و در نهایت اگر نیاز به وام یا قرض گرفتن بشه حدودا چقدر کم میاریم و زودتر دست به کار بشیم.تخمین‌ هزینه‌برای مدیریت بودجه باید اول یه هزینه تقریبی از تمام مراحل به دست می‌آوردم و زمانبندی اجرای هر کدوم رو می‌نوشتم.رفتم سراغ دوست و یار همیشگی، اینترنت.سعی کردم هزینه کارهای خدماتی رو از آچاره دربیارم. (البته قبلش با اپراتور آچاره صحبت کردم، شرایطم رو گفتم و اعلام کردم فعلا فقط می‌خواهم هزینه‌ها رو دربیارم، بعدا در صورت نیاز ثبت سفارش می‌کنم.)هزینه کالاهایی که باید خریداری می‌‌کردیم رو هم از دیجی‌کالا و ترب درآوردم.هزینه حدودی اسباب کشی رو هم از اسنپ باکس درآوردم.هزینه‌های واقعیبعد از اینکه هزینه پیش‌بینی شده هر کدوم رو جلوی تسک‌ها نوشتم متوجه شدم با بودجه مد نظرمون فاصله داریم و باید هر طور شده مدیریت کنیم.در نتیجه تصمیم گرفتیم برای خرید بعضی از محصولات به مرکز اصلیشون مراجعه کنیم و حضوری خرید کنیم.این اختلاف هزینه مخصوصا در مورد برق و روشنایی، تقریبا هزینه‌هامون رو نصف کرد.درباره هزینه خدمات مثل نقاشی و قفسه بندی کمد هم سعی کردیم از آچاره متخصص پیدا کنیم و با مذاکره درباره کیفیت کار و قیمت، بهترین گزینه رو انتخاب کنیم.در مورد اسباب کشی هم بعد از بررسی گزینه‌های مختلف، تصمیم گرفتم به سه دلیل از سرویس اسباب کشی اسنپ باکس استفاده کنم.اسنپ باکسیک دلیلم این بود که در همین شرکت مشغول به کار هستم.دلیل دیگه این بود که بعد از مقایسه سرویس‌های مختلف به این نتیجه رسیدم که این سرویس نیازهای من رو کامل رفع می‌کنه و پشتیبانی هم بدون اینکه بدونه من همکارشون هستم،‌ خیلی خوب ساپورت کرد.سومین دلیل خودم به عنوان اسکرام مستر اسنپ باکس، از ابتدا در این فیچر مشارکت داشتم و دارم و می‌خواستم به چشم یک کاربر واقعی، محصول رو استفاده کنم و فیدبک واقعی بدم تا محصول بهتری رو به سایر کاربران عرضه کنیم.بازنگریبا کمی بالا پایین هزینه‌ها و کارها، ما تونستیم:تمام کارهای Must have (کارهای ضروری و با اولویت بالا)تمام کارهای Should have (کارهایی که اگه قبل از جابجایی انجام می‌دادیم بهتر بود)و بخشی از Nice have (کارهایی که دوست داشتیم انجام بدیم ولی اولویت نبود) رو میت کنیم.ما به صورت دوره‌ای و هفته‌ای یکبار بک لاگمون رو نگاه می‌کردیم و می‌دیدیم چه مواردی هنوز میت نشده.همسرم در این پروژه، هم‌تیمی خیلی خوبی بود و به تسکهاش کاملا وفادار موند و بدون بدهی فنی تونستیم بریم روی پروداکشن خوشبختانه.و در پایاناین پروژه واسه من به شخصه خیلی جذاب بود، به ویژه اینکه همه چیز طبق اولویت‌بندی پیش رفت و همه چیز در زمان مقرر تموم شد. حتی از نظر تخصیص هزینه هم کمی با رقم پیش‌بینی شده اختلاف پیدا کردیم که به دلیل تورم و مشکلات این چنینی به نظرم خیلی طبیعی و قابل پیش ‌بینی می‌اومد.انقد به این پروژه افتخار می‌کنم که اگر می‌تونستم، به عنوان یک دستاورد مهم توی رزومه‌م می‌نوشتم.ما موفق شدیم با تفکر اجایل یه پروژه سخت رو که برای اولین بار تجربه می‌کردیم، به طور کامل مدیریت کنیم و به سرانجام برسونیم و خب خیلی دلم می‌خواست این موضوع رو با شما هم در میون بذارم. سارا رشادی سارا رشادی Sat, 30 Jul 2022 15:41:05 +0430 https://virgool.io/@sara.reshadi/%D8%AA%DB%8C%D9%85-%D8%B8%D8%B1%D9%81%DB%8C%D8%AA-%D9%88-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-ayxyinvbroj3 چند وقت پیش یکی از بچه‌ها ازم پرسید: «وقتی می‌گیم ظرفیت اعضای تیم اسکرامی با هم سنجیده می‌شه، یعنی مثلا من می‌تونم یه اسپرینت همه تسک‌ها رو بردارم و مثلا بقیه کاری برندارن؟»گفتم: «آره. ما همه یه تیم هستیم. ظرفیت همه ما با هم سنجیده می‌شه. ممکنه این اسپرینت آقا یا خانم ایکس مشکلی واسش پیش بیاد و نتونه کار کنه، پس تیم نبودنش رو تا جایی که بتونه، جبران می‌کنه و دفعه بعد ایکس هوای یکی دیگه رو داره.»بعد به این فکر کردم که چرا در این باره بیشتر حرف نمی‌زنیم؟ مبحثی به این مهمی ارزش این رو داره که بیشتر بهش بپردازیم و بدونیم تیم ورک قراره چطور روی ما تاثیر بذاره؟Scrum Teamاگه با متد اسکرام کار کرده باشید، می‌دونید که در پایان هر اسپرینت خروجی کار کل تیم سنجیده می‌شه، نه خروجی فرد. اما چطوری؟این جمله دقیقا یعنی چی؟ یعنی اگه ما نیروی خوبی باشیم، اما در تیم تازه و احتمالا ضعیفی جوین بشیم قرار نیست پیشرفتمون دیده بشه؟ آیا قراره یه نفر بیشتر کار کنه و بقیه کمتر؟ اصلا سنجش کار تیمی چطور ممکنه؟فکر کنم خوب باشه یکم بیشتر راجع به این موضوع حرف بزنیم و واسه خودمون مفهوم خروجی کار تیمی رو مشخص کنیم.چند وقت پیش یکی از بچه‌ها ازم پرسید: «وقتی می‌گیم ظرفیت اعضای تیم اسکرامی با هم سنجیده می‌شه، یعنی مثلا من می‌تونم یه اسپرینت همه تسک‌ها رو بردارم و مثلا بقیه کاری برندارن؟»گفتم: «آره. ما همه یه تیم هستیم. ظرفیت همه ما با هم سنجیده می‌شه. ممکنه این اسپرینت آقا یا خانم ایکس مشکلی واسش پیش بیاد و نتونه کار کنه، پس تیم نبودنش رو تا جایی که بتونه، جبران می‌کنه و دفعه بعد ایکس هوای یکی دیگه رو داره.»بعد به این فکر کردم که چرا در این باره بیشتر حرف نمی‌زنیم؟ مبحثی به این مهمی ارزش این رو داره که بیشتر بهش بپردازیم و بدونیم تیم ورک قراره چطور روی ما تاثیر بذاره؟توی متدهای قدیمی‌تر، معمولا اینجوریه که کار هر نفر به تنهایی سنجیده می‌شه. چقدر کار کرده، چقدر تسک دان کرده و چقدر تمیز کار کرده و ....اما اگه با متد اسکرام کار کرده باشید، می‌دونید که ما به عنوان یک تیم برای هر اسپرینت، ظرفیت مشخصی از تسک‌ها رو پیک می‌کنیم.احتمالا دیدید که توی پلنینگ، اسکرام مستر از تیم می‌پرسه کسی این اسپرینت می‌خواد به مرخصی بره؟ و بعد از پرسیدن چند سؤال مشابه دیگه، عددی رو به عنوان ظرفیت تیم در اسپرینت اعلام می‌کنه.بعد از اون تیم براساس میزان سختی هر تسک، پوینتی رو اعلام می‌کنن و تسک پیک می‌شه. در نهایت مجموع پوینت‌های پلن شده، می‌شه تعهدی که تیم باید تا آخر اسپرینت ادا کنه.همه این‌ها رو به صورت خلاصه گفتم، که برسم به این موضوع که چرا ما کار هر نفر رو جداگانه نمی‌سنجیم و چرا به خروجی تیم با هم نگاه می‌کنیم.متریک‌های سنجش تیمما سعی می‌کنیم نگاهمون رو از فرد فراتر ببریم و به خروجی تیم با هم نگاه کنیم.به همین دلیل هم ما راه‌ها و متریک‌هایی برای سنجش تیم اسکرامی وجود داره که مهم‌ترین و رایج‌ترینش برن داون چارته.درباره انواع برن داون چارت و تفسیرش قبلا مفصل اینجا توضیح دادم (برن داون چارت)، اما اگه بخوام خلاصه بگم، ما میاییم عدد ظرفیت تیم رو که براساس تجربه‌های قبلی تیم، مرخصی اعضا و ... در نظر گرفته بودیم، مد نظر قرار می‌دیم و می‌گیم در حالت ایده‌آل تیم اگه بخواد تمام تسک‌ها رو دان و تعهدش رو ادا کنه، باید هر روز چند پوینت به طور متوسط دان کنه.بعد در طول اسپرینت، براساس زمانبندی دان شدن تسک‌ها، یه نمودار رسم می‌کنیم تا بفهمیم چند درصد از چیزی که اول اسپرینت پیش‌بینی کرده بودیم، برآورده شده.Burn Down Chartاین نمودار به عنوان مهمترین معیار پیشرفت تیم در هر اسپرینت، در اختیار تیم و استکهولدر قرار داده می‌شه. هرچقدر که تیم بیشتر در کنار هم کار کنه، این پیش‌بینی‌ها به واقعیت نزدیک‌تر می‌شه و می‌تونیم به مشتری قول دقیق‌تری بدیم.البته نمودارهای دیگه‌ای هم برای این کار داریم مثل برن داون فیچر، برن داون و برن آپ اسپرینت و ... که ترجیح می‌دم توی یه مقاله دیگه با هم درباره‌شون حرف بزنیم.تقسیم کاروقتی می‌گیم کار تیمی انجام بدیم، به این معنا نیست که حواسمون نباشه آدم‌ها چقدر کار می‌کنن. قاعدتا باید یه راه حلی پیدا کنیم که به کسی فشار بیشتری نیاد. در چند سال گذشته که کار ریموت محبوب‌ و رایج شده، درک اینکه همه چقدر کار می‌کنند، سخت شده.اگر حواسمون نباشه، عدم تقسیم عادلانه کار به یه تعارض تیمی جدی تبدیل می‌شه. خوشبختانه اسکرام واسه این موضوع هم راهکاری داره.ما می‌تونیم با کمک یکی از اعضای سینیور تیم که تسلط بیشتری به سیستم داره و با مشورت و موافقت اعضای تیم، بار عادلانه‌ای از کارها رو بین بچه‌ها تقسیم کنیم.همچنین می‌تونیم با کمک رویدادهایی مثل استندآپ‌های روزانه (دیلی) فضایی رو فراهم کنیم که بفهمیم هرکسی چقدر کار داره و آیا به کمک نیاز داره یا نه.در نهایت اگر فکر می‌کنیم سبک تقسیم کار تیمی ما مشکل داره و باید اصلاح بشه، بهترین رویداد، رترو هست. می‌تونیم توی رترو درباره این موضوع حرف بزنیم و به راه حلی عادلانه برسیم.پرفورمنس شخصی یا تیمی؟حالا ممکنه واستون سؤال پیش بیاد که اگه یه نفر فوق‌العاده پروداکتیو و فعال باشه، اما توی یه تیم بد و بدون انگیزه قرار بگیره چی؟ آیا قراره به خاطر تیم هیچ‌وقت کارش دیده نشه و پروموت نشه؟راستش نه! قرار نیست این اتفاق بیفته.تمام تلاش‌ها بر اینه که تیم به بلوغ برسه و رشد کنه و درسته که آخر اسپرینت، سرعت همه تیم با هم سنجیده می‌شه، اما با استفاده از راهکارهایی مثل فیدبک ۱۸۰ و ۳۶۰، جلسات ۱:۱ (اینجا درباره‌ش بیشتر بخونید) و ... پرفورمنس هر فرد هم به تنهایی دیده می‌شه.پس اگه توی یه تیم اسکرامی قرار گرفتید، اصلا نگران نباشید و با خیال راحت در کنار تیم باشید.به نظر من که هم تیمی خوبی بودن و کمک به رشد تیم، آدم رو خیلی به گرفتن پوینت‌های مثبت و پروموت شدن نزدیک می‌کنه. نظر شما چیه؟ سارا رشادی سارا رشادی Tue, 10 May 2022 11:26:43 +0430 https://virgool.io/@sara.reshadi/%D8%AA%D9%88%D8%B5%DB%8C%D9%87-%D9%87%D8%A7%DB%8C%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AF%D8%A7%D8%B4%D8%AA%D9%86-%DB%8C%DA%A9-%D8%AC%D9%84%D8%B3%D9%87-%DB%B1%DB%B1-%D9%81%D9%88%D9%82-%D8%A7%D9%84%D8%B9%D8%A7%D8%AF%D9%87-%D8%AE%D9%88%D8%A8-ylh0bkmw3thr One on One meetingشاید تا به حال واستون پیش اومده که جلسه ۱:۱ داشته باشید و با خودتون فکر کنید که «ای بابا! چی بگم آخه؟ حرفی نداریم که! مدیرم هم که فکر نمی‌کنم واسش مهم باشه، پس بذار بپیچونمش.»خب امروز قصد دارم بهتون بگم که برای داشتن یک جلسه ۱:۱ مؤثر و خوب باید چیکار کنید. شاید این مقاله بهتون کمک کنه که دفعه بعد به جای پیچوندن جلسه، با علاقه به استقبالش برید.۱:۱ چیست؟اول از همه بذارید یه تعریف خلاصه و خودمونی از ۱:۱ داشته باشیم.جلسات ۱:۱، (یک به یک یا «One on One») جلسات هفتگی یا دو هفته یکباری هستند که بین مدیر و هر کدوم از اعضای تیم برگزار می‌شه.موضوع این جلسات که معمولا بین ۳۰ دقیقه تا یک ساعت طول می‌کشه، درباره وضعیت شغلی اعضای تیم، مسیر پیشرفتشون و مشکلات احتمالی هست.مزایای ۱:۱به عنوان یک کارمند، جلسه ۱:۱ به شما کمک می‌کنه فیدبک‌ و راهنمایی بهتری دریافت کنید و بتونید راحتتر مسیر پیشرفت شغلی رو طی کنید.به عنوان یک مدیر، این سبک از جلسات باعث می‌شه راحتتر و سریعتر مشکلات اعضای تیم رو شناسایی کنید، ارتباط بهتری برقرار کنید و تیم بهتری داشته باشید.در جلسه ۱:۱ چی مطرح می‌شه؟گاهی اگه موضوعی توی ذهنتون باشه، این جلسه خیلی هم جذابه و بی‌صبرانه منتظر هستید تا حرف‌هاتون رو بزنید، اما گاهی هم حرفی ندارید و با همه وجود دلتون می‌خواد کنسل کنید.خب ما امروز می‌خوایم به این فکر کنیم، چیکار کنیم که دیگه گزینه کنسل کردن خط بخوره و به‌جاش یه جلسه مفید داشته باشیم.رترواسپکتیو برگزار کنید!اول از همه به جای اینکه دنبال ایده‌های عجیب وغریب بگردید، بهش به چشم جلسه رترواسپکتیو نگاه کنید.(جلسه رترواسپکتیو: رودیدادی در پایان هر اسپرینت که اعضای تیم دور هم جمع می‌شن و درس‌ آموخته‌های اسپرینتی که گذشت رو بررسی می‌کنن. بعد از بررسی اینکه چه اتفاقات خوبی افتاده، چه اتفاقات بدی افتاده، چطور می‌شه اوضاع رو بهتر مدیریت کرد و پیشنهادهای احتمالی، یک چک لیست به دست میاد که تیم توافق می‌کنه تا رتروی بعدی اون چک لیست رو انجام بده و نتایجش رو دفعه بعد بررسی کنه ببینه چقدر مؤثر بودن.)سعی کنید اتفاقاتی که در بازه زمانی ۱:۱ قبلی تا ۱:۱ فعلی رخ داده رو مرور کنید. درست همون کاری که در پایان اسپرینت انجام می‌دید. با این تفاوت که اونجا می‌خواهید به بهبود تیم کمک کنید، اما اینجا می‌خواید به بهبود وضعیت خودتون کمک کنید.پنج قدم برای مدیراناگر مدیر هستید و می‌خواید با اعضای تیم ۱:۱ بذارید، این پنج قدم احتمالا خیلی بهتون کمک می‌کنه:قدم اول: به هر کدوم از اعضای تیم خبر بدید که جلسه۱:۱ بعدیشون چه زمانی خواهد بود.قدم دوم: ازشون بخواید بنویسن که توی محیط کار چه مواردی رو دوست دارن و چه مواردی اذیتشون می‌کنه و همچنین چه ایده‌ای برای تغییرش دارن. شما هم توی جلسه از حرف‌هاشون نوت بردارید.قدم سوم: در زمان جلسه درباره مواردی که نوشتید، حرف بزنید و تبادل نظر کنید.قدم چهارم: با برین استورم، یه اکشن پلن در بیارید که بتونید جلسات بعدی رو بهبود بدید.قدم پنجم: یه اکشن کوچیک انتخاب کنید و سعی کنید برای سه جلسه بعدی درباره این موضوع حرف بزنید و بررسی کنید.همین قدم‌های کوچیک کمک می‌کنه که جلسه ۱:۱ مفیدتری با اعضای تیمتون داشته باشید.و اگر مدیر نیستید؟اگه مدیر نیستید و یکی از اعضای تیم هستید که جلسه ۱:۱ تون نزدیکه، پیشنهاد می‌کنم از راهکارهای زیر ایده بگیرید:این مقاله رو واسه مدیرتون بفرستید و بگید دوست دارید ۱:۱ رو به روش رترواسپکتیو تجربه کنید.برای جلسه بعدی، از مدیرتون بخواید که چند دقیقه درباره اینکه چطور جلسه مفیدی داشته باشید، حرف بزنید.با روش برین استورم یه لیست شامل «چیزهایی که ناراحتتون می‌کنه- چیزهایی که عصبی‌تون می‌کنه و چیزهایی که خوشحالتون می‌کنه» بسازید و در جلسه بعدی هم بررسیشون کنید.از مدیرتون بپرسید که به نظر اون هدف اصلی این جلسه چیه و فکر می‌کنن چطور بهتره پیش برید.احساس واقعیتون رو درباره این جلسه به مدیرتون بگید و احساس اون هم بپرسید.صحبت کردن درباره چیزی که واقعا داره رخ می‌ده و متوقف کردن یه روند بی‌نتیجه، در نهایت به نفع خودتون تموم می‌شه و باعث می‌شه انگیزه کار کردن و رضایت شغلیتون بیشتر بشه.در مجموع خوبه که بدونید شما و مدیرتون می‌تونید با همکاری همدیگه همه چیز رو درباره ۱:۱ تغییر بدید. مثلا اینکه:چند وقت یک بار برگزار بشه؟کجا برگزار بشه؟چقدر طول بکشه؟هدفش چی باشه؟و ....و در آخرچه کارمند باشید و چه مدیر، این رو بدونید که ۱:۱ جلسه شماست و برای اینکه تبدیل به یک جلسه جذاب با خروجی مفید بشه، نیاز به همکاری هر دو طرف ماجرا داره. پس برای جلسه بعدی به جای صحبت‌های روتین همیشگی، می‌تونید با همدیگه یه بازنگری روی کل جلسه داشته باشید و تلاش کنید این جلسات رو واسه خودتون جذابتر کنید. سارا رشادی سارا رشادی Wed, 20 Apr 2022 09:44:56 +0430 https://virgool.io/@sara.reshadi/%DA%A9%D9%85%DB%8C-%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87-%D8%B1%DB%8C%D9%84%DB%8C%D8%B2-%D9%BE%D9%84%D9%86-mwgvrkqzqyig Release Planهمونطور که می‌دونید در اسکرام یه نوع پلن داریم به اسم اسپرینت پلنینگ. این ایونت در واقع نقطه آغاز رسمی اسپرینته و خب خیلی‌ها فکر می‌کنن فقط همین یه نوع پلن رو داریم اما فراتر از اسکوپ اسپرینت، انواع دیگه‌ای از پلنینگ‌ها وجود داره، ازجمله ریلیز پلن.ریلیز پلن درباره اسکوپ کارها، تاریخ و ظرفیت‌هاییه که برای دلیوری محصول بهشون نیاز داریم. در واقع نگاهی کلی به نتیجه چند اسپرینت داره و خیلی مهمه که بعد از پروداکت پلنینگ و قبل از شروع اولین اسپرینت، بهش بپردازیم.یکی از راه‌هایی که می‌شه درباره ریلیز پلنینگ تاریخ درست‌تری رو تخمین زد، توجه به کارهای عقب مونده از ریلیزهای قبلیه.چطوری؟ خب باید اول باید بدونیم که ورودی ریلیز پلن شامل دو مورده:خروجی ریلیز پروداکت (چشم انداز محصول- پروداکت بک لاگ و رودمپ پروداکت)سرعت تیم‌هابعد می‌ریم بک لاگ رو کاملا مرتب کنیم و کارها رو به ترتیب اولویتی که می ‌خوایم انجام بشه، دسته بندی کنیم. بعد یه خط فرضی می‌کشیم و مشخص می‌کنیم چه مواردی باید توی ریلیز ما جای داده بشه. این خط فرضی، ریلیز لاین ماست.به عبارت دیگه هرچیزی که بالای خط ریلیز قرار داره، قراره ریلیز بشه و فعلا بقیه موارد زیر خط رو می ذاریم کنار و تمرکزمون رو می‌ذاریم روی شفاف کردن جزییات مواردی که می خوایم حتما ریلیز بشه.البته ممکنه در حین همین کار متوجه شیم مواردی که زیر خط هستند افورت بیشتر یا کمتری دارن، که در اون صورت بنا به نیاز خط رو بالا یا پایین می کنیم و دیتیل ریلیز کم و زیاد می‌شه.برای اینکه یه ریلیز پلن خوب داشته باشیم، لازمه تیم اسکرام و استکهولدر با همدیگه همفکری و همکاری کنن. چرا؟ چون ریلیز پلن یه مسیر مداوم و تکرار شونده س و در طول هر اسپرینت می‌شه اون رو دید. البته همونطور که بالاتر گفتیم ریلیز پلن اولیه از پروداکت پلن پیروی می کنه و هدف پروداکت پلن هم برنامه ریزی برای محصول نهاییه.یادمون نره که هدف از ریلیز پلن کشف گام‌های منطقی بعدی برای رسیدن به هدف محصوله و باید به سه سوال مهم جواب بده:کی کارمون تموم می شه؟چقدر هزینه برمیداره؟کدوم فیچر رو می تونم تا آخر سال به دست بیارم؟در مجموع خوبه که بدونیم ریلیز پلن سعی داره یک بالانس بین ارزشهایی که مشتری می خواد و کیفیت محصول تولید شده ایجاد کنه و هر سازمانی می تونه براساس سبک کارکردشون انتخاب کنه که ریلیز پلن رو بعد از چند اسپرینت داشته باشه در طول هر اسپرینت داشته باشه یا حتی براساس ریلیز هر فیچر پیش بره سارا رشادی سارا رشادی Sat, 01 Jan 2022 09:36:40 +0330 https://virgool.io/@sara.reshadi/%D9%BE%D9%86%D8%AC-%D8%AF%D9%84%DB%8C%D9%84-%D9%85%D9%87%D9%85-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B4%DA%A9%D8%B3%D8%AA-%DB%8C%DA%A9-%D8%B1%D9%88%D8%AF%D9%85%D9%BE-%D9%BE%D8%B1%D9%88%D8%AF%D8%A7%DA%A9%D8%AA%DB%8C-wex72iir2edd Product Roadmapچند وقت پیش داشتم یه مقاله درباره «دلایل شکست طرح‌های پروداکتی» می‌خوندم.نویسنده به چند دلیل رایج اشاره کرده بود و توضیح داده بود چرا افورت‌ها و تخمین‌هایی که اول کوارتر مشخص می‌کنیم، تا پایان کوارتر محقق نمی‌شه.به شخصه از این همه جزیی‌نگری و دقت نظرش که البته نشون دهنده سال‌ها تجربه‌س، لذت بردم. بعد با خودم فکر کردم ببینم من چی فکر می‌کنم.خلاصه مواردی که از اون مقاله توی ذهنم مونده رو با جزییاتی اضافه یا کمتر به همراه نظر و تجربیات خودم هم ترکیب کردم و در همین راستا دوست دارم نظر و تجربه شما رو هم بدونم.خب اگه بخوایم از اول شروع کنیم، می‌بینیم که بیشتر ما برای اولویت بندی و تقسیم کار، از برنامه‌ریزی کوارتری و در بعضی موارد سالانه استفاده می‌کنیم و در قالب این برنامه‌ریزی موارد مهم رو به ترتیب اولویت مرتب می‌کنیم و به اصلاح رودمپ آماده می‌کنیم.یعنی اول موارد مهم‌تر که اولویت بیزینسی دارند رو بالاتر می‌ذاریم تا زودتر بریم سراغشون و سریع‌تر محصول رو به بازار برسونیم.احتمالا بعد از اینکه اولویت بیزینسی مشخص شد، می‌ریم سراغ مهند‌س‌ها و ازشون می‌پرسیم با شرایط و امکانات موجود فکر می‌کنید، ساختن چنین محصولی چقدر طول می‌کشه؟اون‌ها هم پس از مقداری بررسی و همکفری به ما یه تخمین حدودی می‌گن. مثلا می‌گن همچین فیچری با امکانات و شرایط موجود، دو اسپرینت طول می‌‌کشه.داستان احتمالی مشکلات از جایی شروع می‌شه که ما یه سری موارد رو نادیده می‌گیریم و فقط براساس تخمین در نظر گرفته شده، منتظر دلیور شدن محصول می‌مونیم. یهو به خودمون میاییم می‌بینیم آخر کوارتر شده، چیزی که برنامه‌ریزی کرده بودیم آماده ریلیز نیست و نمی‌دونیم دلیل اصلی این شکست چیه.بیایید با هم یه سری از رایج‌ترین مشکلات رو مرور کنیم و ببینیم هر مورد چقدر به اتفاقی که برای ما افتاده نزدیکه:۱ عدم مشارکت تیم: تیم فقط و فقط ایده‌های استکهولدر رو دیکته می‌کنه و هیچ خلاقیت یا اختیار عملی نداره. به عبارت دیگه، بدون توجه به مزایا یا معایب، فقط کاری که بهشون گفته شده رو انجام می‌دن. این ممکنه نتیجه عدم توانمندی تیم باشه یا حتی عدم مشارکتشون. به عبارت دیگه شاید تیم توانمنده اما ما انقدر دیر بازیشون می‌دیم که دیگه وقتی واسه ابراز خلاقیت نمی‌مونه.۲ طرح بیزینسی ناقص: هر طرح بیزینسی باید به دو سوال مهم جواب بده. قراره چقدر پول به دست بیاریم؟ و چقدر هزینه کنیم؟ مسئله اینه که در ابتدای راه ما در واقع دقیق جواب این دو سوال رو نمی‌دونیم. همه‌ چیز به راه حل‌هایی که به کار می‌بریم بستگی داره. اگه طرح بیزنسی ما ناقص باشه، راه حل‌ها و تخمین‌هایی که مهندس‌ها به ما می‌گن، تحت تاثیر این نقص قرار می‌گیره، تخمین‌ها رو تغییر می‌ده و باعث می‌شه آخر سر ببینیم در واقع هیچی دلیور نکردیم و ارزشی به دست نیاوردیم.۳ اولویت بندی اشتباه: ما برای بازاریابی به اولویت بندی نیاز داریم و این اولویت بندی مستقیم از نیاز بازار به دست میاد. مشکل اینجاست که شاید یه چیزایی رو ندیده باشیم یا طرح ما خیلی کمال‌گرایانه باشه. بیایید قبول کنیم که نصف ایده‌ها در عمل کار نمی‌کنن و برخلاف تصور ما، کاربر اون بیرون خیلی هم قرار نیست هیجان‌زده ‌شه. یا حتی ممکنه انقدر گرون یا پیچیده باشه که کاربر بیخیال اون نیاز بشه. از اون طرف گاهی ایده‌های خوب که عملیاتی شدن، در کوتاه مدت به سود دهی نمی‌رسن. پس باید رودمپ رو جوری بچینیم که اولا کمال‌گرایانه نباشه و قابلیت اجرایی داشته باشه و دوما هزینه‌های فیچرهای اشتباه یا دیربازده رو جبران کنه.۴ نقش‌های اشتباه: نقش مدیرمحصول به گردآورنده دیتا و اطلاعات برای مهندس‌ها تغییر می‌کنه و همین خودش به تنهایی فاجعه به بار میاره. خلاقیتی در کار نیست. صرفا بدون توجه و تحلیل بازار و رقبا، حرف‌های استکهولدر به مهندس‌ها نقل قول می‌شه.۵ بی‌توجهی به اجایل: گاهی هم ممکنه انقدر دیر به اصول اجایل در اجرای پروژه توجه کنیم که اثرگذاریش رو از دست بده. همین توجه دیرهنگام باعث می‌شه چیزی که تحویل می‌دیم با اصول اجایل و چابک مغایرت داشته باشه. حتی ممکنه از اونور بوم بیفتیم و به جای اجایل توی فرآیند واترفال بیفتیم. به عبارت دیگه به روش قدیمی واترفال، مرحله به مرحله و سنتی جلو می‌ریم. اول مستندات، بعد برنامه‌ریزی، بعد تولید و در تمام این مراحل با مشتری ارتباط نمی‌گیریم و بدون توجه به اون پیش می‌ریم. در نتیجه یه عالمه ریسک رو در مسیر با خودمون انباشته می‌کنیم و میاریم.Agile vs Waterfall(برای اینکه ذهنیت بهتری از مفهوم اجایل و واترفال داشته باشید، یه طرح گرافیکی مقایسه‌ای واستون گذاشتم. همونطور که از اسمش هم پیداست واترفال مثل آبشار مرحله مرحله و سرازیری پیش می‌ره و اجایل به فرآیندهای تکرارشونده دیسکاوری تا دلیوری براساس فیدبک در بازه زمانی کوتاه معتقده)بجای اینکه اعتبارسنجی و دلیوری مداوم رو تجربه کنیم، همه چیز رو بذاریم برای مرحله آخر و بعد از دلیوری. در نتیجه با ریسک خیلی بالایی مواجه می‌شیم و نمی‌دونیم آیا داریم در راستای خواسته بازار پیش می‌ریم یا نه. یعنی اگه در لحظه دلیوری (لحظه آخر) بفهمیم یه جایی مشکل داره، به جای اینکه بتونیم سریع برگردیم و درستش کنیم، مجبوریم همه چیز رو از اول شروع کنیم. چون اجایل نبودیم و آبشارطور رفتیم جلو.خلاصه اینکه به نظر من، موفقیت یه رودمپ به مشارکت جمعی بالا نیاز داره. این یه کار تیمیه که یه نفر به تنهایی از پسش برنمیاد.به خاطر اینکه یه رودمپ تمام سازمان رو تحت تاثیر قرار می‌ده. من در این پنج مورد سعی کردم از زاویه‌های مختلف به رودمپ و دلایل شکست یا برعکس اون، دلایل موفقیتش نگاه کنم.خیلی موارد ممکنه منجر به شکست یه طرح بیزینسی فوق‌العاده بشه و حتما شما هم ضمن خوندن این متن، مثال‌ها و دلایل زیادی به ذهنتون اومد. خیلی دوست دارم بدونم چه مواردی به ذهنتون اومده. سارا رشادی سارا رشادی Wed, 22 Dec 2021 10:03:25 +0330 https://virgool.io/@sara.reshadi/%D9%82%D8%AF%D9%85-%D8%A8%D9%87-%D9%82%D8%AF%D9%85-%D8%AA%D8%A7-%DA%A9%D8%B4%D9%81-%D9%85%D8%AD%D8%B5%D9%88%D9%84-xnaeuilfemhy رضایت مشتری با رشد محصول در بازار رابطه‌ای کاملا مستقیم داره. در دنیای پر رقابت امروزی، همه شرکت‌ها به دنبال این هستند که تعداد کاربران خودشون رو افزایش بدن و از این طریق سهم بیشتری از بازار رو به خودشون اختصاص بدن. از طرف دیگه فیچرهایی که با کدنویسی تولید می‌شن بسیار گرون هستند، به همین دلیل هم بهتره که قبل از شروع کدنویسی، از نیاز مشتری مطمئن شیم.Product Discoveryاول از همه باید مطمئن بشیم که مشتری واقعی این محصول رو می‌خواد، بعدش باید راه حلی پیدا کنیم که قابل استفاده، مفید و امکان‌پذیر باشه.کشف محصول، درباره ساختن محصول درست برای ارائه به مشتریه و به تیم‌های محصول کمک می‌کنه با درک مشکلات کاربر واقعی و سپس یافتن بهترین راه حل برای آن‌ها، ایده‌هاشون رو پالایش کنن.وقتی داریم درباره یک محصول تصمیم می‌گیریم، همیشه عدم قطعیت وجود داره. اصلا واسه همین هم کشف محصول انجام می‌دیم تا بتونیم خطرات مربوط به این تصمیم رو کاهش بدیم و ریسک رو پایین بیاریم، پس اگه کشف محصول رو کنار بذاریم، به احتمال خیلی زیاد ارتباط بین نیازهای کاربر و محصول رو قطع کردیم.مارتی کاگان (مدیر محصولی با سابقه در سیلیکون ولی)، معتقده که چهار ریسک بزرگ در مدیریت محصول وجود داره:۱ ریسک ارزش: آیا مشتری محصول رو می‌خره یا کاربر ازش استفاده می‌کنه؟۲ ریسک قابل استفاده بودن: آیا کاربر می‌دونه چطور از محصول استفاده کنه؟۳ ریسک امکان‌پذیری: آیا مهندسان ما می‌تونن چیزی رو که نیاز داریم در زمان مورد نظر و با فناوری‌های موجود در سازمان بسازن؟۴ ریسک ماندگاری کسب و کار: آیا این راه حل برای جنبه‌های مختلف بیزینس ما کار می‌کنه؟کشف محصول کمک می‌کنه تا این ریسک‌ها کاهش پیدا کنن، اما باید توجه داشته باشیم که هدف از کشف محصول فقط لیست کردن فیچر و نیازمندی‌های اون نیست، بلکه ایجاد محیط یادگیریه که بتونیم در اون محصول رو مرتب بهبود بدیم.خب ما برای کشف محصول می‌تونیم از مراحل زیر استفاده کنیم:اول از همه باید یه مدل داشته باشیم. ما اینجا از مدل دابل دیموند برای دیسکاوری استفاده می‌کنیم که شامل مراحل زیره:double diamond · کشف نیاز اساسی کاربر:فهمیدنتعریف· شناسایی راه‌حل‌های بهینه:ایده‌آلپروتوتایپ (نمونه اولیه)تستکشف نیاز اساسی کاربر:دیسکاوری یا کشف محصول با شناسایی چالش‌هایی که می‌خوایم توی محصولمون فیکس کنیم، شروع می‌شه. مثلا یه چالش مثل این «چطور می‌تونیم کاری کنیم تا شرکت‌های بازار میانی از تخته محصول استفاده بهتری کنن؟»تعریف چالش گاهی سخته و حتی ممکنه گاهی در پایان پروسه ریلیز محصول با چالش جدیدی روبرو بشیم. در کل چالش‌ها رو می‌تونیم با بررسی مشکلات فعلی و نیازهای کاربران پیدا کنیم یا حتی در زمان برطرف کردن یه چالش دیگه. مثلا ممکنه در حال بهبود محصول باشیم و حفظ امنیت کاربر هم به اهدافمون اضافه بشه.فهمیدن: برای شناسایی صحیح چالش، ابتدا باید نیازهای اساسی کاربر در زمان استفاده از محصول رو درک کنیم. دراین مرحله، تیم محصول ما برای رسیدن به پاسخ، نیاز به تحقیقات کمی و کیفی داره. بعضی از ابزارها و تکنیک‌هایی که می‌تونه توی این مسیر بهمون کمک کنه به ترتیب شامل موارد زیره:تحقیقات کاربر ، تشکیل گروه‌های تمرکز، مشاهده، مصاحبه با مشتری، تحلیل دیتا، تحقیقات مقایسه‌ای و نقشه همدلی (empathy mapping).تعریف: بعد از درک نیازهای کاربر، باید بتونیم اون‌ها رو به وضوح تعریف کنیم. برای انجام این کار، چند مرحله وجود داره: برطرف کردن مشکل: هدف رو باید طوری بنویسیم که کل مشکلی که قراره حل کنیم، پوشش بده. این بهمون کمک می‌کنه تا با تیم ارتباط برقرار کنیم و به یه درک مشترک از نتیجه کار برسیم. اگه مشکل رو به طور دقیق ننویسیم، تمرکز درباره اینکه چی می‌خوایم برای همه سخت می‌شه. تایید مشکل: باید مطمئن شیم که مشکب در محیط واقعی وجود داره و نیاز به حل شدن داره. مشکلی که کاربرامون لمس می‌کنن، چقدر بزرگه؟ حل این مشکل چقدر ارزش داره؟ اولویت بندی: باید مطمئن بشیم که کدوم یکی از مشکلات شناسایی شده رو باید ابتدا حل کنیم. چندین فریم‌ورک وجود داره که توسط تیم‌های محصول مورد استفاده قرار می‌گیره. مثل RICEبرای تعریف مشکل، بعضی از تیم‌های محصولی از روش‌هایی مثل نقشه راه (journey mapping) یا آنالیز SWOT استفاده می‌کنن.شناسایی راه‌حل‌های بهینه:بعد از اینکه مشکلات خاص کاربر رو جدا کردیم، بهتره آن‌ها رو به بخش‌های کوچیکتر تبدیل کنیم تا راحت‌تر به نتیجه برسیم. توی این مرحله، ایده‌های اولیه، پروتوتاپ‌ها و تست راه‌حل‌های احتمالی رو دوباره با تیم اولویت بندی می‌کنیم. همه این‌ کارها رو به یه دلیل انجام می‌دیم و اون هم اینکه قبل از دلیوری محصول، از ارزش و اعتبارش مطمئن بشیم.ایده‌آل: در حالت ایده‌آل می‌دونیم که چطور برای حل مشکلات کاربر باید برنامه ریزی کنیم. این جاییه که تیم ما می‌تونه با تمرین‌های نوآوارانه و سایر تکنیک‌های ایده‌پردازی (طوفان فکری (brainstorming)، نقشه ذهنی (mind mapping) یا طراحی داستان (storyboarding) و حتی اجرای اسپرینت طراحی (design sprint)) وارد عمل بشه.بعد از ارائه ایده‌ها، تیم‌ می‌تونه وارد فاز امکان‌سنجی و بعد اولویت‌بندی برای پروتوتایپ بشه. بعدش پروتوتاپ‌ها رو به مشتری ارائه می‌دیم و فیدبک می‌گیریم.پروتوتایپ (Prototype): داشتن پروتوتایپ باعث می‌شه بتونیم ایده‌ها رو به صورت زنده نشون بدیم. پروتوتایپ‌ها نمونه‌های مختلفی دارن که بنا به نوع خروجی که تیم می‌خواد ازش بگیره انتخاب می‌شن. مثلا طرح‌ها (sketches)، ماکت‌ها (mockups)، پروتوتاپ قابل کلیک (clickable prototypes)، نسخه اولیه (MVPs) و حتی محصول ساده قابل مقایسه (competitive/similar products).تست: مرحله تست مشخص می‌کنه که آیا راه حل پیشنهادی می‌تونه مشکل و حل کنه یا خیر؟ ابزارهای رایج تست عبارتند از: تست آ/ب (A/B testing)، مصاحبه با مشتری (customer interviews)، تست کاربر (user testing)، توزیع نظرسنجی (distributing surveys) و تست بتا محصول (product beta testing).نکته پایانی: در مجموع فراموش نکنیم که هیچ‌چیزی در مرحله راه حل ساخته نمی‌شه و فقط قراره ایده‌‌هامون رو به ذی‌نفعان و کاربران نشون بدیم. بعد از این مرحله و دریافت تایید ذی‌نفعان و کاربران، وارد فاز دلیوری می‌شیم.پ.ن: این متن ترجمه آزادی از لینک زیره. من سعی کردم به زبانی ساده و به صورت خلاصه یه راهنمای سریع و آسون برای فاز کشف محصول ترجمه کنم و در اختیار شما عزیزان قرار بدم.پ.ن ۲: از اونجایی که ما به تلفظ انگلیسی بعضی از کلمات عادت کردیم، احساس کردم ترجمه لغویشون خیلی بد می شه، واسه همین اصل کلمه رو توی پرانتز گذاشتم.برداشت آزاد از:https://www.productboard.com/blog/step-by-step-framework-for-better-product-discovery/ سارا رشادی سارا رشادی Sun, 19 Sep 2021 15:36:57 +0430 https://virgool.io/@sara.reshadi/%DB%B6-%D8%B1%D8%A7%D9%87-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%DB%8C%D9%86%DA%A9%D9%87-%D8%AA%DB%8C%D9%85-%D8%A8%D9%87%D8%AA%D8%B1%DB%8C-%D8%AF%D8%A7%D8%B4%D8%AA%D9%87-%D8%A8%D8%A7%D8%B4%DB%8C%D8%AF-bx79lf8ltoyd Team buidingهدایت یه تیم اصلا کار آسونی نیست. حالا می‌خواد یه تیم ۱۰ نفره باشه یا ۱۰۰ نفره.شما باید آدم‌های مختلف رو در کنار هم قرار بدید و در مسیر رسیدن به یک هدف واحد، هدایتشون کنید. این اصلا کار کوچیک یا آسونی نیست، حتی شاید شما رو دیوونه کنه! (شوخی کردم، نترسید)همین موضوع، یعنی گروه‌بندی کردن آدمهایی مختلف با اخلاق‌های متفاوت، گاهی ممکنه منجر به شکل‌گیری ارتباطات اشتباه و بروز درگیری بشه و ناگفته پیداست که هر دوی این‌ها در نهایت روی بهره‌وری در محل کار اثر منفی می‌ذاره.با این وجود اگه کمی با تدبیر رفتار کنید و یه سری نکات ریز و کاربردی رو بدونید، احتمالا می‌تونید این مشکلات رو پشت سر بذارید و به اهدافتون برسید. پس خیلی نگران نباشید.اینکه چطور بین آدم‌های یک تیم، تقسیم کار کنید تا همه با هم به یه هدف مشترک برسند، خودش یه هنره و من امروز می‌خوام با شما درباره این هنر ناب صحبت کنم. فارغ از اینکه تیم شما چقدر سودمنده، همیشه راه‌هایی وجود داره که تیم شما و محیط کاریتون رو به سطح بهتری ارتقا بده، اما قبل از اشاره به چند نمونه ازاین راه‌ها، دوست دارم با هم به معنی سودمندی و بهره‌وری نگاه کنیم تا به یه تعریف مشترک برسیم.بهره‌وری در واقع سطحی از عملکرده که در اون از کمترین مقدار ورودی، بیشترین خروجی رو می‌گیریم. از اونطرف، سودمندی میانگین اندازه‌گیری بهره‌وریه (ایشالا گیج نشده باشید)خب بریم سراغ اون راه‌هایی که می‌تونه یه تیم رو به یه تیم خوب و یه تیم خوب رو به یه تیم خفن تبدیل کنه:۱ به اعضای تیمتون حس مالکیت بدیدبهترین رهبران، قدرت مالکیت رو درک می‌کنن. دادن حس مالکیت به اعضای تیم به معنای این نیست که اون‌ها اختیار تصمیم‌گیری شخصی دارند، بلکه به این معناست که اون‌ها در قبال کارهاشون پاسخگو هستن. وقتی یک تیم رو به این سطح می‌رسونید که پاسخگوی کارهای خودشون باشن، در واقع به اون‌ها حس مسئولیت‌پذیری می‌دید و باعث می‌شید از زاویه‌ای متفاوت به کارهاشون و تاثیر اون بر کل تیم نگاه کنن. شما به شیوه‌های متفاوتی می‌تونید به تیم حس مالکیت بدید، مثلا با دادن مسئولیت هدایت یه پروژه، مسئولیت‌ دلیوری یک تسک یا ....شاید باورتون نشه، اما هیچ‌چیز بیشتر از ایجاد عزت نفس در کارکنان، به قدرتمند شدن یک سازمان کمک نمی‌کنه.۲ مشخص کردن وضعیت ارتباطاتارتباطات یک فاکتور کلیدی در ایجاد تیم سودمنده. بدون ارتباط موثر، بیزینس شکست می‌خوره. به خاطر اینکه در غیاب ارتباط موثر، ارتباط نادرست به وجود میاد و همین شروع شکست‌های پشت سرهم خواهد بود. بسیاری از سازمان‌های موفق، شکوفاییشون رو مدیون ارتباطات موثر هستند.۳ شناسایی نقاط قوت و ضعف تیمهر انسانی، استعدادهای پنهانی داره که می‌تونه ازشون به خوبی استفاده کنه. وظیفه رهبر تیم اینه که استعدادها رو کشف کنه و در هنگام تخصیص وظایف این نکته رو در نظر داشته باشه. مثلا اگه یه نفر در تیم خارج از چهارچوب فکر می‌کنه، می‌تونید اون رو مسئول ارائه ایده به مشتری کنید.۴ تیم سازی کنید!بهره‌وری ارتباط مستقیمی با میزان رفاقت بین اعضای تیم داره. اگه اعضای تیم با هم همراه باشن و از نقاط ضعف و قوت هم باخبر باشن، محل کارشون به طور خودکار به مکانی شادتر تبدیل می‌شه و این حس شادی باعث افزایش بهره‌وری و سودمندی در کار می‌شه. برای تقویت این حس، فعالیت‌های تیم‌سازی رو جدی بگیرید و سرگرمشون کنید.۵ بهشون مشوق بدیدتجربه ثابت کرده کارمندها با گرفتن مشوق بهتر کار می‌کنن. آن‌ها ترجیح می‌دن از طرف رییسشون ازشون قدردانی بشه. به همین دلیل هم بسیاری از کارفرمایان از برنامه‌های تشویقی برای ایجاد انگیزه در کارکنانشون استفاده می‌کنن.براساس مطالعات ۸۵ درصد کارمندان وقتی تشویق می‌شن، انگیزه بیشتری برای انجام کار بهتر دارن. این مشوق می‌تونه پول نقد، کوپن رایگان، مرخصی با حقوق، نهار یا ... باشه.۶ به همدیگه فیدبک بدیدآخرین و اما مهم‌ترین نکته، فیدبک دادن اعضای تیم به یکدیگره. اگه آدم‌ها ندونن نقاط ضعفشون در ابتدا کجا و چی بوده، نمی‌تونیم انتظار داشته باشیم که کارآیی افراد بالا بره. به همین دلیل هم هست که بررسی عملکرد و بازخورد سازنده در بهره‌وری تیم نقش مهمی داره. سعی کنید فرهنگ گفتگوی باز رو تشویق کنید تا همکاری‌های بعدی آسونتر از قبل بشه.جمع بندی:به طور کلی هیچ راه مشخص یا الگوی از پیش نوشته شده‌ای برای تقویت تیم‌ها وجود نداره. این موارد، فقط پیشنهادهای تجربی و آزموده شده‌ای هستن که می‌تونه به شما کمک کنه، تیم‌تون رو بسازید و تقویت کنید. به رفتار جمعی نگاه کنید و علایق مشترکشون رو پیدا کنید و پرورش بدید. هیچ‌چیزی بیشتر از اینکه اعضای تیم حس کنن کارشون دیده شده و ازشون قدردانی می‌شه به رشد و بهبود وضع تیم کمک نمی‌کنه. با ارائه پشتیبانی، بازخورد و تشویق مداوم می‌تونید به زودی شاهد افزایش چشم‌گیر میزان بهره‌وری در تیم باشید.پ.ن: این متن ترجمه آزاد و خلاصه ای از مقاله‌ای به همین نام در آدرس اینترنتی زیر بود: https://www.proofhub.com/buzz سارا رشادی سارا رشادی Wed, 01 Sep 2021 10:26:54 +0430 https://virgool.io/@sara.reshadi/%DA%86%D8%B7%D9%88%D8%B1-%D9%85%D9%88%D9%81%D9%82%DB%8C%D8%AA-%D8%AA%DB%8C%D9%85-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%B1%D9%88-%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%D9%87-%D8%A8%DA%AF%DB%8C%D8%B1%DB%8C%D9%85-oco13epg0zcl جیم اس. میلر، درباره متریک می‌گه: مهم‌ترین متریک ما اینه که از خودمون بپرسیم: آیا همون چیزی رو که می‌خواستیم، اجرا کردیم؟ و آیا همون محصولی که قول داده بودیم رو با تمام ارزش‌هاش تحویل دادیم؟success scrum teamممکنه عضوی از یه تیم اجایل باشید و بارها از خودتون پرسیده باشید چطور می‌شه عملکرد تیم رو اندازه گرفت؟ آیا ما در مسیر موفقیت هستیم؟تقریبا هر چیزی رو می‌شه اندازه گرفت، اما در مورد اجایل روش اندازه گیری و تخمین‌ها کمی متفاوته.واقعیت اینه که تیم‌های اجایل سبک کاریشو براساس تحویل افزایشیه (یعنی مثلا یه فیچر رو کم کم و به صورت پیوسته ریلیز می‌کنن). بر همین اساس هم برای ارزیابی عملکرد تیم‌های اجایل از تخمین دلیوری استفاده می‌شه.تخمین‌ها در واقع نوعی پروکسی برای تعیین ارزش‌ کار انجام شده هستند. مثلا استوری پوینت، به عنوان یه ارزش و یه شاخص برای اندازه گیری سختی و وزن تسک پذیرفته شده است.اگه دقت کرده باشید، می‌بینید مواردی از نظر سهامداران پروژه به عنوان ارزش واقعی شناخته می‌شن، برای اینکه معیار اندازه‌گیری باشن، زیادی سخت هستن به همین دلیل به متریک‌هایی نیاز داریم که به اصطلاح کوک آید (cock-eyed) باشن. (فکر کنم معادل فارسیش می شه سریع به چشم بیان.)این متریک‌ها با توافق تیم اجایل به وجود میان و مثلا نشون می‌دن که تخمین تیم از میزان کار قابل دلیوریشون در هر اسپرینت چقدره؟از این داده‌ها برای پیش‌بینی اینکه با کمک این تیم، محصول نهایی چه زمانی دلیور می‌شه استفاده می‌کنیم.مزیت اصلیش هم اینه که تخمین دقیقتر و محصول با کیفیت‌تری خواهیم داشت. به خاطر اینکه در اجایل، محصول به صورت افزایشی تولید و تحویل مشتری می‌شه، در بازه‌های زمانی کوتاه قابل بازرسی و اصلاح هست و زمان تحویل مرتب آپدیت می‌شه.امروز می‌خوام به دو تا از این متریک‌های مهم که در اسکرام استفاده می‌کنیم، اشاره کنم:اسپرینت برن داون (The Sprint Burndown)اسپرینت برن داون یه مثال از متریک‌های اجایله. اسپرینت برن داون یه نموداره و تا رسیدن به هدف در تمام اسپرینت، آپدیت می‌شه.این نمودار از یه محور افقی تشکیل شده که بر اساس روزهای اسپرینت تقسیم بندی شده و یه محور عمودی که براساس استوری پوینت مرتب شده.The Sprint Burndownهمونطور که می‌دونید در اسکرام به جای استفاده از زمان، از تخمینی به نام استوری پوینت استفاده می‌شه.ماجراش هم اینه که در طول جلسه پلنینگ، توسعه‌دهندگان بعد از اینکه با پروداکت اونر صحبت کردن و براساس هدف اسپرینت، کار برداشتن و آوردن توی اسپرینت بک لاگ، به هر کدوم از این کارها یه امتیازی می دن و این امتیاز، اسمش استوری پوینت هست.براساس شاخص‌هایی مثل ظرفیت تیم در اسپرینت‌های گذشته، تعداد نیروها، روزهای تعطیل و ... عددی به عنوان ظرفیت اسپرینت پیش‌بینی می‌شه و با تقسیم اون به تعداد روزهای اسپرینت، یه خط فرضی به دست میاد. میزان تفاوت کارآیی تیم نسبت به اون خط فرضی سنجیده می‌شه.برای اینکه بهتر بتونیم وضعیت دلیوری محصول رو فالو کنیم و همچنین روند رشد تیم رو بررسی کنیم، از اسپرینت برن داون استفاده می‌کنیم. اسپرینت برن داون نشون می‌ده تیم با ظرفیتی که داره چقدر می تونه کار کنه و چطور باید بهتر برنامه‌ریزی کنیم.(اگه به توضیحات تکمیلی نیاز دارید، اینجا مفصل درباره برن داون توضیح دادم)پروداکت برن داون (The Product Burndown)یه نمودار مهم دیگه، نمودار پروداکت برن داونه که یه راه خیلی متداول برای تخمین زمان دلیوری پروژه براساس استوری پوینت به حساب میاد و خیلی هم پر کاربرده.از نظر ظاهری این نمودار خیلی شبیه اسپرینت برن داون هست و جالبه که بدونید، مبنای رسمش هم براساس برن داونه با این تفاوت که نمودار افقی بر اساس اسپرینت‌های مختلف و نمودار عمودی هم مثل قبل بر اساس استوری پوینته.The Product Burndownبا شروع یه فیچر در اولین اسپرینت این نمودار رسم می‌شه و تا زمان دلیوری اون فیچر به مشتری، براساس تعداد استوری‌ پوینت‌های باقی مونده تا دلیوری کامل و میزان پوینتی که در هر اسپرینت انجام شده، نمودار رسم می‌شه.تکمیل این نمودار ممکنه چند اسپرینت، ماه یا حتی سال طول بکشه و هدفش فالو کردن محصول از لحظه شروع تا دلیوری هست.علاوه بر این، تفاوت دیگه‌‌ش اینه که این نمودار برای تیم توسعه نیست، بلکه مخاطب اصلیش سهامداران و افراد بالادستی و مدیران سازمان هستند که تمایل دارن نتایج دلیوری محصول رو دنبال کنن.سخن پایانی: چرا تخمین؟ چرا زمان نه؟ (بر وزن چرا تهران نه؟)متریک‌های اجایل و اسکرام به همین دو نمودار ختم نمی‌شه، اما سعی کردم خیلی خلاصه دوتا از پرکاربردترین‌ها رو بهتون معرفی کنم. به عنوان حسن ختام هم شاید بد نباشه به این بپردازیم که چرا می‌ریم سراغ استوری پوینت؟ جرا براساس ساعت برنامه‌ریزی نمی‌کنیم؟اگر دقت کرده باشید، ما گفتیم که توی اسکرام از تخمین استفاده می‌کنیم به جای زمان، اما چرا این کار رو می‌کنیم؟ دلیوری فیچرهای زود هنگام مهم‌تر از هرچیزیه و اینه که مشتری رو راضی نگه می‌داره. درسته؟قطعا ما می‌دونیم و درک می‌کنیم که اندازه‌گیری پیشرفت اسپرینت براساس تخمینی مثل استوری پوینت، خیلی قطعی و قابل اتکا نیست و حتی ممکنه یه جاهایی نشه ازش استفاده کرد.چیزی که استوری پوینت و نمودار برن داون به تیم می‌ده در واقع، شفافیته و باعث می‌شه در هر لحظه از اسپرینت، تیم و هر کسی که به نمودار نگاه می‌کنه ببینه وضعیت چیه و اگه مشکلی هست، همونجا سریع حل کنیم. بر همین اساس هم استفاده از استوری پوینت می‌تونه به تیم کمک بیشتری کنه.ترجمه آزاد از: scrum.org سارا رشادی سارا رشادی Wed, 02 Jun 2021 10:11:14 +0430 https://virgool.io/@sara.reshadi/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%AF%D8%B1-%D8%A7%D9%85%D8%AA%D8%AD%D8%A7%D9%86-psm-1-%D9%85%D9%88%D9%81%D9%82-%D8%B4%D9%88%DB%8C%D9%85-ndidicnxlonh PSM 1خب سلام علیکممن هر روز به خودم می‌گم بیام بگم چطوری می‌شه توی این آزمون شرکت کرد، بعد هی سرم شلوغ می‌شه، با خودم می‌گم ایشالا فردا. اگه می‌شد واستون ویس فرستاد، تا حالا تعریف کرده بودم و تامام.اول از همه بگم که نداشتن مدرک، چیزی از حرفه‌ای بودن ما کم نمی‌کنه، همونطور که داشتنش ما رو علامه دهر نمی‌کنه.اسکرام همونطور که همه می‌دونیم و همه‌جا هم نوشته شده «بسیار آسونه اما تسلط بر اون بسیار سخته» و وقتی ما آزمون رو می‌دیم این بهمون بیشتر ثابت می‌شه.راهنمای اسکرام رو که نگاه می‌کنیم کلا ۱۴ صفحه‌س اما واقعا فقط با خوندن این ۱۴ صفحه آدم اسکرام‌مستر نمی‌شه. چون یه عالمه حرف نگفته داره و یه عالمه شرایط مختلف ممکنه پیش بیاد.من چند ساله اسکرام‌مستر هستم، اما توی این چند سال، به تعداد روزهای کاریم تجربه متفاوت داشتم.هر روز، هر آدمی، هر وضعیتی یه تجربه جدیده و این رو لابلای سوالات آزمون هم می‌تونیم ببینیم.بیشتر سوالات اینجوریه که فرض کنیم یه تیم هست با فلان شرایط، بهترین تصمیم در مقام اسکرام مستر چیه؟خب اینا رو بذاریم کنار، بذارید از اول بگم چطور بریم سراغ این آزمونفرض کنیم که شما یه اسکرام‌مستری هستید، مثل من که دارید توی این حوزه کار می‌کنید، اما دلتون می‌خواد مدرک PSM1 هم بگیرید.هدف من چالش شخصی بود، هدف شما هر چیزی می‌تونه باشه.شرکت در این آزمون دو بخش داره:- آمادگی- ثبت نامآمادگی:غول مرحله اول (بزرگترین غول) آمادگیه.باید خط به خط و کلمه به کلمه راهنمای اسکرام ۲۰۲۰ رو بخونیم و درک کنیم و در شرایط مختلف به یاد بیاریم، توصیه راهنمای اسکرام چی بوده. پس تا می‌تونیم بخونیم و درک کنیم. (برای آزمون حداقل ۳ بار به بالا بخونیم.)در این مسیر سایت Scrum.org می‌تونه بهمون کمک زیادی کنه. من خیلی وقتا گفت‌وگوهای اسکرام مسترها رو می‌خوندم و لابلای تحلیل‌هاشون، جوابم رو می‌گرفتم.اگه بکوب و شبانه روز بخونید شاید سه هفته طول بکشه، اما اگه مثل من همزمان هزارتا کار دیگه هم داشته باشید و شاغل هم باشید، ممکنه یکی دو ماه وقتتون رو بگیره.بعد اینکه یه عالمه تست وجود داره که می‌تونیم با سرچ گوگل بهش برسیم. مهمترینش هم همون تست‌های رایگان سایت اسکرامه. اون تست‌ها رو انقدر بزنیم که ۴ دفعه آخر، بتونید ۱۰۰ درصد پاس کنیم.این سوالات مو به مو توی امتحان اصلی نمیاد، اما مشابهش زیاد میاد و بهمون دید خوبی می‌ده که بتونیم شرایط رو فرض کنیم و سریع تصمیم بگیریم.اماااااااادر بخش تست زنی، یه امای بزرگ وجود داره.اگر ما همت می‌کردیم و قبل از انتشار راهنمای ۲۰۲۰ مدرک رو می‌گرفتیم خیلی خوب بود. چون بیشتر تست‌هایی که وجود داره، هنوز براساس راهنمای قبلیه و آپدیت نشده متاسفانه.ولی حالا که راهنمای ۲۰۲۰ اومده باز هم نگران نباشید، فقط خیلی دقت کنیم و اگه تست‌های اینترنتی رو می‌خونیم مواظب باشیم که بعضی از جواب‌ها غلطه.تغییرات اسکرام ۲۰۲۰ رو در نظر بگیریم و انقدر بخونیم که وقتی تستی رو با جواب اشتباه ببینیم، بتونیم تشخیص بدیم که اشتباهه و درستش چی بوده.حالا چرا من انقدر اصرار می‌کنم حسابی مطمئن شیم؟ چون این آزمون مثل کنکوره، اما با هزینه ۱۵۰ دلاری.ثبت نامبعد از اینکه مطمئن شدیم آماده هستیم، تشریف می‌بریم سایت scrum.org اکانت می‌سازیم و لاگین کنیم.(یادتون باشه، هر اسمی انتخاب کنید، روی مدرکتون همون اسم ثبت می‌شه.)بعد باید PSM1 رو انتخاب کنیم، هزینه ۱۵۰ دلاریش رو با پی‌پال یا ویزاکارت یا گیفت‌کارت بپردازیم.مرحله بعد یه ووچر برای شما ایمیل می‌شه (حداکثر تا یک روز کاری بعد). این ووچر تاریخ انقضا نداره اما یکبار مصرفه، پس اگه خدای نکرده دستتون اشتباهی بخوره، بخواید تست کنید ببینید کار می‌کنه یا توی آزمون رد بشید، ۱۵۰ دلار پریده.آزمون به زبان انگلیسی برگزار می‌شه، پس مطمئن شیم که در شرایط استرسی امتحان، معنی کلمات از ذهنمون نمی‌پره.بعد از اینکه استارت رو زدیم، ۶۰ دقیقه وقت داریم که به ۸۰ سوال جواب بدیم. (تقریبا ۴۵ ثانیه برای هر سوال)برای قبولی در این آزمون باید حداقل ۸۵ درصد سوالات رو درست جواب بدیم، پس قبلش حسابی تمرین کنیم که بتونید زمان رو مدیریت کنیم.نکته بعدی اینکه صفحه قفل می‌شه و نمی‌تونیم متن رو توی گوگل کپی کنیم و اصلا فرصتش هم نداریم، پس این گزینه رو بیخیال می‌شیم و قبل از آزمون حسابی آماده می‌شیم.بعضی از سوالات از جنس «فرض کنید تیم اینجوریه، حالا چیکار کنیم که اوضاع درست شه» هست، بعضیای دیگه مثل امتحان‌های کنکور جای خالی را پر کنید و کدام گزینه صحیح است و ....اگه سوالی رو شک داریم یا بلد نیستیم، زمان رو از دست ندیم. اون سوال رو بوک مارک کنیم، برید سراغ بعدی و اگه وقت اضافه آوردیم برگردیم و تصحیح کنیم.اگه زمان اضافه آوردیم به هیچ‌وجه دکمه پایان رو نمی‌‌زنیم، برمی‌گردیم سراغ سوالاتی که شک داریم و با دقت می‌خونیمشون.تجربه منمن خیلی تست زدم و خیلی مقاله خوندم. انقدر که وقتی تست می‌زدم و می‌دیدم سایت یه جواب غلط داده، می‌دونستم اشتباه کردن و جواب درست چیه.کلی هم تایم گرفته بودم و هر ۸۰ سوال رو می‌تونستم توی ۲۵ دقیقه تموم کنم.با این حال موقع آزمون اصلی به شدت استرس داشتم. طوری که روی سوال اول ۳ دقیقه وقت گذاشتم، آخرش هم بوکمارک کردم رفتم سراغ بعدی‌.آخرش وقتی در دقیقه ۵۹:۳۶ برگشتم سراغ اون بوکمارک، دیدم درست جواب دادم و فقط استرس گرفته بودم.من آزمونم رو با ۹۴ درصد پاسخ صحیح پاس کردم و خیلی خوشحالم.می‌خواستم به خودم یه کادوی خوب بدم که دادم، فقط باهام خیلی گرون تموم شد.موقعی که من آزمون دادم دلار نزدیک ۲۵ تومن بود الان که دارم اینو واستون می‌نویسم، به فاصله یک هفته بعد دلار حدودای ۲۱ شده. (که اینم شانس مایه. اگه من امتحان نمی‌دادم دلار شده بود ۲۶)قطعا شما هم می‌تونید توی این آزمون موفق شید، فقط یادتون نره که این یه کنکوره که دانش آکادمیک و تجربه شما رو با هم محک می‌زنه.پس حسابی آماده شید و به پاسخ‌های خودتون ایمان داشته باشید. سارا رشادی سارا رشادی Thu, 06 May 2021 13:53:30 +0430 https://virgool.io/@sara.reshadi/%DA%86%DA%AF%D9%88%D9%86%D9%87-%DB%8C%DA%A9-%D8%B1%D9%88%D8%AF%D9%85%D9%BE-%D8%AE%D9%88%D8%A8-%D8%A8%D9%86%D9%88%DB%8C%D8%B3%DB%8C%D9%85-py3keak7toar نوشتن یک نقشه راه (رودمپ) در عین سادگی، بسیار چالش‌ برانگیزه. باید مواظب باشید که مسیر رو درست طراحی کنید، اما چطوری؟roadmapراستش رو بخواید، خیلی وقت بود که می‌خواستم بنویسیم، اما فرصت نمی‌شد. تصمیم گرفتم از تعطیلات نوروزی استفاده کنم و اولین مطلب سال رو واستون بنویسم.در همین راستا، از چیزی که این روزها دغدغه خودم شده، یعنی رودمپ شروع می‌کنم و امیدوارم واستون مفید باشه.داشتن یه رودمپ یا همون نقشه راه، به آدم کمک می‌کنه با جدیت بیشتری در مسیر مورد نظرش قدم برداره. فرض کنید که شما می‌خواهید به بهترین فرد توی رشته کاری خودتون تبدیل بشید، این عالیه اما چطور قراره به این هدف برسید؟برای اینکه وسط راه دلسرد نشید، به بیراهه نرید و توی مسیر بمونید، به رودمپ احتیاج دارید.حالا جدای از اهداف شخصی، توی کار هم به رودمپ نیاز داریم.پروداکت منیجرها و پروداکت اونرها بیشتر با این کلمه مواجه هستن و در دنیای اسکرام شاید هر روز یا هر هفته یا هر کوارتر این کلمه رو بشنوید.در مسیر دلیوری یه فیچر، همیشه به یه رودمپ نیاز داریم تا ببینیم کجای مسیر هستیم و چطور باید ادامه بدیم.پس اگر به دنبال رسیدن به اهداف شخصی هستید، یا کاری، این پست برای شماست. من در این پست بیشتر درباره نوشتن رودمپ محصول صحبت می‌کنم اما اگر قصد نوشتن رودمپ شخصی با اهداف مشخصی رو دارید، باز هم می‌تونه واستون کاربردی باشه. با من باشید:شاید نوشتن رودمپ محصول یا حتی رودمپ شخصی، کاری زمانبر باشه، اما به شما و ذینفعان تیم‌های مختلف چشم اندازی از هدف می‌ده و مهم‌تر از همه اعتماد به نفستون رو تقویت می‌کنه.وقتی شروع به نوشتن رودمپ می‌کنید، پیش‌بینی درست مراحل، توجه به جزییات و ایجاد ارتباط بین مراحل کار سختیه. بیشتر اوقات افراد یا شرکت‌ها در نوشتن رودمپ دچار اشتباه می‌شن. چرا؟ چون به جای تمرکز بر تهیه یک نقشه راه محصول یا فردی خوب، روی تاریخ دلیوری تمرکز می‌کنن و خودشون و تیم رو دچار اضطراب می‌کنن.Product Roadmapشخصی‌سازی کنیدنقشه راه محصول باید استراتژی محصول رو طوری بیان کنه که همه مخاطبان با نیازهای منحصر به فردشون بتونن اون رو درک کنن. بر همین اساس می‌شه با تقریب خوبی گفت که رودمپ هر محصول براساس مشخصات و ویژگی‌های افراد اون سازمان و مشتریانش نوشته شده و یه جورایی شخصی‌سازی می‌شه. پس یادتون نره، قدم اول اینه که مخاطبان و ویژگی‌هاشون رو مشخص کنید.ریچارد میرونوو، مشاور محصول درباره رودمپ می‌گه: «به‌نظر من، رودمپ به جای ابزار تصمیم‌گیری، ابزاری برای ارتباطه. بیشتر مردم هدفشون نوشتن رودمپه اما من می‌گم هدف ما داشتن یه استراتژی محصول خوبه که براساس اون بتونیم در شرایط سخت تصمیم‌گیری کنیم و موارد رو به درستی اولویت‌بندی کنیم.»براساس تایم‌لاین برنامه‌ریزی کنید:قبل از هرچیزی بگم که نیازی نیست حتما یه لیست از تاریخ‌های دقیق برای رودمپ پروداکت مشخص کنید اما به هر حال باید برای فیچرهای کوتاه مدت، میان مدت و بلند مدت یه برنامه‌ریزی کنید و زمانی رو برای بررسی و تحویلشون در نظر بگیرید.مثلا:کوارتر: بازه‌های زمانی سه‌ماهه (کوارتر) رو در نظر بگیرید و ببینید تا انتهای هر کوارتر باید به چه خروجی‌هایی برسید. البته ممکنه همیشه همه چیز طبق برنامه پیش نره اما برنامه و چشم انداز سه‌ماهه داشتن، بهتر از نداشتنشه.ماه: پیش‌بینی کنید در هر ماه کوارتر قراره چه کاری رو انجام بدید. پیش‌نیاز و پس‌نیازش چیه. مثلا اینکه تا آخر فروردین قراره چی ریلیز کنید؟ برنامه اردیبهشت چیه و ...حالا، آینده، بعدا: مشخص کنید در هر مرحله قراره چیکار کنید و بعدش چی.Quarterبراساس فیچرها دسته‌بندی کنید:خودتون بپرسید: «چه فیچرهایی رو براساس تایم‌لاینی که حرفشو زدیم قراره در چه زمان‌هایی ریلیز کنید؟» برای دسته‌بندی درست‌تر، به نیازهای تیم‌های مرتبط، مخاطبان و ذی نفعان و اطلاعاتی که از طریق ابزارهای مدیریت پروژه به دست میاد هم توجه کنید. سعی کنید در مسیر نوشتن فیچرها، مشکلات و راه حل‌های پیشنهادیش از سمت افراد مختلف رو هم در نظر بگیرید. استفاده از خرد جمعی بیشتر به شما کمک می‌کنه.فیچرها می‌تونن مواردی مثل نمونه‌های زیر باشن:- فیچر ویدئو مسیج- ساختن فلو ساین‌آپ کاربر، ضبط ویدئو کال- به اشتراک گذاشتن فایل‌های ویدیویی سیو شدههدف‌هاتون رو مشخص کنید:به دنبال چه هدفی هستید؟ محصول مورد نظر شما قراره چه فیچری داشته باشه؟ مشخص کردن هدف یا اهداف، باعث می‌شه سازمان بدونه محصول (پروداکت) قراره به کدوم سمت هدایت بشه و چه دستاوردی قراره داشته باشه. برای این مرحله بهتره از ابزارهای گرافیکی استفاده کنید و نشون بدید محصول نهایی که توی ذهنتونه قراره چه شکلی بشه.مثلا:- بهبود بستر ارتباطی تیم- لانچ کردن داشبورد آنالیز- افزایش ماهانه یوزرهای فعال تا ۵ درصدوقت تصمیم‌گیریه:بعد از اینکه فیچرها، هدف و چشم اندازش مشخص شد، وقت اینه که کم‌کم رود مپ رو بکشید.برای این کار لازمه مدیر محصول (پروداکت منیجر) با تیم فنی مشورت کنه، فیچرهای پیشنهادی و هدفشون رو به تیم توضیح و تصاویر مرتبطش رو نشون بده و ازشون پیش‌بینی زمانی دلیوری (استیمیت) بگیره.بعد از مشخص شدن استیمیت‌های هر فیچر و با توجه به ظرفیت آدم‌های موجود می‌شه برنامه‌ریزی رو براساس تایم‌لاینی که بالاتر گفتیم انجام بدیم. یعنی پروداکت منیجر میاد و یه بازه زمانی حدودی رو برای دلیوری هر فیچر توی یه جدول وارد می‌کنه و با توجه به فاکتورهایی مثل اولویت بیزینس، نیاز مشتری، سایز فیچر و ... یه رودمپ رسم می‌کنه و نشون می‌ده در بازه‌های زمانی مختلف چه اتفاقاتی باید بیفته.البته می‌دونیم که همیشه همه چیز قابل پیش‌بینی نیست و ممکنه این تایم‌لاین جابجا بشه، به همین دلیل بهتره ۲۰ درصد رو به عنوان ضریب خطا در نظر بگیرید تا کمتر دچار تغییر بشید.پ.ن ۱: سعی کردم براساس چیزهایی که می‌دونم و البته خیلی خلاصه طوری که خسته نشید درباره رودمپ بگم، اگر جایی گنگ یا کلی بود، حتما بهم بگید که با هم بهترش کنیم.پ.ن ۲:یک چهارم از این متن ترجمه آزاد از این سایت بود: https://www.productboard.com/ سارا رشادی سارا رشادی Sun, 28 Mar 2021 11:08:51 +0430 https://virgool.io/@sara.reshadi/%DB%B1%DB%B8-%D8%A7%D8%B4%D8%AA%D8%A8%D8%A7%D9%87-%D8%B1%D8%A7%DB%8C%D8%AC-%D8%AF%D8%B1-%D8%AA%DB%8C%D9%85-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-b4jjkdnwuzhh شاید یه تیم خفن و کاردست اسکرامی باشید، اما ناخودآگاه و به مرور دچار اشتباهاتی شده باشید. امروز می‌خوام از این اشتباهات ریز و البته رایج باهاتون حرف بزنم.راهنمای اسکرام درباره نقش‌ها و ایونت‌ها توضیحات خوبی داده اما گاهی وقتی در محیط قرار می‌گیری همه چیز فرق می‌کنه. امروز می‌خوام درباره اشتباهات کوچیک اما رایجی صحبت کنم که هر تیمی ممکنه بهش دچار شه.scrum team https://virgool.io/p/b4jjkdnwuzhh/%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87%D9%86%D9%82%D8%B4%E2%80%8C%D9%87%D8%A7%DB%8C%D8%AA%DB%8C%D9%85%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85%D9%88%D8%A7%DB%8C%D9%88%D9%86%D8%AA%E2%80%8C%D9%87%D8%A7%D9%88%D8%AC%D8%B2%DB%8C%DB%8C%D8%A7%D8%AA%D8%B4%D9%88%D9%86%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7%DB%8C%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85%D8%A8%D9%87%D9%88%D8%B6%D9%88%D8%AD%D8%AA%D9%88%D8%B6%DB%8C%D8%AD%D8%AF%D8%A7%D8%AF%D9%87%D8%8C%D8%A7%D9%85%D8%A7%D8%A8%D8%A7%D8%A7%DB%8C%D9%86%D8%AD%D8%A7%D9%84%D9%88%D9%82%D8%AA%DB%8C%D8%AF%D8%B1%D9%85%D8%AD%DB%8C%D8%B7%D9%82%D8%B1%D8%A7%D8%B1%D9%85%DB%8C%E2%80%8C%DA%AF%DB%8C%D8%B1%DB%8C%D8%8C%DB%8C%D9%87%DA%86%DB%8C%D8%B2%D8%A7%DB%8C%DB%8C%D9%81%D8%B1%D9%82%D9%85%DB%8C%E2%80%8C%DA%A9%D9%86%D9%87.%D8%A7%D9%85%D8%B1%D9%88%D8%B2%D9%85%DB%8C%E2%80%8C%D8%AE%D9%88%D8%A7%D9%85%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87%D8%A7%DB%8C%D9%86%D8%AD%D8%B1%D9%81%D8%A8%D8%B2%D9%86%D9%85%DA%A9%D9%87%D8%A8%D9%87%D8%B9%D9%86%D9%88%D8%A7%D9%86%DB%8C%D9%87%D8%AA%DB%8C%D9%85%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85%DA%86%D9%87%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%DB%8C%DB%8C%D9%86%D8%A8%D8%A7%DB%8C%D8%AF%D8%A7%D9%86%D8%AC%D8%A7%D9%85%D8%A8%D8%AF%DB%8C%D9%85.%D8%A8%D8%B1%D8%A7%DB%8C%D9%87%D9%85%DB%8C%D9%86%D9%85%D9%88%D8%B6%D9%88%D8%B9%D8%AD%D8%B1%D9%81%D8%A7%D9%85%D8%B1%D9%88%D8%AF%D8%B1%D9%82%D8%A7%D9%84%D8%A8%D8%A7%DB%8C%D9%88%D9%86%D8%AA%E2%80%8C%D9%87%D8%A7%DB%8C%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85%D8%AF%D8%B3%D8%AA%D9%87%D8%A8%D9%86%D8%AF%DB%8C%DA%A9%D8%B1%D8%AF%D9%85: اشتباهات رایج در پلنینگ- در نظر گرفتن ظرفیت بالا: تیم توسعه ظرفیت رو بیش از حد ارزیابی کرده و کارهای زیادی برداشته. همه مواردی رو که ممکنه روی توانایی تیم برای دلیوری محصول اثر بذاره، در نظر بگیرید.- نادیده گرفتن بدهی فنی: تیم توسعه ظرفیت لازم برای رفع بدهی فنی و باگ در طول اسپرینت رو در نظر نمی‌گیره.- در نظر نگرفتن اسلک تایم: تیم توسعه باید ۲۰ درصد از اسپرینت رو به عنوان اسلک تایم در نظر بگیره. در نظر نگرفتن این زمان، باعث می‌شه وقتی واسه کارهای تیمی، رسیدگی فوری به مشکلات کوچیک یا برنامه‌نویسی جفتی باقی نمونه.- پلنینگ با جزییات زیاد: نباید توی تک تک تسک‌ها و ساب تسک‌ها ریز بشید. این دیگه اسمش برنامه‌ریزی نیست، تخصیص وظایف و جلسه فنی و همه چیزه جز پلنینگ.اشتباهات رایج در طول اسپرینت:- محدودیت WIP رو رعایت نمی‌کنید: محدودیتی در انجام همزمان چند تسک باهم ندارید. توجه کنید که هدف اسپرینت، ارائه افزایشی یه محصول به مشتریه. برای رسیدن به این هدف باید روی انجام کارهای ضروری و با ترتیب اولویت تمرکز کنید.- چری پیکینگ: تیم توسعه کارها رو به روش چری پیکینگ برمی‌داره. یعنی چی؟ یعنی بدون توجه به اولویت تسک‌ها، هرکدوم رو بیشتر باهاش حال می‌کنه یا آسونتره، انجام می‌ده. در نتیجه هدف اسپرینت از دست می‌ره.- بورد آپدیت نشده: وقتی بورد هر روز آپدیت نشه، هماهنگی بین اعضای تیم و افرادی که از روی بورد، کارها رو فالو می‌کنن سخت می‌شه.- ساید گیگز: تیم روی تسک‌هایی کار می‌کنه که روی بورد ثبت نشده. این نشون دهنده شلختگی و بی‌برنامگیه.- گلد پلتینگ: تیم توسعه با اضافه کردن کارهای غیرضروری به بلک لاگ اسپرینت، دامنه رو افزایش می‌دن. در نتیجه دچار اسکوپ چنگ یا گلد پلتینگ می‌شیم. این نشون می‌ده تیم توسعه به دامنه اصلی که با پروداکت اونر بسته، وفادار نیست.development teamاشتباهات رایج در دیلی https://virgool.io/p/b4jjkdnwuzhh/%F0%9F%93%B7developmentteam - با شماره تیکت حرف می‌زنید: مثلا یه نفر میاد می‌گه «دیروز روی تسک ۱۲۹ کار کردم امروز روی ۱۳۰» و اون لحظه کسی نمی‌دونه ۱۲۹ چی بود و ۱۳۰ چیه.- حل مشکلات فنی: تیم دولوپر از دیلی به عنوان زمانی برای حل مشکلاتش استفاده می‌کنه. مشکلات فنی، تیمی و ... رو مطرح می‌کنه.اشتباهات رایج در ری ویو- ارائه شفاهی: وقتی قرار باشه فقط به صورت شفاهی بگید چیکار کردید، خیلی حوصله‌ بقیه سر می‌ره و اصلا مطمئن نیستن کاری انجام شده باشه. پس سعی کنید واقعا چیزی برای نمایش داشته باشید و عملی نشون بدید.- تقلب: یه وقتایی کارتون هنوز تمام نشده، اما شما تقلب می‌کنید و برای اینکه نشون بدید خیلی کار کردید، جلسه ری‌ویو رو برگزار می‌کنید. اینجوری فقط اعتماد مشتری رو از دست می‌دید. نکنید آقا جان.-بیخیال ری‌ویو: ری‌ویو رو جدی نمی‌گیرید و اصلا برگزار نمی‌کنید. این یه اشتباه بزرگه که عواقبش رو به زودی هم در محصول و هم در روحیه اعضای تیم خواهید دید.اشتباهات رایج در رترو- رترو ندارید: تیم فکر می‌کنه همه چیز خوبه و نیازی به رترو نیست. خبر بد اینکه، وقتی فکر می‌کنید همه چیز خوبه، قطعا یه جای کار می‌لنگه. در برگزاری رترو مشارکت کنید.- رترو مهم نیست: اولویت رترو خیلی پایینه و اگه کار داشته باشن، رترو رو کنسل می‌کنن و می‌رن سراغ اون کار.- جلسه غرزنی: تیم از جلسه رترو واسه غر زدن استفاده می‌کنه و دنبال راه حلی برای بهبود اوضاع نیست.نتیجه:ممکنه خیلی از این موارد توی تیم شما اتفاق بیفته. خبر خوب اینکه از هرجایی متوجه بشید و به سمت تغییر برید، یعنی شما اصل چابک رو درک کردید. سعی کنید یه لیست درست کنید و ببینید چه اتفاقاتی توی تیم‌تون می‌افته و با همفکری تیم، مشکلات رو اصلاح کنید. سارا رشادی سارا رشادی Tue, 19 Jan 2021 10:31:54 +0330 https://virgool.io/@sara.reshadi/%D9%88%D8%B3%D9%88%D8%A7%D8%B3%D9%87%D8%A7%DB%8C%DB%8C-%DA%A9%D9%87-%D8%AA%DB%8C%D9%85-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%B1%D8%A7-%D9%86%D8%A7%D8%A8%D9%88%D8%AF-%D9%85%DB%8C%DA%A9%D9%86%D8%AF-q9kwjbqljfsa افرادی که تازه به اسکرام روی میارن، اغلب در تلاش هستن که مرزهای کنترلی بین مدیریت موثر، اسکرام مستر و مالک محصول رو درک کنن. این نکته خیلی مهمه، چون همون اندازه که این نقش‌ها روی کار تیمی و رشد اسکرام در سازمان موثره، می‌تونه باعث ایجاد مانع و توقف هم بشه.micro managementفرقی نداره اسکرام مستر باشید یا مدیر، ممکنه احساس کنید یه چیزی اشتباهه و باید درستش کنید. کاملا قابل درکه که نیت خوبی دارید و اصلا فکر نمی‌کنید روش میکرومدیریت رو در پیش گرفتید. مثلا ممکنه مدیران مستقیم به اعضای تیم پیشنهاد یا دستور بدن یا حتی ذی‌نفعان، استوری‌ها رو به مالک محصول دیکته کنه. یا اینکه اصرار کنه کارها رو به روش خاصی انجام بده چون قبلا صد بار همین راه رو رفته و نتیجه گرفته، یا هزاران مثال دیگه اما همه این مثال‌ها یه سری ویژگی مشترک دارن: «یه نفر، بجز افراد تیم که دارن مستقیم روی محصول کار می‌کنن، سعی داره روی چگونگی کار اثر بذاره.»من اینجا به چند مورد از میکرومدیریت که در محیط‌های اسکرامی رخ می‌ده، اشاره می‌کنم:اسکرام مستر به عنوان میکرومنیجر:· به جای تشویق خودسازماندهی، شخصا کارها رو به افراد تیم اساین می‌کنه. این حالت وقتی رخ می‌ده که اسکرام مستر نمی‌تونه بین نقش مدیر پروژه و اسکرام مستر تفاوت قائل شه.· افکار و ایده‌های خودش رو توی رترو اعمال می‌کنه.· به اعضای تیم می‌گه چطور کارشون رو انجام بدن.· به اعضای تیم می‌گه چطور مشکلاتشون رو حل کنن. این کار در نهایت به توانایی تیم برای اینکه چطور راه حلی برای مشکلات خودشون پیدا کنن، ضربه می‌زنه.· به اعضای تیم می‌گه مشکل دقیقا چیه. این کار هم مثل مورد بالا در نهایت به خودسازماندهی تیم ضربه می‌زنه.مالک محصول به عنوان میکرومنیجر:· کارهای جدیدی رو وسط اسپرینت اضافه می‌کنه و فورا هم می‌خواد تحویل بگیره. (بجز مالک محصول، مدیریت هم ممکنه همچین کاری کنه)· توجه ویژه‌ای به اسکرام دیلی داره و ازش به عنوان جلسه به روز رسانی وضعیت تیم استفاده می‌کنه. (اسکرام دیلی برای اعضای تیم توسعه‌س تا بتونن روی همکاری روزانه تمرکز کنن. اگه تیم از مالک محصول دعوت کنه که در این رویداد حاضر باشه، مالک محصول باید اینو درک کنه و دخالت نکنه.)· از اسکرام دیلی به عنوان جلسه‌ای برای بازجویی از تیم استفاده می‌کنه.· به جزییات کارهای اعضای تیم دقیق نگاه می‌کنه و همه چیز رو مو به مو چک می‌کنه. (یه مالک محصول خوب باید به رشد تیم کمک کنه و بذاره تیم تصمیمات کوچیکش رو خودش بگیره.)مدیریت و ذی‌نفعان به عنوان میکرومنیجر:توجه زیادی به اسکرام دیلی دارن و سعی می‌کنن نظراتشون رو در این رویداد اعمال کنن. جالبه که اسم این کار رو می‌ذارن «پیشنهاد»! (کلا حضور مدیریت توی اسکرام دیلی، این رویداد رو به جلسه گزارش وضعیت تبدیل می‌کنه. تیم ناخودآگاه به جای ارتباط چشمی با همدیگه، همه به مدیر نگاه می‌کنن. بعد هم پیشنهادها رو حتی اگه پیشنهاد باشه، دستور می‌بینن. چون می‌دونن جلب رضایت مدیر، روی بررسی عملکرد، افزایش حقوق و امنیت شغلیشون اثر می‌ذاره.)وسط اسپرینت از اسکرام مستر می‌خوان آپدیتی از وضعیت اسپرینت و روند پیشرفت رو بهشون بده.از نمودار برن داون چارت به عنوان متری برای اندازه‌گیری موفقیت و پیشرفت تیم در اسپرینت استفاده می‌کنند.از نمودار برن داون برای پیش بینی وضعیت بک لاگ استفاده می‌کنن.می‌خوان که سرعت (Velocity) افزایش پیدا کنه و تیم سریعتر کار کنه. البته که تیم هم اغلب سریعتر پیش می‌ره اما در عوض کیفیت کار پایین میاد.به بقیه می‌گه چطور باید کارشون رو انجام بدن.استوری‌ها رو به مالک محصول دیکته می‌کنه.به عنوان کارفرما با اسکرام مستر برخورد می‌کنه.در کل همه این نشونه‌ها به یک چیز ختم می‌شه: نیاز به اعمال کنترل شدید. این نیاز از اونجایی میاد که شخص معتقده می‌دونه چطور یه کاری رو بهتر از بقیه انجام بده. اما باید بدونید که مدیریت میکروسکوپی، در نهایت استقلال تیم رو می‌گیره و مشکلات منفی زیاد و البته موندگاری روی سازمانتون می‌ذاره.عواقب میکرو منیجمنت:۱ از بین بردن اعضای تیمدر سراسر دنیا ۶۷٪ کارمندان، از کار افتاده هستن! اون‌ها کار می‌کنن تا حقوق بگیرن، نه واسه اینکه از کارشون لذت می‌برن یا بهش اهمیت می‌دن. انرژی زیادی روی فرآیند یا بهبود محصول نمی‌ذارن و مایل هم نیستن آزمایشش کنن. وقتی تعداد زیادی از این آدم‌ها یه جا باشن مثل زامبی، انرژی بقیه رو هم می‌گیرن.در تیم‌های اسکرام، این حالت وقتی اتفاق می‌افته که مدیریت یا اسکرام مستر یا مالک محصول مدام فشار میاره که سریعتر کار کن. مثلا اینکه به کار تیم نگاه می‌کنن و مدام می‌گن چیکار کن که سرعتت بره بالاتر، این کار همیشه به استقلال تیم لطمه می‌زنه و تعاملشون رو با هم کم می‌کنه. در نتیجه کیفیت و کمیت کار میاد پایین و در نهایت این روی نارضایتی مشتری هم اثر می‌ذاره.۲ کاهش خودسازماندهیبدون خود سازماندهی و استقلال، ظرفیت (Capacity) تیم کاهش پیدا می‌کنه و فرصت آزمایش، شکست و یادگیری از این تجربه از بین می‌ٰره.۳ تاخیر در تصمیم گیریتیم نمی‌تونه تصمیم بگیره، چون فهمیده بدون تایید مدیریت احتمالا وقفه توی کار می‌افته. در نتیجه صبر می‌کنه تا مدیریت بیاد تصمیماتشون رو تایید یا رد کنه. ناگفته پیداست که این کار باعث تاخیر در تحویل به مشتری و نارضایتی او می‌شه. واقعیت اینه که هرچی مدیریت بیشتر بخواد کنترل رو دست بگیره باید تصمیمات بیشتری بگیره و هر تصمیم بیشتر، یعنی تیم باید بیشتر منتظر بمونه.معمولا در این مواقع تیم می‌ره سراغ کارهای کم اهمیت‌تر و کارهای مهم‌تر رو می‌ذاره بعدا که مدیر بیاد تایید کنه تا به مشکل نخوره. اینجور مواقع وقتی از بیرون نگاه می‌کنی، به نظر میاد تیم دنبال جلب رضایت مشتری نیست.۴ ارتباطات محدود اعضای تیموقتی مدیریت خرد زیاد می‌شه و تیم قبل از هر کاری نیاز به تصمیم گیری مدیر داره، دیگه نیازی به گفت‌وگو با هم‌تیمی‌های خودش نمی‌بینه. در نتیجه کارها به سبک آبشاری شروع می‌شه و در وهله اول روند بهبود شروع می‌شه و احتمالا هیچوقت تموم نمی‌شه. بعلاوه این کاهش ارتباط با کاهش تنوع اندیشه ترکیب می‌شه و به کیفیت محصول آسیب می‌زنه.راهکارهایی برای رهایی از میکرومنیجمنت:تیم رو با کارهای زیر عایق بندی کنید:از اسپرینت، جعبه سیاه بسازید و به ذی‌نفعان توضیح بدید که تیم برای موفقیت به فضا نیاز داره. کاری بهشون نداشته باشن تا آخر اسپرینت.نمودار برن داون رو ردیابی نکنید. وقتی عضو تیم اسکرام نیستید، نمودار به چه دردتون می‌خوره؟اگه ابزارهایی برای فالو کردن و سرک کشیدن به کار تیم دارید، بذارید کنار.اگه مالک محصول توی اسکرام دیلی رفتارهای میکرومنیجمنت داره، اسکرام مستر باید تا زمان بهبود رفتارهاش مانع حضورش در این رویداد بشه.پاداش فردی به اعضای تیم اسکرام رو کنار بذارید.به جای اینکه عدد سرعت تیم رو به مدیریت بدید، محدوده‌هایی از درصد بدید. (مثلا ۲۰٪- ۵۰٪- ۸۰٪)از نمودار برن داون برای بررسی بک لاگ اسپرینت استفاده نکنید.درباره روابط بین مدیران و اعضای تیم توسعه مذاکره کنید.درباره نقش اسکرام مستر و محدوده کارهای تیم توسعه صحبت کنید تا درک درستی درباره مرزبندی‌ها به دست بیاد.به مدیریت یادآوری کنید که اعضای تیم توسعه، درخواست از طرف مدیر رو یک الزام می‌دونن. پس شخصا درخواست یا پیشنهاد ندن.به مدیریت یادآوری کنید که حضور در اسکرام روزانه به تیم توسعه این سیگنال رو می‌ده که بزرگترشون حواسش به کاراشون هست.از مدیران بخواهید که روی نتایج تمرکز کنن نه نحوه انجام کار.ترجمه آزاد: https://agilepainrelief.com/blog/scrum-anti-patterns-micromanagement.html سارا رشادی سارا رشادی Mon, 30 Nov 2020 11:32:12 +0330 https://virgool.io/@sara.reshadi/%DB%B5-%DB%B1%DB%B0-%DB%B1%DB%B5-%D8%AD%D8%B1%DA%A9%D8%AA-fr3howrucndi به عنوان یک برنامه‌نویس که داره همراه با تیم کار می‌کنه، زمانتون رو چطور بین کدنویسی، رفع باگ و بدهی فنی مدیریت می‌کنید؟شاید با خودتون فکر کنید که نیازی به در نظر گرفتن زمان اضافی برای رفع بدهی فنی نیست و تیم باید از وقت آزادش صرف کنه اما واقعیت اینه که تیم بعد از مدت کوتاهی شروع به سقوط می‌کنه. تولید مداوم کد بدون توجه به کیفیت، قابلیت تحویل محصول در آینده رو کاهش می‌ده و عواقب بدی با خودش به همراه میاره.این اشتباهیه که خیلی از تیم‌های اسکرام انجام می‌دن. اون‌ها در محاسبه ظرفیت تیم، تمام ظرفیت رو به کد زدن اختصاص می‌دن. همونطور که در ابتدای متن هم اشاره کردم، این موضوع باعث چند تا آسیب جدی می‌شه:اول اینکه تیم تمام مدت داره می‌دوه که به عدد مورد نظر برسه در نتیجه ممکنه از کیفیت محصول کم بشه. در نتیجه به زودی شما با یه عالمه بدهی فنی و یه عالمه مشتری ناراضی مواجه می‌شید. دوم اینکه تیم در بلند مدت خسته و دلسرد می‌شه. چون وقتی برای یادگیری و رشد نداره.سوم اینکه دیگه حوصله همدلی هم نداره دیگه و به جای تمرکز روی کار تیمی و توجه به روش‌هایی مثل برنامه‌نویسی دو نفره، مشارکت برای بهبود وضعیت یا کمک به بقیه، تمام تمرکزش رو می‌ذاره روی کارهای فردی و خیلی زود تیم تبدیل به مجموعه‌ای از افراد با اهداف شخصی (نه جمعی) می‌شه.برنامه‌نویسی دونفره (به انگلیسی: Pair programming) روشی برای برنامه‌نویسی در متد برنامه‌سازی مفرط در پارادایم توسعه نرم‌افزاری چابک است. در این روش دو برنامه‌نویس در کنار هم و روی یک ایستگاه کاری کار می‌کنند. در هر لحظه یکی از این دو کدنویسی کرده و دیگری کد او را بررسی و نقد می‌کند و به فراخور نیاز راهنمایی‌اش می‌نماید. این دو به صورت دوره‌ای جای خود را عوض کرده و کسی که راهنمای ای نقاد بوده دست به کدنویسی برده و کد‌نویس مرحله قبل کد او را نقد و بررسی می‌کند.نفر دوم که کار کدنویسی را مشاهده می‌کند، مشاهده‌گر (به انگلیسی observer) یا ناوبر (به انگلیسی navigator) می‌نامند. نفر کناری بررسی و نقد کد به استراتژی کلی برنامه و مشکلاتی که در آینده پیش خواهد آمد نیز می‌اندیشد. به‌طور کلی نفر دوم به تاکتیک‌ها توجه بیشتری دارد تا تکنیک‌ها.این آسیب‌ها در نهایت به کاهش بهره‌وری تیم منجر می‌شه. برای حل این چالش می‌شه از تکنیک «پنج-ده-پانزده» استفاده کرد. به این ترتیب که: ۵ درصد از ظرفیت به افزایش دانش فنی افراد ۱۰ درصد از ظرفیت به رفع باگ و مشکل ۱۵ درصد از ظرفیت به رفع بدهی فنی اسپرینت جاری و اسپرینت‌های قبل اختصاص پیدا کنه. این توزیع باعث می‌شه تیم فرصت و توجه کافی داشته باشه و علاوه بر رضایت تیم، رضایت مشتری رو برای شما به همراه بیاره. سارا رشادی سارا رشادی Tue, 10 Nov 2020 15:57:30 +0330 https://virgool.io/@sara.reshadi/%DA%86%D8%B7%D9%88%D8%B1-%DB%8C%D9%87-%D8%AA%DB%8C%D9%85-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%AE%D9%81%D9%86-%D8%A8%D8%B3%D8%A7%D8%B2%DB%8C%D9%85-%DB%B1%DB%B0-%D9%86%DA%A9%D8%AA%D9%87-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%DB%8C-devwcaervju2 Scrum Teamدر این پست می‌خوام بهتون بگم چطور می‌تونید با کمک ۱۰ نکته کاربردی، یه تیم اسکرام خیلی خفن بسازید.تجربه سال‌ها کار کردن به من یاد داد که یه شروع خوب، باعث می‌شه نصف راه رو راحت طی کنی.این روزها خیلی از تیم‌ها تصمیم می‌گیرن برای پاسخگویی سریع‌تر به تغییرات از اسکرام استفاده کنن، برای همین هم آدم‌ها رو می‌فرستن کلاس اسکرام، بعد هم بلافاصله کنار هم می‌چینن و می‌گن خب شما تیم اسکرام شدید. این یه انتظار غیر منطقیه و واقعا نباید انتظار نتیجه دلچسبی رو داشته باشید.در اسکرام همه چیز درباره تیم‌های خودسازماندهیه که به طور مداوم در حال توسعه محصولی که کار می‌کنه، هستن.نمی‌شه آدم‌ها رو به زور کنار هم گذاشت و گفت دیگه شما یه تیم هستید. در کار تیمی همه چیز درباره همکاری، ایمنی و توجه ب نقاط قوت همدیگه‌س.برای ایجاد یه تیم اسکرام جدید، استفاده از مدل تاکمن (از اینجا می‌تونید با مدل تاکمن بیشتر آشنا شید.) خیلی خوبه. این مدل کمک می‌کنه بفهمید توی تیم چی می‌گذره و برای ادامه به چی نیاز داره. با صبر و حوصله به تیم نگاه کنید ببینید توی کدوم مرحله هستید. بعد از شناسایی مرحله مورد نظر، این ۱۰ نکته می‌تونه به شما در تیم‌سازی کمک کنه:۱ زمانی رو برای استارت کار در نظر بگیرید.استارت کار چیزی نیست که مثلا بگید دو ساعت آخر روز دوشنبه انجامش می‌دیم. این لحظه تاسیس تیمه، حداقل دو تا سه روز واسش زمان بذارید.روز اول رو صرف آموزش اسکرام و بازنگری اصول کنید. درباره چگونگی استفاده بهینه از اسکرام در تیم حرف بزنید.روز دوم رو صرف تیم‌سازی کنید و سعی کنید همدیگه رو بشناسید. در ادامه همین روز یه مانیفست تیمی تدوین کنید. با این کار در واثع نوع بحث و درگیری‌های مرحله طوفان ایجاد می‌شه.روز سوم هم به ایجاد بک لاگ محصول و شروع اسپرینت اول اختصاص بدید.بهتون تضمین می‌دم که همه تیم‌هایی که این بازه زمانی سه روز رو برای شروع در نظر بگیرن، در ادامه مشکلات کمتری رو تجربه می‌کنن و کارشون با سرعت بیشتری پیش می‌ره.۲ شناختن همدیگه، نیمی از کارهمهم‌ نیست که همه با هم غریبه هستن یا یه مدتی با هم کار کردن، به هر حال باید وقت بذارن و در اولین جلسه تیمی همدیگه رو بیشتر بشناسن.مثلا ازشون بخواید خودشون رو در قالب یه کاراکتری که دوست دارن معرفی کنن و از نقاط قوتشون بگن. می‌خوام بهتون بگم باید یخ آدم‌ها رو بشکنی و مجبورشون کنی حرف بزنن. سعی کنید فضا رو گرم و صمیمی کنید و از مشارکتشون ابزاری برای تهدید نسازید تا نتیجه خوبی بگیرید.۳ آموزش اسکرامنباید اینطوری باشه که از کل تیم اسکرام فقط دو نفر درباره اسکرام خونده باشن. می‌شه توی ساعت‌های استراحت در حد ۱۵ دقیقه هر روز درباره‌ش حرف زد. متاسفانه علی‌رغم محبوبیت اسکرام، بیشتر مردم تفسیر یا برداشت غلطی نسبت به اسکرام دارن. (یادم بندازید بعدا یه خاطره درباره این تفسیر غلط واستون تعریف کنم.)Development Teamکلا بهتره شروع کار با آموزش اسکرام باشه که نکات غلط توی ذهنشون موندگار نشه. اگه تیم درباره اینکه اسکرام دقیقا چیکار می‌کنه، اطلاعاتی داره، بذارید بیان کنه و تعامل برقرار شه. بیان اختلاف نظر در نهایت نشون می‌ده که آدم‌ها اهمیت می‌دن و احساس می‌کنن به تیم و هدفش وفادار هستند. تیمی که سکوت کنه و انتقاد یا اختلاف نظری نداشته باشه، نگران کننده‌س.۴ تدوین چشم‌انداز تیمیبه تیم بگید که بدترین تیم ممکن و بهترین تیم ممکن رو تصور کنن. بعد بگید دو نفر دو نفر درباره مواردی که برای تیم اتفاق می‌افته حرف بزنن و نتایج رو بگن. این کار به تیم کمک می‌کنه که درباره رفتارهای مولد و غیر مولد آگاه بشن و چشم اندازی از موانع داشته باشن. در اصل تیم دیدگاهی از معنای یه تیم خوب به دست میاره. در نهایت می‌تونه یه مانیفست تیمی برای خودش تدوین کنه و ببینه به کجا می‌خواد برسه.۵ تدوین قرارداد تیمیبهتره همین اول کار، شفافیت داشته باشید. چطور قراره به صورت تیمی کار کنیم؟ چه کسی مسئول چیه؟ رویدادها کی برگزار می‌شه؟ چه موقع به عنوان تیم خوشحالیم؟ هدف اسپرینت چیه؟ وضوح در نقش‌ها و رویدادها باعث ایجاد نظم می‌شه و در تشکیل تیم موثره. تیم در این مرحله هنوز احساس امنیت نداره و باید دغدغه‌هاش رفع شه. بهتره یه قرارداد تیمی بنویسید و همه چیز رو مشخص کنید.۶ انتخاب نام تیمدر مرحله هنجارسازی، تیم هویت پیدا می‌کنه. این هویت به کمک هنجارها، ارزش و اصول روابط به دست میاد. دوباره آدم‌ها رو به دسته‌های دو نفری تقسیم کنید و ازشون بخواید اسم انتخاب کنن. تجربه نشون داده تیم‌ها به نام خودشون افتخار می‌کنن و این بهشون حس عضویت می‌ده. خیلی از تیم‌ها می‌رن تصاویر مرتبط با نامشون پیدا می‌کنن و سعی می‌کنن بهش بها بدن.۷ تعیین انتظاراتیه تیم اسکرام خوب با یکی دو اسپرینت، شکل اصلی خودش رو پیدا نمی‌کنه. زمان می‌بره تا بفهمید چطور بهترین کار رو انجام بدید اما در هر صورت صرف زمانی قبل از شروع کار باعث می‌شه بعضی چیزها سرعت بگیره. مواظب باشید انگیزه اولیه از بین نره و انتظارات تیم و آدم‌های بیرون از تیم رو مدیریت کنید.چند اسپرینت اول معمولا سخت می‌گذره، اما به مرور تیم شکل خودش رو پیدا می‌کنه که معمولا همین روند سه تا پنج اسپرینت طول می‌کشه.۸ رترو، رترو و رترورویداد رترو، فرصت خوبی برای شکایت از مشکلاته اما مزایاش فقط به همین مورد محدود نمی‌شه. رترو می‌تونه باعث رشد تیم بشه. از ایده‌های جدید استفاده کنید. کلی ایده‌ برای ایجاد تنوع رترو وجود داره که کافیه دنبالشون بگردید.Retrospective۹ درگیر کردن مدیریت برای حمایت از استارت کاریه تیم اسکرام هم در داخل و هم در خارج تیم با پیچیدگی‌های زیادی روبرو می‌شه. باید مدیریت از این روند حمایت کنه و این حمایت رو به صورت عملی نشون بده. یادتون نره که پشتیبانی فقط به حرف نیست، مدیریت باید بدونه اسکرام چیه و چه اتفاقی می‌افته. در غیر اینصورت پیام‌های متناقضی دریافت می‌کنید.۱۰ «خودسازماندهی را به تیم بیاورید.»تیم اسکرام، خود سازمانده است. این جمله خیلی انتزاعی و مبهمه. چنین تیمی می‌تونه مشکلاتش رو به تنهایی درون تیم حل کنه. اینجا نقش اسکرام مستر به عنوان حلال مشکلات نیست، بلکه به تیم کمک می‌کنه تا راه حل مناسب رو پیدا کنن. تا وقتی خودسازماندهی رو به تیم نیارید، تیم نمی‌تونه پاسخ مشکلاتش رو پیدا کنه.نتیجه‌گیری:رویداد استارت کار برای تیم جدید اسکرام، کار کمی نیست. درسته زمان و هزینه صرف می‌شه اما در نهایت می‌تونید در مراحل بعدی سریعتر پیش برید.ترجمه آزاد: https://medium.com/the-liberators/how-to-kickstart-a-great-scrum-team-10-practical-things-to-do-2143bdde1a8d سارا رشادی سارا رشادی Thu, 29 Oct 2020 13:45:54 +0330 https://virgool.io/@sara.reshadi/%DA%A9%D8%A7%D8%B1-%D8%AA%DB%8C%D9%85%DB%8C-%D8%A8%D9%87-%D8%B1%D9%88%D8%B4-%D8%AA%D8%A7%DA%A9%D9%85%D9%86-%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7%DB%8C%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%DB%8C%D9%85-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-jjddc1tkvbgv Tuckman Modelنمی‌شه آدم‌ها رو به زور کنار هم گذاشت و گفت دیگه شما یه تیم هستید. در کار تیمی همه چیز درباره همکاری، ایمنی و توجه ب نقاط قوت همدیگه‌س.مدل تاکمن (Tuckman) کمک می‌کنه که تیم‌ها رو بهتر بشناسید. این مدل در سال ۱۹۶۵ به وسیله روانشناسی به اسم «بروس تاکمن» توسعه یافت و فازهایی رو تعریف می‌کنه که طی اون اکثر تیم‌ها پیشرفت می‌کنن و به تیم واقعی تبدیل می‌شن.تاکمن با مطالعه ۲۶ تیم توسعه کوچیک، تونست یه الگوی پنج مرحله‌ای از مراحل تشکیل تا انحلال یه تیم بسازه:مرحله تشکیلدر این مرحله تیم بیشتر از هرچیزی نگران اینه که چرا اینجا هستن؟ چرا با هم یه جا جمع شدن؟ هدف چیه؟ قراره چیکار کنن؟در این مرحله معمولا آدم‌ها هنوز با همدیگه آشنا نیستن. حس امنیت و آشنایی وجود نداره و انتقادات، تهدیدها و عدم اطمینان‌ها آشکار نیست. در عوض همه ترجیح می‌دن روی وظایفی که ازشون انتظار می‌ره، تمرکز کنن و خودشون رو عضوی از یه تیم نمی‌دونن.اینجا اسکرام مستر می‌تونه به عنوان یه معلم به اعضای تیم آموزش بده و درباره هدف و ساختار تیم واسشون توضیح بده.مرحله طوفانبعد از اینکه احساس آشنایی و امنیت در تیم ایجاد بشه، افراد با یکدیگر راحتتر برخورد می‌کنن و اگه حس تردید یا نگرانی دارن، بروز می‌دن. اینجا اولین درگیری‌ها پدیدار می‌شه. البته بیشتر درگیری‌ها درباره وظایفه نه درباره بقیه اما هرچی میزان آشنایی تیم بیشتر شه، تحریکات جزیی بین افراد هم بیشتر می‌شه.این نتیجه تفاوت بین انتظارات اعضا از خودشون، از همدیگه و تیمه و مرحله مهمی برای پیشرفته. اگه فرصت کافی برای حل سازنده تعارضات فراهم شه، تیم یاد می‌گیره به همدیگه اعتماد کنه. تلاش برای دور زدن این مرحله و نادیده گرفتن درگیری‌ها، بدترین کار ممکنه.اینجا هم اسکرام مستر می‌تونه به عنوان مربی ظاهر شه. البته نباید مشکلات رو حل کنه، بلکه باید به تیم کمک کنه مشکلاتشون رو شناسایی و حل کنن.مرحله هنجار و انسجامبعد از حل تعارضات در مرحله طوفان، تیم وارد مرحله هنجار می‌شه. اینجا دیگه تمرکز روی پیدا کردن نقطه تعادل انتظارات اعضا از همدیگه و تیمه. (مثلا کیفیت، سرعت، دقت و حتی رفتار افراد)به عبارت دیگه در مرحله هنجار، تیم درباره هنجارها، ارزش و قواعدی که باید باشه، با هم به توافق می‌رسن. این مرحله تقریبا شبیه مرحله تشکیله اما با این تفاوت که تیم بیشتر حس وفاداری پیدا کرده و بیشتر به وظایف و قواعد می‌پردازه.در این مرحله اسکرام مستر می‌تونه با کمک چارچوب اسکرام، به تیم کمک کنه تا روش‌های مفید رو پیدا کنن.مرحله بهره‌وریاینجا دیگه تیم به درک مشترکی از اینکه چی مهمه و چی نیست، رسیده. افراد درباره نقش‌های خود انعطاف بیشتری نشون می‌دن و خودسازماندهی بیشتر آشکار می‌شه. ترس از شکست و خطا حل شده و جو کلی حاکم بر تیم، مثبت و سازنده‌س.در این مرحله، اسکرام مستر نقش مشاور رو داره. تیم می‌تونه به تنهایی مشکلاتش رو حل کنه و اسکرام مستر فقط مشاوره می‌ده که کدوم راه بهتره.مرحله توقف یا انحلالدر نهایت همه تیم‌ها از بین می‌رن. ممکنه این انحلال به دلیل این باشه که تیم به هدف خودش رسیده باشه یا به دلایل دیگه از بین بره. این برای تیم‌هایی که طولانی مدت در کنار هم بودن، خیلی دردناکه چون باید از رویدادها برای خداحافظی استفاده کنید.اینجا اسکرام مستر نقش مجری رو داره و به تیم فرصت می‌ده تا احساساتشون رو بیان کنن. سارا رشادی سارا رشادی Mon, 26 Oct 2020 09:43:11 +0330 https://virgool.io/@sara.reshadi/%D9%86%D9%85%D9%88%D8%AF%D8%A7%D8%B1-%D8%A8%D8%B1%D9%86-%D8%AF%D8%A7%D9%88%D9%86-%D8%B4%D9%85%D8%A7-%DA%86%D9%87-%D8%B4%DA%A9%D9%84%DB%8C%D9%87-grefho6hqpid نمودار برن داون (burn down chart) یکی از مهم‌ترین نمودارهای اسکرامه.کاربرد اصلی برن داون، ردیابی روند پیشرفت در پروژه‌های چابکه. به همین دلیل هم مهمه که تفسیرش رو بدونید.burndown chartنمودار برن داون چطور رسم می‌شه؟رسم نمودار برن داون خیلی ساده‌س:· محور X (افقی) تعداد روزهای اسپرینت رو نشون می‌ده.· محور Y(عمودی) استوری پوینت یا ساعت یا روز رو نشون می‌ده. (بسته به اینکه کدوم رو ترجیح می‌دید.)· خط ایده‌آل پیشرفت (که از محور X کشیده می‌شه و Y رو قطع می‌کنه.)· خط واقعی پیشرفتهمونطور که می‌بینید، برن داون جزییات کمی داره. به همین دلیل هم توضیحش آسونه، آپدیت روزانه‌ش آسونه و تحلیلش هم همینطور اما آیا اعضای تیمتون هم واقعا درکش می‌کنن؟ آیا می‌تونن بخوننش؟در این مقاله، از یازده حالت نمودار برن داون، تفسیرش و راه حل اصلاحش با هم حرف می‌زنیم:تیم ایده‌آلideal burn down chartاول بگم که اگه همچین نموداری داشتید، حتما به تیم تبریک بگید.این یعنی:تیم کارش رو عالی انجام می‌ده.کارها در حد معقوله و نیازی به کار بیشتر نیست.تسک‌ها دیرتر یا حتی زودتر از زمان مورد نظر کامل نشده.تیم خیلی سر وقت کار می‌کنه.اسکرام مستر به صورت منظم نمودار رو آپدیت کرده و در دسترس همه گذاشته. (این کار باعث افزایش شفافیت می‌شه.)چیکار کنیم؟ فقط همین مسیر رو ادامه بدید!تیم عالیGreat burn down chartاین نموداریه که در خیلی از تیم‌های چابک باتجربه می‌بینید.این یعنی:تیم متعهد به هدفه.در صورت نیاز، خودشون رو با دامنه تطبیق می‌دن.تیم سرعتش رو برای به اتمام رسوندن کارها بهبود می‌ده.تیم به این پرسش که «چطور باید اسپرینت رو کامل کنیم؟» واکنش نشون می‌ده.چیکار کنیم؟ استوری‌های اضافی رو از اسپرینت بعد به اسپرینت جاری بیارید، تا در زمان باقی مونده انجام شه.تیم خوبnice burn down chartاین سبک نمودار رو توی خیلی از تیم‌های اجایل می‌بینید. این به معنای پایین بودن کیفیت پایین اجایل در تیم نیست. اگه همچنان تیم داره با توجه به اولویت، تسک‌های عقب مونده رو تحویل می‌ده، باز هم عالیه. مواردی که از اسپرینت قبل باقی مونده بهتره در چند رو از اول اسپرینت جدید به سرعت تکمیل شه. هر چند که نتیجه مورد نظر چند روز دیرتر به دست میاد اما در مقایسه با روش آبشاری که همه نتیجه یهو آخر سر به دست میاد، خیلی هم بد نیست. مگه نه؟این یعنی:تیم به هدف اسپرینت متعهده.دامنه تا حد نیاز سازگاره.تیم بلده سرعتش رو برای انجام کارها بهبود بدهتیم به این پرسش که «چطور باید اسپرینت رو کامل کنیم؟» واکنش نشون می‌ده.چیکار کنیم؟وسط اسپرینت یه توقف کنید و در مورد بازگشت به مسیر اصلی حرف بزنید. شاید بشه بعضی از تسک‌ها که اولویت کمتری دارن، از بک‌لاگ اسپرینت خارج کنید یا شاید مالک محصول بتونه نیازمندی‌ها رو ساده کنه تا کار به روش ساده‌تری انجام بشه.بیایید استراحت کنیم!به نمودار نگاه کنید، شاید تیم نیاز استراحت داره.این یعنی:تیم کارهاش رو زودتر از انتظار تموم کرده و می‌تونه بره سراغ کارهای بیشتر.شاید آیتم‌های زیادی توی بک لاگ اسپرینت نیست. آیا چیزی برای توسعه در بک لاگ محصول وجود داره؟ نیست؟ شاید پروداکت اونر باید یه کاری بکنه.تیم بزرگتر از اون چیزی شده که اول اسپرینت بوده یا پیش بینی کردیم؟شاید درست تخمین نزدیم و عدد بالاتری به استوری‌ها اختصاص دادیم! تخمین‌هاتون رو به روز کنید تا از این مورد مطمئن شید و بعدا پیش نیاد.چیکار کنیم؟با در نظر گرفتن اولویت‌ها، هرچه سریعتر استوری از اسپرینت بعدی وارد کنید.اوه اوه! الان مدیریت میاد!تیم کار نمی‌کنه؟ کجا رفتن؟ مطمئن هستید به موقع اسپرینت رو تموم می‌کنن؟این یعنی:احتمالا تیم داره کار می‌کنه، اما شاید یه نفر داره مدام معادل کار انجام شده، به اسپرینت کار اضافه می‌کنه.تیم به طور منظم، خودش رو با زمان باقی مونده به روز نمی‌کنه.اسکرام مستر و تیم به دوره آموزشی نیاز دارن.شاید پوینت‌‌ها رو درست تخمین نزدیم.مالک محصول خیلی حواسش نیست.چیکار کنیم؟اگه سه روز مداوم نمودار خطی بود، توقف کنید و بلافاصله رترو برگزار کنید.رفیق، یه کاری کن!این خیلی بده. شاید تسک رو تموم کردی، اما کاری که تموم شده قابل مشاهده نیست.این یعنی:شرایط نمودار قبلی رو مرور کن.اسپرینت ممکن هنوز برقرار باشه.چیکار کنیم؟دوباره شروع کنید. از اول آموزش بدید، حرف بزنید، رترو رو برگزار کنید تا بفهمید چرا اینطوری شد.تلاش صفر!این یعنی:توی پلنینگ استوری‌ها تخمین زده نشده.هیچ استوری توی بک لاگ نیست.چیکار کنیم؟بلافاصله باید استوری‌ها رو تخمین بزنید و بک لاگ رو آپدیت کنید.بالا، تو آسمون‌ها!اولین اسپرینت زندگیتونه؟ به نظر میاد باشه‌ها. اگه اینجوریه قبول، اما بدونید که این یعنی:استوری‌ها همینجوری داره به بک لاگ اسپرینت اضافه می‌شه.کارهای اضافه شده، بیشتر از کارهای کامل شده است.تسک‌ها دائم داره از اول تخمین زده می‌شه.اگه این روش از اول اصلاح نشه، هرگز نمی‌تونی اسپرینت رو کامل کنی.چیکار کنیم؟بلافاصله باید استوری‌ها رو تخمین بزنید و بک لاگ رو آپدیت کنید.دیگه دیره!این یعنی:تعهداتون رو کامل نکردید و حسابی دیر شده.تسک‌ها کامل نشده.در طول اسپرینت تطبیقی صورت نگرفته.چیکار کنیم؟بررسی کنید ببینید بک لاگ داره رشد می‌کنه؟ در اسرع وقت و قبل از پایان اسپرینت توسعه رو متوقف کنید و استوری‌های با اهمیت پایین رو به بک لاگ یا اسپرینت بعد منتقل کنید.خیلی زوده!این یعنی:خیلی زودتر از انتظار کارهاتون رو کامل کردید.استوری‌ها تخمین اشتباه دارن. (پوینت بیشتری دادید احتمالا)تیم تعهد زیادی نداره.ظرفیت اشتباه حساب شده.استوری‌ها از اسپرینت بعد نمیان و بی‌ربط به هم هستن.بعضی از اعضای تیم تسکی بهشون اساین نشده.چیکار کنیم؟بعد از دو یا سه روز اسکرام مستر باید بپرسه تیم می‌تونه بره سراغ تسک‌های اسپرینت بعد؟ اگه آره بیاره.دست انداز توی جاده هست!قیافه نمودار اینجوریه که انگار اول برن آپ، بعد برن داونه.این یعنی:در شروع اسپرینت تخمین درستی زده نشده.استوری تا اواسط اسپرینت به بک لاگ اسپرینت اضافه شده.تشخیص وضعیت اسپرینت نادرسته.(این خوبه اما دیره)نقشه راه برای اینکه چگونه به صفر برسیم رو فراموش کردیم.چیکار کنیم؟ دوباره رویداد پلنینگ رو برگزار کنید و اسپرینت رو از اول شروع کنید.ترجمه آزاد: https://www.scrumdesk.com/is-it-your-burn-down-chart/ سارا رشادی سارا رشادی Fri, 16 Oct 2020 13:58:09 +0330 https://virgool.io/@sara.reshadi/%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D9%85%D8%B3%D8%AA%D8%B1-%D8%AA%D9%88%DB%8C-%D8%AA%DB%8C%D9%85-%DA%86%DB%8C%DA%A9%D8%A7%D8%B1-%D9%85%DB%8C%DA%A9%D9%86%D9%87-iqmbhnltbjh8 یه سوالی که برای مدیران و بعضی از برنامه‌نویسا مطرحه اینه که اسکرام مستر چیکار می‌کنه؟ تسک‌ها رو که ما می‌زنیم، اون چی می‌گه این وسط؟اسکرام مستر چیکار می‌کنه؟اگه برنامه‌نویس باشید، به احتمال خیلی زیاد با اسکرام و اسکرام مستر آشنایی دارید.شاید هم با این سبک دارید کار می‌کنید، نمی‌دونم.خیلی‌ها با اسکرام آشنایی دارن و نیازی به گفتن اینکه اسکرام چیه، ندارن.اسکرام یه چارچوب برای تفکر چابکه و کمک می‌کنه تیم در مسیر چابک پیش بره. خیلی سطحی می‌شه گفت یه سبک از کنترل پروژه است اما در واقع خیلی متفاوت از کنترل پروژه‌ست و برای تیم‌های کوچیک و چابک به کار می‌ره.به دلیل ماهیت کار تیم‌های برنامه‌نویسی، به ویژه تیم‌های استارت‌آپی و اینکه می‌خوان سریع محصول رو لانچ کنن، اسکرام بیشتر در حوزه برنامه‌نویسی به کار می‌ره.خب این از خود اسکرام به زبان ساده و البته خلاصه.اسکرام مستر چیکار می‌کنه؟ اسکرام که کاری نداره، ما خودمون بلدیم!اسکرام مستر مواظب مسیره. مواظبه تیم در چارچوب اسکرام پیش بره و یهو سوییچ نکنه. با اعضای تیم توسعه و پروداکت اونر در ارتباطه و مدام سعی می‌کنه موانع رو شناسایی و رفع کنه.البته در این مسیر بیشتر کمک می‌کنه فضایی ایجاد بشه که خود اعضای تیم موانع رو بشناسن و رفع کنن.اسکرام مستر کد نمی‌زنه؟ واقعا کهگاهی وقت‌ها اسکرام‌ مستر کد می‌زنه، اما در چارچوب وظایفش کد زدن تعریف نشده. اسکرام انقد کار داره که واقعا زمانی برای کد زدن نمی‌مونه. ضمن اینکه وقتی ذهنت درگیر کد زدن می‌شه چطور می‌خوای مواظب تیم و موانع و راه‌های بهبود باشی؟ از طرف دیگه اسکرام مستر برنامه‌نویس ممکنه توی حس رقابت با تیم بیفته یا در مواردی جانبدارانه برخورد کنه. در این صورت تیم به جای اینکه به اسکرام مستر تکیه و اعتماد کنه، دچار دو دستگی می‌شه.البته بعضی‌ها معتقدن تیم ممکنه سر اسکرام مستر غیر فنی کلاه بذاره که این درست نیست. این یعنی به تیم اعتماد نداری و مطمئن نیستی خودسازمانده هستن.اولین شرط اجرای اسکرام، اعتماد و تیم خودسازمانده‌ است. پس نه، اگه آدم‌ها رو درست انتخاب کنی قرار نیست کسی سر اون یکی کلاه بذاره.اسکرام مستر لازمه؟ ما تک لید داریم، بسه دیگه. تازه کد هم می‌زنه!به همه دلایلی که بالا گفتم، اسکرام مستر علاوه بر اینکه برنامه‌نویس نیست، تک لید هم نیست.تک لید با اون همه مشغله قراره کارهای اسکرام مستر هم انجام بده؟ بعد چابک هم هستید؟ فکر نکنما. شما فقط دارید از یه نفر بیش از حد کار می‌کشید.ضمن اینکه در اسکرام همه تیم توسعه یکسان هستن و سمت تک لید رسمیت نداره.اسکرام مستر یکی کمه، دوتا باهم توی یه تیم باشن بهتر نیست؟واقعا آشپز که دوتا بشه، آش یا شور می‌شه یا بی‌نمک.تیم اسکرام تعریف مشخصی داره: اسکرام مستر (یک نفر)- تیم توسعه (سه تا ۹ نفر)- پروداکت اونر (یک نفر)همه بچه‌های تیم اسکرامحالا اگه قراره اسکرام مستر یه تیم دو نفر باشه، پس باید خواه ناخواه منتظر تعارض‌ها باشی و تفاوت سلیقه‌هایی که احتمالا به جای کمک به پیشرفت، باعث دوگانگی و عقب موندن هدف اسپرینت می‌شه رو بپذیری.اسکرام مستر فقط می‌شینه تو جلساتمون؟ ول کن بابا.توی بحث جلسات و رویدادها، وظیفه اسکرام مستر اطمینان از برپایی رویداد و نگه داشتن باکس زمانیه. مواظب باشه رویداد بیش از حد کش پیدا نکنه. چون این کش اومدنه نشون می‌ده بحث به بیراهه رفته.درصدها پایینه، تقصیر اسکرام مستره!معمولا همیشه یه نفر باید مقصر باشه. پروداکت اونر که نماینده مشتریه و خودش شاکی اصلیه چون باید جواب مشتری رو بده و اگه اسپرینت خوب پیش نره باید بره اونا رو راضی کنه. از اونجایی که برنامه‌نویس‌ها معمولا زود می‌پرن می‌رن جای بعدی، مدیر دلش نمیاد نیروی گرونقیمتش رو برنجونه و از اونجایی که در اسکرام، اسکرام مستر هوای تیم رو داره. هرچه غر دارن بر سر اسکرام مستر می‌زنن.معمولا وقتی اسپرینت خوب پیش نمی‌ره، اسکرام مستر مقصره اما اگه همه چیز عالی پیش بره، برنامه نویس تشویق می‌شه.البته که اسکرام مستر در کنار تیمه که مشکلات رو شناسایی و رفع کنه و تخمین نسبتا درستی از ظرفیت اسپرینت داشته باشه، اما واقعیت اینه که همیشه تیم ۱۰۰ درصد نیست. چون ما در دنیایی آرمانی زندگی نمی‌کنیم و اتفاقات مختلف ممکنه روی تیم اثر بذاره.اسکرام مستر گزارش ریز و آمار برنامه‌نویسا رو به مدیر نمی‌ده؟ به چه دردی می‌خوره؟بحث اصلی توی اسکرام اینه که تیم داریم. قراره کار تیمی انجام بدیم. اگه یه نفر گاهی کمتر کار می‌کنه، بقیه تیم یا پوشش می‌دن یا به تفاهم می‌رسن که کار رو چطور تقسیم کنن.اگه شما مدیر هستید و به تیم اعتماد ندارید یا اینکه به میکرومنیجمت (مدیریت میکروسکوپی یا با ذره بین دنبال آدما افتادن) اعتقاد دارید و می‌خواید هر ثانیه بدونید برنامه‌نویس چیکار می‌کنه؟ دورتون می‌زنه یا نمی‌زنه؟ پس اسکرام به درد شما نمی‌خوره.موثرترین نمودار برای اسکرام، برن داونه که نشون می‌ده تیم همه با هم هر روز چقدر پوینت زدن و چقدر از کار مونده.اسکرام مستر کد نمی‌زنه؟ تست چی؟اسکرام مستر همونطور که برنامه‌نویس نیست، تستر هم نیست. اصلا تستر بودن توی شرح وظایف اسکرام مستر نیست، ضمن اینکه تستر یه پوزیشن شغلی جداست و هر کدوم به اندازه کافی سرشون شلوغه.اسکرام مستر، پروداکت اونر نیست؟ برنامه نویس هم که نیست، نمی‌خوایم بابا اما اسکرام رو می‌خوایم.اسکرام بدون اسکرام مستر می‌شه آش شله قلمکار. چطور می‌خواید مطمئن شید که دارید توی چارچوب پیش می‌رید و چطور قراره انتظار نتیجه مطلوب رو داشته باشید وقتی مطمئن نیستید؟ فقط با یاد گرفتن اسم رویدادها و اجرای هر از گاهیشون؟ شاید این کار یکی دو هفته جواب بده اما قول می‌دم توی بلند مدت دردسر ساز می‌شه. چطور می‌خواید یه استاندارد رو پیاده کنید وقتی فقط اسمش رو شنیدید و نمی‌دونید توی هر شرایطی چه برخوردی باید داشت؟بله اسکرام مستر به عنوان مربی اسکرام باید درباره کار پروداکت اونر بدونه و بلد باشه چی به چیه اما قرار نیست این دو یه نفر باشن.اسکرام مستر و پروداکت اونر دو نقش جدا با ویژگی‌های متفاوت هستند.اسکرام مستر هوای تیم رو داره و مشکلات رو شناسایی می‌کنه اما پروداکت اونر نماینده ذی‌نفع و مشتری در تیمه و قراره صدای اون رو به گوش تیم برسونه.چطور می‌خواید هم مواظب تیم باشید، هم نماینده مشتری؟ با یه دست نمی‌شه دوتا هندونه برداشت دوستم.اسکرام مستر مدیر هم نیست؟ مسخره کردی؟اسکرام مستر باید مدیریت اسکرام رو بلد باشه اما تیمی زیر دستش نداره که مدیرشون باشه. تیم توسعه هویت مستقل داره و اسکرام مستر به عنوان رهبر خدمتگذار یا معنوی در کنار تیمه تا به هدف برسن. پس نه، اسکرام مستر مدیر کسی نیست اما اسکرام رو مدیریت می‌کنه.اسکرام مستر فلان سوال من رو نمی‌دونست! برو بابا من خودم اسکرام مسترم.همیشه آدم جواب همه سوالات رو نمی‌دونه و در شرایط مختلف، اتفاق‌های مختلفی می‌افته. پس طبیعیه که پاسخ همه سوال‌ها رو ندونه اما بخشی از وظیفه اسکرام مستر مطالعه مداوم و همکاری با سایر اسکرام مسترهاست.همه وظایف اسکرام مستر:آموزش و پیاده سازی فرآیند اسکرام و نظارت بر روند آنساماندهی و تسهیل تمام جلسات اسکرامنظارت بر کارایی تیمبهبود خلاقیت و کارایی تیمبهبود فرایند اسکرامحذف موانع تاثیرگذار در کار تیم و روند پروژهآموزش و نظارت بر مالک محصول در جهت انجام درست مسئولیت هاکمک به مالک محصول در جهت ایجاد درست backlog محصولکمک به مالک محصول در جهت اولویت بندی و آماده سازی درست آیتم های backlog محصولکمک به مالک محصول درجهت اطمینان از داشتن یک backlog محصول قابل مدیریتکمک به مالک محصول در تنظیم و تخمین نسخه های محصولکمک به مالک محصول در جهت شناسایی ریسک های پروژهنظارت بر چگونگی انجام فعالیت های مهندسیآموزش و هدایت تیم در راستای self-organize و functional cross شدنشناسایی مشکلات موجود در روند کارها و ارائه راه حلتحلیل اسپرینت و روند کارها در جهت تخمین ظرفیت کاری تیمنظارت بر هماهنگی تیم و کار تیمینظارت بر ارتباطات اعضای تیم و سایر بخش‌ها با تیمتعریف مدت زمان یک اسپرینتهدایت تیم در راستای رعایت تمام زمانبندی های فرآیندکمک به ایجاد و تغییر ساختار تیم با شکل و سایز مناسبحفظ نظم تیم در سازماندر آخراسکرام مستر در واقع نقش مربی و راهنما رو داره و مواظبه یهو سبک کار از اسکرام به یه چیز دیگه سوییچ نکنه و مشکلات بعدی پیش نیاد.منم روز اولی که درباره اسکرام خوندم حس کردم چقدر آسونه، فول شدم اما واقعیت اینه که توی یه تیم چابک هر روز به تعداد تک تک ساعت‌ها چالش پیش‌بینی نشده به وجود میاد.به همین دلیله که بخشی از شغل اسکرام مستری به یادگیری می‌گذره. مدام باید مطالعه کنی و حالات مختلف رو در نظر بگیری.شاید به نظرتون عجیب بیاد، اما در واقع بهتره اسکرام مستر فنی نباشه تا بتونه بدون اینکه درگیر تسک‌های خودش بشه به تیم رسیدگی کنه. رویدادها رو برگزار کنه و مواظب مسیر باشه. سارا رشادی سارا رشادی Sat, 10 Oct 2020 17:36:53 +0330 https://virgool.io/coderlife/%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7%DB%8C-%D8%B3%D8%A7%D8%AF%D9%87-%D9%88-%D9%81%D9%88%D8%B1%DB%8C-%DA%AF%DB%8C%D8%AA-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%A8%D8%AA%D8%AF%DB%8C%D8%A7%D9%86-lekhlelg5ud6 Gitحدودا ۹ ماهه که برنامه‌نویسی رو با دانش صفر و به صورت خودآموز شروع کردم. البته بیشتر به صورت بازی و تفریح انجام می‌دم و هنوز به کار جدی نرسیده. بیشتر واسه دل خودم و اینکه بفهمم بچه‌های برنامه‌نویس شرکت چی می‌گن.این وسط‌ها رفتم گیت هم یاد گرفتم و کدهای تفریحی‌م رو روی ریپازیتوری‌های خودم ذخیره می‌کنم اما یه مشکل جدی و همیشگی واسه من اینه که آموزه‌هام مشمول زمان می‌شه و چون هرچند وقت یه بار می‌رم سراغش، یادم می‌ره فلان دستور ضروری گیت چی بود. واسه همین این بار تصمیم گرفتم هرچی رو که بیشتر لازم دارم، بنویسم تا یادم نره.از اونجایی که اوایل یادگیری گیت، یه روز نشستم کلی گریه کردم که چرا هیچی نمی‌فهمم، می‌خوام بهتون مژده بدم که اصلا سخت نیست. اگه آدم بی‌طاقتی مثل من یاد گرفته، پس شما هم حتما یاد می‌گیرید. چند تا دستور ضروری رو بهتون می‌گم، بقیه رو اساتید یاد دادن و با سرچ می‌تونید پیدا کنید و خیلی خفن شید.گیت چیه؟گیت یه مخزنه. اصلا فرض کنید یه کتابخونه‌س. شما یه عالمه کتاب دارید که روی هم چیدید یه گوشه و هربار می‌خواید یکی رو بردارید، باید همه رو بهم بریزید. بعد می‌رید کتابخونه می‌خرید و براساس نیاز و دسته‌بندی، کتاب‌ها رو می‌چینید. از این به بعد هر کاری بخواید انجام بدید، راحت می‌رید و کتاب رو می‌کشید بیرون.گیت واستون این کار رو می‌کنه. هرچیزی رو بهش بسپاری مرتب یه گوشه می‌ذاره تا صداش کنی. خوبیش اینه که هم روی سیستم قابل دسترسیه و هم می‌تونید به سایت گیتهاب یا گیت‌لب وصل شید و اونجا بایگانیشون کنید.نصباول از همه برید از اینجا ابزار گیت رو براساس سیستم عاملتون دانلود کنید. تا گیت نصب شه، اینو بهتون بگم که وقتی یه پروژه جدید می‌خواید شروع کنید، یه فولدر در هر جایی از سیستم عاملتون بسازید و واردش بشید. بعد که گیت نصب شد، با کمک کلیک راست، ترمینال گیت رو فراخوانی کنید.دستور Git initاین اولین دستور بعد از فراخوانی ترمینال گیته و برای شما یه مخزن توی همون پوشه می‌سازه. از این به بعد همه دستوراتی که می‌دید توی اون مخزن اجرا و همه کدها اونجا ذخیره می‌شه.Git initاگه دقت کنید، بعد از اجرای این دستور آخر خط فرمان کلمه masterرو می‌بینید. این یعنی یه برنچ اصلی به اسم مستر برای شما ساخته شده.نکته: حواستون باشه که برنچ مستر رو تمیز نگه دارید. هر کاری خواستید انجام بدید، یه برنچ دیگه بسازید و هر وقت مطمئن شدید کد تمیزه و کار می‌کنه، روی مستر انتقالش بدید. پیشنهاد می‌کنم برنچ development بسازید و تغییرات رو از زیر شاخه اون دنبال کنید. در نهایت ببرید روی مستر.این شکلی:Branchدستور Git statusاز این خیلی استفاده کنید. به کمک این دستور می‌فهمید که الان وضعیت چطوره. وقتی همه‌چیز درست ذخیره و کامیت شده باشه، بهتون همچین پیامی می‌ده:Git statusدستور Git add -Aبعد از اینکه کدتون رو نوشتید، وقتشه که به گیت بگید «این فایل رو دنبال و هر وقت گفتم ذخیره کن». قبل از این کار، اگه Git statusرو بزنید، به شما پیام می‌ده می‌گه چی فالو نشده (با رنگ قرمز) یا چی فالو شده (با رنگ سبز).بعد Git add –A رو بزنید، اینجوری هر چی که ذخیره نشده، ذخیره می‌شه. البته می‌تونید یکی یکی با Git add filename ادد کنید، اما من حال ندارم. :Dاتفاقی که می‌افته اینه که گیت می‌دونه باید این فایل یا فایل‌ها رو دنبال کنه و هر وقت گفتید ذخیره کنه. یادتون نره بعد از هر تغییر، فایل رو addکنید که یهو همه چیز از دست نره.Git add -Aدستور Git commitبعد از ادد، نوبت کامیته. با کامیت کردن، تغییرات روی برنچی که هستید، ذخیره می‌شن. برای کامیت کردن حتما باید یه پیام بذارید که مثلا داستان این ذخیره چیه. فایل جدید اضافه کردی، تغییر خاصی داره یا چی؟ اینجوری:Git commitدستور Git branchگیت برنچ به شما نشون می‌ده چه برنچ‌هایی دارید و با رنگ سبز و ستاره نشون می‌ده روی کدوم برنچ هستید، البته بغل خط فرمان هم نگاه کنید، متوجه می‌شید کجایید.Git branchدستور git checkout -b nameاین دستور به شما کمک می‌کنه همزمان یه برنچ بسازید و روی اون سوییچ کنید.git checkout -b nameدستور Git checkout branchnameکمک می‌کنه روی برنچ‌ها جابجا شید.Git checkout branchnameدستور git branch –d nameحالا ممکنه یه برنچ رو اشتباهی ساخته باشید و بخواید حذف کنید. اول باید چک‌اوت رو بزنید و برید روی یه برنچ دیگه و بعد برنچ مورد نظر رو حذف کنید.git branch –d nameدستور Git merge branchnameوقت اون رسیده دو تا برنچ رو یکی کنید. مثلا تغییرات استایل‌ها تموم شده و می‌خواید به برنچ مستر انتقالش بدید. اول برید روی برنچ مقصد و بعد اسم برنچی که اطلاعات روش قرار داره رو با این دستور صدا بزنید.Git merge branchnameدستور git logتاریخچه کارهاتون رو بهتون نشون می‌ده.git logدستور Git helpاگه دستورا یادتون بره از این کمک بگیرید.Git helpپیش به سوی گیتهاب یا گیت‌لبخب حالا احتمالا می‌خواید کم کم همه چیز رو ببرید روی ریپازیتوری گیتهاب یا گیت‌لب، درسته؟دستور git pushبرای اینکه بتونید فایل‌ها رو روی گیت‌هاب یا گیت‌لب بفرستید، باید به اصطلاح اون‌ها رو پوش کنید. کاراتون رو روی گیت بفرستید به اصلاح پوش کنید به یه ریپازیتوری خاص. مثلا برنچ مستر. برای این کار اول باید با کمک دستور git config به اکانتی که توی سایت ساختید وصل شید. بعد با کمک git push ، اطلاعات رو به ریپازیتوری منتقل کنید.دستور git pullبا کمک این دستور دریافت آخرین تغییرات مخزن آنلاین رو می‌تونید روی سیستمون دریافت کنید.سخن پایانیدستورات گیت به اینجا ختم نمی‌شه. من سعی کردم دستورات پرکاربرد ابتدایی رو بهتون بگم که کارتون راه بیفته. توی اینترنت هزاران راهنما برای گیت هست، امیدوارم به سهم خودم تونسته باشم با این پست به شما کمک کرده باشم که بتونید کارتون رو راه بندازید. اون آخراش هم خیلی حال نداشتم توضیح بدم. ایشالا چند روز دیگه میام درباره git push و git pull بیشتر می‌گم. سارا رشادی سارا رشادی Fri, 02 Oct 2020 20:25:21 +0330 https://virgool.io/@sara.reshadi/%D8%AF%D9%88%D8%B1%DA%A9%D8%A7%D8%B1%DB%8C%D9%87%D8%A7%DB%8C-%D8%A7%D8%AF%D8%A7%D9%85%D9%87%D8%AF%D8%A7%D8%B1-eixsu3nqbohg شما هنوز دورکار هستید یا برگشتید شرکت؟اوایلی که کرونا اومده بود یکی از نگران کننده‌ترین موضوعات این بود که نکنه با دورکاری راندمان بیاد پایین.این موضوع نه فقط واسه ما، فکر کنم واسه حداقل ۸۰ درصد شرکت‌های جهان دغدغه بود اما خب کاری نمی‌شد کرد و از اونجایی که «احتیاج مادر اختراعه» هر کی یا راهی یافت، یا راهی ساخت.ما هم تصمیم گرفتیم تیم اسکرام رو دورکار کنیم.البته که افت و خیز هم داشتیم و چون هیچ‌‌وقت فکر نمی‌کردیم روزی برسه که یه ویروس همه رو ماه‌ها خونه‌نشین کنه (البته تو فیلمای تخیلی دیده بودیم)، به آزمون و خطا رو آوردیم.سعی کردیم رویدادهای اسکرام رو تا جای ممکن آنلاین کنیم، برای مواردی که نیاز به بحث فنی بود، بچه‌ها تک و توک هر چند هفته یه بار توی شرکت جمع می‌شدن حرف می‌زدن و کارهایی از این قبیل.از اون طرف یه مزیتی که داشت این بود که هم سالم موندیم و ریسک بیماری یا انتقالش کم شد و هم اینکه بچه‌ها آزادی عمل پیدا کردن که چقدر و چطور کار کنن.به‌نظرم فرصت خوبی شد که مفهوم سلف ارگانایز با مدیریت زمان و حجم کار خودش رو نشون بده.شما چی؟ هنوز دورکار هستید یا برگشتید شرکت؟اگه به صورت ریموت با تیم همکاری می‌کنید یا می‌کردید، چه چیزهای جدیدی رو تجربه کردید؟ سارا رشادی سارا رشادی Wed, 02 Sep 2020 11:39:39 +0430 https://virgool.io/@sara.reshadi/%D8%BA%D9%88%D9%84%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-%D9%85%D8%B4%D9%87%D9%88%D8%B1-%D8%A7%D8%B2-%DA%A9%D8%AF%D8%A7%D9%85-%D8%B1%D9%88%D8%B4-%DA%A9%D9%86%D8%AA%D8%B1%D9%84-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D9%85%DB%8C%DA%A9%D9%86%D9%86%D8%AF-eybbshiy9p9y شاید وقتی نام کنترل پروژه به میان می‌آید، با خود فکر کنید که فقط یک راه برای این کار وجود دارد. (همان شیوه قدیمی دنبال کردن لحظه به لحظه کارها از لحظه اول تا آخر.)اما خوشبختانه این روزها دنیای کنترل پروژه تفاوت‌های زیادی کرده و متناسب با نوع پروژه و خواسته‌های کارفرما و مجری از خودش انعطاف نشان می‌دهد.اگر به دنبال راهی برای کنترل پروژه‌های نرم افزاری هستید، باید بگوییم این روزها دو شیوه اصلی برای این کار وجود دارد:واترفال (روش آبشاری)اجایلمن در این مقاله به‌صورت خلاصه به ویژگی‌های هر کدام اشاره می‌کنم.واترفالواترفال رایج‌ترین و در واقع سنتی‌ترین روش کنترل پروژه‌های نرم افزاری است.نام دیگر واترفال، آبشاری است و در آن مایلستون‌های یک پروژه پس از تکمیل مثل آبشار باعث ایجاد مایلستون‌های بعدی می‌شوند.این شیوه، کار مدیران را برای تصمیم‌گیری درباره ادامه پروژه و بودجه‌بندی راحت می‌کند اما مشکلات زیادی هم دارد.اول اینکه به دلیل اینکه کارها پشت سر هم و براساس توالی خاص انجام می‌شود، نمی‌توان پروژه را به اصطلاح خرد کرد و به ناچار باید زمان زیادی صرف انجام یک پروژه کرد. این شیوه به ویژه در پروژه‌های بزرگ دردسرساز است.دوم اینکه تیم‌های مختلف در حوزه‌هایی جداگانه کار می‌کنند و با هم هماهنگ نمی‌شوند. هر مشکل کوچکی در هر تیمی ممکن است کار کل پروژه را تعویق بیندازد.سوم اینکه به دلیل زمانبر بودن پروژه‌های واترفال، فهمیدن نیازهای مشتری و رفع آن سخت است.چهارم اینکه باید به سختی راهی برای بررسی و سنجش وضعیت پیدا کرد.و در آخر توسعه محصولاتی که با سبک واترفال ساخته می‌شود سخت است. چون احتمالا مجبور می‌شوید دوباره همان مسیر را طی کنید.با این حال شرکت‌ مایکروسافت در تولید محصول ناموفق آفیس ویزاکت Microsoft Office VizAct از آن استفاده کرده و البته که شکست خورده!به‌طور کلی این روش به ویژه در دنیای نرم افزار تقریبا منسوخ شده است.اجایلاجایل پرطرفدارترین شیوه کنترل پروژه‌های نرم افزاری است. اجایل یا چابک ۱۲ اصل دارد و معتقد است بیشتر از هرچیز باید به دنبال رضایت مشتری باشیم و این کار را باید از طریق ارتباط مداوم و به‌روز رسانی محصول انجام داد.در اجایل پروژه به بخش‌های خرد تقسیم می‌شود و یک یا چند تیم کوچک به‌صورت موازی به تولید و توسعه محصول می‌پردازند. در تمام مراحل تیم با مشتری ارتباط مستقیم دارد، پس در نتیجه محصول سریع‌تر و مطابق سلیقه مشتری ساخته می‌شود.البته اجایل هم مشکلات مخصوص به خود را دارد. مثلا اینکه همه اعضای تیم باید به کار تیمی معتقد باشند و با بقیه هماهنگ شوند.اجایل، متدهای شیوه‌های مختلفی دارد از جمله:- اسکرام (Scrum)اسکرام در میان توسعه‌دهندگان، محبوبترین، پرکاربردترین و البته رایج‌ترین متد به شمار می‌آید.اسکرام شامل رویدادهای اختصاصی مختلفی از جمله استندآپ روزانه، پلنینگ، دمو و رترو است.یک تیم اسکرام بین سه تا ۹ نفر است. چرخه اسکرام یک بازه زمانی یک تا چهار هفته‌ای است که اسپرینت نامیده می‌شود. (معمولا همه تیم‌ها دو هفته‌ای آن را برگزار می‌کنند.)کوتاه بودن زمان هر اسپرینت باعث می‌شود، مشتری زودتر به نتیجه مطلوب برسد. با این حال اسکرام نیز نقاط ضعف مخصوص خود را دارد و در صورت اجرای نادرست ممکن است شما را با در بسته مواجه کند.لگو، اسپاتیفای، یاهو، جنرال الکتریک، مایکروسافت، ادوب، نوکیا، زیمنس و گوگل از جمله شرکت‌هایی هستند که از اسکرام استفاده می‌کنند.- کانبان (Kanban)در کانبان تمام جریان تولید از لحظه اول تا آخر روی تخته دنبال می‌شود. هرچند که اینجا محدودیتی برای تعداد اعضای تیم وجود ندارد اما محدودیت ظرفیت تولید وجود دارد و اعضای تیم باید به یکدیگر کمک کنند تا یک محصول به انتها برسد و سپس به سراغ کار جدید بروند.این روش ابتدا در کارخانه تویوتای ژاپن مورد استفاده قرار گرفت.- برنامه نویسی اکستریم (XP)این روش بر اصولی مانند ارتباطات، سادگی، بازخورد، شجاعت و احترام تاکید دارد و برای توسعه دهندگانی مناسب است که حتی در مراحل پایانی توسعه نیز هرگونه تغییر در نیاز و سفارش مشتری را می‌پذیرند. در این شیوه برخی از مشکلات یا تغییرات مستند نمی‌شود و همین موضوع می‌تواند دردسرساز شود.- توسعه ناب (Lean Development)روش تولید ناب یا لین نیز ابتدا در شرکت تویوتا اجرا شد. در این شیوه تمام فعالیت‌های اضافی حذف و تمرکز کامل بر کدنویسی است به همین دلیل به شدت به مستندات وابسته است. این روش نیز برای تیم‌هایی با تعداد زیاد اعضا مناسب است.- کریستالاین روش برای انواع تیم‌های کوچک یک تا هشت نفره، تیم‌های متوسط ۱۰ تا ۲۰ نفره و تیم‌های بزرگ ۵۰ تا ۱۰۰۰ نفره است. در این شیوه در هر مرحله مشکلات بررسی و محصول به روز رسانی می‌شود. تعامل اعضای تیم بسیار بالاست اما از طرف دیگر به دلیل قابل کنترل نبودن اعضای تیم، مدیریت پروژه دشوار است.منابع:https://pm.stackexchange.com/questions/2115/famous-projects-using-scrumhttps://www.cprime.com/resources/what-is-agile-what-is-scrum/https://www.seguetech.com/waterfall-vs-agile-methodology/https://www.simplilearn.com/waterfall-vs-agile-vs-devops-article?source=frs_left_nav_clicked سارا رشادی سارا رشادی Sun, 09 Aug 2020 18:20:52 +0430