तत्परता (DoR/DoD)

DoR — Definition of Ready: काम शुरू होने के लिए क्या तैयार होना चाहिए। यह उस माँग को खत्म करने के लिए है जो निष्पादन में जाती है और दो दिन बाद लौट आती है क्योंकि एक्सेस, डेटा या निर्णय की कमी थी।
DoD — Definition of Done: काम को पूरा माने जाने के लिए क्या हो चुका होना चाहिए। यह उस "मैंने पूरा कर लिया" को खत्म करने के लिए है जिसका अभी तक न परीक्षण हुआ, न दस्तावेज़ बना, न सूचना दी गई।

दोनों एक ही विचार हैं जो दोनों छोरों पर लागू होता है: समझौता पहले लिख लें, ताकि बाद में बहस न हो। और दोनों बोर्ड के हर चरण के लिए होते हैं — हर कॉलम का अपना हो सकता है।

दो सूचियाँ जिन पर टीम एक बार सहमत होती है और हमेशा इस्तेमाल करती है: किसी मांग के शुरू हो सकने के लिए क्या तैयार होना चाहिए (Definition of Ready) और उसे पूरा माने जाने के लिए क्या तैयार होना चाहिए (Definition of Done)। यही उस मांग को रोकता है जो बिना दायरे के स्प्रिंट में आ जाती है, और उसे जो "तैयार" है पर किसी ने टेस्ट नहीं की।

यहाँ आप टीम के तैयारी समझौते (DoR/DoD) का एक आइटम दर्ज करते हैं: यह किस चरण पर लागू होता है, यह उसमें प्रवेश की शर्त है या निकास की, क्या यह केवल एक प्रकार की मांग पर लागू होता है, समझौते का पाठ, क्या यह चरण से निकास को रोकता है, प्रदर्शन क्रम और क्या यह सक्रिय है। यह आइटम-दर-आइटम प्रवाह की गुणवत्ता चेकलिस्ट है।

"प्रवेश या निकास" फ़ील्ड तय करता है कि समझौता चरण के किस तरफ़ है। प्रवेश आइटम Definition of Ready है: मांग के उस चरण में आने से पहले क्या तैयार होना चाहिए (उदाहरण के लिए, निष्पादन में जाने से पहले "स्वीकृति मानदंड लिखे गए")। निकास आइटम Definition of Done है: मांग के चरण से बाहर निकलने के लिए क्या किया जाना चाहिए ("code review स्वीकृत")। "केवल इस प्रकार के लिए" फ़ील्ड आइटम को एक प्रकार की मांग तक सीमित करता है — बग का समझौता सुधार पर लागू होना ज़रूरी नहीं।

आप आइटम यहाँ एक बार लिखते हैं; जब माँग उस चरण में आती है तो यह माँग की अपनी चेकलिस्ट में कॉपी हो जाता है, लेबल कोष्ठक में होता है (उदाहरण के लिए [DoD Em execução] testes automatizados verdes)।

ध्यान दें कि चिह्नित करने के लिए कोई दूसरी सूची नहीं है: काम करने वाला हमेशा वाली जगह, माँग के भीतर ही चिह्नित करता है, और जाँच वहीं से पढ़ती है। दूसरी सूची का व्यवहार में मतलब होता एक छोड़ी हुई सूची।

यह सबसे उल्टा लगने वाला हिस्सा है। जब आप कार्ड को एक कॉलम से दूसरे में खींचते हैं, तो सिस्टम उस कॉलम का DoD जाँचता है जिससे वह निकल रहा है — क्योंकि सवाल यह है कि "क्या इसे यहाँ पूरा माना जा सकता है?"।

DoR कभी नहीं रोकता। यह प्रवेश-जाँच के रूप में आता है, चेकलिस्ट में दिखता है और याद दिलाने का काम करता है। अगर आप DoR के किसी आइटम पर रोक चिह्नित करते हैं, तो सिस्टम उसे बंद करके चेतावनी देता है।

खिसकाने पर तीन संभावित नतीजे: कुछ बाकी नहीं, और कार्ड आगे बढ़ जाता है; बिना रोक वाला आइटम बाकी, और कार्ड बाकी चीज़ों की सूची के साथ चेतावनी सहित आगे बढ़ता है; रोक वाला आइटम बाकी, और कार्ड अपनी जगह लौट जाता है। रोकने के लिए एक खुला रोक वाला आइटम काफ़ी है।

समझौते से पहले थोपा गया गेट गुणवत्ता नहीं, रास्ते निकालना पैदा करता है: टीम बोर्ड को चकमा देना सीख जाती है। आइटम लिखें, टीम को कुछ हफ़्ते उनके साथ रहने दें और रोक केवल उसी पर चालू करें जो आदत बन चुका है और फिर भी छूट जाता है।

