fa-IR
گزارش کارگاه تفکر چابک و متد اسکرام در استارت‌آپ‌ها

گزارش کارگاه تفکر چابک و متد اسکرام در استارت‌آپ‌ها

کارگاه مبانی به‌کارگیری تفکر چابک و متد اسکرام در استارت‌آپ‌ها روز سه‌شنبه ۲۷ تیر‌ماه ۱۳۹۶ از ساعت ۱۶ تا ۲۰ در مرکز توانمندسازی و تسهیل‌گری کسب‌وکارهای نوپای فاوا برگزار شد

در این کارگاه خانم مریم عبدی مدرس کارگاه ضمن معرفی خود و این‌که ۱۴ سال از زندگی خود را در کشور سوئد بوده و در آنجا تحصیل کرده است. تجربه کاری خود را ۱۰ سال عنوان کرد و این‌که ۸ ماه است در شرکت رهنما به‌عنوان اسکرام مستر مشغول به کار است. در ادامه ارائه خود را به این صورت آغاز کرد:

مفهوم لین در ابتدا توسط شرکت تویوتا معرفی شد زمانی که ژاپن بعد از جنگ جهانی دوم هم چیز خود را ازلحاظ مالی از دست داده بود و می‌خواست کارش را شروع و دوباره به چرخه زندگی عادی برگردد و در آنجا بود که متوجه شد برای شروع کار با کمبود منابع روبه‌روست و سوال مطرح شده این بود که چگونه بتواند کار را شروع کرده و وارد بازار شود؟ درنتیجه آن‌ها تصمیم گرفتند روی مشتری تمرکز کنند و با خود گفتند «ما آن‌قدر منابع نداریم که اول تولید کنیم و یا این‌که انواع خیلی زیادی از محصول را به بازار بدهیم، چون ممکن است اصلا کسی خریدار محصولی ما نباشد». پس ژاپن مفهوم این‌که مشتری در ابتدا قرار بگیرد را در دستور کار خود قرار داد و این‌که ما ارزش را به مشتری بدهیم. درواقع همین لکزوزی که تویوتا به آمریکا داد از همین‌جا ناشی شد. تویوتا یکسری از کارکنان خود را به آمریکا فرستاد تا ببینند آمریکایی‌ها چه نوع اتومبیلی را سوار می‌شوند، چون می‌خواست دقیقا محصولی را تولید کند که مطمئن باشد آمریکایی‌ها آن را می‌خرند. این یکی از مفاهیم اصلی تفکر لین است. دومین مورد که در لین مطرح است احترام به افرادی است که ما با آن‌ها کار می‌کنیم، یعنی مردمی که برای ما کار می‌کنند برای ما قابل‌احترام هستند و باید آن‌ها را در تصمیم‌گیری دخالت دهیم و این‌که نظر آن‌ها مهم است و باید به آن‌ها قدرت داد تا در پروسه توسعه به ما کمک داده و مشارکت داشته باشند و سومین موضوع مطرح در لین کاهش کارهای اضافی ست یعنی هر آن‌چه زیادی است باید از بین ببرید منظور از چیز اضافی چیزی است که در راه تولید هیچ ارزشی رو به محصول ما اضافه نمی‌کند حالا این ممکن است از طریق جابجایی وسایل در شرکت باشد مثلا ممکن است کارمندان برای این‌که به اطلاعاتی دسترسی داشته باشند باید چندین طبقه را جابه‌جا شوند که با جابه‌جایی افراد و وسایل کار بهینه‌تر و کار اضافی پایان می‌یابد و یا این‌که ممکن است خود محصول در بخش‌های مختلف یک شرکت خیلی جابه‌جا شود که باید این موارد شناسایی شوند و با انجام کار مناسب از چرخه تولید حذف شوند. مورد چهارم ارتقای دائم فرآیندها است یعنی ما باید دائماً فرآیند‌های تولید خود را بهینه کنیم. یک شرکت هیچ‌وقت نمی‌تواند بگوید ما در بهترین حالت هستیم چراکه جامعه تغییر می‌کند، محصولات تغییر می‌کنند و شرایط عوض می‌شود و ما برای این‌که همواره بازار را در دست خود داشته باشیم الزاما باید هر دفعه فرایندها را بهتر کنیم.

مدیریت در لین ۵ فاکتور دارد. فاکتور اول این‌که بگذارید ابتدا مشتری از شما بخواهد بعد شما تولید کنید یعنی اول تولید نکنید بعد با کلی محصول بگویید حالا می‌خواهم وارد بازار شوم. چراکه در این صورت هم انبارها پر می‌شود و هم بیشتر از نیاز، ممکن است تولید کرده باشید و هم این‌که هزینه بالایی دارد دومین فاکتور در مدیریت لین این است که یک محصول را در ابتدا در چرخه قرار دهید و پس از اتمام این چرخه برای محصول فعلی، محصول بعدی را در چرخه تولدی قرار دهید چراکه در حالتی که یک محصول را در چرخه تولید قرار دهیم تمرکز کارکنان روی محصول بیشتر می‌شود. همچنین زمان هدر رفت کار کمتر می‌شود. وقتی ما هم‌زمانی تولید زیادی داشته باشیم ممکن است کلی چیز در یک بخش تولید و در بخش دیگری از کار این موارد در انتظار باشد؛ و همچنین وقتی تمرکز کارمندان کم شود کیفیت محصول نیز پایین می‌آید پس برای جلوگیری از این موارد باید روی یک محصول کار کرد و در نوبت بعدی سراغ محصول دیگر رفت. سومین فاکتور تاکتیک است. درواقع ریتمی که ما محصول را تولید می‌کنیم مهم است. تاکتیک مانند ضربان قلب تفکر لین است که اگر نتوانیم هماهنگی بین بخش‌های تولید ایجاد کنیم باعث می‌شود تغییراتی که در دنیای بیرون اتفاق می‌افتد را درک نکنیم ولی اگر یک همزمانی در تولید نداشته باشم فرصت دیدن بیرون و تغییرات آن را خواهیم داشت و در صورت وجود تغییرات بیرونی می‌توانیم آن را در کار خود در نظر گرفته تصمیم مناسب را بگیریم و از رقبا عقب نمانیم. فاکتور چهارم به صفر رساند نقص هست یعنی هیچ مشکل کوچکی هم در سیستم نباشد. دراین‌باره یکی از نکته‌های مهمی که در کتاب‌هایی که راجع به تویوتا می‌نویسد وجود دارد این است که یک سری دکمه‌های قرمزرنگی در کل خط تولید تویوتا وجود دارد که هرکسی فرقی نمی‌کند ساده‌ترین کارگر باشد و یا حرفه‌ای‌ترین مهندس که کوچک‌ترین مشکل در این خط تولید دید می‌تواند این دکمه را فشار دهد و همه افراد باید در جهت رفع آن مشکل دیده شده اقدام کنند؛ یعنی هیچ محصولی در صورت کوچک‌ترین نقص کوچکی از آن قسمت خارج نمی‌شود تا آن مشکل در قسمت مربوط رفع شود این کار به این دلیل است که وقتی محصول به آخرین مرحله می‌رسید بدون نقص باشد نه این‌که محصول یک پروسه گران‌قیمت را در ابتدا طی کند و در انتها تازه متوجه شویم که قسمتی از محصول دارای نقص است و باعث ضرر بیشتر شده است؛ و آخرین فاکتور از اصول مدیریت لین ارتقای دائم است که ما همیشه باید در حال ارتقا و پیشرفت باشیم این مورد هم در زمینه فرایندهای انجام کار باید در نظر گرفته وهم توانایی کارکنان چراکه این دو باعث می‌شود در رقابت با دیگران موفق شویم.

