آشنایی با اسکرام، ایکس‌پی، ناب، و کانبان
یادگیری چابکی (۲۰۱۵) یک راهنمای خلاصه برای مفهومی‌ست که اغلب اشتباه گرفته می‌شود: چابکی. دلیل این سوء‌تفاهم ساده‌ست: در اغلب موارد، چابکی به عنوان یک راه‌حل یکسان برای همه مشکلات سازمانی قابل تصور مطرح می‌شود. اندرو استلمن و جنیفر گرین، تمرین‌کنندگان چابکی سنتی، آن را اینطور نمی‌بینند. برای آنها، چابک ابزاری عالی‌ست، اما باید بدانید چگونه، و چه زمانی، و چرا از آن استفاده کنید. و این با درک اصول زیربنایی چابکی شروع می‌شود.
این کتاب چه چیزی برای من دارد؟ مقدمه‌ای بر چابکی
مشتریان همیشه نمی‌دانند چه می‌خواهند یا به چه چیزی نیاز دارند. همانطورکه هنری فورد زمانی بیان کرد، اگر از مردم می‌پرسیدیم که چه می‌خواهند، آنها می‌گفتند «اسب‌های سریع‌تر». یادگیری چابکی
البته فورد به آنها خودرو داد. اما تصور کنید اگر او این کار را نکرده بود. سال‌ها تلاش برای ارضای این تقاضا هدر می‌رفت. این احتمال وجود دارد که تا زمانی که محصول فورد وارد بازار شود، شخص دیگری فروش خودروهای ارزان و قابل اعتماد را آغاز کرده باشد. محصول او در بدو امر مرده بود.
در این خلاصه‌کتاب، ما در مورد توسعه نرم‌افزار صحبت خواهیم کرد، نه خودرو. اما ما همان مشکل را بررسی خواهیم کرد. این مشکل را می‌توان در یک پرسش خلاصه کرد: چگونه یک محصول ارزشمند را به مشتری‌شان تحویل می‌دهید، حتی اگر آنها نتوانند به شما بگویند که واقعاً چه می‌خواهند یا چه چیزی نیازی دارند؟
یک پاسخ مجموعه‌ای از تمرین‌ها و اصول‌ست که به عنوان چابکی شناخته می‌شوند. اگر قبلاً این کلمه را شنیده‌اید، احتمالاً با مفاهیم مرتبط مانند اسکرام، کانبان، ایکس‌پی و ناب نیز برخورد داشته‌اید. اغلب اوقات، این وسوسه وجود دارد که در بحث درباره این روش‌ها در کنار چابکی عجله کنیم.
برای اندرو استلمن و جنیفر گرین، نویسندگان یادگیری چابکی، این کار همانند قرار دادن گاری بعد از اسب‌ست. اگر ما نشان ندهیم که چرا شما و سازمان‌تان باید در وهله اول چابکی را در نظر بگیرد، هیچ فایده‌ای برای ورود به این موضوع وجود ندارد. بنابراین این همان کاری‌ست که ما در این خلاصه‌کتاب انجام خواهیم داد: بررسی چرایی چابکی. یادگیری چابکی
برای انجام این کار، یک پروژه را از ابتدا تا انتها دنبال خواهیم کرد. در طول مسیر، خواهیم دید که چگونه اصول چابکی می‌تواند به تیمی از توسعه‌دهندگان نرم‌افزار کمک کند تا کارآمدتر و مؤثرتر کار کنند. و محصول بهتری ارائه دهند.
شما نمی‌توانید نرم افزار خوبی را در خلاء طراحی کنید
بیایید یک لحظه درباره کتابخوان‌های الکترونیکی صحبت کنیم.
به راحتی می‌توان فهمید که چرا آنها بسیار محبوب هستند. این دستگاه تقریباً به اندازه یک کتاب معمولی‌ست، اما هزاران کتاب را در خودش جای می‌دهد. حتی بهتر از آن، هر متنی رای شما، خواننده پاسخگو دارد. می‌توانید کلمات را بزرگ کنید، فونت را تغییر دهید، یا بین متن اصلی و منابع به جلو و عقب پرش کنید. با یک کلیک می‌توانید به کتابخانه‌ها و کاتالوگ‌ها دسترسی داشته باشید. با یک کلیک دیگر، می‌توانید کتاب‌های جدید را در دستگاه‌تان امانت بگیرید یا دانلود کنید. یادگیری چابکی
به طور خلاصه، این دستگاه عالی‌ست. به خوبی طراحی شده‌ست. راحت. دیداری. هر ذینفعی را راضی می‌کند. خوانندگان استفاده از آن را آسان می‌دانند و متون را با دقت نمایش می‌دهد. که برای نویسندگان مهم‌ست. هم‌چنین به کتابفروشان و ناشران در فروش و توزیع کتاب کمک می‌کند.
اگرچه اولین خواننده‌های کتاب الکترونیکی همه این کارها را انجام ندادند. در واقع، بیش از یک دهه توسعه طول کشید تا نرم‌افزار به جایگاه امروزی برسد. در اوایل دهه ۲۰۰۰، مشخص نبود که چه چیزی یک کتابخوان الکترونیکی را ارزشمند می‌کند. ما امروز فقط این را می‌دانیم. زیرا آینده‌نگری‌ست که ما را به آزمایش فکری کوچک خودمان می‌رساند.
بیایید به گذشته برگردیم. تصور کنید که ما وظیفه توسعه نرم‌افزاری برای نمایش کتاب‌های الکترونیکی در دستگاه‌های دستی جدید را بر عهده داریم. چگونه به وظیفه خودمان نزدیک خواهیم شد؟ یادگیری چابکی
خُب، ما در واقع این کار را به بدترین شکل ممکن انجام خواهیم داد. زیرا این شرکتی نیست که راه‌های جدیدی برای ساختن نرم‌افزار جست‌وجو کند. این یک عملیات قدیمی‌ست، با رهبرانی که رهبری و پیروانی، که توسعه‌دهندگانی مثل ما هستیم که دنبال می‌کنند. به طور خلاصه، این دفتری نیست که در آن کلمه «چابکی» را بشنوید. پس بیایید ببینیم اوضاع چگونه پیش می‌رود.
تیم سخت‌افزار قبلاً یک نمونه اولیه ساخته‌ست. یک تبلت مشکی درشت با یک پورت یو‌اس‌بی [USB] برای بارگذاری کتاب‌ها و یک صفحه کلید کوچک غلتان برای تعامل با خواننده را تصور کنید. ساختن نرم‌افزاری به عهده ماست تا کتاب‌های الکترونیکی را در این گجت نمایش می‌دهد. یادگیری چابکی
شرکت ما آنچه را که به عنوان فرایند آبشار شناخته می‌شود در پروژه‌های خودش اعمال می‌کند. به معنی اینکه پروژه‌ها از قبل بارگذاری می‌شوند. تمام الزامات محصول در ابتدا تعریف شده‌ست. همانطورکه گفتیم رهبران رهبری و پیروان از آنها پیروی می‌کنند. همه ذینفعان – مدیران ارشد، نمایندگان انتشارات، خرده‌فروشان آنلاین و غیره – می‌نشینند و طرحی را تدوین می‌کنند. آنها الزامات را مشخص می‌کنند و ارائه می‌دهند که تمام چک‌لیست‌های مربوطه را علامت‌گذاری می‌کند. هر مرحله دیگر از فرایند، از طراحی گرفته تا توسعه و آزمایش، از این تصمیمات به پایین دست جریان می‌یابد. درست همانطورکه آب در پایین دست از یک آبشار جریان می‌یابد.
بنابراین در فهرست مشخصات چیست؟ در یک کلام همه چیز این کتابخوان الکترونیکی انقلابی خواهد بود. این قابلیت‌های زیادی خواهد داشت. این آمار بازار را برای ناشران ثبت می‌کند. این یک فروشگاه اینترنتی برای خوانندگان برای خرید کتاب خواهد داشت. نویسندگان می‌توانند هنگام نوشتن کتاب‌های‌شان را پیش‌نمایش و ویرایش کنند. و همه چیز در ۱۸ ماه آماده می‌شود.
یک سال و نیم سریع به جلو. از آنجایی‌که این یک طرح آزمایشی‌ست، لازم نیست واقع‌بین باشیم. بنابراین می‌گوییم که پروژه به‌موقع کامل شده‌ست. و همه چیز وجود دارد – همه الزامات در مشخصات اجرا، آزمایش و تأیید شده‌ست. همه خوشحال هستند.
آیا می‌توانید حدس بزنید چه اتفاقی می‌افتد؟ دستگاه وارد بازار می‌شود. و اصلاً استقبال نمی‌شود. کسی آن را نمی‌خرد.
چه چیزی اشتباه پیش رفت؟
مسئله اینکه نیازهای مردم ثابت نیست. آنها با زمان تغییر می‌کنند. اگر تنها انتخاب شما اسب‌ست، اسب سریع‌تر می‌خواهید. اما اسب، مهم نیست چقدر سریع‌ست، اگر همه در حال حاضر راننده خودرو باشند، سوارکار چندان کاربردی ندارد. به طور مشابه، نرم‌افزاری که مردم ۱۸ ماه پیش به آن نیاز داشتند، نرم‌افزار امروزی نیست. از زمانی‌که پروژه ما شروع شد، استاندارد صنعتی جدیدی برای کتاب‌های الکترونیکی پدیدار شد. هیچ خرده‌فروشی نمی‌خواهد قالب غیراستاندارد ما را منتشر کند. این خیلی آزاردهنده‌ست. و بنابراین هیچ یک از ویژگی‌های انقلابی ما پشتیبانی نمی‌شوند، به این معنی که برای هیچ‌کس فایده‌ای ندارند.
هم‌چنین به این معنی که ما زمان و پول زیادی را برای ایجاد نرم‌افزاری هدر داده‌ایم که خیلی ارزشمند نیست. پس باید چه کار متفاوتی انجام می‌دادیم؟ یادگیری چابکی
امروز نرم‌افزار ناقص را منتشر کنید و فردا محصول نهایی بهتری خواهید داشت
اینجا جایی‌ست که ما اشتباه کردیم: ما پاسخگو نبودیم. ما ۱۸ ماه در خلاء کار کردیم تا طرحی را اجرا کنیم که حتی قبل از اینکه به بازار برسد قدیمی بود. هیچ تنظیمی وجود نداشت. پروژه ما انعطاف‌پذیر نبود.
یک فرایند طراحی تکراری در خلاء انجام نمی‌شود. در عوض، محصولات را به سرعت عرضه می‌کند، آنها را در اسرع وقت به مشتریان می‌رساند و بازخورد جمع‌آوری می‌کند. این بازخورد مبنایی برای بهبودست، که پس از آن به مشتریان – دوباره، در سریع‌ترین زمان ممکن – ارسال می‌شود تا بتوانند بازخورد جدیدی ارائه دهند. در آن نقطه، چرخه دوباره شروع می‌شود. به هر حال تکرار کردن به معنای «انجام مکرر»ست. یادگیری چابکی
این حلقه بازخورد در قلب فرایندهای چابکی قرار دارد. در مورد کلمه «چابکی» همانطورکه در زبان روزمره استفاده می‌کنیم بیاندیشید. این روشی را برای حرکت سریع و زیرک توصیف می‌کند – پاسخگو بودن به محیط و درگیر شدن با آنچه در مقابل شماست. برای مثال یک کوهنورد چابک به هر سنگ و شنی که با آن برخورد می‌کند پاسخ می‌دهد. آنها تنظیمات سریعی را برای جلوگیری از لغزش و گیرکردن انجام می‌دهند. چابکی در طراحی نرم‌افزار نیز به همین صورت‌ست. تیم‌های چابک از فرایندهای تک‌حلقه‌بسته برای پاسخ سریع و زیرکانه به اشکالات و اختلاط‌ها در هنگام مواجهه با آنها استفاده می‌کنند. آنها ممکن‌ست نرم‌افزاری را که قصد ساختن آن را دارند نسازند، اما این بسیار بهتر از ساختن چیزی بی‌فایده‌ست.
بنابراین اولین اصل چابکی وجود دارد. می‌توانیم آن را این‌گونه بیان کنیم: بالاترین اولویت، جلب رضایت مشتری از طریق تحویل زودهنگام و مستمر نرم‌افزارهای ارزشمندست. یادگیری چابکی
حال، بیایید جزئیات این اصل را بیشتر بررسی کنیم.
نرم‌افزار فقط در دنیای واقعی – دنیای انسان‌های ناقص – ساخته می‌شود. حتی سخت‌کوش‌ترین تیم‌ها نیز جزئیات مهم را از دست می‌دهند. بااستعدادترین توسعه‌دهندگان در پیش‌بینی الزامات حیاتی شکست می‌خورند. تنها راهی که می‌توانیم اشتباهات را تصحیح کنیم اینکه نرم‌افزاری را که می‌سازیم در اختیار مشتریان قرار دهیم. افرادی که واقعاً از آن استفاده می‌کنند. به عنوان توسعه‌دهندگان، ما کاملاً به بازخورد آنها وابسته هستیم. به این دلیل که باید نرم‌افزار را زودتر منتشر کنیم.
انتشار زودهنگام نرم‌افزار فقط پادزهری برای کمال‌گرایی نیست. ارزشی برای مشتریان به ارمغان می‌آورد. اگر امروز یک ویژگی واحد داشته باشند، هر چند، می‌توانند کاری را انجام دهند که دیروز نتوانستند انجام دهند. با استفاده از یک محصول، آنها می‌توانند نیازهای خودشان را روشن کنند. بدان معنی که آنها می‌توانند به ما ایده واضح‌تری از آنچه می‌خواهند یک محصول انجام دهد، ارائه دهند. و هنگامی‌که در این حلقه بازخورد قفل شدیم، در مسیر ایجاد یک محصول نهایی هستیم که در واقع این نیازها را برآورده می‌کند.
پذیرش تغییر همه چیز درباره اتخاذ یک طرز فکر صحیح‌ست
بنابراین پاسخ به پرسشی که قبلاً داشتیم وجود دارد. کاری که باید انجام می‌دادیم این بود که نرم‌افزارمان را در اختیار مشتریان قرار دهیم تا بتوانند از آن استفاده کنند و به ما بازخورد بدهند. اگر این کار را می‌کردیم، متوجه می‌شدیم که مشکلی وجود دارد و مسیر را تغییر می‌دادیم. این باعث صرفه‌جویی در زمان، تلاش و پولی می‌شد که برای ساختن یک مجموعه گران‌قیمت صرف می‌کنیم.
البته، تغییر مسیر در میانه پروژه آسان‌تر از انجام آن‌ست. در عمل، معمولاً یک تجربه دردناک و ناخوشایندست. وقتی تصمیمات سختی گرفتید می‌دانید که چه چیزی می‌سازید. شما می‌دانید که مشتریان شما چه انتظاراتی دارند. گردش کار شما برقرارست. دقیقاً قایقرانی ساده نیست، اما شما در حال پیشرفت هستید.
و سپس یک نفر از بیرون پروژه می‌آید و می‌گوید که شما در تمام مدت مسیر اشتباهی را طی کرده‌اید. که آن همه برنامه‌ریزی و کار بیهوده بود. که باید دایره‌ای برگردید و دوباره شروع کنید. بدتر از آن، فردی که به شما می‌گوید مسیرتان را تغییر دهید، همان کسی که شما را در همان مسیر قرار داده‌ست! گفتند یک چیز را بسازید و حالا که نصف آن را ساخته‌اید می‌گویند کار دیگری بکنید. این باعث تضعیف روحیه – حتی بی‌احترامی می‌شود. جای تعجب نیست که حالت تدافعی می‌گیرید و در مقابل تغییرات مقاومت می‌کنید. یادگیری چابکی
قابل درک‌ست؟ مطمئن. مفیدست؟ اصلاً. پرسش مهم اینکه چگونه می‌توانید از این احساس عبور کنید؟
خُب، بحث ذهنیت‌ست و دو بخش دارد. اولین مورد اینکه بپذیرید اگر به طور مداوم برنامه‌های قبلی خودتان را بررسی و بازبینی نکنید، ساختن نرم‌افزار ارزشمند واقعاً دشوارست. بله، تغییر مسیر در نیمه راه یک پروژه ناامیدکننده‌ست. اما به اندازه رسیدن به پایان یک پروژه و فهمیدن اینکه یک آشغال درست کرده‌اید، نمی‌تواند آن را کاهش داد.
قسمت دوم در مورد دیدگاه و به شکل یک تمرین‌ست.
این همیشه یک تمرین آسانی نیست. به خونسردی و همدلی بیشتر از آنچه که ممکن‌ست بخواهید به فردی نیاز دارد که روز شما را خراب کرده‌ست. اما می‌تواند روشنگر باشد. با پرسیدن این دو سؤال از خودتان شروع کنید: اول، آیا مشتری شما عمداً شما را در مسیر اشتباه قرار داده‌ست؟ احتمالاً نه، درست‌ست؟ و دوم اینکه وقتی فهمیدند کارشان را خراب کرده‌اند و ماه‌ها کار شما را خرج کرده‌اند چه احساسی داشتند؟ به احتمال زیاد، آنها بسیار خجالت زده بودند.
آنها احتمالاً نمی‌خواستند پیش شما بیایند و اشتباه خودشان را بپذیرند. این کار خوبی‌ست که آنها انجام دادند. آنها فقط در زمان تلف‌شده شما حتی بیشتر صرفه‌جویی کردند! و این فقط ضرب‌الاجل شما نیست که به پایان رسیده‌ست. جدول زمانی مشتری شما هم اکنون به تأخیر افتاده‌ست. شرکت آنها پول خوبی را برای ساختن نرم‌افزاری خرج می‌کند که نیازهایش را برآورده کند، و این اشتباه به این معنی‌ست که پروژه ارائه نمی‌شود. به عبارت دیگر، این برای همه ناامیدکننده‌ست. یادگیری چابکی
وقتی به آن دست می‌یابید، هر دو در موقعیت دشواری قرار می‌گیرید. تنها راهی که از نظر تئوری می‌توانید از خرابکاری‌ها جلوگیری کنید اینکه ذهن مشتری خودتان را بخوانید. مشتری شما نیز به نوبه خودش باید بتواند آینده را پیش‌بینی کند. در یک دنیای ایده‌آل، هر دوی شما می‌توانید آن کارها را انجام دهید. اما نرم‌افزار در دنیای ایده‌آل ساخته نشده‌ست. شما با روشن‌بینان تله پاتیک کار نخواهید کرد. این را بپذیرید، و اشتباهات – همراه با تغییراتی که ایجاد می‌کنند – بسیار آسان‌تر خواهد بود.
فرایندهای مکرر و حلقه‌بسته شما را با مشتریان‌تان در ارتباط نگه می‌دارد
خُب، برگردیم به جایی که شروع کردیم. اصول چابکی که بررسی کرده‌ایم چگونه می‌توانند به پروژه مشکل‌دار کتابخوان الکترونیکی ما کمک کنند؟ بیایید با اجرای دوباره پروژه متوجه شویم.
ابتدا، بیایید به خودمان یادآوری کنیم که چرا آن کتابخوان شکست خورد. فاقد برخی از ویژگی‌های مهم مورد استفاده توسط کتابخوان الکترونیکی رقیب، مانند پشتیبانی از فرمت استاندارد صنعتی بود. با این حال، توجه داشته باشید که این مشکل را نمی‌توان پیش‌بینی کرد یا از آن اجتناب کرد. وقتی تیم ما کار شروع کرد، استاندارد صنعتی وجود نداشت. بنابراین، تأکید ما باید بر پاسخگویی تیم به آن چیزی باشد که پس از شروع کارش متوجه می‌شود.
این بار، پروژه چابک خواهد بود. ما با یک جلسه بزرگ شروع خواهیم کرد که در آن الزامات و مشخصات را ارائه می‌کنیم. اما قرار نیست به مدت ۱۸ ماه متوالی به آن برنامه پای‌بند باشیم. در عوض، ما آن یک سال و نیم را به دوی سرعت یک ماهه تقسیم می‌کنیم. یک چرخه واحد از حلقه بازخوردی که قبلاً درباره آن صحبت کردیم. به عبارت دیگر، ما هر ماه طراحی خودمان را در پاسخ به بازخوردها به‌روز می‌کنیم.
البته در ابتدا چیز زیادی برای آزمایش وجود نخواهد داشت، بنابراین ما به سرعت به دوره چهارم می‌رویم. هنگامی‌که مدیر پروژه، تیم و ذینفعان ملاقات می‌کنند، یکی از توسعه‌دهندگان گزارش می‌دهد که استاندارد صنعتی جدیدی برای قالب‌های کتاب الکترونیکی وجود دارد. این تیم این اطلاعات جدید را در دوره بعدی خودش گنجانده و کتاب‌خوانی می‌سازد که از قالب جدید پشتیبانی می‌کند. تا ششمین اسپرینت، آماده‌ست که آن قالب را در رابط کاربری کتابخوان قرار دهد.
همانطور که می‌بینید، هر اسپرینت تقریباً بر روی هر تکرار یا نسخه نرم‌افزاری که تیم در حال ساخت‌ست، نقشه می‌کشد. بنابراین اجازه دهید به ماه یازدهم برویم. یازدهمین دوره و یازدهمین تکرار. ما اکنون یک ساخت کار داریم که می‌توان آن را روی نمونه‌های اولیه تیم سخت‌افزار بارگذاری کرد. اما برای آزمایش در دنیای واقعی به اندازه کافی خوب‌ست، این دقیقاً همان چیزی‌ست که تیم می‌خواهد. هنگامی‌که مدیر پروژه با کاربران اولیه نرم‌افزار صحبت می کند، متوجه می‌شود که آنها مایلند بتوانند مقالات روزنامه و فایل‌های پی‌دی‌اف [PDF] را به دستگاه‌های خودشان ایمیل کنند. این تمرکز برای دوره بعدی تیم‌ست. یادگیری چابکی
این رویکرد فقط مربوط به آزمایش و ترکیب ویژگی‌های جدید نیست، اما می‌توان برخی از ویژگی‌ها را نیز کنار گذاشت. به عنوان مثال، شاید آن ویترین فروشگاه اینترنتی منطقی نباشد. بالاخره یک قالب استاندارد کتاب الکترونیکی وجود دارد، بنابراین ما مجبور نیستیم یک پلتفرم منحصربه‌فرد خودمان ایجاد کنیم. این مفیدست زیرا زمان را برای کار بر روی سایر ویژگی‌های مهم‌تر آزاد می‌کند.
احتمال اینکه این نسخه از پروژه به پایان برسد بسیار بیشترست. ما به طور مداوم نرم‌افزاری را برای آزمایش در دنیای واقعی منتشر کرده‌ایم. و در پاسخ به آن آزمایش‌ها تغییرات به موقع ایجاد می‌کنیم. تفاوت بزرگ در اینجا اینکه ما با مشتریان و کاربران در تماس هستیم. زمانی‌که از فرایند آبشاری استفاده کردیم، پس از تأیید الزامات پروژه، به طور کامل از این گروه‌ها جدا شدیم. با این حال، این بار، هدف نهایی خودمان را فراموش نکرده‌ایم: ساختن نرم‌افزار ارزشمند و کاربردی که نیازهای واقعی را برآورده می‌کند. و این دلیل چابکی است.
خلاصه نهایی
راه‌های زیادی برای چابکی وجود دارد، اما هر رویکردی بر اساس اصول اساسی یکسان‌ست. اولین مورد پاسخگویی‌ست. فرایندهای چابک همه درباره بازخورد هستند. شما برای آزمایش نرم‌افزاری که ساخته‌اید تا پایان پروژه منتظر نمی‌مانید – در اسرع وقت آن را در اختیار شما قرار می‌دهید. آزمایش در دنیای واقعی مشکلات را زود شناسایی می‌کند. و به مشتری کمک می‌کند تا روشن کند که چه کاری را برای انجام این نرم‌افزار نیاز دارد. اصل دوم؟ چیزی به نام طرح کامل وجود ندارد. هر پروژه‌ای به اصلاحات، تغییرات و بازطراحی نیاز دارد. اما این چیز خوبی‌ست. بهترین نرم‌افزار چگونه ساخته می‌شود.
شما می‌توانید این کتاب را از انتشارات چیتگرها تهیه کنید.
