آیندۀ چابک، گُه (Shit) نیست !

آیندۀ چابک، گُه (Shit) نیست ! این واژگان شاید آزاردهنده باشند اما بیانگر توصیفاتی است که عده ای چابک گرا در این سال ها به کار برده اند.

ترجمۀ مقاله ای از اسکات امبلر (Scott Ambler) پایه گذار چابک منضبط (DA)

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

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

• ما فراتر از بیانیه ها حرکت خواهیم کرد.
• ما بر توسعۀ نرم افزار تمرکز خواهیم کرد.
• ما فراتر از توسعۀ نرم افزار خواهیم رفت.
• ما باید تکنیک های چابک را در متن قرار دهیم.
• من کار خودم را تکامل خواهم داد.
• ما دوباره جویندگی طلا را را آغاز نخواهیم کرد.

ما فراتر از بیانیه ها حرکت خواهیم کرد

بیانیۀ  اصلی [بیانیۀ اصلی چابک مربوط به فوریه 2001] برای توسعۀ نرم افزار چابک به چالش هایی که توسعه دهندگان نرم افزار در اواخر دهه 1990 با آن مواجه بودند، پرداخت. ایده هایی که آن را به تصویر می کشد مدت ها پیش توسط جامعۀ توسعه دهندگان نرم افزار پذیرفته شد، تا جایی که توسعه دهندگان جدید برای درک داستان های مربوط به استراتژی های سنتی تلاش می کنند. واضح است که بیانی دیگر آن مصنوع رادیکال سابق نیست. آیا نباید جلو برویم؟

در طول سال ها افراد مختلف نیاز به یک بیانیۀ به روز شده را تشخیص داده اند. متأسفانه همه آنها با مشکلاتی روبرو شدند:

1. بیانیۀ اصلی به‌روزرسانی نمی‌شود. نویسندگان بیانیه موافقت کردند که بیانیه را به روز نخواهند کرد مگر اینکه همۀ آنها در مورد هر گونه تغییر توافق کنند. درک من این است که چندین نفر در مورد عدم تغییر آن مصمم هستند، و اینکه شما آن را دوست دارید یا نه، این تصمیمی است که ما باید به آن احترام بگذاریم.
2. گرد هم آوردن افراد باهوش از نظر فیزیکی کارساز نبود. برای دهمین سالگرد نشست اصلی در اسنوبرد[شهری در ایالت یوتای آمریکا]، آلیستر کاکبرن [از نگارندگان بیانیۀ اصلی چابک] جلسۀ جدیدی ترتیب داد تا مشخص کند که آیا بیانیه باید به روز شود یا خیر. اگرچه این یک کارگاه عالی بود، با صداهای بسیار خوبی که در آن شرکت داشتند، اما واضح بود که در مورد چگونگی حرکت رو به جلو، به جای همگرایی، واگرایی وجود دارد. نه تنها چیزی از آن حاصل نشد، بلکه احتمالاً حتی نمی دانستید که این اتفاق افتاده است.
3. همکاری مجازی به نتیجه نرسید. در رویداد Agile20Reflect در سال 2021، یک کنفرانس مجازی بین‌المللی یک ماهه با بیش از 200 جلسه، بسیاری از سخنرانان دیدگاه‌های خود را برای تکامل بیانیۀ چابک مورد بحث قرار دادند و تلاش‌هایی برای همکاری با یکدیگر آغاز شد. از هیچ یک از اینها نیز چیزی حاصل نشد.
4. به نظر می رسد انجام کار خود نیز کارساز نیست. هیچ چیز مانع از نوشتن دیگران بر روی نسخه های خود از بیانیۀ جدید چابک نیست و بسیاری از این تلاش ها در طول سال ها رخ داده است. من و مارک لاینز [همکار اسکات امبلر در طرح ریزی چابک منضبط] آن را با بیانیۀ چابک منضبط (DA) که در اوایل دهه 2010 نوشته شده بود، امتحان کردیم، با پیوستن آل شالووی [یک مشاور آمریکایی چابک] برای تبدیل آن به ذهنیت DA در اواخر سال 2019. این خود خوانشی عالی است که پایه ای برای چابکی سازمانی فراهم می کند. اما به طور گسترده مورد پذیرش قرار نگرفت.

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

