பயனர் கதை
பயனர் கதைகள் வளர்ச்சியில் மென்பொருளுக்கான தேவைகளைக் கூறுவதற்கான ஒரு சிறந்த வழியாகும். இத்தகைய கதைகளில் மென்பொருளின் பயனரின் சார்பாக சுருக்கமான ஆலோசனைகள் உள்ளன.
ஸ்க்ரம் முறையியலில், இலக்குகளை அமைப்பது பொதுவாக வாடிக்கையாளர் அல்லது மென்பொருள் உரிமையாளரின் தனிச்சிறப்பாக இருப்பதால், அவை வளர்ச்சி செயல்முறையை பாதிக்கும் முக்கிய வழியாகக் கருதப்படுகின்றன. ஒவ்வொரு பயனர் கதைக்கும் உரையின் அளவு மற்றும் விளக்கக்காட்சியின் சிக்கலான தன்மை ஆகியவற்றில் வரம்பு உள்ளது. வரலாறு பெரும்பாலும் ஒரு சிறிய தாளில் எழுதப்படுகிறது, இது அதன் அளவைக் கட்டுப்படுத்துகிறது.
பயனர் கதைகளுக்கு நன்றி, நீங்கள் வாடிக்கையாளரின் விருப்பங்களை ஆவணப்படுத்தலாம் மற்றும் சந்தை கோரிக்கைகளுக்கு விரைவாக பதிலளிக்கலாம்.
பயனர் கதையானது தேவைகளின் எளிமையான அளவீடாகக் கருதப்பட வேண்டும், ஏனெனில் அது ஏற்றுக்கொள்ளும் சோதனை நடைமுறையைக் கொண்டிருக்கவில்லை. பயனர் கதையின் தொகுப்பு சேர்க்கை நடைமுறைக்கு இணங்க வேண்டும். பயனர் கதை அதன் இலக்கை அடைவதை இது உறுதி செய்யும்.
கதை அமைப்பு இது போல் தெரிகிறது: "ஒரு பயனராக <பயனர் வகை>, <விளைவு> பெற <action> செய்ய விரும்புகிறேன்" (ஒரு தயாரிப்பு உரிமையாளராக நான் விரும்புகிறேன் ...). அத்தகைய அமைப்பு எளிமையானது மட்டுமல்ல, அனைவருக்கும் புரியும்.
பயனர் கதைகளைப் பயன்படுத்துவதன் நன்மைகள்:
- கதைகள் சிறியவை மற்றும் உருவாக்க எளிதானவை.
- திட்டப்பணி மற்றும் அதன் ஆதரவைப் பற்றி விவாதிக்க அனைத்து பங்குதாரர்களுக்கும் உதவுங்கள்.
- நிலையான பராமரிப்பு தேவையில்லை.
- பயன்படுத்தும் போது மட்டுமே பொருத்தமானது.
- வாடிக்கையாளருடன் தொடர்புகளை மேம்படுத்தவும்.
- அவர்களுக்கு நன்றி, நீங்கள் திட்டத்தை சிறிய நிலைகளாக பிரிக்கலாம்.
- சரியாக புரிந்து கொள்ளப்படாத தேவைகள் கொண்ட திட்டங்களில் பணியை எளிதாக்குதல்.
- பணி மதிப்பீட்டை எளிதாக்குங்கள்.
பயனர் கதைகளின் தீமைகள்:
- முன் ஒப்பந்தம் இல்லாமல், ஒப்பந்தத்தின் அடிப்படையாகப் பயன்படுத்துவதை நடைமுறைகள் கடினமாக்கும்.
- அவற்றின் பயன்பாட்டிற்கு முழு திட்டத்திலும் கிளையண்டுடன் நெருங்கிய தொடர்பு தேவைப்படுகிறது, இது சில நேரங்களில் பணிப்பாய்வு கடினமாக்குகிறது.
- பெரிய திட்டங்களில் அளவிடும் போது அவர்களுக்கு தீமைகள் உள்ளன.
- டெவலப்பர்களின் தொழில்முறை மட்டத்துடன் நேரடியாக தொடர்புடையது.
- விவாதத்தைத் தொடங்கப் பயன்படுகிறது, ஆனால் விவாதத்தை முடிக்காமல் போகலாம், மேலும் கணினி ஆவணப்படுத்தலுக்குப் பயன்படுத்தப்படாது.
பின்னிணைப்பு
தயாரிப்பு பேக்லாக் என்பது ஒரு பட்டியலின் வடிவத்தில் தற்போதைய பணிகள், முன்னுரிமை வரிசையில் தொகுக்கப்பட்டுள்ளது. திட்டத்தின் பாதை வரைபடம் (சாலை வரைபடம்) மற்றும் அதில் குறிப்பிடப்பட்டுள்ள புள்ளிகளின் அடிப்படையில் பட்டியல் உருவாக்கப்பட்டுள்ளது. மிக முக்கியமான பணிகள் பொதுவாக பட்டியலில் முதலிடத்தில் இருக்கும். எந்த வேலை முதலில் செய்யப்பட வேண்டும் என்பதைப் புரிந்து கொள்ள இது அவசியம்.
வாடிக்கையாளரின் விருப்பத்தைப் பொருட்படுத்தாமல் பேக்லாக் பணிகளை முடிக்கும் வேகத்தை டெவலப்மென்ட் குழு தேர்வு செய்கிறது, ஆனால் அவர்களின் தகுதிகள் மற்றும் கடந்த கால ஸ்பிரிண்ட்களின் அனுபவத்தின் அடிப்படையில். புரோகிராமர்களை "சரிசெய்வது" மிகவும் விரும்பத்தகாதது. குழுவானது அதன் சொந்த பரிசீலனைகள் மற்றும் திறன்களுக்கு ஏற்ப பேக்லாக் இருந்து பணிகளை தேர்வு செய்கிறது. மரணதண்டனை குறுக்கீடு இல்லாமல் (கன்பன்) அல்லது பல மறு செய்கைகள் (ஸ்க்ரம்) இல்லாமல் நடைபெறுகிறது.
இரண்டு முக்கியமான பின்னடைவு நிலைமைகள்
ஒரு தயாரிப்பு பின்னிணைப்பின் மையமானது ஒரு சாலை வரைபடம், முன்மொழிவுகள் மற்றும் செயல்படுத்தல் நிலைமைகளைக் கொண்டுள்ளது. காவியங்களில் நிபந்தனைகள் மற்றும் பயனர் கதை உள்ளது. ஒரு பொதுவான சாலை வரைபட உதாரணத்தை உற்று நோக்கலாம்.
![](https://cdn.codegym.cc/images/article/ed1effe1-28b8-460e-be96-6e0a3f63cadb/512.jpeg)
"டீம்ஸ் இன் ஸ்பேஸ்" இணையதளத்தை உருவாக்குவதே சாலை வரைபடத்தின் முதல் முன்மொழிவாகும். இது காவியங்களாகப் பிரிக்கப்பட வேண்டும் (படத்தில் அவை பச்சை, நீலம் மற்றும் டர்க்கைஸ் வண்ணங்களில் காட்டப்பட்டுள்ளன) மற்றும் ஒவ்வொரு காவியத்திற்கும் ஒரு பயனர் கதை.
![](https://cdn.codegym.cc/images/article/1abe569c-0299-4ae4-b5f4-b6b8444ed525/512.jpeg)
மென்பொருள் வாடிக்கையாளர் பல பயனர் கதைகளிலிருந்து ஒரு பட்டியலை உருவாக்குகிறார். தேவைப்பட்டால், கதைகள் செயல்படுத்தப்படும் வரிசையை அவர் மாற்றலாம், இதனால் டெவலப்பர்கள் முதலில் மிக முக்கியமான காவியங்களில் ஒன்றை (இடது) கையாள்வார்கள் அல்லது தள்ளுபடி டிக்கெட் முன்பதிவு எவ்வாறு செயல்படுகிறது என்பதைச் சரிபார்க்கலாம். இதைச் செய்ய, நீங்கள் காவியங்களிலிருந்து (வலது) கதைகளைச் செயல்படுத்த வேண்டும். இரண்டு விருப்பங்களையும் கீழே காணலாம்.
![](https://cdn.codegym.cc/images/article/d60c4faf-cc40-44ed-90f8-5ab66c914e47/512.jpeg)
எந்தக் காரணிகளின் அடிப்படையில் வாடிக்கையாளர் முன்னுரிமை அளிக்க வேண்டும்?
- பயனர்களுக்கு பொருத்தம்.
- பின்னூட்டத்தின் இருப்பு.
- வளர்ச்சியின் சிக்கலானது.
- பணிகளுக்கு இடையிலான உறவு ("B" ஐ முடிக்க, நீங்கள் முதலில் "A" செய்ய வேண்டும்).
வேலையில் முன்னுரிமைகள் வாடிக்கையாளரால் தீர்மானிக்கப்படுகின்றன, ஆனால் மற்ற கட்சிகள் இதைப் பற்றி தங்கள் கருத்தை தெரிவிக்கலாம். பேக்லாக்கின் வெற்றி, மற்றவற்றுடன், வாடிக்கையாளர்கள் மற்றும் புரோகிராமர்களின் கருத்துகளைப் பொறுத்தது. ஒன்றாக, அவர்கள் சிறந்த முடிவுகளை அடைய முடியும் மற்றும் முடிக்கப்பட்ட தயாரிப்பு சரியான நேரத்தில் விநியோகம் உறுதி.
பேக்லாக் வைத்திருப்பது எப்படி
பேக்லாக் ஏற்கனவே உருவாக்கப்பட்டிருந்தால், அதன் பிறகு நீங்கள் அதை மேலும் பணியின் போது அவ்வப்போது மாற்ற வேண்டும். ஒவ்வொரு புதிய மறு செய்கை திட்டமிடலுக்கு முன்பும் பின்னிணைப்பு சரியாக தொகுக்கப்பட்டுள்ளதா என்பதை மென்பொருள் வாடிக்கையாளர் உறுதி செய்ய வேண்டும். இது முன்னுரிமைகளை தெளிவுபடுத்த அல்லது கடைசி மறு செய்கையின் பகுப்பாய்வுக்குப் பிறகு ஏதாவது மாற்ற உதவும். சுறுசுறுப்பான பேக்லாக்கைச் சரிசெய்வது சில நேரங்களில் "சீர்ப்படுத்துதல்" அல்லது "சுத்திகரிப்பு" அல்லது "பேக்லாக் பராமரிப்பு" என்று அழைக்கப்படுகிறது.
பேக்லாக் ஏற்கனவே ஒப்பீட்டளவில் பெரியதாக இருந்தால், வாடிக்கையாளர் குறுகிய கால மற்றும் நீண்ட கால செயல்பாட்டின் மூலம் பணிகளை குழுவாக்க வேண்டும். குறுகிய கால பணிகளுக்கு இந்த அந்தஸ்து வழங்கப்படுவதற்கு முன் ஆய்வு செய்யப்பட வேண்டும். நீங்கள் ஒரு பயனர் கதையை உருவாக்க வேண்டும், குழுவில் உள்ள அனைத்து நுணுக்கங்களையும் கண்டறியவும்.
நீண்ட கால பணிகளைப் பொறுத்தவரை, டெவலப்பர்கள் தங்கள் மதிப்பீட்டை வழங்குவது மிகவும் விரும்பத்தக்கது. இது முன்னுரிமை கொடுப்பதை எளிதாக்கும். ஒருவேளை ஏதாவது மாறும், ஆனால் குழு பணிகளைப் பற்றிய அவர்களின் புரிதலை மேம்படுத்தி, வேலையை விரைவாகச் செய்யும்.
வாடிக்கையாளருக்கும் நிரலாக்கக் குழுவிற்கும் இடையில் பேக்லாக் ஒரு முக்கிய அங்கமாகும். வாடிக்கையாளர் கருத்து, கணிப்புகள் அல்லது புதிய தேவைகளின் அடிப்படையில் வாடிக்கையாளர் எப்போதும் முன்னுரிமைகளை மாற்றலாம்.
செயல்பாட்டின் போது நேரடியாக மாற்றங்களைத் தவிர்க்க பரிந்துரைக்கப்படுகிறது. இது வேலைப்பாய்வு மற்றும் புரோகிராமர்களின் உணர்ச்சி நிலை ஆகியவற்றில் மோசமான விளைவை ஏற்படுத்துகிறது.
ஸ்பிரிண்ட்
ஸ்பிரிண்ட் என்பது ஒரு குறுகிய காலம் ஆகும், இதன் போது முன்னர் ஒப்புக் கொள்ளப்பட்ட அளவு வேலைகள் முடிக்கப்பட வேண்டும். ஸ்பிரிண்ட்ஸ் ஸ்க்ரம் மற்றும் அஜில் முறைகளை அடிப்படையாகக் கொண்டது. சரியான ஸ்பிரிண்ட்களைத் தேர்ந்தெடுப்பது, ஒரு சுறுசுறுப்பான குழு தரமான மென்பொருளை உருவாக்க உதவுகிறது.
“ஸ்க்ரமைப் பயன்படுத்தி, நீங்கள் ஒரு தயாரிப்பை பல மறு செய்கைகளில் தெளிவான கால அளவுடன் உருவாக்கலாம் - ஸ்பிரிண்ட்ஸ். இது பெரிய திட்டங்களை சிறிய பணிகளாக உடைக்க உதவுகிறது,” என்கிறார் அட்லாசியனில் ஜிரா லீட் மேகன் குக்.
![](https://cdn.codegym.cc/images/article/b909003c-7af8-4a4e-a6f1-f64c173eb213/512.jpeg)
ஸ்க்ரம் எப்படி ஸ்பிரிண்ட்களை திட்டமிட்டு செயல்படுத்துகிறது?
ஸ்க்ரம் முறையின் ஆசிரியர்களின் கூற்றுப்படி, எதிர்கால ஸ்பிரிண்டைத் திட்டமிட, அனைவரும் ஒரு தனி கூட்டத்தில் சந்திக்க வேண்டும். இந்த நிகழ்வில், குழு உறுப்பினர்கள் இரண்டு முக்கிய கேள்விகளுக்கான பதில்களைக் கண்டுபிடிக்க வேண்டும்: இந்த ஸ்பிரிண்டில் என்ன செய்ய வேண்டும் மற்றும் அதை எவ்வாறு சிறப்பாகச் செய்வது?
மென்பொருள் வாடிக்கையாளர், ஸ்க்ரம் மாஸ்டர் மற்றும் புரோகிராமர்கள் பணிப் பணிகளின் பட்டியலைத் தீர்மானிப்பதில் ஈடுபட்டுள்ளனர். ஸ்பிரிண்ட் மற்றும் பணிகளை பின்னிணைப்பில் இருந்து வாடிக்கையாளர் விளக்குகிறார்.
பின்னர் குழு ஒரு திட்டத்தை உருவாக்குகிறது, அதன்படி ஸ்பிரிண்டில் உள்ள பணிகள் முடிக்கப்படும். இந்தத் திட்டம், தேர்ந்தெடுக்கப்பட்ட பணிப் பொருட்களுடன் சேர்ந்து, ஸ்பிரிண்ட் பேக்லாக் என்று அழைக்கப்படுகிறது. திட்டமிடல் கூட்டத்திற்குப் பிறகு, குழு வேலை செய்கிறது. டெவலப்பர்கள் பின்னிணைப்பில் இருந்து பணிகளைத் தேர்ந்தெடுக்கிறார்கள், வேலை முடிந்ததும், ஒவ்வொரு பணியின் நிலையும் "செயல்படுகிறது" என்பதிலிருந்து "முடிந்தது" என மாறுகிறது.
ஸ்பிரிண்டின் போது, குழு தினசரி ஸ்க்ரம் சந்திப்புகளை (ஸ்டாண்ட்-அப்கள்) நடத்தி தற்போதைய சிக்கல்கள் மற்றும் முன்னேற்றம் பற்றி விவாதிக்கிறது. ஸ்பிரிண்ட் முடிவடைவதைப் பாதிக்கக்கூடிய சிரமங்களைக் கண்டறிய இத்தகைய சந்திப்புகள் தேவைப்படுகின்றன.
ஸ்பிரிண்ட் முடிந்தால், முடிவுகளின் மதிப்பாய்வில் (டெமோ) குழு அவர்களின் பணியின் முடிவுகளைக் காட்டுகிறது. திட்டத்தின் ஒவ்வொரு பங்கேற்பாளரும் முடிவுகளைப் பற்றி அறிந்து கொள்ளலாம். முடிக்கப்பட்ட குறியீடு உற்பத்தி சூழலில் இணைக்கப்படுவதற்கு முன் பரிச்சயப்படுத்தப்பட வேண்டும்.
பின்னோக்கி ஸ்பிரிண்ட் சுழற்சியை நிறைவு செய்கிறது. அதில், எதிர்கால ஸ்பிரிண்டில் மேம்படுத்தப்பட வேண்டிய பகுதிகளை குழு அடையாளம் காட்டுகிறது.
![](https://cdn.codegym.cc/images/article/c4ae36c8-333f-4141-a45b-5d813c391c8c/512.jpeg)
எதில் கவனம் செலுத்த வேண்டும், என்ன செய்யக்கூடாது
பெரும்பாலான இளம் அணிகள் முதல் முறையாக தங்கள் பணிப்பாய்வுகளில் ஸ்பிரிண்ட்களை அறிமுகப்படுத்துவது கடினம். சிக்கல்களைத் தவிர்க்க, முன்னுரிமை கவனம் தேவைப்படும் செயல்களின் பட்டியலை மதிப்பாய்வு செய்ய பரிந்துரைக்கிறோம்.
நாம் என்ன செய்ய வேண்டும்:
- ஸ்பிரிண்டின் நோக்கம் மற்றும் அது எவ்வாறு வெற்றிபெறும் என்பதை குழு புரிந்துகொள்கிறதா என்பதைச் சரிபார்க்கவும். அனைவரும் ஒன்றிணைந்து வெற்றிகரமான முடிவை நோக்கிச் செல்ல இது அவசியம்.
- உங்களிடம் தெளிவான மற்றும் புரிந்துகொள்ளக்கூடிய பின்னடைவு இருக்க வேண்டும். பேக்லாக் சரியாக பராமரிக்கப்படாவிட்டால், இது பணிப்பாய்வுக்கு சேதம் விளைவிக்கும் ஒரு சிக்கலாக மாறும்.
- கோடை விடுமுறைகள் மற்றும் பிற காரணிகளை கணக்கில் எடுத்துக்கொண்டு, வேலையின் வேகம் குறித்த உங்கள் மதிப்பீடு சரியானது என்பதை உறுதிப்படுத்தவும்.
- ஸ்பிரிண்ட் திட்டமிடலில் தீவிரமாக பங்கேற்கவும். கதைகள், பிழைகள் மற்றும் பணிகளுக்கான திட்டத்தை விரிவுபடுத்த குழு உறுப்பினர்களை ஊக்குவிக்கவும்.
- டெவலப்பர்களால் சார்புச் சிக்கல்களைத் தீர்க்க முடியாத பணிகளை நிராகரிக்கவும்.
- திட்டம் அங்கீகரிக்கப்பட்ட பிறகு, திட்ட மேலாண்மை திட்டத்தில் (ஜிரா கார்டுகள், முதலியன) தரவை உள்ளிடுவதற்கு பொறுப்பான ஒரு பணியாளரை நியமிக்கவும்.
எதை தவிர்க்க வேண்டும்:
- அதிக எண்ணிக்கையிலான கதைகளை அதிகமாகப் பயன்படுத்தாதீர்கள், வேலையின் வேகத்தை நிதானமாக மதிப்பிடுங்கள் மற்றும் ஒரு வேகத்தில் முடிக்க கடினமாக இருக்கும் பணிகளை ஒதுக்க வேண்டாம்.
- உங்கள் வேலையின் தரத்தில் கவனம் செலுத்துங்கள். தரக் கட்டுப்பாடு மற்றும் குறியீட்டில் உள்ள பிழைகளைச் சரிசெய்வதற்கு உங்களுக்கு போதுமான நேரம் இருக்கிறதா எனச் சரிபார்க்கவும்.
- அனைத்து குழு உறுப்பினர்களும் ஸ்பிரிண்டின் உள்ளடக்கத்தை தெளிவாக புரிந்துகொள்கிறார்கள் என்பதை உறுதிப்படுத்தவும். வேகத்தைத் துரத்த வேண்டாம். முழு அணியும் ஒன்றாகச் செல்ல வேண்டும்.
- டெவலப்பர்களுக்கு கூடுதல் வேலைகளைச் செய்ய வேண்டாம். மற்றொரு ஸ்பிரிண்ட் விரைவில் வருகிறது.
- பணிச்சுமை அல்லது காலக்கெடு குறித்து குழு கவலை தெரிவித்தால், நீங்கள் அவர்களின் கருத்தை கணக்கில் எடுத்துக்கொள்ள வேண்டும். சிக்கல்களைச் சமாளிக்கவும், தேவைப்பட்டால் அவற்றை சரிசெய்யவும்.
ஸ்க்ரம் போர்டு
ஸ்க்ரம் போர்டு என்பது ஸ்க்ரம் குழுவின் பணி எவ்வாறு செய்யப்படுகிறது என்பதைக் காட்டும் ஒரு கருவியாகும். காகிதத்தில், சுவரில் அல்லது மின்னணு வடிவத்தில் (JIRA, Trello) அத்தகைய பலகையில் தகவலை நீங்கள் காட்டலாம்.
ஒரு ஸ்க்ரம் போர்டில் குறைந்தது மூன்று நெடுவரிசைகள் உள்ளன: செய்ய வேண்டியது, செயல்பாட்டில் உள்ளது மற்றும் முடிந்தது. இங்கே ஒரு எடுத்துக்காட்டு பலகை:
![](https://cdn.codegym.cc/images/article/4939be8a-e658-46a1-b509-4bbc7357d2df/512.jpeg)
ஸ்க்ரம் போர்டில் திட்டமிடலுக்கு முன்னர் அங்கீகரிக்கப்பட்ட பின்னிணைப்பில் இருந்து அனைத்து தகவல்களும் உள்ளன. ஒரு விதியாக, வணிகப் பணி அட்டைகள் மேலிருந்து கீழாக முன்னுரிமையின் மூலம் போர்டில் பின் செய்யப்படுகின்றன. நீங்கள் அவற்றை குறிப்பிட்ட வகை வேலைகளாகப் பிரிக்கலாம் (குறியீடு, வடிவமைப்பு மற்றும் பிறவற்றில் வேலை செய்யுங்கள்).
வேலையின் ஒரு பகுதி முடிந்ததும், அட்டை பலகையின் குறுக்கே அடுத்த நெடுவரிசைக்கு நகர்த்தப்படும். குழுவின் வேலையின் முன்னேற்றத்தின் தெரிவுநிலையைக் காட்ட, பர்ன்டவுன் விளக்கப்படத்தில் நாள்தோறும் "மீதமுள்ள வேலை" உதவுகிறது.
நீங்கள் ஃபிளிப்சார்ட் போர்டையும் பயன்படுத்தலாம். அதில், காகித ஸ்டிக்கர்களில் படைப்புகளின் பெயர்கள் எழுதப்பட்டு பலகையில் இணைக்கப்பட்டுள்ளது. வேலை முடிந்தவுடன், ஸ்டிக்கர்கள் மற்றொரு நெடுவரிசைக்கு மாற்றப்படும்.
எரிப்பு விளக்கப்படம்
பர்ன்டவுன் விளக்கப்படம் செய்யப்பட்ட வேலையின் அளவு மற்றும் மீதமுள்ள வேலையின் அளவு ஆகியவற்றைக் காட்டுகிறது. இது ஒவ்வொரு நாளும் புதுப்பிக்கப்பட்டு அனைத்து ஆர்வமுள்ள தரப்பினருக்கும் கிடைக்கும். ஸ்பிரிண்டில் வேலையின் முன்னேற்றத்தைக் காட்ட வரைபடம் தேவை.
இரண்டு வகையான விளக்கப்படங்கள் உள்ளன:
- ஸ்பிரிண்டில் வேலையின் முன்னேற்றத்தைக் காட்டும் பர்ன் டவுன் விளக்கப்படம்.
- தயாரிப்பு வெளியிடப்படும் வரை வேலையின் முன்னேற்றத்தைக் காட்டும் பர்ன்டவுன் விளக்கப்படம் (தரவு பல ஸ்பிரிண்ட்களில் இருந்து சுருக்கப்பட்டுள்ளது).
விளக்கப்பட எடுத்துக்காட்டு:
![](https://cdn.codegym.cc/images/article/c006b168-1332-4ffc-bf97-236edc73da12/512.jpeg)
இந்த எடுத்துக்காட்டு உளவியலைப் பயன்படுத்துகிறது: விளக்கப்படம் முடிக்கப்பட்ட பணிகளின் எண்ணிக்கையைக் காட்டாது, ஆனால் மீதமுள்ள எண்ணிக்கை (செய்யப்படவில்லை).
அதாவது 100க்கு 90 டாஸ்க்குகளை டீம் செய்திருந்தால் எல்லாம் தயார் என்ற தவறான எண்ணம் வரலாம். எல்லாவற்றிற்கும் மேலாக, 90 முதல் 100 பணிகள் வரை முன்னேற்றம் உண்மையில் எதையும் மாற்றாது.
மீதமுள்ள பணிகளின் எண்ணிக்கையை நீங்கள் காட்டினால், ஒவ்வொரு முறையும் அவை எவ்வாறு குறைவாகவும் குறைவாகவும் மாறும் என்பதை நீங்கள் கவனிக்க முடியாது. இது திட்ட பங்கேற்பாளர்களை இலக்கை விரைவாக அடைய ஆழ் மனதில் தூண்டுகிறது - குழுவில் முடிக்கப்படாத பணிகள் இருக்கக்கூடாது.