این مسئله که ما اتلاف وقت را کمتر کنیم خیلی مهم است چراکه در فرآیندهای تولید، ۸۵ درصد اتفاقات که در این فرآیند انجام می‌گیرد هیچ ارزشی را به محصول اضافه نمی‌کند و باید این موارد شناسایی و حذف شوند و درواقع ۵ درصد این مراحل ارزش افروده به تولید می‌دهد و ۱۰ درصد دیگر نیز تقریبا بودن و نبودنش خیلی فرقی نمی‌کند و جز ساختار شرکت هستند. پس بهتر است هرچند وقت یک‌بار پروسه تولید خود را مرور و بررسی کنید و در هر قسمتی که محصول شما از آنجا رد می‌شود از خود بپرسید آیا واقعا این مرحله نیاز است و تغییر و ارزشی به محصول می‌دهد و یا یک کار اضافی است که می‌تواند حذف شود؟ البته ما هیچ‌وقت نمی‌توانیم اتلاف را ۱۰۰ در ۱۰۰ از بین ببریم چراکه یکسری مراحل هستند که به دلیل ساختار وجودی آن شرکت به وجود آمده‌اند و حذف این موارد ساختار شرکت را به هم می‌ریزد و قابل‌حذف نیست برای مثال برخی شرکت‌ها میگویند قبل از این‌که محصول از شرکت خارج شود باید مدیرعامل آن را تایید کند که این مورد به ساختار شرکت مربوط می‌شود که قابل‌حذف نیست اما ۸۵ درصد باقی مانده می‌تواند حذف شود پس تا جایی که می‌توانیم باید اتلاف را کمتر کنیم.

پیش‌ازاین برای توسعه نرم‌افزار از متد آبشاری استفاده می‌شد و ۸۰ درصد نرم‌افزار‌ها یا با کلی مشکل و یا تاخیر وارد بازار می‌شدند. در این مدل با مشتری نشسته و صحبت می‌شد و تمام درخواست‌ها را می‌خواستیم از ۰ تا ۱۰۰ از او بگیریم درواقع به مشتری گفته می‌شد که برایمان بگو که دقیقا چه چیزی می‌خواهی؟ اما این کار ماه‌ها زمان می‌برد تا تمام توانمندهای لازم سیستم را خود مشتری برایمان بنویسد و بعد آن نیازمندی‌ها تجزیه تحلیل می‌شد و این‌که چطور می‌توان آن مشکل را از منظرهای مختلف مانند سخت‌افزاری و نرم‌افزاری و نحوه عملکرد برطرف ساخت سپس خروجی این قسمت وارد بخش و دپارتمان توسعه می‌شد که کد و برنامه موردنظر را بنویسند تا همین‌جای کار توسعه‌دهنده برنامه دو مرحله از مشتری دور شده و این‌که آن چیزی که او فهمیده دقیقا آن چیزی است که مشتری می‌خواهد مشخص نیست. بعد از نوشتن برنامه توسط توسعه‌دهنده، برنامه به قسمت تست و ارزیابی می‌رفت و این بخش نیز سیستم را از دیدگاه خودشان (نه مشتری) ارزیابی و تست می‌کردند درصورتی‌که از دید این بخش برنامه درست کار می‌کرد آن را به بخش گسترش می‌رفت که بخش پایانی تست سیستم نیز در آن قسمت انجام می‌شد و در انتها محصول به مشتری ارائه می‌شد و در این مرحله مشتری شروع به کار با نرم‌افزار می‌کرد و در صورت مشکل دوباره به همین چرخه بازمی‌گشت و این مورد مستلزم طی کردن همین مراحل و با هزینه‌های بالابود. با توجه به وجود این مشکل و زمان زیادی که طول می‌کشد که کار انجام شود و حتی ممکن است توسعه‌دهنده از آن بخش هم رفته باشد و حال باید کس دیگری همین کار را از ابتدا فهمیده و مشکل را رفع کند. کار به‌شدت گره می‌خورد و انجام کار بسیار سخت می‌شد. این توضیح نشان می‌دهد که این مدل چقدر زمان‌بر و بسیار پرهزینه خواهد بود. پس متد پله‌ای یا آبشاری برای یک شرکت تولید نرم‌افزار زیاد مناسب نبود.

چراکه مشتری از ابتدا فقط نیاز را می‌گوید و جزییات را نمی‌داند – توسعه‌دهنده که از مشتری می‌شنود گمان می‌کند که همه‌چیز را فهمیده درصورتی‌که به‌طورکلی همه افراد نه خوب بیان می‌کنند و نه خوب می‌شنوند و در هر دو طرف انتقال، بی‌تردید نقصی وجود خواهد داشت.

مشکل دیگری هم که وجود دارد مدیریت زمان و برنامه‌ریزی است که توسعه‌دهنده مثلا می‌گوید برای انجام این کار ۳ ماه زمان نیاز است و مشتری آن را طی دو ماه می‌خواهد و درنهایت شاید بعد از ۴-۵ ماه محصول تحویل داده شود که حتی بسیار امکان این بالاست که کیفیت محصول نیز اصلا چیز خوبی نباشد. یا مثلا در موادی مشتری درخواست را داده و با فرض این‌که قرار است همین محصول به او داده شود با توجه با بررسی‌هایی که مشتری از بازار خودش انجام می‌دهد هر دفعه نیازهای خود را تغییر و بیشتر می‌کند و این باعث اختلال کار توسعه‌دهنده و مشکلات بین طرفین هم می‌شود و در این حالت‌ها کم‌کم به خاطر عدم اعتماد طرفین کیفیت کار نیز پایین می‌آید و دراین‌بین دقیقا مشخص نمی‌شود که مشکل از کجای کار است که محصولی با هزینه بالا یا زمان زیاد و یا کیفیت پایین ساخته شده است؛ که معمولا در شرکت‌ها توسعه‌دهنده را مقصر می‌دانند؛ اما مشکل جای دیگری این است.

پس در فرآیند تولید نرم‌افزار نیازمندی‌ها درست درک و بیان نمی‌شود و همچنین نیازمندی‌ها در طول تولید محصول تغییر می‌کند که دلیل این تغییرات همیشگی محصول تغییرات در فضا و شرایط دنیای دیجیتال است و دلیل آن نیز موضوع تغییر همیشگی تکنولوژی همچنین بازار است

در ادامه باید گفت امروزه فرآیندها در حال تغییر است اما در گذشته توافق بین طرفین راحت‌تر بود، چراکه محصولات خیلی دیربه‌دیر تغییر پیدا می‌کرد و تکنولوژی سریع آپدیت نمی‌شد و امروزه چنین چیزی کمتر امکان دارد و دلیل آن تغییرات سریع و غیرقابل‌پیش‌بینی است.

