ಬಳಕೆದಾರ ಕಥೆಗಳನ್ನು ಬರೆಯುವುದು ಹೇಗೆ (ಉದಾಹರಣೆಗಳು ಮತ್ತು ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳೊಂದಿಗೆ)

ಬಳಕೆದಾರ ಕಥೆ ಎಂದರೆ ಬಳಕೆದಾರರ ದೃಷ್ಟಿಯಿಂದ ಒಂದು ವೈಶಿಷ್ಟ್ಯದ ಸಣ್ಣ ವಿವರಣೆ: "[ಬಳಕೆದಾರರ ಪ್ರಕಾರ]ನಾಗಿ, ನಾನು [ಗುರಿ] ಬಯಸುತ್ತೇನೆ, ಇದರಿಂದ [ಕಾರಣ]." ಅದರ ಕೆಳಗೆ ನೀವು ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳನ್ನು ಬರೆಯುತ್ತೀರಿ, ಅಂದರೆ ಕಥೆ ಪೂರ್ಣವೆಂದು ಪರಿಗಣಿತವಾಗಲು ನಿಜವಾಗಿರಬೇಕಾದ ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಷರತ್ತುಗಳು. ಪ್ರತಿ ಕಥೆಯನ್ನು ಒಂದೇ ಬಾರಿಗೆ ನಿರ್ಮಿಸಿ ಪರೀಕ್ಷಿಸುವಷ್ಟು ಚಿಕ್ಕದಾಗಿಡಿ, ಮತ್ತು ಯಾರಾದರೂ ಪರಿಶೀಲಿಸಬಹುದಾದಂತೆ ಮಾನದಂಡಗಳನ್ನು ಬರೆಯಿರಿ.

ಬಳಕೆದಾರ ಕಥೆಗಳು ಚುರುಕು (agile) ಸಾಫ್ಟ್‌ವೇರ್ ತಂಡಗಳ ಮೂಲಕ ಜನಪ್ರಿಯವಾದವು, ಆದರೆ AI ಆಪ್ ಬಿಲ್ಡರ್ ಬಳಸಿ ನೀವೇ ನಿರ್ಮಿಸುವಾಗಲೂ ಅವು ಅಷ್ಟೇ ಉಪಯುಕ್ತ. ಒಳ್ಳೆಯ ಕಥೆ ಒಳ್ಳೆಯ ಪ್ರಾಂಪ್ಟ್ ಕೂಡ.

ಸ್ವರೂಪ

ಬಳಕೆದಾರ ಕಥೆಗೆ ಮೂರು ಭಾಗಗಳಿವೆ:

ನಾನು [ಯಾರು] ಆಗಿ, ನಾನು ಬಯಸುತ್ತೇನೆ [ಏನು] ಇದರಿಂದ [ಏಕೆ].

• ಯಾರು ಎಂಬುದು ನಿರ್ದಿಷ್ಟ ಬಗೆಯ ಬಳಕೆದಾರ: ಮೊದಲ ಬಾರಿ ಭೇಟಿ ನೀಡುವವರು, ಪಾವತಿಸುವ ಸದಸ್ಯರು, ಕ್ಲಿನಿಕ್ ಸ್ವಾಗತಕಾರರು, ನಿರ್ವಾಹಕರು. "ಬಳಕೆದಾರ" ಎಂದಲ್ಲ.
• ಏನು ಎಂಬುದು ಅವರು ಮಾಡಲು ಬಯಸುವ ಕೆಲಸ, ಅವರದೇ ಮಾತುಗಳಲ್ಲಿ. ಪರದೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದಲ್ಲ.
• ಏಕೆ ಎಂಬುದು ಅವರಿಗೆ ಮುಖ್ಯವಾದ ಫಲಿತಾಂಶ. ಇದನ್ನು ಜನರು ಬಿಟ್ಟುಬಿಡುತ್ತಾರೆ, ಮತ್ತು ಇದೇ ತಪ್ಪಾದದ್ದನ್ನು ನಿರ್ಮಿಸದಂತೆ ತಡೆಯುತ್ತದೆ.

ಉದಾಹರಣೆ:

ಒಬ್ಬ ಜಿಮ್ ಸದಸ್ಯನಾಗಿ, ನಾನು ತರಗತಿ ಬುಕಿಂಗ್ ಅನ್ನು ನನ್ನ ಫೋನಿನಿಂದ ರದ್ದುಗೊಳಿಸಲು ಬಯಸುತ್ತೇನೆ, ಇದರಿಂದ ವೇಟ್‌ಲಿಸ್ಟ್‌ನಲ್ಲಿರುವ ಯಾರಾದರೂ ನನ್ನ ಸ್ಥಾನ ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ನನಗೆ ಗೈರುಹಾಜರಿ ಶುಲ್ಕ ವಿಧಿಸಲಾಗುವುದಿಲ್ಲ.

"ಏಕೆ" ಭಾಗ "ಏನು" ಭಾಗ ಹೇಳದ ಎರಡು ವಿಷಯಗಳನ್ನು ಹೇಳುತ್ತದೆ: ಇದು ಫೋನಿನಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕು, ಮತ್ತು ವೇಟ್‌ಲಿಸ್ಟ್ ಹಾಗೂ ಶುಲ್ಕದ ನಿಯಮಗಳು ಒಳಗೊಂಡಿವೆ.

ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು

ಕಥೆ ಏನು ಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ. ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು ಅದು ಯಾವಾಗ ಪೂರ್ಣ ಎಂದು ಹೇಳುತ್ತವೆ. ಪ್ರತಿಯೊಂದು ಮಾನದಂಡ ಪಾಸ್ ಆಗಿದೆಯೇ ಇಲ್ಲವೇ ಎಂದು ಇಬ್ಬರು ವ್ಯಕ್ತಿಗಳು ಒಪ್ಪುವಷ್ಟು ನಿರ್ದಿಷ್ಟವಾಗಿರಬೇಕು.

ಇವನ್ನು ಬರೆಯಲು ಸಾಮಾನ್ಯ ದಾರಿ Given / When / Then:

• Given ಆರಂಭದ ಸ್ಥಿತಿ
• When ಬಳಕೆದಾರ ಏನನ್ನಾದರೂ ಮಾಡಿದಾಗ
• Then ಇದು ಫಲಿತಾಂಶ

ಜಿಮ್ ಬುಕಿಂಗ್ ಕಥೆಗೆ:

1. Given ನನ್ನ ಬುಕಿಂಗ್ 12 ಗಂಟೆಗಳಿಗಿಂತ ದೂರದಲ್ಲಿದ್ದರೆ, when ನಾನು Cancel ಒತ್ತಿ ದೃಢಪಡಿಸಿದಾಗ, then ಬುಕಿಂಗ್ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು "ಬುಕಿಂಗ್ ರದ್ದುಗೊಳಿಸಲಾಗಿದೆ" ಎಂದು ತೋರಿಸುತ್ತದೆ.
2. Given ನಾನು ಬುಕಿಂಗ್ ರದ್ದುಗೊಳಿಸಿದ್ದು ಮತ್ತು ತರಗತಿಗೆ ವೇಟ್‌ಲಿಸ್ಟ್ ಇದ್ದರೆ, when ರದ್ದತಿ ಉಳಿತಾಯವಾದಾಗ, then ವೇಟ್‌ಲಿಸ್ಟ್‌ನಲ್ಲಿ ಮೊದಲಿರುವ ವ್ಯಕ್ತಿಗೆ ಸ್ಥಾನ ಮತ್ತು ಇಮೇಲ್ ಸಿಗುತ್ತದೆ.
3. Given 12 ಗಂಟೆಗಳಿಗಿಂತ ಕಡಿಮೆ ದೂರದ ಬುಕಿಂಗ್ ಇದ್ದರೆ, when ನಾನು Cancel ಒತ್ತಿದಾಗ, then ದೃಢಪಡಿಸುವ ಮೊದಲು ತಡವಾದ ರದ್ದತಿ ಶುಲ್ಕ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸಲಾಗುತ್ತದೆ.
4. Given ನಾನು ಫೋನ್ ಅಗಲದ ಪರದೆಯಲ್ಲಿದ್ದರೆ, then Cancel ಬಟನ್ ಬದಿಗೆ ಸ್ಕ್ರಾಲ್ ಮಾಡದೆ ಕಾಣಿಸುತ್ತದೆ.

