อยากพัฒนาตัวเอง? งานนี้ไม่ควรพลาด #BugDayBKK2012

อ. พูดได้ประทับใจ สื่อออกมาได้ดี ฟังแล้วไม่เบื่อ ใช้น้ำเสียงได้เหมาะสมมากครับ -/\- อยากจะพูดให้ได้แบบนี้บ้างจัง

เรื่อง non-functional requirement นี้จริงๆ แล้วเหมือนเป็นความคาดหวังส่วนบุคคลซะมากกว่า ซึ่งจะเป็นการคาดหวังว่าระบบควรจะมีคุณภาพอย่างไร เช่น การค้นหาข้อมูล ก็ควรจะค้นหาด้วยความรวดเร็ว หรืออะไรประมาณนี้ เริ่มแรก อ.ได้เน้นว่า requirement นั้นเป็นของ user เท่านั้น เราห้ามไปคิดให้ โดยส่วนใหญ่แล้วสิ่งที่เรากับเค้าต้องการไม่ตรงกัน มีข้อควรทำหลักๆ คือ

1. เราต้องฟังปัญหาและทำความเข้าใจ ห้ามสร้าง assumption เอง
2. มุมมองของคุณภาพ เป็นสิ่งที่ลูกค้าตัดสินใจว่าดีหรือไม่ดี ไม่ใช่คนพัฒนา

ต่อมาได้เปรียบเทียบ functional กับ non-functional requirement ซึ่งพวก functional คือพวกระบบหรือฟังก์ชั่นที่ลูกค้าต้องการว่าระบบเราจะทำอะไรได้บ้าง ส่วน non-functional คือพวกคุณภาพ เป็นสิ่งที่ทำให้ functional ดีขึ้น เช่น ค้นหาข้อมูลอย่างรวดเร็ว ระบบมีความปลอดภัยสูง

วิธีจัดการ non-functional จะจัดการได้ยากกว่าแบบ functional ให้เราคิดอยู่เสมอว่าอย่างแรกคือต้องเก็บ requirement ให้ดีก่อน แล้วสิ่งที่ตามมาจะดี ความต้องการของลูกค้าต้องชัดเจน ต้องวัดได้ว่า fail/success ต้องเป็นสิ่งที่ยอมรับได้ ต้องเป็นสิ่งที่ทำได้จริง และต้องติดตามได้ว่าใครทำอะไร เมื่อไหร่ อย่างไร อ. ได้แนะนำ user story ว่ามีประสิทธิภาพมากเพราะเป็นภาษาที่ลูกค้าเขียนจากความต้องการของเค้าเอง และนักพัฒนาจะเข้าใจความต้องการของลูกค้าได้ดีมากขึ้น และเราก็สามารถเปลี่ยนไปเป็น design ของเราได้ง่าย

ต่อมาให้สร้าง metric หรือตาราง ออกมาดูว่า functional นั้นๆ ต้องมี non-functional อะไรบ้าง เราจะจับประเด็นของ non-functional ได้ specific และ measurable (สามารถวัดได้) สิ่งที่วัดไม่ได้ เช่นพวก usability เราอาจจะใช้ prototype ช่วย และเราควรจะมีทางเลือกให้เค้า เรื่อง usability เป็นสิ่งที่กว้างมาก และยาก เราต้องหาตัวชี้วัดมาให้ได้ และการ test จะส่งผลต่อ user satisfaction มีหลายระดับ เช่น เบื้องต้นอาจจะมีแค่ design 1 หน้ากระดาษ ต่อไปก็อาจจะให้ทดลองใช้ได้ แต่ยังใช้ได้ไม่สมบูรณ์ หรืออาจจะทดลองเป็นส่วนๆ

อ. ได้พูดถึงงานวิจัยของ Virzi (1992) และ Nielsen & Landauer (1993) ว่าควรจะมี user สัก 5 คนขึ้นไปมาร่วมทดสอบ usability และ user ควรจะเป็น user ของระบบจริงๆ ถ้าเป็นไปได้ก็ควรจะเริ่มทดสอบตั้งแต่เราเริ่มพัฒนาระบบ จะช่วยลด cost ในภายหลัง และตอนท้าย อ. ได้กล่าวถึง process การทำงานก็ต้องดีด้วย จะช่วยพัฒนาคุณภาพ การเลือกใช้ process ซึ่งไม่ว่าจะใช้แบบไหน ให้ดู culture ของทีมเราด้วย แล้วนำไปใช้ให้เหมาะสม

