உங்கள் காலக்கெடுவை சந்திக்கவும்: டெவலப்பர்கள் முயற்சியை மதிப்பிடுவதற்கு பயன்படுத்தும் முறைகள்

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

தவறான மதிப்பீட்டை வழங்கினால் என்ன செய்வது?

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

நேரத்தை மதிப்பிடுவது எப்படி

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

கதை புள்ளிகள் என்ன?

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

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

கதை புள்ளிகளை எப்படி பயன்படுத்தக்கூடாது

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

ஸ்க்ரம் போக்கர் என்றால் என்ன?

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

முடிவுப்புள்ளிகளின் எண்ணிக்கை தெரியவில்லை

எல்லையற்ற நீண்ட பணி

ஓய்வு தேவை

குறைவான பொதுவான மதிப்பீட்டு முறைகள் பயன்படுத்தப்படுகின்றன:

• டி-ஷர்ட் அளவுகள் - எஸ், எம், எல், எக்ஸ்எல்
• நாய் இனங்கள் — சிவாவா, பக், டச்ஷண்ட், புல்டாக், மற்றும் பல (தனிப்பட்ட முறையில், இது முயற்சி மதிப்பீட்டிற்கான வினோதமான அலகு என நினைக்கிறேன் =D)

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

முயற்சியை மதிப்பிடுவதற்கான எடுத்துக்காட்டு

மதிப்பீடுகளுக்கு கதைப் புள்ளிகளை ஒதுக்குவதற்கு உங்கள் குழு பின்வரும் அளவை நிறுவியுள்ளது என்று வைத்துக்கொள்வோம்: ஒவ்வொரு பணிக்கும் ஸ்க்ரம் போக்கர் விளையாடப்படுகிறது, மேலும் நீங்கள் பின்வரும் மதிப்பீட்டை வழங்குகிறீர்கள்:

• நீங்கள் இதற்கு முன் இதுபோன்ற செயல்பாட்டை செயல்படுத்தியதில்லை: +3
• செயல்பாடு சராசரி அளவு: +2
• செயல்படுத்தல் மிகவும் சிக்கலானதாக இருக்கும்: +3
• செயல்பாட்டிற்கான சோதனைகளை எழுதுவது மிகவும் சிக்கலானதாக இருக்கும்: +3

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

• அவர் முன்பு இதேபோன்ற பணியுடன் பணியாற்றியுள்ளார்: +1
• செயல்பாடு சராசரி அளவு: +2
• செயல்படுத்தல் சராசரி சிக்கலானதாக இருக்கும்: +2
• செயல்பாட்டிற்கான சோதனைகளை எழுதுவது சராசரி சிக்கலானதாக இருக்கும்: +2