ಸರಳ ಪರಿಶೀಲನಾ ಪಟ್ಟಿಯೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಪ್ರತಿ ಅಂಶ ಪರೀಕ್ಷಿಸಬಹುದಾದರೆ. "ರದ್ದುಗೊಳಿಸುವುದು ಸುಲಭ" ಪರೀಕ್ಷಿಸಲಾಗುವುದಿಲ್ಲ. "ಬುಕಿಂಗ್ ಪಟ್ಟಿಯಿಂದ ರದ್ದತಿಗೆ ಗರಿಷ್ಠ ಎರಡು ಟ್ಯಾಪ್" ಪರೀಕ್ಷಿಸಬಹುದು.

ಹಂತ ಹಂತವಾಗಿ: ಒಳ್ಳೆಯ ಕಥೆ ಬರೆಯುವುದು

ಹಂತ 1: ನಿಜವಾದ ಬಳಕೆದಾರ ಮತ್ತು ನಿಜವಾದ ಸಮಸ್ಯೆಯಿಂದ ಆರಂಭಿಸಿ

ಒಂದು ಬಗೆಯ ಬಳಕೆದಾರ ಮತ್ತು ಇಂದು ಅವರಿಗೆ ಕಷ್ಟವಾಗುವ ಒಂದು ವಿಷಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ. ನೀವು ಗ್ರಾಹಕರ ಸಂದರ್ಶನಗಳನ್ನು ಮಾಡಿದ್ದರೆ, ಅವರ ಮಾತುಗಳನ್ನೇ ಬಳಸಿ. "ನಾನು ಯಾವಾಗಲೂ ರದ್ದುಗೊಳಿಸಲು ಮರೆತು ಶುಲ್ಕ ವಿಧಿಸಲ್ಪಡುತ್ತೇನೆ" ಎನ್ನುವುದು "ರದ್ದತಿ ವೈಶಿಷ್ಟ್ಯ ಸೇರಿಸಿ" ಎನ್ನುವುದಕ್ಕಿಂತ ಉತ್ತಮ ಆರಂಭ.

ಹಂತ 2: ಒಂದು ಸಾಲಿನ ಕಥೆ ಬರೆಯಿರಿ

ಟೆಂಪ್ಲೇಟ್ ತುಂಬಿರಿ. ನಂಬಲರ್ಹವಾದ "ಇದರಿಂದ" ಭಾಗ ಬರೆಯಲಾಗದಿದ್ದರೆ, ಆ ವೈಶಿಷ್ಟ್ಯ ನಿಜವಾಗಿ ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ಕೇಳಿಕೊಳ್ಳಿ.

ಹಂತ 3: ಮೂರರಿಂದ ಆರು ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳನ್ನು ಸೇರಿಸಿ

ಮೊದಲು ಮುಖ್ಯ ಯಶಸ್ಸಿನ ಪ್ರಕರಣವನ್ನು ಒಳಗೊಳ್ಳಿ, ನಂತರ ಮುಖ್ಯ ವ್ಯತ್ಯಾಸಗಳನ್ನು: ಬೇರೆ ಪಾತ್ರ, ಖಾಲಿ ಸ್ಥಿತಿ, ಮಿತಿ, ದೋಷ. ಆರಕ್ಕಿಂತ ಹೆಚ್ಚು ಬರೆಯುತ್ತಿದ್ದರೆ, ಕಥೆ ಬಹುಶಃ ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ.

ಹಂತ 4: ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿರುವುದನ್ನು ಗಮನಿಸಿ

ಒಂದು ಸಾಲು ಬಹಳಷ್ಟು ಹಿಂದೆ-ಮುಂದೆ ಉಳಿಸುತ್ತದೆ: "ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗೆ: ಪಾವತಿಸಿದ ತರಗತಿಗಳಿಗೆ ಮರುಪಾವತಿ; ನಿರ್ವಾಹಕರು ಸದಸ್ಯರ ಪರವಾಗಿ ರದ್ದುಗೊಳಿಸುವುದು." ನೀವು ನಿರ್ಮಿಸುವಾಗ ಕಥೆ ಬೆಳೆಯುವುದನ್ನು ಇದು ತಡೆಯುತ್ತದೆ.

