Refinement,Requirement Gathering

From Question to Specification : Specification by Example

จากวันก่อนที่พูดเรื่อง เมื่อการเทสไม่ใช่การทดสอบผลงาน แล้วก็พูดถึงวิธีการในการทำ Backlog Refinement แบบนึงให้เกิดการมีส่วนร่วม เลยรู้สึกได้ว่ายังขาดอะไรไปสักอย่างในช่วงวันแรกของ CSD เพราะทั้ง 2 หัวข้อผมลืมใส่รายละเอียดที่เกี่ยวกับกิจกรรม และการนำไปใช้อยู่พอสมควร เลยคิดว่าน่าจะเอามาพูดกันในวันนี้

สิ่งที่ Terry สอนให้เราทำในขั้นตอนของการทำ Backlog Refinement นั้น เขาเรียกมันว่า Specification by Example ถ้าจะแปลง่าย ๆ คือการสร้างข้อกำหนดของระบบโดยการให้ตัวอย่าง เพื่อให้สามารถมองเห็นภาพของระบบได้อย่างชัดเจนทั้งคนให้ Requirement และคนที่เก็บ Requirement จริงอยู่ ตามหลักการแล้วก็แค่สร้าง Example มาให้ลูกค้าเพื่อ Confirm ว่าเนี่ยแหละคือสิ่งที่เขาต้องการหรือเปล่า แต่สิ่งที่ได้จาก CSD ซึ่งเป็นการลงมือทำเองนั้น ทำให้ได้สัมผัสจริง ๆ ว่าขั้นตอนต่าง ๆ จนกลายเป็น Example นั้นเป็นอย่างไร แถมหลังจากเราได้ Example มาแล้วขั้นตอนการแปลงมันให้เป็น Automate Script โดยยังคงความเป็น Specification นั้นยังมีจุดสำคัญอีกหลายอย่างที่เราต้องใส่ใจ

คำถามที่ควร และไม่ควรถาม

จากคราวที่แล้วที่ผมบอกว่า Terry ให้เราเล่นเกมส์ 20 คำถามนั้น จริง ๆ แล้ว เขาบอกก่อนที่จะมีการออกไป Workshop เพื่อการเก็บ Requirement ว่า สิ่งสำคัญอันดับแรกของการตั้งคำถามคือ ประเภทของคำถาม อย่างแรกเลยคืออย่าถามว่าทำไม (Why) การถามคำถามว่าทำไมบ่อย ๆ จริง ๆ แล้วไม่เป็นผลดีกับใครเลย ยิ่งเป็นคนที่เราพึ่งเจอกันหรือพึ่งรู้จักกัน พาลจะทำให้เขาไม่พอใจได้ง่าย ๆ เพราะทุกคนมีความรู้สึกต้องป้องกันตัวเองจากคำถามประเภทนี้ (ลองถามเมียดูสิว่าทำไมถึงจะซื้อไอ้นั่นไอ้นี่ อาจจะมีบ้านแตก) เพราะฉะนั้นคำถามที่ควรถามคือ อะไร (What) และอย่างไร (How) เช่น ถ้าระบบจะต้องโชว์ผลของการส่ง Email ก็ควรถามว่าผลที่ว่านี้ควรจจะแสดงรายละเอียดอะไรบ้าง หรือ แล้วคุณต้องการให้โชว์ออกมาอย่างไร สิ่งสำคัญในจุดของการตั้งคำถามคือ การให้ลูกค้าแสดงตัวอย่างของสิ่งที่เขาต้องการ เพื่อให้ลูกค้าสามารถอธิบายสิ่งที่เขาอยากจะได้หรืออยากจะเห็นจริง ๆ ในมุมมองของเขา และถ้าเป็นไปได้การตังคำถามนั้นให้มุ่งเน้นไปที่คำตอบที่จะออกมาเป็นเชิงเหตุการณ์หรือพฤติกรรมที่เกิดขึ้น ประมาณว่าถ้าเขาเข้ามาทำอันนี้ เขาจะได้อะไรกลับออกไป แล้วมันจะมีผลกระทบกับตรงไหน ที่ต้องใครมาทำอะไร

อุปกรณ์ที่ควรใช้

Terry ให้ความสำคัญกับการใช้อุปกรณ์สูงมาก มีบางกลุ่มที่พยายามจะเขียนสิ่งที่คิดออกมาบนกระดาษ A4 บนโต๊ะ Terry มาเห็นเท่านั้นก็ลากบอร์ดใหญ่ ๆ พร้อมปากกามาให้ บอกให้เขียนบนนี้ แล้วให้ทุกคนได้มีโอกาสเขียนตรงไหนก็ได้ ซึ่งเขามาสรุปให้เราฟังอีกทีหลังว่า อุปกรณ์ในการทำ Requirement Gathering สำคัญมาก การจดอะไรบางอย่างลงในกระดาษเล็ก ๆ อย่าง A4 เป็นการบีบให้เรามีช่องทางในการสื่อสารน้อยลง แถมยังเปิดโอกาสให้เกิดการเขียนคนเดียวซึ่งทำให้คนอื่น ๆ ในกลุ่มไม่ได้มีส่วนร่วมในการทำด้วย ส่วนการจดลงในสมุดส่วนตัวในช่วงนี้เป็นเรื่องต้องห้าม แถมกระดานยังทำให้ทุกคนมองไปยังจุดเดียว แถมเป็นจุดเดียวที่ทุกคนมองเห็น ยิ่งทำให้เกิดการ Focus หรือเมื่อเรียก PO เข้ามาถามการให้เขามองไปที่กระดานย่อมง่ายกว่าจ้องมองไปที่กระดาษเล็ก ๆ