அவரது இடைநிலை முடிவு 7 கதைப் புள்ளிகள், ஆனால் அந்த எண் ஃபைபோனச்சி தொடரில் இல்லை, எனவே அவர் மிகவும் தோராயமான எண்ணைக் கொண்ட கார்டைச் சமர்ப்பிக்கிறார் - 8. மற்ற குழு உறுப்பினர்களும் தங்களின் அகநிலை பார்வைகளின் அடிப்படையில் தங்கள் மதிப்பீடுகளைச் செய்கிறார்கள். பின்னர் அனைவரும் தங்கள் கார்டுகளைக் காட்டுகிறார்கள், மேலும் உங்கள் சக பணியாளர்கள் அனைவரும் 13 மதிப்பீட்டைக் கொடுத்திருப்பதைக் காணலாம், ஒரு டெவலப்பர் 8 ஐ பரிந்துரைத்ததைத் தவிர. இந்த விஷயத்தில், அவர் தனது குறைந்த மதிப்பீட்டிற்கான காரணங்களைத் தெரிவிக்க அனுமதிக்கப்படுகிறார். அவர் இந்த நியாயத்தை வழங்குகிறார் என்று வைத்துக்கொள்வோம்: அவர் முன்பு அதே பணியில் பணிபுரிந்தார், அது தோன்றும் அளவுக்கு கடினமாக இல்லை. இறுதியில், அவர் மற்ற குழுவினரை 13-ல் இருந்து 8 கதைப் புள்ளிகளுக்கு மாற்றும்படி சமாதானப்படுத்துகிறார், யார் இந்தப் பணியை முடிக்கிறார்களோ அவர்களுக்கு உதவுவதாகக் கூறினார். அல்லது அவர் அதை தானே செய்வார். எந்தவொரு சந்தர்ப்பத்திலும், அது இல்லை மற்றவர்கள் அவருடைய வாதங்களை ஏற்றுக்கொள்கிறார்களா இல்லையா என்பது முக்கியமல்ல, ஏனென்றால் ஒரு வழி அல்லது மற்றொரு பணிக்கு ஒரு மதிப்பீடு ஒதுக்கப்படும், மேலும் குழு அடுத்ததைக் கருத்தில் கொள்ளச் செல்லும். ஆரம்பத்தில், மதிப்பீடுகள் துல்லியமற்றதாக இருக்கும், அடுத்த காலகட்டத்தில் (ஸ்பிரிண்ட்) நீங்கள் செய்யத் திட்டமிடும் வேலையின் அளவின் மதிப்பீடுகள் துல்லியமாக இருக்கும். எல்லாவற்றிற்கும் மேலாக, இந்த மதிப்பீடுகள் மதிப்பீடுகளைப் பயன்படுத்தி செய்யப்பட்டன. சிறிது நேரம் கழித்து, ஒருவேளை மூன்று மாதங்களுக்குப் பிறகு, குழு பணிகளுக்குத் தேவையான நேரத்தை மிகவும் துல்லியமாக மதிப்பிடத் தொடங்கும், மேலும் ஸ்பிரிண்டில் குழு செய்யக்கூடிய சராசரி வேலையின் அளவு தெளிவாகத் தெரியும். ஆனால் இது வேலையின் நோக்கத்திற்கான பொதுவான திட்டத்தை உருவாக்குவதற்கான ஒரு செயல்முறையாகும். இது முக்கியமாக நேரத்தில் கவனம் செலுத்துகிறது, ஆனால் இந்த விஷயத்தில் பல்வேறு தொடர்புடைய காரணிகள் இருக்கலாம். எடுத்துக்காட்டாக, ஒரு டெவலப்பர் இரண்டு வாரங்களுக்கு விடுமுறைக்குச் சென்றார் என்று வைத்துக்கொள்வோம். நீங்கள் ஒரு குறிப்பிட்ட அளவு திட்டமிட்ட வேலைகளை (திட்டமிடப்பட்ட செயல்பாடு) குறைக்க வேண்டும். அல்லது ஒரு புதிய டெவலப்பர் அணியில் சேர்ந்துள்ளார் என்று வைத்துக்கொள்வோம், ஆனால் இன்னும் முழுமையாக வேகமடையவில்லை, எனவே நீங்கள் ஒரு திட்டத்தின் மூலம் அவரது நேரத்தைப் பற்றி அறிந்துகொள்ள அனுமதிக்க வேண்டும்.உள்கட்டமைப்பு செயல்முறை. இது இரண்டு வாரங்களாக இருக்கலாம், திட்டத்தின் சிக்கலைப் பொறுத்து ஒரு வாரம் கொடுக்கலாம் அல்லது எடுத்துக்கொள்ளலாம். இன்னைக்கு அவ்வளவுதான்! மென்பொருள் மேம்பாட்டிற்கு தேவையான தொழில்நுட்பம் அல்லாத அம்சமான முயற்சியின் மதிப்பீட்டில் உங்களின் அறிவை நான் சற்று மேம்படுத்தியிருக்கிறேன் என்று நம்புகிறேன். நீங்கள் இந்தத் தலைப்பிலும், ஸ்க்ரம் பற்றிய விவரங்களிலும் ஆழமாகச் செல்ல விரும்பினால், ஜெஃப் சதர்லேண்டின் "SCRUM" புத்தகத்தைப் படிக்குமாறு நான் கடுமையாக பரிந்துரைக்கிறேன். விளைவுகளைப் பற்றி என்னால் எந்த வாக்குறுதியும் அளிக்க முடியாது, ஏனென்றால் அதைப் படித்த பிறகு நீங்கள் ஸ்க்ரம் மாஸ்டர் ஆக வேண்டும் என்ற எரிச்சலூட்டும் ஆசை =D