به طور خلاصه، بیانیۀ چابک برای توسعۀ نرم افزار [بیانیۀ اصلی فوریه 2001] یکی از مهمترین و مختصرترین آثار در تاریخ مهندسی نرم افزار است. زمان اعلام موفقیت و حرکت فرا رسیده است.

ما بر توسعۀ نرم افزار تمرکز خواهیم کرد

در غیاب بیانیۀ جدید، چه کنیم؟ در مورد تمرکز بر روی شیوه های توسعه نرم افزار چطور؟ یا اگر آن کلمه را دوست ندارید، تکنیک‌ها، استراتژی‌ها و روش‌های کار (WoW)  [الگووارۀ چابک منضبط] نیز شرایط خوبی هستند. تمرکز اصلی جنبش چابک بر این بود که چگونه می‌توان در توسعۀ نرم‌افزار تیم کوچک مؤثر بود، بیشتر ابتکارات توسعۀ نرم‌افزار ده نفر یا کمتر هستند، و بازگشت به این تمرکز منطقی است.

برای انجام این کار، من معتقدم که ما شاهد رنسانس کار در زمینه های زیر خواهیم بود:

1. استخراج نیازمندی ها: استخراج نیازمندی‌های چابک بسیار بیشتر از نوشتن داستان‌های کاربری و انجام تمام کارهای سخت بر روی نقش مشکل‌پذیر مالک محصول (PO) است. من در حال مشاهدۀ جرقه های تجدید حیات در تحلیل کسب و کار هستم و با توجه به اهمیت روزافزون هوش مصنوعی در سازمان ها، تحلیل داده.
2. معماری نرم افزار: معماری چابک بسیار بیشتر از جهش گاه و بیگاه معماری و امید به اینکه معماری به نحوی ظهور کند وجود دارد. حداقل اگر به ایجاد راهکار های مبتنی بر نرم افزار که در آزمون زمان مقاومت می کنند و با استراتژی کلی سازمان شما تناسب دارند، اهمیت می دهید. یک منبع عالی برای معماران نرم افزار، انجمن بین المللی معماران نرم افزار (IASA) است.
3. کد پاک: در رویکرد ما برای نوشتن کد جا برای بهبود وجود دارد. این فقط در مورد نوشتن نرم‌افزار کارآمد نیست، بلکه تولید نرم‌افزار خوش‌ساخت و قابل استفاده است. فریاد به باب مارتین [نویسنده و مشاور توسعۀ نرم افزار] که با کتاب Clean Code خود کار بزرگی انجام داده است (درک من این است که او در حال کار بر روی نسخۀ دوم است) و همچنین به طور کلی کار او در زمینه ساخت نرم افزار.
4. دادۀ پاک: درست همانطور که باید کد پاک ایجاد کنیم، باید داده های پاک را نیز ایجاد کنیم. با توجه به رواج بدهی فنی داده ها در بیشتر سازمان ها، واضح است که ما در این فضا کارهای زیادی برای انجام داریم. خبر خوب این است که بسیاری از تکنیک‌های کیفیت داده، از جمله تکنیک‌های چابک وجود دارد.
5. رهبری تیم: جامعۀ چابک دو دهۀ گذشته را صرف سرکوب مدیران پروژه و چرخش داستان‌های ساده‌لوحانه پیرامون اسکرام مسترها کرده است. وقت آن است که با همۀ اینها کنار بیایم. تیم ها به رهبران موثر نیاز دارند و انواع مختلف تیم ها به انواع مختلفی از رهبران نیاز دارند. مطمئناً در مورد آنچه به مدیران پروژه در مورد رهبری تیم توسعه نرم افزار آموزش داده می شود، جا برای پیشرفت قابل توجهی وجود دارد (و بله، من به شما نگاه می کنم، انجمن مدیریت پروژه [PMI]). به طور مشابه، جامعۀ چابک موظف است یک استراتژی قابل اجرا برای چگونگی رهبری یک تیم نرم افزاری ایجاد کند که همه جنبه های انجام این کار را منعکس کند، نه فقط چیزهای چیپسی پفکی (Fluff) که به راحتی می توان آنها را “استاد” [Master] تایید کرد. هر دو گروه می توانند به وضوح از هر یک بیاموزند. دیگر، و امیدوارم آنها این کار را انجام دهند.

