மென்பொருள் மேம்பாட்டு முறைகள்

பல நேர்காணல்களில், நீங்கள் வழிமுறைகளைப் பற்றி கேட்கப்படுவீர்கள். இது மிக முக்கியமான அல்லது கடினமான கேள்வி அல்ல, ஆனால் ஒரு ஏமாற்று தாளை வைத்திருப்பது நன்றாக இருக்கும். இந்த கட்டுரையில், வளர்ச்சி முறை என்ன என்பதை வெளிப்படுத்தவும் அவற்றை ஒப்பிடவும் முயற்சிப்போம். மென்பொருள் மேம்பாட்டு முறை என்பது ஒரு குறிப்பிட்ட தயாரிப்பை உருவாக்கப் பயன்படுத்தப்படும் ஒரு செயல்முறையாகும், அதாவது டெவலப்பர்களின் குழுவால் மேம்பாட்டை ஒழுங்கமைப்பதற்கான ஒரு வழியாகும். பல்வேறு வளர்ச்சி மாதிரிகள் உள்ளன, ஒவ்வொன்றும் அதன் சொந்த அணுகுமுறையை வரையறுக்கின்றன. அவர்களில் யாரையும் ஒவ்வொரு திட்டத்திற்கும் பயன்படுத்த வேண்டும் என்று சொல்ல முடியாது. சரியான அணுகுமுறை முற்றிலும் சூழ்நிலையைப் பொறுத்தது. அவற்றில் மூன்றை இன்னும் விரிவாகக் கருத்தில் கொள்ள விரும்புகிறேன்.

அருவி

நீர்வீழ்ச்சி முறையானது பழமையான ஒன்றாகும் மற்றும் கண்டிப்பாக வரிசைப்படுத்தப்பட்ட செயலாக்கத்தை உள்ளடக்கியது: ஒவ்வொரு கட்டமும் அடுத்த கட்டம் தொடங்கும் முன் முடிக்கப்பட வேண்டும். வேறு வார்த்தைகளில் கூறுவதானால், அடுத்த கட்டத்திற்கு மாறுவது என்பது முந்தைய கட்டத்தின் வேலை 100% முடிந்தது என்று அர்த்தம். இது எவ்வாறு செயல்படுகிறது என்பதை படம் காட்டுகிறது: முதலில், நாங்கள் சிக்கலை பகுப்பாய்வு செய்கிறோம் (ஆவணப் பணிகள், சவால்களைப் பற்றி விவாதிக்கவும்), பின்னர் நாங்கள் வடிவமைக்கிறோம் (திட்டத்தின் அமைப்பு இந்த கட்டத்தில் வடிவம் பெறுகிறது), பின்னர் நாங்கள் குறியீடு செய்து சோதிக்கிறோம். முந்தைய நிலைகளுக்குத் திரும்புவது அனுமதிக்கப்படாது. இந்த அணுகுமுறை சிறிய திட்டங்களுக்கு பரிந்துரைக்கப்படுகிறது, அங்கு தேவைகள் முன்கூட்டியே அறியப்படுகின்றன மற்றும் மாற்றப்பட வாய்ப்பில்லை. நன்மைகள்:

• ஒவ்வொரு கட்டத்திலும் முழுமையான மற்றும் நிலையான ஆவணங்கள்
• பயன்படுத்த எளிதாக
• நிலையான தேவைகள்
• பட்ஜெட் மற்றும் காலக்கெடு முன் வரையறுக்கப்பட்டுள்ளது

தீமைகள்:

• ஒரு பெரிய அளவு ஆவணங்கள்
• மிகவும் நெகிழ்வானது அல்ல
• தயாரிப்பின் டெமோ பதிப்பை கிளையன்ட் பார்க்க முடியாது
• பின்னோக்கி நகர்த்த விருப்பம் இல்லை

ஸ்க்ரம்

