அண்மைக்காலங்களில் பல மென்பொருள் நிறுவனங்கள் தகவெளிமை முறைக்கு மாறியிருக்கின்றன. ஏன் இந்த மாற்றம்? அப்படி என்ன இருக்கிறது இந்த முறையில்? இதைப் பற்றி விரிவாகத் தெரிந்து கொள்ள வேண்டுமே என்று நினைப்பவர்கள் கணியத்தில் திரு. அசோகன் அவர்கள் எழுதியுள்ள “எளிய தமிழில் Agile/Scrum” மின் நூலில் படித்துத் தெரிந்து கொள்ளலாம். விரிவாகத் தெரிவதற்கு முன்னர், தகவெளிமை(Agile) பற்றிய ஓர் அறிமுகமாவது வேண்டாமா? என்று கேட்பவரா நீங்கள்? அப்படியானால் உங்களுக்கானது தான் இந்தப் பதிவு!
இதற்கு முன்பு நாம் பார்த்த சீர்வடிவங்கள் இரண்டும் நீண்ட காலத் திட்டப்பணிகளுக்கு ஏற்றவை. நீண்ட காலம் என்று இங்கு சொல்லப்படுவது மாதக்கணக்கிலோ ஓரிரண்டு ஆண்டுகளிலோ செய்து முடிக்கப்படும் திட்டப்பணிகள். ஆனால் கொஞ்சம் யோசித்துப் பாருங்கள் – இன்றைய காலத்தில் அலைபேசி செயலி ஒன்றைச் செய்து முடிப்பதற்கோ ஓர் இணையத்தளத்தை வடிவமைப்பதற்கோ ஆண்டுக்கணக்கில் நேரம் எடுக்க மாட்டார்கள் அல்லவா? ஓரிரு வாரங்கள், கூடிப்போனால் ஒரு மாதத்தில் முடித்து விடுவார்கள். 2,3 வாரங்களில் உருவாக்கப் போகும் ஒரு மென்பொருளுக்குப் பல நாட்கள் வாடிக்கையாளரிடம் பேசித் தேவைகளைப் பக்கம் பக்கமாகக் கட்டுரை எழுத வேண்டிய தேவை இருக்காது தானே!
இதையெல்லாம் செய்வது தான் தகவெளிமை(Agile) முறை! தகவெளிமை முறையில் ஆவணமாக்கல் என்று ஒன்று பெரிதாகக் கிடையாது. தேவை ஏற்படும் போதெல்லாம் வாடிக்கையாளரிடம் பேசுவார்கள். அவர் சொல்வதைக் குறித்து வைத்துக் கொள்வார்கள். அந்தக் குறிப்புகளுக்குத் தான் “காப்பியம்“(epic) என்று பெயர். காப்பியம் என்றால் தான் நமக்குத் தெரியுமே! இராமாயணம், மகாபாரதம் ஆகியன காப்பியங்கள்! காப்பியங்கள் என்றாலே அதில் இருக்கும் ஒவ்வொரு கதை மாந்தருக்கும் ஓர் உள் கதை பிரிந்து போகும் அல்லவா! அதே தான் இங்கேயும்!
ஒவ்வொரு காப்பியத்தையும் நிரலர் அணி உட்கார்ந்து ஆராயும். ஆராய்ந்து பயனர் என்னென்னவெல்லாம் கேட்டிருக்கிறார் என்று ஒரு பட்டியலை உருவாக்கும். பயனர்க்குத் தேவைப்படும் அந்தக் கதைகளுக்குப் பயனர் கதைகள்(User Stories) என்று பெயர். அதாவது, ஒவ்வொரு காப்பியமும் பயனரின் பல கதைகளை(தேவைகளை)க் கொண்டிருக்கும்.
பல கதைகளா? அப்படியானால் ஒவ்வொரு கதைக்கும் நிறைய வேலைகள் செய்ய வேண்டியிருக்குமே! எந்த அடிப்படையில் – எந்த வேலையை எப்போது முடிப்பது என்று முடிவு செய்வார்கள் என்கிறீர்களா? கவலையை விடுங்கள். அதை வாடிக்கையாளரிடமே கேட்டு விடலாமே!
“நாங்கள் இந்தத் திட்டப்பணியை ஆறு வாரத்தில் முடிக்கத் திட்டமிட்டிருக்கிறோம். முதல் இரண்டு வாரங்களில் மென்பொருளின் குறிப்பிட்ட சில பகுதிகளை முடித்து நீங்கள் அப்படியே பயன்படுத்தும் வகையில் (Shippable Product) கொடுத்து விடுகிறோம். எந்தெந்தப் பகுதிகளை முடிக்க வேண்டும் என்று சொல்லுங்கள்.” என்று வாடிக்கையாளரிடமே கேட்டு விடுவார்கள். வாடிக்கையாளரை “மென்பொருள் உரிமையாளர்” (Product Owner) என்று சொல்வார்கள்.
இப்படி மென்பொருள் உருவாக்கத்தை இரண்டு இரண்டு வாரங்களாகப் பிரித்து, ஒவ்வோர் இரு வாரத்திலும் பயன்படும் வகையிலான ஒரு மென்பொருளை(Shippable product) வாடிக்கையாளருக்குக் கொடுத்து விடுவார்கள். சில நிறுவனங்கள் இரண்டு வாரங்களாகப் பிரிப்பதற்குப் பதிலாக, ஒரு வாரம், மூன்று வாரம், 4 வாரம் என அவர்கள் வசதிக்கேற்ப பிரித்துக் கொள்வார்கள். மென்பொருள் உருவாக்க நேரத்தில் இந்தப் பிரிப்புக்குச் சிற்றோட்டம்(Sprint) அல்லது குறுவோட்டம் என்று பெயர். (பொதுவாக, வேகமாகப் பாய்ந்து செல்லும் கார் பந்தயங்களில் ஒரு சுற்று முடிப்பதை sprint என்று சொல்வார்கள்.) ஒவ்வொரு சிற்றோட்டத்திலும் ஒரு காப்பியத்தின் சில பல கதைகளை ஓடி முடித்திருக்க வேண்டும்.
எல்லாம் சரி! இந்தக் கதைகளை முடிக்க எவ்வளவு நேரம் ஆகும் என்று யார் முடிவு செய்வார்கள்? முந்தைய அருவி முறை, வி முறை ஆகியவற்றில் திட்டமிடல் என்று தனியே ஒரு படி இருந்தது. இங்கு நீங்கள் அதைப் பற்றிப் பேசவே இல்லையே! என்று கேட்டால் அது நியாயமான கேள்வி தானே!
முந்தைய முறைகளைக் காட்டிலும் தகவெளிமை(Agile) முறை முற்றிலும் மாறுவது இந்த இடத்தில் தான்! முந்தைய முறைகளில் ஒவ்வொரு நிரலரும் எவ்வளவு நேரத்தில் முடிக்க வேண்டும் என்பதை அணித்தலைவர் முடிவெடுப்பார். ஆனால், தகவெளிமை(Agile) முறையில் அப்படி இல்லை! ஒவ்வொருவரும் எவ்வளவு நேரத்தில் முடிப்பார்கள் என்பதை அவரவரே தீர்மானிப்பார்கள். ஆ! இதென்ன புதுமை! அப்படியானால், ஒரு வேலையை முடிக்க எவ்வளவு நேரம் வேண்டுமானாலும் எடுத்துக் கொள்ளலாமா – என்றால் இல்லை.
ஒருங்கிணைப்பாளர் (Scrum Master):
தகவெளிமை(Agile) முறையில் ஏழில் இருந்து ஒன்பது பேர் வரை கொண்ட அணிகளைப் பிரிப்பார்கள். இந்த அணிக்கு மொய்திரள்(Scrum) அணி(team) என்று பெயர். ஒவ்வோர் அணியிலும் ஓர் ஒருங்கிணைப்பாளர் (Scrum Master) இருப்பார். தகவெளிமை(Agile)யில் உள்ள இன்னொரு சிறப்பு இந்த ஒருங்கிணைப்பாளர் (Scrum Master) தாம்! வயதில் மூத்தவரோ, வேலையில் மூத்தவரோ தான் ஒருங்கிணைப்பாளர் (Scrum Master) ஆக இருக்க வேண்டும் என்று எந்தக் கட்டாயமும் கிடையாது. ஒருங்கிணைப்பதில் ஆர்வம் உள்ள யார் வேண்டுமானாலும் ஒருங்கிணைப்பாளராக (Scrum Master) ஆகலாம். சில திட்டப்பணிகளில் அணியில் உள்ள எல்லோருக்கும் ஒருங்கிணைப்பாளர் (Scrum Master) வேலை தெரிய வேண்டும் என்பதற்காக – ஒவ்வொரு சிற்றோட்டத்திற்கும்(Sprint) ஒருங்கிணைப்பாளர் (Scrum Master) மாறுவது போல் அமைத்துக் கொள்வார்கள். தேவைப்பட்டால் இப்படிக் கூட அமைத்துக் கொள்ளலாம். இந்த ஒருங்கிணைப்பாளரின்(Scrum Master) வேலைகள் தாம் என்னென்ன?
1) மொத்தத் திட்டப்பணிக்கான திட்டமிடல் கூட்டங்கள் நடத்துவது (Project Planning Meeting)
2) ஒவ்வொரு சிற்றோட்டத்திற்கும்(Sprint) திட்டமிடல் கூட்டங்கள் நடத்துவது (Sprint Planning Meeting)
இந்தக் கூட்டங்களில் தாம், காப்பியங்களில்(Epic) உள்ள கதைகள்(User Stories) பற்றிப் பேசுவார்கள். ஒவ்வொரு கதையையும் முடிக்க எவ்வளவு நேரம் ஆகும் என்பதை எல்லா நிரலர்களிடமும் கேட்பார்கள். இப்படிக் கேட்கும் போது ஒவ்வொரு நிரலர் கையிலும்
அ. 1,2,3,5,8,13,21 என்று பைபோனாச்சி எண்கள் அச்சிடப்பட்ட அட்டைகள்
ஆ. மிகச் சிறியது, சிறியது, நடுத்தரம், பெரியது, மிகப்பெரியது என்பன போன்ற (சட்டைக்கான அளவுகோல் போல) அச்சிடப்பட்ட அட்டைகள்
போன்றவற்றைக் கொடுத்திருப்பார்கள். ஒவ்வொரு கதையையும் பேசி முடித்த பின்னர், அந்தக் கதையை முடிக்க எவ்வளவு உழைப்புத் தேவை என்பதற்கேற்ப ஒவ்வொருவரும் தங்கள் கைகளில் உள்ள அட்டைகளைக் காண்பிக்க வேண்டும். ஒருங்கிணைப்பாளர் ஒவ்வொருவரிடமும் “நீங்கள் ஏன் இந்த எண்ணைச் சொல்கிறீர்கள்? விளக்குங்கள்” என்று காரணம் கேட்பார். அவர்கள் சொல்லும் காரணத்தின் மேல் கலந்துரையாடல் நடக்கும். கலந்துரையாடலின் இறுதியில் மொய்திரள்(Scrum) அணி(Team) அனைவரும் (மிகச் சில நேரங்களில் பெரும்பாலானோர்) ஒத்துக்கொள்ளும் முடிவை ஏற்றுக்கொள்ளும். இப்படித்தான் திட்டமிடல் இங்கு நடக்கும். இது தகவெளிமை(Agile)யின் சிறப்புகளுள் ஒன்றாகும். நம்முடைய வேலைக்கான திட்டமிடலை நாமே உருவாக்குவது!
3) இந்தத் திட்டமிடல் வழி அணி இயங்குகிறதா என்பதை யார் கண்காணிப்பது? வேறொருவர், நிரலர்களைக் கூப்பிட்டு வேலையைக் கொடுத்தால் தானே கண்காணிக்க வேண்டும்? இங்கு திட்டமிடுவதும் நிரலர்கள் தாம்! யார் யார் எந்தெந்த வேலையைச் செய்வது என்று பிரித்துக் கொள்வதும் அவர்கள் தாம்! எனவே, இங்கு பகிரப்படுவது வேலை இல்லை, பொறுப்பு! அவரவர் தத்தமக்கு விரும்பிய வேலைகளை எடுத்துக் கொள்கிறார்கள். கடினமான வேலையை ஒருவர் எடுத்தால், பிற உறுப்பினர்கள் தத்தம் பொறுப்புகளை முடித்த பிறகு அவருக்கு உதவுவார்கள். அப்படியானால், யார் கடினமான பொறுப்புகளுடன் இருக்கிறார்கள், யார் எளிமையாகப் பொறுப்புகளை முடித்து விட்டார்கள் என்று மொத்த மொய்திரள்(Scrum) அணிக்கும் தெரிய வேண்டும் அல்லவா? இதற்காக ஒவ்வொரு நாளும் 10 அல்லது 15 மணித்துளிகள் அணிக்கூட்டம் போடுவார்கள். இந்தக் கூட்டத்திற்கு தினசரி கூட்டம்(Daily Standup meeting) என்று பெயர்.
இந்தக் கூட்டத்தில் மூன்றே மூன்று கேள்விகளை மட்டும் தான் எடுத்துக் கொள்வார்கள்.
- நேற்று நான் என்ன செய்தேன்?
- இன்று என்னுடைய திட்டம் என்ன?
- என்னுடைய வேலையில் ஏதேனும் தடங்கல் இருக்கிறதா?
இந்த மூன்று கேள்விகளைத் தவிர, வேறு கேள்விகளைப் பேசக் கூடாது.
4. ஒவ்வொரு சிற்றோட்டத்தின்(Sprint) இறுதியிலும் பயன்படு மென்பொருளை(Shippable Product)ப் பயனரிடம் காண்பிக்க வேண்டும் அல்லவா? அதற்கான முன்னோட்டக் கூட்டத்தை(Demo Meeting)க் கூட்டுவது!
5. பலர் சேர்ந்து பணியாற்றும் இடம் என்றால் அரசல் புரசல்களுக்கு இடம் இல்லாமலா? அரசல் புரசல்களுடன் பாராட்டுகளுக்கும் இடம் இருக்கும் அல்லவா? சிக்கல்களைக் கூடிய வரை சீக்கிரம் தீர்க்க வேண்டும் என்று (Early Testing) என்று மென்பொருள் சோதனை நெறிமுறை சொல்கிறது. அதை மென்பொறியாளர்களே தம்முடைய வாழ்க்கையில் செயல்படுத்தாவிட்டால் எப்படி? – செயல்படுத்த வேண்டும் அல்லவா? அதற்காகத் தான், இப்படிப்பட்ட அரசல், புரசல்கள் என்னென்ன, பாராட்டுகள் என்னென்ன என்பதை அணியோடு உட்கார்ந்து பேச, ஒவ்வொரு சிற்றோட்டத்தின் முடிவிலும் குறைநிறை கூட்டம்(Retrospective meeting) நடத்தப்படும்.
தகவெளிமை(Agile) முறையில் இப்படிப் பல கூட்டங்கள் இருப்பதால், நாள் திட்டமிடலையே எட்டு மணிநேரத்திற்குப் பதிலாக, ஆறு மணிநேரத்திற்குத் தான் வைத்திருப்பார்கள். ஏனென்றால், தினசரி கூட்டத்தைத் தவிர மீதி எல்லாக் கூட்டங்களுமே ஒரு மணி நேரமோ இரண்டு மணி நேரமோ நடக்கும்.
எங்கு பயன்படும்?
குறுகிய காலத் திட்டப்பணிகளுக்குப் பயன்படும். அவ்வப்போது வாடிக்கையாளருக்குப் பயன்படு மென்பொருளை(Shippable Product) அனுப்புவதால் வாடிக்கையாளரின் எண்ணவோட்டங்கள், கருத்துகளை உடனுக்குடன் அறிந்துகொள்ளலாம். அதற்கேற்ப மாற்றங்களை அடுத்த குறுவோட்டத்திலேயே(Sprint) செய்தும் கொள்ளலாம்.
சிக்கல்கள்:
தகவெளிமையின்(Agile) மிகப் பெரிய சிக்கல் – முறையான ஆவணங்கள் இல்லாதது. இன்னொரு மிகப்பெரிய சிக்கல் – குறுகிய காலத் திட்டப்பணிகள் என்பதால் பெரும்பாலான இடங்களில் டெஸ்டருக்குப் பதிலாக, நிரலரையே(Developer) மாற்றி மாற்றிச் சோதிக்கச் சொல்கிறார்கள். அறிவியல் அடிப்படையில் ஒரு நிரலரே டெஸ்டராக மாறுவது எந்த அளவு சிறந்தது என்பது இன்னும் கணினி வல்லுநர்கள் நடுவே பேசி முடிக்கப்படாத கருத்தாகவே இருக்கிறது.
சாப்ட்வேர் டெஸ்டிங் – நிறைவாகச் சில வரிகள்
இதுவரை நாம் பார்த்திருப்பது சாப்ட்வேர் டெஸ்டிங் என்று சொல்லப்படும் மென்பொருள் சோதனையின் அடிப்படைகள். புதுநிலை மென்பொறியாளர் ஒருவருக்கு இந்த அடிப்படைகளே போதுமானவை தாம். நாம் பேசிய இந்தத் தலைப்புகள் தாம் ISTQB என்று அழைக்கப்படும் மென்பொருள் சோதனைக்கான பன்னாட்டுத் தரச் சான்றிதழ் அமைப்பின் பாடத்திட்டத்தில் இருப்பதை நீங்கள் பார்க்கலாம். நாம் பார்க்காது விடுபட்ட பகுதிகள் ஒரு சில இருந்தாலும் அவற்றை மிக எளிதாக உங்களால் புரிந்து கொள்ள முடியும்.
நாம் பார்த்தவை தவிர்த்து, ஒரு டெஸ்டருக்கு அடிப்படையில் தரவமைப்பு(Database) பற்றிய புரிதலும் அதன் அடிப்படை கட்டளைகளும் இன்றியமையாதவை. அவற்றைத் திருமதி. து. நித்யா அவர்கள் எழுதிய எளிய தமிழில் MySQL புத்தகம் வழி நீங்கள் படித்துக் கொள்ள முடியும். தகவெளிமை(Agile) பற்றி ஏற்கெனவே சொன்னது போலத் திரு. இரா. அசோகன் அவர்கள் எழுதிய “எளிய தமிழில் Agile/Scrum” புத்தகம் மூலம் விரிவாகத் தெரிந்து கொள்வது நல்லது. இன்னும் திருமிகு. கலாராணி அவர்கள் எழுதும் சோதனை வழி நிரலாக்கம் பற்றிய தொடர் – கணியத்திலேயே காணக் கிடைக்கிறது. தானியங்கிச் சோதனை (Automation Testing) பற்றித் திருமதி. து. நித்யா அவர்களின் மின் நூல் – கணியத்திலேயே கிடைக்கிறது – அதைப் படிப்பதற்கு முன்பு கொஞ்சம் நிரலாக்கம் படித்து விட்டு அந்தப் புத்தகத்தைப் படியுங்கள். எப்படி சாப்ட்வேர் டெஸ்டிங்கை அடைய நினைப்பவர்களுக்கு, அது எளிமையாகத் தெரிகிறதோ, அதே போல் தான் நிரலாக்கமும்! நிரலாக்கத்தைப் பொருத்த வரை பயிற்சி தான் தேவை. எனவே, கொஞ்சம் கூடுதல் நேரம் ஒதுக்கி அதையும் கைக்கொள்ளுங்கள். மென்பொருள் துறையில் வெற்றிக் கொடி நாட்டுங்கள்.
– கி. முத்துராமலிங்கம் (muthu@payilagam.com)