اما یک روش علمی برای مقابله با این تغییرات و انعطاف در مقابل آن‌ها وجود دارد که می‌گوید بجای این‌که روزها وقت بگذاریم که نیازمندی‌ها را بنویسم و آن‌ها را طی این فرآیند فرسایشی و طولانی ساخته و به مشتری بدهیم باید محصول را در چرخه‌های کوچک تولید کنیم و به دست مشتری بدهیم و بازخورد را از مشتری بگیریم و همین‌طور ادامه دهیم و کم‌کم محصول را پیچیده و پیچیده‌تر کنیم. این باعث می‌شود که مشتری نیز همواره چیزی که تحویل می‌گیرد را بررسی می‌کند و ممکن است حتی بعد از سه چرخه کوچک تولید و ارائه محصول به مشتری، کار انجام پروژه تمام شود و حتی بقیه درخواست‌هایی که مشتری قبلا گفته بود را اصلا نیاز نداشته باشد. خود من هم چنین تجربه‌ای دارم در شرکت دلفای که بودم ما محصولی به نام active safety به اتومبیل‌هایی مانند ولوو و رنو می‌دادیم، رنو وقتی درخواست خود را داد مقادیر بسیاری درخواست را نوشته بود که ما نیز آن را مطالعه و به آن‌ها گفتیم هر دو ماه به شما یک نرم‌افزار داده می‌شود که آن را تست کنید. در ادامه شرکت ما همین کار را برای رنو انجام داد و بعد از یک سال شرکت رنو برای محصول ۲۰۱۶ خود در active safety ۵ ستاره را اخذ کرد؛ و همان‌جا درخواست را تمام کرد و الباقی درخواست‌ها را متوقف کرد و گفت که بقیه درخواست‌ها در مدل‌های اتومبیل دیگرش برای سال ۲۰۱۷ انجام شود. پس درواقع همین دادن محصول در چرخه‌های کوچک باعث می‌شود هم خود مشتری برد کند و هم نرم‌افزار نویس که در زمان کوتاه‌تر کار را انجام داده و به سرانجام رسانده است.

 

تفکر چابک

معنی لغوی agility این است که سریع و آسان انجام دهیم. agility به ما کمک می‌کند که به تغییرات سریع پاسخ دهیم اما ریسک آن را نیز مدیریت کنیم

همان‌طور که در شکل بالا می‌بینید در این مثلث ما ۳ مورد را داریم: زمان، چهارچوب و هزینه که نتیجه برآیند آن کیفیت را می‌سازد و ما باید در تولیدات خود همیشه کیفیت را داشته باشیم؛ و داشتن کیفیت مستلزم داشتن این ۳ است.

اما منظور از مدیریت ریسک چیست؟ یعنی این‌که مثلا وقتی مشتری نیاز خود را می‌گوید و زمانی را می‌دهد که محصول را دریافت کند یعنی شما را در حوزه زمان محدود کرده است اما باید ریسک آن را هم بپذیرد یعنی چهارچوب را نیز کوچک‌تر و محدودتر کند مثلا اگر شما ۳ ماه فرصت دارید که محصول را به مشتری برسانید و ۱۰۰۰ مورد درخواست و عملکرد برای این محصول وجود دارد، اما باید چهارچوب را محدودتر کند و نمی‌تواند تمام این ۱۰۰۰ مورد را در آن زمان محدود شده از شما بخواهد چراکه اگر این کار را نکند کیفیت محصول پایین می‌آید یا اصلا شاید نخواهد آن‌قدر هزینه کند و منابع کم دارد یا برعکس بگوید که من تمام ۱۰۰۰ درخواست را می‌خواهم پس باید زمان را در اختیار قرار دهد که ممکن است حتی یک سال طول بکشد که همه این موارد انجام شود. پس چه در زمان کم و چه زمانی که چهارچوب و درخواست بالاست شما باید کیفیت محصول را حفظ کنید. پس یادمان باشد در تفکر چابک همیشه باید کیفیت را در نظر گرفت. تفکر چابک زیرشاخه تفکر لین است و لین می‌گوید که مشتری اول است؛ و اگر در لین زمان‌های اتلاف را از بین ببرید خودبه‌خود در تفکر چابک سرعت و کیفیت ظاهر می‌شود و نیاز نیست مراحل مهم که کیفیت را به محصول شما می‌دهد نادیده گرفته شده یا کمتر موردتوجه قرار گیرد. پس دقت داشته باشید که ما برای سرعت باید زمان اتلاف را کم کنیم نه کیفیت محصول را.

agility یک تفکر است که می‌گوید به‌صورت چرخه‌های کوچک و پیش‌رونده محصول را عرضه کنیم و هر دفعه از مشتری بازخور گرفته و در هر چرخه این بازخوردها را در چرخه‌های بعد استفاده و موردتوجه قرار دهیم که به آن تفکر چابک می‌گویند که جای اجرای پروژه با مدل آبشاری آمده است.

تفکر چابک چند مورد را مدنظر قرار می‌دهد که از لین به ارث برده که تک‌تک به آن‌ها اشاره می‌کنیم.
مشتری: اولا این‌که مشتری را در نظر گرفته و او را با خود همراه کنید و ببینید در هر چرخه چه چیزی را عنوان کرده و آن را مدنظر قرار دهید
ارزش محوری: دومین مورد ارزش محوری است یعنی واقعا به مشتری آن چیزی که برایش ارزش دارد را تحویل دهید مثلا زمانی وجود دارد که مشتری می‌گوید من فلان مورد را می‌خواهم که به محصول اضافه شود ارزش برای او قابلیتی است که می‌خواهد و وقتی می‌گوید من مورد اضافی دیگری نمی‌خواهم و فقط کیفیت می‌خواهم ارزش برای او کیفیت است که ما باید با توجه به صحبت‌های او چرخه بعدی را پیاده و اجرا کنیم تا دقیقا آن چیزی که برای مشتری ارزش است انجام دهیم و به او بدهیم.

بازخورد: باید سریع از مشتری بازخورد گرفته شده و با تکرار این کار را انجام دهیم.

تغییر: این‌که خود را برای هر تغییری در این تکنیک چابک آماده و با تغییرات محیطی همگام باشید

قدرت: باید به کارمندان خود قدرت بدهید تا بتوانید از سواد آن‌ها استفاده کنید وگرنه نمی‌توانید از آن‌ها درست استفاده کنید.

شناخت عدم اطمینان: ریسک مشکل را بپذیرید و با ارتباطات آن را دریافت کنید و برای آن راهکار ایجاد کنید

این‌ها چیزهایی که در تفکر چابک باید رعایت کنیم که هر فریم ورکی به ما ابزاری را می‌دهد تا بتوانیم به این موارد برسیم.

پس در تفکر چابک توجه داشته باشید که:

*حرف زدن رودررو با افراد را تا جایی که ممکن است به استفاده و ایجاد ابزار و فرآیند ترجیح دهید؛ که البته در ایران این مورد بیش‌ازحد نیز مورداستفاده قرار می‌گیرد که در یک شرکت باعث اختلال و مشکل در کار افراد نیز می‌شود.

