14 ਦਸੰ 2025·7 ਮਿੰਟ
Claude Code ਟਾਸਕ ਸਕੋਪਿੰਗ: ਅਸਪਸ਼ਟ ਬੇਨਤੀਆਂ ਤੋਂ ਕਮਿਟ ਤੱਕ
Claude Code ਟਾਸਕ ਸਕੋਪਿੰਗ ਸਿੱਖੋ—ਕਿਵੇਂ ਗੰਦੇ ਫੀਚਰ ਦੀ ਬੇਨਤੀ ਨੂੰ ਸਪੱਸ਼ਟ acceptance criteria, ਇੱਕ ਨਿੂੰਨਤਮ UI/API ਯੋਜਨਾ, ਅਤੇ ਕੁਝ ਛੋਟੇ ਕਮਿਟਾਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਅਸਪਸ਼ਟ ਫੀਚਰ ਬੇਨਤੀਆਂ ਕਿਉਂ ਸਮਾਂ ਘਰਾਉਂਦੀਆਂ ਹਨ
ਇੱਕ ਅਸਪਸ਼ਟ ਬੇਨਤੀ ਹਲਕੀ ਲੱਗਦੀ ਹੈ: “ਇੱਕ ਵਧੀਆ ਖੋਜ ਜੋੜੋ,” “Onboarding ਨੂੰ ਸਧਾਰੋ,” “ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚਾਹੀਦੇ ਹਨ।” ਅਸਲ ਟੀਮਾਂ ਵਿੱਚ ਇਹ ਆਮ ਤੌਰ ’ਤੇ ਇੱਕ-ਲਾਈਨ ਚੈਟ ਸੁਨੇਹਾ, ਤੀਰ ਵਾਲੀ ਸਕਰੀਨਸ਼ਾਟ, ਜਾਂ ਅਧ-ਯਾਦ ਗ੍ਰਾਹਕ ਕਾਲ ਵਜੋਂ ਆਉਂਦਾ ਹੈ। ਸਾਰੇ ਇਸ਼ਾਰਿਆਂ ਨਾਲ ਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਹਰ ਕੋਈ ਕੁਝ ਵੱਖਰਾ ਸੋਚਦਾ ਹੈ।
ਲਾਗਤ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੀ ਹੈ। ਜਦੋਂ ਸਕੋਪ ਅਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਲੋਕ ਅਨੁਮਾਨਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਪਹਿਲੀ ਡੈਮੋ ਇਕ ਹੋਰ ਸਪਸ਼ਟੀਕਰਨ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦੀ ਹੈ: “ਇਹ ਉਹ ਨਹੀਂ ਸੀ ਜੋ ਮੈਂ ਮੰਨਿਆ ਸੀ।” ਕੰਮ ਦੁਬਾਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬਦਲਾਅ ਚੁੱਪਚਾਪ ਵੱਡਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਡਿਜ਼ਾਈਨ ਦੇ ਝਟਕੇ ਕੋਡ ਬਦਲਾਅ ਲਿਆਉਂਦੇ ਹਨ, ਜੋ ਹੋਰ ਟੈਸਟਿੰਗ ਨੂੰ ਜਨਮ ਦਿੰਦੇ ਹਨ। ਰਿਵਿਊ ਸਲੋ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਕ ਧੁੰਦਲਾ ਬਦਲਾਅ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵੇਰਿਫਾਈ ਨਹੀਂ ਹੁੰਦਾ। ਜੇਕਰ ਕੋਈ “ਸਹੀ” ਦੀ ਪਰਿਭਾਸ਼ਾ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਤਾਂ ਰਿਵਿਊਅਰ ਬਿਹੇਵਿਯਰ ਬਾਰੇ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ ਕਰਨ ਲੱਗਦੇ ਹਨ ਨਾ ਕਿ ਗੁਣਵੱਤਾ ਜਾਂਚਣ।
ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਅਸਪਸ਼ਟ ਟਾਸਕ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਪਛਾਣ ਸਕਦੇ ਹੋ:
- ਕਿਸੇ ਕਦਮ-ਦਰ-ਕਦਮ ਉਦਾਹਰਨ ਦੀ ਘਾਟ (ਉਪਭੋਗਤਾ ਕੀ ਕਰ ਸਕੇਗਾ)
- ਕੋਈ ਐਡਜ ਕੇਸ ਨਹੀਂ (ਖਾਲੀ ਸਥਿਤੀਆਂ, ਪర్మਿਸ਼ਨ, ਐਰਰ)
- “ਜਰੂਰਤ-ਮੁਤਾਬਕ” ਕੰਮ ਜੋ ਵੱਡੇ PR ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦਾ ਹੈ
- ਰਿਵਿਊ ਟਿੱਪਣੀਆਂ ਵਰਤਾਵ ਬਾਰੇ बहਸ ਕਰਦੀਆਂ ਹਨ, ਨ ਕਿ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਬਾਰੇ
- “ਅਸੀਂ ਰਸਤੇ ਵਿੱਚ ਫੈਸਲਾ ਕਰ ਲਵਾਂਗੇ” ਯੋਜਨਾ ਬਣ ਜਾਂਦੀ ਹੈ
ਇੱਕ ਚੰਗਾ ਸਕੋਪ ਕੀਮਤੀ ਲਾਈਨ ਦਿੰਦਾ ਹੈ: ਸਾਫ਼ acceptance criteria, ਇੱਕ ਨ્યૂਨਤਮ UI ਅਤੇ API ਯੋਜਨਾ, ਅਤੇ ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਸ਼ਾਮਿਲ ਨਹੀਂ ਹਨ ਉਨ੍ਹਾਂ ਦੀਆਂ ਹੱਦਾਂ। ਇਹ ਫਰਕ ਹੈ “ਖੋਜ ਸੁਧਾਰੋ” ਅਤੇ ਇਕ ਛੋਟੇ ਬਦਲਾਅ ਵਿਚ ਜਿਸਨੂੰ ਬੰਨ੍ਹਨਾ ਅਤੇ ਰਿਵਿਊ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ।
ਇੱਕ ਵਿਹਾਰਕ ਆਦਤ: “definition of done” ਨੂੰ “nice-to-have” ਤੋਂ ਵੱਖਰਾ ਕਰੋ। “Done” ਜ਼ਿਆਦਾ ਨਹੀਂ—ਕੁਝ ਚੈਕਾਂ ਦੀ ਸੂਚੀ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਚਲਾ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ: “Search results title ਨਾਲ ਵਾਪਸ ਆਉਣ, ਖਾਲੀ ਹੋਣ 'ਤੇ ‘No results’ ਦਿਖਾਏ, ਅਤੇ query URL ਵਿੱਚ ਰਹੇ”)। “Nice-to-have” ਉਹ ਸਭ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਸਿਨੋਨਿਮ, ranking tweaks, highlighting, analytics). ਪਹਿਲਾਂ ਹੀ ਇਹਨਾਂ ਨੂੰ ਲੇਬਲ ਕਰਨ ਨਾਲ ਅਕਸਮਾਤੀ ਸਕੋਪ ਵਾਧੇ ਰੁਕਦੇ ਹਨ।
ਨਤੀਜੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਹੱਲ ਨਾਲ ਨਹੀਂ
ਅਸਪਸ਼ਟ ਬੇਨਤੀਆਂ ਅਕਸਰ ਸੁਝਾਵਾਂ ਵਜੋਂ ਆਉਂਦੀਆਂ ਹਨ: “ਇੱਕ ਬਟਨ ਜੋੜੋ,” “ਨਵਾਂ ਫਲੋ ਵਰਤੋ,” “ਵੱਖਰਾ ਮਾਡਲ ਵਰਤੋਂ।” ਰੁਕੋ ਅਤੇ ਪਹਿਲਾਂ ਸੁਝਾਅ ਨੂੰ ਨਤੀਜੇ ਵਿੱਚ ਬਦਲੋ।
ਇੱਕ ਸਧਾਰਨ ਫਾਰਮੈਟ ਮਦਦ ਕਰਦਾ ਹੈ: “As a [user], I want to [do something], so I can [reach a goal].” ਸਿੱਧਾ ਅਤੇ ਸਪਸ਼ਟ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਇਕ ਸਾਹ ਲੈ ਕੇ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਤਾਂ ਇਹ ਹਾਲੇ ਵੀ ਧੁੰਦਲਾ ਹੈ।
ਅਗਲਾ, ਵਰਣਨ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਲਈ ਕੀ ਬਦਲਿਆ ਜਾਵੇਗਾ ਜਦੋਂ ਕੰਮ ਖਤਮ ਹੋ ਜਾਵੇ। ਦਿੱਖਯੋਗ ਵਰਤਾਰ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਨ ਕੀ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਤੇ। ਉਦਾਹਰਨ: “ਫਾਰਮ ਜਮ੍ਹਾਂ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ ਇੱਕ ਪੁਸ਼ਟੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਅਤੇ ਮੈਂ ਨਵਾਂ ਰਿਕਾਰਡ ਲਿਸਟ ਵਿੱਚ ਲੱਭ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।” ਇਹ ਇੱਕ ਸਾਫ਼ ਖਤਮ-ਲਾਈਨ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ “ਹੋਰ ਇੱਕ ਛੋਟੀ ਟਵੀਕ” ਨੂੰ ਚੁਪਚਾਪ ਦਾਖਲ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਇਹ ਵੀ ਲਿਖੋ ਕਿ ਕੀ ਉਹੀ ਰਹੇਗਾ। Non-goals ਤੁਹਾਡੇ ਸਕੋਪ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ। ਜੇ ਬੇਨਤੀ “onboarding ਸੁਧਾਰੋ” ਹੈ, ਤਾਂ ਇੱਕ non-goal ਹੋ ਸਕਦਾ ਹੈ “ਕੋਈ dashboard redesign ਨਹੀਂ” ਜਾਂ “ਕੋਈ pricing-tier logic ਬਦਲਾਅ ਨਹੀਂ।”
ਅੰਤ ਵਿੱਚ, ਪਹਿਲਾਂ ਇਕ ਮੁੱਖ ਰਸਤਾ ਚੁਣੋ: ਉਹ ਇੱਕ end-to-end slice ਜੋ ਪਹਿਲਾਂ ਸਾਬਿਤ ਕਰੇ ਕਿ ਫੀਚਰ ਕੰਮ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਨ: “ਸਭ ਥਾਂ snapshots ਜੋੜਣ ਦੀ ਬਜਾਏ, ਲਿਖੋ: ‘As a project owner, I can restore the latest snapshot of my app, so I can undo a bad change.’ Non-goals: ‘no bulk restore, no UI redesign.’”
ਅਸਪਸ਼ਟਤਾ ਖਤਮ ਕਰਨ ਵਾਲੇ ਕੁਝ ਸਵਾਲ ਪੁੱਛੋ
ਇੱਕ ਅਸਪਸ਼ਟ ਬੇਨਤੀ ਅਕਸਰ ਜ਼ਰੂਰਤ ਦੀ ਘਾਟ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਫੈਸਲਿਆਂ ਦੀ ਘਾਟ ਹੁੰਦੀ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਉਹਨਾਂ ਪਾਬੰਦੀਆਂ ਨਾਲ ਜੋ ਸਕੋਪ ਨੂੰ ਚੁਪਕੇ ਨਾਲ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਡੇਡਲਾਈਨ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਐਕਸੇਸ ਨਿਯਮ ਅਤੇ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਕ ਐਸੇ ਪਲੈਟਫਾਰਮ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ ਜਿੱਥੇ ਟੀਅਰ ਅਤੇ ਰੋਲ ਹਨ, ਤਾਂ ਫੈਸਲਾ ਪਹਿਲਾਂ ਕਰੋ ਕਿ ਕੌਣ ਫੀਚਰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸ ਯੋਜਨਾ ਹੇਠ।
ਫਿਰ ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ ਮੰਗੋ। ਇੱਕ ਸਕਰੀਨਸ਼ਾਟ, ਇੱਕ ਮੁਕਾਬਲੇਦਾਰ ਦਾ ਵਿਵਹਾਰ, ਜਾਂ ਪਹਿਲੀ ਟਿਕਟ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ “ਬਿਹਤਰ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਜੇ ਰੀਕੁਏਸਟਰ ਕੋਲ ਕੁਝ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪਿਛਲੀ ਵਾਰ ਦਰਦ ਮਹਿਸੂਸ ਕਰਨ ਵਕਤ ਦੀ ਪੁਨਰਾਵਰਤੀ ਕਰਨ ਲਈ ਕਹੋ: ਉਹ ਕਿਸ ਸਕਰੀਨ ਉੱਤੇ ਸਨ, ਉਹ ਕੀ ਕਲਿੱਕ ਕੀਤਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਕੀ ਉਮੀਦ ਕੀਤੀ?
ਐਡਜ ਕੇਸ ਉਹ ਹਨ ਜਿੱਥੇ ਸਕੋਪ ਫੈਲਦਾ ਹੈ, ਇਸ ਲਈ ਵੱਡੇ ਕੇਸ ਪਹਿਲਾਂ ਨਾਮ ਕਰੋ: ਖਾਲੀ ਡਾਟਾ, validation errors, slow ਜਾਂ failed network calls, ਅਤੇ “undo” ਦਾ ਅਰਥ ਕੀ ਹੈ।
ਅਖੀਰਕਾਰ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਸਫਲਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋਗੇ। ਇਕ ਟੈਸਟਬਲ ਨਤੀਜੇ ਦੇ ਬਗੈਰ, ਟਾਸਕ ਰਾਏਆਂ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਹ ਪੰਜ ਸਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾਤਰ ਅਸਪਸ਼ਟਤਾ ਹਟਾ ਦਿੰਦੇ ਹਨ:
- ਕੌਣ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ (ਟੀਅਰ ਅਤੇ ਰੋਲ)?
- ਡੇਡਲਾਈਨ ਕੀ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਨਿੱਕੀ ਸੰਪੂਰਨ ਵਰਜ਼ਨ ਕੀ ਹੈ?
- ਉਮੀਦ ਕੀਤਾ ਵਿਹਾਰ ਦਾ ਇੱਕ ਉਦਾਹਰਨ ਕੀ ਹੈ?
- ਖਾਲੀ ਸਥਿਤੀਆਂ, ਐਰਰ, ਅਤੇ ਸਲੋ ਕਨੈਕਸ਼ਨ 'ਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?
- ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰਾਂਗੇ (ਪ੍ਰਮਾਣਿਤ ਮਾਪਦੰਡ ਜਾਂ ਮੈਟ੍ਰਿਕ)?
ਉਦਾਹਰਨ: “Add custom domains for clients” ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇਹ ਕਿਸ ਟੀਅਰ ਲਈ ਹੈ, ਕੌਣ ਸੈਟਅਪ ਕਰ ਸਕਦਾ ਹੈ, ਹੋਸਟਿੰਗ ਸਥਾਨ ਕੀ ਕੰਪਲਾਇੰਸ ਲਈ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ, invalid DNS ਲਈ ਕਿਹੜਾ ਐਰਰ ਦਿਖੇਗਾ, ਅਤੇ “done” ਦਾ ਕੀਮਤ ਕੀ ਹੈ (domain verified, HTTPS active, ਅਤੇ safe rollback ਯੋਜਨਾ)।
ਗੰਦੇ ਨੋਟਸ ਨੂੰ acceptance criteria ਵਿੱਚ ਬਦਲੋ
ਗੰਦੇ ਨੋਟਸ ਲਕ਼ਸ਼, ਅਨੁਮਾਨ, ਅਤੇ ਅਧ-ਯਾਦ ਕੀਤੀਆਂ ਐਡਜ ਕੇਸ ਨੂੰ ਮਿਲਾਉਂਦੇ ਹਨ। ਕੰਮ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਐਸੇ ਬਿਆਨਾਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾਵੇ ਜੋ ਕੋਈ ਵੀ ਕਿਸੇ ਦੇ ਮਨ ਨੂੰ ਪੜ੍ਹੇ ਬਿਨਾਂ ਟੈਸਟ ਕਰ ਸਕੇ। ਉਹੀ criteria design, coding, review, ਅਤੇ QA ਲਈ ਰਾਹ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਨ ਨਮੂਨਾ ਸਪਸ਼ਟ ਰੱਖਦਾ ਹੈ। ਤੁਸੀਂ Given/When/Then ਵਰਤ ਸਕਦੇ ਹੋ ਜਾਂ ਛੋਟੀਆਂ ਗੋਲੀਆਂ ਜੋ ਉਹੀ ਮਤਲਬ ਰੱਖਦੀਆਂ ਹਨ।
ਇੱਕ ਛੋਟੀ acceptance-criteria ਟੈਪਲੇਟ
ਹਰ criterion ਨੂੰ ਇੱਕ ਟੈਸਟ ਵਜੋਂ ਲਿਖੋ ਜੋ ਕੋਈ ਚਲਾ ਸਕਦਾ ਹੈ:
- Given ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ, when ਉਪਭੋਗਤਾ X ਕਰਦਾ/ਕਰਦੀ ਹੈ, then Y ਹੁੰਦਾ ਹੈ।
- validation rule ਸ਼ਾਮਲ ਕਰੋ (ਕਿਹੜੇ ਇਨਪੁੱਟ ਮਨਜ਼ੂਰ ਹਨ)।
- ਘੱਟੋ-ਘੱਟ ਇੱਕ failure case ਸ਼ਾਮਲ ਕਰੋ (ਉਪਭੋਗਤਾ ਨੂੰ ਕਿਹੜਾ ਐਰਰ ਦਿਖਾਈ ਦੇਵੇਗਾ)।
- “done signal” ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (QA چੈਕ ਕੀ ਹਨ, ਰਿਵਿਊਅਰ ਕੀ ਉਮੀਦ ਕਰਨਗੇ)।
ਹੁਣ ਇਸਨੂੰ ਲਾਗੂ ਕਰੋ। ਮੰਨ ਲਓ ਨੋਟ ਕਹਿੰਦਾ ਹੈ: “Snapshots ਆਸਾਨ ਬਣਾਓ। ਮੈਂ ਅਖੀਰਲੇ ਬਦਲਾਅ ਨੂੰ ਵਾਪਸ ਲੈਣਾ ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ ਹਾਂ ਜੇ ਉਹ ਤੋੜ ਦੇਵੇ।” ਇਸਨੂੰ ਟੈਸਟਬਲ ਬਿਆਨਾਂ ਵਿੱਚ ਬਦਲੋ:
- Given ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਜਿਸ ਵਿੱਚ 2 snapshots ਹਨ, when ਮੈਂ Snapshots ਖੋਲ੍ਹਦਾ/ਸਕਦੀ ਹਾਂ, then ਮੈਂ ਦੋਹਾਂ ਨੂੰ ਸਮਾਂ ਅਤੇ ਛੋਟਾ ਲੇਬਲ ਦੇ ਨਾਲ ਵੇਖਦਾ/ਦੇਖਦੀ ਹਾਂ।
- Given ਇੱਕ snapshot, when ਮੈਂ Roll back 'ਤੇ ਕਲਿੱਕ ਕਰਕੇ confirm ਕਰਦਾ/ਕਰਦੀ ਹਾਂ, then ਪ੍ਰੋਜੈਕਟ ਉਸ snapshot 'ਤੇ ਵਾਪਸ ਆ ਜਾਦਾ ਹੈ ਅਤੇ ਐਪ ਸਫਲਤਾਪੂਰਵਕ build ਹੁੰਦੀ ਹੈ।
- Given ਮੈਂ project owner ਨਹੀਂ ਹਾਂ, when ਮੈਂ roll back ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ, then ਮੈਨੂੰ ਇੱਕ ਐਰਰ ਦਿਖਾਈ ਦੇਂਦਾ ਹੈ ਅਤੇ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਹੁੰਦਾ।
- Given ਇੱਕ rollback ਚੱਲ ਰਿਹਾ ਹੈ, when ਮੈਂ ਪੇਜ refresh ਕਰਦਾ/ਕਰਦੀ ਹਾਂ, then ਮੈਂ ਹੁਣ ਵੀ status ਅਤੇ final result ਵੇਖ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।
- Given rollback fail ਹੋ ਜਾਂਦਾ ਹੈ, when ਉਹ ਰੁਕਦਾ ਹੈ, then ਮੈਨੂੰ ਇੱਕ ਸਾਫ਼ ਸੁਨੇਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ ਵਰਜ਼ਨ ਸਰਗਰਮ ਰਹਿੰਦਾ ਹੈ।
ਜੇ QA ਇਹਨਾਂ ਚੈਕਾਂ ਨੂੰ ਚਲਾ ਸਕਦੀ ਹੈ ਅਤੇ ਰਿਵਿਊਅਰ UI ਅਤੇ ਲੌਗਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ UI ਅਤੇ API ਕੰਮ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਛੋਟੇ ਕਮਿਟਾਂ ਵਿੱਚ ਵੰਡਣ ਲਈ ਤਿਆਰ ਹੋ।
ਇੱਕ ਨ્યૂਨਤਮ UI ਯੋਜਨਾ ਤਿਆਰ ਕਰੋ
ਇੱਕ ਨਿੂੰਨਤਮ UI ਯੋਜਨਾ ਇਕ ਵਾਅਦਾ ਹੈ: ਸਭ ਤੋਂ ਘੱਟ ਦਿੱਖਯੋਗ ਬਦਲਾਅ ਜੋ ਸਾਬਤ ਕਰੇ ਕਿ ਫੀਚਰ ਕੰਮ ਕਰਦਾ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਇਹ ਨਾਮ ਲਿਖ ਕੇ ਕਿ ਕਿਹੜੀਆਂ ਸਕ੍ਰੀਨਾਂ ਬਦਲਣਗੀਆਂ ਅਤੇ ਇਕ ਵਿਅਕਤੀ 10 ਸੈਕਿੰਡ ਵਿੱਚ ਕੀ ਨੋਟਿਸ ਕਰੇਗਾ। ਜੇ ਬੇਨਤੀ ਕਹਿੰਦੀ ਹੈ “ਇੱਕੋ-ਜਿਹੀ ਆਸਾਨ ਬਣਾਓ” ਜਾਂ “ਸਾਫ਼ ਕਰੋ,” ਤਾਂ ਉਸਨੂੰ ਇੱਕ ਨਿਰਧਾਰਿਤ ਬਦਲਾਅ ਵਿੱਚ ਤਰਜਮਾ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਨਿਸ਼ਾਨਾ ਬਣਾ ਸਕਦੇ ਹੋ।
ਇਸਨੂੰ ਇੱਕ ਛੋਟੀ ਮੈਪ ਵਜੋਂ ਲਿਖੋ, ਨਾ ਕਿ redesign। ਉਦਾਹਰਨ: “Orders page: add a filter bar above the table,” ਜਾਂ “Settings: add a new toggle under Notifications.” ਜੇ ਤੁਸੀਂ ਸਕ੍ਰੀਨ ਅਤੇ ਸਥਾਨਕ ਤੱਤ ਨਹੀਂ ਨਾਂਮਿਤ ਕਰ ਸਕਦੇ, ਤਾਂ ਸਕੋਪ ਹਾਲੇ ਵੀ ਅਸਪਸ਼ਟ ਹੈ।
ਮੁੱਖ UI ਸਥਿਤੀਆਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ
ਜ਼ਿਆਦਾਤਰ UI ਬਦਲਾਅਾਂ ਨੂੰ ਕੁਝ ਸਪੱਸ਼ਟ ਸਥਿਤੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਿਰਫ ਉਹਨਾਂ ਨੂੰ ਲਿਖੋ ਜੋ ਲਾਗੂ ਹੁੰਦੇ ਹਨ:
- Loading
- Empty
- Error (ਅਤੇ retry ਹੈ ਕਿ ਨਹੀਂ)
- Success (toast, inline message, updated list)
ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਜੋ ਸ਼ਬਦ ਦੇਖਣਗੇ ਉਹ ਪੁਸ਼ਟੀ ਕਰੋ
UI copy ਵੀ ਸਕੋਪ ਦਾ ਹਿੱਸਾ ਹੈ। ਉਹਨਾਂ ਲੇਬਲਾਂ ਅਤੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਕੈਪਚਰ ਕਰੋ ਜੋ ਮੰਨਜ਼ੂਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: button text, field labels, helper text, ਅਤੇ error messages। ਜੇ ਸ਼ਬਦ ਅਜੇ ਤੈਅ ਨਹੀਂ, ਤਾਂ ਉਸਨੂੰ placeholder ਕਾਪੀ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰੋ ਅਤੇ ਲੇਖਕ ਦਾ ਨਾਂ ਜਾਣੋ ਜੋ ਇਸਨੂੰ ਪੱਕਾ ਕਰੇਗਾ।
ਕੋਈ ਵੀ “ਹੁਣ ਨਹੀਂ” ਨੋਟ ਰੱਖੋ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਲਈ ਜੋ ਵਰਤੋਂ ਲਈ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹਨ (responsive polish, advanced sorting, animations, ਨਵੇਂ ਆਇਕਨ)।
ਇੱਕ ਨਿੂੰਨਤਮ API ਅਤੇ ਡਾਟਾ ਯੋਜਨਾ ਤਿਆਰ ਕਰੋ
Keep scope safe while iterating
Experiment safely with snapshots and rollback when a change goes sideways.
ਇੱਕ ਸਕੋਪਡ ਟਾਸਕ ਲਈ UI, ਬੈਕਐਂਡ, ਅਤੇ ਡਾਟਾ ਵਿਚਕਾਰ ਇੱਕ ਛੋਟੀ, ਸਾਫ਼ قرارداد ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਨਹੀਂ—ਇਹ ਸਭ ਤੋਂ ਘੱਟ ਕਾਲਾਂ ਅਤੇ ਫੀਲਡ ਜੋ ਫੀਚਰ ਸਾਬਤ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਹਨ, ਉਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਲਿਸਟ ਕਰਨ ਨਾਲ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜਾ ਡੇਟਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹ ਕਿੱਥੋਂ ਆਵੇਗਾ: ਉਪਲਬਧ ਫੀਲਡ ਜੋ ਤੁਸੀਂ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਨਵੀਆਂ ਫੀਲਡਾਂ ਜੋ ਸਟੋਰ ਕਰਨੀਆਂ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਮੁੱਲ ਤੁਸੀਂ ਕੈਲਕੁਲੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਹਰ ਫੀਲਡ ਲਈ ਸਰੋਤ ਨਹੀਂ ਨਾਂਮ ਦੇ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਯੋਜਨਾ ਨਹੀਂ ਹੈ।
API ਸਰਫੇਸ ਨਿੂੰਨਤਮ ਰੱਖੋ। ਕਈ ਫੀਚਰਾਂ ਲਈ ਇੱਕ read ਅਤੇ ਇੱਕ write ਕਾਫੀ ਹੁੰਦੇ ਹਨ:
GET /items/{id}returns the state needed to render the screenPOST /items/{id}/updateaccepts only what the user can change and returns the updated state
Inputs ਅਤੇ outputs ਨੂੰ ਸਪੱਸ਼ਟ ਆਬਜੈਕਟਾਂ ਵਜੋਂ ਲਿਖੋ, ਨ ਕਿ ਪੈਰਾਗ੍ਰਾਫਾਂ ਵਜੋਂ। Required vs optional ਫੀਲਡਾਂ ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਆਮ ਐਰਰਾਂ (not found, validation failed) 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਇਹ ਉੱਤੇ ਦਰਸਾਓ।
ਡੇਟਾਬੇਸ ਨੂੰ ਛੁਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ quick auth pass ਕਰੋ। ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੌਣ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਅਤੇ ਕੌਣ ਲਿਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਨਿਯਮ ਇਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ (ਉਦਾਹਰਨ: “any signed-in user can read, only admins can write”). ਇਹ ਛੱਡਣਾ ਅਕਸਰ ਦੁਬਾਰਾ ਕੰਮ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ।
ਅਖੀਰ ਵਿੱਚ, ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕੀ ਕੈਲਕੁਲੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: facts ਸਟੋਰ ਕਰੋ, views ਨੂੰ compute ਕਰੋ।
Claude Code ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਕੋਪਡ ਟਾਸਕ ਬਣਾਓ
Claude Code ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਸਨੂੰ ਇੱਕ ਸਾਫ਼ ਟਾਰਗੇਟ ਅਤੇ ਇਕ ਤੰਗ ਬਾਕਸ ਦਿੰਦੇ ਹੋ। ਗੰਦੀ ਬੇਨਤੀ ਅਤੇ ਕਿਸੇ ਵੀ ਪਾਬੰਦੀਆਂ (ਡੇਡਲਾਈਨ, ਪ੍ਰਭਾਵਤ ਯੂਜ਼ਰ, ਡਾਟਾ ਨਿਯਮ) ਨੂੰ ਪੇਸਟ ਕਰੋ। ਫਿਰ ਇੱਕ ਸਕੋਪਡ ਆਉਟਪੁੱਟ ਮੰਗੋ ਜੋ ਇਹ ਸ਼ਾਮਲ ਹੋਵੇ:
- ਇੱਕ ਸਧਾਰਨ-ਭਾਸ਼ਾ ਵਿੱਚ ਸਕੋਪ ਦਾ पुनਰਕਥਨ ਅਤੇ ਇੱਕ acceptance-criteria ਚੈੱਕਲਿਸਟ।
- 3 ਤੋਂ 7 ਛੋਟੇ ਕਮਿਟਾਂ ਦੀ ਲੜੀ, ਹਰ ਇਕ ਨਾਲ ਇੱਕ ਸਪੱਸ਼ਟ ਨਤੀਜਾ।
- ਹਰ ਕਮਿਟ ਲਈ ਸੰਭਾਵੀ ਫਾਈਲਾਂ ਜਾਂ ਫੋਲਡਰ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚ ਕੀ ਬਦਲਿਆ ਜਾਵੇਗਾ।
- ਹਰ ਕਮਿਟ ਲਈ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਪਲੈਨ (ਇੱਕ ਖੁਸ਼-ਪਾਥ ਅਤੇ ਇਕ ਐਡਜਕੇਸ)।
- ਸਪਸ਼ਟ out-of-scope ਨੋਟਸ।
ਜਦੋਂ ਇਹ ਜਵਾਬ ਦੇਵੇ, ਉਸਨੂੰ ਰਿਵਿਊਅਰ ਵਾਂਗ ਪੜ੍ਹੋ। ਜੇ ਤੁਸੀਂ “improve performance” ਜਾਂ “make it cleaner” ਵਰਗੇ ਫਰੇਜ਼ ਵੇਖਦੇ ਹੋ, ਤਾਂ ਮਾਪਯੋਗ ਸ਼ਬਦਾਂ ਲਈ ਪੁੱਛੋ।
ਛੋਟਾ ਉਦਾਹਰਨ (ਛੰਗਾ ਕੀ ਦਿੱਸਦਾ ਹੈ)
Request: “Add a way to pause a subscription.”
A scoped version might say: “User can pause for 1 to 3 months; next billing date updates; admin can see pause status,” and out of scope: “No proration changes.”
ਇੱਥੋਂ, commit ਯੋਜਨਾ ਵਿਵਹਾਰਿਕ ਬਣ ਜਾਂਦੀ ਹੈ: DB ਅਤੇ API shape ਲਈ ਇੱਕ ਕਮਿਟ, UI control ਲਈ ਇੱਕ, validation ਅਤੇ error states ਲਈ ਇੱਕ, end-to-end tests ਲਈ ਇੱਕ।
ਕੰਮ ਨੂੰ ਛੋਟੇ, reviewable ਕਮਿਟਾਂ ਵਿੱਚ ਵੰਡੋ
Make UI states explicit
Translate outcomes into real UI states: loading, empty, error, and success.
ਵੱਡੇ ਬਦਲਾਅ ਬੱਗ ਛੁਪਾਉਂਦੇ ਹਨ। ਛੋਟੇ ਕਮਿਟ ਰਿਵਿਊਜ਼ ਤੇਜ਼ ਬਣਾਉਂਦੇ ਹਨ, ਰੋਲਬੈਕ ਸੁਰੱਖਿਅਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਤੁਹਾਨੂੰ ਨੋਟਿਸ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ acceptance criteria ਤੋਂ ਭਟਕਦੇ ਹੋ।
ਇੱਕ ਉਪਯੋਗ ਨਿਯਮ: ਹਰ ਕਮਿਟ ਨੂੰ ਇੱਕ ਨਵਾਂ ਵਿਹਾਰ ਅਨਲੌਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਪ੍ਰਮਾਣ ਦਿਖਾਉਣ ਲਈ ਇਕ ਛੋਟੀ ਜਹੀ ਪ੍ਰੂਫ਼ ਰਾਹ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਆਮ ਕ੍ਰਮ ਇਹ ਹੋ ਸਕਦਾ ਹੈ:
- Data model ਜਾਂ migration (ਜੇ ਲੋੜ ਹੋਵੇ) ਨਾਲ tests
- API ਵਿਹਾਰ ਅਤੇ validation
- UI wiring ਨਾਲ empty ਅਤੇ error states
- ਲਾਜ਼ਮੀ ਹੋਵੇ ਤਾਂ logging ਜਾਂ analytics, ਫਿਰ ਛੋਟਾ polish
ਹਰ ਕਮਿਟ ਨੂੰ ਕੇਵਲ ਇੱਕ ਫੋਕਸ ਰੱਖੋ। “While I was here” refactors ਤੋਂ ਬਚੋ। ਐਪ ਨੂੰ end-to-end ਕੰਮ ਕਰਦਾ ਰੱਖੋ, ਚਾਹੇ UI ਬੁਨਿਆਦੀ ਹੋਵੇ। migrations, behavior, ਅਤੇ UI ਨੂੰ ਇੱਕ ਕਮਿਟ ਵਿੱਚ ਪੈਕ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਮਜਬੂਤ ਕਾਰਨ ਨਾ ਹੋਵੇ।
Walkthrough: “Export reports”
Stakeholder ਕਹਿੰਦਾ ਹੈ: “Can we add Export reports?” ਇਹ ਕਈ ਚੋਣਾਂ ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ: ਕਿਹੜਾ ਰਿਪੋਰਟ, ਕਿਸ ਫਾਰਮੈਟ, ਕੌਣ export ਕਰ ਸਕਦਾ, ਅਤੇ delivery ਕਿਵੇਂ ਹੋਵੇगी।
ਉਹੀ ਸਵਾਲ ਹੀ ਪੁੱਛੋ ਜੋ ਡਿਜ਼ਾਈਨ ਬਦਲ ਦਿੰਦੇ ਹਨ:
- v1 ਲਈ ਕਿਹੜੇ report types ਸ਼ਾਮਲ ਹਨ?
- v1 ਲਈ ਕਿਹੜਾ ਫਾਰਮੈਟ ਲੋੜੀਂਦਾ ਹੈ (CSV, PDF)?
- ਕੌਣ export ਕਰ ਸਕਦਾ (admins, specific roles)?
- direct download ਜਾਂ emailed export?
- ਕੋਈ limits (date range max, row count cap, timeouts)?
ਮੰਨ ਲਓ ਜਵਾਬ ਹਨ: “Sales Summary report, CSV only, manager role, direct download, last 90 days max.” ਹੁਣ v1 acceptance criteria ਸਪਸ਼ਟ ਹੈ: ਮੈਨੇਜਰ Sales Summary ਪੇਜ 'ਤੇ Export 'ਤੇ ਕਲਿੱਕ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹੈ; CSV on-screen table columns ਨੂੰ ਮਿਲਦਾ ਹੈ; export ਮੌਜੂਦਾ filters ਨੂੰ ਮੰਨਦਾ ਹੈ; 90 ਦਿਨਾਂ ਤੋਂ ਵੱਧ export ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ 'ਤੇ ਸਾਫ਼ ਐਰਰ ਦਿਖਦਾ ਹੈ; 50k rows ਤੱਕ 30 ਸਕਿੰਟ ਵਿੱਚ download ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਨਿੂੰਨਤਮ UI ਯੋਜਨਾ: table actions ਕੋਲ ਇੱਕ Export button, generate ਹੋਣ ਦੌਰਾਨ loading state, ਅਤੇ ਐਰਰ ਸੁਨੇਹਾ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿਵੇਂ مسئلہ ਹੱਲ ਕਰਨਾ ਹੈ (ਜਿਵੇਂ “Choose 90 days or less”)।
ਨਿੂੰਨਤਮ API ਯੋਜਨਾ: ਇੱਕ endpoint ਜੋ filters ਲੈਂਦਾ ਹੈ ਅਤੇ generated CSV ਨੂੰ file response ਵਜੋਂ ਵਾਪਸ ਕਰਦਾ ਹੈ, table ਵਾਲੀ query ਨੂੰ reuse ਕਰਦਾ ਹੈ ਅਤੇ 90-day rule server-side ਲਾਗੂ ਕਰਦਾ ਹੈ।
ਫਿਰ ਇਸਨੂੰ ਕੁਝ ਤੰਗ ਕਮਿਟਾਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰੋ: ਪਹਿਲਾਂ fixed happy path ਲਈ endpoint, ਫਿਰ UI wiring, ਫਿਰ validation ਅਤੇ user-facing errors, ਫਿਰ tests ਅਤੇ documentation।
ਆਮ ਸਕੋਪਿੰਗ ਦੀਆਂ ਗਲਤੀਆਂ (ਅਤੇ ਕਿਵੇਂ ਬਚਣਾ)
Hidden requirements sneak in
“Add team roles” ਵਰਗੀਆਂ ਬੇਨਤੀਆਂ ਅਕਸਰ invite, edit, ਅਤੇ ਮੌਜੂਦਾ ਯੂਜ਼ਰਾਂ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਬਾਰੇ ਨਿਯਮ ਲੁਕਾਉਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਅਨੁਮਾਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਅਨੁਮਾਨ ਲਿਖੋ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਸਵਾਲ ਜਾਂ ਸਪਸ਼ਟ ਨਿਯਮ ਬਣਾਓ।
UI polish core behavior ਦੇ ਨਾਲ ਮਿਲ ਜਾਂਦਾ ਹੈ
ਟੀਮਾਂ ਦਿਨ ਲੁੱਟ ਦਿੰਦੀਆਂ ਹਨ ਜਦੋਂ ਇੱਕ ਟਾਸਕ ਵਿੱਚ “ਕੰਮ ਕਰੋ” ਅਤੇ “ਸੁੰਦਰ ਬਣਾਓ” ਦੋਹਾਂ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਪਹਿਲਾ ਟਾਸਕ ਵਿਹਾਰ ਅਤੇ ਡਾਟਾ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਰੱਖੋ। styling, animations, ਅਤੇ spacing ਨੂੰ follow-up ਟਾਸਕ ਵਿੱਚ ਰੱਖੋ ਜੇ ਲੋੜ ਨਾ ਹੋਵੇ।
ਤੁਸੀਂ v1 ਵਿੱਚ ਹਰ ਐਡਜ ਕੇਸ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ
ਐਡਜ ਕੇਸ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਪਰ ਸਾਰੇ ਇਨ੍ਹਾਂ ਨੂੰ turant ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਹੱਲ ਕਰੋ ਜੋ ਭਰੋਸਾ ਤੋੜ ਸਕਦੇ ਹਨ (double submits, conflicting edits) ਅਤੇ ਬਾਕੀ ਨੂੰ clear notes ਨਾਲ ਦੇਰ ਕਰੋ।
Error states ਅਤੇ permissions ਨੂੰ “ਬਾਅਦ” ਲਈ ਰੱਖ ਦਿਓ
ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਲਿਖ ਕੇ ਨਹੀਂ ਰੱਖਦੇ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ। acceptance criteria ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ unhappy path ਅਤੇ ਇੱਕ permission rule ਸ਼ਾਮਲ ਕਰੋ।
Criteria ਜੋ ਤੁਸੀਂ verify ਨਹੀਂ ਕਰ ਸਕਦੇ
“Fast” ਜਾਂ “intuitive” ਵਰਗੇ ਸ਼ਬਦਾਂ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਨੰਬਰ ਜਾਂ concrete check ਨਾ ਲਗਾਉ। ਉਹਨਾਂ ਨੂੰ ਕਿਸੇ ਐਸੇ ਬਿਆਨ ਨਾਲ ਬਦਲੋ ਜਿਨ੍ਹਾਂ ਦੀ ਰਿਵਿਊ ਵਿੱਚ ਪੁਸ਼ਟੀ ਹੋ ਸਕੇ।
ਕੋਡਿੰਗ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ
Lock the plan first
Use Planning Mode to define outcomes, non-goals, and a small commit sequence.
ਟਾਸਕ ਨੂੰ ਇਸ ਹੱਦ ਤੱਕ ਪੱਕਾ ਕਰੋ ਕਿ ਕੋਈ teammate ਬਿਨਾਂ ਮਨ-ਪੜ੍ਹਾਈ ਦੇ ਰਿਵਿਊ ਅਤੇ ਟੈਸਟ ਕਰ ਸਕੇ:
- Outcome ਅਤੇ non-goals: ਇੱਕ ਵਾਕ ਵਿੱਚ outcome, ਅਤੇ 1-3 ਸਪਸ਼ਟ non-goals।
- Acceptance criteria: 5-10 ਟੈਸਟੇਬਲ ਚੈਕਸ plain language ਵਿੱਚ।
- UI states: ਨਾਮਮਾਤਰ loading, empty, error, ਅਤੇ success states।
- API ਅਤੇ ਡਾਟਾ ਨੋਟਸ: ਸਭ ਤੋਂ ਘੱਟ endpoint shape ਅਤੇ ਕੋਈ ਡਾਟਾ ਬਦਲਾਅ, ਅਤੇ ਕੌਣ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਸਕਦਾ ਹੈ।
- Commit plan with tests: 3-7 commits, ਹਰ ਇੱਕ ਇੱਕ quick proof ਨਾਲ।
ਉਦਾਹਰਨ: “Add saved searches” ਬਣ ਜਾਂਦਾ ਹੈ “Users can save a filter and reapply it later,” non-goals ਜਿਵੇਂ “no sharing” ਅਤੇ “no sorting changes.”
ਅਗਲੇ ਕਦਮ: ਬਣਾਉਂਦੇ ਸਮੇਂ ਸਕੋਪ ਸਥਿਰ ਰੱਖੋ
ਇੱਕ ਵਾਰ ਤੁਹਾਡੇ ਕੋਲ ਸਕੋਪਡ ਟਾਸਕ ਹੋਵੇ, ਉਸ ਦੀ ਰੱਖਿਆ ਕਰੋ। ਕੋਡਿੰਗ ਤੋਂ ਪਹਿਲਾਂ, ਜੋ ਲੋਕ ਬਦਲਾਅ ਮੰਗਿਆ ਉਹਨਾਂ ਨਾਲ ਇਕ quick sanity review ਕਰੋ:
- Acceptance criteria ਪੜ੍ਹੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ outcome ਨਾਲ ਮਿਲਦਾ ਹੈ।
- Permissions, empty states, ਅਤੇ failure behaviour ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
- Out of scope ਨੂੰ ਦੁਬਾਰਾ ਪੁਸ਼ਟੀ ਕਰੋ।
- ਉਹ ਸਭ ਤੋਂ ਛੋਟੇ UI ਅਤੇ API ਬਦਲਾਅ ਤੇ ਸਹਿਮਤ ਹੋ ਜਿਨ੍ਹਾਂ ਨਾਲ criteria ਮਿਲਦੇ ਹਨ।
- ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ demo ਕਰੋਂਗੇ ਅਤੇ “done” ਕਿਸ ਤਰ੍ਹਾਂ ਲੱਗੇਗਾ।
ਫਿਰ criteria ਨੂੰ ਉਸੇ ਥਾਂ ਸੰਭਾਲੋ ਜਿੱਥੇ ਕੰਮ ਹੁੰਦਾ ਹੈ: ticket ਵਿੱਚ, PR description ਵਿੱਚ, ਅਤੇ ਜਿੱਥੇ ਵੀ ਟੀਮ ਅਸਲ ਵਿੱਚ ਵੇਖਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪਲੇਨਿੰਗ ਪਹਲਾਂ ਲਾਕ ਕਰੋ ਅਤੇ ਫਿਰ ਕੋਡ ਜੀਨਰੇਟ ਕਰੋ। Planning Mode ਇਸ ਵਰਕਫਲੋ ਲਈ ਚੰਗੀ ਫਿਟ ਹੈ, ਅਤੇ snapshots ਅਤੇ rollback ਐਸਪੈਰੀਮੈਂਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਨੂੰ ਕਿਸੇ ਤਰੀਕੇ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ ਅਤੇ ਵਾਪਸ ਲੈਣਾ ਪਵੇ।
ਜਦੋਂ ਨਵੇਂ ਵਿਚਾਰ ਦੌਰਾਨ-ਨਿਰਮਾਣ ਆਉਂਦੇ ਹਨ, ਸਕੋਪ ਸਥਿਰ ਰੱਖੋ: ਉਹਨਾਂ ਨੂੰ follow-up ਸੂਚੀ ਵਿੱਚ ਲਿਖੋ, ਜੇ ਉਹ acceptance criteria ਨੂੰ ਬਦਲਦੇ ਹਨ ਤਾਂ ਰੀ-ਸਕੋਪ ਕਰਨ ਲਈ ਰੁਕੋ, ਅਤੇ ਕਮਿਟਾਂ ਨੂੰ ਹਰ ਵਾਰੀ ਇੱਕ criterion ਨਾਲ ਜੋੜਕੇ ਰੱਖੋ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
How do I know a feature request is too vague to start building?
Start by writing the outcome in one sentence (what the user can do when it’s done), then add 3–7 acceptance criteria that a tester can verify.
If you can’t describe the “correct” behavior without debating it, the task is still vague.
What’s the fastest way to turn “do X better” into a clear outcome?
Use this quick format:
- As a [user]
- I want to [action]
- So I can [goal]
Then add one concrete example of the expected behavior. If you can’t give an example, replay the last time the problem happened and write what the user clicked and expected to see.
How should I separate “done” from “nice-to-have” without arguing for days?
Write a short “Definition of done” list first (the checks that must pass), then a separate “Nice-to-have” list.
Default rule: if it’s not needed to prove the feature works end-to-end, it goes into nice-to-have.
What questions remove the most ambiguity early?
Ask the few questions that change scope:
- Who gets access (tier and roles)?
- What’s the deadline, and what’s the smallest acceptable version?
- What’s one example of expected behavior?
- What happens on empty states, errors, and slow connections?
- How will we confirm it works (criteria or a metric)?
These force the missing decisions into the open.
Which edge cases should I include in v1 acceptance criteria?
Treat edge cases as scope items, not surprises. For v1, cover the ones that break trust:
- Empty state
- Validation errors
- Permission denied
- Network/API failures
- “Undo” or rollback behavior (if relevant)
Anything else can be explicitly deferred as out-of-scope notes.
What does good acceptance criteria look like in practice?
Use testable statements anyone can run without guessing:
- Given a starting state
- When the user does X
- Then Y happens
Include at least one failure case and one permission rule. If a criterion can’t be tested, rewrite it until it can.
How minimal should a UI plan be for a scoped task?
Name the exact screens and the one visible change per screen.
Also list the required UI states:
- Loading
- Empty
- Error (and whether retry exists)
- Success (toast/message/updated list)
Keep copy (button text, errors) in scope too, even if it’s placeholder text.
What’s the simplest way to draft an API/data plan without over-designing?
Keep the contract small: usually one read and one write is enough for v1.
Define:
- Inputs/outputs as plain objects (required vs optional fields)
- Common errors (not found, validation failed)
- Auth rule in one sentence (who can read/write)
Store facts; compute views when possible.
How should I prompt Claude Code to produce a scoped task and commit plan?
Ask for a boxed deliverable:
- Restated scope + acceptance checklist
- 3–7 commits, each unlocking one behavior
- Likely files touched per commit
- Quick test plan (happy path + one edge)
- Explicit out-of-scope list
Then re-prompt any vague wording like “make it cleaner” into measurable behavior.
How do I split a feature into small commits that are easy to review?
Default sequence:
- Data/model change (if needed) + tests
- API behavior + validation
- UI wiring with empty/error states
- Final polish only if required
Rule of thumb: one commit = one new user-visible behavior + a quick way to prove it works. Avoid bundling “while I’m here” refactors into the feature commits.