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