*مهم این است که نرم‌افزار کار کند تا این‌که ما کلی مستندات در مورد محصولات و فرآیند و ساختار محصول داشته باشیم که این مورد نیز متأسفانه در ایران بیش‌ازحد انجام می‌شود به‌طوری‌که هیچ مستندی در شرکت‌ها وجود ندارد و با رفتن یک شخص از شرکت تقریبا همه‌چیز و همه کارها و وظایف و محصولات مربوط به او برای شخص بعدی کاملا نامفهوم و غیرقابل درک است. پس مستندسازی را تا حد لزوم باید انجام داد مثلا در داخل کد باید کامنت نوشت که اگر توسعه‌دهنده دیگری آن را دید متوجه کار شما بشود که در این حالت هم اطلاعات به افراد رسیده و یادگیری بیشتر می‌شود و اگر فرد جدید بیاید با خواندن آن‌ها راحت‌تر می‌تواند به شما بپیوندد.

*همکاری با مشتری: به‌طور هفتگی با مشتری جلسه بگذارید تا با هم به یک فهم و نیازمندی مشترک برسید چراکه مشتری دقیقا نمی‌داند چه می‌خواهد این همکاری و جلسات حتی گاهی لازم است هرروز باشد.

* طوری کار کنید که اگر مشتری نیازمندی جدید داد بتوانید آن را انجام دهید نه این‌که یک برنامه یک‌ساله بریزید که قابلیت انعطاف نداشته باشد چون بازار همیشه در حال تغییر است و ممکن است نیاز مشتری تا آن زمان تغییر کرده باشد و نیازمند این باشد که کار دیگری را انجام دهد و ما باید بتوانید طوری ساختار تولید نرم‌افزار بچینید که این کار را انجام دهید چراکه عملا متد‌های قدیمی در این دنیای سراسر تغییر بازار و فناوری بخصوص دیجیتال جواب نمی‌دهد، حال ممکن است در جای دیگر و فناوری‌های دیگری که خیلی کند تغییر می‌کند روش‌های قدیمی پاسخ‌گو باشد. برای مثال در شرکت بوم باردی که کار تولید قطار و راه‌آهن را انجام می‌دهد با توجه به این‌که فناوری در این حوزه با توجه به نیازش به امنیت، به‌کندی تغییر می‌کند روش‌های قدیمی و برنامه‌ریزی قبلی پاسخگوی این حوزه از صنعت هست و با روش آبشاری به راحتی انجام می‌شود این کار را انجام داد اما در دنیای دیجیتال اصلا چنین چیزی امکان ندارد البته توجه داشته باشید که این مورد بستگی به‌اندازه پروژه ندارد چه پروژه کوچک باشد و چه بزرگ باشد مهم نیست، مهم این است که تغییرات چقدر است. برای مثال تغییرات برای شرکت اریکسون از سال ۲۰۰۸ آن‌ها را بر آن داشت که تفکر چابک را وارد کار خود کنند و شرکت ولوو به‌تازگی وارد این حوزه شده است چراکه پیش‌ازاین میزان تغییرات به‌گونه‌ای نبوده که بخواهند از این متد استفاده کنند.

اگر بخواهیم مقایسه‌ای بین تفکر چابک و لین داشته باشیم باید گفت:
تفکر چابک زیرمجموعه لین است و در ابتدا برای توسعه نرم‌افزار به وجود آمد که البته امروزه در بازاریابی هم استفاده می‌شود؛ اما لین بیشتر به تولیدات صنعتی توجه داشت برای مثال تولیدات اتومبیل تویوتا

تفکر چابک می‌گوید سریع کارها را انجام دهیم تا راحت‌تر خود را با تغییرات وفق دهیم و لین می‌گوید ما باید خیلی هوشمندانه به جلو حرکت کرده و محصول خود را توسعه دهیم که روش این کار از بین بردن کارهای بیهوده‌ای است که باعث اتلاف زمان می‌شود و بیشتر به این توجه کنیم که باید ارزش را به مشتری بدهیم.

تفکر چابک می‌گوید فرایندهای توسعه نرم‌افزار باید منعطف باشد و به راحتی بتوان آن را تغییر داد و لین هم البته به این نکته اشاره دارد

در تفکر چابک گفته می‌شود که تولید نرم‌افزار را در چرخه‌های کوچک انجام دهید و در هر چرخه به این نکته توجه کنید که باید چیز قابل‌ارائه‌ای را قرار است به مشتری تحویل دهید و در لین این فرآیند به‌صورت حلقه‌ای ۳ مرحله‌ای تولید – اندازه‌گیری – آموزش انجام می‌شود یعنی ابتدا محصول را تولید کنید سپس آن را به مشتری بدهید و با توجه به بازخورد و اطلاعاتی که او به شما می‌دهد موارد را بررسی و اندازه‌گیری و مقایسه را انجام دهید و در پایان از این موارد چیزهایی را یاد بگیرید و دوباره همین چرخه را این بار با توجه به چیزهایی که از حلقه‌ی قبل یاد گرفته‌اید ادامه دهید؛ که این روش برای استارت‌آپ‌هایی که هنوز محصول آن‌ها جای خود را در بازار پیدا نکرده مناسب است

در تفکر چابک برای توضیح پیشرفت کار از مفهومی به نام تعریف انجام شده «definition of done» استفاده می‌شود و در لین برای توضیح پیشرفت کار از «تولید یک محصول با کیفیت که هیچ نقصی ندارد» استفاده می‌شود.

نمونه‌های متد تفکر چابک؛ اسکرام (scrum) و اکس پی (XP) هستند و نمونه‌های لین می‌توان به کانبان (Kanban) و کایزن (Kaizen) هستند.

توجه داشته باشید که قرار نیست تکنیک اسکرام همه مشکلات را برای شما حل کند و همه‌چیز را باید از این متد بروید گاهی ممکن است نیاز باشد که شما از کانبان استفاده کنید. بسته به جنس کار هرکدام ممکن است مناسب باشد.

در متد چابک یک فاکتور که خیلی اهمیت دارد قابلیت آشکار بودن کار برای همه است به‌نحوی‌که می‌توان برای این کار، یک برد را در شرکت در نظر گرفت و دقیقا مشخص شود که مشکل و گلوگاه کار کجاست تا اگر مشکلی در هر بخش بود برای همه مشخص شود و زودتر مشکل رفع شود نه این‌که وقتی زمان کار گذشت تازه به دنبال این باشیم که مشکل کار کجا بوده است. در متد چابک همکاری شدید چه بین اعضای تیم و حتی همکاری با کسانی که به تیم درخواست می‌دهند وجود دارد و همچنین باید هر چیزی که در کار استفاده می‌کنید سعی کنید ساده باشد چراکه هر چیز پیچیده‌ای باعث گرفتن وقت زیاد از تیم می‌شود و اتلاف و هدر رفت زمان ایجاد می‌کند مثلا اگر شما بخواهید متد اسکرام را در تیم خود راه بیندازید نیاز نیست حتما ابزار جیرا را برای این کار استفاده کنید و برای این کار کسی آن را در سیستم ادمین نصب کنید و بعد به شما یوز دهد و... شاید کار شما خیلی راحت‌تر و با یک وایت برد و یا چند کاغذ حل شود. پس به‌جای پیچیده کردن کار، همکاری را خیلی راحت‌تر انجام دهید و انرژی خود را صرف کارهای دیگری کنید. در این تفکر باید سمت ارزش محوری برویم یعنی بخواهیم ارزش به مشتری بدهیم که ارزش برای مشتری همان محصول با کیفیت است و نباید برنامه محور باشیم و نگذاریم برنامه ما را به جلو ببرد و باید روی چیزی که ارزش دارد تمرکز کنیم. باید تجربی کار را انجام دهم و نباید همه‌چیز را پیش‌بینی کنم چون در دنیای امروز چنین چیزی امکان ندارد. پس اول تجربه کنید بعد انجام دهید؛ مثلا مدیر پروژه نباید بگوید من این کار را طی این‌قدر زمان انجام می‌دهد چون این زمانی که می‌گوید اصلا درست نیست و خودش هم نمی‌داند واقعا چقدر طول می‌کشد باید اول با تیم کار کرد یک هفته یا یک ماه و با توجه به حجم کاری که تیم به شما تحویل داد می‌توان گفت چقدر دیگر زمان می‌برد کار را انجام داد.

