Agile/Scrum பற்றி தொடர் கட்டுரை – 14
நாம் முன்னர் பார்த்தபடி, மென்பொருள் தேவைகள் பட்டியல் ஒரு தகவல் தொடர்பு பிரச்சினை. மென்பொருள் கட்டி வாங்க விரும்புபவர்கள் அதை உருவாக்கத் தெரிந்தவர்களுக்கு தெளிவாகச் சொல்வது அவசியம். இல்லாவிட்டால் பிள்ளையார் பிடிக்கப் போய் குரங்காய் முடிந்தது என்று சொல்கிறார்களே அம்மாதிரி ஆகிவிடும்.
70 – 80 களில் அமெரிக்க வங்கிகளுக்கான கட்டுப்பாடுகள் தளர்த்தப்பட்டன. அவர்கள் மற்ற வங்கிகளுடன் போட்டியில் வெல்ல என்ன செய்யலாம் என்று சிந்திக்கத் தொடங்கினர். இதன் பொருட்டு தங்கள் வாடிக்கையாளர்களிடம் கருத்துக் கணிப்பு செய்யத் தொடங்கினர். இந்த கருத்துக் கணிப்பில் வாடிக்கையாளர்களிடமிருந்து திரும்பத் திரும்ப வந்த பின்னூட்டங்கள் வங்கிகள் அதிக மணி நேரம் திறந்திருக்க வேண்டும் மற்றும் அதிக பணப் பொறுப்பாளர்களை வேலைக்கு அமர்த்த வேண்டும் என்பவையே.
வங்கிகள் இந்த பரிந்துரைகளை அப்படியே செயல்படுத்தியிருந்தால் செலவு எக்கசக்கமாக ஆகியிருக்கும். அவர்கள் அதிகம் செலவு செய்யாமல் எவ்வாறு தீர்வு காண முடியும் என்று கேட்டனர். இதன் விளைவாகத்தான் 60 களிலேயே கண்டுபிடிக்கப்பட்டு ஆனால் சந்தையில் பயன்படுத்தப்படாமல் கிடந்த ஏடிஎம் (ATM) கருவி பரவலாக நிறுவப்பட்டது.
மேற்கண்ட கதையின் உட்கருத்து என்னவென்றால் தேவைகள் பட்டியல் பயனர் கண்ணோட்டத்தில் இருந்து எழுதப்பட வேண்டும். மற்றும் பயனர்களுக்கு “என்ன” தேவை என்பது மட்டுமல்லாமல் “ஏன்” அது தேவை என்பதையும் தெளிவாக்குவது அவசியம். ஆனால் “எப்படி” செயல்படுத்துவது என்பதுபற்றி எதுவும் இருக்கக் கூடாது. புதுமையான வழிகளில் பயனர் இலக்குகளை அடைவதற்கு உருவாக்குநர்களுக்கு இணங்கு தன்மை வேண்டும்.
அருவி செயல்பாட்டில் நன்கு எழுதப்பட்ட தேவைகள் பட்டியல்கள் “எப்படி” என்பதைத் தவிர்த்து “என்ன” என்பதில் கவனம் வைப்பது உண்டு. ஆனால் “ஏன்” அது தேவை என்பதை ஒவ்வொரு தேவையிலும் விளக்குவது அரிதே. தகவெளிமை (Agile) / மொய்திரள் (Scrum) செயல்முறைகளில் தேவைகள் பட்டியலை பயனர் கதைகள் என்று கூறுகிறோம். பயனர் கதைகளை “இன்ன பயனர் வகையாகிய நான் இன்ன காரணங்களால் இன்ன இலக்கை அடைய வேண்டும்.” என்ற வடிவில் எழுதுவது பரிந்துரைக்கப்படுகிறது.
ஒரு குறுவோட்டம் முடியும் தருவாயில் மொய்திரள் குழுவினர் அடுத்த குறுவோட்டத்துக்கு கிடக்கும் பணிகளைத் தெளிவாக்குவதற்காக கூடிப்பேச வேண்டும். இக்கூட்டத்தில் குழு மற்றும் தயாரிப்பு உரிமையாளர் கிடக்கும் பணிகள் பட்டியலில் மேல் வரிசையில் உள்ள பணிகளைப்பற்றி கலந்தாய்வு செய்ய வேண்டும். திட்டமிடும் போது எழும் கேள்விகளை முன்னரே கேட்க குழுவினருக்கு இது ஒரு நல்ல வாய்ப்பு. இந்த கேள்விகளை முன்னரே கேட்பதன் மூலம் உடனடியாக பதில் இல்லை என்றால் தயாரிப்பு உரிமையாளர் திட்டமிடுவதற்கு முன்னால் அவற்றை சேகரிக்க இயலும்.
ஒரு பயனர் கதைக்கு பல லட்சணங்கள் உள்ளன. அவற்றில் முக்கியமான சில: ஒவ்வொரு கதையும் மென்பொருளின் பயனருக்கு மதிப்புள்ள பயனை வழங்க வேண்டும். அதிகபட்சம் ஒரு குறுவோட்டத்தில் முடிக்கும் அளவுக்கு சிறிதாக இருக்க வேண்டும். முடிந்தால் அதை விட சிறியதாக இருப்பதே மேல். பல கதைகளை உள்ளடக்கிய பெரிய தேவைகளை காப்பியம் என்று கூறுகிறோம். அத்தகைய காப்பியங்களை உடைத்து சமாளிக்கக்கூடிய அளவில் கதைகளாக எழுத வேண்டும். பயனர் கதை அல்லது அதன் தொடர்புடைய விளக்கம் அதை சோதனை செய்யத் தேவையான தகவல்களை வழங்க வேண்டும். இவற்றை ஏற்றுக் கொள்வதற்கான நிபந்தனைகள் என்று தனியாக பயனர் கதையில் எழுதுவது வழக்கம். ஏற்றுக் கொள்வதற்கான நிபந்தனைகள் அளவிட சாத்தியமாக இருப்பது நல்லது. எதிர்பார்த்தபடி செயல்படுகிறதா என்று தீர்மானிக்க ஒரு சாத்தியமான வழி இருந்தால் அதை சோதனை செய்யக்கூடியது என்று கூறலாம்.
அருவி செயல்முறையில் தேவைகள் பட்டியல் பங்குதாரர்கள் மற்றும் உருவாக்குநர் குழு இடையே உள்ள ஒப்பந்தம் ஆகும். மாறாக மொய்திரளில் இவ்வாறு எழுதிய கதைகள் தயாரிப்பு உரிமையாளர் மற்றும் உருவாக்குநர் குழு இடையே ஒரு விரிவான உரையாடலை ஆரம்பிக்கும் வழி என்றே கருதப்படுகின்றன. கூடுதல் விளக்கங்கள் தயாரிப்பு உரிமையாளரால் உரையாடல்களில் வழங்கப்படும்.
கிடக்கும் பணித்தொகுதிகளில் அம்சங்கள் மற்றும் கதைகளை சேர்ப்பதற்கு தயாரிப்பு உரிமையாளர்தான் பொறுப்பு. ஆனால் உருவாக்குநர் குழு தயாரிப்பு உரிமையாளருடன் கூடி வேலை செய்ய வேண்டும். குறைந்தபட்சம் அடுத்த குறுவோட்டத்துக்கான கதைகளை உடனடியாக நடவடிக்கை எடுக்கக்கூடிய வடிவத்தில் கொண்டு வர வேண்டும். மேலும் தயாரிப்பு உரிமையாளர், குறுவோட்டம் தொடங்கும் வரை பயனர் கதைகளில் தேவைப்பட்ட மாற்றங்களை செய்யலாம். எடுத்துக்காட்டாக உருவாக்குநர் குழு ஒரு கதைக்கு அதிக முயற்சி எடுக்குமென்று மதிப்பீடு செய்தால் தயாரிப்பு உரிமையாளர் அந்தக்கதையில் சில அம்சங்களை குறைக்கலாம் அல்லது அந்தக்கதையையே கிடக்கும் பணிகள் பட்டியலில் கீழே நகர்த்தி விடலாம்.
பாதுகாப்பு போன்ற பொதுவான தேவைகளை செயல்பாடு அல்லாத தேவைகள் (non-functional requirements) என்று கூறுகிறோம். இவற்றை ஒவ்வொரு பயனர் கதையிலும் எழுதத்தேவையில்லை. இவற்றை பொதுவாக ஏற்றுக்கொள்ளப்பட்ட வரையறையில் (definition of done) ஒரு பகுதியாக சேர்த்துவிடுவோம். பொதுவாக ஏற்றுக்கொள்ளப்பட்ட வரையறை பற்றி நாம் பின்னர் வரும் கட்டுரையில் விரிவாகப் பார்ப்போம்.