ಹಂತ 5: INVEST ಜೊತೆ ಪರಿಶೀಲಿಸಿ

INVEST ಒಳ್ಳೆಯ ಕಥೆಗಳಿಗೆ ಸಾಮಾನ್ಯ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ. ಕಥೆ ಹೀಗಿರಬೇಕು:

ಪ್ರತಿ ಕಥೆಗೆ ಅಂಕ ನೀಡಬೇಕಾಗಿಲ್ಲ. ಕಥೆ ತಪ್ಪೆನಿಸಿದಾಗ ಏಕೆ ಎಂದು ತಿಳಿಯಲು ಬಯಸಿದರೆ ಇದು ಅತ್ಯಂತ ಉಪಯುಕ್ತ.

ಒಳ್ಳೆಯ ಮತ್ತು ಕೆಟ್ಟ ಉದಾಹರಣೆಗಳು

ತುಂಬಾ ದೊಡ್ಡ ಕಥೆಯನ್ನು ವಿಭಜಿಸುವುದು ಹೇಗೆ

ದೊಡ್ಡ ಕಥೆಗಳಲ್ಲೇ ಯೋಜನೆಗಳು ನಿಂತುಹೋಗುತ್ತವೆ. ವಿಭಜಿಸಲು ಸಾಮಾನ್ಯ ದಾರಿಗಳು:

• ಬಳಕೆದಾರರ ಪಾತ್ರದ ಪ್ರಕಾರ. ಸದಸ್ಯರು ತಮ್ಮ ಬುಕಿಂಗ್ ರದ್ದುಗೊಳಿಸುತ್ತಾರೆ; ಸಿಬ್ಬಂದಿ ಯಾರದೇ ಬುಕಿಂಗ್ ರದ್ದುಗೊಳಿಸುತ್ತಾರೆ.
• ಹರಿವಿನ ಹಂತದ ಪ್ರಕಾರ. ತರಗತಿಗಳನ್ನು ವೀಕ್ಷಿಸಿ; ತರಗತಿ ಬುಕ್ ಮಾಡಿ; ಜ್ಞಾಪನೆ ಪಡೆಯಿರಿ.
• ಸರಳ ಪ್ರಕರಣ ಮೊದಲು. ಉಚಿತ ತರಗತಿಯನ್ನು ಈಗ ರದ್ದುಗೊಳಿಸಿ; ಶುಲ್ಕ ಮತ್ತು ಮರುಪಾವತಿಗಳನ್ನು ನಂತರದ ಕಥೆಯಲ್ಲಿ ನಿರ್ವಹಿಸಿ.
• ಡೇಟಾ ವ್ಯತ್ಯಾಸದ ಪ್ರಕಾರ. ಮೊದಲು ಒಂದು ಸ್ಥಳವನ್ನು ಬೆಂಬಲಿಸಿ, ನಂತರ ಹಲವು.
• ಸರಿಯಾದ ಹಾದಿ ಮೊದಲು, ನಂತರ ದೋಷಗಳು. ಅದು ಕೆಲಸ ಮಾಡುವಂತೆ ನಿರ್ಮಿಸಿ, ನಂತರ ತರಗತಿ ತುಂಬಿದಾಗ, ಅವಧಿ ಮುಗಿದ ಪಾಸ್ ಮುಂತಾದವುಗಳ ನಿರ್ವಹಣೆ ಸೇರಿಸಿ.

ಪ್ರತಿ ತುಣುಕೂ ಬಳಕೆದಾರರು ಬಳಸಬಹುದಾದ ಮತ್ತು ಗಮನಿಸಬಹುದಾದ ವಿಷಯವಾಗಿರಬೇಕು.