مدیریت پروژه در متد تفکر چابک باعث می‌شود که میزان ریسک ما کاهش پیدا کند چون در چرخه‌های کوچک کار را انجام و نتیجه را به مشتری می‌دهیم و هزاران مشکلی که متد آبشاری ممکن است به وجود بیاورد را نخواهیم داشت اگر نقص هم هست و یا عدم فهم مشترک درست در موضوعی وجود دارد زودتر فهمیده و مشکل رفع می‌شود و همچنین خیلی مستندسازی کمتر می‌شود و به کار سرعت می‌دهد.

پیش‌ازاین گفتیم که لین و تفکر چابک یک متد فکر کردن و اسکرام، کانبان و اکس پی فریم ورک‌ها و نمونه‌های آن‌ها هستند که می‌توانیم از آن‌ها استفاده کنیم

در یک مقایسه اجمالی بین اسکرام کانبان و اکس پی باید گفت هر سه این روش‌ها به این‌که در چرخه‌های کوچک و به‌طور مداوم نرم‌افزار را تحویل دهید اشاره دارند. احترام به کارمندان و اعتماد به آن‌ها را تشویق می‌کنند. گرفتن بازخورد سریع را مدنظر قرار می‌دهند و بازخورد و ارتقای همیشگی کار درواقع سرلوحه کار هر سه فریم ورک قرار دارد و کارکنان باید همیشه آموزش ببینند همچنین فرآیند‌ها و محصول نیز همیشه باید بهتر شود.

در روش کانبان ما یک برد که دارای چند ستون است را در اختیار داریم که شامل این موارد می‌شود:

– کارهایی که قرار است انجام دهیم

– کارهایی که در حال انجام است

– کارهایی که در حال تست است

– کارهایی که انجام شده است

در قانون روش کانبان هر چیزی که اول آمده باید اول‌ازهمه نیز پایان‌یافته و خارج شود اما تعداد وظایفی که در هر ستون هستند محدودیت دارد برای مثال در ستون کارهای یکه در حال انجام هستند باید تعداد محدودی مورد وجود داشته باشد مثلا اگر ۳ توسعه‌دهنده نرم‌افزار دارید باید ۳ تا آیتم نیز در این ستون باشد نه بیشتر و در تمام شرکت‌هایی که برد کانبان را دارند حتما مقدار VIP (محدودیت تعداد فرآیندها) را می‌نویسند این کار برای سایر ستون‌ها نیز به همین حالت است یعنی اگر دو نفر برای تست نرم‌افزار دارم میزان VIP برای این ستون ۲ خواهد بود و... پس کانبان بر اساس منابعی که شرکت دارد این محدودید را ایجاد می‌کند این روش بیشتر برای شرکت‌های فعال و تیم‌های به کار می‌آید که همواره برایشان کار جدید می‌آید و باید کارهای زیادی را انجام دهند.

روش اکس پی نیز مانند اسکرام است و به هم شبیه هستند اما تنها چیزی که اکس پی دارد اما در اسکرام وجود ندارد دیدگاه مهندسی (engineering perspective) است. اسکرام به ما نمی‌گوید چگونه کار کنید اما اکس پی مثلا می‌گوید دو نفر دو نفر کار کنید یا کیفیت کدهای نوشته شده را بهبود ببخشید و به شما می‌گوید چگونه کار کنید. البته شما توجه داشته باشید که می‌توانید در اسکرام نیز از این موارد استفاده کنید.

اسکرام

در ابتدا ببینیم فریم ورک اسکرام به ما چه چیزی داده است تا بتوانید به تفکر چابک و توسعه ناب نزدیک شویم

معنی لغوی اسکرام از فوتبال راگبی آمده در زمانی که افراد یکجا جمع می‌شوند و با هم هدفی را تعیین می‌کنند و سپس به سمت آن هدف می‌‌روند، به این حرکت هم‌هدف اسکرام می‌گویند.

اسکرام یک فریم ورک هست که توسط کن و جف نوشته و توسعه داده شد اسکرام به این دلیل به وجود آمد که پروژه‌های خیلی پیچیده را بتوانند راحت‌تر مدیریت کنند. اسکرام هیچ‌وقت به ما نمی‌گوید چگونه کار کنید مانند دات نت که به شما نمی‌‌گوید چطوری برنامه بنویسید و فقط فضایی را ایجاد کرده که بتوانید برنامه خود را به راحتی بنویسید. فهمیدن این فریم ورک کار سختی نیست اما مستر شدن در آن کار سختی است یعنی به راحتی می‌‌توانید بگویید که این موارد را دارد اما این‌که در شرایط خاص به چه نحو از آن استفاده شود سخت است.

اسکرام می‌‌گوید یادگیری با تجربه است و تصمیم‌گیری بر اساس چیزی است که می‌دانید؛ و چرخه بازخورد- یادگیری بعد تصمیم‌گیری و پیشرفت از مواردی است اسکرام بر اساس ایجاد شده است.

توجه داشته باشید که در اسکرام برای این‌که شما اول یاد بگیری و تجربه کنی باید اول همه‌چیز واضح باشد و معلوم باشد. همه‌چیز برای همه واضح باشد چه کسی که کار را انجام می‌‌دهد و چه کسی که کار را تحویل می‌‌گیرد تا فهم و درک مشترک در کار داشته باشیم. پس اگر همه‌چیز روی سطح بود را می‌‌بینیم و می‌‌توانیم اگر مشکلی پیش آمده بفهمیم وقتی همه‌چیز واضح بود نوبت به بازرسی می‌رسد یعنی ما گذشته را تحلیل و بازنگری کنیم ببینیم چه چیزی خوب و چه چیزی بد انجام‌گرفته، چیزی که خوب بود را ادامه دهیم و چیزی که بد پیش رفته را تغییر دهم و وقتی تغییر دادیم حالا به مرحله وفق دادن می‌رسیم یعنی مدتی اجازه دهیم این تغییر کار خود را انجام دهد سپس ببینیم از آن سود می‌‌بریم یا نه که البته باید به آن فرصت بدهیم و بعد دو بار آنالیز می‌‌کنید و همین کار را ادامه می‌‌دهید

ارزش‌ها در اسکرام این موارد است احساس تعهد خیلی مهم است که احساس مسئولیت به تعهدات خود در اسکرام بکنید این‌که مشتاق باشید کاری که به شما داده شده را انجام دهید. تمرکز، هدف که مشخص باشد تمرکز ایجاد می‌شود پس اسکرام می‌خواهد کاری کند که همه‌ی تیم روی یک موضوع کار کنند و پراکندگی در کارها نباشد. باز بودن محیط، همه با همه راحت بتوانند صحبت کنند و احترام که جز ارزش‌های اسکرام است.