من چندین چالش را برای پیشرفت در این زمینه ها پیش بینی می کنم، البته چالش هایی که می توان با تلاش بر آنها غلبه کرد:

1. فرهنگ سنتی: به جز کد پاک، هنوز فرهنگ‌های سنتی قوی در همۀۀ این مناطق وجود دارد. این نشان می‌دهد که جامعۀ چابک هرگز برای مشارکت دادن آن جوامع به شیوه‌ای معنادار، از جمله سرمایه‌گذاری تلاش برای درک دیدگاه‌های آن‌ها و سپس اطلاع‌رسانی به آن‌ها، گام بر نمی‌دارد – فقط دعوت از آنها برای مشارکت با ما کافی نبود، بل نوعی سلب مسئولیت رقت برانگیز بود. توصیۀ من این است که متخصصان چابک به این انجمن‌ها بپیوندند، از آنها بیاموزند، و سپس هر کاری که می‌توانید برای کمک به آنها در استفاده از استراتژی‌های چابک انجام دهند.
2. فرهنگ چابک: فرهنگ چابک موجود که اهمیت این موضوعات را به حداقل می رساند نیز مشکل ساز است. این یک بار دیگر به دلیل عدم سرمایه گذاری در تلاش برای درک آنها، تمرکز بر لیز و لغزنده بودن (Fluff) به جای چیز (Stuff)، و همچنین لفاظی کاسب کارانۀ مجتمع صنعتی چابک (AIC) است که به طور هدفمند اهمیت آنها را به حداقل رساند. توصیه من این است که عقب نشینی کنید، تصمیم بگیرید که خارج از چارچوب جریان اصلی چابک فکر کنید و به جای آنچه که AIC می خواهد به شما گواهینامه دهد، توجه کنید که چه چیزی برای موفقیت در توسعۀ نرم افزار چابک لازم است.
3. عدم تخصص: به طور کلی در میان متخصصان چابک کمبود تخصص وجود دارد، زیرا ما این موضوعات را در دو دهۀ گذشته کم اهمیت جلوه داده‌ایم. خوشبختانه منابع بسیار خوبی در مورد این موضوعات وجود دارد که می‌توانیم از آنها به عنوان پایه‌ای برای حرکت به جلو استفاده کنیم.

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

[به نظر می رسد اسکات امبلر یک بازی واژگانی با Stuff و Fluff انجام داده است، اولی را می توان چیز ترجمه کرد و دومی را سوتی یا اشتباه. شاید با اندکی مطایبه بتوان دومی را لیز (لغزنده) ترجمه کرد که با چیز، بازی واژگانی نماید.]

ما فراتر از توسعۀ نرم افزار خواهیم رفت

توسعۀ نرم افزار تنها بازی در شهر نیست. کمی شکاف در جامعۀ چابک وجود دارد که آیا چابک باید خارج از توسعۀ نرم افزار به کار رود. چابک از دنیای نرم افزار آمده است و مطمئناً بیشتر آنچه در مورد چابک نوشته شده است بر روی تیم های نرم افزاری تمرکز دارد. با این حال، به عنوان یک مرد واقعی در زمین، من به راحتی می توانم مشاهده کنم که چابک بسیار فراتر از قلمرو نرم افزار اعمال شده است، و همچنان ادامه دارد. و بله، “خیر توسعۀ نرم افزار” با توسعۀ نرم افزار متفاوت است. این مشاهده دلیل دیگری است که چرا بیانیۀ چابک برای توسعۀ نرم دیگر پایۀ محکمی نیست.

برخی از زمینه هایی که استراتژی های چابک و ناب در آنها اعمال می شود عبارتند از:

