https://virgool.io/feed/@kasratoofani یه کدنویس که توی دهه سوم زندگیش علاقه زیادی به اسکرام و اسکرام دولوپری داره. کنار کدنویسی واقعا یادداشت نویسی دلچسبه. fa 2026-06-07 09:56:16 https://files.virgool.io/upload/users/231011/avatar/azjjXv.png?height=120&width=120 https://virgool.io/@kasratoofani https://virgool.io/@kasratoofani/10-%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B1%D9%87%D8%A7%DB%8C%DB%8C-%D8%A7%D8%B2-%D8%B2%D8%A7%D9%85%D8%A8%DB%8C-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-l99gqviw8muz در دسامبر 2020 ، من (بَری اُوِریم)، یوهانس شرارتو و کریستیان ورویز، “راهنمای نجات از زامبی اسکرام” را منتشر کردیم. ما آن را نوشتیم تا به خوانندگان کمک کند که بفهمند چرا اسکرام اغلب به زامبی اسکرام تبدیل می شود و بتوانیم راهنمایی عملی و واقعی را ارائه دهیم. زامبی اسکرام چیزی نیست که با یک آزمایش ساده آن را برطرف کنید. هرچه در سازمان شما عمیق تر وجود داشته باشد، تلاش بیشتری برای رهایی از آن لازم است. بنابراین حدود 6 ماه پس از انتشار کتاب، ما می خواستیم بررسی کنیم که جامعه ما با عملی کردن آزمایش هایی که در کتاب خود شرح می دهیم چه پیشرفتی دارد. دلایل موفقیت آنها در مبارزه با زامبی اسکرام چیست؟ چه اتفاقی افتاده است؟ ظاهر زامبی اسکرام چگونه بود و چگونه توانستند اوضاع را بهبود ببخشند؟برای یافتن پاسخ این سؤالات، ما یک جلسه عمومی در The Liberators Network ترتیب دادیم. به همراه 40 شرکت کننده، ما از Liberating Structure متد “طراحی با هم” (Drawing Together) برای تجسم مسیر هر شخص در پیاده سازی اسکرام و متد “مصاحبه های قدرشناسی” (Appreciative Interviews) برای شناسایی و به اشتراک گذاری داستان های موفقیت استفاده کردیم. در این نوشته، ما 10 عامل موفقیت را که بیشتر از همه برجسته بودند به اشتراک می گذاریم. عواملی که به جامعه ما کمک کرد تا از اسکرام به طور مؤثرتری در تیم و سازمان خود استفاده کنند. اگرچه این ایده ها چندان حیرت انگیز و جادویی نیست، اما چیزی است که به تمرین کنندگان “واقعی” اسکرام در برطرف کردن زامبی اسکرام کمک کرد. شما نیز می توانید از آن به عنوان الهام دهنده ای برای بهبود اسکرام در سازمان خود استفاده کنید!در اینجا 10 عامل موفقیت را که از جلسه ما به دست آمده است، مشاهده می کنید. این ها 10 عامل نهایی برای مبارزه با زامبی اسکرام نیستند، زیرا هر تیم و سازمان متفاوت است و به رویکردی اختصاصی نیاز دارد. با این حال این عوامل الگوهای روشنی در داستان هایی بودند که 40 شرکت کننده به اشتراک گذاشتند، بنابراین باید حقیقتی در آن وجود داشته باشد.1. رویدادهای اسکرام را هدفمند کنیدهدف اسپرینت و هدف محصول (Sprint Goal – Product Goal) جزو قوی ترین بخش های چارچوب اسکرام هستند. آنها با هم به کار تیم اسکرام معنا می دهند و یک هدف واحد برای همکاری و تمرکز بر روی آنها ارائه می دهند. اگر تیمی با بکار گرفتن یک هدف اسپرینت یا هدف محصول درگیری داشته باشد، اغلب نشانه یک مشکل عمیق تر است. به عنوان مثال آنها روی محصولات مختلف و زیادی کار می کنند، واقعاً cross-functional نیستند یا مالک محصول ندارند که جهت مشخصی را ارائه دهد.بسیاری از اعضای جامعه هدف ما به سمت اسکرام مؤثرتر حرکت کردند تا تمرکز اصلی شان را بر تعیین اهداف بگذارند. به خصوص در طول رویدادهای اسکرام. در طول برنامه ریزی اسپرینت، آنها هدف اسپرینت را تعیین کردند. در مراحل ابتدایی این کار سختی بود و آنها با چندین هدف، جلسه را به پایان رساندند، اما به مرور توانستند آن را به یک هدف برای کل تیم تبدیل کنند. با داشتن یک هدف اسپرینت، جلسه اسکرام روزانه (Daily Scrum) نیز تمرکز بیشتری داشت. به جای به اشتراک گذاشتن تمام کارهایی که همه انجام داده اند، آنها فقط پیشرفتی را که برای رسیدن به هدف انجام داده اند به اشتراک گذاشتند. در طول جلسه بررسی اسپرینت (Sprint Review)، همه فرآورده بهبود یافته (improved increment) را بررسی کردند. در مورد پیشرفت به سوی هدف محصول بحث کردند و ایده هایی را در مورد هدف اسپرینت بعدی به اشتراک گذاشتند. برای خیلی از نفرات، این تغییر رویه آسان نبود اما رویدادهای اسکرام هدفمند، در دور شدن از زامبی اسکرام، کلیدی و حیاتی بود.2. سعی کنید ایمنی روانی را افزایش دهیدایمنی روانی یکی از مهمترین عوامل در تیم های موفق است. ایمی ادموندسون ایمنی روانی را “یک باور مشترک در مورد عواقب ریسک پذیری هر فرد” تعریف می کند. با گفتگوها و مناظرات سخت و جدی مغایرتی ندارد، اتفاقاً این چیزی است که به تیم ها اجازه می دهد مکالمات بی پرده و شفافی داشته باشند. ایمنی روانی به این معنا نیست که همیشه با یکدیگر توافق داشته باشید یا مدام تعریف و تمجید کنید. این بیشتر به تشویق مردم برای ابراز وجود در هنگام نگرانی، عدم اطمینان یا تردید است.در طول جلسه، شخصی داستانی درباره نحوه استفاده از Liberating Structure متد “شنیده شده، دیده شده، محترم شمرده شده” (Heard, Seen, Respected) برای افزایش ایمنی روانی به اشتراک گذاشت. این ساختار رهایی بخش تماماً در مورد ایجاد همدلی و شفقت است. این کار با دعوت از شرکت کنندگان برای به اشتراک گذاشتن داستانی از زمانی که احساس می کردند شنیده نشده، دیده نشده یا مورد احترام نبوده اند، انجام می شود. همچنین دعوت از همه برای فعالانه گوش دادن به داستان نفرات دیگر هم هست. افرادی که در “شنیده شده، دیده شده ، محترم شمرده شده” شرکت می کنند اغلب در مورد قدرت سکوت فکر می کنند و در عین حال اذعان می کنند که صرفاً “گوش دادن” تا چه اندازه دشوار است. تیم هایی که محیطی را ایجاد می کنند که در آن همه شنیده می شوند، دیده می شوند و مورد احترام قرار می گیرند، اغلب زمینه ساز ریشه دواندن و رشد زامبی اسکرام نمی شوند.از متد “شنیده شده، دیده شده ، محترم شمرده شده”برای افزایش ایمنی روانی استفاده کنید.3. اسکرام را برای کانبان کنار بگذارید یا از اسکرام همراه با کانبان استفاده کنیداسکرام چارچوبی برای توسعه و نگهداری محصولات پیچیده است. این به تیم ها کمک می کند تا ریسک را مدیریت کرده و ارزش را سریعتر به ذینفعان خود ارائه دهند. این چارچوب پنج رویداد تکراری را برای کار بر روی سه مصنوع (artifact)، سه مسئولیت (accountability) برای حمایت از آن و به علاوه چندین اصل و قانون برای اتصال اینها به یک کلِ منسجم ارائه می دهد. از آنجا که این یک چارچوب است می توانید از آن به عنوان “قاب” برای “کار” بر روی طیف گسترده ای از مشکلات، پروژه ها و محصولات پیچیده استفاده کنید.اما همچنان همه تیم ها ریتم اسپرینت ها را دوست ندارند. برای برخی از تیم ها تمرکز بر “جریان” (flow) منطقی تر است و به عنوان مثال از کانبان استفاده می شود. راهنمای کانبان، کانبان را اینگونه توصیف می کند: “یک استراتژی برای بهینه سازی جریان ارزش از طریق فرآیندی که از یک سیستم کشش محدود و قابل رؤیت و همینطور در حال پیشرفت استفاده می کند”. سایر تیم ها فهمیدند که استفاده از اسکرام مطابق راهنمای اسکرام و تکمیل آن با شیوه های کانبان برای آنها به شکل خیلی خوبی کار می کند. هر روشی که انتخاب کرده اید، اگر با زامبی اسکرام درگیر شده اید ممکن است به این دلیل باشد که اسکرام برای شما مناسب نیست. آزمایش را شروع کنید و ببینید چه چارچوب، روش یا فرآیندی به شما در مدیریت ریسک و ارائه ارزش کمک می کند.4. رویدادهای اسکرام جذاب تری ایجاد کنیدهنگام توضیح رویدادهای اسکرام، من همیشه بر واژه “رویداد” تأکید می کنم. چارچوب اسکرام شامل 4 جلسه خسته کننده نیست (به علاوه خوده اسپرینت به عنوان پنجمین رویداد به عنوان دربرگیرنده مابقی رویدادها)، بلکه 4 رویداد پر جنب و جوش را به شما ارائه می دهد. تیم باید از آنها به عنوان لحظاتی برای انجام کار واقعی، با هم استفاده کنند! رویدادهایی که به ایجاد برنامه ای برای اسپرینت آینده (Sprint Planning)، بازرسی پیشرفت به سوی هدف (Daily Scrum) ، شناسایی پیشرفت ها (Sprint Retrospective) و جمع آوری بازخورد از ذینفعان (Sprint Review) کمک می کند.برای بسیاری از اعضای جامعه مورد آزمایش ما، رویدادهای اسکرام به جلساتی تبدیل شد که در آن همه نفرات زامبی می شدند و به صورت مکانیکی و بی روح رفتار می کردند. جلساتی که افراد سعی می کردند از آن صرف نظر کنند یا لغو کنند زیرا اتلاف وقت بود. برای ایجاد رویدادهای جذاب تر اسکرام، 33 ساختار رهایی بخش (Liberating Structures) یک منبع الهام بخش ارزشمند بود. آنها به چاشنی دار کردن رویدادها و مشارکت مجدد همه کمک کردند. به اشتراک گذاری همه نمونه ها از حوصله این نوشته فراتر می رود. این سری مقالات را در مورد نحوه ترکیب اسکرام با Liberating Structures بررسی کنید.5. اسکرام را به انتخاب خود تیم ها بگذاریدبه عنوان یک تیم، اساساً دو راه برای شروع کار با اسکرام وجود دارد. اول: کسی از خارج از تیم آنها را تشویق (یا مجبور کند) اسکرام را امتحان کنند. دوم: خوده تیم تصمیم بگیرد اسکرام را امتحان کند. هر دو رویکرد می تواند کارایی داشته باشد. اگرچه من معتقد به اعمال روش کار بر روی تیم نیستم، اما اگر مدیریت، تیم را تشویق می کند تا اسکرام را امتحان کند این می تواند مزایایی داشته باشد. یکی از مزایای کلیدی این است که احتمالاً عدم پشتیبانی مدیریت پیش نمی آید و مشکل ساز نمی شود. اگر استفاده از اسکرام به پیشنهاد آنها باشد، به احتمال زیاد آنها به طور فعال تری به رفع موانع تیم کمک خواهند کرد.تیم های بزرگ اسکرامی از اسکرام به عنوان یک آینه برای خودبینی استفاده می کنند.با این حال، یک الگویی که از داستان های اعضای جامعه مورد بررسی ما بروز کرد، این است که موفق ترین تیم ها برای انتخاب چارچوبی که ترجیح می دهند، آزادی دارند. یا آن را به گونه ای تغییر می دهند که بیشتر مناسب آنها باشد. با این حال، انگیزه تغییر نحوه استفاده از چارچوب اسکرام می تواند ریشه در اختلالات سازمانی داشته باشد. در بهترین تیم ها، نفرات یکدیگر و همچنین محیط خود را به چالش کشیدند و از اسکرام به عنوان یک آینه استفاده کردند. نیاز به سازگاری با چارچوب به عنوان یک لحظه مهم برای خوداندیشی (self-reflection) مورد استفاده قرار گرفت. اما هر آنچه که آنها تصمیم گرفته باشند، به این دلیل که تیم، مالکیت خود را به دست آورده، می تواند برای آنها آزادی عمل را به منظور ایجاد هر گونه تغییر و تنظیمات لازم فراهم کند.6. ایجاد یک فضای امن برای تجربه کردناسکرام در محیط هایی با پیچیدگی بالا رشد می کند. هرچه مشكل سازمان پیچیده تر باشد، استفاده از رویکرد تجربی اهمیت بیشتری دارد. به دلیل ماهیت پیچیدگی، نتیجه چیزی است که نمی توانید پیش بینی کنید. به عنوان مثال، هنگام توسعه یک محصول نرم افزاری، نمی توان از قبل پیش بینی کرد که چه ویژگی هایی بیشتر مورد توجه قرار می گیرند و چقدر زمان می برد تا آنها را ایجاد کنیم.به عنوان یک تیم اسکرام، بسیاری از فرضیات دیگر را نیز به کار خواهید گرفت. مفروضات در مورد ویژگی های محصول، برنامه ریزی، بودجه، زمان، همکاری، خطرات، وابستگی ها، مهارت ها، پویایی تیم و غیره. تنها راه تأیید همه این مفروضات انجام آزمایشات کوچک است. در سازمان هایی که درجه بالایی از زامبی اسکرام دارند، تجربه و آزمودن تشویق نمی شود. ما روایت هایی را شنیده ایم که سازمان ها نمی خواهند آزمایش زیادی انجام دهند زیرا تصور می کردند نتیجه ناشناخته است … سایر سازمان ها عوامل ناشناخته را تصدیق کرده و از اسکرام به عنوان اهرمی برای کشف پاسخ ها استفاده کردند. آنها محیطی را ایجاد کردند که انجام آزمایشات کوچک تشویق می شد. آنها درک کردند که این واقعاً به آنها در مدیریت ریسک کمک کرده است!7. بازگشت به Scrum Guideچارچوب اسکرام عمداً ناقص است. همانطور که در راهنمای اسکرام توضیح داده شده است، تیم ها می توانند از فرآیندها، تکنیک ها و روش های مختلف در چارچوب استفاده کنند. ما همیشه تیم ها را تشویق می کنیم تا آزمایشاتی را در این سطح نیز امتحان کنند. با این حال، آزمایش با تغییر عناصر اساسی چارچوب اسکرام دشوار است. به عنوان مثال، فقط دو بار در هفته Daily Scrum را انجام دهید، از Sprint Retrospective رد شوید یا از Sprint Goal استفاده نکنید. اگرچه من حتی تیم ها را تشویق می کنم که این رفتارها را امتحان کنند، اما همیشه تأکید می کنم که این دیگر اسکرام نیست. اسکرام فقط به طور کامل نمایانگر می شود.برخی از تیم ها آنقدر این موارد را امتحان کرده اند که در نتیجه فریم ورک اسکرام دیگر به سختی قابل تشخیص است. شاید به یک روش کار عالی منجر شود. احتمال این هم وجود دارد که اینطور پیش نرود. در این مواقع خوب است که دوباره Scrum Guide را بررسی کنید. نه برای اجرای مجدد کورکورانه اسکرام طبق راهنما، بلکه بیشتر برای شروع گفتگو در مورد اینکه چرا تیم تغییراتی در چارچوب ایجاد کرده است. چه چیزی مفید بود؟ چه ایده ای خوب نبود؟ چه تغییراتی را باید در نظر بگیریم؟ اگر این مکالمه را با تیم اسکرام تسهیل می کنید، مطمئن شوید که موعظه گر اسکرام نمی شوید!8. شجاعت مواجه شدن با موانع مداوم را داشته باشیدیک الگوی واضح که در جامعه ما نشان داده شد این است که بسیاری از تیم هایی که با زامبی اسکرام مبارزه می کنند، هیچ ارزشی به عنوان خروجی از جلسه بازنگری اسپرینت ندارند. این تیم ها عمدتاً بر ایجاد جلسه بازنگری سرگرم کننده، شاد و انرژی بخش متمرکز شده اند و از بسیاری بازی ها و تکنیک های تسهیل استفاده می کنند. این چیزی است که ما آن را اسکرام سرخوشانه (Happy-Clappy-Scrum) می نامیم. ممکن است برای مدتی سرگرم کننده باشد، اما به سرعت باعث ناامیدی تیم ها می شود زیرا مشکلات واقعی نادیده گرفته می شوند.استفاده مؤثر از اسکرام آسان نیست. تیم ها باید بر بسیاری از موانع سخت، چالش برانگیز و مداوم غلبه کنند که اغلب به نظر می رسد فراتر از محدوده تأثیر آنها نیست. اگر حل موانع دشوار باشد، تمرکز تنها بر پیشرفت های آسان وسوسه انگیز است. تیم هایی که از زامبی اسکرام فاصله گرفتند شجاعت مواجه شدن با موانع خود را داشتند. آنها به طور فعال با ذینفعان، سایر تیم های اسکرام و مدیریت، همکاری کردند تا راه حلی پیدا کنند. آنها آگاهی را در سازمان گسترده تر ایجاد کردند و توضیح دادند که چگونه موانع بر سایر مناطق نیز تأثیر می گذارد. اغلب، حمایت از افراد خارج از انتظار بوجود می آمد و راه حل هایی برای مشکلاتی پیدا می شد که حل آنها غیر ممکن به نظر می رسید.9. قرارداد تیمی یا مانیفست تیم ایجاد کنیدیکی دیگر از عوامل موفقیت عملی برای جلوگیری از زامبی اسکرام، ایجاد قرارداد تیمی یا مانیفست تیمی در شروع کار یک تیم جدید است یا اگر قبلاً در برنامه راه اندازی مجدد تیم در زامبی اسکرام گیر کرده اید. یک قرارداد یا مانیفست تیمی، شفافیت را در مورد ارزش های شخصی، توافق نامه های کاری یا نحوه همکاری ایجاد می کند. چگونه می خواهیم به صورت تیمی کار کنیم؟ چه کسی مسئول چه چیزی است؟ رویدادهای اسکرام چه زمانی هستند؟ همچنین می تواند حاوی توافقاتی در مورد نحوه برخورد با تعارض باشد. اگر نظر کاملاً متفاوتی در مورد چگونگی ساخت یک فیچر داشته باشیم، چطور؟ اگر در مورد هدف اسپرینت اختلاف نظر داشته باشیم چه؟ اگر بحث داغی داشته باشیم که بیش از حد شخصی شود؟اگر همه چیز بدون مشکل پیش رود، احتمالاً اهمیت قرارداد تیمی یا مانیفست تیم مشخص نیست. حتی ممکن است مانند اتلاف وقت احساس شود. با این حال در حال حاضر به شما کمک می کند تا از بسیاری از مشکلات جلوگیری کنید. مشکلاتی که ظاهراً از آنها آگاهی ندارید. ارزش آن زمانی مشخص می شود که با تیم خود در شرایط سختی قرار بگیرید. اگر در تیم خود بحث شدید دارید، بسیار مفید است که مکالمه را به طرف قرارداد تیمی هدایت کنید و همه را در مورد آنچه توافق کرده اند یادآوری کنید. به این ترتیب، قرارداد یا مانیفست به عنوان پایه محکمی برای پویایی، همکاری و رشد تیم عمل می کند. در مقالات “چگونه می توان یک تیم بزرگ را راه اندازی کرد” و “مانیفست تیم” این مفهوم را با جزئیات بیشتری شرح داده ایم.10. تمرکز بر فرآورده کامل شده (Done Increment)دهمین عامل موفقیت جامعه ما برای جلوگیری یا حذف زامبی اسکرام احتمالاً مهمترین عامل است. تیم اسکرام باید تمرکز عمیق خود را بر تولید فرآورده کامل شده در هر اسپرینت بگذارد که به ذینفعان خود ارزش ارائه می دهد. هدف از فرآورده، تأیید مفروضات مربوط به کارهایی است که تا به امروز انجام شده است. افرادی که در محصول سهیم هستند می توانند در صورت درک نحوه عملکرد و برآوردن انتظارات آنها، آن را بررسی کرده و تعیین کنند که آیا نیازهای آنها برآورده می شود یا خیر. فرآورده همچنین محرک ایده های جدید است، زیرا داشتن چیزی ملموس برای تعامل با آنها راهی عالی برای دیدن امکانات جدید است.این تمرکز سطح بالا بر ایجاد فرآورده کامل شده به احتمال زیاد موانعی را آشکار می کند. ممکن است تیم از قابلیت های فنی برای انتشار زودهنگام برخوردار نباشد و اغلب، مالک محصول این وظیفه را ندارد، یا همه بر روی محصولات مختلف زیادی کار می کنند که مانع از ایجاد هر چیزی برای ذینفعان خود می شود. تیم های دیگر حتی نمی دانند ذینفعان آنها چه کسانی هستند … این ما را به بسیاری از عوامل موفقیتی که قبلاً به اشتراک گذاشته بودیم باز می گرداند. تیم هایی که زامبی اسکرام را برطرف کرده اند در محیطی با درجه ایمنی روانی بالا کار می کردند، آنها روش های زیادی را برای یافتن راه حل امتحان کرده اند و شهامت مواجه شدن با موانع مداوم را داشتند.سخن آخردر این نوشته، ما 10 عامل موفقیت را که از جلسه اشخاصی که برای شبکه آزادی خواهان (The Liberators Network) میزبانی کرده بودیم به اشتراک گذاشتیم. عواملی که به تمرین کنندگان اسکرام کمک می کرد تا از زامبی اسکرام در تیم و سازمان خود جلوگیری کرده یا آن را برطرف کنند. امیدواریم این مقاله به عنوان منبع الهام برای بهبود اسکرام در سازمان شما عمل کند! مثل همیشه، ما مشتاق هستیم که از تجربیات شما نیز درس بگیریم. عوامل موفقیتی که تشخیص می دهید چیست؟ چه موارد دیگری را برای استفاده مؤثرتر از اسکرام امتحان کرده اید؟ با خیال راحت یافته های خود را به اشتراک بگذارید. بیایید با هم یاد بگیریم و رشد کنیم!لینک مقاله اصلیLiberating Structures کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Wed, 08 Dec 2021 21:22:22 +0330 https://virgool.io/@kasratoofani/%D8%A2%D9%86%DA%86%D9%87-%D8%AF%D9%88%D8%A7%D9%BE%D8%B3-%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87-%D8%A7%D8%AC%D8%A7%DB%8C%D9%84-%D8%A8%D9%87-%D9%85%D9%86-%D8%A2%D9%85%D9%88%D8%AE%D8%AA-tq023ch85ldu من زمان زیادی را صرف بررسی چگونگی استفاده سازمانها از دواپس برای بهبود زمان چرخه تحویل نرم افزار ، توانایی نوآوری و توانایی بهبود کیفیت کرده ام. من شنیده ام که بعضی از مردم تا آنجا پیش می روند که می گویند دواپس جایگزین اجایل شده است ، اما فکر نمی کنم درست باشد. دواپس اجایل را تقویت و پشتیبانی می کند و اجایل همچنان در قلب دواپس است. ویژگی های اساسی اجایل – کار با مراحل کوچک (دسته ای) ، ارائه نرم افزار کارکننده به طور مرتب بر اساس اولویت های کاری ، کار در تیم های کوچک دارای عملکرد خودکار کوچک و اندازه گیری پیشرفت بر اساس نرم افزار کارکننده – برای کار دواپس ضروری است. به نظر من دواپس به صراحت آنچه که بسیاری از تیم های اجایل قبلاً آموخته بودند را بیان می کند اما ممکن است رسمیت نیافته باشد. دواپس همچنین اصول اجایل را به سایر قسمتهای سازمان بخصوص بخش عملیات (Ops) گسترش می دهد. در حقیقت ، اجایل و دواپس از نظر همزیستی و جدایی ناپذیری با هم ارتباط دارند.اجایل برای افزایش سرعت به اتوماسیون نیاز داردبیانیه اجایل می گوید تیم های اجایل به نرم افزارهای که کار می کنند بیش از مستندات جامع اهمیت می دهند. این بدان معنی است که آنها نیاز به ساخت و تست نرم افزار دارند. زیاد. در واقع همه وقت. در حالت ایده آل ، آنها باید هر بار که تغییراتی در سورس کد منبع ایجاد می شود ، ساخته شوند. اما ساختارها فقط نقطه شروع هستند – آنها همچنین باید هر بار که تغییر ایجاد می کنند آزمایش شوند. نه فقط تست های واحد ، بلکه تست های عملیاتی ، تست رگرسیون ، عملکرد و مقیاس پذیری ، همه از API گرفته می شوند. و نه فقط در محیط های ساده ، بلکه در محیط هایی که تا حد امکان شبیه تولید هستند. وقتی این کار را انجام می دهند کد بهتری ارائه می دهند.برای انجام این کار ، آنها باید توسعه مبتنی بر تنه اصلی (master) را تمرین کنند. آنها به اتوماسیون ادغام مداوم نیاز دارند که نه تنها روند ساخت ، بلکه یک فرآیند تست مبتنی بر API را هر بار کد تغییر می کند به عهده بگیرد. آنها همچنین باید محیط های تست قوی را در صورت تقاضا در دسترس داشته باشند ، این بدان معنی است که از زیرساخت ها به عنوان کد یا سایر اتوماسیون های تأمین کننده محیط استفاده می شود. و در برهه ای از زمان ، هنگامی که آنها کاملاً مسئول پشتیبانی از برنامه در تولید هستند ، برای استقرار قابل اعتماد کد ، به ابزارهای اتوماسیون انتشار نیاز دارند. برخی از افراد اظهارات بیانیه را مبنی بر اینکه تیم های اجایل برای افراد و تعاملات بیش از فرایندها و ابزارها به معنای مهم نبودن ابزارها ارزیابی می کنند. افراد از اهمیت بیشتری برخوردار هستند زیرا آنها کسانی هستند که در واقع نرم افزار را خلق می کنند ، اما از نظر عملی این افراد به ابزار نیاز دارند.فاصله بین “آماده برای انتشار” و “منتشر شده واقعی” می تواند بسیار زیاد باشدارائه کد در حال کار در نسخه ی نمایشی در پایان هر اسپرینت بسیار ضروری است. با این وجود نسخه های نمایشی همانند دنیای واقعی نیستند. نسخه نمایشی ظرفیت کاری واقعی را در محیط های تهدید کننده زندگی تست نمی کند. نسخه نمایشی لازم نیست با برنامه های دیگر به خوبی اجرا شود. نسخه نمایشی نیازی به تحمل خطا یا خود درمانی ندارد. نسخه نمایشی در یک محیط تست لازم است اما کافی نیست. مقیاس پذیری ، امنیت ، قابلیت اطمینان و قابلیت نگهداری ضروری است. نسخه ی نمایشی می تواند بیش از حد بر روی ظاهر و احساس برنامه تمرکز کند و به اندازه کافی به ویژگی های دنیای واقعی آن نپردازد. تیم های اجایل که از برنامه های خود در محیط های واقعی پشتیبانی می کنند به سرعت این را می آموزند.محیط های تستی که مشابه شرایط واقعی هستند اولین قدم خوب است. تکنیک های پیشرفته استقرار مانند استقرارهای سبز و آبی و استقرار قناری ها ، استقرار در زیرمجموعه های جامعه کاربران ، بینش هایی را ارائه می دهد که نسخه های نمایشی هرگز نمی توانند. تست فرآیندهای استقرار خود با استفاده مکرر در محیط های واقعی به رفع ناهماهنگی هایی که منابع قابل توجهی از حوادث تولید هستند ، کمک می کند. تیم های چابک باید تعریف خود را از “انجام شده” تنظیم کنند تا درنهایت ارسال به مشتریان واقعی را شامل شود – تا زمانی که این کار را انجام دهند ، ممکن است خودشان را در مورد کیفیت و ارزشی که فکر می کنند ارائه می دهند فریب دهند.بازخورد مالک محصول و ذینفع محصول عالی است اما بازخورد واقعی مشتری، تست درستی از ارزش ارائه شده استمالک محصول تنها مرجع در مورد آنچه باید ساخته شود و داور “انجام شده” است ، حداقل تا زمانی که مشتریان واقعی صحبت کنند. دارندگان محصولات ، حتی افراد عالی ، افرادی مانند بقیه ما هستند ، با تعصبات و نقاط کور خاص خود. افزودن سایر سهامداران به نسخه های نمایشی می تواند با گسترش دیدگاه ها کمک کند ، اما آنها نیز نقاط کور دارند. داور نهایی ارزش، مشتری است و هرچه تیم سریعتر بتواند به مشتریان واقعی ارائه دهد ، سریعتر نظریه های خود را درباره آنچه که واقعاً مشتری به آن نیاز دارند تأیید یا رد می کند. این انتقادی از نقش مالک محصول یا نظرات ذینفعان نیست ، صرفاً بازتاب واقعیت است.معماری برنامه مهم استعملکرد و مقیاس پذیری اهمیت دارد. مسائل امنیتی مهم  است. خدمات ، ریز سرویس ها و API ها خصوصاً مهم هستند. هرچه برنامه با ساختار تکه های مستقل و یا کم وابسته باشد (loosely coupled) ، تغییر یک قسمت آسان تر است بدون اینکه این قسمت باعث تخریب بسیاری از قسمت های دیگر شود. API ها می توانند به عنوان بخشی از روند ادغام مداوم ، رگرسیون را تست کنند. به حداقل رساندن وابستگی به کد هنگام پرداختن به برنامه های بزرگتر سودآوری نیز دارد: هماهنگی کار با تیم های دیگر از طریق API های مشترک بسیار آسان تر از به اشتراک گذاری ساختارهای داده است. هنگامی که وابستگی تیم از طریق API واسطه است ، می توان از بسیاری از برنامه های پیچیده مدیریت برنامه و هماهنگی تیم جلوگیری کرد. تکنیک هایی مانند مجازی سازی خدمات (در غیر این صورت تمسخر و لجاجت شناخته می شوند) می توانند برای شبیه سازی تعهدات در حالی که تیم دیگر روی تحویل API جدید کار می کنند ، استفاده شوند.یکی از دلایلی که انتشار کد برنامه قدیمی بسیار دشوار است این است که برنامه یکپارچه است ، ساختار داده ها و پایگاه داده را با برنامه های دیگر به اشتراک می گذارد. تغییر آنها سخت است زیرا هر تغییری عوارض جانبی ناشناخته ای دارد. کنترل مجدد این کد سال ها به طول می انجامد و بازنویسی آن ساده تر است. ولی اپلیکیشن های مدرن اینگونه نیستند و تیم های اجایل بایستی سخت کار کنند تا محصولات آنها بر اساس ساختار تکه های مستقل یا وابستگی کم باشند که مبادا روزی اپلیکیشن های قدیمی آینده شوند.اندازه کوچک برای چرخه بازخورد سریع و کاهش خطر انتشار بسیار مهم استهرچه میزان انتشار کمتر باشد ، وابستگی ها نیز کمتر می شوند. هر چه وابستگی ها کمتر باشد ، موارد کمتری برای اشتباه وجود دارد. اگر می خواهید خطر انتشار را کاهش دهید ، اندازه را کاهش دهید ، فرآیندهای کنترل را که در واقع اندازه انتشار را افزایش می دهند ، با ایجاد یک فرآیند بسیار سخت ، دو برابر نکنید ، به طوری که افراد برای جلوگیری از آن هر کاری انجام می دهند ، مانند انتشار کمتر. انتشارهای کوچکتر هماهنگی را آسان می کند. آنها پذیرش کاربر را آسان می کنند زیرا تغییرات یا ویژگی های جدید کمتری برای یادگیری وجود خواهد داشت. انتشارهای هدفمند و کوچک تر ، ارزیابی تأثیر آنها را آسان تر می کند زیرا موارد کمتری برای اندازه گیری وجود دارد. این بازخورد را سریعتر می کند ، که باعث کاهش اتلاف شده و به تیم ها کمک می کند تا نسخه های بعدی را بهتر کنترل کنند. انتشارهای مکرر و کوچک تر ، خوب هستند.آنها خوب هستند ، اما تنها در صورتی که تیمی به طور مداوم در حال ساخت و آزمایش نرم افزار خود باشد. آنها فقط درصورتی که فرآیندهای انتشار، ساده و قابل پیش بینی باشند ، خوب هستند. آنها فقط زمانی خوب هستند که اپلیکیشن ها بر اساس ساختار تکه های مستقل و یا کم وابسته باشند تا در صورت بروز یک مشکل،  منجر به ایجاد سلسله ای از مشکلات دیگر نشوند.تیم های چابک به عملکردهای دواپس و همچنین دواپس برای دستیابی به نتایج بهتر به مدل تیمی اجایل و اتصال به ارزش تجاری نیاز دارندشیوه های دواپس به تیم اجایل کمک می کند تا کارهای روزمره و معمولی را به صورت خودکار انجام دهد و به آنها اجازه می دهد تا روی نوشتن کد ماژولار با کیفیت بالا و به هم پیوسته متصل شوند که راه حل مناسب را ارائه دهد. دواپس به بک لاگ تجاری محور اجایل (از طریق مالک محصول) و قابلیت مدیریت خط جریان (pipeline) نیاز دارد. این برای ایجاد تیم های با عملکرد بالا به مدل تیم اجایل نیاز دارد. تیم های چابک باید مسئولیت مدیریت برنامه های کاربردی در تولید را به عهده بگیرند و مهارت های Ops و Security را به کارنامه خود اضافه کنند.اجایل و دواپس در واقع چیزهای جداگانه ای نیستند. چابک همیشه از برتری در اصول مهندسی استقبال کرده است. نیاز به ارائه و پشتیبانی برنامه های کاربردی در تولید ، تمرکز را گسترش می دهد. انجام این کار در چرخه های سریعتر به این معنی است که اتوماسیون اکنون حتی بخش مهمی از آن اقدامات مهندسی است.لینک مقاله اصلی:https://www.scrum.org/resources/blog/what-devops-taught-me-about-agile کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Sun, 29 Aug 2021 17:10:18 +0430 https://virgool.io/@kasratoofani/%D9%81%D8%B9%D9%84%D8%A7%D9%8B-%D8%A7%D8%B2-%D8%A2%D8%A8%D9%86%D8%A8%D8%A7%D8%AA%D8%AA-%D9%84%D8%B0%D8%AA-%D8%A8%D8%A8%D8%B1-nif7mpwfi26s *بر اساس داستان واقعی*“هنوز روی مبل منتظرم. ساعت ۹ صبح روز دوشنبه است و هاب اسپاتی ها پشت سر هم وارد می شوند. خیلی ها لباس های هاب اسپات به تن دارند، مثل بازیکن های تیم های ورزشی. ”“هاب اسپات پانصد کارمند دارد و دیوانه وار هم نیروی جدید استخدام می کند. ”“در طبقه همکف، یک سالن همایش بزرگ کار اتاق بازی را هم می کند و میز فوتبال دستی، میز پینگ پنگ، میز بیلیارد و بازی های رایانه ای دارد. به یکی از دیوارها چند ظرف شیشه ای پر از انواع آجیل و آبنبات نصب کرده اند. اسمش را ‘دیوار آبنبات’ گذاشته اند.”دَنیل لاینز روزنامه نگار بخش فناوری و کسب و کار نشریه نیوزویک که از کارش برکنار شد و برای گذران زندگی در سن پنجاه و یک سالگی به هاب اسپات یکی از استارتاپ های بزرگ سیلیکون ولی پیوست. حالا او قصد دارد با توصیف تجربیات و مشاهدات خود، نقاب پر زرق و برق شرکت های استارتاپی را از چهره شان بردارد.سرمایه گذارها این تصویر را دوست دارند: یک مشت جوان شاد و شنگول که از عوض کردن دنیا حرف می زنند، خوب می فروشد.هاب اسپات زیان ده است اما به نیروی کار زیاد با دستمزد پایین نیاز دارد. راه حل این است که آدم های تازه فارغ التحصیل را استخدام کنی و کار را تفریح نشان دهی. برایشان آبجوی مجانی و فوتبال دستی می آوری. محیط کار را ملغمه ای از مهدکودک و خانه مجردی میکنی و به مناسبت های مختلف مهمانی میگیری.شرکت را به یک تیم تبدیل کنی و برای این تیم یک رنگ و نماد انتخاب کنی. به همه کلاه و تیشرت می دهی. مرامنامه فرهنگی سرهم میکنی و دم از ایجاد شرکتی میزنی که همه عاشقش باشند و بعد هم منظره پولدار شدن پیش چشمشان ترسیم میکنی.اما واقعا در پس صحنه این نمایش جذاب چه منافعی برای صاحبان اصلی کسب و کار نهفته است؟لاینز اعتقاد راسخ دارد فضای رنگارنگ و (زیادی) خودمانی برخی از استارتاپ ها صرفاً برای بزرگ کردن نام آن ها و ثروتمند شدن مدیران آنهاست.“دیگه کسی به خاطر تولید فناوری عالی چیزی گیرش نمیاد. مهم مدل کسب و کاره. بازار بهت پول میده تا شرکتی بسازی که سریع رشد کنه. لازم نیست سودآور باشی، فقط گنده شو.”در مدل جدید کار در عصر دیجیتال و فناوری، کارفرما می تواند از کارکنان انتظار وفاداری داشته باشد اما هیچ لزومی ندارد به کارکنانشان وفادار باشد. برای آدم ها شغل های امن مادام العمر نمی سازند، بلکه مثل قطعات دورریختنی با آنها رفتار می کنند که می شود یکی دو سال به شرکت وصلشان کرد و بعد جدایشان کرد و دور انداخت.رِید هافمن، هم بنیانگذار مولتی میلیاردر لینکدین، در کتاب پرفروش “اتحاد” می گوید: “شرکت شما خانواده تان نیست.” هافمن اعتقاد دارد کارکنان باید کار را یک “سفر خدمت” بدانند و انتظار استخدام طولانی نداشته باشند. از دید او، شغل یک معامله است که در آن کارمند خدمتی را ارائه می کند، پولش را می گیرد و خداحافظ.شرکت آمازون به شرایط سخت کارش معروف است. تحقیقات در سال ۲۰۱۳ نشان می دهد کارکنان آمازون به طور متوسط فقط یک سال آنجا دوام می آورند.در مرامنامه فرهنگی نتفلیکس جمله معروفی وجود دارد: “ما یک تیم هستیم، نه یک خانواده.” توجیه آنها هم این است که شرکت های فناور هم باید مانند تیم های ورزشی حرفه ای “ستاره هایی در همه پست ها داشته باشند.”این مدل کار جدید چیزی جز نسخه تازه ای از داستانی کهنه نیست، همان قصه استثمار نیروی کار توسط سرمایه. فرقش این است که این بار لبخند پهنی روی صورت استثمارگر نشسته.لاینز در جمع همکاران جوان خود می گوید:“می دونید، نسل شما اولین نسلیه که حاضره بخاطر آبنبات مجانی کار کنه. نسل من هیچ وقت گول این چیزا رو نمی خورد. ما فقط پول رو قبول می کردیم.”نکته قابل توجه این است که لاینز به نکوهش کارکنان این شرکت ها هم پرداخته و افسوس می خورد که چطور این جوانان بلند پرواز با یک محیط کار دیزنی لند و ایده های جنگ ستارگانی راحت فریفته می شوند. حتی دسته جمعی در مقابل لاینز جبهه می گیرند و شاید در ذهنشان او را “پیر بدبین” می دانند.لاینز عقب نشینی می کند و دست از نکوهش می کشد:“می دونید چیه، حق با شماست. ببخشید که بحثش رو پیش کشیدم. آبنبات ها عالین.”“ما یک تیم هستیم، نه یک خانواده.” درست مثل بازیکن های لیگ برتر بیسبال، یکی از روزهای خدا و بی هیچ هشداری پرتت می کنند بیرون. اما ببین…فعلاً از آبنباتت لذت ببر!براشت هایی از کتاب “مصائب من در حباب استارتاپ ها” نوشته دنیل لاینز و ترجمه سعید قدوسی نژادپیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Tue, 02 Feb 2021 21:23:13 +0330 https://virgool.io/@kasratoofani/%D9%88%D8%A7%D9%82%D8%B9%D8%A7%D9%8B-kiss-%D8%AF%D8%B1-%D8%A7%D8%B2%D8%A7%DB%8C-%D8%A8%D8%AF%D9%87%DB%8C-%D9%81%D9%86%DB%8C-myq5bfxdutab در توسعه نرم افزار مفهومی وجود دارد به نام KISS یا اصل سادگی که به روایت های مختلفی بیان می شود:“Keep it simple, silly”, “keep it short and simple”, “keep it simple and straightforward”, “keep it small and simple”, “keep it stupid simple”در ویکی پدیا اینگونه تعریف شده است:“این اصل بیان می‌کند که اکثر سیستم‌ها چنانچه ساده و به‌ دور از پیچیدگی بمانند، عملکرد بهتری خواهند داشت؛ بنابراین، سادگی باید هدف اصلی طراحی سیستم‌ها باشد و از پیچیدگی‌های بیهوده اجتناب کرد.”برای آنکه به درک مشترکی برسیم من اسمش را “سادگی جذاب مشتری” می گذارم که یک مالک محصول توانمند و متخصص از آن به عنوان ابزاری برای کسب اقبال بیشتر مشتریان و کاربران استفاده می کند. اما در سوی دیگر این میدان سادگی، توسعه دهندگان محصول (یا سیستم) قرار دارند. جایی که برنامه نویسان وظیفه اصلی پیاده سازی این سادگی را دارند و متاسفانه محل بروز چالش ها و اشاره همیشگی چوب های سرزنش در مشکلات و خطاهای سیستم هستند!راحت نویسییک رویکرد بسیار متداول بین برنامه نویسان این است که کد نویسی به گونه ای انجام شود که در مرحله اول صرفاً کد عملیاتی شده و سیستم کار کند. اما دقیقاً تأکید همینجاست “در مرحله اول”.مشکل زمانی بروز می کند که این سادگی در کدنویسی تا آنجایی ادامه یابد که امکان گسترش و تعمیم آن در سطوح دیگر برنامه (یا برای scale بزرگتر) وجود نداشته باشد.این مورد را می توان “سادگی جذاب برنامه نویس” نامید که در نقطه مقابل بشدت منفور مالک محصول و سرمایه گذاران است. چرا که دیر یا زود گریبان گیر شده و آن ها را با گلایه و شکایت های کاربران مواجه می کند. این همان “بدهی فنی” (Technical Debt) است.“بدهی فنی در نتیجه تصمیمات بد یا انتخاب های ضعیف فنی ایجاد می شود.”بدهی های فنی می بایست بطور مستمر رسیدگی و رفع شوند. در صورت انباشت به مرور زمان سرعت توسعه و تحویل محصول را کاهش داده و در نهایت حتی می توانند مانع تولید increment و خروجی نهایی برای زمان طولانی شود.بدون شک کد گسترش می یابد. کاربران سیستم شما بیشتر می شوند و مهمتر از همه از نوشتن کد فعلی زمان می گذرد و آنوقت بهبود آن روز به روز سخت تر شده و هزینه عملیاتی بیشتری به همراه خواهد داشت.به طور مثال در طراحی شیء گرا یکی از اصول پنج گانه SOLID این است که کلاس ها، توابع، متدها و … باید گسترش پذیر باشند و در عین حال برای تغییر کردن بسته باشند.حفظ کیفیتچالش دیگر همراه با ایجاد اصل سادگی این است که باید همراه با حفظ و ارتقا کیفیت محصول باشد و از طرف دیگر این سادگی در طراحی سمت کاربر زمانی که بیش از اندازه باشد می تواند کاربر را سردرگم کند. طراحان UI/UX شما در این زمینه متخصص هستند پس به آن ها اعتماد کنید.بطور مثال اگر شما در سیستمتان یک پنل کاربری دارید عملیات های مختلف باید به راحتی و سریع در دسترس کاربر باشند اما اگر همین پنل شامل ۲۰ عملیات مختلف باشد برای فراری دادن کاربرانتان می توانید همه آن ها را در یک آیتم بگنجانید. باید خیلی احتیاط کنیم که بقول همان ضرب المثل معروف از آن طرف بوم نیفتیم!به خاطر داشته باشیم که اصل سادگی، بسیار ارزشمند و مهم  است اما نه به هر قیمتی.پیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Mon, 11 Jan 2021 13:22:21 +0330 https://virgool.io/@kasratoofani/10-%D9%85%D9%88%D8%B1%D8%AF-%D8%A7%D8%B2-%D9%85%D9%87%D9%85%D8%AA%D8%B1%DB%8C%D9%86-%D8%A8%D8%B1%D8%AA%D8%B1%DB%8C-%D9%87%D8%A7%DB%8C-%D9%81%D9%86%DB%8C-%D8%AA%DB%8C%D9%85-%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-a1vpi7is8grq https://www.aparat.com/v/36GUD www.aparat.com/v/36GUD در طول زمان با تغییر نگرش و بزرگ تر شدن اهداف سازمان ها، بهبود و پیشرفت جزو ملزومات تیم های نرم افزاری شده است. پروژه های جدید دانش های جدید را هم طلب می کنند. تا جایی که به جرأت میتوان گفت چابکی سازمانی بدون چابکی فنی بی معنی است.به عنوان یک عضو تیم نرم افزاری بسیار مهم است که با این برتری ها آشنا بوده و به آن ها پایبند باشیم. در این ویدیو به معرفی و بررسی 10 مورد از مهمترین برتری های فنی می پردازیم."توجه مداوم به برتری فنی و طراحی خوب، چابکی را بهبود می بخشد." (یکی از اصول ۱۲ گانه مانیفست چابک)پیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Sat, 12 Dec 2020 17:13:15 +0330 https://virgool.io/@kasratoofani/%D8%AF%D9%88%D8%B1%D9%87-%D8%A2%D9%85%D9%88%D8%B2%D8%B4%DB%8C-%D9%88%DB%8C%D8%AF%DB%8C%D9%88%DB%8C%DB%8C-%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D9%85%D9%82%D8%AF%D9%85%D8%A7%D8%AA%DB%8C-%D8%A8%D8%A7-%D9%85%D9%87%D8%A7%D8%B1%D8%AA-%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%AF%D9%88%D9%84%D9%88%D9%BE%D8%B1%DB%8C-zhwjpcv57a9q کتاب ها، وبینارها و دوره های زیادی وجود داره که به شما آموزش میده چطور بهتر کد بزنین، یک تکنولوژیه جدید رو یاد بگیرین یا چطور پروژه نرم افزاریتون رو پیاده سازی و اجرا کنین.حتی ممکنه آموزش های زیادی درباره حرفه شما وجود داشته باشه و اینکه چطور بهبودش بدین یا چطور جلسات مصاحبه کاریه موفقی داشته باشین.اما بیاین از زاویه دیگه ای نگاه کنیم ... واقعا چقدر آموزش وجود داره که به شما بگه چطور میتونین نسخه بهتری از یک توسعه دهنده نرم افزار، برنامه نویس یا عضو تیم نرم افزاری باشین؟اینکه "حرفه ای" بودن درون یک تیم نرم افزاری، فارغ از هر تخصصی چطور معنا میشه و یک کار تیمی خوب چه رفتار، مهارتها و روحیاتی رو میتونه شامل بشه؟تعاملات یک عضو تیم با سایر اعضاء، مدیر، مالک محصول، اسکرام مستر و ... چطور باید باشه و با توجه به فرهنگ، شرایط اجتماعی و روحیات ما ایرانی ها چه رفتارهایی واقعا درون تیم خیلی ضروریه؟چه مشکلاتی اخیرا درون تیم های ایرانی زیاد داره دیده میشه و راه حل ها چی میتونن باشن؟و شاید مهمترین داستان این روزها ... با این شرایط شیوع کرونا و دورکاری چطور یکی از مهمترین اصول و مبانی اجایل و اسکرام یعنی "communication" رو طوری حفظ کنیم که هم خودمون پیشرفت کنیم و هم با بهبود کار تیمی، رضایت مشتری، مدیر یا کارفرما رو داشته باشیم؟# توی این آموزش قراره با استناد به منابع خوب و بروز بین المللی، اصول اسکرام دولوپری و همینطور تجربیات کاریه خودم و همکارانم در محیط های نرم افزاری و استارتاپی رو بررسی کنیم و به دغدغه هامون بپردازیم.# "آشنایی مقدماتی با مهارت های نرم دولوپری" یک دوره آموزشی ویدیویی هست که در مرحله تولید هستیم و به امید خدا تا قبل از پایان آذر منتشر میشه. این دوره نقطه شروع هست و بعد از اون "دوره جامع مهارتهای نرم دولوپری" رو تولید خواهیم کرد. خیلی خوشحال میشم اگه نظر و پیشنهادتون رو بهم برسونین تا با ذکر نام خودتون ازش استفاده بشه و به پیشرفت همه برنامه نویسان و توسعه دهندگان نرم افزاریه کشورمون و حتی مدیران این تیم ها کمک کنیم.پیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Tue, 01 Dec 2020 18:44:55 +0330 https://virgool.io/@kasratoofani/%D8%A7%D9%81%D8%B1%D8%A7%D8%AF-%D8%AF%D8%B1-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%DB%8C%DA%A9-%D8%AA%DB%8C%D9%85-%D9%86%D8%A7%D9%85%DB%8C%D8%AF%D9%87-%D9%85%DB%8C-%D8%B4%D9%88%D9%86%D8%AF-%D8%A7%D9%85%D8%A7-%D8%A2%DB%8C%D8%A7-%D9%88%D8%A7%D9%82%D8%B9%D8%A7-%DB%8C%DA%A9-%D8%AA%DB%8C%D9%85-%D9%87%D8%B3%D8%AA%D9%86%D8%AF-qpmsma2kmuod در این مقاله می خواهم به مباحث مربوط به مربیگری تیم حرفه ای و همچنین اسکرام حرفه ای بپردازم. در دوره “مربیگری تیم”، برای اسکرام مسترهایی که می خواهند وضعیت مربیگری خود را بهبود دهند، مباحث جالب زیادی را متوجه شدم.اول از همه، می خواهم متذکر شوم که مدل ها و اصطلاحاتی که من از آنها استفاده می کنم و در مورد آنها بحث می کنم مال من نیستند. آنها از جلسات تمرینی و مربیگری متعلق به ورومن هستند. ارتباطی که من با اسکرام ایجاد می کنم تعبیر من است.اسکرام و تیم هاوقتی سازمان ها با اسکرام شروع می کنند ، اولین کاری که انجام می دهند تشکیل تیم ها است. تیم های اسکرام با تیم های توسعه. بعضی اوقات در یک انفجار بزرگ، گاهی اوقات ناشی از تغییرات سازمانی رو به افزایش، اما همه چیز با تیم ها شروع می شود. تیم ها اساس اسکرام هستند. بدون این ساختار بنیادی، اسکرام وجود ندارد.اما تیم دقیقاً چیست؟ چه زمانی گروهی از افراد تیم هستند؟ چه چیزی آنها را به یک تیم تبدیل می کند؟ و وقتی تیمی در کنار هم قرار می گیرند ، بر چه اساس است؟ اصلا آیا آنها می خواهند تیمی شوند؟ و چرا ممکن است که این مسئله مهم باشد؟مراحل توسعه تیموقتی گروهی از افراد را در یک اتاق قرار می دهید ، هنوز تیم تشکیل نشده است. چیزهای بیشتری برای این منظور لازم است. آنها به یک هدف مشترک، یک مقصود رایج نیاز دارند. این چیزی است که آنها روی خودشان کار می کنند یا به آنها گفته شده است که انجام دهند. حتی وقتی آنها این هدف مشترک را دارند ، آیا آنها را به یک تیم تبدیل می کند؟ اگر این افراد مختلف به طور جداگانه با اهداف یکسان کار کنند ، آیا این کار تیمی است؟ می توانم بشنوم که فکر می کنید: “نه …”.این همان چیزی است که به بسیاری از افراد در سازمان ها اجبار می شود. برخی دیگر تصمیم می گیرند که گروهی از افراد نیاز است که با هم همکاری داشته باشند و کنار هم قرار بگیرند: یک تیم اسکرام متولد می شود! از نظر فنی می توانید آنها را تیم بنامید. سؤال این است: “آیا مجموع کار این افراد منجر به ارزش ، بهره وری و هم افزایی بیشتر از زمانی خواهد شد که افرادی باشند که منفرد روی این اهداف کار می کنند؟”در اینجا در مورد اهداف و مقاصد صحبت می کنم. با این حال ، من تیم های اسکرام زیادی را دیده ام که بدون مقصود و هدف شروع به کار می کنند. فقط توده انبوهی از کار.این نقطه شروع ما است.وقتی تیم ها را بررسی می کنیم می توانیم چند مرحله مختلف را تشخیص دهیم. من از مدل ورومن در مراحل توسعه تیم استفاده می کنم. او مدل خود را بر اساس کار کاتزنباخ و اسمیت ساخت. می توانید اطلاعات بیشتری درباره تفسیر کار او در اینجا بخوانید.هدف از این مقاله این نیست که به طور کامل این مدل توضیح داده شود ، اگرچه فکر می کنم به دلایل زیادی می تواند ارزشمند باشد. دلیل اینکه می خواهم این مدل را نشان دهم این است که میخواهم ذهن شما را به فکر کردن در مورد تیم های اسکرام که ایجاد می شوند اما در واقع یک تیم نیستند، معطوف کنم.شاید آنها حتی لازم نیست که وجود داشته باشند. شاید آنها یک “تیم باغ اختصاصی” باشند همانطور که ورومن می گوید. همه آنها چمن مخصوص به خود را دارند که روی آن کار می کنند. آنها تخصص خود را دارند. آنها به طور مستقل از بقیه کار می کنند ، برای اینکه کار خود را تمام کنند به دیگران در تیم نیازی ندارند. اگر یک عضو تیم کار خود را تمام نکرده باشد ، ممکن است آنها را آزار دهد ، اما به همان اندازه ممکن است آزار دهنده نباشد. اگر کسی به علفهای هرز خود که بعداً به چمن دیگر منتقل می شود توجه نکند، آنها را آزار می دهد – کارهای بیشتری برای آنها ایجاد می شود… شاید آنها از همان آب استفاده کنند اما برای آبیاری گیاهان خود. نه بیشتر.در یک تیم کاری افراد واقعاً به یکدیگر وابسته هستند تا بتوانند کار خود را انجام دهند و به اهداف خود برسند. آنها به دنبال ارتباط هستند ، با هم کار می کنند ، و بیشتر به یکدیگر کمک می کنند. به افراد یک تیم می توان دستور داد که با هم کار کنند ، اما آنها تنها در صورتی که برای خودشان تصمیم گیری کنند، واقعاً این کار را انجام می دهند.زمانی که  افراد در این مرحله از خارج از تیم مجبور شوند یک تیم کاری شوند ، احتمالاً به یک تیم مشکل ساز تبدیل می شوند.این یک جنبه مهم برای تحقق بخشیدن است زمانی که شما درون تیم های اسکرام مشغول هستید یا در کنار آن، به خصوص اگر شما اسکرام مستر باشید آیا این مسئله برای افراد مهم است که یک تیم نباشند؟ آیا آنها می خواهند بخشی از یک تیم باشند؟ آیا آنها حرفی برای گفتن دارند؟وقتی در مورد یک تیم عالی فکر می کنیم ، چیزی مرموز در مورد آن وجود دارد. هم افزایی و انسجام وجود دارد. اعتماد. کار دو نفر بیشتر از مجموع کارهای فردی آنهاست. این همان چیزی است که ما هنگام مربیگری تیم یا وقتی در یک تیم کار می کنیم به دنبال آن هستیم.اسکرام مستر و موضع مربیگری (تیم)در مورد مواضع مختلف اسکرام مستر بسیار نوشته شده است. من می خواهم به طور خاص در مورد اسکرام مستر به عنوان مربی تیم صحبت کنم.درک اینکه چگونه تیم به تیم تبدیل شده است می تواند به شما به عنوان اسکرام مستر کمک کند تا تیم را به سمت انسجام و هم افزایی بیشتر هدایت کنید. این باعث می شود تیم به مکانی امن و شاد برای کار تبدیل شود. آگاه باشید که با ارزیابی این مسئله ، این تیم هرگز نمی توانست تیم اسکرام باشد یا اصلاً هیچ وقت نیازی به تیم اسکرام بود؟من یک مقاله جداگانه در مورد اسکرام مستر به عنوان مربی تیمی اختصاص خواهم داد و اینکه چه ستون هایی برای هدایت تیم به سمت انسجام و هم افزایی بیشتر مهم هستند.خلاصههمه تیم های اسکرام به عنوان یک تیم شروع نمی شوند. این ممکن است به این دلیل باشد که:آنها یک هدف یا یک مقصود مشترک ندارندو / یا۲- آنها در دستیابی به اهداف خود یا انجام کار خود هیچ وابستگی ندارندو / یاآنها در بخشی از تیم حرفی برای گفتن نداشتندنقش اسکرام مستر می تواند این باشد که این مسائل شفاف شود و به تیم کمک کند تا تصمیم بگیرد که در آینده چه کند.بیایید احترام بگذاریم و در مورد نیازها و توانایی های آنها با مردم صحبت کنیم. بیایید فقط با صراحت همه را در یک تیم رها نکنیم و انتظار داشته باشیم که اسکرام مستر موانع آنها را برطرف کند زیرا آنها در راه رسیدن به یک تیم فوق العاده هستند. بیایید یک تیم را بر روی افراد اعمال نکنیم ، اما بگذارید اعضای تیم بصورت بالقوه در انتخاب هایی که انجام می شود شرکت کنند. این اولین قدم برای تیم عالی اسکرام  است!با تشکر از سیورد کرانندونک، ماچا گیلینگ و استیو ترپس برای کمک به من در بهبود این مقاله. و البته ورومن بخاطر الهام بخشی و دانش مربیگری تیم.لینک مقاله اصلی:https://www.scrum.org/resources/blog/people-are-called-team-scrum-are-they-really-teamپیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Sat, 31 Oct 2020 19:17:31 +0330 https://virgool.io/@kasratoofani/%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%B1%D9%88%D8%B2%D8%A7%D9%86%D9%87-%D8%B5%D8%B1%D9%81%D8%A7%D9%8B-%DB%8C%DA%A9-%D8%AC%D9%84%D8%B3%D9%87-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA-%DA%A9%D8%A7%D8%B1-%D9%86%DB%8C%D8%B3%D8%AA-fp55kszcjduz آیا  اسکرام روزانه (Daily Scrum) رویدادی است برای آن که بررسی کنیم تیم توسعه طبق برنامه ریزی انجام شده عمل می کند؟این یک سوال مکرر در طول آموزش های اسکرام من است. اغلب در ابتدای جلسه اتفاق می افتد. در واقع شبیه به یک افسانه است. این افسانه به طور قابل توجهی بر کارایی تیم های اسکرام و سازمان هایی که از آنها استفاده می کنند تأثیر می گذارد.بیایید تفاوت های اساسی بین Daily Scrum و یک جلسه پیشرفت را کشف کنیم.جلسه اسکرام روزانه چیست؟Daily Scrum  رویدادی است که توسط تیم توسعه انجام می شود. این امکان را به وی می دهد تا با یک برنامه جدید برای ۲۴ ساعت آینده، کارهای انجام شده در ۲۴ ساعت گذشته را بازرسی کند و با رسیدن به هدف اسپرینت سازگار شود. اسکرام روزانه با همکاری گسترده ای که برای رسیدن به هدف اسپرینت ایجاد می کند ، خود سازماندهی تیم توسعه را تقویت می کند.احساس فوریت ایجاد شده به واسطه بازه محدود زمانی ۱۵ دقیقه ای، فرصتی بزرگ برای تیم توسعه است که به یک تیم واقعی تبدیل شود و نه فقط جمعی از افراد. تمرکز اسکرام روزانه روی هدف اسپرینت است و این بازه زمانی کوتاه ، همه ما را به سمت موارد اساسی سوق می دهد: همکاری برای دستیابی به بهره وری و خلاقیت.آیا تیم توسعه می تواند افراد دیگری را دعوت کند؟مستند راهنمای اسکرام در مورد این موضوع چیزی را اجبار نکرده است. اما تصریح می کند که اسکرام روزانه برای تیم توسعه است و ضمناً خود سازمان یافته است. یعنی خود تیم توسعه تصمیم می گیرد که چگونه به بهترین وجه به اهداف خود برسد.یک تیم توسعه می تواند تصمیم بگیرد که اگر در زمانی مشخص برای آن مفید باشد شخص ثالث (اسکرام مستر، مالک محصول یا یک متخصص) را دعوت کند. اما خطری وجود دارد که بزرگترین دارایی خود را برای رسیدن به هدف خدشه دار کند. هدف از اسپرینت در واقع این است: همکاری صمیمانه و خود سازماندهی.شخصاً زمانی که فردی به دیدن من در محل کار می آید ، رفتار من تمایل به تغییر دارد، شما اینطور نیستید؟جلسه پیشرفت کار چیست؟اگر تعریف رسمی وجود نداشته باشد ، عملی که در سازمان ها مشاهده می شود این است که هر فرد به نوبه خود دستاورد خود را در ارتباط با کارهایی که شخص دیگری به او واگذار کرده است ارائه می دهد. تمرکز روی تکمیل کارها یا دستیابی به مرحله بعد برجسته تر است ، نه ارزش تحویل داده شده یا تأثیر کاربر، و در نهایت همکاری های فردی مورد بررسی قرار می گیرد ، یا حتی مقایسه می شود.این جلسات پیشرفت به صورت آگاهانه یا ناخودآگاه تمایل به کنترل افراد و سنجش کمک های فردی آنها دارند. از آنجا که افراد به رقابت تشویق می شوند ، همکاری بین آنها آسیب می بیند چه آنکه شفافیت اصلی ضروری برای عملکرد صحیح تجربه گرایی (Empiricism) است.تبدیل اسکرام روزانه به یک جلسه پیشرفت ، یک ترمز گاهی بی رحمانه برای ایجاد ارزش توسط تیم اسکرام است و مخالف منافع مورد علاقه ذینفعان است.اسکرام روزانه به طور طبیعی خطرات اسپرینت را کنترل می کند.اسکرام روزانه با پرورش تیم با اعتماد به نفس ، شفافیت را تقویت می کند. ریتم روزانه آن امکان کنترل افراد را امکان پذیر نمی کند ، بلکه خطرات ناشی از عدم موفقیت در محیط های پیچیده قابل سازگاری (complex adaptive environments) را نشان می دهد.کسانی که مایل به تحمیل حضور خود در اسکرام روزانه هستند ، تیم را با مشکل مواجه کرده و اسپرینت را در معرض خطر قرار می دهند. آنها عدم اعتمادشان به تیم توسعه را نشان می دهند و تیم را از انگیزه ها و ایده هایی که بیشترین ارزش را ایجاد می کند ، دلسرد می کنند.نتیجه گیریبه وسیله تیم توسعه و برای آن ها، اسکرام روزانه برای ایجاد ارزش در یک محیط پیچیده ضروری است. توانایی آن برای به وجود آوردن تجربه گرایی و خود سازماندهی تیم توسعه ، زندگی را به طور روزمره کنترل می کند و شانس رسیدن به هدف اسپرینت را  بدون نیاز به مداخله از خارج ، به حداکثر می رساند.اسکرام روزانه هنری است به بزرگی و اهمیت یک رویداد اسکرام.و شما ، از چه تکنیکی برای مؤثر کردن این رویداد استفاده می کنید؟لینک مقاله اصلی:https://www.scrum.org/resources/blog/le-daily-scrum-nest-pas-une-reunion-davancementپیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Sun, 04 Oct 2020 16:52:24 +0330 https://virgool.io/@kasratoofani/%D9%88%DB%8C%D8%AF%D8%A6%D9%88-%D8%A8%D9%84%D8%A7%DA%AF-%D8%AE%DB%8C%D9%84%DB%8C-%D8%B3%D8%A7%D8%AF%D9%87-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%DA%86%DB%8C%D8%B3%D8%AA-z8ebuhgqqavd راستی واقعا اسکرام چیست؟این سوال شاید برای خیلی از افراد پیش آمده باشد که اسکرام چیست؟ در واقع اسکرام چارچوبی است برای کار تیمی موثر جهت تولید و تحویل مستمر محصولات پیچیده از قبیل پروژه های نرم افزاری، مارکتینگ، تحقیق و توسعه، آموزش، بهداشت و درمان و … . ولی با توجه به چارچوب بودن اسکرام و نوعی تعریف انتزاعی که پشت آن است فهم آن را در قدم اول کمی مشکل کرده است. از اینرو تصمیم گرفته ایم تا تعریف آن را با کمک مثالی از دنیای واقعی و نقش اسکرام در برون رفت از مسئله ای که بوجود آمد، ارائه دهیم. این مثال از تجربه واقعی خود نویسنده آمده و می توانست اثر شگرف آن را در صورت استفاده درست و به موقع از اسکرام ببیند. به عقیده نویسنده پتانسیل و قدرت چارچوب اسکرام آنقدر قابل توجه است که به هیچ وجه نمی توان از آن چشم پوشی کرد. این چارچوب در تمام ابعاد زندگی از جمله بعد شخصی، کار در یک تیم و حتی راهبری یک کسب و کار حرفی برای گفتن دارد. https://www.aparat.com/v/KlqPG حالا شاید برایتان روشن شده باشد که چرا براحتی نمی توان و نباید از این روش کاری جدید که بیش از ده ها میلیون نفر در جهان در حال استفاده از آن هستند، غافل شد.مدرسه اسکرام مرجع حرفه ای آموزش اسکرام کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Thu, 24 Sep 2020 15:17:00 +0330 https://virgool.io/coderlife/%D8%A2%DB%8C%D8%A7-%D8%AF%D8%B1-%D8%AC%D9%84%D8%B3%D9%87-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D8%B1%DB%8C%D8%B2%DB%8C-%D8%A7%D8%B3%D9%BE%D8%B1%DB%8C%D9%86%D8%AA-%D8%A8%D8%AF%D9%87%DB%8C-%D9%81%D9%86%DB%8C-%D8%A7%DB%8C%D8%AC%D8%A7%D8%AF-%D9%85%DB%8C-%DA%A9%D9%86%DB%8C%D8%AF-tadeobhyeovc اسکرام  یک چارچوب ساده برای توسعه محصولات نرم افزاری پیچیده در یک محیط پیچیده است ولی عملی کردن آن سخت است. اما چرا؟ من به تشریح دلایل این موضوع نمی پردازم، اما می خواهم مطابق درک خودم یکی از مشکلات تیم توسعه را مطرح کنم که منجر به ایجاد بدهی فنی برای تیم توسعه می شود.تیم توسعه به معنای تیمی متشکل از دولوپرها و یا توسعه دهنده هاست که خودکفا و خود سازمانده (cross-functional and self-organizing) می باشد. اما توسعه دهنده کیست؟ آیا هر کسی را که به توسعه نرم افزار کمک می کند نمی تواند شامل شود؟ برنامه نویس ، آنالیزور، dba، طراح UI، نویسنده محتوا و تحلیلگر کسب و کار؟ حالا به تیم خود نگاه کنید. آیا خودکفا است؟ بله، به دلیل این که شما تکنسین هایی برای همه مهارت ها دارید، اما آیا این تکنسین ها توسعه دهنده هستند؟ شاید نه. آنها فقط برنامه نویس، تستر، dba و طراحان UI هستند و منتظر کارهای مربوط به مهارت خود هستند. آنها به عنوان توسعه دهنده هایی که قصد توسعه نرم افزار را دارند کار نمی کنند، اما بر اساس مهارت های خود وظایف خود را انجام می دهند.موارد کلیدی که به شما در درک ویژگی های تیم توسعه کمک خواهد کرد.فرض کنید L&D (گروه یادگیری و توسعه) در حال برگزاری چند آموزش مانند موارد زیر است.اعلامیه اول “ما قصد داریم یک کارگاه آموزشی برای دولوپر اسکرام داشته باشیم ، بنابراین تمایل خود را برای شرکت در آن به ما اعلام کنید.” خواهید فهمید که فقط برنامه نویسان در این کارگاه شرکت کرده اند.اطلاعیه دیگر “ما در حال برگزاری کارگاه تست اجایل هستیم، بنابراین تمایل خود را برای شرکت در آن به ما ارسال کنید.” این بار فقط تسترها مشارکت می کنند. همین اتفاق در مورد تجزیه و تحلیل کسب و کار Agile و آموزش UI / UX نیز رخ می دهد.چه چیزی در بالا منعکس می شود؟ این تیم هنوز بر اساس مهارتهای برنامه نویسی، تجزیه و تحلیل، UI / UX و تست تقسیم شده است. تستر احساس می کند هر چیزی مربوط به تست در حوزه مسئولیت آنهاست و به همین ترتیب کد نویسان فکر می کنند تمام کارهای کدنویسی بخشی از کار آنها است.“در واقعیت، تست کنندگان برای تست کدهای مرحله تولید کد می نویسند و کدنویس ها برای انجام تست های واحد و یکپارچگی کد (unit and integration tests)، تست می نویسند.”بیایید نگاه دیگری داشته باشیمدر طول جلسه برنامه ریزی اسپرینت، تیم اسپرینت بک لاگ زیر را آماده کرده است.چه چیزی برداشت می شود؟ وظایفی وجود دارد، اما آن وظایف مبتنی بر مهارت است و مبتنی بر جزء (component)  نیست. آیا این روشی اشتباه برای ایجاد کارهای فرعی نیست؟ اگر موافق نیستید پس شرایط زیر را بخوانید.فرض کنید الکس (کدنویس) و مارتا (تستر) روی این سه استوری (آیتم های اسپرینت بک لاگ) کار می کنند.الکس قسمت برنامه نویسی استوری اول را در ۲ روز به پایان رساند، و مارتا تست را شروع کرده است، پس الکس بعد از آن چه خواهد کرد؟به احتمال زیاد الکس کار خود را روی قسمت کدنویسی استوری ۲ شروع خواهد کرد. اما آیا این روش درست است؟ چرا الکس نمی تواند کار دیگری را از همان استوری انتخاب کند؟ یا چرا مارتا منتظر بود تا الکس کدنویسی را برای تکمیل تست انجام دهد؟ چرا او نمی تواند با الکس هماهنگ شود تا به صورت موازی تست انجام شده یا حداقل تست API ها را شروع کند؟بسیاری از مردم از من پرسیدند که اگر الکس کار بر روی قسمت برنامه نویسی استوری ۲ را شروع کند چه اشتباهی روی داده است؟ بیایید وضعیت زیر را ببینید.الکس کدنویسی استوری ۱ را به پایان رساند و برنامه نویسی استوری ۲ را شروع کرد. مارتا در استوری ۱ اشکالی پیدا کرده است. او باید چه کند؟ او پیش الکس رفت و می خواست درباره آن بحث کند، اما الکس بسیار شلوغ است و از او خواست که بعداً بیاید.مارتا اکنون چه خواهد کرد؟ به احتمال زیاد، او یک ابزار ردیابی اشکال را باز کرده و اشکال تازه یافته را آنجا وارد می کند. این کار درست است؟ نه ، اما چرا نه؟ من در مورد چالش های ورود به سیستم به طور جداگانه خواهم نوشت، اما در حال حاضر به جنبه های دیگر آن توجه کنید.الکس کدنویسی استوری ۲ را به پایان می رساند و سپس شروع به بررسی اشکالاتی می کند که توسط مارتا ثبت شده است.  او پی می برد که ریشه اصلی پروژه (root) علت بروز برخی مشکلات شده است و برای برطرف کرن آن تغییرات کد فریمورک نیاز است. اما این روی کدی که او تازه برای استوری ۲ تکمیل کرده است نیز تأثیر می گذارد؟الکس چه خواهد کرد؟ اگر او هر آنچه را که برای رفع مشکلات ریشه لازم است تغییر دهد، باعث تولید مجدد و تأخیر در تحویل محصول خواهد شد. گزینه دیگر میانبر برای رفع اشکال است  (patchwork) ، بنابراین نباید روی کد استوری دوم تأثیر بگذارد.اکثر برنامه نویسان امروزی گزینه ۲ را انتخاب می کنند زیرا کدنویس ها نسبت به کد خود بسیار احساساتی هستند (صرفا جنبه شوخی). دلایل مختلفی برای انتخاب گزینه ۲ وجود دارد، اما نتیجه آن “بدهی فنی” خواهد بود.چه چیز دیگری وجود دارد؟برای جلوگیری از چنین سناریویی چه کاری می توانیم انجام دهیم؟اولا کارهای فرعی مانند بالا ایجاد نکنید بجای آن سعی کنید استوری را به اجزاء مشخص (component-based) بشکنید. بهترین کار، ایجاد کارهای فرعی و کوچک نگه داشتن استوری ها نیست. با همکاری هم روی یک استوری کار کنید به جای اینکه مدام از یک استوری به استوری دیگر بروید. تیم باید روی اتمام کارها تمرکز کند و نه صرفاً شروع کار جدید.لینک مقاله اصلی:https://www.scrum.org/resources/blog/are-you-planning-technical-debt-sprint-planningپیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Thu, 03 Sep 2020 11:25:45 +0430 https://virgool.io/@kasratoofani/%D8%B4%D8%B1%D9%88%D8%B9-%D8%A8%D8%A7-%D8%AA%D8%B9%D8%B1%DB%8C%D9%81-%D8%A7%D9%86%D8%AC%D8%A7%D9%85-%D8%B4%D8%AF%D9%87-definition-of-done-dadnotvrksyg شما چطور تعیین می کنید “عاری از نقص” چیست؟ از آنجا که این برای هر محصول متفاوت است و ممکن است با گذشت زمان تغییر کند شما نیاز به تمرکز بر کیفیت و انعکاس کیفیت در “تعریف انجام شده” (Definition of Done) دارید.در نهایت این تیم توسعه شماست که مسئولیت تولید فرآورده های تکمیل شده از نرم افزار را به عهده دارد. فرآورده های تکمیل شده. به معنای واقعی تکمیل شده.تیم توسعه شما باید تصمیم بگیرد که تکمیل شده چیست. آنها باید لیستی از مواردی را تهیه کنند که برای هر فرآورده یا خروجی قابل ارائه نرم افزاری که تولید می کنند صادق باشد. نرم افزار در حال اجرا مختص یک PBI نیست؛ بدون توجه به هر آیتم از بک لاگ محصول در تحویل نهایی اعمال می شود. نه فقط برای هر آیتم از بک لاگ محصول.“فرآورده مورد نظر بدون در نظر گرفتن اینکه آیا مالک محصول (Product Owner) تصمیم به انتشار آن را در بازار داشته باشد یا خیر، باید در شرایط قابل استفاده باشد.“اگر شما حداقل هر ۳۰ روز یک بار نتوانید نرم افزارهای در حال اجرا به بازار ارائه دهید، پس با هرگونه تعریفی شما هنوز در حال اجرای Scrum نیستید. از آنجا که تیم های اسکرام حرفه ای نرم افزاری را تولید می کنند که کار می کند ، توقف کنید، یک نرم افزار را تولید کنید که مطابق با تعریف شما از در حال اجرا (DoD)  باشد و سپس بخش بندی دوره های تکرار (Sprinting) را شروع کنید و مقصود خود را با “کار” مداوم و بر روی حداقل یک قاعده منظم، بررسی و مرور کنید.تعریف انجام شده (DoD) چیست؟شما باید از جایی شروع کنید و بیشتر اوقات ما یک محصول کامل شده و نهایی نداریم. یا به ما یک محصول موجود تحویل داده می شود، یا ما تیمی هستیم که آن را ساخته و به اسکرام سوئیچ می کنیم. از هر کجا که محصول شما سرچشمه گرفته باشد، کد و در نتیجه محصول، در حال حاضر نرم افزار اجرایی نیست. وقتی تعریفی از معنی “در حال اجرا” ندارید چگونه می توانید تعریفی از “تکمیل شده” داشته باشید؟ در نتیجه چه کاری انجام می دهید؟قبل از اینکه یک خط کد را قطع کنید باید تصمیم بگیرید که چه چیزی برای محصول و شرکت شما به معنی “انجام شده” است. قطعا این مفهوم در مورد ساختن سیستم عامل برای دستگاه های تنظیم کننده ضربان قلب با ایجاد یک پورتال تجارت الکترونیک بسیار متفاوت خواهد بود. در اینجا به بیان برخی از ویژگی های DoD می پردازیم:یک چک لیست کوتاه و قابل اندازه گیری – سعی کنید مواردی را در تعریف تکمیل شده (DoD) خود داشته باشید که قابل اندازه گیری باشد، تا بتوانید نتیجه را ترجیحاً به صورت خودکار آزمایش کنید.بازتاب های قابل ارائه – اگرچه ممکن است محصول خود را به بازار ارائه نکرده باشید، (اگرچه ما آن را توصیه می کنیم) شما باید این حق انتخاب را داشته باشید. مالک محصول شما باید بتواند در جلسه Sprint Review اعلام کند: “این عالی است … بیایید آن را منتشر کنیم.”باقی نماندن کارهای متعاقب – برای ارائه محصول شما به بازار نباید دیگر به کارهای دیگری نیاز باشد. هر کار اضافی بدان معنی است که شما در حالت “تکمیل شده” نیستید و برای دوره های تکرار بعدی از ظرفیت مالکان محصولات فاصله می گیرد. در حالت ایده آل ، شما یک فرایند کاملاً خودکار برای تحویل نرم افزار دارید و هرگز برای تحویل از تکرارهای با کارهای مبهم استفاده نکنید.چک لیست کوتاه و قابل اندازه گیری شما که بازتاب های قابل ارائه را در خود جای می دهد و نتیجه کار دیگری برای تحویل کالای شما نیست، لازم است تعریف شود. از دید من بهترین راه برای این کار، داشتن یک جلسه ساده سازی DoD برای تیم Scrum (مالک محصول به اضافه تیم توسعه) است. بدون تعریف Done ما درک نمی کنیم که نرم افزار در حال اجرا چیست و بدون نرم افزار در حال اجرا نمی توانیم تحویل قابل پیش بینی داشته باشیم. مالک محصول شما نمی تواند یک آیتم از بک لاگ محصول را رد کند، فقط به این دلیل که فرآورده کار می کند یا خیر.اولین تعریف من از “انجام شده” (DoD)تعریف شما از “تکمیل شده” بطور جادویی ظاهر نمی شود و نرم افزار شما بطور اتفاقی با این تعریف مطابقت پیدا نمی کند. سازگاری نرم افزار با تعریف خود از کار انجام شده کار سختی است و اگرچه تعریف شما از انجام شده باید به صورت ارگانیک رشد کند، اما ابتدا باید دانه ای را ایجاد کنید که بتوانید آن را خلق کنید.من توصیه می کنم که یک کارگاه آموزشی را با کل تیم Scrum و احتمالاً برخی دیگر از متخصصین حوزه انجام دهید. اگر مراحل دیگری نیز وجود دارد که نرم افزار شما پس از اتمام کار تیم توسعه باید آن ها را طی کند، برای شرکت در کارگاه به نمایندگان آن مراحل احتیاج دارید. صرف نظر از نوع محصولتان، شما به تخصص های زیر در مورد نمایندگان احتیاج دارید. کد ، تست ، امنیت ، UX ، UI ، معماری و غیره. ممکن است این مهارت را در تیم خود داشته باشید یا شاید لازم باشد یک متخصص از سازمان خود یا حتی خارج از آن برای سازمان خود بیاورید.برخی از نمونه مواردی که می توانید تعریف خود را از تکمیل شده بیان کنید:فرآورده، بررسی های SonarQube (یک سری بررسی های خودکار کدها) را بدون هیچگونه خطای بحرانی با موفقیت می گذراند – کارهای شما به مرور زمان افزایش خواهد یافت، بنابراین شاید نیاز باشد که بگویید “کدها بررسی های SonarQube را با کمتر از ۵۰ خطای بحرانی پشت سر بگذارند” و سپس به مرور زمان روی آن کار کنید.Coverage Coverage Coverage همان حالت باقی می ماند یا بالاتر می رود – نگاه کردن به یک اندازه گیری خاص ، مانند ۹۰٪ ، پوشش کدها شنوایی خوانده شده است و هیچ چیزی از کیفیت کد به شما نمی گوید. با این حال ، ممکن است نظارت و اندازه گیری برای تغییرات منفی در پوشش کد سودمند باشد ، و ما همیشه از شیوه های TDD طرفداری می کنیم.فرآورده مطابق با استانداردهای مهندسی است – شما باید قوانینی را برای نامگذاری متدها، تستها، متغیرها و همه چیز فی ما بین آن ها در نظر بگیرید. در ابتدا با کم شروع کرده و به مرور زمان به آن اضافه کنید. استانداردهای توافق شده خود را در سندی (wiki) به هم ارتباط داده و به طور مداوم قوانین خود را بهبود و گسترش دهید. در صورت امکان این عملیات را خودکار سازی کنید.معیارهای پذیرش برای قبول کردن فرآورده – اطمینان حاصل کردن از اینکه شما به حداقل معیارهای تعیین شده دست یابید، یک هدف قابل ستایش است و خودکار سازی آن ها با روش های ATDD حتی با ارزش تر است.تست های پذیرش برای فرآورده خودکار هستند – اطمینان حاصل کنید که تمام تست های خود را به صورت خودکار انجام می دهید. اگر فکر می کنید چیزی خراب خواهد شد، پس باید آزمایش و بررسی آن را انجام دهید.بررسی های امنیتی روی فرآورده پشت سر گذاشته می شوند – از یک ابزار خودکار به عنوان بخشی از ساختار خود استفاده کنید و آسیب پذیری های امنیتی شناخته شده را بررسی کنید. شما تمام مسائل امنیتی خود را نخواهید یافت، اما حداقل کارهایی نکنید که می دانیم منعکس کننده ضعف امنیتی هستند.فرآورده مطابق با استانداردهای UX توافق شده است – مجدداً یک صفحه wiki داشته باشید و مطمئن شوید که آن را دوبار بررسی کرده اید. اگر از ورودی DoD خودکار استفاده نمی کنید، باید بصورت تیمی موافقت کنید که معیارها را رعایت کرده باشید.فرآورده با اصول معماری توافق شده مطابقت دارد – ویکی برای این کار خارق العاده است، اما آنچه را می توانید خودکار کنید.هرچقدر هم که تعریف Done را خوب و جامع ارائه دهید بعید است که محصول شما در حال حاضر معیارها را برآورده کند. شما هنوز در حال اجرای اسکرام نیستید. قبل از شروع به اسپرینت سازی، باید اطمینان حاصل کنید که پیشرفت فعلی شما با تعریف جدید Done شما مطابقت دارد. روی کیفیت تمرکز کنید ، این همان چیزی است که تیم توسعه مسئولیت آن را بر عهده دارد و مطمئن شوید که پیشرفت شما قبل از شروع کار با آن نوار کیفیت جدید مطابقت دارد. فرآورده بعدی فقط می تواند به کیفیت تمام کارهایی که قبلاً انجام شده اند افزوده شود.یک خروجی قابل اجرا از نرم افزار تولید کنید که مطابق با تعریف شما از “انجام شده” باشد و سپس اسپرینت سازی را شروع کنید. نگه داشتن نرم افزار در وضعیت در حال اجرا، به یک سیستم کنترل منبع مدرن نیاز دارد که امکانات شما را برای اجرای شیوه های خوب DevOps فراهم می کند.تعریفتان از “انجام شده” (DoD) را رشد دهیداین بسیار مهم است که کیفیت همیشه در حال بهبود است و این بدان معناست که شما نیاز دارید که حداقل در یک تعریف منظم روی Definition of Done تأمل کنید. در اسکرام، این ریتم توسط طول اسپرینت شما تعریف می شود و شما یک لحظه Kaizen در Sprint Retrospective  دارید. این بدان معنی نیست که شما همیشه در مورد DoD خود تأمل نمی کنید، شما به طور مداوم تأمل می کنید که آیا میزان درآمد شما در حال حاضر با DoD شما مطابقت دارد و یا اینکه برای رسیدن به آنجا چه کارهایی باید انجام دهید. شما همیشه باید در مورد اینکه آیا DoD شما متناسب با نیازهای شما هست، تأمل کنید. اگر تیم توسعه شما می داند که چیزی از DoD در نیمه راه اسپرینت وجود دارد ، آنها باید رو به جلو حرکت کنند و آن را اضافه کنند. مطمئن شوید که آنها هدف اسپرینت (Sprint Goal) را به خطر نمی اندازند.شما ممکن است به این نتیجه برسید که همانطور که دیوید کوربان در پست قبلی من خاطرنشان کرد، با محصول خود مشکل عملکردی دارید. چگونه مطمئن شویم که این مسئله را حل کردیم؟ از دیدگاه من شما ۲ راه پیش روی اسپرینت جاری دارید. شکست را بپذیرید (به دلیل کیفیت پایین، اسپرینت را متوقف کنید) ، و مشکل را برطرف کنید، یا می توانید این دانش جدید را در چرخه محصول خود ادغام کنید.اگر این یک مسئله مهم است که منجر به عدم وجود نرم افزار در حال اجرا می شود، باید متوقف و رفع شود. در اسکرام این کار را غرق شدن (Scrumble) می نامند، به عنوان بازتابی از اینکه تیم توسعه متوقف شده است به دلیل اینکه چیزی را از دست داده است. قبل از ادامه اسپرینت سازی و اضافه کردن ویژگی های جدید، ابتدا باید نرم افزار در حال اجرا خلق کنید. پس از برطرف کردن مسئله، می توانید Definition of Done را بهبود دهید تا مطمئن شوید که تمام فرآورده های آینده نیازمندی های جدید را برآورده می کنند.اگر این از اهمیت کمتری برخوردار باشد ممکن است بخواهید کار خود را ادامه دهید و آنچه را که لازم دارید به بقیه محصول خود اضافه کنید. سپس می توانید چندین اسپرینت بعدی را بهبود بخشیده و مشکل شناسایی شده را برطرف کنید. پس از حل آن می توانید نتیجه را با اضافه کردن بخش جدیدی به DoD خود متصل کنید.همیشه به دنبال راه هایی باشید که بتوانید کیفیت خود را بهبود ببخشید. امروز تعریف شما از “ تکمیل شده ” یا DoD چیست؟لینک مقاله اصلی:https://www.scrum.org/resources/blog/getting-started-definition-done-dodپیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Sat, 22 Aug 2020 19:33:08 +0430 https://virgool.io/@kasratoofani/%DA%86%D8%B1%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%B4%D9%85%D8%A7-%DA%A9%D8%A7%D8%B1%D8%A2%D9%85%D8%AF-%D9%86%DB%8C%D8%B3%D8%AA-%D8%A7%D8%B2-%D8%AF%DB%8C%D8%AF-%D8%AA%DB%8C%D9%85-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-riq93omr9z0o بسیاری از تیم ها و سازمان ها برای به دست آوردن بهترین استفاده از اسکرام تلاش می کنند. در مقاله دیگری با عنوان " اجایل را به خاطر مشکلات موجود سرزنش نکنید" من این تحلیل را به اشتراک گذاشتم که چرا اجایل یا اسکرام غالباً مقصر شناخته می شوند. در این مقاله به متداول ترین اشتباهات اسکرام که منجر به عملکرد نامناسب و عدم بهره گیری کارآمد از اسکرام می شود خواهیم پرداخت. این بار از منظر تیم توسعه به موضوع نگاه خواهیم کرد.نقش های اسکرام و مسئولیت های مرتبطبا گذشت سالها یاد گرفته ام و تجربه کرده ام که اکثر علائم مشکلات را می توان به دلیل عدم رعایت مسئولیت های نقش های اسکرام دانست. به همین دلیل این موضوع را در سه پست جداگانه تقسیم کرده ام:مالک محصولتیم توسعهاسکرام مسترهر مقاله از نقشی که تحت پوشش قرار می دهد موضوع را بررسی میکند. منشاء بسیاری از اختلاف ها را از چگونگی بکارگیری اسکرام (که به آن "اسکرام حرفه ای" گفته می شود) و چگونگی تمرین و سوء تفاهم ها و برداشت های اشتباه، کشف می کنم. این مقالات بر اساس تجربه شخصی من است که در هنگام تمرین نقش های تیم توسعه (عضو)، مالک محصول و اسکرام مستر کسب کرده ام و یا در مثال های تکراری که دانش آموزانم در دوره های Scrum.org به آنها اشاره می کنند.تیم توسعهتیم حرفه ای توسعه اسکرامتیم حرفه ای توسعه اسکرام گروهی از متخصصان تمام وقت است که با هدف دستیابی به یک هدف خاص - هدف اسپرینت -  می توانند محصول بالقوه قابل انتشار را ایجاد کنند. آنها این کار را هر اسپرینت (1 ماه یا کمتر) انجام می دهند. با تبدیل آیتم های Product Backlog به یک محصول کارآمد، مرتباً ریسک را کاهش می دهند:ریسک فنی: آیا واقعا کار می کند؟ و آیا با موفقیت با فرآورده قبلی محصول ادغام می شود؟ریسک تجاری: آیا واقعا یک مشکل کاربر نهایی حل می شود؟ آیا این فرآورده یک نیاز را بطور هدفمند برآورده می کند؟در نتیجه ، تیم توسعه نه تنها ارزش ارائه می دهد بلکه چابکی تیم اسکرام را نیز ممکن می کند. برای حراست از این، تیم توسعه مفهوم "انجام شده" را که آنها همیشه به آن تعهد دارند، توسعه داده و پیاده سازی می کند. این مفهوم آنچه را که تیم توسعه برای نگه داشتن محصول در حالت قابل انتشار انجام می دهد را بیان می کند. تیم توسعه مسئول فرآورده است و در نتیجه آنها مسئولیت کیفیت فرآورده را بر عهده دارند.فراوظیفه ای و خود سازمانده (cross-functional، self-organizing)تیم توسعه یک تیم کارآمد است. این بدان معناست که آنها تمام مهارتهایی را که برای ارائه یک فرآورده بالقوه قابل انتشار در هر اسپرینت لازم است، دارند و یک تیم خود سازمان دهنده هستند. هیچ کس به تیم توسعه نمی گوید که چگونه کار را انجام دهد. ما برای انجام کارها به آنها اعتماد داریم. براساس هدف اسپرینت که تیم اسکرام در حین برنامه ریزی اسپرینت فعالیت می کند، تیم توسعه به طور مرتب پیشرفت و برنامه خود را برای دستیابی به هدف اسپرینت بررسی و تنظیم می کند (بک لاگ اسپرینت). هنگامی که بینش های جدید نمایان می شوند، احتمالاً Sprint Backlog در سراسر اسپرینت تغییر می کند. تیم توسعه مالک Sprint Backlog است و تنها کسی است که می تواند آن را تغییر دهد. حداقل در هر جلسه اسکرام روزانه (Daily Scrum) آنها فرآورده خود را به سمت هدف اسپرینت بررسی کرده و برای مدت 24 ساعت آینده برنامه ریزی می کنند.در عین حال، خود سازماندهی متضمن این است که آنها چالش های خود را، چه مربوط به مسائل فنی و چه محصول، و همچنین بین فردی / همکاری مرتبط با خود حل می کنند. با این حال، اسکرام مستر به آنها کمک می کند تا توانایی های خود را برای حل این چالش ها به شیوه ای مؤثر توسعه دهند.همکاری مشتری و پالایش بک لاگ محصولتیم توسعه از نزدیک با کاربران نهایی همکاری می کند تا نیازهای آنها و آنچه که برای آنها با ارزش است را بهتر بشناسد و همراه با مالک محصول، بطور مداوم باقیمانده کارهای تولید و توسعه محصول را پالایش می کنند تا جزئیات کافی را ثبت کنند. در همان زمان آنها در تلاشند تا موارد "آماده" بک لاگ محصول را در بالای بقیه آیتم های لیست بک لاگ قرار دهند. به عبارت دیگر، تیم توسعه این موارد را تا حدی کوچک و شفاف می کند تا بتواند این آیتم ها را به یک فرآورده بالقوه قابل انتشار در محدوده زمانی اسپرینت تبدیل کنند.چرا ممکن است برای شما کار نکندتفاسیر غلط توسط سازمانسازمان شما ممکن است کمی انتظارات متفاوت داشته باشد ، مانند:فقط وظایفی را که تعریف کردیم انجام دهید. شما دست هستید، نه مغز.سرعت مشخصه خوبی برای سنجش عملکرد تیم توسعه است.اگر نیاز داریم که سریعتر کار خود را انجام دهیم، ساده ترین راه این است که باید سخت تر کار کنید.مالک محصول می تواند با بالا بردن سرعت، کیفیت را هم افزایش دهد.اگر درخواست آخرین لحظه ای داشته باشیم می توانیم آن را هر طور شده در اسپرینت قرار دهیم.اگر تیم توسعه فرا وظیفه ای(cross-functional) نباشد، اشکالی ندارد. آنها می توانند با همکاری سایر بخش ها هرگونه شکاف ممکن را پر کنند.از آنجایی که تیم توسعه خود سازمانده است ما باید آنها را از نزدیک کنترل کرده و تحت نظر داشته باشیم. در غیر این صورت منجر به هرج و مرج خواهد شد.خوشبختانه ما اسکرام مستر و مالک محصول را داریم تا از نزدیک آنها را مدیریت کنیم.ما باید مشتریان و کاربران نهایی را از تیم توسعه دور نگه داریم تا آنها بتوانند زمان بیشتری را در تولید محصول صرف کنند.اگر ما مشتریان خود را بیشتر و حتی در حین توسعه درگیر کنیم، آنان این احساس را پیدا می کنند که ناتوان هستیم و قادر به فهمیدن پیشاپیش نیازهای آنها نیستیم.مشتریان ما اغلب نمی خواهند که آزاد باشیم.تفاسیر غلط توسط تیم توسعهیا شاید شما - به عنوان عضو تیم توسعه - درک متفاوتی از نقش تیم توسعه داشته باشید ، مانند:من فقط باید روی کارهای خودم در اسپرینت تمرکز کنم.مهمترین چیز این است که من بهره ور هستم.همکاری با هم منجر به پایین آمدن راندمان ما می شود و این یعنی اتلاف.اگر نتوانم کار خودم را تمام کنم از آنجایی که کار من به دیگران بستگی دارد، مشکل من نیست.کار با کاربران نهایی مرا از انجام کار خود دور می کند.اگر تمام کارهایی را که در طول برنامه ریزی اسپرینت مشخص شده بود به پایان برسانیم، برابر با یک اسپرینت موفق است.مالک محصول باید کلیه الزامات را با جزئیات توصیف کند تا در حین اسپرینت هیچ گونه ابهامی وجود نداشته باشد.اگر در تیم توسعه مشکلی داریم، اسکرام مسترها آن را پیگیری خواهند کرد.در حقیقت، ما می توانیم تمام مواردی را که ما را از انجام کار خود منحرف می کند به اسکرام مستر ارجاع دهیم.اگر شرایط پیش بینی نشده ای وجود داشته باشد، باید از مالک محصول بخواهیم تصمیم بگیرد.اگر صاحب محصول به ما گفت که کارهای اضافی را انجام دهیم، مجاز هستیم که کیفیت را قربانی کنیم تا آن کار انجام شود.مادامی که همه جوانب عملکردی را از اسپرینت بک لاگ خود پوشش دهیم، اشکالی ندارد که نتوانیم تمام کارها را بر اساس "تعریف انجام شده" لحاظ کنیم. می توانیم کار باقی مانده را در اسپرینت بعدی به پایان برسانیم.کلیه ارتباطات با ذینفعان باید از طریق مالک محصول انجام شود.ما فقط در طول جلسه بررسی اسپرینت مالک محصول را در مورد اسپرینت مطلع خواهیم کرد.اگر همه کارهایمان از اسپرینت را در انتهای اسپرینت ادغام کنیم، به اندازه کافی خوب است.شما چه کاری برای این موضوع می توانید انجام دهیدمستمرا آنچه را که از یک تیم توسعه حرفه ای اسکرام انتظار دارید را بررسی کنید. به عنوان مثال با شرکت در یک دوره تخصصی مبانی حرفه ای اسکرام یا توسعه دهنده حرفه ای اسکرام، مطالعه کتاب "Scrum - a Pocket Guide" و بررسی مجدد کتاب "راهنمای اسکرام". علاوه بر این، در مورد نحوه تمرین نقشها در اسکرام کارآمد در این لحظه تأمل کنید. فقط در این صورت می توانید اختلافات را تشخیص دهید و در نتیجه می توانید بفهمید که چه کاری می توانید انجام دهید تا آن را به نحوی بهتر تغییر دهید. اسکرام مسترهای شما می توانند در اینجا به شما کمک کنند.لینک مقاله اصلی:https://www.scrum.org/resources/blog/development-team-why-your-scrum-doesnt-work-23پیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Mon, 10 Aug 2020 19:05:43 +0430 https://virgool.io/@kasratoofani/%D8%AA%D9%82%D8%A7%D8%B6%D8%A7%DB%8C-%D8%AF%D9%88%D8%A7%D9%BE%D8%B3-hm0pzdyorinq برای داشتن دید بهتر نسبت به درک و دانش مردم در مورد یک مسئله، کافیست به شبکه های اجتماعی رجوع کنید.این پیام از سوی یک شرکت برای جذب یک رهبر دواپس من را در مورد درک و فهم بازار در مورد دواپس به فکر فرو برد.اما آیا واقعا دواپس با چنین نقشی در سازمان دیده می شود؟ در ابتدا، دواپس چیست؟تعریف دواپسدر کتابخانه ویکی پدیا این چنین تعریف شده است:” حرکتی فرهنگی و حرفه ای که بر ارتباطات، همکاری و ادغام های بین توسعه دهندگان نرم افزار و متخصصان عملیات IT در زمان خودکار سازی فرآیند تحویل نرم افزار و تغییرات زیرساختی تأکید می کند.”اساساً درک و تفسیر من از دواپس اینگونه است:روشی که با هدف ایجاد همدلی متقابل بین دو گروه انجام می شود. تیم توسعه (Development) و تیم عملیات (Operations) که اهدافی دارند که مقابل یکدیگر قرار می گیرند. بنابراین دواپس امکان تحقق اهداف خاص برای هر گروه را در عین احترام به مسئولیت های گروه دیگر فراهم می آورد.من در اینجا ۲ تیم را ذکر کرده ام که در حالت ایده آل باید یک تیم باشند اما متاسفانه بر اساس تجربیات گذشته و حتی امروزه ۲ گروه مجزا هستند که اهداف مشترکی ندارند. هدف یکی از آنها تحویل هرچه سریعتر ارزش تجاری است در حالی که در مورد دیگری داشتن پایدارترین زیرساخت ممکن است.باید بگوییم برای به کار گرفتن دواپس دو چیز مورد نیاز است. اول یک چارچوب که فرآیند تحویل ارزش تجاری را ساختار دهد و سازمان دهی کند، برای مثال اسکرام یا کانبان. رویکرد اجایل انتخاب شده، به سازمان ها و تیم های توسعه امکان می دهد تا در هر چرخه تکرار (iteration) و حتی هر روز یک ارزش گرانبها تولید کنند.دوم، لازم است مجموعه ای از ابزارهای خودکار وجود داشته باشد که به Ops و Dev اجازه می دهد ضمن احترام به اهداف و مسئولیتهای هر گروه ، میزان تحویل ارزش تجاری سازمان را نیز رعایت کنند.نقش اسکرام یا کانبان در دواپسبرای به حداکثر رساندن شانس اجرای یک عملیات دواپس در یک سازمان ، ضروری است که این دو معیار اساسی وجود داشته باشند: یک چارچوب و مجموعه ای از ابزارهای مرتبط برای سازماندهی فرآیند تحویل ارزش تجاری. اگر تمایل به اجرای دواپس صرفاً از سوی تیم IT  باشد ، سازمان با پرداخت هزینه بدون ایجاد ارزش واقعی، قادر نخواهد بود ابتکار را دنبال کند و نتایج آن را ببیند. اگر تمایل صرفا از سوی سازمان باشد و تیم IT دانش و ابزار لازم را نداشته باشد ، اجرای این تمرین فشار زیادی را به سازمان وارد می کند و موفقیت های مورد انتظار را در پی نخواهد داشت.بنابراین اولین مرحله برای ایجاد چارچوبی برای ساختار دهی و هدایت گردش کار برای ایجاد ارزش، به عنوان نمونه Scrum یا Kanban است. این سازمان با استفاده خوب از Scrum یا Kanban قادر به پشتیبانی از تحویل مکرر یا حتی روزانه نیاز مشتری از تحقق تا تحویل آن خواهد بود.از طرف دیگر ، برای اینکه بتوانید یک عملیات دواپس را پیاده سازی کنید لازم است که فرایند تحویل ارزش تجاری درون سازمان به مرحله خاصی از بلوغ رسیده باشد.منظور من از این مسئله این است که معمولاً وقتی یک سازمان تصمیم می گیرد مباحث اجایل را با استفاده از Scrum یا Kanban بکار گیرد، استفاده از چارچوب فقط به تیم توسعه متصل می شود. با بلوغ روزافزون تیم Agile ، تیم با لحاظ کردن هر دو جنبه بازاریابی و عملیات تولید و توسعه، دسترسی به چابکی را گسترش می دهد.جعبه ابزار لازمبه همین دلیل ضروری است که تیمها برای دستیابی به این اهداف یک جعبه ابزار داشته باشند که شامل تمام ابزارها باشد. معمولاً برای هر یک از دسته های زیر نیاز به یک یا چند ابزار وجود دارد:کنترل نسخه و مخازن مرتبط (Version control and repositories)ادغام مداوم / تحویل مداومکنترل کیفیتابزار تست خودکار  (از جمله آنالیزورهای کدهای استاتیک / چارچوب های تست خودکار)ابزار تست عملکردابزارهای انتشار / استقرار خودکارزیرساخت بر پایه کد: مدیریت پیکربندی تعریف شده توسط نرم افزارفناوری های مجازی سازی و کانتینر سازیاگر بخواهم به ابتدای مقاله برگردم و به پست لینکدین شرکتی که به دنبال رهبر دواپس بود بپردازم، به این نتیجه می رسیم که ممکن نیست فقط یک نفر یا حتی یک گروه مسئولیت پیاده سازی و رهبری دواپس را بر عهده بگیرد. بنابراین اگر می خواهید یک دواپس عملی را در سازمان خود ایجاد کنید ، اطمینان حاصل کنید که هم معیارهای اساسی را در کار خود داشته باشید و هم به جای یک تیم یا یک شخص، کل سازمان را پرورش داده و توانمند کنید.لینک مقاله اصلیپیج لینکدینپیج اینستاگرامپروفایل در scrum.org کسری طوفانی | Kasra Toofani کسری طوفانی | Kasra Toofani Wed, 29 Jul 2020 17:55:38 +0430