در اسکرام هر آن‌چه باید انجام شود در یک قسمت به نام product backlog قرار می‌گیرد هر آن‌چه باید تیم اسکرام در یک بازه sprintی باید انجام دهد می‌رود در product backlog که برایش برنامه‌ریزی شود مثلا یک توسعه‌دهنده در یک تیم اسکرام بگوید که ماژولی باید دوباره نوشته و کد آن بهینه شود در تیم مطرح می‌کنیم و اگر همه موافق این دوباره‌نویسی باشند در مالک محصول آن را در product backlog قرار می‌دهد یا مثلا در مستندسازی، اگر یک توسعه‌دهنده ببیند که مستندات به‌اندازه کافی وجود ندارد و او نمی‌داند که چه چیزی را باید کد بزند و چگونه کار را انجام دهد و محصول چگونه کار می‌کند به مالک محصول می‌گوید که برای ما یک آیتم در product backlog بگذار بنام مستندسازی حالا این‌که در برنامه‌ریزی محصول مالک محصول بخواهد این آیتمی که او در product backlog قرار داده‌ را در اولویت بالا قرار دهد بستگی به استراتژی محصول دارد برای مثال مالک محصول ببیند در sprint بعدی ازلحاظ بازار کیفیت خیلی همه نیست آن را در اولویت پایین‌تر قرار می‌دهد حال اگر در sprint بعد بخواهیم کیفیت برود بالا اولویت‌های product backlog هم عوض می‌شود و موارد مربوط به کیفیت در اولویت بالاتر قرار می‌گیرند پس هر چیزی که قرار است در محصول قرار بگیرد اول در product backlog می‌‌آید پس آن کسی که کمک می‌کند به اولویت‌بندی در product backlog مالک محصول است و این زنجیره اتصال را بین توسعه و بازار ایجاد می‌کند.

برای درک بهتر شکل زیر نگاه کنید:

در قسمت product backlog همه‌چیز اضافه می‌شود و هر آن‌چه قرار است در یک بازه زمانی sprint انجام شود باید ابتدا توسط مالک محصول در قسمت sprint backlog قرار بگیرد. پس بالاترین اولویت‌های product backlog در یک sprint مشخص در product backlog قرار می‌گیرد. حال تیم اسکرام در این چرخه sprint که در زمان بین ۲ تا ۴ هفته است خود را متعهد می‌کند که کار را انجام دهد و در پایان چیز قابلیت عرضه به مشتری را به‌عنوان خروجی بدهد و در این روال اسکرام صبح‌ها جلسه‌ای بین اعضای تیم انجام می‌گیرد که بگویند دیروز چه‌کاری کردند و امروز قرار است چه‌کاری را انجام دهند.

همان‌طور که پیش‌ازاین گفتیم اسکرام سه قسمت دارد وظایف – جلسات و رویدادها و عناصر که اول از وظایف شروع می‌کنیم که شامل مالک محصول اسکرام مستر و تیم توسعه است

و رویدادها شامل programing sprint، review sprint، retrospective sprint، جلسات روزانه اسکرام

و عناصر شامل product backlog، sprint backlog، increment و نمودار burndown است

وظیفه مالک محصول این است که مشخص کند که قرار است در هر sprint چه‌کاری انجام شود و روی چه چیزی قرار است کار انجام شود و چون معمولا مالک محصول در استارت‌آپ‌ها با تیم بازاریابی رابطه تنگاتنگ و نزدیکی دارد اولویت‌ها را نیز مشخص می‌کند و در قسمت product backlog اولویت‌بندی‌ها را تغییر می‌‌دهد و به آن، مواردی که پیشنهاد داده می‌شود و یا عوض شده است را اضافه و کم و تغییر دهد.

توجه داشته باشید که در تیم اسکرام ممکن است یک کار ناگهانی پیش بیاید پس برای این کار در یک sprint مالک محصول باید حدود ۸۰ -۸۵ درصد توان تیم را مورداستفاده قرار دهد و این ۱۵-۲۰ درصد برای مواردی است که ممکن است به‌طور عجله‌ای و ناگهانی لازم باشد که انجام گیرد. وظیفه تایید و رد خروجی هر sprint نیز با مالک محصول است. وظیفه مالک محصول این است که خیلی واضح product backlog را بنویسد به‌طوری‌که توسعه‌دهنده راحت آن را بفهمد و اگر تیم توسعه نداند چه چیزی می‌خواهد او موظف است توضیح دهد. درواقع مالک محصول برای تیم توسعه دقیقا مانند مشتری است و تیم اسکرام باید بداند که او دقیقا چه چیزی را می‌خواهد و قرار است چه‌کاری انجام دهد.

وظیفه اسکرام مستر یک تیم لیدر است که باید به تیم سرویس دهد برای این‌که کمک کند که تیم به اهداف خود برسد او باید قوانین اسکرام را دانسته و این فریم ورک رو خوب بشناسد و بر این اساس به مالک محصول کمک می‌کند که موارد را راحت‌تر وارد قسمت برنامه‌ریزی sprint کند، اعضای تیم را راهنمایی می‌کند که اسکرام برایشان بهتر جا بیفتد و مسئول همه جلسات روزانه تیم اسکرام خواهد بود و این‌که هر کاری می‌کند که تیم با تمام توان در جهت تعهد sprintی که داده است حرکت کند. بررسی انجام هر یک از موارد اسکرام داخل تیم اسکرام وظیفه اسکرام مستر است و همچنین روابط با بیرون تیم اسکرام را مدیریت می‌کند که وقت تیم اسکرام زیاد گرفته نشود

تیم توسعه (تیم اسکرام) اولین بار که اریکسون اسکرام را ایجاد کرد گفت تیم اسکرام تیمی است که افراد توانایی داشته باشند که در آن هر کاری را انجام دهند؛ و بعدا آن را عوض کرد به این مفهوم که تیم اسکرام تیمی است که می‌تواند همه کار را خودش انجام دهد و به فرد خارجی دیگری نیاز نداشته و معطل تیم دیگر نباشد. تعداد اعضای این گروه باید بین ۵ تا ۹ نفر باشد چراکه کمتر از آن ممکن است کار به‌خوبی و در زمان خود انجام نشود و بیشتر از 9 نفر نیز باعث اختلال و مشکلات و پیچیدگی می‌شود. افراد تیم اسکرام را تا زمانی که یک sprint تمام نشده نمی‌توان خارج و یا داخل تیم اسکرام کرد؛ و همچنین برای هیچ‌یک نقشی وجود ندارد همه هر کاری ممکن است بکنند.

