Agile/Scrum பற்றி தொடர் கட்டுரை – 5
ஒருவேளை நீங்கள் அரசியல் கட்சிகள் மட்டும்தான் கொள்கை விளக்க அறிக்கைகளை தேர்தல் நேரத்தில் வெளியிடுவார்கள் என்று நினைத்தீர்களா என்ன? 2001-ம் ஆண்டு குளிர்காலத்தில் யூடா மாகாணத்தின் ஸ்னோபேர்ட் பனிச்சறுக்கு மையத்தில் 17 மென்பொருள் உருவாக்குபவர்கள் கூடினர். இவர்கள் யாவரும் வெவ்வேறு மென்பொருள் செயல்முறைகளை (Extreme Programming or XP, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others) உருவாக்கி ஊக்குவித்து வந்தனர். ஆனாலும் பொதுவாக இவர்கள் பயன்படுத்திய வழிமுறைகள் பேச்சுவழக்கில் “இலகுரக வழிமுறைகள்” என்று குறிப்பிடப்பட்டன. ஏனென்றால் அருவி வழிமுறை போலில்லாமல் இவர்களின் வழிமுறைகள் ஆவணங்களைக் குறைத்து நிரலாக்கத்தில் அதிக முக்கியத்துவம் வைத்தன. இவர்கள் சந்தித்து, கூடிப்பேசி, தங்கள் வழிமுறைகளில் பகிர்ந்த நம்பிக்கைகளை வெளிக்கொணர்ந்து, ஒருமுகப்படுத்த முயற்சி செய்தனர். இந்த முயற்சியின் முடிவில் மென்பொருள் உருவாக்குவதற்கான தங்களுடைய கொள்கை விளக்க அறிக்கையையும் (Agile Manifesto) அத்துடன் மென்பொருளுக்கான கோட்பாடுகளையும் வெளியிட்டனர். இந்த கொள்கைகளும் கோட்பாடுகளும் ஒவ்வொரு விதத்திலும் அருவி செயல்முறைக்கு எதிர்மாறாக இருந்தன.
ஆவணங்கள் பற்றி
-
விரிவான ஆவணங்களை விட வேலை செய்யும் மென்பொருளே முக்கியமானது. திட்டத்தில் வேலை எவ்வளவு முடிந்தது என்பதற்கு முதன்மையான அளவு மென்பொருள்தான். ஆகவே நாங்கள் இடைவிடாமல் மதிப்புமிக்க மென்பொருளை உருவாக்கி வெளியீடு செய்வதன் மூலம் வாடிக்கையாளரை திருப்தி செய்வதே முக்கியம் என்று நம்புகிறோம்.
மாற்றங்கள் பற்றி
-
வாடிக்கையாளர்களால் அவர்களுக்கு தேவைப்படும் மென்பொருள் தேவைகளை பட்டியலிடுவது சாத்தியமற்றது. அவர்கள் ஒருக்கால் இதைச் செய்தாலும், மென்பொருள் வெளியீடு செய்வதற்குள் அந்த தேவைகளில் மாற்றம் ஏற்படலாம்.
-
வாடிக்கையாளர் தேவைகளும், தொழில்நுட்பமும் மாறிவிட்ட பின் கண்ணைமூடிக்கொண்டு முன் போட்ட திட்டத்தையே பின்பற்றுவது விவேகமல்ல.
-
திட்டத்தின் கடைசி கட்டங்களில் கூட மாறிவரும் தேவைகளை வரவேற்கிறோம். மாற்றங்களை கட்டுப்படுத்தி பயன்படுத்துவதன் மூலம் வாடிக்கையாளருக்கு சந்தைப் போட்டியில் அனுகூலம் செய்வோம்.
திட்ட இறுதியில் வெளியீடு செய்வது பற்றி
-
வணிகத்துறையினரும் நிரலாளர்களும் தினந்தோரும் இணைந்து வேலை செய்ய வேண்டும். அருவி செயல்முறையில் ஒப்பந்தக்காரர் கொள்முதல் ஆணையை வாங்கிக்கொண்டு சென்று வேலையை முடித்தபின் முழுமையான நிரலை கொண்டுவந்து சேர்ப்பதை இத்துடன் ஒப்பிட்டுப் பாருங்கள்.
-
மென்பொருளை உடனுக்குடன் வெளியீடு செய்வதன் மூலம் உங்கள் திட்டத்தின் தற்போதைய நிலை தெளிவாவது மட்டுமல்லாமல் பங்குதாரர்கள் உடன் பின்னூட்டம் வழங்கவும் இயலும்.
வேலை செய்யும் அணிகள் பற்றி
-
குழு உறுப்பினர்களின் திறமையும், அவர்கள் ஒன்றாக இணைந்து வேலை செய்வதும் மிக முக்கியம். அது சரியாக நடக்கவில்லை என்றால் சிறந்த கருவிகளாலும் செயல்முறைகளாலும் எந்தப் பயனும் ஏற்படாது.
-
சுயமாக வேலையை பங்கிட்டுச்செய்யும் அணிகளே சிறந்த கட்டமைப்புகளையும், தேவைகளையும், வடிவமைப்புகளையும் உருவாக்குகின்றனர்.
-
மென்பொருள் வழிமுறைகளில் மேம்பாடு என்பது தொடர்ந்து செய்ய வேண்டிய முயற்சி ஆகும். செயல் முடித்த பின் இன்னும் திறம்படசெய்வது எப்படி என்று ஆய்வு செய்து அணிகள் தங்கள் நடவடிக்கைகளை சரிப்படுத்திக் கொண்டே இருக்க வேண்டும்.
-
இந்த செயல்முறைகள் நிலைத்திருக்கக்கூடிய வளர்ச்சியை ஊக்குவிக்கின்றன. பங்குதாரர்கள், நிரலாளர்கள், மற்றும் பயனர்கள் காலவரையின்றி ஒரு நிலையான வேகத்தை பராமரிக்க முடியும். அருவி செயல்முறையில் திட்டக் கெடுவில் முடிக்க செய்யும் மரண அணிவகுப்பை இத்துடன் ஒப்பிட்டுப் பாருங்கள். மரண அணிவகுப்பு என்பது கடைசி நிமிடத்தில் அவசர அவசரமாகச் செய்யும் களைக்க வைக்கும் அளவுக்கு மீறிய வேலையைக் குறிக்கிறது.
commons.wikimedia.org/wiki/File:Agile-vs-iterative-flow.jpg
இந்த Agile Manifesto மென்பொருள் உருவாக்கும் செயல்முறைகளை நிரந்தரமாக மாற்றியது. வணிக மற்றும் தொழில்நுட்ப உலகில் ஏற்றுக்கொள்ளப்பட்ட, ஆனால் மிகப் பிரச்சினையானதென்று உணர்ந்த, மென்பொருள் உருவாக்கும் அணுகுமுறையான அருவி செயல்முறை வேலைக்கு ஆகாது என்று இந்த Agile Manifesto பிரகடனம் செய்தது. அருவி செயல்முறை பழுதானது. இம்முறையில் சந்தையிலும் தொழில் நுட்பங்களிலும் ஏற்படும் மாற்றங்களுக்கு ஏற்ப மென்பொருளை உடன் மாற்றுவது மிகக் கடினம். திட்டம் வெற்றியில் முடியுமா அல்லது தோல்வியில் முடியுமா என்பது கடைசி நிமிடம் வரை மதில் மேல் பூனையாகவே இருக்கிறது. இந்தக் காரணங்களால் அருவி செயல்முறை அடிப்படையிலேயே குறைபாடுகளுடையது.
farm8.staticflickr.com/7314/8746306184_502e6dcccf_o_d.jpg
திட்டத்தில் முன்னேற்றம் பற்றி வாடிக்கையாளருக்கு ஆவணங்கள் அனுப்புவது புரோநோட்டு எழுதித் தருவது போல்தான் என்று கூறுகிறார் Crystal-ன் ஆலிஸ்டேர் காக்பர்ன் (Alistair Cockburn). புரோநோட்டு எழுதித் தருவதற்கு பதிலாக தவணை முறையில் பணமே செலுத்துங்கள். சோதனை செய்த, ஓடுகின்ற நிரலின் கூறுகளை நீங்கள் அடிக்கடி விநியோகம் செய்வதனால் திட்டத்தை குறித்த கெடுவில் முடிக்கும் சாத்தியக்கூறு அதிகமாகிறது.
இந்த கொள்கை விளக்க அறிக்கை நிரலாளர்களால் உருவாக்கப்பட்டது. Pragmatic Programming டேவிட் தாமஸ் (David Thomas) கூறுகிறார், “1980 மற்றும் 90-ல் இருந்த அவசியமற்ற, ஆன்மாவை அழிக்கும் நடை முறைகள் சிலவற்றிலிருந்து நிரலாளர்கள் உடைத்து வெளிவர இது உதவியது.”
மேற்குறிப்பிட்ட பல இலகுரக வழிமுறைகளில் திட்ட மேலாண்மைக்கு Scrum செயல்முறையும் பொறியியல் நடைமுறைகளுக்கு XP-ம் மேலோங்கின. தற்போதைய சிறந்த நடைமுறை இந்த இரண்டையும் ஒருங்கிணைத்தது. Scrum செயல்முறையை உருவாக்கி, வெற்றிகரமாக செயல்படுத்தி, பிரபலப்படுத்தியவர்கள் ஜெஃப் சதர்லேண்ட் (Jeff Sutherland) மற்றும் கென் ஷ்வாபர் (Ken Schwaber). பொறியியல் நடைமுறையில் பல புதிய அம்சங்களை முயற்சி செய்து அவற்றின் செயல்திறனை நிரூபித்து நிலைநாட்டியவர் XP-ன் கென்ட் பெக் (Kent Beck). ஆகவே இவர்களையும் இவர்களின் பங்களிப்புகளையும் பற்றி அடுத்து வரும் கட்டுரைகளில் விவரமாகக் காண்போம்.
Agile-க்கு தமிழாக்கம் “தகவெளிமை” என்று கருத்தனின் சிந்தனைப் பட்டறையில் விளக்கமாக எழுதியுள்ளார். எனக்கும் இது சரியாகவே படுகிறது. நீங்கள் என்ன நினைக்கிறீர்கள்? கீழே உள்ள கருத்துப்பெட்டி மூலம் உங்கள் எண்ணங்களைப் பகிர்ந்து கொள்ளுங்கள்.
இரா. அசோகன்
Ashok Ramachandran <ashokramach@gmail.com>
தொடரின் முந்தைய பதிவுகள்
www.kaniyam.com/most-of-the-software-fails/
www.kaniyam.com/agile-scrum-part-2/