1. مدیریت داده: مدیریت داده شامل فعالیت هایی برای ایجاد، مدیریت، ارائه و پشتیبانی از داده ها در یک سازمان است. سایت Agile Data مطالب زیادی را در مورد این موضوع ثبت کرده است.
2. معماری سازمانی: معماری سازمانی دیدگاهی را برای چگونگی ساخت سازمان شما توسعه می دهد، پشتیبانی می کند و تکامل می دهد. معماری سازمانی چابک یک رویکرد مشارکتی و تکاملی برای انجام این کار است.
3. امور مالی: امور مالی – بودجه ریزی، برآورد مالی، ردیابی مالی و گزارشگری مالی – یکی از جنبه های مهم همۀ سازمان ها است. انجام این کار به شیوه ای چابک/ ناب ممکن و بسیار مطلوب است. نهاد Beyond Budgeting ده ها سال در این فضا پیشرو بوده است.
4. حاکمیت: من همیشه گفته ام که شما تحت حاکمیت هستید، چه بخواهید چه نخواهید، و لیاقت این را دارید که خوب اداره شوید. حاکمیت، زنجیره‌های مسئولیت، اختیار و ارتباطات را در حمایت از اهداف و استراتژی کلی شرکت ایجاد می‌کند. همچنین اندازه گیری ها، خط مشی ها، استانداردها و مکانیسم های کنترلی را ایجاد می کند تا افراد را قادر سازد تا نقش ها و مسئولیت های خود را به طور موثر انجام دهند. حاکمیت تیمی چابک، مدیریت تیم‌های چابک یا ناب است به نحوی که روش‌های چابک و ناب کار را منعکس و پشتیبانی می‌کند.
5. امور حقوقی: روشی که وکلا کار خود را در سازمان شما انجام می دهند را می توان با استراتژی های چابک و همچنین هوش مصنوعی (AI) افزایش داد. به نظر می رسد کمی کار در این فضا در حال انجام است.
6. بازاریابی: من همیشه استدلال کرده ام که بازاریابی ذاتاً یک فعالیت چابک است و یک منبع عالی وبلاگ Agile Sherpas در مورد بازاریابی چابک است.
7. مدیریت افراد: مدیریت افراد اصطلاح ترجیحی من برای «منابع انسانی (HR) »است، زیرا از اشاره به افراد به عنوان منابع خودداری می‌کنم. سایت جامعۀ منابع انسانی چابک مطالب بسیار خوبی ارائه می‌دهد، و آنها فلسفۀ من را به اشتراک می‌گذارند که مردم منابع نیستند، اما انتخاب می‌کنند که جامعۀ منابع انسانی موجود با استفاده از اصطلاحات خود راهی برای استقبال بیشتر دارد.
8. تدارکات: با توجه به اینکه در فرآیندهای تدارکات در هر دو سمت دریافت و “تصدی گری” بوده ام، به جرات می توانم بگویم که فضای قابل توجهی برای بهبود در این فضا وجود دارد. من همیشه از طرفداران پر و پا قرص کاری بوده ام که توسط اتحاد Lean Agile Procurement (LAP) انجام می شود.
9. استراتژی: استراتژی بر نحوۀ مدیریت منابع، ریسک و بازده سازمان برای اطمینان از موفقیت و طول عمر تمرکز دارد. مؤسسه چابکی کسب و کار (BAI) در حال انجام کارهای خوبی در مورد استراتژی چابک است.
10. جریان های ارزش/منفعت: جریان‌های ارزش بر کل فرآیند رفت و برگشت ارایۀ ارزش پایدار به مشتریان از طریق محصولات و خدمات، و جریان‌های منفعت بر نحوه ارائه پایدار محصولات نرم‌افزاری به مشتریان متمرکز است. کار بزرگی توسط انجمن های مدیریت جریان ارزش (VSM)، Amplio، TameFlow و Profit Streams انجام می شود.
11. و بسیاری دیگر. این لیست کامل نیست، با عرض پوزش. هدف من این بود که روشن کنم که چابک بسیار فراتر از نرم افزار اعمال می شود، صرف نظر از اینکه برخی ممکن است ادعا کنند، نه برای ارایۀ یک منبع جامع.

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