Sprint‌ها درواقع ضربان قلب اسکرام هستند و هر دفعه ریتمیک تکرار می‌شوند و پیشرفت پروژه را می‌توان از این sprint‌ها دید که دارای زمان ۲ تا ۴ هفته هستند البته در شروع یک استارت‌آپ شاید ۱ هفته هم مناسب باشد. همچنین این sprint همیشه یک خروجی دارند در هر sprint نباید تغییری ایجاد شود مگر آنکه از قبل برنامه‌ریزی کرده باشید که قرار است چنین اتفاقی بیفتد و ما ۲۰ یا ۲۵ درصد زمان خالی برای چنین تغییراتی گذاشته باشیم. این‌که قرار است خروجی یک sprint چه چیزی باشد را نیز تیم توسعه و مالک محصول با هم به توافق رسیده‌اند. همچنین اگر به هر دلیل مشکلی در کار پیش بیاید یا تصمیم شرکت عوض شود یا مثلا بازار دیگر نیازی به فعالیت sprint که در حال انجام است نداشته باشد تنها کسی که می‌تواند sprint را کنسل کند مالک محصول است.

Sprint planning یکی از مهم‌ترین جلسات است زیرا افراد در این جلسه می‌خواهند خود را متعهد کنند که چه چیزی را قرار است در این sprint به مشتری بدهند؛ و زمان‌بندی آن به این صورت است که برای مثال برای یک sprint که قرار است ۱ ماه به طول بینجامد باید مدت‌زمان این sprint حدودا ۸ ساعت باشد. تا دقیقا مشخص شود که sprint قرار است چه‌کاری را این بار انجام دهد. مالک محصول باید در این جلسه باشد و کاملا و واضح و روشن بگوید که چه چیزی می‌خواهد. در Sprint planning مواردی که از product backlog می‌آید شکسته می‌شود چراکه product backlog معمولا به شکل یک داستان نوشته می‌شود؛ مثلا می‌خواهد نمرات دانش آموزان را وارد کنم و در Sprint planning معلوم می‌شود که چگونه قرار است این کار را انجام دهید. در Sprint planning یک سری کاغذ به افراد داده می‌شود و گفته می‌شود حال زمان انجام کار را مشخص کنید که اگر تفاوت بالا باشد باید هم دیگر را قانع کنند و به زمان مشترک برسند. در این جلسه باید دو چیز را حتما داشته باشیم تا جلسه درست برگزار شود اول product backlog است که دقیقا مشخص شود که چه‌کارهایی قرار است انجام شود و دوم اینکه تیم در Sprint پیش رو چه کسانی را خواهد داشت، توانایی‌ها چقدر است چند درصد افراد در این Sprint حضور دارند تا کامل بدانیم تیم اسکرام با چند درصد توان و ظرفیت قرار است کار را انجام دهد. خروجی این جلسه این است که ما هدف Sprint را مشخص می‌کنیم تا خروجی بهتر درک شود.

The daily scrum جلسه‌ای است که در آن هرروز افراد می‌گویند که دیروز چه‌کاری کردند و قرار است امروز چه‌کاری را انجام دهند و در این بین چه مانع و مشکلی برایشان ایجاد شده تا راه حل به کمک دیگران که در جلسه هستند،مشخص و رفع شود . ۱۵ دقیقه است و همه باید ایستاده در جلسه باشند. دلیل این کار این است که افراد خسته شوند و جلسه زیاد طول نکشد. در این جلسه همه حضور دارند و حتی ممکن است رییس‌های بخش نیز در آن جلسه بیایند و حضور داشته باشند این جلسه خودبه‌خود باعث جلوگیری از جلسات بی‌اهمیت می‌شود چراکه هماهنگی را بیشتر می‌کند. اینجا قرار است اعضای تیم با هم صحبت کنند نه به اسکرام مستر یا کس دیگر توضیح دهند. این جلسه برای صحبت‌های اعضای تیم اسکرام و توسعه با یکدیگر است.

سومین جلسه در اسکرام The sprint review است زمانی که کار تیم اسکرام تمام شده و قرار است به مالک محصول خروجی عرضه شود و قرار است توضیح دهند که در این اسپرینت چه گذشته است و اگر نرسیده‌اند دلیل آن چه بوده است این جلسه تشکیل می‌شود. در این جلسه مالک محصول نیز توضیحاتی در مورد بازار و ادامه روند کار بر اساس آن توضیحاتی به افراد می‌دهد. تیم اسکرام را در جریان بازار قرار می‌دهد مالک محصول نیز بر اساس چیزهایی که انجام گرفته product backlog خود را آبدیت می‌کند.

Sprint retrospective جلسه‌ای است که در آن اسکرام مستر مسئول آن است و همه در آن جلسه حضور دارند که در آن تمام چیزهایی که در اسپرینت قبلی خوب یا بد پیش رفته را بیان می‌کنند و در برد قرار می‌دهند و اسکرام مستر این موارد را گروه بندی می‌کند؛ و سپس با رای‌گیری مشکلات را رده بندی می‌کنند و راهکارها پیشنهاد می‌شود و در پایان خروجی را که دو مورد اصلاحی است، توسط اسکرام مستر پیگیری می‌شود که آن مشکل رفع شود.

Product backlog یکی از زنده‌ترین عناصر اسکرام است که تا وقتی پروژه هست هر دفه تغییر و آبدیت می‌شود و صاحب آن و مسئول آن مالک محصول است و الویت بندی آن هم با مالک است در فازهای اولیه پروژه شاید تعداد کمی آیتم در آن باشد اما به‌مرور با آموزش و ساخت بهتر و پیشرفت می‌کند و وقتی محصول جای خود را در بازار پیدا می‌کند تعداد آیتم‌های آن بالا می‌رود؛ و هر تغییر و اضافه کمی در محصول در این قسمت می‌نشیند و اگه واقعا اولویت داشته باشد این تغییر در اسپرینت بعدی انجام می‌شود. مطالب Product backlog معمولا مبهم هستند و براین اساس مالک محصول باید با همکاری تیم اسکرام برآورد کنند حجم آیتم موردنظر در اجرا چقدر است البته ریز شدن و مشخص کردن وظایف آیتم‌های Product backlog در جلسه Sprint planning انجام می‌شود اما در اینجا فقط ۳ مقدار کار کوچک متوسط و بزرگ را برای هر یک از این آیتم‌ها مشخص می‌کنیم. مالک محصول توضیحات خود را در مورد آیتم (user story) می‌دهد تیم توسعه سوال می‌پرسد و کم کم مورد برای افراد شفاف و حجم کار مشخص می‌شود؛ که البته این کار در ابتدای کار و در اسپرینت‌های ۱ و ۲ سخت است اما کم کم افراد باتجربه شده و با مقایسه با اسپرینت‌های قبلی یادگیری انجام می‌شود. تیم اسکرام باید توجه داشته باشد که اگر حجم یک آیتم (user story) از دیدشان خیلی بزرگ بود باید آن‌قدر با مالک محصول صحبت کنند تا طرفین به توافق برسند که آیتم موجود به ۲ یا ۳ آیتم شکسته و تقسیم شود تا بتوان در یک اسپرینت آن را انجام داد.

توجه داشته باشید که ما یک آیتم (user story) در Product backlog را زمانی به اسپرینت باید ببریم که آیتم موردنظر به‌درستی تعریف و انجام شدنش هم به‌درستی تعریف شده باشد

مطابق شکل زمانی می‌گوییم آیتم (user story) تعریف شده باید ۱- به‌اندازه کافی کوچک باشد ۲- مالک محصول شاخص‌های قبول کردن خروجی را بگوید ۳- قابلیت تست داشته باشد