แปลงคำถามเป็น Example, Scenario

สิ่งสำคัญในการทำ Refinement แบบที่ใช้ Specification by Example คือต้องพยายามแปลง สิ่งถามให้เกิดเป็น Behavior คือต้องมีที่มา การทำงานภายใน และที่ไป เพราะฉะนั้นการเขียนออกมาทำได้หลายแบบ อย่างแรกคือเขียนออกมาเป็น Scenario เช่นเมื่อลูกค้าทำแบบนี้ แล้วระบบจะทำอะไร ผลลัพท์จะออกทางไหน เพื่อให้ลูกค้าและเราสามารถเห็นภาพ Flow ของการทำงานทั้งหมดเป็นภาพเดียวกัน แล้วจึงสร้าง Example Data จาก Scenario นั้น และเพื่อให้เป้นการง่ายในการแปลง Example Data ให้เป็น Test Script หรือ Automate Test Script สิ่งที่ควรจะทำคือเขียนออกมาในรูปแบบของตาราง ที่ประกอบไปด้วย Input และ Output หรือที่ผมเคยเรียนมาสมัย ปวช ปวส ก็คือ ตาราง Truth Table

เขียน Spec ให้เป็น Business Rule

จริง ๆ ผมรู้จักคำว่า Specification by Example มาก่อนแล้ว แต่จุดที่ผมหลงทางอยู่นานในการเขียน Specification by Example คือพยายามทำให้มันเป็น Spec เพื่อให้ทีม Develop สามารถทำงานต่อได้ จนลืมไปว่าสิ่งที่เรากำลังทำอยู่คือ Requirement เพื่อให้ทุกคนสามารถเข้าใจระบบได้ตรงกัน หรือมันก็คือ Business Rule ของลูกค้า แถมถ้าเราทำ ATDD ซึ่งเราต้อง Maintain Spec นี้ต่อไปการพยายามคงความเป็น Business Rule ไว้จึงสำคัญต่อทุกคนมาก ๆ แถมยังควรจะเป็น Business Rule ที่สามารถอ่านแล้วรู้ว่า Business ต้องการอะไร ส่วนที่เสริมขึ้นมาคือสามารถนำไป Excuse ได้ด้วย โดยใน Specification Pyramid สิ่งที่ผมเข้าใจเกียวกับการเขียน Automate Test ก่อนหน้านี้จะอยู่แถว ๆ Technical Activity ประมาณว่า กรอกอันนั้น กรอกอันนี้ ที่ Input Box , กดปุ่ม Submit แล้วก็จะได้ผลลัพท์ออกมาเป็นแบบนี้ ซึ่งก็ไม่ผิดอะไร แต่เขาบอกว่ามันอ่านไม่รู้เรื่อง ใน Class CSD จึงมีการแบ่งแยก Level ของ Rule, Workflow และ Technical Activity ออกอย่างชัดเจนพอสมควร และจะถูกปรับจูนกันในตอนที่ทำ Code Reviews กันเกือบทุกเช้าซึ่งมีเวลาผมคงเอาตัวอย่างที่มีการปรับจูนจาก Technical ไปจนเป็น Rule ที่สามารถอานเข้าใจได้ง่ายมาให้ดูกัน

สรุป

จะเห็นได้ว่าจริง ๆ แล้ว Specification by Example พูดยาวตั้งแต่ การทำ Requirement Gathering ในกิจกรรม Backlog Refinement (ซึ่งจะเน้นที่การมีส่วนร่วมของทั้งทีมงานและผู้ให้ความต้องการ) การเขียนออกมาในรูปแบบของ Scenario , Example เพื่อให้สามารถ Confirm สิ่งที่ลูกค้าต้องการ รวมไปถึงการแปลง Requirement ออกมาเป็น Business Rule จริง ๆ (ซึ่งภายใต้นั้นอาจจะมี Technical Activity อะไรหลาย ๆ อย่าง ) จนไปถึงการ Maintain Execution Spec เพื่อให้พร้อมรองรับการเปลี่ยนแปลงที่อาจจะเกิดขึ้นในอนาคต …

 

cerdit image : http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/

Advertisements

4 thoughts on “From Question to Specification : Specification by Example

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s