ಬಳಕೆದಾರ ಕಥೆಗಳನ್ನು ಪ್ರಾಂಪ್ಟ್‌ಗಳಾಗಿ ಬಳಸುವುದು

ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳಿರುವ ಬಳಕೆದಾರ ಕಥೆ AI ಆಪ್ ಬಿಲ್ಡರ್‌ಗೆ ಒಳ್ಳೆಯ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ತುಂಬಾ ಹತ್ತಿರ. ಅದು AI ಗೆ ಯಾರು, ಏನು, ಏಕೆ ಮತ್ತು "ಮುಗಿದಿದೆ" ಎಂದರೆ ಏನು ಎಂಬುದನ್ನು ಕೊಡುತ್ತದೆ. ಪ್ರತಿ ಸಂದೇಶದಲ್ಲಿ ಒಂದು ಕಥೆ ಕಳುಹಿಸಿ:

ಜಿಮ್ ಸದಸ್ಯನಾಗಿ, ನಾನು ನನ್ನ ಫೋನಿನಿಂದ ತರಗತಿ ಬುಕಿಂಗ್ ರದ್ದುಗೊಳಿಸಲು ಬಯಸುತ್ತೇನೆ, ಇದರಿಂದ ವೇಟ್‌ಲಿಸ್ಟ್‌ನಲ್ಲಿರುವ ಯಾರಾದರೂ ನನ್ನ ಸ್ಥಾನ ಪಡೆಯಬಹುದು. ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು:

1. ನನ್ನ ಬುಕಿಂಗ್‌ಗಳಲ್ಲಿ ಪ್ರತಿ ಬುಕಿಂಗ್‌ನಲ್ಲೂ ದೃಢೀಕರಣ ಹಂತದೊಂದಿಗೆ Cancel ಇರುತ್ತದೆ.
2. ತರಗತಿಗೆ 12 ಗಂಟೆಗಳಿಗಿಂತ ಮುಂಚೆ ರದ್ದುಗೊಳಿಸಿದರೆ ಬುಕಿಂಗ್ ಕೇವಲ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.
3. 12 ಗಂಟೆಗಿಂತ ಕಡಿಮೆ ಇದ್ದರೆ, ದೃಢಪಡಿಸುವ ಮೊದಲು "$5 ತಡವಾದ ರದ್ದತಿ ಶುಲ್ಕ ಅನ್ವಯಿಸುತ್ತದೆ" ಎಂದು ತೋರಿಸಿ, ಮತ್ತು ಶುಲ್ಕವನ್ನು ಬುಕಿಂಗ್‌ನಲ್ಲಿ ದಾಖಲಿಸಿ.
4. ತರಗತಿಯಲ್ಲಿ ವೇಟ್‌ಲಿಸ್ಟ್ ಇದ್ದರೆ, ಮೊದಲಿರುವ ವ್ಯಕ್ತಿಗೆ ಸ್ಥಾನ ಮತ್ತು ಇಮೇಲ್ ಸಿಗುತ್ತದೆ.
5. ಫೋನ್ ಅಗಲದ ಪರದೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗೆ: ಮರುಪಾವತಿಗಳು, ಸದಸ್ಯರ ಪರವಾಗಿ ಸಿಬ್ಬಂದಿ ರದ್ದುಗೊಳಿಸುವುದು. ಇದನ್ನು ನಿರ್ಮಿಸಿ, ನಂತರ ಪ್ರಿವ್ಯೂನಲ್ಲಿ ಪ್ರತಿ ಮಾನದಂಡವನ್ನು ಪರಿಶೀಲಿಸಿ ಯಾವುದು ಪಾಸ್ ಆಗಿದೆ ಎಂದು ಹೇಳಿ.

ಸ್ಥೂಲ ಕಲ್ಪನೆಯಿಂದ ಕಥೆಗಳ ಕರಡನ್ನು AI ಗೆ ಮಾಡಲು ಕೇಳಿ, ನಂತರ ನೀವೇ ತಿದ್ದಿ:

ನನ್ನ ಆಪ್ ಐಡಿಯಾ ಇದು: [ಎರಡು ಅಥವಾ ಮೂರು ವಾಕ್ಯಗಳು]. ಮೊದಲ ಆವೃತ್ತಿಗಾಗಿ ಬಳಕೆದಾರರ ಪ್ರಕಾರದ ಪ್ರಕಾರ ಗುಂಪು ಮಾಡಿದ ಬಳಕೆದಾರ ಕಥೆಗಳನ್ನು ಬರೆಯಿರಿ, ಪ್ರತಿಯೊಂದಕ್ಕೂ 3 ರಿಂದ 5 Given/When/Then ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳೊಂದಿಗೆ. ಬಿಡುಗಡೆಗೆ ಅತ್ಯಗತ್ಯವಾದವು ಮತ್ತು ಕಾಯಬಹುದಾದವನ್ನು ಗುರುತಿಸಿ.

