https://virgool.ir/feed/@m_83218790fa2026-11-12 22:52:20https://files.virgool.ir/upload/users/1146846/avatar/g1rg4S.pnghttps://virgool.ir/@m_83218790https://virgool.ir/@m_83218790/گزارشی-بر-گزارشات-بهبودِ-عملکردِ-تیمِ-نرم-افزاری-ق-سوم-ffowhmqmljyhبس که در خرقه‌یِ آلوده زدم لافِ صلاح – شرمسار از رخِ ساقیُ و میِ رنگینم (حافظ)این نوشته، ادامه‌ی قسمت دوم این مقاله می‌باشد.نویسندگان: محسن باقری – محمد عباسیتحول و اندازه‌گیری فرهنگدر جمع‌های دواپسی، اهمیتِ زیادِ مقوله‌یِ «فرهنگ» به امری بدیهی تبدیل شده است.(1). اما فرهنگ مسئله‌ای ناملموس است و همچنین تعاریف و مدل‌های متنوعی از آن وجود دارد. چالشِ ما باید یافتنِ مدلی از فرهنگ باشد که هم در ادبیاتِ علمی قابل تعریف باشد، هم بشود آن را بخوبی اندازه گرفت و همچنین به ما قدرت تخمین آینده را بدهد.در ادامه چنین مدلی را معرفی می‌کنیم و خواهیم گفت که چطور با پیاده‌سازیِ راه‌کارهای دواپس (DevOps)، فرهنگ را بهتر کنیم و تحت تاثیر بگذاریم.مُدل کردن و اندازه‌گرفتن فرهنگرویکردهای متنوعی برای مُدل کردن یا الگوسازیِ «فرهنگ» وجود دارد.(2). به‌عنوان مثال، فرهنگِ سازمانی را می‌توان صرفا «ارزش‌هایی (values)» دانست که رفتارِ تیم‌ها را می‌سازند. یا آنکه از جنبه‌های مختلف‌تری به آن نگاه کرد. مسئله این است که بسته به زوایه‌ی دیدِ ما، و همچنین هدفی که داریم، می‌توانیم مُدل‌های گوناگونی داشته باشیم.فرهنگِ سازمانی را می‌توان با سه سطح در سازمان تعریف کرد: یک، مفروضاتِ بنیادین. دو، ارزش‌ها. سه، مصنوعات (Schein 1985).اولین سطح، مفروضاتِ بنیادین (basic assumptions)، بواسطه‌ی فعالیت‌ها، رخدادها و ارتباطاتِ افرادِ یک سازمان در طول زمان شکل می‌گیرد. ولی تعاریف و تفاسیر در این سطح زیاد «مشخص (visible)» نیست، از جنس چیزهایی هستند که ما اگر یک مدت طولانی در تیم باشیم، «می‌دانم‌یشان» اما نمی‌توانیم براحتی بیانش کنیم یا فرموله‌سازیش کنیم.دومین سطح از فرهنگ سازمانی، ارزش‌ها (values)، برای اعضای یک جامعه «مشخص‌تر» هستند. و اساسا ارزش‌های جمعی و هنجارها (norms)، در بین افراد سازمان مورد بحث و مناظره هم قرار می‌گیرند و به بیانِ دیگر در خصوص آن صحبت می‌شود. اساسا ارزش‌ها «عینکی» هستند که اعضای یک گروه می‌توانند از طریقِ آن، روابط، رخدادها و فعالیت‌های پیرامون خودشان را تفسیر و قضاوت کنند. ارزش‌ها با ایجادِ هنجارهای اجتماعی که کُنش‌های اعضای گروه را تعریف می‌کنند، بر تعاملاتِ اعضای گروه تاثیر می‌گذارد. و همچنین قوانینی نانوشته وضع می‌کنند .(3). این‌ها اغلب همان «فرهنگی» هستند که وقتی از فرهنگ یک تیم و یک سازمان صحبت می‌کنیم به آن فکر می‌کنیم.سومین سطحِ فرهنگ سازمانی، مصنوعات (artifacts)، از همه «مشخص‌تر» است و کاملا قابل مشاهده است. مصنوعات شامل سندِ چشم‌انداز، مَسلَکِ سازمان، فناوری، رویه‌های رسمی و مناسکِ سازمانی باشد.بحث‌هایی که در جمع‌های دواپسی در خصوص اهمیتِ مقوله‌ی فرهنگِ سازمانی می‌شود، در سطحِ دوم (ارزش‌ها) است. الگو و مُدلی هم که برای بیان و تفسیر این سطح در نظر گرفته شده است هم مُدلِ جامعه‌شناسی بنامِ Ron Westrum است. آقای وِسترُم درموردِ عواملِ انسانی در ایمنیِ سیستم تحقیق می‌کردند، علی‌الخصوص در حوزه‌های فناورانه‌ی (technological) صنایع‌ای که، ریسک و پیچیدگی (complexity) بالایی دارند، نظیر حمل‌ونقل هوایی یا حوزه‌ی سلامت. ایشان در سال 1988 گونه‌شناسیِ (typology) فرهنگ‌های سازمانی را ایجاد کرد:بیمارگونه (Pathological) (قدرت محور): سازمان‌های بیمارگونه (power-oriented) به واسطه‌ی میزانِ زیادِ «ترس و تهدید» شناخته می‌شوند. افراد در چنین فضایی، غالبا اطلاعات را نزدِ خود نگه‌ می‌دارند، یا به دلایل سیاسی آن را مخفی می‌کنند، یا برای بهتر نشان دادنِ خودشان، آن را «تحریف» می‌کنند.بوروکراتیک (Bureaucratic) (قانون محور): در سازمان‌های بوروکراتیک (rule-oriented)، به دپارتمان‌ها اهمیت زیادی قائل‌اند. هر دپارتمان‌ هم متناسب با قوانین و خواستِ خودش، امور را جلو می‌برد.مُوَلِد (Generative) (شایسته‌سالار): در سازمان‌های مُولد (performance-oriented)، تمرکز بر «هدف (mission)» است. چطور وظیفه‌ی خود را درست انجام دهیم. در شایسته‌سالاری، همه چیز تابعی از عملکردِ خوب است تا بتوانیم وظیفه‌ی خود را درست انجام دهیم.وِستروم معتقد بود که فرهنگِ سازمانی، تعیین کننده‌ی «نحوه‌ی جریان اطلاعات (information flow)» در سازمان است. و سه خصیصه برای «اطلاعاتِ خوب (good information)» معرفی کرد:1. ابهامِ پرسش‌کننده را کامل برطرف می‌کند.2. همواره در دسترس است.3. در قالبی است که استفاده‌کننده می‌تواند به بهترین نحو از آن استفاده کند.جریانِ «اطلاعاتِ خوب»، امری حیاتی برای داشتنِ عملکردِ «درست» و «مطمئن» در محیط‌های حساس است. خصوصا در سازمان‌های فناوری‌محور، که تغییراتِ کوچک هم می‌توانند پیامدهای گسترده‌ای داشته باشند.(4).(5).وِستروم اعتقاد دارد، فرهنگِ سازمان از هر نوع که باشد (بیمارگونه، بوروکراتیک یا مولد)، خصیصه‌هایی خواهد داشت که در جدول زیر آماده است.یک نکته‌ی مهم دیگر از اندیشه‌ی وِستروم این است که چنین تعریف و الگویی از فرهنگِ سازمانی، تعیین کننده‌ی عملکردمان در آورده‌ها (outcomes) است.(6). از آنجاییکه ما زیاد شنیده‌ایم که «فرهنگ مقوله‌ی مهمی در DevOps است، در این مقاله بررسی خواهیم کرد که آیا فرهنگ، واقعا می‌تواند تعیین کننده‌ی عملکردِ تحویلِ نرم‌افزار باشد یا خیر.* عموما افراد بخاطر عواقبی که یک مسئولیت می‌تواند داشته باشد، از زیرِ بارِ آن شانه خالی می‌کنند. در فرهنگ مُولد با توزیع و پخش ریسک، ترس از مسئولیت‌پذیری را کم می‌کنند.اندازه‌گیریِ فرهنگانواعِ فرهنگ‌ها (بیمارگونه، بوروکراتیک و مُولد) در نظریه‌ی Westrum، در یک «طیف» هستند. به عبارتِ دیگر، یک فرهنگِ سازمانی، الزاما یا «قدرت‌محور» نیست یا «قانون‌محور». ‌می‌تواند تاحدی هم قدرت‌محور باشد و هم تاحدی قانون‌محور. این ویژگیِ بازه‌ای بودن، این امکان را می‌دهد که برای اندازه‌گیریِ فرهنگِ سازمان، از سوالاتِ Likert-type در نظرسنجی‌ها استفاده کنیم.(8).در فُرمِ نظرسنجیِ زیر، گزاره‌ها از مُدلِ وِستروم گرفته شده است و از مقیاسِ Likert استفاده شده است:پی‌نوشت 1: «دواپس ابزار نیست، فرهنگ است»: حرفِ مبتذلی که هم زیاد شنیده‌ام و هم متاسفانه گفته‌ام. از این دست جملات در مهندسی کم نیستند؛ مثلا در حوزه داده‌کاوی و هوش مصنوعی: «همه چیز دیتایست». یا در حوزه‌ی امنیت: «امنیت هیچوقت صد در صدی نیست». گزاره‌های نسبتا درستی که انقدر هم تکرار شده‌اند و از زبان هر کس و ناکسی درآمده است که رنگ باخته‌اند و از معنا تهی شده‌اند. اگر باور دارید که «امنیت صد در صدی نیست»، پس چرا زمانی که هک می‌شوید و اطلاعاتِ حیاتیِ کاربرانتان بر کفِ اینترنت نشت می‌کند هم، هزار جور آسمون‌ریسمون می‌روید که «نه هک نشده‌ایم، شایعه است، اختلالِ داخلی است، دیتاسنتر آتش گرفته است و...» و تا می‌شود «انکار» می‌کنید؟ و زیر بارِ مسئولیت نمی‌روید؟ فرد و سازمانی که به جمله‌ی «امنیت صد در صدی نیست» باور دارد، می‌داند که هر آن ممکن است که «هک» بشود، برای آن برنامه‌ریزی می‌کند و اگر «هک» هم بشود آن را می‌پذیرد و در سازمان «بگیروببند» راه نمی‌اندازد و اَنگُشت اتهام به سمت «فرد» نمی‌گیرد، «سیستم» را اصلاح می‌کند. مصادیقشان واقعا کم نیست، هرچه مسئله، جنسِ مدیریتی داشته باشد، مثل اجایل و اسکرام، این جملات هم بیشتر و شدیدتر می‌شوند. هر مُزَلفی هم که بخواهد در این حوزه‌ها گردن‌درازی کند، ابتدای عرایض‌اش چندتای آن را بی‌آنکه بفهمد طوطی‌وار بیان می‌کند و مخاطبانشان هم عموما بدون آنکه واقعا بفهمند از ناچاری و ترسِ نادان تلقی شدن، تایید می‌کنند. می‌دانم که شما هم «کله‌اتان از شنیدن این اراجیف خراب است»، ولی با عرض معذرت از شما مخاطبِ عاصی، من باید این جمله‌ی نسبتا صحیح اما گمراه‌کننده را اصلاح کنم، که «بله، فرهنگ در دواپس بسیار با اهمیت است و تاثیر مستقیم در عملکردِ تحویلِ نرم‌افزار دارد، و همچنین با راه‌کارهای دواپسی هم می‌شود فرهنگ را بهبود داد».پی‌نوشت 2: منظور از مُدل کردنِ فرهنگ، یعنی ارائه‌ی یک ساختارِ مفهومی (conceptual) یا یک تعریف برای بیان، توضیح و واکاویِ اعتقادات و احساساتِ گروه مشخصی از افراد. هر اجتماعی را می‌شود به شکل‌های گوناگونی تعریف (مُدل) کرد. به بیانِ دیگر، هر اندیشمندِ صائب نظری در این حوزه، با بررسی الگوهای رفتاریِ یک اجتماع (از یک تیم تولید گرفته تا افراد یک کشور)، آن را مدل می‌کند. هر مُدل، متناسب با هدفی که بر آن تاکید دارد، خصیصه‌های خود را دارد و از جنبه‌های مدنظرِ خودش در خصوص فرهنگ صحبت می‌کند. برخی از این مدل‌ها مشهورتر و بهتر هستند و خیلی دقیق‌تر یک جامعه را توضیح می‌دهند و برخی نه.پی‌نوشت 3: قوانینِ نانوشته، ترجمه‌ی contextual rules است. قوانینی هستند که به نوعی نیاز به بیان ندارند، با پذیرش ارزشی، در فرهنگ هستند. مثال: احترام به بزرگترها؛ در فرهنگ ما ارزشی بنام احترام به بزرگ‌تر هست که قوانین نانوشته‌ای هم برای خودش آورده است، مثلا جای خود را در اتوبوس به پیر مرد/زن دادن. و امثالهم. اما بنظرم، جدا از قوانینِ نانوشته، ما ارزش‌های نانوشته هم داریم که گاهی خیلی آزاردهنده است. سازمانی را تصور کنید، که در آن فضای سلسله‌مراتب و چابلوسی حاکم باشد. در چنین فضایی، چابلوسی نکردن، امری نابهنجار است. جلوی پای مدیر، از جای برنخواستن نابهنجار تلقی می‌شود. چرا که بر خلاف ادعایی که قطعا خواهند کرد، ارزشی نانوشته اینجا هست. یا در یک سازمانِ مذهبی، در ماه رمضان، حتا اگر کسی مانع ناهار خوردن شما نباشد، شما رفتاری «نابهنجار» کرده‌اید. بنظرم، این ارزش‌های پنهان، «سخت‌ترین» نوعِ ارزش‌های یک سازمان است. چرا که این ارزش‌ها از باورِ قلبیِ افرادِ تاثیرگذار سازمان بوجود آمده‌اند و بودنشان هم انکار می‌شود. برخلافِ «قوانین نانوشته» که نه‌تنها انکار نمی‌شوند، بلکه ممکن است تبلیغ هم بشوند. به همین خاطر گمان می‌کنم «ارزش‌های نانوشته» سخت و تغییرناپذیر باشند. این ارزش‌های پنهان احتمالا در سطحِ اول (مفروضاتِ بنیادین) قرار بگیرند.پی‌نوشت 4: محیط‌های عملیاتیِ محصولاتِ نرم‌افزاری یکی از همین محیط‌های حساس است که هر تغییری می‌تواند پیامدهای گسترده (high-consequence) داشته باشند. به عنوان مثال، محیطِ عملیاتیِ یک اپلیکیشنِ پراستفاده را تصور کنید. هر تغییر اشتباهی می‌تواند هزینه‌ی بالایی را تحمیل کند. Westrum معتقد است که برای چنین محیط‌هایی، جریانِ «اطلاعاتِ خوب» حیاتی است. البته تعریفی هم از اطلاعات خوب با بیان سه ویژگی ارائه داد.پی‌نوشت 5: احتمالا متوجه شده‌اید که از نگاهِ وِستروم، مستنداتِ خوب نرم‌افزاری، لازمه‌ی محیط‌های پیچیده‌ی امروزی هستند. اما متاسفانه بی‌توجهی به مسئله‌ی مستندات در تیم‌های نرم‌افزاری یا تقلیلِ «مستنداتِ نرم‌افزاری» به چند سندِ معماری، شایع است. امیدوارم فرصتی پیش‌آید تا در این خصوص به تفصیل صحبت کنم.پی‌نوشت 6: این همان ادعایی است که باید یقه‌اش را چسبید و بررسی کرد که آیا واقعا یک فرهنگ سازمانی (فارغ از آنکه چه باشد)، می‌تواند تعیین کننده‌ی عملکردِ تحویلِ نرم‌افزار باشد؟پی‌نوشت 7: من عبارت Messengers را «منتقدان» ترجمه کردم. برای بخش «بیمارگونه» دقیقا از لفظ «messengers “shot”» استفاده شده است. منظور افرادی هستند که از سر وظیفه خطاها، مشکلات و نگرانی‌های امنیتی را گزارش می‌دهند. در فرهنگِ بیمارگونه که قدرت حاکم است، چنین افرادی جریمه می‌شوند (مثلا ارتقا نمی‌گیرند)، یا به نوعی از گفتن می‌مانند. در چنین فضایی، هرگونه تغییرِ وضعیتِ فعلی برای برخی تهدید تلقی می‌شود. خب، پُرواضح است که نتیجه‌ی چنین فرهنگی، ایجادِ فضای ترس و سکوت است که افراد تمایلی برای رسیدگی به امور ندارند.پی‌نوشت 8: در علمِ روان‌سنجی (psychometrics)، برای اندازه‌گیریِ اِدراکاتِ (perceptions) افراد، از آن‌ها می‌خواهند که شدتِ موافقت یا مخالفتِ خودشان را به گزاره‌هایی امتیاز دهند. به عنوان مثال، شما نسبت به یک گزاره، ممکن است «بشدت موافق» باشید، «موافق» باشید، «تاحدی موافق» باشید، «نه موافق و نه مخالف» باشید، «تاحدی مخالف» باشید، «مخالف» باشید و یا «بشدت مخالف» باشید. به چنین مقیاسی، Likert scale می‌گویند. برای هرچه کاراتر کردنِ سوالاتِ این شکلی، باید از واژگانِ واضح و قاطع استفاده کرد که افراد بتوانند براحتی نسبت به گزاره‌ها واکنشِ «مخالف» و «موافق» داشته باشند (و البته که خنثی هم می‌توانند باشند).محسن باقریمحسن باقریWed, 26 Jul 2023 15:43:44 +0330https://virgool.ir/@m_83218790/گزارشی-بر-گزارشات-بهبودِ-عملکردِ-تیمِ-نرم-افزاری-ق-دوم-updrzaz0qn4cهرجا که ترس حاکم است، اطلاعاتِ غلط می‌گیرید.این نوشته، ادامه‌ی قسمت اول این مقاله می‌باشد.نویسندگان: محسن باقری – محمد عباسیخانمِ فرگوسن و تیم همراهشان، تیم‌های نرم‌افزاری زیادی را با چهار معیارِ مطرح شده در قسمت قبل سنجیدن. نتایج تحلیل‌های(1) تیمِ خانم فرگوسن، منتج به سه دسته شد(2). عملا با بررسی عملکردِ تحویل (software delivery performance) در صنعت نرم‌افزار ما به سه دسته‌ی «عملکرد بالا»، «عملکرد متوسط» و «عملکرد ضعیف» می‌رسیم که اجازه دهید برای بیان راحت‌تر، تا پیدا شدن ترجمه‌ای مناسب از الفاظی «غیر علمی» استفاده کنیم؛ برای high performersها بگوییم «خفن‌ها»، برای medium performers بگوییم «معمولی‌ها»، و برای low performers بگوییم «فَشَل‌ها». این سه دسته در هر چهار معیار(3)، کاملا باهم متفاوت هستند که این امر خودش تاکیدی بر اهمیت معیارهای مطرح شده است.جداول زیر، جزئیاتِ عملکردِ تحویلِ نرم‌افزار را به در سال‌های 2016 و 2017 را نشان می‌دهد:* در این معیارها، فشل‌ها پایین‌تر از میانگین هستند، اما باتوجه به میانه‌ی مشترک با معمولی‌ها، در یک دسته قرار گرفته‌اند.این نتایج نشان می‌دهند که هیچ بِده‌بِستانی (tradeoff) بین بهبود عملکرد (performance improvement) و رسیدن به پایداری (stability) و کیفیتِ (quality) بالاتر وجود ندارد، چه بسا «خفن‌ها» که سریع‌تر هستند، پایدارتر و باکیفیت‌تر هم هستند. اما افراد دُگم و فُسیل در این صنعت، همچنان مصّر به این فرضِ غلط هستند که «سریع‌تر» شدن بده‌بستانی با دیگر اهدافِ عملکردی است تا اینکه تسهیل کننده‌ی آن‌ها باشد. به بیان دیگر، تمام معیارها در یک راستا هستند، و بهبود در هرکدام، محرک و تسهیل‌گری برای بهبود در دیگری است، نه آنکه ما با سریع‌تر شدن، پایداری یا کیفیت را از دست بدهیم.خب تا اینجای کار، ما به مجموعه‌ای از معیارهای معتبر و قابل اتکا برای اندازه‌گیری عملکردِ تحویل نرم‌افزار «پیدا» کردیم، که نیازمندی‌های ما را پوشش می‌دهند. اما یک سوال مهم اینجا مطرح است که باید به آن پاسخ داد: «عملکرد تحویل نرم‌افزار (software delivery performance) مهم است؟».تاثیرِ عملکردِ تحویل بر عملکردِ سازمانیبرای اندازه‌گیری و سنجشِ عملکردِ سازمانی (organizational performance)، معیارهای شناخته‌شده‌ی این حوزه درنظر گرفته شدند، یعنی: سودآوری، سهمِ بازار، و بهره‌وری. این متر و معیارها کاملا نیز با معیارِ بازگشتِ سرمایه (ROI) همبسته (correlated) است.(4).تحقیقات چند سال اخیر نشان می‌دهند که «خفن‌ها»، دوبرابر بیشتر از «فشل‌ها» به اهداف کسب‌وکاری خود می‌رسند. این موضوع بیانگر این است که ظرفیت تحویلِ نرم‌افزارِ سازمان، می‌تواند برگِ برنده‌ی سازمان در دنیای رقابتی کسب‌وکار باشد. تحقیقات نشان می‌دهند که عملکردِ IT، تاثیر مستقیمی بر توانمند کردن سازمان برای رسیدن به اهداف تجاری خودش دارد. این توانمندی ورای کسب سود و درآمد بیشتر است، چرا که فارغ از آنکه سازمان به دنبال منافع مالی باشد یا نه، سازمان‌های امروزی برای تحقق اهدافشان و خلق سریع ارزش برای مشتریان و ذی‌نفعان خودشان به صورت پایدار و امن (securely)، به فناوری (technology) وابسته‌اند.(5)به هرجهت، فارغ از هدف، عملکردِ خوب سازمان در حوزه‌ی تکنولوژی، سوختِ عملکردِ کلیِ سازمان است بعبارتی اهدافِ غیرتجاری سازمان را هم کمک می‌کند. تحقیقات نشان می‌دهند «خفن‌ها» دوبرابر بیشتر می‌توانند به اهداف‌اشان در حوزه‌های تعدد محصولات و خدمات، راندمان اجرایی، رضایت مشتری، کیفیت محصولات و خدمات و چشم‌اندازهای سازمانی، دست یابند. شکل زیر این رابطه را به تصویر کشیده است:همانطور که در تصویر مشخص است، عملکردِ تحویلِ نرم‌افزار، بر عملکردِ سازمانی و عملکردِ غیرتجاری، تاثیر مستقیم دارد.(6).پیش از آنکه هر بحث دیگری را ادامه بدهم، ترجیح می‌دهم کمی در خصوص روش Lean صحبت کنم. داشتنِ یک درکِ کلی از lean خالی از لطف نیست، و در فهمِ بهتر مباحث پیشین و پیش‌رو کمک کننده است.مدیریت به سبکِ LEANظهور lean برمیگردد به شرکتِ ژاپنیِ تویتا (Toyota)، غول صنعت اتومبیل سازی جهان. اینکه چنین نگرشی توانسته این شرکت را به بزرگ‌ترین شرکتِ این صنعت (خیلی بالاتر از مرسدس و فورد) تبدیل کند یا نه را نمی‌دانم، اما بنظر مشخص است که اگر رویکردِ lean واقعا در فرهنگِ یک سازمان وجود داشته باشد، بی‌شک، دستاوردهای بزرگی حاصل خواهد شد.(7). بعدها lean در صنایع دیگر، مِن‌جمله صنعت نرم‌افزار وارد شد.(8)درواقع Lean یک متدولوژی برای مدیریت است که بدنبالِ رسیدن به حداکثرِ «ارزش» با حداقلِ «اتلاف» است. تمرکزِ lean بر «پیشرفتِ مستمر (continuous improvement)» و حذف «اتلاف (waste)» است. منظور از اتلاف، هرگونه فعالیت یا فرایندی است که در محصول یا خدمتِ نهایی، ارزشی نمی‌افزاید. مدیریت با نگاهِ lean، همواره بدنبالِ کشف و حذف این ناکارآمدی‌هاست تا بتواند هم هزینه‌ را کم کند، هم ارزش را بیشتر کند.در متدلوژی lean فرضی بصورت ضمنی پذیرفته شده است که تاکید بر آن بی‌فایده نیست. زمانیکه میگوییم Lean بدنبالِ حذفِ فعالیت‌ها و فرایندهای بی‌ثمر است، یعنی در lean بطور ضمنی پذیرفته شده است که «اضافه‌کاری» منجر به کمتر شدن کیفیت محصول نهایی می‌شود. توجه بفرمایید که در اینجا گفته نمی‌شود که کم‌کاری، علتِ معیوب شدنِ محصول نهایی است. منظور از «اضافه‌کاری» و «کم‌کاری» در ساعتِ کاری نیست. «اضافه‌کاری»، یعنی برای انجام یک عمل، مجموعه‌ای از کارها را انجام بدهی، یا یک بوروکراسی مفصل را بگذرانی که اگر با دقت به آن نگاه کنیم، خواهیم فهمید که تمام این اعمال، تاثیرِ واقعی در محصول نهایی ندارد. به عنوان مثال، بدن یک انسان را تصور کنید، اگر از یک حدی بیشتر (اضافه‌کاری) به آن خوراک برسد، به اندازه‌ی همان بیشتری، اضافه وزن حاصل می‌شود و به تعبیری کارآمدی بدن (محصول نهایی) را کمتر می‌کند. در نگرش lean این خوراک کم و کمتر می‌شود تا بدن به بهترین وضعیت خود برسد. به این ترتیب با حداقلِ اتلاف، حداکثرِ ارزش را بدست آورده‌ایم. واژه‌ی lean به در انگلیسی به معنای «ترکه» و «خوش‌هیکل» است و اساسا به کسی اطلاق می‌شود که «اضافه‌وزن» ندارد.(9).اساسا Lean برای دستیابی به هدف خود (خلق پیوسته‌ی ارزش و حذف اتلاف)، به مجموعه‌ای از اصول استوار است که ذکر همه‌ی آن‌ها در این مقاله آورده‌ای ندارد، ولی به برخی از آن‌ها خواهیم پرداخت. چرا که خیلی از معیارهای سنجش عملکردِ نرم‌افزاری که تا به اینجا ذکر شد، مبتنی بر همین اصولِ نگرش lean می‌باشد.یکی از اصول lean، «کار به ازای درخواست» است، بجای آنکه براساس نیازهای آینده تولید کند. به این معنا که تا نیازی از سمت مشتری نباشد، تولید دست به اقدامی نمی‌زند. این اقدام از بروز تولیدات اضافه جلوگیری می‌کند که خودش منجر به اعمال هزینه‌های انبارداری و مدیریت اضافه می‌شود.(10) همچنین lean برای دستیابی به عملکردِ بهتر، متعهد به اصل «پیشرفت کوچک ولی مستمر» یا همان اصل «کایزن (Kaizen)» است. یعنی حجم تغییرات کم (batch sizeهای کم)، ولی بطور مستمر در حال بهتر شدن. لازم به توضیح نیست که این اصل تا چه حد در دنیای نرم‌افزار مسئله‌ی مهمی است. و در آخر، اصل «به رسمیت شناختن افراد» است. یعنی تمام افراد را به عنوانِ بخشی از تیم بپذیریم و به آن‌ها اجازه بدهیم متانسب به شرایط تصمیم گیری کنند و با توجه به آموزش‌هایی که دریافت کردند، بتوانند فرایندها را بهبود ببخشند. این اصل در دنیای نرم‌افزار اهمیت دوچندانی دارد، بی‌توجهی در متعهد بودن به این اصل، علتِ بسیاری از ناکامی هاست. در این خصوص، در جای خود بیشتر صحبت خواهد شد.بطور مشخص متدلوژی lean برای دنیای نرم‌افزار که مطرح می‌شود، اصول و تعاریفش با اصطلاحات نرم‌افزاری بازتعریف می‌شوند. اما در اصل و ماهیت، چیز متفاوتی با آنچه من تا اینجا اشاره کرده‌ام ندارند. اگر یک پرسش اینجا حائز اهمیت باشد، این است که lean چه تفاوت یا شباهتی با agile دارد و اساسا فاصله‌ی این دو به چه شکل است؟Lean و Agile هر دو متدولوژی‌هایی برای تحویلِ سریعِ ارزش بصورت کارآمد (efficient) هستند. به بیان دیگر می‌توان ادعا کرد به تعبیری هر دوی این روش‌ها، اهداف مشترکی را دنبال می‌کنند، ولی تفاوت‌هایی در روشِ انجام و محل تمرکز دارند.Lean به دنبال به حداکثر رساندن ارزش با حداقلِ اتلاف است. خواستگاه این نگرش صنعت manufacturing است. Lean بر شناسایی (identifying) و حذف اتلاف در فرایند توسعه تاکید می‌کند تا کیفیت و کارآمدی افزایش یابد.اما Agile متمرکز بر انعطاف‌پذیری (flexibility) و تطبیق‌پذیری (adaptation) برای تغییر (change) است. خواستگاه این نگرش صنعت نرم‌افزار است. در اجایل برای رسیدن به تحویل سریعِ ارزش و پاسخ به نیازمندی‌های مدام درحال تغییر، تاکید بر «همکاری»، «تیم‌های خودمختار» و «چرخه‌های توسعه» است.بنظر میاید هر دوی این‌ها در کنار هم تاحدی سازگاری دارند و می‌توانند تکمیل کننده‌ی یکدیگر باشند. اما با این وجود برخی از معیارهای مطرح شده مبتنی بر مدل lean است تا agile. به عنوان مثال ما باتوجه به نگرش lean معیارِ lead time را اندازه‌ می‌گیریم و با مدل agile، معیارِ velocity را اندازه‌گیری می‌کنیم. که فرق این دو را مفصل صحبت کرده‌ایم.پس از بحثی به نسبت مفصل در خصوص lean، بهتر است برگردیم به رسالت اصلی مقاله، یعنی عملکردِ تحویلِ نرم‌افزار.مدیریت تغییرخب، تا اینجای کار ما «عملکردِ تحویلِ نرم‌افزار» را به روشی سخت‎گیرانه و قابل‌اندازه‌گیری تعریف کردیم. حالا می‌توانیم متناسب با شرایط و وضعیت کنونی، برای چگونگیِ بهبود عملکردِ خدمات و محصولاتِ نرم‌افزاری‌امان تصمیم بگیریم. باتوجه به داشته‌هایمان، اکنون می‌توانیم وضعیت پیش‌رفت یا پس‌رفت تیم‌ها را در گذر زمان رصد کنیم، می‌توانیم تیم‌ها را در قیاس با هم به هدف یافتن اقدام بهینه، benchmark کنیم. حال می‌توانیم فرضیه‌های مختلف را بسنجیم که مثلا تست‌نویسی واقعا چه تاثیری در عملکردِ تحویل خواهد داشت، یا هر تصمیم فنیِ دیگر. اکنون می‌توانیم آورده‌های (outcomes) مهم دیگری مثل «میزان فسیل شدن آدم‌های تیم» یا «درد نسخه‌گذاری» را هم اندازه بگیریم. اکنون می‌توانیم سوال‌های تاثیرگذارتری را پاسخ بدهیم، مثلا «آیا کمیته‌ی فنی که متشکل از افراد خبره در هر حوزه هست، به بهبود عملکرد منجر می‌شود؟» یا «آیا هیئتی از مشاوران برون سازمانی که تصمیمات کلان را می‌گیرند بهبود عملکرد منجر می‌شود؟». پاسخ این سوالات که مشخصا «خیر» است. تحقیقات ثابت کرده‌اند اتفاقا وجود چنین کمیته‌هایی دقیقا تاثیر عکس در «ضرب‌آهنگ تحویل» و «پایداری» دارند. ولی مسئله الان پاسخ به این سوال نیست (بعدا می‌پردازیم)، مسئله این است که اکنون ما این توانمندی را داریم که چنین دست سوالاتی از خودمان بپرسیم، و بتوانیم به آن‌ها پاسخ دقیق بدهیم.اما این‌ها کافی نیستند، ما می‌توانیم «فرهنگ» را هم بصورت کمّی (quantitatively) مدل کنیم و اندازه بگیریم. این توانمندی، امکان سنجش تاثیر DevOps و تحویلِ مستمر (continuous delivery) بر فرهنگ را ممکن می‌سازد. و حتا از آن مهم‌تر، تاثیر فرهنگ بر عملکردِ تحویل نرم‌افزار و عملکردِ سازمانی را می‌توان اندازه گرفت.توانایی ما در اندازه‌گیری و سبک‌سنگین کردنِ اقدامات (practices)، فرهنگ (culture) و آورده‌ها (outcomes)، یک توانمندیِ بی‌نظیر و قدرتمندی است که می‌تواند ما را در مسیر همواره بهتر شدن، راهبری کند.اگرچه گفته‌هایمان تاکنون برای پیاده‌سازی این موارد در عمل کافی بوده است، اما در آینده بیشتر به مسئله‌ی پیاده‌سازی می‌پردازیم، و چالش‌های آن را هم بررسی می‌کنیم تا رفتار ما باعث این نشود که افراد تیم، حس تحت کنترل بودن داشته باشند. به گفته‌ی Deming، « هرجا که ترس حاکم است، اطلاعاتِ غلط می‌گیرید.». فعلا نیاز است که در خصوص فرهنگ خود بدانیم و آن را بهبود بدهیم. در قسمت بعدی به این موضوع خواهم پرداخت.پی‌نوشت 1: نحوه‌ی تحلیل به روش cluster analysis بوده تا تحلیل داده‌ها بدون جهت‌گیری (bias) باشد. توضیحات بیشتر در این خصوص در کتاب accelerate.پی‌نوشت 2: البته از سال 2018، نتیجه‌ی بررسی‌ها، چهار خوشه شد، تا دوباره سال 2022 که عملا مجدد سه خوشه شد. تغییر تعداد خوشه‌ها، یک نکته‌ی حائز اهمیت و آموزنده است. اما من به این موضوع نمی‌پردازم. برای بررسی بیشتر به کتاب accelerate و گزارش سال 2022 گزارش وضعیت devops مراجعه کنید.پی نوشت 3: چهار معیارِ مرتبط با عملکردِ تحویل: مدت زمان تحویل (delivery lead timed)، تعدد نسخه‌گذاری (deployment frequency)، زمانِ بازیابی (mean time to restore) و نرخ شکست (change fail rate/percentage).پی‌نوشت 4: در این مقاله ما به تفصیل معیارهای عملکردِ تحویل را بررسی کردیم و خواهیم کرد. ولی برای عملکردِ سازمانی، استدلال و تحلیلی ارائه نخواهد شد، در صورت نیاز به فصل دوم کتاب accelerate مراجعه کنید.پی نوشت 5: فناوری با نرم‌افزار یکی نیست. خواننده‌ی هوشیار به این تفاوت توجه می‌کند.پی نوشت 6: در متن مکرر از عبارت «تحقیقات نشان می‌دهند/دادند» استفاده شده است. لازم به یادآوری است که این مقاله‌، گزارشی بر چندین گزارش است. و در متن گزارشات گه‌گاه جزئیات نحوه تحقیقات آمده است و در خصوص روش تحقیق هم بحث شده است. اما در این مقاله تا جای ممکن به این جزئیات پرداخته نمی‌شود. مخاطب می‌تواند به کتاب accelerate و مجموعه گزارشات مربوط به وضعیت devops موسسه‌ی DORA مراجعه کند.پی نوشت 7: در ایران هم کارگزاری مفید، به عنوان موفق‌ترین کارگزاری صنعت بورس، شعارِ سازمانی «پیشرفتِ مستمر» را دارد که بنظر تاثیرگرفته از نگرشِ lean است.پی نوشت 8: صنعت نرم‌افزار چند ویژگی منحصر بفرد دارد که آن را متمایز از دیگر صنایع می‌کند. یکی از بارزترین آن‌ها ملموس نبودن خروجی آن است. اساسا به همین خاطر هم اندازه‌گیری عملکردِ آن بسیار پرچالش است. از این رو، خیلی از مباحثی که در صنایع manufacturing مشترک است، در صنعت نرم‌افزار بی‌کارکرد است و بلعکس. اما lean از آن دست مباحث مدیریتی است که با اندک تغییری کاملا منطبق با نیازمندی‌های دنیای نرم‌افزار است.پی نوشت 9: شکی ندارم که تا این لحظه مصادیقِ زیادی به ذهنتان خطور کرده است که فقط «اضافه‌کاری» هستند. یکی از آن مصادیق که برای من بیشتر خودنمایی می‌کند، مسئله‌ی «خدمت نظام وظیفه» است. پروژه‌ای آشفته که پس از چند دهه از اجرای آن، علی‌رغم هزینه‌ی گزافی که داشته و دارد، همچنان محصول نهاییِ آن مشخص نیست! ابتدا به هدفِ تقویت قوای نظامی کشور بواسطه نیروی آموزش‌دیده‌ی مردمی تاسیس شد، اما آیا این نتیجه حاصل شده است؟ یا برای تحقق چنین نتیجه‌ای، به چنین «اتلافی» (مدت دو سال سربازی برای این تعداد سرباز) در زمان صلح واقعا نیاز است؟ در نگرش lean تاکید بسیاری می‌شود که تا زمانیکه نیاز به نیروی نظامیِ مردمی نیست، نیروی نظامیِ مردمی تربیت نکنیم. صحبت در این خصوص بسیار است، ولی به این پرسش بسنده می‌کنم که آیا شرایط به‌گونه‌ای است که اضافه شدن یک نیروی کار (سرباز)، به همان اندازه من را به هدفِ نهایی‌ام نزدیک می‌کند؟ یا من برای بدست آوردن یک نیروی بی‌تجربه، مجبور شده‌ام بسیجی از نیروهای باتجربه‌ی خودم را هم برای مدیریت سربازان بکاربگیرم؟ امیدوارم در آینده، دست‌کم سودآوری این پروژه با دقت بیشتری بررسی شود، تا شاید زیان‌ده بودن این پروژه بتواند جلوی اتلاف وقت و جانِ خلق‌الله را بگیرد.پی نوشت10: در صنعت به این روش، سیستمِ just-in-time production یا سیستمِ pull-based می‌گویند. بد نیست اشاره کنم که سیستم Kanban که این روزها در صنعت نرم‌افزار مقبولیت دارد، برهمین مدل استوار است. سیستم just-in-time production می‌گوید میزان و کیفیتِ تولید محصول، باید دقیقا متناسب به میزانِ درخواستی مورد نیاز باشد و همچنین دقیقا همان خواسته‌ی کیفی مشتری باشد، نه بیشتر یا کمتر. جالب است بدانید سیستم Kanban هم از ابداعات شرکت تویوتا است.محسن باقریمحسن باقریWed, 26 Jul 2023 15:37:32 +0330https://virgool.ir/@m_83218790/گزارشی-بر-گزارشات-بهبودِ-عملکردِ-تی-ِم-نرمافزاری-ق-یکم-gltzwtzy3gfsمهندس . [ م ُ هََ دِ ]: اندازه‌گیرنده.نویسندگان: محسن باقری – محمد عباسینکته: در جاهایی که عدد داخل پرانتز است به پی نوشت مربوطه مراجعه کنید.زمانی که به «بهودِ» وضعیتِ عملکردی یک تیم نرم‌افزاری فکرمی‌کنیم، مجموعه‌ای از راهکارها در ذهنمان جاری و ساری می‌شود. ولی اینکه کدام راهکار را به عنوان اولین قدم بَرگُزینیم مسئله‌ی اصلی است. به هرجهت، سفرِ «بهتر» شدن، بدون در نظر گرفتن چهار چیز، ناشدنی است. اول از همه مبدا، دوم مقصد و سوم نقشه‌ی راهِ رسیدن از مبدا به مقصد و چهارم، جهت‌نمایی که به ما تضمین بدهد که حرکت ما به سمتِ نزدیک‌تر شدن به مقصد است.با این تفاسیر، پیش از آنکه به پرسشِ «کدام راهکار را برگزینم؟» پاسخ بدهیم، تا بتوانیم سفرِ «بهتر» شدن را آغاز کنیم، مسئله‌ی دیگری مطرح است، و آن مهیا کردنِ ملزوماتِ این سفر است. که در این مقاله، این موضوع را بررسی می‌کنیم.منظور از مبدا، مقصد، نقشه‌ی راه و جهت‌نما چیست؟ بی‌شک این تعابیر نمادین هستند، و منظور از مبدا، «وضعیت فعلی»، و منظور از مقصد، «وضعیت مطلوب» و منظور از نقشه‌ی راه، «مجموعه اقداماتِ مناسب برای رسیدن به وضعیت مطلوب»، و منظور از جهت‌نما، «ترازویی برای ارزیابی وضعیت» است. تاکید بر لفظ «سفر» از این بابت است که فرایندِ بهتر شدن یک پدیده‌ی «یکباره» نیست. اساسا همچون هر فرایند دیگری، «رخداد» یا «اتفاق» نیست(1).پس من برای مهیا کردن ملزوماتِ «سفرِ بهتر» شدن، پیش از هرچیزی به ترازویی برای ارزیابی وضعیت نیاز دارم، تا بتوانم وضعیت فعلی را براورد کنم، و با توجه به وضعیت فعلی، بتوانم وضعیتِ «مطلوب» را هدف‌گذاری کنم. و متناسب به هدف‌گذاری صورت گرفته، مجموعه اقداماتی را آماده کنم که بتواند من را به سمت وظعیت مطلوب برساند (یا نزدیک کند). از این ترازوی عملکرد هم بطور پیوسته استفاده خواهم کرد تا مطمئن شوم که اقداماتم به در راستای انتظاراتم است.اما این ترازوی عملکرد چیست؟ ادامه‌ی این مقاله تا انتها به این مسئله می‌پردازد.ترازوی عملکردتاکنون تلاش‌های زیادی برای اندازه‌گیری عملکردِ تیم‌های نرم‌افزاری صورت گرفته است که اغلب این معیارها متمرکز بر امرِ «بهره‌وری (productivity)» بوده‌اند و عموما دو اشکالِ اساسی دارند:اول. این معیارها (متریک‌ها) متمرکز بر «خروجی (output)» هستند، بجای آنکه متمرکز بر «آورده (outcome)» باشند. (2)دوم. این معیارها متمرکز بر اشخاص هستند بجای آنکه بر تیم‌ تمرکز کنند، یا اگر بر یک تیم هم تمرکز کنند، وضعیت آن تیم را نسبت به خودش می‌سنجند، نه آنکه متمرکز بر وضعیت تیم در قیاس جهان-شمولی باشند.اجازه بدهید دو تا از این معیارها را باهم بررسی کنیم: معیارِ «خطوطِ کُد (lines of code)» و معیارِ «سرعت (velocity)».معیارِ خطوط کُد – lines of codeبرآوردِ بهره‌وری (productivity) بکمک معیارِ خطوطِ کُد (lines of code) تاریخچه‌ی مفصلی در صنعت نرم‌افزار دارد (3). خیلی از شرکت‌ها از این معیار (یا مشتقات آن(4)) استفاده می‌کردند و می‌کنند، در حالیکه در واقعیت ما می‌دانیم که راهکار 10 خطی بهتر از راهکار 1000 خطی برای یک مشکل است. وقتی توسعه‌دهندگان را تشویق به بیشتر کردن تعداد خطوط کُد بکنیم، در عمل آن‌ها را سوق داده‌ایم به سمت چَرندنویسی و تولید کُدهای وَرَم کرده (inflated) و شکننده که در نتیجه، هم هزینه‌ها‌ی نگهداری (maintenance costs) را زیاد می‌کنند، هم هزینه‌‌ی تغییرات (cost of change) را. در حالیکه در دنیای ایده‌آل باید به توسعه‌دهندگانی پاداش داد که برای حل مشکلاتِ کسب‌وکاری، حداقل کُد ممکن را می‌نویسند، و یا حتا از آن بهتر بدون نوشتن کُد یا حتا با پاک کردن کُد، مشکلی را حل می‌کنند (مثلا با تغییر یک فرایند کسب‌وکاری).به هرحال، معیار تعداد خطوطِ کُد در هر دو جهت بی‌کاربرد است. به این معنا که نه «کم» بودنِ تعدادِ خطوطِ کُد تضمین کننده‌ی کیفیت است نه «زیاد» بودن تعدادِ خطوط.معیار سرعت - velocityبا ظهور بحث توسعه‌ی نرم‌افزار اَجایل (چابک)، معیار جدیدی در بحث اندازه‌گیریِ بهره‌وری مطرح شد: سرعت (velocity). در خیلی از مکاتبِ اَجایل، مسائل (problems) به عناصر کوچکتری بنام اِستوری (story) شکسته می‌شوند و بعد از آن توسعه‌دهندگان (developers) به این اِستوری‌ها امتیاز (point) می‌دهند. این امتیاز نمایانگرِ تلاش نسبیِ (relative effort) پیشبینی شده برای تکمیلِ آن اِستوری است. و در پایانِ هر چرخه‌ی توسعه (iteration) مجموع آن امتیازهای انجام شده را محاسبه می‌کنند، و به حاصلِ آن می‌گویند سرعتِ (velocity) تیم. غالبا از معیارِ سرعت به جهت تخمین ظرفیتِ تیم استفاده می‌شود. به این معنا که یک تیم که معیارِ سرعت آن عدد ایکس است، میتواند در هر چرخه ایکس-امتیاز کار انجام دهد. برخی از مدیران از این معیار به عنوان معیاری برای سنجه‌ی بهره‌وریِ تیم هم استفاده می‌کنند، یا حتا آن را مقیاسی برای مقایسه‌ی تیم‌ها با یکدیگر درنظر می‌گیرند.استفاده از معیارِ سرعت (velocity) به عنوان متری برای ارزیابیِ بهره‌وریِ تیم، چند اشکال دارد. اولا، سرعت یک معیار نسبی (relative) است و کاملا وابسته به تیم است، نه یک معیار مستقل.(5). دوما، زمانیکه سرعت را معیار بهره‌وری قرار بدهیم، تیم‌ها را گرفتارِ بازیِ سرعت خواهیم کرد و از اعضای آن‌ها رفتارهای غیرقابل‌انتظاری مشاهده خواهیم کرد؛(10) تخمین‌های خودشان از کار را، بالا (غیرواقعی) می‌دهند و بجای آنکه دغدغه‌ی همکاری با تیم‌های دیگر را داشته باشند، دغدغه‌ی هرچه بیشتر انجام دادن امتیاز اِستوری (story point) را خواهند داشت. به بیان دیگر، برای خلق ارزش واقعی، گاهی یک تیم باید وقت خود را صرفِ همکاری و کمک به یک تیم دیگر بکند، اما از آنجا که چنین فرهنگی در چنین شرایطی، سرعت تیم اول را پایین‌تر ارزیابی می‌کند، تیم اول ترجیح می‌دهد که بجای کمک به تیم دوم، استوری‌پوینت‌های خودش را تکمیل کند. در چنین مواقعی ما صرفا بهره‌وری را کاهش ندادیم، ما به فرهنگِ همکاریِ درون سازمانی لطمه زده‌ایم.حال که اشکالات برخی از معیارهای متداولِ اندازه‌گیریِ عملکردِ تیمِ نرم‌افزاری را دیدیم، چه معیارهای مناسب این امر است؟ در ادامه به این موضوع می‌پردازم.معیارهای اندازه‌گیرییک معیارِ درست برای سنجشِ عملکرد، باید دو خصیصه داشته باشد؛خصیصه‌ی اول: مبتنی بر براوردِ جمعی (global outcome) باشد تا مبادا تیم‌ها در مقابل هم قرار بگیرند. یک نمونه‌ی کلاسیک و ملموس‌اش تشویق تیمِ توسعه‌ به نسخه دادن، و تشویقِ تیم عملیات به پایداری است.(11) چیزی که از آن به عنوان «دیوارِ اختلافات (wall of confusion)» یاد می‌شود. زمانی که عملکردِ تیم‌ها را جمعی بررسی نکنیم، یا به عبارت دیگر، آورده‌ی (outcome) نهایی را معیار قرار ندهیم و متمرکز بر خروجی‌ها (outputs) باشیم، با تیم‌هایی طرف خواهیم شد که صرفِ داشتن گزارش عمکردِ بهتر، به سمت بیشتر کردن خروجی می‌روند و در واقعیت ارزشی را تولید نمی‌کنند (یا به اندازه‌ی ظرفیتی که دارند، تولیدِ ارزش نمی‌کنند). در این خصوص پیش‌تر هم صحبت شد. اما به عنوان آخرین مثال، زمانیکه عملکرد تیم توسعه را صرفا با تولید فیچر یا نسخه زدن بسنجیم، آن‌ها را باوجودِ داشتن بدهی‌های فنیِ سنگین، ترغیب کرده‌ایم که تمام توان خودشان را بکاربگیرند که کُدافزایی کنند و در نهایت کُدی بی‌کیفیت را تحویل تیم عملیات بدهند. تیم عملیات هم ناگزیر طی یک فرایندِ زجر آور و خسته‌کننده باید نسخه را در محیط عملیاتی نصب و نگهداری کند.خصیصه‌ی دوم: معیار باید مبتنی بر آورده‌ها (outcomes) باشد نه خروجی‌ها (outputs).تحقیقات خانم نیکول فورگسن و تیم همراهشان در خصوص کشف و خلق معیارهای اندازه‌گیری عملکرد که چنین خصیصه‌هایی را داشته باشند، به معرفیِ چهار معیار منتج شد: معیارِ «مدت زمانِ تحویل (delivery lead time)»، «تعدد نسخه‌گذاری (deployment frequency)»، «زمان بازیابی (time to restore)» و «نرخ شکست تغییر (6) (change fail rate)». که در ادامه به چرایی انتخابِ این معیارها می‌پردازیم.معیار مدت زمان تحویل – Lead Timeمعیارِ «مدت زمان تحویل (delivery lead time)»، زمانی است که می‌گوید، از لحظه‌ای که مشتری درخواستی داده است تا زمانیکه درخواست‌اش اجابت شده است، چقدر طول کشیده است. این زمان طول کشیده را lead time می‌گوییم. به بیان دیگر، از زمانی که مشتری نیاز خودش را برای ما مطرح کرده است، چند دقیقه یا چند ساعت یا چند روز و هفته طول کشیده است تا ما آن نیاز را تحویل بدهیم.اگر دقیق‌تر بررسی کنیم، خود این معیار هم در واقع از دو بخش تشکیل شده است؛ یک بخش، مربوط به زمانی است که طول کشیده تا درخواست مشتری تحلیل و طراحی و راه‌حل کشف شود، یک بخش هم زمانی است که طول می‌کشد تا راه‌حلِ تولید شده، تحویل مشتری داده شود. در واقع مجموعِ زمانِ این دو بخش است که «مدت زمان (lead time)» را مشخص می‌کنند. اما این دو بخش ماهیت متفاوتی باهم دارند، و توجه به این نکته حائز اهمیت است.در بخشِ «طراحیِ» معیارِ مدت زمان (بخش اول)، همه چیز ممکن است ناواضح باشد و ما با دنیایی از عدم قطعیت طرف باشیم، چرا که متغیرها در این فضا زیاد است. به همین خاطر Reinersten این بخش را fuzzy front end می‌نامد. اما در بخشِ «تحویل» (بخش دوم)، وضعیت اینگونه نیست و با توجه به متغیرهای کم‌تری که وجود دارد، راحت می‌توان زمانی که برای ساختِ آرتیفکت، تست و تحویل محصول سپری می‌شود را اندازه گرفت. جدول زیر نیز تفاوت این دو بخش را نمایان کرده است:هرچه زمانِ بخشِ «تحویل محصول» کوتاه‌تر باشد، نتیجه بهتر است. چرا که این امکان را مهیا می‌کند که هرچه سریع‌تر بازخوردِ آن چیزی را که تولید کرده‌ایم را دریافت کنیم و در صورت وجود خطا، آن را بسرعت اصلاح کنیم. جدا از این مورد، ممکن است نسخه باعث اختلال (defect) و یا قطعی (outage) شود، ما نیاز داریم که در سریع‌ترین زمان ممکن نسخه‌ی سالم را عملیاتی کنیم. به همین خاطر باید تلاش به سمتی باشد که مدت زمان تحویل محصول به حداقل برسد.برای اندازه‌گیریِ بخشِ دومِ این معیار (تحویل محصول)، مدت زمان سپری شده از لحظه‌ای که کُد در شاخه‌ی مربوطه‌اش کامیت شده است تا نسخه در عملیاتی با موفقیت اجرا شده است، را اندازه می‌گیرند.معیارِ تعدد نسخه‌گذاری – Deployment Frequencyاما معیارِ دوم. این معیار در ملاحظه با حجم تغییرات (batch size) است. (7). کم کردن حجم تغییرات یکی از المان‌های اصلی پارادایم LEAN است. کم‌کردن حجم تغییرات، زمان و ناپایداری چرخه‌ی تولید را کاهش می‌دهد، بازخورد را سرعت می‌بخشد، ریسک و سربار را کاهش می‌دهد، بهره‌وری را افزایش می‌دهد، انگیزه را تقویت می‌کند، هزینه‌ها را کاهش می‌دهد و رشد را قابل پیش‌بینی می‌کند. اما گرفتاری اینجاست که در حوزه‌ی نرم‌افزار، اندازه‌گیریِ حجم تغییرات کاری مشکل و گه‌گاه نشدنی است. به همین جهت از معیارِ «تعدد نسخه‌گذاری (deployment frequency)» به عنوان یک پوسته‌ برای معیارِ «حجم تغییرات» استفاده می‌کنیم. تعدد نسخه‌گذاری براحتی قابل اندازه‌گیری است و میزان بالای آن، می‌تواند بیانگر میزان پایین حجم تغییرات باشد.(8). منظور از «نسخه‌گذاری» این است که نرم‌افزار مثلا روی app store بشیند یا روی محیط عملیاتی نصب شود.یک ریلیز (release)، یعنی تغیری که قرار است نصب (deploy) شود، معمولا شامل چندین فیچر است، مگر اینکه سازمان تصمیم بگیرد که هر فیچر را به مجرد تکمیل شدن عملیاتی کند (عملی که از آن به عنوان نصب مستمر (continuous deployment) یاد می‌شود.).معیارهای «زمانِ تحویل» و «تعدد نسخه‌گذاری» را می‌توان ضرب آهنگِ عملکردِ تحویل (delivery performance) نرم‌افزار باشند. یعنی موفقیت یا شکست در این دو معیار، نشان‌دهنده‌ی عملکرد سریع یا کُند تیم در تحویل نرم‌افزار است.معیارِ زمان بازیابی – Mean Time to Restoreاگرچه که ما انتظار سرعت و چابکی در تحویل محصول را داریم، ولی این امر را زیر چتر «پایداری» می‌خواهیم. در گذشته، پایداری را با اندازه‌گیری زمانِ بین شکست‌ها می‌سنجیدن. به عبارت دیگر اگر یک سیستم مدت زمان زیادی از آخرین اختلال‌اش می‌گذشت، به همان نسبت پایدار تلقی می‌شد. ولی در دنیای پیچیده‌ی محصولات و سرویس‌هایِ نرم‌افزاریِ امروزی، شکست و اختلال امری اجتناب ناپذیر است. بنابراین سوال اساسی این است: وقتی که با قطعی مواجه می‌شوی، چقدر زمان طول می‌کشد تا آن را برطرف کنی؟ پاسخ به این سوال، پایداری سیستم‌های پیچیده‌ی مدرن را نشان می‌دهد. به همین خاطر معیارِ سوم، «زمانِ بازیابی (time to restore)» است.معیارِ نرخ شکست – Change Fail Percentageآخرین معیار (نرخ شکست) مشخص کننده‌ی میزان درصد شکست به نسبت تغییرات است. تغییرات اعم از هر نوع تغییر (چه افزودن فیچر، چه تغییر تنظیمات سرور عملیاتی)، اگر منجر به شکست شود، نرخ شکست افزایش میابد.در مقاله بعدی به بررسی تاثیر این معیارها بر عملکرد تیم و سازمان می‌پردازیم. منبع اصلی این سلسله مقالات گزارشات موسسه DORA و کتاب Accelerate می‌باشد، و به نوعی این مقالات گزارشی بر گزارشات DORA و کتاب مذکور می‌باشد.پی‌نوشت1: پذیرشِ این موضوع (که بهتر شدن یک فرایند است) علی‌رغم اهمیت بسیار زیادی که دارد، در این مقاله بررسی نمی‌شود. چنانچه مخالفِ این گزاره هستید به کتاب Accelerate و فصل دوم Measuring Performance مراجعه کنید.پی‌نوشت2: خروجی یک چیز است، آورده یک چیز دیگر. ممکن است گاهی در یک راستا باشند، و گاهی کاملا در جهت عکس. به عنوان مثال فرض کنید شما با حذف یک قابلیت از نرم‌افزار، رضایت مشتری را جلب کردید. در اینجا علی‌رغم آنکه خروجی نداشته‌اید، آورده داشته‌اید. تاکید بر متر و معیار خروجی، کارِ گِل می‌آفریند. مثال دیگر: زمانی که متر و معیار «بهره‌وری» ساعت کاری باشد، نه دستاوردِ کاری، با افرادی مواجه خواهیم شد که ساعت‌های زیادی را کار می‌کنند بدون آنکه دستاورد خاصی داشته باشند.پی‌نوشت3: در این لینک داستانی در این خصوص نقل شده است که نشان می‌دهند چطور با کمتر کردن 2000 خط کد توانستند عملکرد یک الگوریتم را تا 6 برابر بهتر کنند و اینکه چقدر معیارِ تعدادِ خطوطِ کُد می‌تواند بی‌معنی باشد. https://www.folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt&sortOrder=Sort+by+Dateپی‌نوشت 4: معیارهای مشابه: code coverage یا امثالهم. اساسا هر معیاری که مترِ آن صرفا «شمارش چیزی» باشد، بی‌آنکه بتواند مسئله‌ای را اثبات کند. معمولا این معیارها می‌توانند بصورت negative indicator نقش ایفا کنند اما نتیجه، نه ثابت کننده‌ی وضعیت مطلوب است نه غیرِ آن.پی‌نوشت 5: همانطور که میدانید تمام امتیازها (story points)، نسبتی به یک ثابتِ مورد توافق در تیم است. با توجه به اینکه این ثابت در هر تیم میتواند کاملا متفاوت باشد، و همینطور ارزیابی اعضای هر تیمی هم می‌تواند متفاوت‌ باشد، این سنجه کاملا وابسته به همان تیم است.پی‌نوشت 6: در اینجا change هم به نسخه‌ی جدید اشاره می‌کند، هم هر تغییر تنظیماتی در سرور یا بطور کلی در محیط عملیاتی.پی‌نوشت 7: منظور از batch size حجم تغییراتی است که به کُد اعمال می‌شود. فرض کنید یک فیچر به کُد اضافه کردید و می‌خواهید نسخه بزنید، اکنون batch size شما برای این نسخه به اندازه‌ی یک فیچر است. حال فرض کنید ده فیچر به کُد اضافه کرده‌اید و حالا قصد نسخه‌زدن دارید، اکنون حجم تغییرات شما به اندازه‌ی ده فیچر است. مشخصا حجم تغییرات ده فیچر نسبت به یک فیچر بیشتر است، و این بیشتر بودن ریسک شکست شما را افزایش می‌دهد. چرا که نسبت به قبل دست‌کم ده برابر بیشتر احتمالِ خطا دارید.پی‌نوشت 8: دو نکته در اینجا مُستَتَر است: یک. توجه بفرمایید که صرف نسخه‌گذاری به معنای بهبود نیست. مسلما منظور نسخه‌گذاری موفق است. دو. هرچه تلاش شما بر این باشد که حجمِ تغییرات در هر نسخه کم باشد، در بلندمدت تعداد نسخه‌گذاری‌های شما افزایش می‌یابد. فلذا از این جهت «تعدد نسخه‌گذاری» یک پوسته برای «حجمِ کم تغییرات» می‌شود.پی‌نوشت 10: اجتماع انسان‌ها، یک سیستم پیچیده (complex system) است. سیستم‌های پیچیده را براحتی نمی‌توان پیشبینی کرد. در سیستم‌های پیچیده، «نتیجه» می‌تواند کاملا دور از «انتظار» باشد. مثال پرواضح آن بحث فیلترینگ است؛ شبکه‌ی اجتماعی پرطرفداری فیلتر می‌شود تا بازارِ معادلِ بومی آن موفق شود، اما «نتیجه» این می‌شود که افراد بیشتری به فیلترشکن دسترسی پیدا می‌کنند، و نیاز به اپلیکیشن‌های بومیِ دیگر هم کم‌تر می‌شود. در بین معامله‌گرانِ بازارهای «آزاد» مالی، خودِ «بازار» یک سیستمِ پیچیده است، و نمی‌توان رفتار آن را همیشه پیش‌بینی کرد.پی‌نوشت 11: در خیلی از سازمان‌ها (حداقل) دو تیم به ازای هر محصول وجود دارد: تیم توسعه و تیم عملیات. مسئولیت تعریف شده برای تیم توسعه، ساختن اپلیکیشن و براوردن نیازهای مشتری در دلِ اپلیکیشن است و مسئولیت تعریف شده برای تیم عملیات، نصب (دیپلوی) اپلیکیشن در محیط عملیاتی و بالانگهداشتنِ (پایداریِ) آن. این شکل از جداسازی پارادوکس جالبی دارد؛ تیم توسعه برای رسیدن به هدفش، تلاش می‌کند هرچه بیشتر نسخه بدهد، و تیم عملیات برای رسیدن به هدفش، سعی می‌کند در برابر هر تغییر مقاومت کند که از پایداری اپلیکیشن کاسته نشود. ماحصل این تعارضِ منافع، مشکلات بیشماری اعم از فنی و فرهنگی بوجود میاورد. و در نهایت علی‌رغم آنکه همه حولِ یک محصول هستند، با دو تا تیم از هم گسسته و کاملا جدا طرف می‌شویم. از این رو برای بیان این وضعیت از اصطلاحات «سیلو» یا «دیوار اختلافات» استفاده می‌شود.محسن باقریمحسن باقریWed, 26 Jul 2023 14:18:42 +0330