ما باید تکنیک های چابک را در متن قرار دهیم

سال‌هاست که گفته‌ام که زمینه مهم است، که روش کار شما (WoW) باید وضعیتی را که با آن روبرو هستید منعکس کند. این یک مشاهدات مهم است زیرا روشن می‌کند که «بهین شیوه‌ها» وجود ندارد، که هر عمل معینی در برخی موقعیت‌ها به خوبی کار می‌کند و در موقعیت‌های دیگر ایده بسیار بدی است. اکنون تقریباً 40 سال است که به دنبال بهین شیوه ها هستم، و اگرچه در مورد هزاران روش بالقوه یاد گرفته‌ام، هنوز به یکی از آنها برخورد نکرده‌ام که در همه موقعیت‌ها به خوبی کار کند.

برای درک صحیح یک تکنیک – چه یک رویه، یک گردش کار، یک الگو یا شکل دیگری از  WoW –  می خواهید بدانید که آن تکنیک چیست، مزایای استفاده از آن تکنیک، معایب انجام آن، و زمینه ای که مؤثر شناخته شده است (و امیدوارم مؤثر نباشد). جامعۀ الگوها ده‌ها سال است که کار خود را در زمینه قرار می‌دهند و زمینۀ اولیه را که در آن یک الگو قابل اجرا است و بافت حاصل پس از اعمال الگو را توصیف می‌کند. ما باید همین کار را برای همه تکنیک ها انجام دهیم، نه فقط الگوها.

قرار دادن تکنیک ها در متن به چند دلیل مهم است:

1. ما تصمیمات بهبود بهتری می گیریم. درک زمینه به شما این امکان را می دهد که تصمیمات بهتری در مورد اینکه آیا یک تکنیک برای موقعیت شما مناسب است یا خیر، بگیرید. تیم های مختلف در موقعیت های مختلف تکنیک های متفاوتی را اتخاذ می کنند، به همین سادگی است.
2. ما گشوده تر می شویم. با دیدن این که تکنیک های چابک دارای اشکالاتی هستند، انگیزه می گیریم که افق خود را گسترش دهیم تا تکنیک های ناب و سنتی را در بر بگیریم. این به ما گزینه های بیشتری برای انتخاب می دهد و شانس تعریف WoW را که برای ما مناسب است افزایش می دهد. تیم‌های «چابک» که در عمل موفق هستند، همواره از یک رویکرد ترکیبی پیروی می‌کنند که صرفاً چابک نیست.
3. ما می توانیم بحث های بهتری در مورد WoW داشته باشیم. با قرار دادن تکنیک‌ها در زمینه، خود را قادر می‌سازیم تا با همکارانمان که ممکن است با مجموعه‌ای از تکنیک‌های متفاوت از آشنای ما آشنا باشند، گفتگوهای بهتری داشته باشیم.
4. ما کمتر به لفاظی می افتیم. هنگامی که متوجه می شویم که همه تکنیک ها ماهیت متنی دارند، احتمال کمتری وجود دارد که درگیر BS بازاریابی افرادی باشیم که روش ها، چارچوب ها و ابزارهای جدید را ارائه می دهند. بله، چیزی که آنها سعی دارند به شما بفروشند همیشه در برخی موقعیت ها به خوبی جواب می دهد، اما آیا این شامل حال شما نیز می شود؟