ஸ்க்ரம் என்பது ஒரு மென்பொருள் மேம்பாட்டு முறை ஆகும், இது முழு செயல்முறையையும் மறு செய்கைகளாக பிரிக்கிறது. ஒவ்வொரு உரையாடலின் முடிவிலும், தயாரிப்பின் டெமோ பதிப்பை வழங்க குழு தயாராக உள்ளது. குழு வளர்ச்சியின் அனைத்து நிலைகளிலும் இணையாக முன்னேறுகிறது என்பதை படம் காட்டுகிறது, இது ஒவ்வொரு மறு செய்கையின் முடிவிலும் திட்டத்தின் ஒரு முடிக்கப்பட்ட பகுதியை சாத்தியமாக்குகிறது. எளிமையான சொற்களைப் பயன்படுத்தி முறையின் சாரத்தை சுருக்கமாக விளக்க முயற்சிப்பேன், ஆனால் நிறைய சொற்கள் உள்ளன. சாராம்சத்தைப் புரிந்துகொள்வதே மிக முக்கியமான விஷயம் என்று நான் நினைக்கிறேன். அனுபவத்துடன் சொற்பொழிவை நினைவில் வைத்திருப்பீர்கள். அனைத்து வளர்ச்சியும் ஸ்பிரிண்ட்களாக பிரிக்கப்பட்டுள்ளது (பெரும்பாலும் 2-3 வாரங்கள்). பாக்கி உள்ளது(பணிகளின் பட்டியல்) முழு வளர்ச்சி காலத்திற்கும் ஒவ்வொரு தனி ஸ்பிரிண்டிற்கும். ஒவ்வொரு பணிக்கும் அதன் சொந்த கதை புள்ளி உள்ளது (கடின மதிப்பீடு). செயல்பாட்டில் ஒவ்வொரு பங்கேற்பாளருக்கும் ஒரு பங்கு உள்ளது:

• ஸ்க்ரம் குழுவில் ஒரு திட்டத்தில் பணிபுரியும் வல்லுநர்கள் (டெவலப்பர்கள், சோதனையாளர்கள், வடிவமைப்பாளர்கள்) உள்ளனர்.
• ஸ்க்ரம் மாஸ்டர் என்பது ஸ்க்ரமின் கொள்கைகள் மதிக்கப்படுவதை உறுதி செய்பவர்.
• தயாரிப்பு உரிமையாளர் வாடிக்கையாளர்.

இந்த முறை தகவல்தொடர்பு சார்ந்தது, எனவே அதிக எண்ணிக்கையிலான கூட்டங்கள் உள்ளன:

• ஸ்டாண்ட்-அப் - இது ஒரு குறுகிய கூட்டம், ஒவ்வொரு நாளும் நடைபெறும், இதில் அனைத்து குழு உறுப்பினர்களும் பங்கேற்கிறார்கள். ஒவ்வொரு பங்கேற்பாளரும் 3 கேள்விகளுக்கு பதிலளிக்கிறார்கள்: நான் என்ன செய்தேன்? நான் என்ன செய்வேன்? மற்றும் என்ன தடை சிக்கல்கள் உள்ளன?
• திட்டமிடல் கூட்டம் - இந்த கூட்டம் ஸ்பிரிண்டின் தொடக்கத்தில் நடைபெறும். அடுத்த ஸ்பிரிண்டில் செய்ய வேண்டிய பணிகள் இந்தக் கூட்டத்தில் அடையாளம் காணப்படுகின்றன.
• பின்னோக்கி - இந்த கூட்டம் ஸ்பிரிண்டின் முடிவில் நடத்தப்படுகிறது மற்றும் அதன் நோக்கம் என்ன சிறப்பாக செய்யப்பட்டது மற்றும் எதை மேம்படுத்தலாம் என்பதைக் கண்டறிவதாகும்.

நன்மைகள்:

• வளர்ச்சி செயல்பாட்டின் போது வாடிக்கையாளர் முடிவுகளைக் காணலாம்
• வளர்ச்சி செயல்முறையின் தினசரி கண்காணிப்பு
• வளர்ச்சியின் போது மாற்றங்களைச் செய்யும் திறன்
• அனைத்து குழு உறுப்பினர்களுடனும் தொடர்புகளை நிறுவியது
• ஒரு சிறிய அளவு ஆவணங்கள்

தீமைகள்:

• வளர்ச்சிக்குத் தேவையான உழைப்பு மற்றும் பிற செலவுகளை மதிப்பிடுவது கடினம்
• வளர்ச்சி தொடங்கும் முன் தடைகளை அடையாளம் காண்பது கடினம்
• மற்ற குழு உறுப்பினர்களின் வேலையில் அனைவரையும் ஈடுபடுத்த வேண்டிய அவசியம்.

கன்பன்