ಫಲಿತಾಂಶವನ್ನು ಯಾವಾಗಲೂ ಓದಿ ತಿದ್ದಿ. ನಿಮ್ಮ ಬಳಕೆದಾರರ ಬಗ್ಗೆ AI ಗೆ ತಿಳಿಯದು; ನಿಮಗೆ ತಿಳಿದಿದೆ.

ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಯೋಜನೆಯಾಗಿಯೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಕಥೆ ನಿರ್ಮಿತವಾದ ನಂತರ, ಪ್ರತಿ ಮಾನದಂಡವನ್ನು ನೀವೇ ಒಂದೊಂದಾಗಿ ಪರಿಶೀಲಿಸಿ. ಬಿಡುಗಡೆಗೆ ಮೊದಲು ನಿಮ್ಮ ಆಪ್ ಪರೀಕ್ಷೆ ಮಾರ್ಗದರ್ಶಿ ಇದರ ಮೇಲೆಯೇ ನಿರ್ಮಿಸುತ್ತದೆ.

ಬಳಕೆದಾರ ಕಥೆಗಳು ಇತರ ದಾಖಲೆಗಳೊಂದಿಗೆ ಎಲ್ಲಿ ಹೊಂದುತ್ತವೆ

• ಉತ್ಪನ್ನ ಅವಶ್ಯಕತೆಗಳ ಡಾಕ್ಯುಮೆಂಟ್ ಇಡೀ ಉತ್ಪನ್ನವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಸಮಸ್ಯೆ, ಬಳಕೆದಾರರು, ವ್ಯಾಪ್ತಿ. ಬಳಕೆದಾರ ಕಥೆಗಳು ಅದರೊಳಗಿನ ವಿವರವಾದ ತುಣುಕುಗಳು. AI ಬಳಸಿ PRD ಬರೆಯುವುದು ಹೇಗೆ ನೋಡಿ.
• ದೋಷ ವರದಿ ಈಗಾಗಲೇ ನಿರ್ಮಿಸಲಾದ ಕಥೆಗೆ ವಿರುದ್ಧವಾಗಿ ಮುರಿದಿರುವುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಒಳ್ಳೆಯ ದೋಷ ವರದಿ ಬರೆಯುವುದು ಹೇಗೆ ನೋಡಿ.
• MVP ಮುಖ್ಯ ಮೌಲ್ಯವನ್ನು ನೀಡುವ ಚಿಕ್ಕ ಕಥೆಗಳ ಗುಂಪು. MVP ಎಂದರೇನು ನೋಡಿ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• "ಬಳಕೆದಾರನಾಗಿ…" ತುಂಬಾ ಅಸ್ಪಷ್ಟ. ಬಳಕೆದಾರರ ನಿಜವಾದ ಪ್ರಕಾರವನ್ನು ಹೆಸರಿಸಿ.
• "ಇದರಿಂದ" ಬಿಟ್ಟುಬಿಡುವುದು. ಕಾರಣವಿಲ್ಲದೆ ಸಮಂಜಸ ರಾಜಿಗಳನ್ನು ಮಾಡಲಾಗುವುದಿಲ್ಲ.
• ಅಗತ್ಯದ ಬದಲು ಪರಿಹಾರ ಬರೆಯುವುದು. "ನನಗೆ ಡ್ರಾಪ್‌ಡೌನ್ ಬೇಕು" ಯಾರೂ ಯೋಚಿಸುವ ಮೊದಲೇ ವಿನ್ಯಾಸವನ್ನು ಲಾಕ್ ಮಾಡುತ್ತದೆ.
• ಪರೀಕ್ಷಿಸಲಾಗದ ಮಾನದಂಡಗಳು. "ಸುಲಭ", "ವೇಗ" ಮತ್ತು "ಸಹಜ" ಎಂಬವು ಆಸೆಗಳೇ ಹೊರತು ಮಾನದಂಡಗಳಲ್ಲ.
• ನಿಜವಾಗಿ ಎಪಿಕ್‌ಗಳಾದ ಕಥೆಗಳು. "ನನ್ನ ಖಾತೆ ನಿರ್ವಹಿಸಿ" ಹತ್ತು ಕಥೆಗಳು.
• ಎಲ್ಲಾ ಕಥೆಗಳನ್ನು ಮೊದಲೇ ಬರೆಯುವುದು. ಮುಂದಿನ ಕೆಲವನ್ನು ವಿವರವಾಗಿ ಬರೆಯಿರಿ; ಉಳಿದವನ್ನು ತಲುಪುವವರೆಗೆ ಒಂದು ಸಾಲಿನಲ್ಲಿ ಇಡಿ.