و خروجی این آیتم (user story) نیز زمانی تعریف می‌شود که این موارد رعایت شده باشند ۱- کد برنامه موجود باشد ۲- شاخص‌های پذیرش مالک محصول رعایت شده باشد ۳- تست شده باشد ۴- مستندسازی شود.

جلسه دیگری نیز وجود دارد که به آن Scrum grooming می‌گویند این جلسه گرچه در اسکرام تیم عنوان نمی‌شود اما اجرای آن بسیار خوب است درواقع همین شفاف‌سازی آیتم (user story) در Product backlog در این جلسه انجام می‌شود. در این جلسه مالک محصول تیم اسکرام و اسکرام مستر حضور دارند آیتم‌ها (user story’s) توسط مالک محصول ارائه می‌شود اما این موارد باید ویژگی‌هایی مانند ۱- کاملا مجزا بودن ۲-بتوان راجع به آن صحبت کرد ۳- واقعا ارزش داشته باشد و به مشتری ارزش بدهد ۴- قابلیت اندازه‌گیری داشته باشد تا بتوانیم بگوییم حجم کار چقدر است ۵- به‌اندازه کافی کوچک و ۶- قابل تست باشد.

اسکرام مستر از مالک محصول می‌خواهد که اولویت‌های آیتم (user story) را در Product backlog مشخص کند و پس از مشخص شدن این موضوع درباره هریک از آیتم‌ها (user story’s) رای‌گیری برای حجم کار گرفته می‌شود و سپس افراد در صورت مغایرت حجم کاری که تخمین زده‌اند، صحبت می‌کنند که همدیگر را قانع کرده و به حجم کاری مشخص برسند برای این کار مالک محصول هم باید مسئله را برای همه واضح کند و شاخص‌های خود را بیان کند تا مفهوم کامل برای همه ‌جا بیفتد درصورتی‌که آیتمی خیلی بزرگ بود به آن Epic می‌گوییم که باید به چند آیتم (user story) کوچک‌تر تقسیم شود و اولویت‌ها دوباره توسط مالک مشخص شود. تفاوت Epic و آیتم (user story) مجزا این است که در Epic تمام آیتم‌ها (user story’s) به هم مرتبط هستند و تا زمانی که همه انجام نشده نمی‌توان گفت که آن Epic انجام شده است. در حین این جلسه و صحبت‌های انجام گرفته آیتم‌ها (user story’s) درست می‌شوند و شرایطی که برای آن‌ها گفته بودیم را درصورتی‌که قبلا نداشتند اصلاح شده و درست نوشته می‌شوند.

Increment یکی از عناصر اسکرام است که در آن همان چیزی است که ما در پایان یک اسپرینت به‌عنوان خروجی می‌دهیم که همان مجموعه چند آیتم (user story) است که با رعایت ۴ موردی که قبلا گفتیم به اتمام رسیده است.

Burndown chart چارتی است که نشان می‌دهد چقدر از کار یک تیم اسکرام باقی مانده است این چارت که در بردی نصب می‌شود باعث می‌شود یک گزارش خلاصه را مدیر قسمت به راحتی با دیدن آن متوجه شود که وضعیت تیم چطور است و اگر مشکلی هست بتواند کمک کند تا مشکل رفع شود.

این نمودار مطابق شکل برای مثال اگر کار را به ۲۰۰ ساعت تقسیم کرده باشیم رسم می‌شود و نمودار انجام فعالیت نیز بر اساس مقدار ساعت باقیمانده می‌نویسیم حال اگر نموداری که هرروز به آن اضافه می‌کنیم زیر منحنی اولیه باشد نشان می‌دهد که یا زمان آیتم‌ها را در جلسه Sprint planning درست در نظر نگرفته‌ایم یا کیفیت کار خیلی خوب نبوده یا مالک محصول آیتم‌های کمی را داشته و اگر بالای نمودار باشد نشان‌دهنده عدم تخمین درست زمان اجرا در جلسه Sprint planning و یا وجود هر نوع اختلال و مشکل است که برای رفع آن باید اقدام کرد.

تویوتا یکسری از کارکنان خود را به آمریکا فرستاد تا ببینند آمریکایی‌ها چه نوع اتومبیلی را سوار می‌شوند، چون می‌خواست دقیقا محصولی را تولید کند که مطمئن باشد آمریکایی‌ها آن را می‌خرند. این یکی از مفاهیم لین است
تویوتا یکسری از کارکنان خود را به آمریکا فرستاد تا ببینند آمریکایی‌ها چه نوع اتومبیلی را سوار می‌شوند، چون می‌خواست دقیقا محصولی را تولید کند که مطمئن باشد آمریکایی‌ها آن را می‌خرند. این یکی از مفاهیم لین است
کارگاه مبانی به‌کارگیری تفکر چابک و متد اسکرام در استارت‌آپ‌ها
کارگاه مبانی به‌کارگیری تفکر چابک و متد اسکرام در استارت‌آپ‌ها
در فرآیندهای تولید، ۸۵ درصد اتفاقات که در این فرآیند انجام می‌گیرد هیچ ارزشی را به محصول اضافه نمی‌کند و باید این موارد شناسایی و حذف شوند و درواقع ۵ درصد این مراحل ارزش افروده به تولید می‌دهد و ۱۰ درصد  دیگر نیز تقریبا بودن و نبودنش خیلی فرقی نمی‌کند و جز ساختار شرکت هستند.
در فرآیندهای تولید، ۸۵ درصد اتفاقات که در این فرآیند انجام می‌گیرد هیچ ارزشی را به محصول اضافه نمی‌کند و باید این موارد شناسایی و حذف شوند و درواقع ۵ درصد این مراحل ارزش افروده به تولید می‌دهد و ۱۰ درصد دیگر نیز تقریبا بودن و نبودنش خیلی فرقی نمی‌کند و جز ساختار شرکت هستند.
تشریح متد آبشاری در توسعه نرم افزار
تشریح متد آبشاری در توسعه نرم افزار
هر آن‌چه قرار است در یک بازه زمانی sprint انجام شود باید ابتدا توسط مالک محصول در قسمت sprint backlog قرار بگیرد.
هر آن‌چه قرار است در یک بازه زمانی sprint انجام شود باید ابتدا توسط مالک محصول در قسمت sprint backlog قرار بگیرد.
۳۱.۵۵MB مفهوم توسعه ناب
۴۱.۶۳MB چالشهای توسعه نرم افزار
۵۹.۵۶MB مزیت های توسعه چابک در نرم افزار
۵۲.۳۴MB بیانیه و ارزش‌های کلیدی توسعه چابک
۲۵.۹۸MB تفاوت‌های توسعه ناب و توسعه چابک
۳۴.۸۲MB روش‌ها‌ی توسعه چابک
۲۱.۱۷MB ارزشهای کلیدی و چرخه اسکرام
۴۲.۴۹MB اسکرام و تئوری‌های مبتنی بر آن
۶۳.۵۷MB جلسات کلیدی در متد اسکرام
۷۱.۳۶MB جلسه هماهنگی Scrum Grooming
۷۱.۱۸MB عناصر کلیدی اسکرام
۴۲.۴۷MB نقش‌های کلیدی تیم در متد اسکرام
نسخه صوتی را گوش دهید (بخش اول) ۱۸۱.۶۴MB
نسخه صوتی را گوش دهید (بخش دوم) ۲۶۵.۵۶MB