கன்பன் என்பது அணியின் பணிகளை முடிப்பதில் ஏற்பட்ட முன்னேற்றத்தைக் காட்சிப்படுத்துவதை அடிப்படையாகக் கொண்ட ஒரு முறையாகும். தற்போது செய்யப்படும் பணிகளின் எண்ணிக்கையைக் குறைப்பதே முக்கிய யோசனையாகும் ("முன்னேற்றத்தில்" நெடுவரிசையில்). ஸ்க்ரமில், ஸ்பிரிண்ட்களை வெற்றிகரமாக முடிப்பதில் குழு கவனம் செலுத்துகிறது. கான்பனில், பணி முதன்மையான இடத்தைப் பிடித்துள்ளது. பராமரிப்பு நிலையில் உள்ள திட்டங்களுக்கு இது நல்லது, அங்கு அடிப்படை செயல்பாடு ஏற்கனவே செயல்படுத்தப்பட்டுள்ளது, மேலும் குறைந்தபட்ச மேம்பாடுகள் மற்றும் பிழை திருத்தம் ஆகியவை உள்ளன. கான்பனில், பணிகள் தனித்தனியாக ஒதுக்கப்பட்டுள்ளன. ஒரு பணி குழுவில் உள்ள அனைத்து நிலைகளிலும் செல்கிறது, மற்ற பணிகளில் இருந்து சுயாதீனமாக, அது முடிந்தவுடன் வாடிக்கையாளருக்கு காண்பிக்கப்படும். ஒரு கான்பன் போர்டு நெடுவரிசைகளைக் கொண்டுள்ளது, அவை ஒவ்வொன்றும் ஒரு தனி வளர்ச்சி செயல்முறையைக் குறிக்கின்றன. சில நெடுவரிசைகள் (எடுத்துக்காட்டாக, "செயல்படுகிறது" ) அவர்கள் வைத்திருக்கக்கூடிய பணிகளின் எண்ணிக்கையைக் கட்டுப்படுத்துங்கள். பணிகளின் விநியோகத்தில் சிக்கல் பகுதிகளை விரைவாகவும் எளிதாகவும் கண்டறிய இது உதவுகிறது. அத்தகைய பலகையின் உதாரணத்தை படம் காட்டுகிறது. நெடுவரிசைகளின் எண்ணிக்கை மற்றும் அவற்றின் பெயர்கள் மாறுபடலாம். நான் மிகவும் பொதுவானவற்றை முன்வைப்பேன்:

• செய்ய வேண்டியது - செய்ய வேண்டிய பணிகளின் பட்டியல்
• செயல்பாட்டில் உள்ளது - தற்போது பணிபுரியும் பணிகள்
• குறியீடு மதிப்பாய்வு - செய்து முடிக்கப்பட்ட மற்றும் மதிப்பாய்வுக்கு சமர்ப்பிக்கப்பட்ட பணிகள்
• சோதனையில் - சோதனைக்குத் தயாராக உள்ள பணிகள்
• முடிந்தது - முடிக்கப்பட்ட பணிகள்

நன்மைகள்:

• பயன்படுத்த எளிதாக
• தெரிவுநிலை (தடைகளைக் கண்டறிய உதவுகிறது, புரிந்துகொள்ளுதலை எளிதாக்குகிறது)
• செயல்பாட்டில் உயர் குழு ஈடுபாடு
• மிகவும் நெகிழ்வான வளர்ச்சி

தீமைகள்:

• ஒரு நிலையற்ற பணி பட்டியல்
• நீண்ட கால திட்டங்களுக்கு விண்ணப்பிப்பது கடினம்
• கடினமான காலக்கெடு இல்லாதது

மென்பொருள் மேம்பாட்டு முறைகளைப் பற்றிய இறுதி வார்த்தை

மேலாண்மை பதவிகளை வகிக்கும் அல்லது விரும்புபவர்கள் மென்பொருள் மேம்பாட்டு முறைகளை முழுமையாக புரிந்து கொள்ள வேண்டும், ஆனால் ஒவ்வொருவரும் குறைந்தபட்சம் அடிப்படைகளையாவது புரிந்து கொள்ள வேண்டும். முறைகள் வளர்ச்சி செயல்முறையின் ஒருங்கிணைந்த பகுதியாகும், மேலும் அவை தகவல் தொழில்நுட்பத் துறையில் மட்டுமல்ல. எனது கட்டுரையைப் படிக்க நேரம் ஒதுக்கியதற்கு நன்றி. இது உங்களுக்கு உதவியாக இருந்தது என்று நம்புகிறேன். முடிந்தவரை அணுகக்கூடியதாகவும் சுருக்கமாகவும் முக்கிய புள்ளிகளை மட்டுமே விவரிக்க முயற்சித்தேன். இதன் விளைவாக, இந்த கட்டுரை முழுமையானதாக இல்லை. அதைப் பற்றிய உங்கள் கருத்தைக் கேட்டு உங்கள் கேள்விகளுக்குப் பதிலளிப்பதில் மகிழ்ச்சி அடைவேன். வாழ்த்துகள்!