من اکنون از روزهای نخستین چابک، تکنیک ها را در چارچوب قرار داده ام. در واقع، زمانی که برای اولین بار کتاب توضیح برنامه‌نویسی کنت بک (XP) را خواندم، به این تفکر رسیدم. یکی از چیزهایی که من را تحت تأثیر قرار داد این بود که او به وضوح می‌دانست که XP کجا کار می‌کند و در کجا مشکوک بود که این کار را نمی‌کند. در اواخر سال های 2009 در IBM چیزی را توسعه دادم که آن را مدل مقیاس‌بندی چابک (ASM) نامیدم که مجموعه‌ای از عوامل زمینه مقیاس‌گذاری را توصیف می‌کرد. به موازات آن فیلیپ کروختن [مدیر پیشین توسعۀ IBM] “مدل هشت پا” خود را از 8 عامل زمینه ای که بسیار شبیه به ASM بود، توسعه داد. از آن زمان، من رویکرد خود را از طریق چندین تکرار به آنچه که فاکتورهای سفارشی سازی WoW می‌نامم، تغییر داده‌ام که هفت عامل را توصیف می‌کند که معمولاً می‌توانید آنها را تنظیم کنید و پنج عامل را که معمولاً نمی‌توانید تنظیم کنید. از آنجایی که هیچ بهترین شیوه، حتی زمانی که نوبت به ارزیابی زمینه می‌شود، برای حوزه باریک کیفیت داده (DQ) وجود ندارد، من بر پنج عاملی تمرکز می‌کنم که به پزشکان کمک می‌کند تا تکنیک‌های مناسب را برای موقعیت خود انتخاب کنند.

به طور خلاصه، بهین روش وجود ندارد. با قرار دادن تکنیک‌ها در زمینه، ذهن بازتر می‌شویم، مکالمات مؤثرتری را امکان‌پذیر می‌کنیم، تصمیمات بهتری در مورد WoW خود می‌گیریم، و احتمال کمتری دارد که به سمت BS بازاریابی بیفتیم.

من کار خودم را تکامل خواهم داد

من بیش از دو دهه است که مواد را در Agile Modeling (AM) و Agile Data (AD) تکامل می‌دهم. تلاش من برای انجام این کار در طول سال‌ها انجام شده و به کار گرفته شده است، معمولاً به این دلیل که من بر روی کار روش‌شناسی دیگر مانند چابک منضبط یا فرآیند یکپارچه سازمانی (EUP) که اکنون منحل شده است، متمرکز بودم. در طول پاییز 2022، من کمی تلاش کردم تا مطالب سایت هایم را به روز کنم و ظاهر و احساس آنها را مدرن کنم.

اما این کار کند شد در حالی که من روی تحصیلاتم تمرکز کردم، من در حال کار بر روی مدرک کارشناسی ارشد در هوش مصنوعی هستم که امیدوارم در دسامبر 2024 به پایان برسانم. در نتیجه، من هنوز لیستی از کارهایی که می خواهم انجام دهم، برای بیشتر از سال 2025 شروع می شود. به هیچ ترتیبی، این شامل موارد زیر است:

• تکنیک ها را در متن قرار دهید. تعدادی از تکنیک‌های موجود در سایت‌ها، به‌ویژه تکنیک‌های AD، شامل توصیه‌های متنی است. خیلی ها این کار را نمی کنند زیرا این اطلاعات در جعبه ابزار DA جمع آوری شده بود، هدف آن قرار دادن صدها تکنیک (حدود 1700 تا زمانی که من آخرین بار در آن شرکت داشتم) در متن بود. این شامل ده ها تکنیک مدلسازی، مستندسازی و داده است که در دو سایت من شرح داده شده است. زمان آن فرا رسیده است که من اطلاعات زمینه را برای تمام تکنیک های سایت خود قرار دهم.
• نمونه ها را به روز کنید بسیاری از مثال‌های من، اگرچه هنوز معتبر هستند، تاریخ دارند. به علاوه، بسیاری از آنها اسکن نمودارهایی هستند که با دست خط وحشتناک من ترسیم شده اند (به قول شوخی قدیمی، من می توانستم پزشک باشم). زمان انجام بهتر است.
• برخی از مواد قدیمی را حذف کنید. من تقریباً قبلاً این کار را انجام داده ام، اگرچه انتظار دارم همچنان با مطالبی روبرو شوم که دیگر مرتبط نیستند. به عنوان مثال، من یک بار مقدمه ای مفصل برای یک استاندارد داده جدید به نام XML و مجموعه ای دقیق از قراردادهای کدگذاری جاوا داشتم. در حالی که هر دو در دوران باستان، زمانی که آن فناوری‌ها جدید بودند، بسیار محبوب بودند، برای من کمی بیش از یک بار تعمیر و نگهداری شدند، بنابراین آنها را کنار گذاشتم.
• مواد را پر و پیمان کنید. بسیاری از جزئیات مربوط به AM و AD در سایت‌ها منتشر نشده‌اند، بلکه در کتاب‌ها، وبلاگ‌ها، مقالات و دوره‌های آموزشی ظاهر می‌شوند. زمان به روز رسانی و انتشار این ایده ها فرا رسیده است.

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

