Agile/Scrum பற்றி தொடர் கட்டுரை – 15
மொய்திரள் (Scrum) செயல்முறையின் சக படைப்பாளரான ஜெஃப் சதர்லேண்ட் (Jeff Sutherland) கூறுகிறார், “நான் OpenView Venture Partners கூட வேலை செய்த பொழுது அவர்கள் எந்த ஒரு இயக்குநர் குழுமம் கூட்டத்திலும் சரியான கான்ட் விளக்கப்படம் பார்த்ததில்லை என்று கூறுவர். தங்கள் அணிகளின் உற்பத்தி திசைவேகம் என்ன என்றே தெரியாமல் இன்ன தேதியில் வெளியீடு செய்ய முடியும் என்று வாக்குறுதி அளிப்பதுதான் இத்திட்டங்களின் தோல்விக்கு மூல காரணம். மொய்திரள் செயல்படுத்துவதற்கு முன் இருந்த நிலை இது.”
நாம் அணியின் திசைவேகம் மதிப்பிட இரண்டு முக்கியமான காரணங்கள் உள்ளன:
-
ஒன்று – நாம் முன்னர் பார்த்தபடி வெளியீட்டுத் தேதிக்கு தயாரிப்பு உரிமையாளர்தான் பொறுப்பு. கிடக்கும் பணிகளின் மதிப்பீடும், அணியின் திசைவேகமும் தெரிந்தால்தான் தயாரிப்பு உரிமையாளர் சாத்தியமான வெளியீட்டுத் தேதி முடிவு செய்ய இயலும்.
-
இரண்டு – நாம் மென்பொருள் உருவாக்கும் வழிமுறை மேம்பாடு செய்தபின் திசைவேகம் அதிகரித்ததா இல்லை குறைந்ததா என்பதை அளவிட இயல வேண்டும். அணியின் திசைவேகம் தெரியாது என்றால் மேம்பாடுகள் வேலை செய்ததா என்பதைத் தெரிந்து கொள்வது மிகக் கடினம்.
எப்படி மொய்திரள் இம்மாதிரி பிரச்சினைகளைத் தாண்டி சாத்தியமான வெளியீட்டுத் திட்டங்களைத் தயாரிக்க உதவுகிறது? வேலை உள்ளடக்கத்தை அளவிட பயன்படுத்தப்படும் அலகு எது? அது எப்படி பிற முறைகளில் உள்ள குறைபாடுகளை நிவர்த்தி செய்கிறது? நாம் இத்தகைய கேள்விகளுக்கு பதிலளிக்க இங்கு முயற்சி செய்வோம்.
ஒரு பயனர் கதையை செய்து முடிக்க எத்தனை மணி நேரம் எடுக்கும் என்று மதிப்பீடு செய்வதில் கீழ்க்கண்ட பிரச்சினைகள் உள்ளன:
-
ஆராய்ச்சிகளின்படி மணி நேரத்தை மதிப்பீடு செய்வது நமக்கு இயல்பாகவே கடினம் என்று தெரிகிறது. நாம் ஒரு வேலைக்கு எவ்வளவு நேரம் எடுக்கும் என்று மதிப்பிடும்போது 400% வரை பிழை வரலாம். நேரடி மதிப்பீட்டை விட ஒப்பிடும் மதிப்பீடே எளிதானது. ஒன்று மற்றொன்றை விட பெரியது அல்லது சிறியது என்று ஓரளவு துல்லியமாக நம்மால் சொல்ல இயலும்.
-
ஒரு குழுவில் எல்லோருக்கும் நிரலாக்கத்தில் அதே அளவு திறமை இருக்காது. ஆகவே ஒருவேலைக்கு எத்தனை மணி நேரம் எடுக்கும் என்பதில் முடிவற்ற வாக்குவாதங்கள் எழக்கூடும்.
-
மணி நேரம் போன்ற அளவீடுகளைத் தவறாகப் புரிந்துகொள்ள வாய்ப்புகள் அதிகம். எடுத்துக்காட்டாக, செய்த மணி நேரத்தை மதிப்பீட்டு மணி நேரத்துடன் ஒப்பிட்டு சில மேலாளர்கள் பகுப்பாய்வு செய்கிறார்கள். இதன் மூலம் இன்னார் நன்றாக வேலை செய்கிறார்கள், இன்னார் நன்றாக வேலை செய்யவில்லை என்ற முடிவுக்கு வருகிறார்கள். இது சரியல்ல. ஏனெனில் நாம் முன்னர் பார்த்தபடி மென்பொருள் வேலையில் தேவைகள் மாறக்கூடியவை, மற்றும் தொழில்நுட்பம் நிச்சயமற்றது.
மேற்கண்ட குறைபாடுகளை நிவர்த்தி செய்வதற்காக ஜெஃப் சதர்லேண்ட் (Jeff Sutherland) கதைப் புள்ளிகள் (Story points) என்ற புதிய அலகை அறிமுகம் செய்துவைத்தார். கதைப் புள்ளிகள் பற்றிய முக்கிய அம்சங்கள்;
-
இவை ஒப்புநோக்கு மதிப்பீடுகள். முன்னால் செய்த கதைகளுடன் ஒப்பிட்டு புதிய கதைகளை மதிப்பீடு செய்ய வேண்டும்.
-
ஒரு அணியின் மதிப்பீட்டை மற்றொரு அணியின் மதிப்பீட்டுடன் ஒப்பிட இயலாது.
-
ஒரு கதைப் புள்ளிக்கு ஒரு அணி சராசரியாக எவ்வளவு நேரம் எடுக்கும் என்று நிச்சயமாகக் கணக்கிட முடியும். எனினும் ஒரு குறிப்பிட்ட கதையை முடிக்க இவ்வளவு நேரம்தான் எடுக்கும் என்று எவரும் சொல்ல இயலாது.
-
இரண்டு புள்ளிகள் என்று நாம் மதிப்பீடு செய்த ஒரு கதைக்கு ஒரு புள்ளி என்று மதிப்பீடு செய்த இன்னொரு கதை அளவே நேரம் எடுக்கலாம். அல்லது அதற்கு மூன்று புள்ளி என்று மதிப்பீடு செய்த மற்றொரு கதை அளவு நேரமும் எடுக்கலாம். எனினும், எல்லாவற்றையும் ஒன்று சேர்த்துப் பார்க்கும்போது இந்த தனிப்பட்ட ஏற்ற இறக்கங்கள் ஒன்றுக்கொன்று ரத்து ஆகி விடும். எனவே நீண்ட கால அடிப்படையில் கதைப் புள்ளிகளை அணியின் திசைவேகம் அளவிட பயன்படுத்தலாம்
எனினும் கதைப் புள்ளிகளில் ஒரு குறைபாடு இருக்கத்தான் செய்கிறது. நாம் இந்தத் தொடரில் முன்னர் பார்த்தபடி சதுர அடியில் கட்டிடத்தின் பரப்பளவு போன்ற வெளியீட்டை அளவிடும் அலகே சிறந்தது. ஆனால் கதைப் புள்ளிகள் எனும் இந்த அலகு எவ்வளவு வேலை உள்ளீடு செய்கிறோம் எனபதற்கான அலகு.
எப்பொழுது இந்த மதிப்பீடு செய்வது? ஒரு குறுவோட்டம் முடியும் தருவாயில் கிடக்கும் பணிகளைத் தெளிவாக்குவதற்காக கூடிப்பேச வேண்டும் என்று நாம் முன்னர் பார்த்தோம். இக்கூட்டத்தில் மதிப்பீடு செய்வது ஒரு முக்கிய வேலை.
யார் மதிப்பீடு செய்ய வேண்டும்? இந்த வேலையை யார் செய்யப் போகிறார்களோ அவர்கள்தான் மதிப்பீடு செய்யவேண்டும். அதாவது உருவாக்குனர்கள் குழு. அனைவரும் பங்கு பெற வேண்டிய அவசியம் இல்லை. சிலருக்கு முடிக்க வேண்டிய வேலை இருந்தால் மற்றவர்கள் பங்கு பெறலாம்.
எப்படி செய்ய வேண்டும்? இதற்கு பரிந்துரைக்கப்படும் முக்கியமான செயல்முறை மதிப்பீடு சீட்டாட்டம் (Planning Poker). இந்த செயல்முறையின் முக்கிய அம்சம் அணி முன்னர் செய்த வேலைகளுடன் ஒப்பீடு செய்து ஒருமித்த கருத்தால் மதிப்பிட வேண்டும்.
குறிப்பு: நாம் “பயனர் கதை’ (user story) அல்லது ‘கதை’ என்று சொல்வதை தயாரிப்புக்கான கிடக்கும் பணிகளில் ஒன்று (Product Backlog Item or PBI) என்றே மொய்திரள் கையேடு குறிப்பிடுகிறது. கதை என்பது அதீத நிரலாக்கத்தில் (Extreme Programming or XP) ஆக்கிய சொல். படிக்கவும், விவாதிக்கவும் எளிதாக இருக்கும் என்பதால் இதையே இக்கட்டுரைத் தொடரில் பயன்படுத்துகிறோம்.
உங்கள் தகவெளிமை (Agile) / மொய்திரள் (Scrum) பயணம் வெற்றியடையட்டும்!
– முற்றும்