गेट की दो ईमानदार सीमाएँ, ताकि आप उस पर ज़रूरत से ज़्यादा भरोसा न करें: यह केवल बोर्ड पर खींचने पर काम करता है — माँग के फ़ॉर्म से, थोक में, या "समाप्त करें" से स्थिति बदलना यहाँ से नहीं गुज़रता। और अगर तकनीकी त्रुटि के कारण जाँच विफल हो, तो बदलाव हो जाता है। जो गेट ढाँचे की खराबी के कारण संचालन रोक दे, वह उस समस्या से बदतर है जिसे वह रोकता है।

आइटम और चिह्न एक-दूसरे को लेबल के पाठ से पहचानते हैं। किसी समझौते का विवरण संपादित करने पर (या चरण का नाम बदलने पर, जो लेबल में आता है), सिस्टम पहले से चिह्नित चीज़ को पहचानना बंद कर देता है: पुराना चिह्न माँग के इतिहास में दिखता रहता है और नया आइटम बाकी के रूप में आता है।

यही सही व्यवहार है — नियम बदला, जाँच फिर से होती है —, लेकिन बदलाव की योजना बनाएँ: स्प्रिंट के बीच में ऐसा करने से पूरे बोर्ड पर बाकी आइटम लौट आते हैं।

"व्यू" बटन से व्यू सहेजने पर वह चार चीज़ें याद रखता है: खोज का टेक्स्ट, लगाए गए फ़िल्टर, कौन-से कॉलम दिखते हैं (और किस क्रम में) और सूची किस कॉलम से क्रमबद्ध है। व्यू लागू करने पर सब कुछ एक साथ लौट आता है — क्रम और आप जिस पेज पर थे उसे रीसेट करना भी, ताकि परिणाम ठीक वही हो जो व्यू बताता है। इस संस्करण से पहले सहेजे गए व्यू मान्य रहते हैं: जो उन्होंने नहीं सहेजा, वह लागू करने पर बस नहीं बदलता।

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

"निकास रोकता है" स्विच मार्गदर्शक समझौते को बाध्यकारी समझौते से अलग करता है: रोकने वाला आइटम पूरा न होने तक मांग को चरण में रोके रखता है; न रोकने वाला आइटम टीम के समझौते की याद के रूप में दिखता है, पर आगे बढ़ने से नहीं रोकता। रोक का सोच-समझकर इस्तेमाल करें — सब कुछ रोकने से प्रवाह नौकरशाही बन जाता है और टीम बिना देखे आइटम चिह्नित करने लगती है; रोक उसके लिए है जो वाकई बिना जाँच के आगे नहीं जा सकता, जैसे पूरा करने से पहले "टेस्ट चलाए गए"।

रिकॉर्ड के गतिविधि पैनल में हर टिप्पणी पर "माँग में बदलें" होता है। क्लिक करने से एक टिकट बनता है जिसमें टिप्पणी का टेक्स्ट, उसे लिखने वाला और इस रिकॉर्ड का लिंक होता है — कुछ भी दोबारा टाइप नहीं करना पड़ता। इसका उपयोग तब करें जब टिप्पणी किसी कार्रवाई का अनुरोध हो ("किसी को इसे देखना होगा"); टिप्पणी अपनी जगह बनी रहती है। बटन सिर्फ़ सहेजे गए रिकॉर्ड पर दिखता है; केवल-पढ़ने वाला सत्र (डेमो) टिकट नहीं बनाता।

केवल तब जब आप प्रकार खाली छोड़ें — तब यह एक सामान्य नियम होता है। प्रकार भरने पर आइटम केवल उसी प्रकार की माँग (बग, सुधार, सहायता...) पर लागू होता है।

एक बारीकी का ध्यान रखें: बिना तय प्रकार वाली माँग को केवल सामान्य नियम मिलते हैं। अगर आपका महत्वपूर्ण DoD किसी प्रकार से बँधा है, तो बिना प्रकार वाली माँग उससे बच निकलती है।

रिकॉर्ड खोलें और दाईं ओर "टाइमलाइन" देखें: वह हर बदलाव को "एक मान से दूसरे मान तक" के रूप में, व्यक्ति और तारीख़ के साथ दिखाती है। बदलाव बहुत हों तो टाइमलाइन के ऊपर के दो फ़िल्टर इस्तेमाल करें — एक फ़ील्ड के अनुसार, दूसरा व्यक्ति के अनुसार। खोज डेटाबेस में होती है, इसलिए पुराना बदलाव भी वैसे ही दिखता है। आप Tenkai से भी पूछ सकते हैं: "अनुबंध 482 किसने बदला?"।