ตอนท้ายของ session นี้มี อ. อีกท่านหนึ่งขึ้นมาปิดท้าย (ผมจำชื่อไม่ได้) เล่าถึงประสบการณ์ที่ล้มเหลวที่ได้เจอมา โดยเล่าว่าเมื่อก่อนมีบริษัทแห่งหนึ่งล้มเหลวเพราะว่าโปรแกรมเมอร์รุ่นเก่าไม่ยอมศึกษาภาษาใหม่ ไม่รับสิ่งใหม่ๆ เข้ามา แต่ลูกค้าต้องการให้ทำภาษาใหม่ เทคโนโลยีใหม่ๆ ทำให้พนักงานที่เข้ามาใหม่ต้องลาออกไปเป็นจำนวนมาก จนบริษัทนั้นเหลือพนักงานอยู่ร้อยกว่าคนจากสี่พันกว่า เรื่องนี้อยากให้เห็นว่าถ้าเราไม่ติดตาม เทคโนโลยี เราจะอยู่ไม่ได้ ตอนท้ายเปิดคลิป Google Adwords ให้ดู แนะนำว่าอีกหน่อยเราต้องทำงานแบบนี้ ต้องก้าวทันโลก ต้องปรับตัวตามเทคโนโลยีใหม่ๆ ที่เกิดขึ้นอยู่เรื่อยๆ ปิดท้ายว่าเราต้องตามให้ได้ว่าลูกค้าต้องการอะไร โปรแกรมเมอร์ที่ไม่ปรับตัวตามเทรนด์จะมีโอกาสล้มเหลวสูง

หัวข้อที่ 2 Our Features = User's Bugs โดย อ. @rawitat

เจ้าของ session มาจัดทอร์คโชว์เพราะลืมเอาสไลด์ใส่ Dropbox แต่ผมมั่นใจว่าไม่น่าจะมีปัญหาอะไร 🙂  และก็ไม่ผิดหวังจริงๆ ด้วยครับ -/\- เริ่มแรกมาก็พูดถึงกฎของ Murphy ว่าน่าสนใจ เพราะว่าโปรเจคมักจะ fail ในวันส่งงาน และก็เพราะว่าวันนี้ลืมโยนสไลด์ลง Dropbox นั่นเอง LOL

เริ่มต้น session นี้ อ. ได้นิยามคำว่าบักไว้ว่า บักคืออะรไก็ตามที่ทำให้ user รำคาญ ให้ทุกคนเข้าใจตรงกันก่อน

บักที่แก้ยากตามประสบการณ์ของผู้พูด (+ ความเห็นจากผู้ฟัง) คือบักที่ทดสอบบนเครื่องเราแล้วไม่เจอ แต่ดันไปเจอบนเครื่องผู้ใช้ บักพวกนี้จะถือว่าเป็นบักที่ reproduce ไม่ได้ (คือเราสร้างมาแบบเป๊ะๆ ไม่ได้) แล้วที่แก้ที่สุดคือบัก user experience คือมันจะเข้าข่ายว่าคนมีความเห็นไม่ตรงกัน ทำให้เราไม่รู้จะแก้อย่างไรให้ทุกคนพอใจ ยกตัวอย่างเรื่องภาษาในซอฟต์แวร์ก็เช่นเดียวกัน เพราะว่าบางกลุ่มของประเทศก็ไม่อยากได้ซอฟต์แวร์ ภาษาอังกฤษ

สาเหตุคือ ผู้พัฒนาซอฟต์แวร์พยายามมี feature มาให้ผู้ใช้มากเกินไป คือมันเป็นสิ่งที่เราอยากให้ user ใช้ แต่ไม่ได้ถามเลยว่าเค้าจะอยากใช้หรือเปล่า ยกตัวอย่างเรื่องนาฬิกาที่มีปุ่มเดียว สามารถตั้งได้ถึงระดับวินาที กว่าจะตั้งได้นี่ใช้เวลานานมาก และจะมีปัญหามากถ้าต้องตั้งเวลาย้อนหลัง

