ลักษณะเฉพาะตัวของความเป็น agile software development อย่างหนึ่งก็คือ การเขียน requirements ในลักษณะ user story... อ้ะ แล้ว user story หน้าตาเป็นยังไง?
User story เริ่มมาจากคำอธิบายสั้นๆถึงความต้องการ ในมุมมองของผู้ที่จะได้ประโยชน์จาก story
As a <stakeholder>, I want to <goal>, so that <reason>.
stakeholder ก็คือ ผู้ที่จะได้ประโยชน์จากการทำ story นี้ เราจะทำ story นี้ไปทำไม ถ้ามันไม่มีประโยชน์กับใครเลย
goal คือ เป้าหมายของ story เมื่อทำเสร็จนี่แหละคือสิ่งที่เราอยากได้
reason คือ เหตุผลที่อยากได้สิ่งนี้ การบอกเหตุผลจะช่วยให้คนทำ story มองเห็นภาพรวมของการนำไปใช้มากขึ้น
ส่วนถัดไปของ user story ก็คือ exit criteria ตัวนี้จะเป็นเหมือนกับ checklist ว่าต้องทำสิ่งเหล่านี้ให้เสร็จนะ story ถึงจะเสร็จได้
จริงๆ ก่อนจะนำ user story ไปทำงานได้ จะต้องมีการนำ story มา discuss แล้วก็ estimate กันก่อน แต่ในวันนี้ อยากจะพูดถึงส่วนนึงของการเขียน story ให้ดีจะดีกว่า เพราะเห็นว่าดูจะเป็นปัญหาที่ผู้ใช้ agile มือใหม่เจอกันเป็นประจำ
สิ่งที่อยากจะพูดก็คือ เราจะต้องไม่ตกไปใน หลุมพราง ต่อไปนี้
- หลุมพรางของ developer ผู้ชอบเขียน story เป็น task
- หลุมพรางของผู้ใช้ที่ไม่รู้ว่าตัวเองอยากได้อะไร
- หลุมพรางของ story มหึมา
1. หลุมพรางของ developer ผู้ชอบเขียน story เป็น task
ตอนนี้บางคนที่อ่านอยู่อาจจะแอบร้อนตัว :P
การเขียน story เป็น task ก็เช่น
As a developer, I want to have a user database, so that I can record my user.
ก็ดูดีใช่มั๊ย มีครบทั้ง stakeholder, goal แล้วก็ reason แต่ปัญหาของมันก็คือ เมื่อทำเสร็จ มันไม่ได้มีประโยชน์อะไรกับคนที่เอาระบบไปใช้จริง สมมตินะคับสมมติ ว่าเราทำ story นี้เสร็จ แล้วเกิดทำ story ที่เป็น UI สำหรับการ add หรือ show user ไม่ทัน มันก็เอาไปใช้ไม่ได้อยู่ดีนั่นแหละ
แอบนึกถึง project นึงตอนเรียนตรี ที่ตอนส่งอาจารย์มีแค่ splash screen (ที่เป็น animation วิ้งวั้งตอน load program น่ะ) ที่ใช้งานได้ แต่ project จริงๆ คือทำ compiler! คือ จริงๆแล้วข้างใน program น่ะ มีส่วนที่ทำงานได้ เป็นก้อนๆอยู่ แต่ว่าแต่ละก้อนก็ต่างคนต่างทำ แล้วตอนจบก็เวลาหมดไม่ได้เอามาต่อกัน งาน 3 วัน 3 คืน สุดท้ายที่โชว์ได้ ก็เหลือแค่ splash screen... จบไป
แล้วเราควรจะเขียน story ยังไงล่ะ สมมติเราต้องมี user แล้วก็ต้องมี database ใช่มั๊ย แต่สำหรับลูกค้าก็คือ เค้าต้องการเพิ่ม user ในระบบ ไม่ว่า user นั้นจะถูกเก็บใน text file หรือ database ดังนั้น user story ก็อาจจะเป็นว่า
As a system admin, I want to add a user into the system, so that they can login to the system and use the functionalities.
แล้ว story นี้ก็จะไม่เสร็จจนกระทั่ง admin สามารถ add user ได้ ซึ่งก็แน่นอนก็ต้องมี database ด้วย
2. หลุมพรางของผู้ใช้ที่ไม่รู้ว่าตัวเองอยากได้อะไร
exit criteria ยอดฮิตที่ทำให้คนเขียนตกหลุมพรางนี้ก็คือ "it should work properly" แล้ว properly นี่มันคืออะไรเรอะ?!
การมี exit criteria ที่ไม่ clear ทำให้เกิดปัญหาใหญ่อย่างหนึ่ง ก็คือ ไม่มีใครรู้ว่า อะไรคือ จุดวัดว่า story นี้เสร็จแล้ว ถึงบางคนจะคิดว่ารู้ แต่หลายคนก็ต่างรู้ สุดท้าย จบลงที่ dev กับ test มาเถียงกันว่านี่เป็น bug หรือ feature นิ (วะฮ่าฮ่า คุ้นจัง)
แล้วเราจะไปยังไงกันต่อดีล่ะ ถ้าเจอ exit criteria อย่างนี้ล่ะก็ อันดับแรก ก็ต้องถามคนเขียน story ก่อนเลยคับ เห็นได้ชัดว่าคนเขียนไม่รู้ว่าตัวเองอยากได้อะไร ถ้าคนเขียนเป็นลูกค้าของคุณล่ะก็ ข่าวร้ายก็คือ บ่อยครั้งเลยล่ะ ที่เค้าจะไม่รู้ว่าเค้าอยากได้อะไร :) สิ่งที่อาจจะทำได้ ก็คือ ตั้งคำถามที่มีลักษณะ narrow down ความต้องการของคุณลูกค้าไปเรื่อยๆ เช่น
- จะเกิดอะไรขึ้นล่ะ ถ้า user ใส่ข้อมูลที่ไม่ถูก format? อยากให้ error text หน้าตาเป็นยังไง?
- ถ้า user ใส่ข้อมูลหน้านี้เสร็จแล้ว กด submit แล้วจะให้ไปไหนต่อ?
- ข้อมูลไหนที่ user จำเป็นต้องใส่ (required) และ ข้อมูลไหนที่ใส่ก็ได้ ไม่ใส่ก็ได้ (optional)?
แต่ทั้งหมดทั้งปวง สิ่งที่ควรจะเกิดขึ้นก็คือ เราต้องรู้สึกให้ได้ว่า story นี้ไม่ชัดเจน และต้องรู้แล้วว่าจะต้องไปถามคำถามนะ ก่อนที่จะมีการ implement ขึ้น
3. หลุมพรางของ story มหึมา
ลักษณะที่ดีของ story ที่นอกจากที่พูดมาแล้วในข้อ 1. ก็คือ เมื่อเราสามารถแบ่ง story ในลักษณะที่เมื่อทำเสร็จแล้วจะมีประโยชน์ได้แล้ว สิ่งที่ควรจะต้องทำอีกอย่างก็คือ ต้องทำเสร็จบ่อยๆ ข้อดีของการทำเสร็จบ่อยๆ ก็คือ เราจะได้ demo ให้ลูกค้าเห็น แล้วข้อดีของการได้ demo ให้ลูกค้าเห็นก็คือ feedback และข้อดีของการได้ feedback ก็คือ จะได้มีการแก้ไข ปรับเปลี่ยน requirements และ priorities ไปตามทางที่ลูกค้าอยากได้มากที่สุด ณ เวลานั้นๆ และข้อดีของการได้สิ่งที่ลูกค้าอยากได้มากที่สุดก็คือ ลูกค้ารักเรา จบ :)
ดังนั้น ถึงแม้จะมี story ที่ไม่ได้เป็น task แล้ว story ก็ควรจะมีขนาดเล็กด้วย เพื่อจะได้ทำ story เสร็จบ่อยๆ trick ง่ายๆก็อาจจะเป็น ถ้า story ไหนต้องใช้เวลาทำนานกว่า 2-3 วัน (ตัวเลขก็ขึ้นอยู่กับ nature ของแต่ละ project) ก็ลองคิดดูว่า story นี้จะแตกออกมาเป็น story ที่เล็กลงกว่านี้อีกได้มั๊ย แต่อย่าลืม ว่าก็ต้องแตกออกมาใน concept เดียวกันกับข้อ 1. คือ ในมุมมองของผู้ใช้ หรือผู้ที่ได้รับประโยชน์ไม่ใช่ task
จริงๆ เราก็มีหลักการง่ายๆให้จำสำหรับลักษณะที่ดีของ story อยู่แล้วล่ะ นั่นก็คือ I.N.V.E.S.T.
I = Independent (เสร็จได้ในตัวของมันเอง ไม่ต้องรออีก story นึง)
N = Negotiable (มา discuss พูดคุยกันได้ เปลี่ยนแปลงได้)
V = Valuable (มีประโยชน์ ให้ value)
E = Estimable (สามารถประมาณ effort ที่จะใช้ในการทำ story ได้)
S = Small (มีขนาดเล็ก จะได้ทำเสร็จเร็ว ได้ feedback เร็ว)
T = Testable (test ได้ มีตัววัดว่าเสร็จแล้วจริง)
ก็ให้ระลึกถึงหลัก 6 อย่างนี้อยู่เสมอ ส่วน 3 หลุมพรางข้างบนที่กล่าวมา อาจจะเป็นตัวช่วยให้มองออกง่ายขึ้นว่าเราได้หลุดไปจากลักษณะของ story ที่ดีแล้ว
Agile ง่ายนิดเดียว ชิ้ง v(^ ^ )