Mythex ನಲ್ಲಿ ಕಥೆಗಳು

Mythex ನಲ್ಲಿ ಐಡಿಯಾವನ್ನು ಕಥೆಗಳಾಗಿ ಬದಲಾಯಿಸಲು Plan ಮೋಡ್ ಒಳ್ಳೆಯ ಸ್ಥಳ: ಏಜೆಂಟ್ ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ವಿಧಾನವನ್ನು ಚರ್ಚಿಸುತ್ತದೆ. ಕಥೆ ಸಿದ್ಧವಾದಾಗ Build ಗೆ ಬದಲಿಸಿ ಅದನ್ನು ಅಂಟಿಸಿ, ಪ್ರತಿ ಸಂದೇಶದಲ್ಲಿ ಒಂದು ಕಥೆ. ಪ್ರತಿಯೊಂದರ ನಂತರ, /test ಪ್ರಿವ್ಯೂ ಮೂಲಕ ಕ್ಲಿಕ್ ಮಾಡಿ ಹರಿವನ್ನು ಪರಿಶೀಲಿಸಬಹುದು, ಮತ್ತು ತಪ್ಪು ದಾರಿ ಹಿಡಿದರೆ Revert to this point ಮೂಲಕ ಯಾವುದೇ ಉತ್ತರವನ್ನು ಹಿಂದಕ್ಕೆ ಉರುಳಿಸಬಹುದು. ದಸ್ತಾವೇಜಿನಲ್ಲಿ ಪರಿಣಾಮಕಾರಿ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ನೋಡಿ, ಮತ್ತು AI ಆಪ್ ಬಿಲ್ಡರ್‌ಗಳಿಗೆ ಪ್ರಾಂಪ್ಟ್ ಬರೆಯುವುದು ಮಾರ್ಗದರ್ಶಿಯನ್ನೂ ನೋಡಿ.

ಬಳಕೆದಾರ ಕಥೆ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

• ನಿರ್ದಿಷ್ಟ ಬಗೆಯ ಬಳಕೆದಾರರನ್ನು ಹೆಸರಿಸುತ್ತದೆ
• ವಿನ್ಯಾಸವನ್ನಲ್ಲ, ಅಗತ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ
• ನಿಜವಾದ "ಇದರಿಂದ" ಕಾರಣವನ್ನು ಒಳಗೊಂಡಿದೆ
• ಮೂರರಿಂದ ಆರು ಪರೀಕ್ಷಿಸಬಹುದಾದ ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳಿವೆ
• ಕನಿಷ್ಠ ಒಂದು ಅಂಚಿನ ಪ್ರಕರಣ ಅಥವಾ ದೋಷವನ್ನು ಒಳಗೊಂಡಿದೆ
• ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿರುವುದನ್ನು ಹೇಳುತ್ತದೆ
• ಒಂದೇ ಬಾರಿಗೆ ನಿರ್ಮಿಸಿ ಪರೀಕ್ಷಿಸುವಷ್ಟು ಚಿಕ್ಕದು
• ನಿರ್ಮಿಸಿದ ನಂತರ ಮಾನದಂಡಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಪರಿಶೀಲಿಸಲಾಗಿದೆ

ಪ್ರಶ್ನೆಗಳು