อ. ได้ให้ take-away message ว่า "ไม่มีใครอยากใช้โปรแกรมของคุณ เค้าแค่อยากได้สิ่งที่โปรแกรมทำให้ เค้าแค่ต้องการผลลัพธ์"

แล้วก็ The best software doesn't exist. ในความหมายของ อ. หมายถึง เราได้ผลลัพธ์มาเองโดยเราไม่ต้องใช้ เช่น นาฬิกามี GPS สามารถตั้งเวลาได้เองเวลาเราเดินทางไปต่างประเทศ ซึ่งก็ประมาณว่าเราต้องทำให้ผู้ใช้ไม่คิดว่าเค้าใช้ซอฟต์แวร์ของเราอยู่ เราต้องทำให้เค้าคิดว่านี่เป็นสิ่งที่เค้าใช้โดยไม่รู้สึกรำคาญ

หัวข้อที่ 3 Achieving Zero Defects with Agile Methods โดย Varokas

ผู้พูดออนไลน์มาจากอเมริกา โดยมีประสบการณ์ทำ Agile มา 2 ปีกว่าๆ วันนี้จะมาพูดว่าใช้ Agile อย่างไรให้ไม่มี defect เลย สิ่งที่สำคัญที่มีผลกระทบมากสุดคือการทำ Test-Driven Development (TDD) และพูดถึงรายละเอียดว่าวิธีการนี้ต้องทำอย่างไร ข้อดีที่เห็นได้คือ โค้ดของเราถูกทดสอบอยู่ตลอด ผู้พูดอยากให้มองว่า TDD คือ spec ที่ทดสอบได้ และทดสอบอยู่ตลอดเวลา และโค้ดที่มี TDD เราสามารถอ่านจาก test case ได้เลยว่าโค้ดนี้มีคุณสมบัติครบหรือเปล่า ทำงานได้ตามที่เราต้องการครบหรือไม่ เราอาจะไม่จำเป็นต้องเสียเวลากลับไปอ่าน requirement หรือกลับไปดูโค้ด

TDD จะสามารถทำให้ design ดีขึ้นอีกด้วย ยกตัวอย่างเช่น ถ้าเราเขียนโค้ดเกี่ยวกับเวลา date = new Date() แบบนี้จะทำให้ QA ไม่สามารถทดสอบได้ทุกวัน ถ้า QA จะทดสอบฟังก์ชั่นนี้ ก็จะต้องไปเปลี่ยน system date เอาเอง แต่ถ้าเราออกแบบให้มีตัว mock up ตัว date ขึ้นมา จะทำให้เราสามารถทดสอบตอนไหนก็ได้ อีกทั้ง QA ยังทำงานง่ายขึ้นอีกด้วย

ต่อมาได้ไปพูดถึงหน้าที่ของ QA โดยข้อสงสัยอันดับแรกคือ ถ้าเราทดสอบโค้ดของเราแล้วเราก็มั่นใจว่าเราไม่มีบัก ทำไมเราถึงต้องมี QA? จริงๆ แล้ว QA จะมาช่วยทดสอบระบบไม่ว่าทั้ง in spec หรือ not in spec ซึ่งจะอ้างไปถึง Exploratory Testing ซึ่งเป็นสิ่งที่มีประโยชน์มากกว่าต้องมานั่งเช็คว่าฟังก์ชั่นนี้ทำงานถูกหรือไม่ QA ยังช่วยดูว่าเราทำอะไร conflict กับ requirement หรือไม่ และช่วยกำหนด spec ตั้งแต่เริ่มพัฒนาซอฟต์แวร์อีกด้วย

การทำ Continuous Delivery ทำให้เราตอบสนองกับการเปลี่ยนแปลงได้ดียิ่งขึ้น และมีส่วนช่วยทำ zero defect คือถ้าเรา release ไม่บ่อย จะมีปัญหาในการตามแก้บัก และยิ่งถ้าเรา branch ออกมาก็มีโอกาสที่จะเกิดบักขึ้นมาได้อีกด้วย

