https://virgool.io/IranAgile/feed انجمن چابک ایران fa 2026-06-16 13:30:10 https://files.virgool.io/upload/publication/id6weoihwzd8/gnm7wf.png https://virgool.io/IranAgile https://virgool.io/IranAgile/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-%D8%A8%D9%86%D9%88%DB%8C%D8%B3%DB%8C%D9%85-%D9%85%D8%AB%D8%A7%D9%84-%D8%A7%D8%B2-%D8%AA%D9%88%D8%B1%D9%85-%DA%A9%D8%B4%D9%88%D8%B1-rbalqrunxea7 یک دوستی از من خواست که داستان‌های کاربری که نوشته بود را بررسی کنم، دیدم همه چیز را در قالب معروف User Story نوشته، و بیشتر از کارکرد و نیت اصلی داستان کاربر، فقط حواسش به قالب آن بوده است. بیشتر در قید فرم بوده تا محتوا. داستان کاربر یک مفهوم خیلی ساده است، که ما کار را از منظر و چشم کاربر نگاه کرده و در تلاشیم تا نیاز اساسی او را رفع نماییم. یک قالب ساده نیز مانند نمونه زیر دارد. اما در عین سادگی، بسیاری از دوستان در استفاده از همین مفهوم اشتباه می کنند. بعنوان ___________(کاربر/مشتری/پرسونا)میخواهم ______________ (یک قابلیت/امکان/فیچر)تا بتوانم ________________ (نیاز/دلیل/برآیند مورد انتظار) در همین راستا، خواستم مفهوم واقعی داستان کاربر یا همان User Story را به او توضیح بدهم، دیدم ذهنش کلا درگیر تورم و وضعیت اقتصادی کشور هست، گفتم شاید بد نباشد که از همین به عنوان مثال واقعی استفاده کنیم. از او پرسیدم "به نظرت مردم چرا می ریزن ماشین، دلار، سکه و ... ثبت نام می کنند؟" جواب داد: "با این بی ارزش شدن پول، نگران هستند خوب..." گفتم: "پس داستان این کاربر ما با همان فرمتی که خودت نوشتی، چی میشه؟"بعنوان کسی که نگران ارزش پولش هست (پرسونا)من دلار میخرم (چیزی که میخواهد یا انجام میدهد)تا بتوانم ارزش موجودی خودم را حفظ کنم و فقیرتر نشوم (دلیل و چرایی یا برآیندی که دنبالش هست)حالا فرض کنید، دولت مثل تیم های فنی، به نیاز کاربر اهمیتی نمی‌دهد، و امور را از نگاه خودشان بررسی می‌کنند (تیم های فنی به همه امور فنی نگاه می کنند). در همین مثال، بانک مرکزی، یک نیازمندی تعریف می‌کند، بعنوان بانک مرکزیما خرید و فروش دلار رو محدود به 2000 دلار در سال می کنیمتا بتوانیم بازار ارز را کنترل کنیمدقیقا قالب داستان کاربر رعایت شده، اما به نیاز کاربر اصلی توجهی نشده و بیشتر به خودشان پرداخته اند، مثل اینکه تیم دیتابیس، نگران حجم دیتابیس است و برای همین اجازه نمی‌دهد که رکورد جدیدی ثبت شود. در مثال خودمان، این محدودیت باعث خواهد شد که کاربران ما دست به اقدام دیگری بزنند:بعنوان کسی که نگران ارزش پولش هست (پرسونا)من طلا و سکه میخرم (چیزی که میخواهد یا انجام میدهد)تا بتوانم ارزش موجودی خودم را حفظ کنم و فقیرتر نشوم (دلیل و چرایی یا برآیندی که دنبالش هست)اگر توجه کنید، نیاز همان است، ولی اقدام تغییر پیدا کرد. اگر طلا و سکه مسدود شود، چون نیاز هنوز برطرف نشده، شاهد اقدامات دیگر خواهیم بود.عدم درک درست نیاز و مشکل مشتری باعث خواهد شد تا تصمیم های ما اشتباه باشند، مثلا در یک جلسه بگوییم، بعنوان سیستم حاکمیتیمی‌خواهیم بر عایدی درآمد مالیات تعیین کنیم تا با سود جویان و دلالان مقابله کنیم (اینکه مالیات اصلا بد نیست، ولی آیا همه دلال هستند) در واقع، از داده های موجود برداشت اشتباه انجام داده ایم، کار مدیر محصول تشخیص نیاز اصلی است. آیا عمده مردمی که طلا/دلار/ و ... می خرند دنبال یک شب پولدار شدن و دلالی هستند یا حفظ ارزش دارایی؟ تشخیص این کار مدیر محصول است. تا زمانی که ما نیاز اصلی کاربر یا مشتری را درست تشخیص ندهیم، اقدامات یا قابلیت هایی که ارائه می‌کنیم، اثر بخش نخواهند بود. حالا چه در قالب "بعنوان ___ می خواهم ___ تا بتوانم___" بنویسم یا Use Case یا هر اسم دیگری، کاربران با همان روش هایی که بلد هستند کار خود را به پیش خواهند برد و آن قابلیت و اقدام ما بی استفاده خواهد ماند. از کجا مشکل یا نیاز واقعی را کشف کنم؟واقعیت این است که ما علاقه داریم، در اتاق خود بنشینیم و با فرضیات خودمان شروع کنیم به طراحی راه‌حل. اما برای درک مسئله، ما باید وارد فضای مسئله بشویم و فضای مسئله جایی نیست جز کف بازار. نمی‌شود، در اتاق های خودمان باشیم، با صاحب مسئله صحبت نکنیم و با دردهای او همدلی نکرده باشیم و فرض کنیم مشکل را درک کردیم، به همه بگوییم دلال و سفته باز و بر اساس آن راه حل طراحی کنیم. در این مسیر نیز ما امکان دارد با خطاهای شناختی مواجه بشویم، مثلا پخش یک ویدئو در فضای مجازی، اینکه مردم هجوم آوردن تا دلار بخرند، شاید ما را با این خطا مواجه کند که همه اینگونه هستند(تعمیم دادن یا Over-generalization) یعنی با یک دیتای کم نتیجه گیری کنیم. یا صرفا دنبای داده هایی بگردیم که فرضیات ما را تایید کنند(خطای میل به تایید (Confirmation Bias))، دیدی گفتم مردم همه دلال شدند.نصف بیشتر داستان کاربر، درست دیدن، همدلی کردن، فهمیدن، و تعریف کردن نیاز و مسئله کاربر است. اگر این را درست تعریف کنیم، راه حل پدیدار خواهد شد. پس، لطفا در بند قالب و تمپلیت گیر نکنیم و به درد و نیاز اصلی در فضای مسئله باشیم.مثال دیگری از داستان کاربر در فضای توسعه نرم افزارچابک و موفق باشیداسد صفری انجمن چابک ایران اسد صفری Fri, 24 Jul 2020 19:39:27 +0430 https://virgool.io/IranAgile/%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D9%85%D8%B3%D8%AA%D8%B1-%D8%A8%D8%A7%D9%87%D9%88%D8%B4-%D9%86%D8%A7%D8%A7%D9%85%DB%8C%D8%AF-%D9%86%D9%85%DB%8C-%D8%B4%D9%88%D8%AF-czivxlehuhm5 اینترنت شرکت به شدت مشکل داشت و دائم قطع و وصل میشد، یا کلا کند بود، در این لحظات اکثر بچه ها به مشکل میخوردند، یا حتی باید دست از کار می کشیدند. در جلسات رترو انتهای اسپرینت چند بار این بعنوان مانع مطرح شد.من بعنوان نماینده تیم، این رو چندین بار با شرکت و مدیران مطرح کردم، ولی ترتیب اثری داده نشد، و موضوع چندین اسپرینت ادامه داشت.حس کردم مدیران نسبت به اتلاف و هزینه این اتلاف آگاهی ندارند، و تصمیم گرفتم این اتلاف را تابلو یا بصری سازی کنم.در ابتدای اسپرینت، از همه بچه در خواست کردم، تعداد دقایقی بخاطر نبودن اینترنت بلاک می شوند، را لاگ بزنند. در انتهای اسپرینت این لاگ ها رو جمع کردم، بعد تبدیل به پول کردم. متوسط حقوق ساعتی ضربدر میزان جمع ساعت تلف شده.مثلا در اسپرینت 13 شد 8000 دلار، بعد رفتم یک سایت فروش خودرو دست دوم و ماشین های 8000 دلاری جستجو کردم و یکی رو انتخاب کردم.عکس ماشین رو پرینت کردم و زیرش زدم، “این اسپرینت ما این ماشین رو آتیش زدیم :cry:” و این رو بر روی تابلوی اسپرینت تیم چسباندیم.هر زمانی که مدیری میخواست از تیم ما بازدید کنه، با دیداین عکس ها بسیار تعجب میکرد و دقیقا از همان اسپرینت ها، کم کم، مشکل سرعت اینترنت بهتر شد.شاید خیلی وقت ها به این برمیخوریم: افراد غر میزنند که شرکت و مدیران به فلان درخواست یا مشکل ما اهمیت نمی دهد، اما برخی مواقع با یک تکنیک درست بصری سازی یا تابلو کردن اتلاف یا مشکل، شما می توانید در آنها آگاهی ایجاد کنید. و آگاهی نصف حل کردن مشکل هست.منبعاین نوشته قبلا در وبلاگ دنیای چابک نیز منتشر شده بود. انجمن چابک ایران اسد صفری Tue, 21 Jul 2020 15:27:27 +0430 https://virgool.io/IranAgile/%DA%86%D8%B1%D8%A7-%DA%AF%D9%88%DA%AF%D9%84-%DB%8C%D8%A7-%D8%B4%D8%B1%DA%A9%D8%AA%D9%87%D8%A7%DB%8C-%D9%85%D8%B4%D8%A7%D8%A8%D9%87-%D8%A7%D8%B2-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D9%86%D9%85%DB%8C%DA%A9%D9%86%D9%86%D8%AF-%D9%88%D9%84%DB%8C-%D9%87%D9%85%DA%86%D9%86%D8%A7%D9%86-%D9%85%D9%88%D9%81%D9%82-%D9%87%D8%B3%D8%AA%D9%86%D8%AF-tfvgvdsaenms با یکی از دوستان در مورد چابک و اسکرام صحبت می‌کردیم، سوال پرسید چرا هیچ وقت نمی‌شنویم که شرکتهایی مثبت گوگل یا نتفلیکس از اسکرام استفاده کنند، یا حتی اگر استفاده کنند اصلا اصراری بر روی آن ندارند. (برعکس شرکتهایی کوچک که در تمامی آگهی استخدام تاکید دارند، آشنایی با اسکرام و … )به نظرم رسید که این سوال خوبی هست و جوابش می‌تونست برای همه جذاب باشه. برای همین تصمیم گرفتم نوشته کوچکی در این خصوص بنویسم.در کتاب اسپرینت، آقای جیک نپ (کارمند اسبق گوگل) یک جمله جالب در مورد گوگل دارد: “گوگل، آزمودن را ترغیب می‌کند، آزمودن نه تنها در مورد خود محصول، بلکه در زمینه روش‌های به کار رفته توسط افراد و تیم‌ها”وقتی تصویر یک کارمند از یک شرکت “دعوت به آزمودن باشد”، یعنی در مورد فرهنگ غالب آنجا صحبت می‌کند. یک سوال اساسی، آیا نهایت چابک بودن و هدف از اسکرام مگر همین نیست؟ در واقع اگر ما خوب بتوانیم فرهنگ چابک را جا بیندازیم، به چنین دستاوردی خواهیم رسید.سوال دوم، پس چرا ما مانند گوگل ابتدا به دنبال فرهنگ یا تغییر شیوه فکری حرکت نکنیم؟یک نقل قول از آقای باکمینستر فولر هست با مضمون، “اگر می‌خواهید به مردم روش جدیدی برای اندیشیدن بیاموزید، لازم نیست زحمت آموزش دادن آن را متحمل شوید. در عوض، به آنها ابزاری بدهید که استفاده از آن، به استفاده از روش جدید اندیشیدن منجر شود.”در واقع، اسکرام ابزاری برای تمرین تفکر چابک هست، که مبتنی بر آن تفکر طراحی شده است. بودن نقشی مثل اسکرام مستر نیز برای تضمین این هست که آیا ما صرفا یک ابزار داریم، یا ابزاری داریم که به قول آقای فولر،استفاده از آن، به استفاده از روش جدید اندیشیدن منجر می‌شود.اما چرا شرکت‌های مثل گوگل از این ابزار برای این تمرین استفاده نمی‌کنند؟وقتی شالوده و بنیان یک شرکت بر اساس این تفکر بنا نهاده شده باشد، خود این بهترین ابزار است و ناخودآگاه تمام اقدامات بر اساس این فلسفه اجرا خواهد شد.پس در واقع با اینکه فقط تکرار کنیم که تفکر جدید باید ایجاد شود، کاری از پیش نخواهد رفت، آموزش، نصحیت، سخنرانی، تاثیر چندانی نخواهد داشت. ابزارهایی لازم داریم که بر اساس این تفکر طراحی شده باشند و ما این تفکر را روزانه تجربه کنیم. اما شرکت‌هایی که تفکر در آن نهادینه شده باشد، دیگر نباید نگران ابزار باشند.ما سالها اسکرام استفاده کردیم ولی خبری از تفکر چابک نیست؟شاید تعدادی دوستان در اعتراض به نوشته بیان کنند، که ما سالها درگیر اسکرام بودیم و خبری از تفکر چابک نبود. دو نکته اساسی هست، یک اینکه، تنها ابزار شما برای تمرین تفکر و اندیشه چابک نباید صرفا اسکرام باشد، نکته دوم، وجود نقشی مانند اسکرام مستر یا مربی چابک، برای این هست که ابزار مناسب را برای تیم خود بر اساس کانتکست مربوطه پیدا کرده یا حتی آن را بسازند. متاسفانه بسیاری از اسکرام مسترهای ما بدلیل تجربه کم خودشان یا شرایط شرکت، صرفا تبدیل شدن به منشی یا کنترل پروژه، و توجهی به ابزاری فکر و تمرین تفکر چابک ندارند یا صرفا دست به دامن آموزش یا نصحیت کردن می شوند که از سوی اعضای تیم همه اینها تئوری تلقی خواهد شد یا اینجا بدرد نمی‌خورد.برای مثال، با یک تیمی برای مدت محدودی کار می‌کردم، بارها مدل پیچیدگی، و عدم قطعیت را توضیح داده بودم، ولی همچنان در جلسات برنامه ریزی بدنبال تخمین زدن با قطعیت بالا بودند. من هر چقدر تلاش کردم که با گفتن مفهوم را منتقل کنم، ناموفق بود. در حرف همه قبول داشتند ولی در مقام عمل، کار دیگری می کردند. مجبور شدم ابزارهایی مثل تابلوی تخمین و ابزار برنامه ریزی بر اساس پیچیدگی را خلق کنم. کار با این ابزارها باعث شده بود، تیم درک عملی نسبت به تفکر پیچیدگی و عدم قطعیت داشته باشند.تجربه شما در ساخت یا استفاده از ابزارها برای ایجاد تفکر چابک، چه بوده است؟چابک و موفق باشیداسد صفریاین نوشته قبلا در وبلاگ دنیای چابک نیز منتشر شده است. انجمن چابک ایران اسد صفری Mon, 22 Jun 2020 09:43:14 +0430 https://virgool.io/IranAgile/%D8%AF%D9%88-%D8%B1%D9%88%D8%B4-%D8%A8%D8%B1%D9%88%D9%86-%D8%B3%D9%BE%D8%A7%D8%B1%DB%8C-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-%D8%AF%D8%B1-%D8%B9%D9%85%D9%84-unamm2suskdb در یک ماه اخیر به صورت اتفاقی با دوستان زیر مجموعه بانک مرکزی و یک سری دوستان از اپراتورهای رسمی کشور صحبت می کردم. یکی از چالش هایی که مطرح می کردند همکاری با شرکت هایی است که پروژه‌های نرم افزاری یا مخابراتی به آنها سپرده شده است اما در تعامل و همکاری با چالش های بزرگی مواجه هستند. یکی از چالشها این بود که چگونه ما هم چابک باشیم و هم بتوانیم یک قرارداد به صورت رسمی بین طرفین نوشته شود.در پروژه های چابک به صورت پیش فرض ما پذیرای تغییرات هستیم تا با پاسخگویی به این تغییرات از نوسانات بازار یا رقابت باز نمانیم. اما شرکتی که پروژه برون سپاری شده را پذیرفته است برای خود برنامه دیگری دارد و سود آنها معمولاً جاییست که سریعتر پروژه مذکور را به اتمام برساند و سراغ پروژه های دیگر بروند.پس عملاً یک تضاد منافع بزرگ در اینجا وجود دارد یکی از طرفین به دنبال بستن سریع پروژه است، طرف دیگر بدنبال رفع نیاز خود است، چه نیازهایی که از قبل مشخص شده است و چه نیازهایی که بعدا معلوم می شود. از سوی دیگر ساختار حقوقی شرکتها اجازه نمی‌دهد که قراردهای باز ببندند.همین یک دلیل ساده باعث شکست خوردن اکثریت پروژه های برون سپاری شده است. برای حل این مشکل اکثر شرکت ها متوسل به قراردادهای ترکمنچای می‌شوند. یک واحد حقوقی خیلی‌قوی قراردادی را تنظیم می کند که آن مجری پروژه نتواند از زیر هیچ تغییری در برود و از سوی دیگر آن شرکت نیز، با تفسیر بندهای قرارداد که منظورش این نبود یا ما این را پیاده سازی کردیم به دنبال این است که دعوای حقوقی را به پیش ببرد. حالا یک سری شرکت هم دوره های آموزشی “مدیریت ادعا” به مردم یاد می‌دهند.عملاً دور و بر خودتان را نگاه کنید یک پروژه مشخص دومین یا سومین بار است که به شرکت‌های مختلف برون سپاری شده است. یا حتی پروژه برون سپاری با مفاد قرارداد توافق شده وسر زمان نیز تحویل داده شده، ولی عملاً نیاز فعلی کسب و کار را برطرف نکرده است.چرا شرکت‌ها به دنبال برون سپاری پروژه های نرم‌افزاری هستند؟یکی از دلایل بسیار مهم برون سپاری پروژه های نرم افزاری دشوار بودن یا پرهزینه بودن نگهداری تیم های نرم‌افزاری است. باید قبول کنیم که جذب و نگهداری و جلو بردن تیم های نرم افزاری کار بسیار دشواری است و هم از نظر نفراتی که در آن تیم ها وجود دارم هم از نظر پیچیدگی تکنولوژی.بسیاری از شرکت ها قبل از برون سپاری، تیم‌های داخل سازمان داشتند ولی به دلیل اینکه پروژه ها جلو نمی‌رفت فکر کردند که با برون سپاری می توانند سرعت دریافت خروجی ها را بالا ببرنند. عملاً زمانی که شما پروژه را برون‌سپاری می کنید ریسک انجام نشدن کار (چه از نظر ابعاد تکنولوژی یا مسائل منابع انسانی یا …) یا سرموقع انجام نشدن آن را، برون سپاری کردید و عملاً مجری این ریسک را قبول کرده است.اینکه ما نیروی برنامه نویس با تجربه چندانی نداریم چون تعداد زیادی از این بچه‌ها مهاجرت کرده‌اند و یا موارد این چنینی، دیگر ریسک شما نیست و ریسک شرکتی است که این پروژه را قبول کرده است.اما با این حال که پروژه و ریسک آن به شخص ثالث سپرده شده است ولی همچنان شرکت نتایج مطلوب خود را دریافت نمی کند، چه از نظر پیشرفت پروژه یا از نظر برآورده شدن نیازها.برای همین بسیاری از شرکت‌ها به فکر افتادند که دوباره تیم های نرم افزاری خود را ایجاد کنند و به جای برون سپاری از استراتژی درون سپاری بهره بگیرند.مدل برون سپاری ها باید تغییر کندشما در برون سپاری پروژه های نرم افزاری باید یک اصل طلایی را بخاطر بسپارید:هسته اصلی یا مزیت رقابتی کسب و کار خود را به هیچ وجه برون سپاری نکنید، تیمی منسجم و با انگیزه دور این مزیت رقابتی ایجاد کنید و با تمرکز بالا خلاقیت کنید، آن رابسازید، تحویل داده فیدبک بگیرید و دوباره اصلاح کنید و …. اما هر چیز به جز آن را برون سپاری کنید، بگذارید بر روی اصل داستان متمرکز باشید.مثال کاربردیبرای اینکه این مثال را با هم چک کنیم، فکر کردم مدل نقشه واردلی می‌تواند به ما در درک اصل طلایی برون سپاری کمک کند.تصویر بالا نقشه واردلی را نمایش میدهد. این نقشه در واقع دو بعد اساسی دارد، بعد جریان ارزش (اینکه اجزای یک سیستم با هم کار می کنند تا یک ارزش را به مشتری یا کاربر برسانند)، بعد تکامل (هر جزء سیستم، یک چرخه تکامل دارد).در نقشه واردلی، به جای اینکه در مورد یک سیستم به صورت کلی صحبت شود، آن را به اجزای مختلف می‌شکند(کامپوننتایز) و در مورد هر جزء جداگانه تصمیم گیری می شود. اصلی ترین نکته نقشه واردلی، در واقع این هست که هر جزء اولین بار در چرخه پیدایش بوده، افراد کمی با آن آشنا هستند یا به آن دسترسی دارند، اما به مرور و با گسترش استفاده کم کم به چرخه انتهایی یا کالایی شدن پیش خواهد رفت. (عکس زیر را مشاهده کنید)تلفن را فرض کنید. یک روز فقط در آزمایشگاه بود، کسی اصلا نمی دانست چیست؟ اینکه مردم آیا نیاز دارند، شک داشتند، درک درستی از چیستی آن نبود – به چه دردی می خورد؟ عدم قطعیت بالا ، پیش بینی پذیری بسیار پایین (پیدایش). بعد یک سری شرکت یا افراد پولدار صاحب تلفن شدند، کم کم افراد نحوه استفاده از آن را درک کردند – بازار در حال شکل گرفتن … (سفارشی). در گام بعدی، به سرعت تعداد استفاده کننده ها بیشتر شد، تقریبا اکثریت جامعه به آن دسترسی داشتند، شرکتهای ارایه کننده خدمات نیز بیشتر شد، رقابت بر روی خدمات بیشتر شد، انواع گوشی تلفن عرضه می شد (محصول) و در گام نهایی اینقدر در دسترس بود که هر کسی تلفن نداشت جای تعجب داشت، همه می دانستند تلفن چیست، آن را پذیرفته بودند و تقریبا از نظر تکنولوژی به بلوغ و ثبات رسیده است (کالا).همین نقشه تکامل را در مورد فالکون شرکت اسپیس ایکس در نظر بگیرید، وقتی اولین پرتاب برای ناسا انجام شد، یعنی وارد حوزه سفارشی شد. در مرحله بعدی تعداد شرکتهایی مثل اسپیس ایکس بیشتر خواهد شد و این محصول پرتابگر را در بازار ارائه خواهند کرد (محصول)، و شاید یک روزی بسیاری از مردم بلیط بخرند و از آن استفاده کنند (کالا). (کسب و کار ناسا پرتاب نبود، آن را برون سپاری کرد، و بر روی کسب و کار اصلی خود تمرکز کرد.)مثال واقعی یک شرکت بورسیفرض کنید، یک شرکت بورسی، بنابر افزایش تقاضا در بازار سرمایه، میخواهد برای سرعت بخشیدن و گرفتن سهم بازار، به سمت معاملات الگوریتمی حرکت کند. به صورتی که با طراحی و ارائه الگوریتمهای معامله بازار را قبضه کند به نوعی که این در بلند مدت مزیت رقابتی این شرکت بورسی شود. اما به فکر این است که این پلتفرم را برای سرعت بخشیدن در توسعه به یک شرکت دیگر برون سپاری کند. اما مدیر فنی آنها، به صورت اتفاقی این نوشته را مشاهده می‌کند، و تصمیم می‌گیرد، اصل طلایی را در برون سپاری رعایت کند. او با کشیدن نقشه واردلی کار خود را شروع می نماید. (همانند شکل زیر)نقشه واردلی، ابتدا از کاربر و نیاز او شروع می کند، کاربر بدنبال چه چیزی است؟مدیر فنی ما شروع کرد، به استخراج کردن کامپوننت ها یا اجزای سیستم. برای برآورده کردن نیاز کاربر، چه اجزایی باید وجود داشته باشند.در ادامه از نظر تکامل، هر کدام از اجزاء را در ستون خود قرار داد.اکنون نوبت انتخاب برای درون سپاری و برون سپاری بود. (همانند شکل زیر)بخش کالا، در واقعی جایی هست که اصلا نیازی نیست ما در مورد آنها دغدغه داشته باشیم. بخش محصول، جایی هست که محصولاتی در بازار وجود دارند که ما باید آنها را پیدا کنیم برای خریداری یا اجاره.اما جایی که ما نیاز به تیم توسعه داریم، بخش سفارسی و پیدایش هست. حالا بر اساس تخصص های این حوزه شروع به استخدام نفرات و متخصصین کرد.اگر خود پلتفرم برون سپاری می شد، چه اتفاقی می‌افتاد؟هر روز، یک الگوریتم جدید باید توسعه داده شود و هر الگوریتم نیازمندی خود را دارد، هر الگوریتم موجب تغییر در خود پلتفرم خواهد شد. حالا فکر کنید، شما این حجم تغییرات را به یک شرکت دیگر بسپارید؟ در بهترین حالت که آنها راغب به انجام این تغییرات نیز باشند، چندین مدت طول خواهد کشید که آنها این تغییرات را اعمال کنند … و دوباره تغییرات… با این اوصاف واقعا این می تواند باعث ایجاد مزیت رقابتی برای این شرکت شود؟اما فکر کنید، یک تیم با انگیزه بر روی این پلتفرم کار کنند، خود آنها از کاربران بازخورد بگیرند، اصلاح کنند، دوباره نسخه جدید و …سخن پایانیبرون سپاری پروژه های نرم افزاری بشدت در ایران با چالش مواجه شده است. بهترین شیوه این است که شرکتها در استراتژی برون سپاری خود تجدید نظر کنند. نه به این معنی که دیگر برون سپاری نکنند. اما آنچه برون سپاری می کنند را تغییر بدهند.هسته اصلی یا مزیت رقابتی کسب و کار خود را به هیچ وجه برون سپاری نکنید، تیمی منسجم و با انگیزه دور این مزیت رقابتی ایجاد کنید و با تمرکز بالا خلاقیت کنید، آن رابسازید، تحویل داده فیدبک بگیرید و دوباره اصلاح کنید و …. اما هر چیز به جز آن را برون سپاری کنید، بگذارید بر روی اصل داستان متمرکز باشید.چابک و موفق باشیداسد صفریاین نوشته قبلا در این آدرس منتشر شده بود انجمن چابک ایران اسد صفری Sat, 13 Jun 2020 11:07:01 +0430 https://virgool.io/IranAgile/raci-%DB%8C%D8%A7-%D8%B1%D8%A6%DB%8C%D8%B3%DB%8C-spw7gnelbu5v تاریخ مشخص و دقیقی برای انتشار ماتریکس تعیین مسئولیت RACI وجود ندارد ولی در اکثر منابع عنوان شده که این ابزار، به عنوان یکی از ابزارهای (GDPM (Goal Directed Project Management در اوایل سال 1970 میلادی طراحی و در سال ۱۹۸۴ منتشر شده است.هر چند شواهدی از انتشار آن در سال 1956 و در Journal of Personnel Management نیز وجود دارد.به نظر می‌رسد زمانی که مدیران کارخانه‌های صنعتی برای اولویت‌بندی کارهایشان، استفاده از ماتریس‌هایی با عناوین فرصت-تهدید ، SWOT، آیزنهاور و ... را شروع کردند، به خانه‌ای به نام "فوری‌های کم اهمیت" رسیدند، که مشاوران به delegate‌کردن آن کارها توصیه می‌کردند. ماتریس آیزنهاور اکثر مدیران در این وضعیت از خود می‌پرسند به چه کسی می‌توانم این کار را بسپارم؟ به چه کسی تفویض کنم؟ از سوی دیگر به دلایل متعددی مثل بی‌اعتمادی، سپردن کار به افراد دیگر خیلی آسان هم نبود. پس صریح‌ترین و سریع‌ترین راهکار، ساختن یک سیستم Command-and-Control بود. که به وسیله ابزار RACI به خوبی قابل پیاده‌سازی بود.ویکی‌پدیا RACI را اینطور معرفی می‌کند:ابزاری برای توصیف مشارکت نقش‌های مختلف در تکمیل Task ها و تحویل پروژه که در شفاف‌سازی و تعیین نقش‌ها و مسولیت‌های پروژه‌ها و فرآیندهای دپارتمانی کاربرد دارد.اما به نظر می‌رسد نیاز به داشتن چنین ابزاری زمانی پدید می‌آید که مدیران شرکت و یا استارتاپ به دلیل نبود شفافیت از یک سو و از سوی دیگر تعیین اهداف و Deadlineهایی حیاتی در توسعه محصول، سعی در ساده‌کردن احوالات افراد دارند. تاکید می‌کنم این ابزار برای مدیران رده‌بالا جذاب بوده و دلایل عمده محبوبیت آن امکان بررسی عملکرد انفرادی و ساده فهم بودن آن است.بر اساس این ماتریکس، نقش، توصیف کننده‌ی مجموعه‌ای از Taskهای مرتبط برای یک نفر است. پس در قبال هر پروژه و حتی Taskی مدیر و یا جمعی از مدیران تعیین خواهند کرد که هر کسی چه نقش داشته باشد. این نقش‌ها به چهار دسته تقسیم می‌شود:R : Responsibleکسی یا کسانی که تعدادی کار را تا اتمام آن انجام می‌دهند و به همه اطمینان می‌دهند همه چیز به درستی پیش می‌رود.مثال: زمانی که قصد راه‌اندازی یه کمپین مارکتینگ داریم، مدیر مارکتینگ Responsible آن کمپین است.A: Accountableکسی که در نهایت پاسخگوی ارایه درست و صحیح کار و یا پروژه است. این افراد حق وتو دارند و موانع روی مسیر را حذف می‌کنند. این افراد در طول پروژه نسبت به سرعت پروژه فیدبک می‌دهند.مثال: زمانی که قصد راه‌اندازی یه کمپین مارکتینگ داریم، مدیرعامل Accountable است.C: Consultedکسانی که اکثرا در یک موضوع خاص کارشناس و متخصص هستند و با آنها مشورت می‌شود.مثال : زمانی که قصد راه‌اندازی یه کمپین مارکتینگ داریم، مشاوران copywriter یا designer ، Consulted هستند.I: Informedکسی که همیشه در جریان آخرین اطلاعات روند پروژه است و بیشتر مانند چشم، مراقبت می‌کنند اما اعمال فیدبک آنها خیلی ضروری نیست.مثال : زمانی که قصد راه‌اندازی یه کمپین مارکتینگ داریم، مدیر فنی پروژه، Informed است.و اما سوال اینجاست این ابزار محبوب، در دنیای توسعه نرم‌افزار چقدر کاربرد دارد؟ سعی می‌کنم نظر خودم رو در چند عنوان بیان کنم:تفاوت دنیا : از نظر من زمانی که قصد انجام کاری را داریم ابتدا باید بدانیم در چه شرایط و دنیایی در حال تصمیم‌گیری هستیم، دنیای پروژه و دنیای توسعه محصول کاملا با هم متفاوت هستند، حتما فریم ورک Cynefin را می‌شناسید:تعریف کار در این دنیا ها متفاوت است، توسعه محصول در دنیای Complex صورت می‌گیرد و تعریف انجام کار، صرفا Done‌ کردن آن نیست. در این دنیا ارزشی که در نهایت خلق می‌شود تعیین کننده میزان تلاشی است که برای آن صورت گرفته است. در این دنیا یک تیم شکل گرفته از مهارت‌ها و تخصص‌های متفاوت به عنوان یک موجود واحد مورد خطاب قرار گرفته و در قبال خلق ارزش تلاش می‌کنند. فضای این تیم، فضای ندانستن است و همیشه در حال تمرین برای یادگیری هستند و اشتباه یکی از طبیعی‌ترین اتفاقات تیم است و تجویز از پیش‌تعیین شده‌ای وجود ندارد.ابزار RACI سعی در حل مشکلات به صورت خطی (Linear ) دارد، در دنیای Complex نمی‌توان با دید خطی سراغ حل آن‌ها رفت، ولی در دنیای Simple و یا حتی Complicated که دنیای واضحات است، صرفا به اتمام رساندن یک‌سری Task‌از پیش تعیین شده، ملاک موفقیت است. پس می‌توان با خطی کردن روند پروژه (مانند کارخانه رب‌سازی) و تفویض مسولیت‌ها با این ابزار سیستم مدیریتی درستی اعمال کرد. در دنیای پروژه، یک تاریخ به عنوان تاریخ اتمام پروژه تعیین می‌شود و اشتباه معنی ندارد. افراد به تنهایی بار مسئولیت را بر می‌دارند.جداسازی فکر کردن از انجام دادن : ابزار RACI در تلاش است تا حد امکان این دو را از هم جدا کند تا فضای کاری را ساده‌تر کند. تفکری که در کارخانه‌ها توسط تیلور رواج پیدا کرد و سعی کرد با تشویق‌های مالی Workers های بهتری تحت مدیریت مهندسین پرورش دهد.این ابزار در جهت خلق سیستم Command and Control بسیار خوب عمل می‌کنداشاعه finger pointing : ابزار RACI از آن جهت محبوب است که می‌توان در انتهای پروژه و در صورت عدم موفقیت مقصر را به راحتی شناسایی کرد، به همین دلیل همیشه از حل مسئله دنیای عدم قطعیت به صورت مشارکتی پرهیز می‌کند که نتیجه‌اش اشاعه فرهنگ سرزنش و بهانه‌جویی است، در حالی که با روحیه تیم‌های ارزش‌محور زاویه اساسی دارند.پهنای باند: بکارگیری این ابزار در تیم توسعه محصول، باعث می‌شود پهنای باند موجود در تیم به شدت خدشه دار شود. با تفکیک مسولیت‌ها، این پهنای باند کم شده و عملا بستر مناسب انرژیک کل تیم از بین خواهد رفت. در دنیای امروز تفکیک تخصص‌ها به این سادگی امکان پذیر نیست و در عمل امکان دارد افرادی که نقش مشاور دارند، در اجرا بسیار موثرتر باشند و بالعکس.و اما خلاصه نظر من:هر گاه اصول زیر را زیر پا گذاشتیم سراغ ابزار RACI‌ در تیم‌های توسعه محصول می‌رویم :ذینفعان کسب و کار و توسعه دهنده ها می بایست به صورت روزانه در طول پروژه با هم کار کنندپروژه ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی کنید و به آنها اعتماد کنید تا کارها را انجام دهندنرم افزار قابل استفاده اصلی ترین معیار سنجش پیشرفت استبهترین معماری ها , نیازمندی ها و طراحی ها از تیم های خود سازمانده پدید آور می شوددر فواصل منظم , تیم بر چگونگی موثرتر شدن تامل و تفکر می نماید و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می نمایدوقتی این موراد نقض شد و سراغ ابزار RACI بریم، بعد از مدتی باید دنبال ادمین RACI بگردیم :Dبا تشکر از سهیل صمد‌زاده عزیز که فیدبک‌های خوبی به من داد تا بتوانم نظرم رو شفاف‌تر بیان کنم. انجمن چابک ایران نوید نیک پی Sat, 16 May 2020 10:28:14 +0430 https://virgool.io/IranAgile/%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%DA%86%DB%8C%D8%B3%D8%AA-h8byhzxo7rsl در این چند سال تجربه کاری، در صنعت های مختلفی کار کردم، از جمله بانک، بورس، شرکتهای استارتاپی و … . یک الگو تکرار شونده اکثرا در همه این شرکتها بود که یک جنس یا یک طیف خاصی از پروژه معمولا شکست می خورند یا حداقل چالش زیادی داشتند. برای مثال پروژه های IT یا توسعه یک نرم افزار جدید از این دست پروژه بودند.یادم هست در یک شرکت بانکی بزرگ و دولتی، قرار بود یک نرم افزار مدیریت املاک و مستقلات تولید شود تا بتوان لیست جامعی از املاک و مستغلات درست کرد با هدف مدیریت بهینه مستغلات بانک و تصمیم گیری درست درخصوص شرایط نگه داری یا واگذاری املاک. مثلا شاید یک بانک بزرگ در یک گوشه از کشور یک ملکی دارد که آن اجاره داده شده است، اما سالها فراموش شده و شاید هم از آن سواستفاده می شود، یا در سالهای اخیر فشار زیادی بر روی بانک ‌ها هست که املاک خود را واگذار کنند، اما کدام ملک باید واگذار شود؟ این باعث شد که نیاز به یک نرم افزار جامع مدیریت املاک حس شود.یک پروژه بنام مدیریت جامع املاک در آن بانک معظم تعریف شد و یک تیم نرم افزاری کار را بر روی آن شروع نمود.در واقع بنابر مدل آبشاری همانطور که در شکل زیر مشاهده می کنید، پیش فرض اصلی تیم بود. این مدل آبشاری دو فاز اساسی دارد: فاز اول، برنامه ریزی شامل : گرد آوری نیازمندی، تحلیل نیازمندی ها و طراحی، که در این فاز ابتدایی ما وارد اجرا نمی شویم و خروجی این فاز بیشتر مستندات و خوراک فاز بعدی است. در فاز بعدی، ما وارد فاز اجرا و نظارت و نهایتا تحول خواهیم شد.علتی که به این مدل آبشاری گفته می شود این است که، خروجی هر مرحله برای بخش بعدی قطعی هست و همانند یک آبشار که آبی که از بالا به پایین میریزد قابل بازگشت نیست، خروجی نیز قابل برگشت نیست.در همین پروژه ذکر شده، کلی دوستان تحلیلگر شروع به جمع آوری نیازمندی ها کردند، برای همین منظور مجبور شدند با دایره مربوطه در بانک جلسات مصاحبه داشته باشند و … . پس از جمع آوری نیازمندی های ، آنها به زبان قابل فهم نیروهای فنی تحلیل و طراحی شده و در قالب سندهای تحلیل-طراحی بدست برنامه نویس ها رسید. (این پروسه شاید ماهها به طول انجامید). در ادامه چندین ماه دیگر نیز ادامه داشت تا پیاده سازی اتفاق بیفتد، بعد از پیاده سازی، تیم تست با استفاده از سندهای تحلیل شروع به تست کرد، و بعد اینکه مطمئن شدند که خروجی پیاده سازی شده با سندهای تحلیل مطابقت دارد، آماده تحویل و استقرار خروجی شدند. نرم افزار نصب شد ولی کسی از آن استفاده نکرد؟ چرا؟ با اینکه این همه زحمت کشده شده بود؟خوب موقعی که یک ملک نیاز بود ثبت شود، اطلاعات بین واحدهای مختلف پخش بود، و درواقع یک اپراتور دسترسی به همه آنها نداشت اما برای ثبت و تایید فرم باید همه اطلاعات وارد میشد یا کلی اقلام اطلاعاتی که هیچ کس به آنها دسترسی نداشت یا وارد کردن اطلاعات برای یک ملک خاص خیلی سخت و پیچیده بود و یک کارمند دولتی خیلی حال نداشت این همه اطلاعات را وارد کند، و موارد زیاد دیگری که باعث می شد واحد سفارش دهنده تمایلی به استفاده از خروجی استقرار یافته نداشته باشد زیراکه اعتقاد داشتند این نرم افزار نیاز آنها را برآورده نمی‌کند یا خیلی پیچیده است یا .. پس نیاز بود که کلی تغییرات انجام شود.شاید بشود، کاسه و کوزه را بر سر تحلیلگرها شکست که چرا درست تحلیل نکردید؟ چرا برنامه نویس ها پیچیده آن را پیاده سازی کردند؟ یا می شود کاسه کوزه را بر سر مشتری سفارش دهنده شکست که چرا از اول همه چیز را نگفتید؟ ولی همانطور که در اول این نوشته گفتم، یک جنس از پروژه ها هستند که این اتفاق به صورت مکرر در آن اتفاق می افتد. پس احتمالا مشکل جایی دیگری هست.پروژه‌ها یا مسئله‌های طیف مشخص و طیف پیچیده با هم فرق دارنداکثر پروژه های نرم افزاری در طیف پیچیده دسته بندی می شوند، از این لحاظ که نه سمت مشتری “دقیقا” میدانند چه نیازمندی دارند و معمولا با دیدن خروجی، قطعیت پیدا می‌کنند(آها ما این رو میخواهیم). هم سمت اجرا کننده پروژه، روشهای و ابزارها، طرح ها و … قطعیت ندارند، مثلا شاید از یک دیتابیس برای ذخیره سازی اطلاعات استفاده کنیم که در ادامه به این نتیجه برسیم که انتخاب بهتری هم هست. از طرف دیگر، شرایط بازار و رقابت نیز باعث می شود ما در برنامه اجرایی قطعیت کامل نداشته باشیم.مدل آبشاری در طیف مسئله های مشخص عالی عمل می‌کندمدل آبشاری در مسئله های پیچیده کاربردی نیست و موجب ایجاد محصولات بدردنخور و اتلاف منابع خواهد شدذات مسئله‌های پیچیدهما در پروژه ها یا مسئله های پیچیده به چند چیز یقین داریم:۱- چیزی که مشتری درخواست داده یا آنچیزی که ما فکر می‌کنیم که مشتری به این قابلیت یا فیچر نیاز خواهد داشت با آنچیزی که واقعا نیاز دارد، معمولا متفاوت هست.۲- ما قطعا میدانیم که روش اجرایی که از اول برنامه ریزی کردیم، چیزهایی پدید خواهد آمد که نمی دانستیم. پس برنامه اجرایی و روش انجام نیز قطعیت ندارد.۳- موارد ۱ و ۲ باعث می شود که مطمئن شویم، که تغییر در مسئله های پیچیده، امری اجتناب ناپذیر بوده و به جای دوری از آن باید راهی پیدا کنیم که پذیرای آن باشیم.خیلی ساده، ما اگر بتوانیم، تغییرات را در گام های نخست پیدا کنیم، پس هزینه تغییرات کم خواهد بود، در نتیجه خواهیم توانست به سهولت آنها را انجام بدهیم. با انجام آنها نیاز اصلی مشتری رفع شده و خواهیم توانست رضایت بالای مشتری را بدست بیاوریم.به تفکر “پاسخگویی سریع به تغییرات” چابک یا چابکی گفته می شود.اسکرام روشی برای حل مسئله های پیچیدهاسکرام یک چارچوب چابک است که با آن میتوانیم مسئله های پیچیده را حل نماییم. مسئله پیچیده به مواردی گفته می شود، دانش ما نسبت به مسئله ناقص است و به مرور این دانش پدیدار خواهد شد. مثلا توسعه نرم افزار برای یک بانک، راه اندازی یک استارتاپ، ترافیک، پیش بینی آب و هوا، یا ساختن واکسن کرونا.اسکرام با استفاده از یک روش چرخشی افزایشی باعث کاهش ریسک و افزایش میزان پیش بینی پذیری می شود.آیا ما “محصول درستی” می سازیم؟آیا ما محصول را به “شیوه درستی” میسازیم؟بخش دوم – اجزا و نحوه کار اسکرامنمایی از اجرای اسکراماین نوشته قبلا در این آدرس منتشر شده است.اگر به تازگی با اسکرام آشنا شدید یا در اوایل کار خود هستید، این دوره آنلاین بهترین پیشنهاد برای شما خواهد بودچابک و موفق باشیداسد صفری انجمن چابک ایران اسد صفری Mon, 11 May 2020 09:13:36 +0430 https://virgool.io/IranAgile/13th-annual-state-agile-report-farsi-wqi8ovyyjnxy سیزدهمین گزارش سالانه وضعیت چابکی در جهان توسط CollabNet VersionOne منتشر شده است. این کمپانی پیشرو در مدیریت جریان ارزش، مدیریت چابک و دواپس است. این گزارش قدیمی‌ترین گزارش بررسی وضعیت چابکی در جهان با بیشترین ارجاع است. نتایج نظرسنجی امسال برگرفته از نظرات پاسخ­‌دهندگان گسترده­‌تری در سطح جهان از اروپا، آسیا، آمریکای جنوبی و آفریقا نسبت به سال گذشته می‌باشد. این موضوع نشان می­دهد پذیرش جهانی رویکردهای چابک در حال افزایش است، به طوری که آمریکای شمالی درصد کمتری از کل پاسخ‌دهندگان نسبت به سال‌های گذشته را دارد.سیزدهمین گزارش سالانه حاکی از موضوعات و ویژگی­های جدید، تغییر در اولویت‌ها و گسترش ناحیه تمرکز است. در گزارش امسال متناظر با افزایش اهمیت دواپس، بخش دواپس به همراه نتایج گسترده‌تری ارائه شده است. موضوع مدیریت جریان ارزش برای اولین بار در این گزارش ارائه شده است. این موضوع یک مقوله نوظهور است که به سازمان‌ها در جهت درک بهتر ارزش اتصال تجارب چابکی و دواپس کمک می‌کند.از نکات برجسته گزارش امسال می‌توان به میزان پذیرش چابکی اشاره کرد به طوری‌که 97% سازمان‌ها بیان کرده‌اند که روش‌های توسعه چابک را تمرین می‌کنند. البته هنوز مهارت در روش‌های چابک پایین است و تنها 17% سازمان‌ها ادعای سطح بالایی از مهارت را دارند. از مزایای مهم چابکی می‌توان به توانایی مدیریت تغییر اولویت­ها (69٪) ، شفافیت پروژه (65%)، همکاری کسب­ وکار و آی‌تی (64%)، روحیه تیم (64%) تحویل سریع و به‌موقع (63%) اشاره نمود.موفقیت پروژه با استفاده از روش‌های چابک نسبتاً زیاد است، به طوری‌که %95 سازمان‌ها اعلام کرده‌اند که حداقل برخی از پروژه‌های چابک آنها موفقیت‌آمیز بوده و 48% می‌گویند که اکثر یا همه پروژه‌های چابک آنها موفق شده ­است. از معیارهای اصلی موفقیت در پروژه‌های چابک می‌توان از رضایت مشتری/کاربر (46%) و تحویل ارزش کسب‌وکاری (%42) نام برد.مهمترین عواملی که در روندهای 2019 برجسته است شامل موارد زیر می‌باشد:پذیرش چابکی به دلیل کاهش هزینه‌ها و بهبود روحیه تیم افزایش یافته است: گزارش امسال یکی از دلایل اصلی پذیرش چابکی را کاهش هزینه پروژه نشان می‌دهد (41%). این درصد نسبت به سال قبل 27% افزایش یافته است. با توجه به گزارش امسال، پذیرش چابکی به دلیل بهره‌وری بیشتر و ریسک کمتر کاهش یافته است.دواپس اولویت سازمانی بالاتری یافته است: نیاز به درک و بهبود دواپس به عنوان اولویت اصلی سازمان‌ها درحال افزایش است. 90% از پاسخ‌دهندگان آن را یک موضوع قابل توجه می‌دانند. درصد پاسخ­‎دهندگانی که دواپس را بسیار مهم تلقی کرده اند (41%) نسبت به سال قبل 27% افزایش یافته است.قابلیت پایش و پیگیری نقطه به نقطه دلیل عمده افزایش پذیرش دواپس است: در مجموع 38% از پاسخ‌دهندگان پایش نقطه به نقطه از کسب‌وکار تا توسعه، تست و استقرار را به عنوان ارزشمندترین قابلیت برای بهبود دواپس مشخص کردند.مدیریت جریان ارزش، موضوعی جدید اما مهم است: اگرچه مدیریت جریان ارزش امسال برای اولین بار خود را معرفی کرد، 67% از پاسخ‌دهندگان گزارش دادند که مدیریت جریان ارزش برای اتصال کسب‌وکار به قابلیت‌های تحویل نرم‌افزار بسیار مهم است.روش SAFe بر دیگر روش‌های مقیاس پذیری چابک غلبه دارد- چارچوب مقیاس‌پذیر چابک (SAFe) به رشد خود در مقبولیت ادامه می‌دهد و به‌عنوان روش مقیاس کردن چابکی با انتخاب30% از پاسخ‌دهندگان مشخص شده است.سه عامل مهم در موفقیت پیاده سازی تحول چابکی در سازمان‌ها شامل سرمايه­‌گذاري بر روی مربيان چابك داخلي، حمایت مالی و برنامه‌هاي آموزشي ارائه شده توسط شركت می­باشدخوانندگان می‌توانند فایل کامل گزارش سیزدهمین وضعیت چابک را از طریق وب سایت پروژه دریافت کنند. نسخه ترجمه شده آن نیز به صورت pdf در این آدرس قابل دانلود است.https://drive.google.com/open?id=1Exc-Gdng9fQURQ3COJBFurRrj7IkuM4sدر ادامه عکس های مربوط به ترجمه این گزارش قرار داده شده است. انجمن چابک ایران مصطفی جاویده Fri, 17 Jan 2020 07:00:46 +0330 https://virgool.io/IranAgile/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%AF%D8%B1-%DB%8C%DA%A9-%D8%B4%D8%B1%DA%A9%D8%AA-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%85%D8%AD%D9%88%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D9%85%D8%AD%D9%88%D8%B1-%D8%A8%D8%A7%D8%B4%DB%8C%D9%85-h7ei9zkxwpjq یکی از مشکلات اساسی که شرکت‌های نرم افزاری با آن مواجه هستند، شتر گاو پلنگ بودن میان دو دنیای پروژه محوری و محصول محوری است. در دنیای پروژه محور ما از اول به دنبال یک “زمان و برنامه” هستیم: 1- چه زمانی کار به اتمام می رسد 2- برنامه دقیق اجرا چیست؟ تا بعد آن یک واحد نظارتی دیگر بر اساس این برنامه و زمان اعلام شده ، پیشرفت پروژه را ارزیابی کند. در نگرش پروژه محور، سوال همیشگی این است "چه زمانی تمام می شود"، بخاطر همین همیشه اصلی ترین چالش شیوه تخمین زدن زمان پروژه است.اما در دنیا محصول محور، یک محصول تا زمانی که برای مشتری/شرکت ارزش خلق کند زنده خواهد ماند و تا هر زمانی که زنده است، توسعه ادامه خواهد داشت(چرخه عمر محصول).فرض کنیم، نرم افزاری مانند اینستاگرام را بخواهیم پروژه در نظر بگیریم که یک شرکت پیمانکار از شرکت فیسبوک گرفته تا انجام دهد، احتمالا در نظام مدیریت پروژه سوال این است که “کی این پروژه تمام می شود؟ ساختار شکست کار به چه صورتی است؟” اما در واقعیت امروز؛ دائما تیم اینستاگرام با مشتری در تماس است، بازخورد می‌گیرد، بر اساس همین بازخورد یا مشاهده رقبای خود، اقدام به توسعه قابلیت‌های جدید می‌کند. در نگاه محصولی، ارزیابی عملکرد با ارزشی که محصول برای مشتری خلق می‌کند، صورت می پذیرد، اما در نگاه پروژه محور، متر موفقیت، هماهنگ بودن پیشرفت پروژه با برنامه از پیش تعیین شده و یا عقب/جلو بودن از آن است. اینکه کدام نظام بد یا خوب است، مسئله ما نیست، هر دو نظام جایگاه خود را دارند. اما واقعیت این است که نظام چابک مبتنی بر خلق ارزش بوده و چارچوب های چابک مثل اسکرام نیز بر اساس همین قاعده بنا نهاده شده اند. منتهی مشکل آنجا شروع می شود که در نظام تفکری چابک، میخواهیم ادبیات نظام پروژه محور را انجام بدهیم.فرض کنید من در شرکتی مدیر پروژه هستم، در آنجا مدیرانی که بیشترین پروژه را تمام کرده باشند، پاداش بیشتری خواهند گرفت، آیا من حاضر خواهم بود که به بازخوردهای کاربر/مشتری در زمان توسعه یا بعد از تحویل گوش بدهم؟ در حالی که در تفکر چابک، پذیرفتن بازخورد کاربر و تغییرات بعنوان اصلی ترین مزیت رقابت سازمان در نظر گرفته شده است. برخی سازمانها برای چابک سازی، عنوان مدیر پروژه را به مالک محصول تغییر می‌دهند، اما همچنان متر موفقیت، مترهای نظام پروژه محور باقی می ماند، پس مسلما ما نتایج همان نظام را بدست خواهیم آورد.باز تاکید میکنم، منظور من این نیست که نظام مدیریت پروژه بد است. اما در صنعت نرم افزار، 1- اساسا دامنه کار ما از اول مشخص نیست 2- بعد از تحویل محصول، بخش اعظمی از دامنه کار معلوم می شود 3- محصولات نرم افزاری معمولا انتها ندارند البته تا زمانی که کنار گذاشته شوند.باید قبول کرد که بسیاری از سازمانهای ما با اینکه می‌خواهند ولی هنوز کامل محصول محور نشده اند(به دلایل مختلف، مانند کارفرما، ساختارهای سنتی و … )، اما در این نوشته می‌خواهم کمی سعی کنم ارتباطی بین دو دنیا را برقرار کنیم.در دنیای پروژه، ما نیاز داریم اسکوپ یا دامنه کار را با جزئیات زیادی دربیاوریم،  تخمین بزنیم که چقدر طول می‌کشد، بعد یک برنامه اجرایی داشته باشیم، مثلا با گانت چارت. مشتری الان میداند چه زمانی پروژه تمام می شود و خیالش راحت است، منتهی در پروژه هایی که اساسا مبتنی بر فیدبک مشتری/کاربر است، یا کلا دامنه شفاف نیست و به مرور کشف می شود، خیلی سخت هست که بتوانیم این روال را داشته باشم. اما باید چه کرد؟نکته مهم: البته روش معرفی شده برای شرکتی و جایی هست که واقعا نتیجه و ارزشی که برای کاربر نهایی خلق می شود مهم باشد یا اساسا جنس کارهایی که انجام می‌دهند مبهم یا دامنه مشخص نداشته باشد، اگر اساسا این در شرکت شما نیست، کلا نیازی به ادامه متن نیست (:1- برای چیزی که داریم برنامه ریزی کنیمبه جای اینکه فکر کنیم ما یک پروژه داریم، باید این را در نظر بگیریم ما یک محصول داریم با چندین نسخه که هر نسخه میتواند یک پروژه باشد. یعنی هر نسخه یک دامنه، زمان و هزینه خواهد داشت. پس بسیاری (نه همه) از قواعد مدیریت پروژه را میتوان در بستر نسخه انجام داد.ما معمولا دو نوع نسخه بندی میتوانیم انجام بدهیم:1- مبتنی بر زمان2- مبتنی بر فیچرهر دوی این روش ها، در نهایت به یک لیستی از فیچر یا قابلیت و یک زمان دست پیدا خواهیم کرد، اما بهتر است در نگاه فیچر محور یا زمان محور، به برآیند نیز فکر کنیم، که هدف ما از ارایه این نسخه چیست؟ دلیل این اقدام این است که اگر روزی قرار بود در دامنه این نسخه تغییر بدهیم بتوانیم سنگ محکی داشته باشیم که کدام اقلام را فعلا میتوان انجام نداد.2- چند نسخه جلوتر را باید برنامه ریزی کنیم؟در محصولات ناشناخته یا پر ابهام، بهتر است همیشه یک نسخه را برنامه ریزی داشته باشید، اما گر باز نیاز بود(بر اساس فشار مدیریت یا مشتری یا …) می‌توانید چند نسخه را جلو-جلو به همین صورت برنامه ریزی کنید. منتهی معمولا برنامه ریزی بیش از 3 نسخه جلوتر غیر واقعی خواهد بود.برخی شرکتها مشتری خود را به ریلییز، دوره ای و منظم عادت می‌دهند، مثلا هر یک و نیم ماه یک ریلییز خواهیم داشت که در یک سال، 8 بار خواهد بود.3- قیمت چگونه تعیین می شود؟زمانیکه کل دامنه معلوم نیست، چگونه بر روی پروژه قیمت گذاری کنیم؟ این قسمت یکی از گیرهای اساسی است. (لطفا این را از من نشنیده بگیرید، حتی شرکتهایی که زمان خیلی زیادی در مرحله قیمت دادن صرف کردند و از انواع روشها برای قیمت دادن استفاده می کنند، به تجربه دیدم این عدد بیشتر از یک حدس و گمان نیست)یک روش جایگزین این است که می‌توانید به جای قیمت گذاری از مفهوم بودجه استفاده کنید. مثلا این محصول تا چقدر می ارزد که ما بودجه صرف آن کنیم.یا حتی اگر قیمتی تعیین شده (حالا با هر روشی)، بهتر است به آن نگاه بودجه داشته باشید. مثلا قیمت روی کل پروژه 1 میلیارد تعیین شده است. اما با توجه به قطعی نبودن نیازمندی ها، دامنه احتمال دارد تغییر کند. پس ما به اندازه یک میلیارد قرار شده برای این محصول کار کنیم. پس با ارزشترین کارها در نسخه ها ابتدایی انجام می شود و بعد بر اساس بازخورد به جلو حرکت می‌کنیم. برای اینکه حتی اگر مشتری نتوانست بودجه بیشتری برای این پروژه بگذارد، محصول قابل استفاده و نیازهای مشتری را رفع نماید.در واقع بودجه برای تحقق چشم انداز است تا رسیدن به Initial Plan . هر لحظه برنامه میتواند تغییر پیدا کنداگر بودجه تعیین شده تمام شد، و همچنان مشتری خواهان توسعه بود، می‌توانیم بودجه جدیدی برای توسعه در نظر بگیریم، اینکه مشتری از کجا بداند ما سر او کلاه نمیگذاریم، با همراه دائمی او در فرآیند توسعه و تحویل اقلام در نسخه های کوچک خواهد بود. (واقعیت این است نظام قرارداد در ایران بسیار قدیمی است و کاملا مبتنی بر شرایط پایدار و قطعیت تعیین شده و در بسیاری اوقات نمیتوان در قرارداد چابک عمل کرد، و بهترین گزینه داشتن یک قرارداد اما تعامل با مشتری در طول انجام کارها و ایجاد توافق برای ادامه راه بر اساس همان بودجه تصویب شده است، یا برخی مواقع قرار داد بر اساس متریال و زمان T&M میتوان گزینه خوبی باشد یعنی هر چند تا ریلییز کار انجام شد کارفرما پول بپردازد. در این مدل قرار اعتماد بین طرفین بسیار حیاتی است)4- چگونه پیشرفت را اندازه بگیریم؟در روش قدیمی، پیشرفت به یک برنامه نیاز دارد، مثلا گانت چارت، و یک سیستم لاگ زدن. متر ما در اسکرام Done  شدن اقلام قابل تحویل به مشتری در انتهای اسپرینت خواهد بود.ما معمولا پیشرفت انجام کار را در سطح نسخه و نه محصول/پروژه اندازه می‌گیریم، و دلیل آن عادت دادن تیم و مشتری به مهم بودن نتیجه هر نسخه است و اینکه هر نسخه را به چشم یک پروژه نگاه می کنیم. نمودار Release Burndown یکی از بهترین گزینه ها در این خصوص است.برای اینکه این نوشته کاربردی تر باشد و باتوجه به اینکه در ایران ابزار اصلی شرکتها جیرا است، نمودار را با این ابزار ایجاد و شرح می‌دهم، اما با اکسل یا حتی امکان رسم دستی نیز وجود دارد.در قسمت نسخه های جیرا، یک نسخه جدید اضافه کنید و بعد اقلام مربوط را به نسخه اضافه کنید. دقت داشته باشید که تنها اقلامی را اضافه کنید که میخواهید در این نسخه تحویل شود (پیش بینی می‌کنید تحویل این اقلام ارزش بیشتری داشته باشد، البته بهتر است انتخاب اقلام بر اساس یک نقشه راه باشد که در کتاب مدیریت محصول چابک میتوانید در این خصوص بیشتر مطالعه کنید)حالا بعد از انجام چند اسپرینت اتوماتیک نمودار بردن داوون برای شما ایجاد خواهد شد(منظور باز شدن و بسته شدن اسپرینت ها در جیرا): این نمودار کمک می‌کند مدیر پروژه/محصول و تیم روند پیشرفت نسخه را ببینند و اگر نیاز به تغییر باشد، آن را سریع اعمال کنند. مثلا در شکل بالا شاهد این هستیم که 6 اسپرینت برای انجام مابقی اقلام این نسخه لازم است، اگر فکر می‌کنیم، 6 اسپرینت خیلی دیر است، می‌توانیم در اسکوپ باقی مانده این نسخه تجدید نظر کنیم.5- تغییرات در اسکوپ نسخهیکی از مواردی که تیم ها را اذیت می کند، موارد پیش بینی نشده هر نسخه هست. یعنی مواردی به دامنه این نسخه اضافه شده که از اول بر روی آنها توافق نشده بود، ولی الان مشتری یا خودمان می‌خواهیم این قابلیت نیز در این نسخه ارایه شود.در شکل بالا، در اسپرینت 3 و در جلسه دمو، نیاز شده دو استوری جدید هر کدام با 5 پوینت به دامنه نسخه اول اضافه شود. کار کرد این نمودار این است که شما همیشه بتوانید میزان کار باقی مانده را به راحتی ببینید و تصمیم مناسب آن لحظه را بگیرد که معمولا نیاز به رایزنی در مورد تغییر دامنه نسخه خواهد بود. برای اینکار خیلی ساده، یک گزارش وجود دارد که شما میتوانید دامنه باقی مانده از نسخه را ببینید و آن را الویت بندی کرده و مواردی که برای این نسخه حیاتی نیستند را از نسخه بیرون بیندازید.فرض کنید برای مثال باید تا سه تا اسپرینت بعد یعنی 1.5 ماه دیگر نسخه را ارایه کنیم، ولی الان برای کار باقی مانده ما به 5 اسپرینت نیاز داریم(بر اساس نمودار)، و سرعت انجام کار 6 پوینت و کار باقی مانده 30 پوینت است. برای اینکه در 3 اسپرینت کار بسته شود، یا باید تیم سرعت را به 10 پوینت برسانند که معمولا نیاز به اضافه کاری خواهد بود که در بلند مدت اصلا توصیه نمی شود، اما راه حل دیگر، بازی با دامنه خواهد بود.6- از تکنیک MoSCoW استفاده کنیدمعمولا در این مرحله که شما نیاز دارید بر روی دامنه مذاکره کنید، تکنیک MoSCoW روش موثری است:در اینجا همراه با ذینفعان بر روی الویت بندی باید کار کرد، مثلا مانند تصویر زیر:آیتمهای با الویت Will معمولا از نسخه حذف می شوند و به بک لاگ یا نسخه بعد اضافه می شوند، پس در نتیجه نمودار ریلیز برن داوون چنین چیزی نشان خواهد داد:ما شاید بتوانیم در تفکر چابک، یک نسخه یا یک اسپرینت را پروژه در نظر بگیریم( البته همچنان باید منتظر بازی کردن با دامنه باشیم)، اما مسلما نمیتوانیم کل یک محصول پیچیده را یک پروژه در نظر بگیریم و انتظار داشته باشیم که با قواعد دنیای پروژه محور، بیشترین ارزش ممکن را خلق کنیم.چابک و موفق باشیداسد صفریاین نوشته قبلا در این آدرس نیز منتشر شده بود. انجمن چابک ایران اسد صفری Mon, 30 Dec 2019 22:58:05 +0330 https://virgool.io/IranAgile/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D8%B3%D9%81%D8%B1-%DA%86%D8%A7%D8%A8%DA%A9-%D8%AF%D8%B1-%D8%B4%D8%B1%DA%A9%D8%AA-%D8%AA%D8%AD%D9%84%DB%8C%D9%84%DA%AF%D8%B1-%D8%A7%D9%85%DB%8C%D8%AF-%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%D9%88%D8%A7%D9%82%D8%B9%DB%8C-%D8%AA%D8%AD%D9%88%D9%84-%DA%86%D8%A7%D8%A8%DA%A9-fuaipspiu0rj تحلیلگر امید شرکتی است که سرویس WealthTech بر پایه هوش مصنوعی برای زیاد کردن پول مشتریانش ارایه می دهد. زمانی که در این شرکت دعوت به همکاری شدم، انتظاری که از من داشتند پیاده سازی اسکرام بود اما بر اساس تجربه میدانستم که اسکرام مثل یک دکمه است که میخواهیم برای آن یک کت بدوزیم. اینکه هدف شرکت پیاده سازی اسکرام باشد، هدف خوبی نیست. واقعا چرا باید اسکرام را پیاده سازی کنیم؟ آیا مشکل اساسی شرکت پیاده نشدن اسکرام است؟ یا در واقع میخواهد با پیاده سازی اسکرام چه مشکلی را حل کند؟در بسیاری اوقات اسکرام پیاده می شود، ولی واقعا چیزی بهتر نمی شود.وقتی تنها ابزار من چکش باشد همه چیز را میخ خواهم دید و به جای حل مشکل سازمان بدنبال پیاده سازی اسکرام خواهم بود.پروژه تحلیلگر امید را چگونه شروع کردیم؟سعی کردم در شرکت امید، از مدل اجایل فلوئنسی برای پیشبرد چابک سازی استفاده کنم. مدل اجایل فلوئنسی سه گام اساسی برای چابک سازی دارد:1- شناسایی فرصت2- دیاگ زدن3- دست یابی به فرصتمرحله اول: شناسایی فرصتبه طور کلی در این گام، سعی می شود که درک کنیم دغدغه سازمان چیست؟ کلمه فرصت/چالش با هم می آیند. سازمان با چه چالشی مواجه است که فکر می‌کند نیاز به یک روش دیگر کار دارد.در مورد شرکت امید، این شناسایی در طی یک هفته اول که در سازمان بودیم انجام شد، شامل صحبت کردن با تیمها و اعضای فنی و مدیران محصول و مدیران ارشد ... .نکته مهم در اینجا این است که همه دوستان از ظن خودشان یار شما می شوند. کار یک مربی در اینجا این است که درک کند که مسائل زیرین و اساسی چیست؟ مثلا اینکه جلسات دیلی به موقع برگزار نمی شود، شاید مسئله اساسی نباشد.چیز مهمی که در امید در جریان بود این بود، که امید در یک مدت کوتاه رشد سریعی انجام داده بود، این رشد سریع باعث شده بود یک سری از سیستم ها خیلی سریع توسعه داده شوند، حتی برای بالا آوردن این سیستم ها جشن گرفته شده بود اما امروز میزان باگ به میزان باور نکردنی بالا بود. این میزان باگ بالا باعث شده توسعه فیچرهای جدید بشدت کند شود، از طرف دیگر، این کند جلو رفتن توسعه فیچرها باعث شده بود فکر کنیم که چرا امور کند است؟ خود این باعث شده سطح اعتماد کمتر شود، آیا آنها واقعا کار می‌کنند؟ خود این کم رنگ تر شدن اعتماد، باعث ایجاد مشکلات روابط انسانی نیز شده بود. حتی بچه های فنی نیز نسبت به هم و توانایی همدیگر با شک نگاه می کردند.حتی علاوه بر این، سود مالی بخاطر عدم پیشرفت به موقع پروژه، کاهش یافته بود و در برخی از موارد، باگ ها باعث ضرر و زیان مالی زیادی برای شرکت شده بودند.این نکته بسیار مهمی است که ما چالش اصلی را پیدا کنیم و صرفا درگیر نشانه ها یا علائم بیماری نشویم. معمولا زیاد می شنوید، فلانی کدنویسی بلد نیست، مدیر شاید بگوید باید نیروی فنی جدید بیاورم، اسکرام مستر می گوید جلسات اسکرام درست برگزار نمی‌شوند و ... حتی شاید بخاطر پایین بودن میزان اعتماد یا خدشه دار شدن روابط انسانی یک دور آموزش کارتیمی بگذاریم اما آیا ریشه داستان حل می شود؟فرصت شناساسی شده در امیدبهبود کیفیت سیستم جهت حداکثری کردن رضایت مشتریان، ذینفعان و بخصوص اعضای تیمدر حالی که کیفیت، چالش شماره یک ما بود، در همان حال می توانست فرصت هم بشود که با پرداختن به آن، اوج بگیریم.انتخاب ناحیه فلوئنسی بر اساس فرصت/چالشمدل اجایل فلوئنسی یک مدل بلوغ نیست، معمولا در مدل بلوغ هر چقدر بیشتر بهتر است اما در مدل اجایل فلوئنسی که ما چهار ناحیه داریم، هر ناحیه برای خودش منافع مشخص و در عین حال هزینه مشخصی دارد. یعنی به تنهایی هر ناحیه ی مدل بالغ کامل است. در صورتی که ناحیه بالاتر نیاز ما نباشد، صرفا هزینه غیر لازمی را انجام خواهیم داد.توضیح خلاصه نواحی مختلف فلوئنسیناحیه Focusing در واقع همان پایه و فونداسیون چابک است و یک تیم چابک فلوئنت در این حوزه می ‌تواند از منافع حاصل شده از شفافیت و کار تیمی به صورت ملموس بهره ببرد. هر چند که فلوئنت بودن در این ناحیه شامل مهارت های فنی پایدار نیست، اما بدست آوردن و نمایش موفقیت در این حوزه باعث ایجاد تمایل بیشتر برای سرمایه‌گذاری های آتی و بدست آوردن مهارت هایی در ناحیه های بعدی می‌شود. همچنین این ناحیه برای تیم هایی خوب است که به نگهداری بلند مدت از نرم‌افزارهای خود نیاز ندارند.برای تیم هایی که نیاز دارند نرم افزار خود را به صورت بلند مدت نگه داشته یا بهبود دهند ناحیه Delivering می تواند انتخاب بهتری باشد. این ناحیه در واقع نمایانگر پایداری چابک است. تیم‌های فلوئنت در این ناحیه باگ کمتری دارند، بازدهی آنها بالا بوده و نسبت به درخواست های کسب و کار پاسخگو هستند. فلوئنت بودن در این ناحیه می تواند برای بسیاری از تیم‌ها جهش بزرگی محسوب شود.سازمان هایی که می‌خواهند با سرعت تغییرات بازار هماهنگ باشند یا حس می کنند که تغییرات مهلک بازار می تواند بقای آنها را به خطر بیاندازد ناحیه Optimizing می تواند انتخاب بهتری باشد. در واقع ناحیه Optimizing وعده اصلی چابک است. چابکی کسب و کار به همراه خلاقیت. گرچه این ناحیه باعث بوجود آمدن منافع زیادی برای کسب و کار می شود ولی نیازمند تغییرات اساسی در ساختار سازمانی خواهد بود. انجام چنین تغییراتی معمولا در سازمان های کوچک راحت تر است.ناحیه Strengthening برای سازمان‌هایی است که مدیران و رهبران به دنبال خلاقیت حداکثری در سازمان هستند و معمولا این اتفاق در سازمان های کوچک و متوسط امکان پذیرتر است. در واقع این آینده چابک است یعنی جدیدترین تکنیک های چابک در همین مسیر در حال حرکت هستند. اما نکته احتیاطی در این جا است که رسیدن به این ناحیه نیاز به تحقیقات بسیاری در خصوص آخرین سبک های مدیریت و سرمایه‌گذاری سنگین برای اجرایی کردن این سبک های جدید کاری خواهد داشت.بر اساس فرصت/چالش اصلی انتخاب شده برای امید، ما ناحیه دوم یا Delivering را انتخاب کردیم اما نیم نگاهی هم به ناحیه Optimizing داشتیم که در صورت پایداری بتوانیم تارگت آینده ما آن باشد، اما تمرکز اصلی در این دوره بر روی ناحیه Delivering بود.اما چرا ناحیه Deliveringانتخاب شد؟متریک اصلی این ناحیه بر اساس تعریف خود مدل اجایل فلوئنسی این است: " تیم می‌تواند آخرین کار خود را با کمترین ریسک و هزینه هر زمان که کسب و کار درخواست داد ارائه کند." و منفعت دیگر "سطح خرابی ها در سیستم پایین است، بنابراین تیم زمان کمتری برای رفع باگ‌ها به هدر خواهد داد و زمان بیشتری در راستای بهبود می‌تواند استفاده کند." و مورد بعد "سطح پایین خرابی‌ها و بدهی فنی بر روی میزان رضایت شغلی و روحیه افراد تاثیر گذار بوده و باعث ماندگاری و افزایش بازدهی افراد تیم‌ها شده است."خوب این موارد دقیقا همان مواردی بود که ما برای فرصتی که کشف کرده بودیم لازم داشتیم. پس بر اساس همین، ناحیه دوم انتخاب شد. نکته مهم: ناحیه Delivering بر پایه ناحیه Focusing استوار است. یعنی شما باید در مسیر، حتما به تمرینات این ناحیه نیز سر بزنید.خوب در هفته اول ما فرصت را کشف کرده بودیم، و تارگت خودمان را نیز انتخاب کرده بودیم، الان زمان دیاگ زدن بود.مرحله دوم: دیاگ زدندیاگ یک ابزار مخصوص تسهیل گران مدل اجایل فلوئنسی است. کار کرد این ابزار این است که، فاصله شما را با ناحیه ای که تارگت کردید را مشخص می کند یا بعبارت ساده تر مانند یک جی پی اس مشخص می کند که شما کجا هستید و چه مسیری را برای رسیدن به آن تارگت انتخاب شده باید بپیمایید.دیاگ زدن تیم های امید در قالب یک ورکشاپ انجام شد، و نتیجه برای تیم و مدیران ارشد در قالب یک گزارش آماده شد. مهمترین کارکرد این گزارش این است که مدیریت می داند که چه کاری باید برای حمایت از تیم در مسیر انجام بدهند، و خود تیم نیز بداند که چگونه باید مسیر را طی کند.با توجه به شرکتی بودن موارد این دیاگ، جزئیات زیاد آن قابل انتشار نیست.مرحله سوم: دست یابی به فرصتگام بعد از دیاگ زدن، حرکت به سمت تارگت انتخاب شده بود، یعنی در مرحله اول تارگت خودمان انتخاب کردیم، در دیاگ زدن، درک کردیم کجا هستیم و الان زمان حرکت و دست یابی به فرصت ها بود. این مرحله در واقع همان مرحله مربی گری تیم ها و مدیران است.در خواست ما از مدیران، برای تارگت ناحیه اول یا همان Focusing (که زیربنای تارگت اصلی ما بود)، موارد زیر بودند:● محیط مناسب که متمرکز بر بازدهی بالا دارد (به خصوص اتاق مخصوص تیم) ایجاد کنید.● مطمئن شوید که شخصی با تخصص در حوزه کسب و کاری و آشنا به ارزش های مشتری در دسترس بوده و به عنوان نماینده کسب و کاری تیم عمل نماید.● سعی کنید موانع کار تیمی موثر را برطرف نمایید مانند رتبه بندی رقابتی، پاداش های انفرادی.● اعضای تیم را در مورد مهارت های Focusing آموزش داده و زیر نظر مربی قرار دهید.● مدیران را آموزش بدهید تا آن ها محیط مناسب جهت کار تیمی را ایجاد نمایند و به جای مدیریت افراد به دنبال مدیریت سیستم های کاری باشند.مدیران همکاری خوبی در تمامی موارد انجام دادند، مثلا شکستن تیم ها به تیم های محصول یکی از کارهایی بود که انجام دادیم، یا اینکه اعضای تیم محصول دور هم سر میز مشترک نشستند. یا اینکه مدیران به جایی پیگیری کار از شخص که قبلا روال بود، سعی کردند کار را از تیم بخواهند. در نهایت نزدیک به ۸ تیم جدید محصول محور شکل گرفت و ساختار تیم ها نظیر Role and Responsibility، چارت ساختار تیم، ماتریس شایستگی و اهداف و ماموریت تیم ها توسط افراد هر تیم مشخص شد.ساختار تیم های محصول محوردر سطح تیم نیز، تیم فرآیندهای اسکرام و کانبان را شروع کرد، جلسات برنامه ریزی اسپرینت و بازبینی و بازنگری اسپرینت شروع شد. از طرف دیگر بردهای فیزیکی برای هر تیم ایجاد شد و ... .متاسفانه خیلی از شرکت ها در این مرحله استاپ می شوند، و معمولا تصویر خیلی از دوستان از چابکی، فقط همین اندازه است، ولی این ناحیه، تارگت اصلی نبود حتی رسیدن کامل به آن دستاورد خاصی حساب نمی‌شد. تارگت اصلی ناحیه Delivering بود. برای این ناحیه بزرگترین چیزی که از مدیران انتظار داریم، زمان و زمان و زمان بود. مدیران اکثرا با خرج کردن پول مشکلی ندارند اما با سرمایه گذاری زمانی یا رفتاری مشکل دارند. نقطه قوت امید این بود که مدیرعامل پشتیبان این حرکت بود و حاضر بود اعتماد کند و سرمایه گذاری را انجام بدهد.این سرمایه گذاری به منزله کم تر شدن ظرفیت تیم برای انجام فیچرهای جدید برای چند ماه میشد.در سطح تیم، کارهای زیادی باید انجام میشد. اصلی ترین کار این بود که یک جاهایی از سیستم باید رفاکتور میشد، یک جاهایی باید از اول نوشته میشد، تست (از انواع مختلف به سیستم باید سیستم اضافه میشد)، اما یک خطری که امکان داشت اتفاق بیفتد این است که ما در دام رفاکتور بی انتها بیفتیم. برای این منظور ما از یک تکنیک ساده استفاده کردیم، بالای ۱۰۰ باگ اخیر سیستم را بررسی کردیم، معمولا باگ ها نشانه های خوبی از نقاط باگ خیز و شکننده سیستم برای ما است. بعد بر اساس این شواهد شروع کردیم، به آماده سازی لیست اولویت بندی شده از رفاکتورها.رفاکتورها و اضافه شدن تست به مرور در اسپرینت ها انجام میشد. اما باید می دانستیم این کارها منجربه کاهش میزان باگ ها میشود، به عبارت ساده اگر چیزی را نتوانیم اندازه بگیریم نمی توانیم آن را بهبود بدهیم. در شروع کار، یک ویجت گزارش باگ به سیستم اضافه کردیم که کاربران و تسترها می توانستند باگ های سیستم را گزارش کند و این باگ ها در جیرا خودکار ثبت می شد. عدد در هفته های اول باور نکردنی بود، ۳۰ تا ۴۵ باگ در هفته.اولین گام همراهی در تغییر، ایجاد حس اورژانس استوقتی اولین بار بچه ها این عدد و نمودار بالا را دیدن، واقعا برایشان باور کردنی نبود، "واقعا ما اینقدر باگ داریم ...". برخی اوقات برای ایجاد حس اورژانس شما نیاز دارید وضعیت واقعی را جلوی چشم بیاورید، همین.برای همراهی بیشتر اعضای تیم این عدد را تبدیل به چالش کردیم، که آیا می توانیم این را به صفر برسانیم؟ چالش 40 به 4. خود این عدد به صورت بصری روی یک مانتیور انداخته شد که جلوی چشم تیم ها باشد. حالا در هر اسپرینت کارهایی که انجام می شد، تیم بدنبال این بود که آیا این عدد کمتر شده است؟ یعنی رفاکتور هم بخاطر رفاکتور یا اینکه فلانی گفته کلین کد بنویسید نبود، بلکه برای افزایش کیفیت سیستم و رضایت مشتریان است.تاثیر کار را ببین، با قدرت تر جلو برویکی از کارهای جالب و موثری که کشف کردیم، این بود که تعدادی از کاربران محصول تیم، که در خود سازمان بعنوان تریدر مشغول به افزایش ثروت مشتریان بودند، را درگیر مساله کردیم. هر روز بعد از تایم بازار و در انتهای جلسات دیلی استنداپ، یکی از دوستان را صدا می کردیم، و دو تا سوال از آنها می پرسیدیم: ۱. امروز چند تا باگ ثبت کردید؟ ۲. به نظرتون نسبت به دیروز کیفیت سیستم بهتر شده است یا خیر؟ سوال اول عدد آمار بود و سوال دوم حس مشتری به سیستم بود. این پرکتیس باعث شده بود افراد فنی تیم، هر رفاکتور یا بهبود که در سیستم انجام می دهند دنبال نتیجه باشند که آیا امروز توانستیم در مشتری حس بهتری ایجاد کنیم و نکته جالب هم همین بود که با کاهش میزان باگ، دقیقا حس منتقل میشد.لیست استخراجی برای رفاکتور، یک لیست ثابت نبود و در طول اسپرینت ها و مشاهده نتایج تغییر می کرد. اما نتیجه باور نکردنی بود. در چهار ماه علاوه بر اینکه تیم توانسته بود این عدد رو تقریبا زیر ۴ برساند از سوی دیگر کار کردن بر روی فیچرها جدید را نیز شروع کرده بود.البته فقط رفاکتور کردن نبود، بلکه بدهی فنی دیگر نیز بود، مثلا کامل کردن مانتیورینگ سرویس ها، اضافه کردن هلث چک و مستند سازی بخش های مهم سیستم، ... جز بدهی فنی ها دیگری بودن که در پروسه انجام شدند. یا کلی اقدام دیگر اعم از ایجاد یک محیط تست شبیه پروداکشن، اضافه شدن تستر و ... . ولی مهم ترین نکته داشتن زمان و تمرکز و همراهی افراد فنی خوب در کنار تیم بود.بعد از دیدن نتایج و کاهش باگ، بشدت روابط انسانی افراد نیز بهبود پیدا کرد.امیرمهدی یکی از برنامه نویس های امید، گزارش کاملی از پرکتیس های فنی در اینجا نوشته است.اما نتیجه چه بود؟همانطور که اول گفتم، مشکل شرکت استفاده نکردن از اسکرام نبود، چیزی که شرکت لازم داشت یک محصول با کیفیت بود که در آن 1- اضافه کردن فیچرها به آن راحت تر شود 2- منجربه رضایت مشتریان شده 3- از سوی دیگر توسعه دهندگان نیز به کیفیت کار خود افتخار کنند.نمودار باگ گزارش شدهولی مهمترین نکته حس بچه های تیم بود، برای مثال این کامنت یک سری از بچه های فنی شرکت است:نتایج ملموس در طول پنج ماه برای کسب و کار،کاهش بشدت زیاد بدهی فنی، و توانایی تیم برای پرداختن به توسعه فیچرافزایش ملموس سطح اعتماد بین افراد تیم و لیدرهاافزایش میزان سود شرکت بر اثر توانایی جذب مشتریان و نگه داری مشتریان قبلیاز نکات مثبت امید این بود که مدیرعامل شرکت همراهی خوبی با ما در راستای تحول چابک انجام میداد.(واقعا بدون همراهی واقعی تحول چابک امکان پذیر نیست)، مثلا یکی از اقدامات مثبت مدیریت، توافق نامه ای برای هدایت عملکرد کل لیدرهای سازمان طراحی شده بود که ایشون زمان خوبی هر هفته برای دادن و گرفتن فیدبک صرف می کرد و مابقی تایم را به حل دغدغه های لیدرها می پرداخت. تقریبا این جمله بین لیدرها و مدیران کامل جا افتاده بود که “انسان ها و روابط شان فراترند از فرآیندها و ابزارها ”.بخاطر اینکه، اصلی ترین ذینفع ما در این پروژه، شخص خود مدیرعامل بود، از ایشون درخواست کردم که در یک جمله نظرشون رو در خصوص نتیجه پروژه انجام شده داشته باشم:“گاهی اوقات در سازمان افراد دچار سوگیری قضاوتی می شوند. فرض کنید شما یک سیستم پیشرفته پیاده سازی می کنید و بعد از ۲ سال تمامی راه حل ها و معماری هایی که کنار هم چیده اید شبیه به فرزندتان هستند. به دلیل sunk cost و گذشته ای که از این ماژول ها میشناسید، سازمان در تصمیم گیری محتاط می شود و ممکن است یک تصمیم اشتباه گذشته را به خاطر هزینه هایی که برایش کرده ایم ادامه دهیم. در این نقاط حتما باید یک فرد متخصص و باتجربه به سازمان وارد شود و با reference point جدید اطلاعاتی، شروع به قضاوت کند و تصمیمات بهتری برای پروژه های اشتباه یا پرخرج بگیرد. شما اسدجان به خوبی این کار رو انجام دادید. درک عمیق از روابط انسانی، پیدا کردن ریشه مسایل به جای پرداختن به شاخ و برگ ها، حضور مداوم در تیم ها و تجربه شگرف و شناخت مشکلات کار تیمی در ایران باعث شد، چالش های قبلی که در امید بود کاملا محو شود. واقعا از شما متشکرم.”آینده امید چگونه است؟نکته مهم در تحول سازمانی، این است که از اول بدانیم، تحول یک پروژه نیست. یعنی پایانی ندارد. تحول یک سفر بی انتها است که بالا و پایین زیادی خواهد داشت. بخصوص تا نقطه فلوئنسی فاصله زیادی وجود دارد، یعنی بسیاری از این تغییرات برای همیشه پایدار باشند، من در ابتدای این سفر همراه دوستان امید بودم و امیدوارم این مسیر همچنان در آینده توسط خود دوستان ادامه داشته باشد.چابک و موفق باشیداسد صفریاین نوشته قبلا در این آدرس نیز منتشر شده بود.نوشته های بیشتر در حوزه چابک انجمن چابک ایران اسد صفری Sat, 07 Dec 2019 11:41:44 +0330 https://virgool.io/IranAgile/better-planning-vvfttueipwit در گذشته روش های توسعه نرم افزار معمولا Plan-driven بودند یعنی در ابتدای پروژه زمان زیادی (مثلا نصف زمان پروژه) صرف تحلیل و طراحی پروژه می کردیم و در نهایت با داشتن یک طرح کامل می توانستیم پیاده سازی را شروع کنیم. اما به تدریج با زیر سوال رفتن این روش ها (که اثبات کردند طراحی های پیچیده قابل پیش بینی نیستند و باید در مرور زمان و در خلال پیاده سازی پروژه کشف شوند) و ظهور روش های برنامه ریزی تجربی گرا مانند اسکرام، ما دائما در روند پروژه درحال برنامه ریزی هستیم.اما مشکل این است که این روش خود مشکلات اساسی برای تیم های برنامه‌نویسی ایجاد می کند؛ چون ما مجبوریم دائما در حال برنامه‌ریزی باشیم و همیشه در طرح هایی که بوجود می‌آوریم جای صحبت و تغییر را باقی می گذاریم و در اینصورت است که انرژی بسیار زیادی از ما گرفته می شود.دلیل اینکه چرا این موضوع برای من مهم شد، این است که : در تیم های اخیری که با آن ها بودم شاهد این هستم که ما یک روز و یا کمی کمتر یا بیشتر برای برنامه ریزی وقت صرف می کردیم، ولی در انتهای روز چندین موضوع بودند که در مورد آنها نتیجه گیری نشده است، یا آنقدر همه تیم خسته شده بودند که بعبارتی ماسمالی کرده بودیم و در هنگام پیاده سازی کلی مشکل بخاطر برنامه ریزی ضعیف به وجود می‌آمد.همه ما معتقد هستیم که برنامه ریزی خوب در اول یک اسپرینت دقیقا مثل یک سال بخور نون و تره، یک عمر بخور نون کره است، یعنی هر چقدر در این جلسه بتوانیم خرد جمعی را بکار بگیریم و مسائل را از زوایای مختلف نگاه کنیم، راه حل های بهتر و خلاق تری کشف خواهند شد و درپیاده سازی سریعتر و بهتر عمل خواهیم کرد.نیروی اراده باعث این مشکل می شود؟همه اذعان دارند که ما خسته شدیم و این خسته گی باعث این قضیه می شود ولی برای خود من سوال بود که اصلا چرا خسته می شویم و آیا این دلیل علمی دارد؟ برای همین تحقیقاتی در این مورد کردم و به یک کتاب عالی برخوردم، Willpower یا نیروی اراده.نیروی اراده، انرژی ذهنی است که باعث متعادل شدن احساسات، عملکرد و رفتار ما می شود. یعنی به عبارتی این انرژی باعث می شود که ما عاقلانه فکر و عمل کنیم  و اگر این انرژی ته بکشد ما شاید رفتارها یا کارهای خارج از عرف و عقل انجام بدهیم یا تصمیم هایی بگیریم که بعدها از انجام آن پشیمان شویم (و اسمش رو بگذاریم چون خسته بودم یا حوصله نداشتم گفتم این کار را انجام دادم ).  نیروی اراده یک انرژی است، پس صرفا یک چیز انتزاعی نیست و واقعیت دارد. این انرژی هم مثل برخی از منابع انرژی پایان پذیر و بسیار محدود است. هر زمان این انرژی ته می کشد، کنترل امور ذهن و افکار به بخش ناخودآگاه مغز که آن هم به صورت خودکار و خیلی نه عاقلانه ما را کنترل می کند سپرده می شود. با انجام کارهای فکری (هر کاری که نیاز به تصمیم گیری و فکر دارد) مقداری از این انرژی مصرف می‌شود (مقدار بستگی به موضوع و نوع بحث دارد) هر چقدر از یک موضوع فکری دور شویم و به استراحت بپردازیم، دوباره انرژی شروع به پر شدن می‌کند و کنتور انرژی بالا می رود.سوال، آیا ما دائم در طی روز کار فکری می کنیم؟ جواب: نه. بسیاری از کارهای ما، حتی کارهای تخصصی، تبدیل به عادت شده اند. کاری که تبدیل به عادت شده باشد بسیار انرژی کمی میسوزاند.اما نکات کلیدی برای جلسات برنامه ریزی:1- با شکم خالی جلسه برگزار نکنیدبدترین زمان برای جلسات زمانی هست که تمام اعضا حاضر در جلسه گرسنه هستند، همان زمانی که هرکس در حال سوزاندن گلوکز می باشد و منجر به ایجاد احساس گرسنگی و ضعف می شود، به همین خاطر زمانی که گرسنه هستیم بدترین زمان برای انجام کار فکری است. بعلاوه بدلیل پایین آمدن گلوکز یا همان قند خون، بهترین چیز این است که در همان اتاق جلسه شکلاتی یا چیزهای شیرینی باشد تا این قند خون تقویت شود.2- قبل از جلسه برنامه ریزی، جلسه باید آماده شده باشدموضوعاتی که قرار است در جلسه روی آنها صحبت شود باید قبل از جلسه آماده شده باشند، آمادهشدن یعنی اینکه، مالک محصول باید بداند که هدف او در اسپرینت بعد چیست؟ چه کارهایی قرار است برای رسیدن به هدف انجام شود(از نظر ویژگی های نرم افزار) در مورد نیازمندی های اسپرینت  حتما با مشتری ها یا ذی نفعان صحبت کرده باشد تا دقیقا مشخص شود که نیازمندی چیست؟ (این به معنی این نیست که تا ته پروژه باید همه کارها را در یک روز انجام بدهد، بلکه به مرور و همگام با تیم نیازمندی ها باید شفاف شوند) سعی شود شرایط پذیرش کار تا آنجایی که امکان پذیر هست مکتوب شده باشد و منتظر جلسه نشویم3- انرژی محدود است پس اولویت بندی لازم استهمانطور که گفتیم انرژی کار فکری بسیار محدود است، بخصوص اگر تعداد نفرات جلسه یا تنوع فکری نفرات زیاد باشد. پس یکی از کارهای مهم این است که چند مورد مهم جلسه که حتما باید درمورد انها به نتیجه برسیم باید اولویت بندی شده باشد. یعنی ابتدا سعی نکنیم قورباغه را قورت بدهیم بلکه سعی کنیم از اولویت بالا شروع کنیم.4- تایم باکس باشیم یکی از سخترین کارها در جلسات رعایت تایم باکس است، ولی اگر ما محتوای جلسه را ابتدا اماده کنیم و دوم اولویت بندی کنیم، خواهیم توانست که متمرکز شویم و آیتم های اولویت بالا را برنامه ریزی کنیم. نگران این نباشید که به نتیجه نرسیدیم، هر چیزی نیاز به هزینه دارد، و با تمرین خواهیم توانست به آن برسیم.5- ما در طول اسپرینت هم در حال برنامه ریزی هستیمبعضی از موضوعات واقعا نیازی نیست در جلسات برنامه ریزی روی آنها زمان زیادی بگذاریم، بهترین زمان جلسات روزانه است که در طول روزها بتوانیم با صحبت مختصر به نتیجه برسیم.6- Swarm کنیدشاید در طول اسپرینت نیاز به یک کار فکری باشد و این هم نیاز به خرد جمعی باشد، بهترین کار این است که یک جلسه با حضور همه یا بخشی از نفرات تیم برگزار شود، این جلسه نیز باید 1- تایم باکس باشد 2- فقط حول و حوش یک موضوع خاص باشد 3- زمانبدی شروع خوبی داشته باشد7-  جلسه نیاز به تسهیل گر داردبهترین متخصص های دنیا هم اگر در جلسه ای باشند،آن جلسه نیاز به تسهیل گر دارد یعنی کسی که بیشتر از موضوع جلسه به فکر کیفیت جلسه باشد. این نفر باید بتواند موضوع جلسه را باز کند، نفرات را به سمت تصمیم گیری هدایت کند و جلسه را ببندد. بعضی وقت ها، روی یک موضوع باید بیشتر بحث شود، بعضی وقت ها نظرات کسانی که حرف نمی زنند باید پرسیده شود، بعضی وقت ها جلسه به گره می خورد باید برویم سراغ موضوع بعدی، یا از روش شش کلاه فکری یا هر روش دیگری استفاده کنیم .امیدوارم که برای دوستان مفید بوده باشدچابک و موفق باشیداسد صفریاین نوشته قبلا در این آدرس منتشر شده بود انجمن چابک ایران اسد صفری Mon, 23 Jul 2018 23:31:00 +0430