ما دوباره جویندگی طلا را آغاز نخواهیم کرد

یک: مفهوم اساسی در تعریف قلمرو تلاش این است که همیشه روشن بودن در مورد آنچه در قلمرو و آنچه خارج از قلمرو است، مهم است. اول، توصیه من این است که سعی نکنید نام چابک را تغییر دهید. در مقالۀ دوم از این مجموعه، من نشان دادم که کلمۀ “تطبیقی” [adaptive] را دوست دارم و همچنین استدلال خوبی برای “چالاک” [nimble] شنیده ام. اگرچه “چابک” به وضوح در حال حاضر به یک فحش تبدیل شده است، ما با تغییر نام آن کسی را فریب نمی دهیم. در بهترین حالت، تمام کاری که می‌توانیم انجام دهیم این است که کارهای زیادی را با تغییر نام چابک به یک اسم جدید با حال [CoolNewName] انجام دهیم تا مردم این تلاش را با مشاهدۀ «بله، اسم جدید باحال چابک که تازه هم داغ شده است» رد کنند.

دوم: به سادگی فرصتی برای جویندگی دوبارۀ طلا در افق وجود ندارد. تنها چیزی که نزدیک است، هوش مصنوعی (AI) است و من مطمئناً می بینم که بسیاری از شرکت های سابق مشاورۀ چابک به سمت معرفی خود به عنوان شرکت های مشاورۀ هوش مصنوعی روی آورده اند، اما این فرصت در بهترین حالت محدود است. فضای هوش مصنوعی تحت تسلط فروشندگان بزرگ فناوری مانند مایکروسافت، گوگل و OpenAI است و آنها بر هر برنامۀ صدور گواهینامه در حال پیشروی تسلط خواهند داشت. آموزش هوش مصنوعی متنوع، پیچیده و به تلاش قابل توجهی نیاز دارد. آن را از من بگیرید، من به تازگی دو سال گذشته را بر روی مدرک کارشناسی ارشد در هوش مصنوعی گذرانده‌ام و فقط ناخنکی زده ام. رهبران واقعی هوش مصنوعی تمایل دارند سال‌ها تجربه و مدرک دکترا داشته باشند، نه چند روز آموزش چیپسی پفکی (fluffy bunny) برای دریافت گواهینامه. ساختن سیستم‌های مبتنی بر هوش مصنوعی به تخصص داده‌ها نیاز دارد، چیزی که در جامعۀ چابک با کمبود مواجه است، بنابراین چابک گرایان سابق کارهای زیادی برای انجام دادن دارند. به طور خلاصه، موفقیت در مشاورۀ هوش مصنوعی نیاز به چیزهای (stuff) قابل توجه و سوتی (fluff) بسیار کمی دارد که آن را به یک مدل کسب و کار بسیار متفاوت از کوچینگ چابک تبدیل می کند.

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

جدول زمانی برای این چیست؟

به صراحت بگویم، دو سال آینده برای جنبش چابک بد خواهد بود، و شایسته است.

همه چیز برای افرادی که روی چیزهای با ارزش تمرکز می کنند شروع به بازگشت خواهد کرد. اگر ما این چیزهای ارزشمند را به اشتراک بگذاریم، و بسیاری از چابک گرایان، سابقه ای در انجام این کار داشته باشند، آنگاه جنبش چابک به مسیر خود بازمی گردد. زمان انجام کار سختی است که باید دو دهه پیش انجام می دادیم.

دیگر مقالات حوزۀ مدیریت چابک:

https://drkasbokar.com/خیز-بعد-از-ریدمان-چابک/