معرفی Application Lifecycle management – ALM – بخش اول

نمودار ساختار چرخه مدیریت تولید نرم افزار

بعضی مواقع وقتی عنوان شغلیم رو برای بعضی از دوستا یا همکارا می گم اولین سوالشون اینه که ALM یا ِDevOps یعنی چی، نکته جالبش اینه که خیلی فرقی نمی کنه اون شخص در زمینه کامپیوتر تحصیل کرده یا نه، که البته طبیعیه چون به مرور انواع تخصص ها در تیم ها داره زیاد میشه و این یک خبر خوبه، به هر حال، تصمیم گرفتم در چند مقاله توضیح بدم که ALM در تئوری و در عمل یعنی چی.( من سعی می کنم خیلی وارد جزئیات نشم )

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

تصویر زیر جنبه های مختلف ALM رو نشون میده.

پروسه ALM

ALM مثل یک چسب نقش های مختلفی رو که به همراه هم برای رسیدن به هدف دارن تلاش می کنن در کنار هم قرار میده، این نقشها شامل و نه محدود به موارد زیر هستن:

  • Stakeholders
  • Business manager
  • Project manager, product owner, or Scrum master
  • Project Management Office (PMO) decision makers
  • Business analyst
  • Architect
  • User experience (UX) design team
  • Database administrators (DBAs)
  • Developers
  • Testers
  • Operations and maintenance staff

تمام تلاش هایی که برای به نتیجه رسیدن پروژه انجام میشه به صورت همکاری گروهی هستن و به این شکل بهترین نتیجه حاصل میشه، علت این تاکید ها روی همکاری اعضا تیم یا همون collaboration اینه که ALM وظیفه اصلیش ایجاد ارتباط مناسب بین افراد تیمه، به همین سادگی ولی همین عدم وجود ارتباط مناسب سرچشمه بسیاری از مشکلاته! که بعضا به دلایل فرهنگی و یا نبود ابزار مناسبه.

 

۴ روش نگاه کردن به ALM

معمولا به ۴ روش به ALM نگاه میشه که البته روش چهارم روش کامل هست و سه مورد دیگه معمولا نگاه سازمان ها به این مساله است.

  • Software development lifecycle – SDLC: این عمومی ترین نگاهه برای اینکه توسعه دهنده ها برای مدت زمان زیادیه که توسعه نرم افزار رو بر عهده دارن و شاید علت دیگه اش فاصله بین تیم های توسعه نرم افزار و تجاری هست.
  • Service management or operations: متاسفانه این بخش همیشه به شکلی کاملا جدا از فرآیند توسعه نرم افزار دیده شده.
  • Application Portfolio Management – APM: این همون بخشی هست که برنامه های تجاری رو ایجاد و مدیریت می کنه که به علت فاصله بخش توسعه نرم افزار و تجاری معمولا در برنامه هاشون فضای زیادی برای تیم نرم افزار در نظر نمی گیرن.

Application Portfolio Management view of alm

  • Unified view: خوشبختانه بعضی سازمان ها روی تمام فرآیند ALM از طریق در نظر گرفتن سه دیدگاه قبلی تمرکز کردن، این تنها راهیه که میشه کنترل رو به دست گرفت. برای یک CIO این مساله خیلی مهمه که همیشه دید جامع رو داشته باشه.

نگاه جامع به پروسه مدیریت تولید اپلیکیشن

سه ستون سنتی ALM

منهای اینکه شما به کدوم یک از چهار روش بالا به ALM نگاه می کنید، ALM دارای ۳ ستون اصلیه که بر اساس اونها بنا نهاده شده.

ستون های ALM

Traceability (قابلیت ردیابی)

تا حالا شده از ایجاد تغییر در بخشی از کد بترسید چون نمی دونید ممکنه چه جاهای دیگه ایی از کد نیاز به تغییر داشته باشه؟ وقتی صحبت از ردیابی میشه یعنی اینکه اگر بخش تجاری بخواد ببینه درخواستی که داشته و باید به نرم افزار اضافه میشده در چه وضعیتیه و چه کارهایی براش انجام شده، افراد مرتبط کارهای انجام شده، باقی مونده، کدهای نوشته شده، تست ها و نتیجه اونها و اینکه اصلا وارد محیط عملیاتی شده و کی؟ این همون Release Note میشه که بعد از هر پابلیش در اختیار عموم قرار می گیره.

 

Automation of High-Level Processes

در هر سازمانی پروسه های نوشته یا نا نوشته وجود داره و ALM نیازداره تا حد ممکن این موارد به شکل خودکار انجام شن تا کارهای تکراری زمان تیم رو به خودشون اختصاص ندن، مثل ربات های خط تولید کارخانه های ماشین سازی. خب نوشتن کد رو که نمیشه اتوماتیک کرد، ولی اجرای تست ها، Build کدها، ایجاد Pakage های نرم افزار و انتقال به محیط های تست رو که میشه اتوماتیک کرد و خیلی موارد دیگه مثل انتقال تغییرات دیتابیس به محیط های مختلف در واقع Continuous Integration  و Continuous Deployment در همین راستا هستن.

 

Visibility into the Progress of Development Efforts

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

 

در  بخش  دوم این نوشته درباره تاریخچه ALM و روند تکامل اون از ALM 1.0  به ALM 2.0  و ALM 2.0+ نگاهی می ندازیم و در بخش سوم هم به شکل عملی به TFS 2017 نگاه می کنیم و موارد تئوری گفته شده رو در عمل بررسی می کنیم، البته در نظر بگیرید که پیاده سازی آخرین استاندارد و حتی استاندارد ۲٫۰ ALM اصلا کار آسونی نیست و هنوز هیچ شرکتی نتونسته حتی تمام جوانب ALM 2.0 رو پوشش بده.

 

 

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *