https://virgool.ir/feed/@alishokrollahi78fa2026-11-12 10:48:15https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@alishokrollahi78https://virgool.ir/@alishokrollahi78/هنگامی-که-agile-با-یادگیری-ماشین-ملاقات-میکند-mr1dv2embp9mپنج اصل راهنما برای پیاده سازی سیستم های چابک در محیط های نرم افزاری پروژه محور.توسعه نرم افزار های چابک در حال تبدیل شدن به روال متداول در اکثر سازمان های نرم افزاری است. برای آن دسته از سازمان هایی که به روش های قدیمی(همچون روش آبشاری) عادت کرده اند ، کوچ کردن به روشی مدرن مثل متد چابک ، به معنی کوچ کوچ کردن موفقیت و پیشرفت آنهاست. این تغییر روش هرگز آسان نیست ، اما قدرت و برتری این متد هنگامی مشخص میشود که با در اختیار داشتن بازه ی زمانی ای محدود و منطقی ، میتوانیم محصولاتی داشته باشیم که هر کدام عملکردی شفاف دارند. و همین نتیجه موجب میشود تا Agile همیشه در این جنگ برنده باشد!علاوه بر دشواری های معمول ، که حین ایجاد یک تغییر با آن مواجه هستیم ، پیاده سازی Agile در بستر هایی که متمرکز بر پژوهش هستند(مثل محصولاتی که برپایه ی یادگیری ماشین اند) دشواری های بیشتری دارد.پژوهش ها به هیچ عنوان از میزان اطمینان بالایی برخوردار نیستند. چرا که پژوهش یا تحقیق یعنی پیدا کردن یک دانش جدید و حدس زدن چهره ی دقیق آن ، که در حال حاضر در دسترس نیست ؛ هرچند با منابع و ماخذ محدود و نایاب.علاوه بر این پژوهشگران در دانشگاه تحصیل میکنند و آموزش میبینند ، در حالی که در بسیاری از موارد شخصی برای همکاری و مشارکت با آن ها وجود ندارد.مستندات جامع ، نتیجه ی نهایی کار آن ها است و دقیق ترین تطابق با ابزارها و استاندارد ها را از آن ها میخواهند ، تا نتیجه ی نهایی کار آن ها ، به راحتی با دستاورد های پیشین قابل قیاس باشد.جای تعجب نیست که واژه ی "پژوهش" برای بسیاری از مدیران ترسناک است!آیا روش چابک برای محیط های نرم افزاری پژوهش محور مناسب است؟این سوال توسط بسیاری از سازمان های نرم افزاری پرسیده میشود ، حتی آن دسته که روش Agile را به خوبی در ویژگی های عملکردی خود ، اعمال و اجرا کرده اند. اما بی شک جواب مثبت است! اگرچه محیط های نرم افزاری متمرکز بر پژوهش (پژوهش محور) ویژگی های منحصر بفردی دارند که باید در تمام ابعاد متد چابک ، مورد توجه قرار گیرند.در این مقاله قصد داریم تا پنج ملاحظه کلیدی را که برای پیاده سازی متد Agile در محیط های نرم افزاری پژوهش محور ، باید توجه بیشتری به آن ها داشته باشیم ، ذکر کنیم:۱- "یک یا هیچ" در کار نیست! : در بحث ویژگی های عملکردی ، دو مقوله وجود دارد: صحت و کیفیت مهندسی. اگر ویژگی ها نتواند به درستی و با کیفیت کافی فراهم شوند ، تیم ها معمولا مسیولیت آن ها را بر عهده نمیگیرند. در مقوله ی ویژگی های عملکردی ، "صحت" نیز به خوبی تعریف شده است.باید دقت داشته باشیم که در ویژگی های پژوهش محور ، دانشی که در ابتدا جهت گسترش و توسعه ی ویژگی های جدید ، مورد نیاز است ، در دسترس نیست. و همچنین اغلب تصور دقیقی از خروجی در دست نداریم. در بسیاری از موارد شاید چندین مرحله ی بررسی صحت وجود داشته باشد.به عنوان مثال یک ویژگی تحلیلی را در نظر بگیرید که شامل یک مدل پیش بینی است. بدون مدل ، پیش بینی تصادفی است. با استفاده از مدل "بهینه" ، دقت پیش بینی ممکن است (به عنوان مثال) 95٪ باشد. با این حال ، مفهوم یک مدل مطلوب صرفاً نظری است ، زیرا در واقع ما نمی توانیم صحت یک مدل بهینه را ارزیابی کنیم و رسیدن به این 95٪ به تلاش های زیادی نیاز دارد. با فرض اینکه این مدل با کیفیت مهندسی بالایی پیاده سازی شده است ، سوال درستی همچنان باقی است: آیا ما قبلاً راه حل را کاملاً بهینه کرده ایم یا خیر؟چابک شدن ، نیازمند این است که گاهی ، راه حل های سریعتر را به راه حل های بهینه ترجیح دهیم و از آن ها استفاده کنیم. با داشتن راه حلی که از قبل ، ارزش تجاری قابل توجهی ارائه می دهد ، معمولاً به جای ادامه بهینه سازی ، بهتر است اجرای مدل را شروع کنیم. در واقع ، وظایفی همچون پیش بینی ، یک مثال آسان هستند،بدین معنا که این راه حلها دارای میزان قابل سنجش و محسوسی از صحت اند.اما چگونه الگوریتم هایی را که اشیا را در گروه های متفاوت قرار می دهند یا الگوریتم هایی که به طور خودکار اسناد طولانی را خلاصه می کنند ، اندازه گیری یا مقایسه کنیم؟ حوزه های تحقیقاتی اغلب به مراحل و راه حلهای کوچکی نیاز دارند تا مکرر در حال بهبود باشند. تحقیق ، محصولی است که به طور مداوم تکامل می یابد و یک پروژه یکبار مصرف نیست. دست کشیدن از ارزیابی روند بهینه سازی ، برای محققانی که در آکادمی تحصیل کرده اند ، (جایی که مشارکت کاربر مورد توجه قرار نمی گیرد) ، گاهی اوقات دشوار است و اغلب به تغییرات اساسی نیاز دارد.۲- یک بافر ایجاد کنید تا تأثیرات ناشی از عدم اطمینان را کاهش دهد : در نتایج هر تحقیق علمی مهمی ، عدم اطمینان وجود دارد. درست است که هر برنامه ریزی ای شامل مقداری عدم اطمینان است ، اما در تحقیقات ، سطح این موضوع (یعنی عدم اطمینان) بسیار بالاتر است. این عدم اطمینان بزرگ ، موجب آن میشود که قرار دادن پژوهش های انجام شده راجع به یک ویژگی ، در کنار پیاده سازی های آن ، داخل یک برنامه ی تکرار شونده ، خطرناک باشد. در تحقیقاتمان ، اگر در مسیر ثابت کردن ایده خود ، شکست خوردیم ، اشکالی ندارد! و نتیجه قابل قبولی است ( هرچند شاید امتحان کردن راه و روش های دیگر هم کمکی نکند و با بسیاری از آنها مواجه شویم!). اما شکست در تحویل یک ویژگی ، کمتر مورد قبول است. حساب باز کردن روی مرحله تحقیق ، برای رسیدن به یک راه حل ، بدین منظور که مستقیما آن را پیاده سازی کنید،یعنی اینکه شما چندین بار کارتان را با ناقص گذاشتن ویژگی ، تمام خواهید کرد. در اغلب موارد شما باید بافر کوچکی از ویژگی های پژوهش-گرا را نگهداری کنید ، که در انتظار پیاده سازی هستند. بدون این بافر ، تیم پیاده سازی دچار قحطی در داده هایش میشود و کارایی اش پایین می آید. داشتن یک بافر خیلی بزرگ نیز توصیه نمی شود ، زیرا این امر ارتباط مهم بین تحقیقات و نیازهای مشتری را مختل می کند و تولید را بسیار کند می کند.۳- ساختن تیم های ناهمگن : تنوع و ناهمگنی در بسیاری از موارد پسندیده است. اما متاسفانه ، بسیاری از سازمان ها ، محققان خود را به عنوان مشارکت کنندگانی میپندارند که هرکدام بصورت انفرادی (و مستقل از گروه) قصد اقدام دارند. محققان آدم هایی بسیار باهوش بنظر می آیند ، و در عین حال ناشناخته ؛ همچنین شاید گاهی کار کردن با آنها مشکل بنظر برسد. محققان با مشارکت فردی شان ، بازخورد بسیار کمی از مشتریان ، توسعه دهندگان و صاحبان محصولات دریافت میکنند. جای تعجب نیست که در برخی موارد ، عوامل مستقل (و منفرد) ارتباطات خود را با واقعیت از دست می دهند و ممکن است نتایجی را ارائه دهند که تمام محدودیت های محصول و زیرساخت های آن را در نظر نگیرد. در حالت مشارکت فردی ، مشتریان ، دارندگان محصول و توسعه دهندگان ، بازخورد بسیار کمی از محققان دریافت می کنند و اغلب وسوسه می شوند که فکر کنند تحقیق ، نوعی جادو است! و این نوع نگرش کم اهمیت نیست. با این دیدگاه و شرایط ، محصول با درخواست و انتظارات غیرواقعی همراه است و نمی تواند این درخواست ها را به محققان ارائه دهد ، و توسعه دهندگان نیز نمی توانند زیرساخت ها را برای اجرای ویژگی های جدید آماده کنند. تیم هایی که تحقیق میکنند ، نباید فقط از محققان تشکیل شود. توسعه دهندگانی که ویژگی مورد تحقیق را به کار می بندند و نماینده محصول نیز باید در این تیم باشند. علاوه بر این ، تقسیم دانش ، باید به درستی در میان اعضای تیم صورت بگیرد و مورد تشویق و توجه واقع شود ، زیرا اصلی بسیار مهم است. محققان اغلب افراد بسیار کنجکاوی هستند و ذهن بازی دارند. آنها می توانند در بسیاری از حوزه ها مشارکت داشته باشند ؛ همچنین به اشتراک گذاری دانش کسب و کار، و توسعه با آنها ، یک پیروزی شکوهمند را رقم خواهد زد! کارهای تحقیقاتی اغلب بسیار جالب هستند، و استفاده کردن از آن ها در محصول سازی و توسعه ، یک برد را رقم میزند! زیرا سطح علاقمندی افراد را در کار ، بسیار افزایش میدهد و به همسویی انتظارات کمک میکند.۴- بهبود مستمر (با گذشته نگری) : "گذشته نگری" یکی از قوی ترین جنبه های سیستم های چابک است. اختصاص دادن زمانی برای بحث کردن در مورد نحوه انجام کار ، به جای کار کردن ، و انطباق روش ها با توجه به نیازها و خواسته های تیم ، در نهایت تیم را به سمت هماهنگی و قدرتمندتر شدن سوق می دهد و به سادگی روش های کاری را بهتر می کند. با داشتن تیم های ناهمگن ، یک سیستم چابک پیچیده تر می شود و از درجه ی آزادی بالاتری برخوردار میگردد.اصطلاحات ، شیوه کار ، نتایج و حتی ذهنیت های مختلف اعضای تیم ، باید با احترام و حوصله ، از تمام جهات ، توسط دیگران مورد بحث و یادگیری قرار بگیرد. هرچقدر تیم از تنوع بیشتری برخوردار باشد ، اهمیت بیشتری پیدا میکند که دیدگاهی عمیق ، و بی طرفانه در بحث "گذشته نگری" داشته باشیم.چابک شدن در محیطهای تحقیقاتی فشرده ، زمان بیشتری را به خود اختصاص داده و تکرارها را بهبود می بخشد ، اما از طرفی هم فضای لازم برای گذشته نگری ، سطح رضایت تیم از تغییر ، احتمال یافتن روشی مناسب برای یک پیاده سازی خوب ، و در نهایت موفقیت کلی را ، به خطر می اندازد.۵- همه چیز در مورد تجارت است : متفاوت از تحقیقات بنیادی ، که در آن تنها هدف ، تولید دانش جدید است ، و جایی که درمورد ارزش این دانش جدید ، که گاه غیرقانونی است تعجب میکنیم، در حوزه تجارت ، دانش باید کاربردی و در خدمت اهداف تجاری باشد.اکنون ، هنگام نوشتن این مقاله ، دشوار است که استدلال کنیم هر تحقیق کاربردی ، از یک نیاز تجاری ناشی شده است و به آن پاسخ میدهد.با این وجود ، تلاشهای زیاد و بی دلیلی از سمت سازمانها صورت گرفت و صرف تحقیقات شد.انجام تحقیق ، بدون نیاز شفاف تجاری ، نه تنها یک دستورالعمل تقریباً قطعی برای شکست است ، بلکه چوبی است در چرخهای یک سیستم چابک! بدون نیازهای شفاف تجاری ، هیچ روش روشنی برای تعریف نتیجه وجود ندارد ، هیچ راهی برای تعهد در کار وجود ندارد و بنابراین راهی برای ادامه نیست.بیشترین چیزی که می تواند از چنین تحقیقات غیر کاربردی ای حاصل شود ، یک روشنگری ناگهانی یا شاید اتفاقی است.ali shokrollahiali shokrollahiMon, 28 Dec 2020 10:48:58 +0330