วิธีต่อมาที่ช่วยให้เกิด zero defect คือ One thing at a time คือทำทีละอย่าง เราแก้ไปทีละอย่าง เสร็จไปทีละอย่าง ดีกว่าที่ต่องคนต่างทำ มีหลายงาน เวลาเกิดปัญหาขึ้นมันจะแก้ได้ยากกว่า

วิธีสุดท้ายที่ช่วยได้การทำ code review หรือ pair programming แนะนำว่าการทำ code review ควรจะทำทีละน้อยๆ เวลาแก้จะได้แก้น้อยๆ

หัวข้อที่ 4 ATDD - Make Love, Not (QA/DEV) War to Work โดย @kluak110 กับ @sinapam

กล่าวถึงว่าจะเป็นการดีถ้าเราสามารถทำลายกำแพงระหว่าง developer กับ tester  ลงได้ ซึ่ง Agile สามารถช่วยได้ ยกตัวอย่างการทำ Scrum ซึ่งจะมีการรวมทีมกัน สามารถทำให้กำแพงนั้นน้อยลงหรืออาจจะหายไปเลย เพราะทุกคนจะกลายเป็นทีมเดียวกัน

Acceptance Test-Driven Development (ATDD) คืออีกวิธีหนึ่ง มีหลักการเดียวกับ TDD แต่ในที่นี้เราจะเขียน Acceptance Test ก่อนการเขียนโค้ด โดยปกติ developer จะรอ Acceptance test จาก QA ก่อน แล้วค่อยเริ่มเขียนโค้ด จากความเห็นของผู้พูด Acceptance test คือ requirement แต่จะมาอยู่ในรูปแบบที่ developer กับ QA เข้าใจตรงกัน

ต่อมาได้เล่าประสบการณ์ให้ฟังว่าช่วงจะเริ่มทำ ATDD นั้น developer จะว่าง ไม่มีงานทำ ระหว่างรอ QA ซึ่ง QA จะรู้สึกว่าต้องรับผิด ชอบในการเขียนชุดทดสอบมากขึ้น แล้วพอ developer ได้รับชุดทดสอบมา ก็จะรู้สึกว่าทำไมเยอะ ยุ่งยาก พอ QA เขียนชุดสอบไมเป็นก็จะมาคุยกับ developer แล้วพอ developer ไม่เข้าใจชุดทดสอบที่ QA เขียนก็จะไปคุยกับ QA หลังจากนั้น พอได้คุยกันมากขึ้น จะทำให้ทุกอย่างดีขึ้น design ก็ดีขึ้น บักก็จะเริ่มหายไป ต่อไป developer ก็เริ่มจะเรียก QA ไปร่วมงานตั้งแต่เริ่มโปรเจค จะได้ลดความวุ่นวายลง QA จะมีเวลาทำ Exploratory test มากขึ้น

ผู้พูดมีหน้าสไดล์สรุปสั้นๆ ไว้ว่า

TDD = Design
ATDD = Conversation

ในช่วงท้ายเป็น demo พูดถึงอุปกรณ์ทำ ATDD เช่น พวก Robot Framework หรือ Selenium และอื่นๆ ก่อน แล้วค่อยยกตัวอย่าง requirement ตามด้วยการเขียน acceptance test ที่จะดูเป็นภาษาคน แล้วเราค่อยแปลงไปเป็นโค้ดที่ยังพอเป็นภาษาคนอยู่เอง เช่น ชื่อฟังก์ชั่น go_to_estimation_page() ในที่นี้ใช้ Robot Framework แสดงการทดสอบให้ดู ไฟล์อินพุทจะเป็นแค่ไฟล์ HTML ธรรมดา การทำงานก็จะเหมือนคนไปนั่งทดสอบจากหน้าซอฟต์แวร์นั้นๆ เอง แต่อะไรที่เราสามารถ automate ได้ก็ทำไว้จะดีกว่า 🙂

จบเพียงเท่านี้.. หวังว่าจะบล็อกนี้จะเป็นความรู้ให้กับคนที่พลาดงานครั้งนี้นะครับ ถ้ามีทีมงานมาอ่านก็ขอให้มี #BugDayBKK2013 และปีต่อๆ ไปด้วยนะครับ ^^

สุดท้ายขอขอบคุณทุกคนที่มาร่วมแชร์ความรู้ให้นะครับ -/\-