ตามหัวเรื่องเลยครับ level 1 อันที่แล้ว ยิ่งอ่านยิ่งขัดใจ มัน abstract ไปหน่อย (แต่แอบดีใจที่ยังมีบางท่านอิน ^ ^) ขอแก้ตัวครับ เริ่มกันเลยละกัน
ถ้าเกิดต้องเขียนทั้ง codeทั้ง test แล้วมันจะเร็วขึ้นจริงๆเหรอ? อย่างนี้ของที่เคยทำวันเดียวเสร็จ ไม่ต้องทำ 2 วันเหรอ?
ผมได้ยินคำถามนี้ในงาน BugDay Bangkok ที่ผ่านมา คำถามโดนใจมากถึงกับต้องยกมือขอตอบ ผมถามเจ้าของคำถามว่า บ่อยครั้งแค่ไหนที่ 1 วันที่เรากะไว้นั้น เป็น 1 วันแม่นๆอย่างที่เราหวัง? ถ้าให้เลือกระหว่าง 1 วัน ด้วยโอกาส 20% กับ 2 วันด้วยโอกาส 80% ชอบอันไหนมากกว่า? จากประสบการณ์ของผม 1 วันนี้จะแม่นในช่วงแรกๆของ project ครับ เพราะการสร้างตึกบนทุ่งโล่งๆนั้นมันง่าย แต่ถ้าเป็นระยะหลังๆ 1 วันที่กะไว้จะใช้เวลานานขึ้นๆครับ นั่นเพราะเราต้องสร้างตึกใหม่บน ผังของเมืองที่เราสร้างขึ้นมาก่อนหน้านี้ (ใครเคย”ขอพรุ่งนี้”ซ้ำๆไปเป็นอาทิตย์บ้างครับ (T-T)/)
เหล่า Agile adopter level 0 พอเริ่มเขียน test แล้ว, เริ่ม assure quality ของสิ่งที่เราพัฒนาด้วยตัวเองแล้ว จะสามารถ estimate งานตัวเองได้แม่นขึ้นครับ เพราะถึงไม่เห็น แต่เรารู้สึกได้ถึง quality ของงานตัวเอง ซึ่งพอต้องต่อยอดมัน สัญชาติญาณมันจะแม่นขึ้น ว่านี่มันควรจะง่ายหรือยาก แต่เด๋วก่อน! ทั้งหมดนี่มันไม่เกี่ยวกับความเร็วเลยนี่นา!? นี่มันแค่ก้าวสั้นๆที่มั่นคงขึ้นเท่านั้น แล้วเร็วล่ะ? เร็วไปไหน?
จริงครับ มันไม่ได้แค่มั่นคงขึ้น มันยังเร็วได้กว่าเดิม แต่ส่วนใหญ่ที่ไม่ได้สัมผัสความเร็วนั้น เพราะ
เปลี่ยนแค่เครื่องยนต์มันไม่พอครับ ต้องเปลี่ยนแผงหน้าปัดความเร็วด้วย ยิ่งขับรถเก่ง ก็ยิ่งไม่กล้าเร่งเกิน red zone ครับ
เพราะเรายังติด design แบบเดิมๆอยู่ครับ ณ ขั้นนี้ ถ้าเราได้ story มาแล้ว ก็เริ่มออกแบบ database แบบ 3NF (3rd Normal Form) เลย แยก header-detail สรรพเสร็จ ทุกอย่างเป็นไปตามสัญชาติญาณ ตรงนี้แหละครับ คือสลักที่ผนึกความเร็วเราไว้ครับ
ถอยกลับมาทบทวนซักนิด ถ้าเราใช้ 1NF ตอบโจทย์ได้ไหม? ถ้าได้ เราลงทุนทำ 3NF ทำไม? เพราะมันใช้เนื้อที่ได้คุ้มค่ากว่า? แล้วมั่นใจไหมครับว่า man-hour ของเรา 3 ชม.ที่เราจ่ายไปเพื่อซื้อพื้นที่ใน hard disk ใน database server เป็นอะไรที่ลูกค้าเราเค้าเห็นด้วยว่าคุ้มค่า? ได้เช็คกับ CEO หรือยังครับว่า release ระบบช้าลง 3 ชม. เสียหายน้อยกว่า 4 พัน (ราคาปัจจุบัน external hdd 500GB) ถ้าคนยังไม่ชินจะรู้สึกว่า ทำ 3NF ไปเลยดีกว่า ทำ 1NF เด๋วมันก็ต้องแก้ แต่จริงๆไม่มีใครรู้อนาคตหรอกครับ ถ้า requirement แถวนั้นเปลี่ยน แล้วต้องโยนทิ้งทั้งก้อน ทำ 1NF ต้องคุ้มกว่าทำ 3NF อยู่แล้ว จริงไหมครับ?
ดูเผินๆเหมือนทำชุ่ยๆเลยนะครับ (ผมเคยพูดใน Narisa.com ด้วยว่า agile สำหรับผมคือการทำชุ่ยๆแล้วค่อยไปแก้เอาดาบหน้า 
แล้วพี่ข้าวโพดหวานก็มา comment ว่าเป็น เป็นนิยามที่ล่อแหลมมากครับ ^ ^”) แต่นั่นแหละครับ ถ้าจะ agile ต้องห้ามละสายตาจากเป้าหมายครับ ถ้าได้ story มาก็จ้องแค่ acceptance criteria ครับ จะ code ไม่ต้องมอง keyboard จะ run ไม่ต้องมองจอ จ้อง acceptance criteria ไว้เป็นพอ
เริ่มยาวละ สรุปดีกว่า
กับดัก level 1 ของคนหัด adopt agile คือ พอทำ test แล้ว ไม่ยอม design แค่พอผ่านครับ
อย่าคิดว่าเด๋วก็ต้องแก้เป็นแบบที่กะไว้อยู่ดี ไม่งั้นต่อให้เขียน test แล้ว ก็ยัง design ระบบออกมาได้เหมือนเดิมครับ (เพราะคน design เป็นคนเดิม) ในเมื่อเราลงทุนเขียน test เพื่อลด refactor cost แล้ว ทำไมเราไม่ใช้ประโยชน์จาก refactor cost ที่ลดลงล่ะครับ? ในเมื่อลดจากแทงตาละ 10 เหลือแทงตาละบาท แต่เวลาได้ก็ได้เต็มๆเท่าเดิม ถ้าไม่แทงก็น่าเสียดายนะครับ เห็นด้วยไหมครับ? 
ปล.
- ผมพยายามให้อันนี้ abstract น้อยลง หวังว่าจะอำนวยความสะดวกให้ผู้อ่านได้มากขึ้นครับ
- หากมีข้อแนะนำติชมประการใด อย่ารีรอนะครับ ผมจะได้นำไปปรับปรุงต่อไปครับ
มีงานวิจัยจาก Microsoft พยายามเก็บข้อมูลว่ามันเร็วขึ้นจริง ๆ หรือเปล่า เค้าพบว่าเวลาเพิ่มขึ้นประมาณ 15% – 35% แต่พบว่า defect density ลดลง 40% – 90%
อ่านบทความเต็ม ๆ ได้ที่ http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx นะครับ
(ขอเพิ่มอีกนิด) อันนี้เป็นข้อมูลระหว่างทีมที่ทำ tdd กับไม่ทำนะครับ
จะว่าถูกมันก็ถูก แต่มันก็ไม่เสมอไป ตัวอย่างคร่าวนี้ดีกว่าเดิมเยอะ และประเด็นก็ชัดเจนขึ้นมาก แต่ก็ล่อแหลมจริงๆ
1NF กับ 3NF นี่มันออกจะ Extreme ไปนิด มันไม่ใช่ว่าเผื่อไม่เผื่อ มันอาจจะเป็นจริงๆในหลายๆเคส แต่มันก็ทำไม่ได้ในหลายๆเคสเหมือนกัน เช่น หากทำงานเกี่ยวกับการเก็บข้อมูลที่ต้องเก็บวันละ 1 ล้าน record หากตอนแรกทำเป็น 1NF และตอนหลังมีการเปลี่ยน requirement แล้วต้องมาทำ database migration มันก็คงจะไม่ใช่งานเล็กๆเช่นกัน แต่การออกแบบ 1NF กับ 3NF เวลาที่ใช้ design จริงๆมันไม่ต่างกันมาก โดยมากน่าจะเป็นเพียงแค่หลักนาที หรือแทบไม่แตกต่างเลย ยกเว้นคนที่ design ไม่มีความเชียวชาญด้าน DB เลย
อย่างไรก็ดี มันก็เป็นจริงในหลายๆเคส เช่น การปรับจาก 1NF เป็น 3NF อยู่ในขั้นตอนการ Development คือตอนนี้ story นี้ทำแค่ 1NF ก็พอ แต่พอไปถึง story อื่นๆเลยต้องปรับเป็น 3NF ซึ่งเป็นสิ่งที่ควรจะเป็นมากกว่า หรือให้ชัดกว่านี้คือ story แรกใช้วิธี Hardcode ค่าตัวแปรเข้าไปตรงๆเช่นกำหนดไปเลยว่า ค.ศ. + 543 = พ.ศ. แต่พอ story ถัดมาเลยต้องแก้เป็น ค.ศ.+ year_AC_BC_diff = พ.ศ. เป็นต้น
Simplicity เป็น 1 ในแนวคิดของ Agile แต่ Continuous attention to technical excellence and good design ก็เป็นแนวคิดของ Agile เช่นเดียวกัน แปลว่า Simplicity ที่ได้เกิดจาก technical excellence and good design ที่ทำอย่างต่อเนื่อง
คำว่า Good Design กับ Over Design ก็แตกต่างกันมาก แต่ก็แค่เส้นแบ่งบางๆเช่นกัน เพราะจากบทความอาจจะเข้าใจได้ว่า 1NF เป็น Good Design แล้ว 3NF เป็น Over Design
ล่อแหลม แต่เป็นบทความที่ดีครับ
ขอบคุณ resource เพิ่มเติมจากคุณ Jittat ครับ
ขอบคุณพี่ Bomber สำหรับ feedback และ comment เพิ่มเติมครับ เห็นด้วยมากๆครับว่ามันล่อแหลมจริงๆ แต่เชื่ออยู่ลึกๆว่าถ้าจ้อง acceptance criteria ไว้ เป็น solution หนึ่งที่ทำให้ได้สัมผัสมุมมองการ design ที่แตกต่าง (แน่นอนว่าจะวางใจได้หรือไม่อยู่ที่คุณภาพของ requirement)
สำหรับเรื่องการ design เส้นแบ่งระหว่าง Good design กับ Over design นั้นบางจริงๆ (ต่างคนต่างเห็นไปต่างๆกันด้วย)
agile designing (design ด่วน) เป็นอะไรที่ achieve ง่าย แต่ master ยาก ผมเชื่อว่าการมุ่ง accomplish acceptance criteria จะทำให้เกิดมุมมองการ design ที่แตกต่าง (อันนี้คือสิ่งที่อยากให้ลองครับ) แต่ต้องไม่ลืมว่า acceptance criteria ก็ผิดได้นะครับ ทั้งนี้ทั้งนั้นขึ้นกับคุณภาพของ requirement และ software process ที่เราใช้งานอยู่ครับ
ปล.
- สำหรับคนที่สงสัยว่า “อ้าว เราไม่ได้ใช้ agile process อยู่เหรอ?” คำตอบคือเปล่าครับ ทั้ง series ของผมอิงบนพื้นฐาน agile ชายเดี่ยว/หญิงเดี่ยวครับ
ยังรู้สึกขัดๆ คำการอธิบายเปรียบเทียบกับ 3NF อยู่ครับ
คือถ้าธรรมชาติของข้อมูลมันควรเป็น 3NF อยู่แล้ว(เช่นใบสั่งซื้อมีหลายรายการ)
แบบนี้ยังควรจะต้องพิจารณา 1NF อีกหรือไม่ครับ
ผมรู้สึกว่า solution ที่มีในทุกวันนี้ มันช่วย cover ปัญหาหลายๆ อย่างไปได้เยอะ (แต่ก็สร้างปัญหาใหม่เช่นกัน)
และช่วยเพิ่มความ dynamic ให้กับระบบ/ข้อมูลด้วย
การที่เราบอกว่า เราเน้น agile ต้องทำงานได้เร็ว หมายถึงเราควรจะต้องปฏิเสธ solution ต่างๆ
เพียงเพราะเรามองแค่จุดเดียว(story นั้นๆ)ว่า ทำแค่นี้ก็น่าจะพอ
เช่น ทำหน้า login … ซึ่งดูแค่จุดเดียว มันไม่จำเป็นต้องใช้เฟรมเวิร์กอะไรก็ได้
ทำ page ขึ้นมาอันเดียวก็น่าจะจบ เร็วด้วย
แต่กลายเป็นว่า ระบบไม่ได้ยืดหยุ่นเพียงพอที่จะเพิ่มเติม function ใหม่ๆ เข้าไป
ทำให้ใน story ต่อๆ ไป แทนที่จะเสียเวลานั่งทำแค่ story นั้น
ก็กลายเป็นว่าต้องไล่ refactoring ใหม่หมดแทบจะทุกครั้ง
เพราะว่า architecture โดยรวมมัน fix ไปเกือบหมดหมดเลย
ก็เลยงงๆ ว่า เน้น simple มากๆ ขนาดนี้ มันจะ agile ได้จริงหรือครับ ^^’
(เรื่อง over design นี่ก็เข้าใจอยู่ครับ แต่ถ้าไม่ design ให้ยืดหยุ่นไว้บ้าง น่าจะเหนื่อยทีหลังอยู่น่ะครับ)
ผมลองแล้วเร็วขึ้นครับ คุณ id=AItOawm3WxBhA3_NJVYFrvm4CtsR2z4_RCL97K8 ลองแล้วได้ผลอย่างไรกลับมาเล่าสู่กันฟังด้วยนะครับ
ไม่ใช่เราไม่ design แต่เราพยายาม delay process นั้นไปให้ไกลที่สุด จนถึงตอนต้องลงมือ
ตัว test case ที่เคยเขียนไว้มันจะช่วยเรื่องตอนถึงจังหวะต้องเปลี่ยนแปลงเอง
ต้องลองครับแล้วจะรู้ว่าเวลาที่เหลือมันมีคุณค่าให้ทำอย่างอื่นอีกแค่ไหน
คำว่า “ไม่ยืดหยุ่นพอ” เอาอะไรมาเป็นตัวชี้วัดละครับ? ถ้าไม่ใช่ test case ใหม่ๆ ของ user story ใหม่ๆ ที่มัน test ไม่ได้ หรือ test ไม่ผ่าน?
ถ้าอย่างนั้นคำว่า “ไม่ยืดหยุ่นพอ” ก็กลายเเป็นเรื่องที่ดีครับ
เพราะเราจะได้รู้ว่าเราไม่ได้นั่งคิดไปเองว่าต้อง refactoring แล้วนะ
แต่ด้วยปัจจัยที่ “วิธีเดิมมันไปต่อไม่ได้” จริงๆ
test case คือเพื่อนที่ดีที่สุดตอนต้องเปลี่ยนแปลง
สิ่งที่ทำมาแล้วไม่ได้ใช้ กองไว้ตรงนั้นมันเป็น waste ที่ต้อง maintain
สิ่งที่ทำแล้วได้ใช้ไปถึงมือลูกค้า แล้วลูกค้าพอใจคือสิ่งที่เราต้องการที่สุด
สลักที่ผนึกความเร็ว .. รบกวนแปลหน่อยค่ะ ไม่แน่ใจว่าเข้าใจถูกหรือเปล่า..
อย่างไรก็ตาม ชอบประโยคนี้
“ถ้าจะ agile ต้องห้ามละสายตาจากเป้าหมายครับ ถ้าได้ story มาก็จ้องแค่ acceptance criteria ครับ จะ code ไม่ต้องมอง keyboard จะ run ไม่ต้องมองจอ จ้อง acceptance criteria ไว้เป็นพอ”
มันทำให้ทำงานง่ายขึ้นจริงๆ นะ เป้าหมายมีไว้พุ่งชน ^_^
รออ่าน level ถัดไปนะคะ เก๋ว่า ตัวเองเป็นคนนึงที่กำลังไต่ตาม level บทความนี้้ด้วยความบังเอิญ
สลัก เป็นคำนาม (นึกถึงสลักระเบิดครับ)
ผนึก เป็นกิริยา ความหมายคล้ายๆยับยั้งไว้ครับ
ความเร็วน่าจะตรงตัวฮะ
สรุปแล้วผมตั้งใจให้จะสื่อว่า การ design ด้วยท่าเดิมๆ เป็นสิ่งที่ยับยั้งไว้ไม่ให้เราไปถึงความเร็วที่ควรจะเป็นครับ
ล่อแหลมจริงๆ เลยครับเนี้ยะ
สงสัยเราต้องนิยามคำว่า “พอดีผ่าน” กันด้วยนะครับ
ผมขอยก quote ตัวเองจากตอนที่แล้วมาแปะซ้ำนะครับ
==================
เส้นแบ่งระหว่าง “เผื่อ” กับ “เตรียมพร้อม” มันอยู่ที่ตรงไหน? จริงๆ มันคือเรื่องเดียวกันหรือเปล่า?
เป็นคำถามที่น่าสนใจนะครับ
ผมมองว่า test coverage ของ automated acceptance test ก็น่าจะเป็นตัวช่วยชี้วัดที่ดีว่า “เผื่อ” หรือ “ไม่เผื่อ”
ส่วน “พร้อม” หรือ “ไม่พร้อม” น่าจะดูที่ความสะอาดของ code มากกว่า
ถ้ามันอ่านง่าย สื่อ intention เข้าใจด้วยการกวาดสายตาทีเดียว ก็ถือว่า maintain ได้แล้วในระดับหนึ่ง ผมก็ถือว่า “เก็บงาน” เรียบร้อยแล้วละครับ
===================
ยังไงซะ test coverage ก็ต้องมี แล้วโค้ดก็ต้องเก็บให้สวยเข้าที่นะครับ (แต่ส่วนนั้นแหละที่เป็นศิลปะที่สอนยากกว่า)
เข้าเรื่องการ persist data กับประเด็น 3NF ที่ยกมานะครับ
ปกติไม่เคย design งานจาก data model ขึ้นมาเลยครับ จะ top-down ลงไปมากกว่า เช่นกัน
เรื่อง Database Normalization ก็จะไม่ได้ซีเรียสมากว่าต้อง 3NF เอาแค่ดูแล้วมันไม่เก็บข้อมูลซ้ำกันน่าเกลียดก็พอ จะได้ xNF ไหนก็ไมได้ใส่ใจมาก
แต่ทั้งนี้ทั้งนั้นเรื่องนี้ก็แล้วแต่ domain อีกเหมือนกันนะครับ ยิ่งยุ่งกับระะบ legacy เก่าๆ อาจต้องคิดให้มากขึ้น
relational database พอขึ้น production ไปแล้วเป็นส่วนหนึ่งที่ปรับยากนะครับ จะ migrate ทีต้องปวดหัวกันหลายรอบ การ refactoring database สำหรับบางคนเป็นศาสตร์มืด คนเลยบ่นว่ามันไม่ agile เท่าที่ควร
ผมจะพูดเข้าเรื่อง NoSQL นั่นแหละครับ
NoSQL เป็น database ทางเลือกอื่นที่ต่างจาก relational DB ที่เรารู้จัก มีหลายแบบหลายลายให้เลือก นอกจากจุดเด่นเรื่องการ scaling ที่ดีกว่าทางด้าน performance แล้ว คุณสมบัติอีกหนึ่งอย่างที่มักพบเห็นใน NoSQL ทุกตัวคือ schema-free ทำให้การเปลี่ยนแปลงทำได้ง่ายกว่า RDBS มาก
เรียกได้ว่า scaling ทั้ง performance ทั้ง scaling ตามวัยที่โตซับซ้อนขึ้นกันเลยทีเดียว
ว่าแล้วใครอยากคุย อยากฟังเรื่อง NoSQL เชิญที่ @OpenDream วันนี้นะครับ (เสาร์ที่ 6 มีนา) 10 โมงเป็นต้นไปครับ ฝากประชาสัมพันธ์กันต่อด้วยครับ
แล้วเจอกันครับ
ผมว่า การเขียนโค้ดแค่ให้พอให้เทสต์เคสผ่าน ไม่ได้แปลว่าเขียนแบบลุยแหลก ไม่มี design นะครับ
Concept น่าจะเป็นว่า ไม่ต้องเขียนโค้ดเผื่อให้ไปรองรับสิ่งที่ยังไม่แน่นอน หรือว่ามีเขียนไว้ใน User Story หลังๆมากกว่า แต่ถ้าเป็นเคสอย่าง database ถ้าเป็น 1NF กับ 3NF มันแน่เป็นแช่แป้งอยู่แล้วถ้าเรากำลังทำระบบ OLTP ยังไงซะ ก็ต้องทำอย่างน้อย 3NF เพราะว่าสามารถรู้ได้เลยว่ามันจะมีปัญหาเรื่องความซ้ำซ้อนแน่นอน ถ้าเกิดไม่ได้ทำ
แต่การไม่ over design ในความคิดผมน่าจะหมายถึง ยังไม่ต้องไปสร้างตารางเพื่อรองรับการเก็บข้อมูลสำหรับ User Story หลังๆที่มันไม่ได้เกี่ยวอะไรกับ User Story ที่เรากำลังทำอยู่ ตัวอย่างเช่น กำลังทำระบบ User Management อยู่ แต่ไป design ตารางเผื่อสำหรับระบบบัญชี อันนี้ก็ไม่ถูก
ส่วนเรื่อง performance หรือการรองรับ user จำนวนมาก เราอาจจะเขียนให้ชัดเจนไปเลย เช่นมี Story พิเศษว่าด้วยเรื่องเกี่ยวกับ Performance ของระบบ หรือว่าถ้า Performance เป็นอะไรที่ sensitive ก็สามารถใส่ไว้ใน acceptance criteria ของ User Story แต่ละตัวเลยก็ยังได้ ขอเพียงว่าให้มีจุดที่ใส่ไว้ให้ชัดเจน คนทำจะได้รู้ว่าควรจะทำมันเมื่อไหร่
สิ่งที่ผมทำในทีมก็คือ สร้าง design pattern ที่เหมาะสมสำหรับแต่ละโปรเจคให้มันเป็นสิ่งที่อยู่ในใจของทีม ตัวอย่างเช่นผมทำ web app และใช้ MVP – Passive View น้องในทีมเวลาเขียนคลาสสำหรับ User Story แรก ก็สามารถเอา MVP Pattern มาประกอบการสร้างคลาสได้ทันที ไม่ใช่เขียนแบบ class เดียวจบเพื่อให้แค่เทสต์เคสผ่าน ก่อนที่น้องจะเริ่มเขียนโค้ด ผมจะให้เขียน Sequence Diagram ออกมาก่อน เพราะจะได้สามารถมี senior มาช่วยรีวิว design ได้ก่อนเขียนโค้ด รู้ว่าสิ่งที่น้องคิดนั้นสมเหตุสมผลมั้ย
เรื่อง design pattern นี่ก็ต้องระวังนะครับ
ใจความสำคัญคือ ต้องให้ test เป็นตัว drive มันไปในทางนั้นจริงๆ
แม้เราจะมีความมั่นใจ 100% อยู่แล้วว่า pattern นี้แก้ปัญหาเราได้แน่ แต่มันมีอะไรมากกว่านั้นอีก
ประสบการณ์มีคุณค่ามาก “ทำผิดวันนี้เพื่อวันหน้าจะได้ไม่ทำซ้ำ” ประสบการณ์ตรงนี้สำคัญมาก
ให้เค้าเจอปัญหาด้วยตัวเอง เพื่อที่จะเรียนรู้วิธีการแก้ปัญหาด้วยตัวเอง
ถ้าไปเริ่มที่ MVP เลยโดยไม่เก็ตว่าปัญหาเดิมๆ คืออะไร ไม่ประสบด้วยตัวเอง แม้มันดูเหมือนจะไม่ over design แต่นั่นคือ over design แล้วสำหรับผม
สรุปเป็นสำนวนง่ายๆ ว่า
เกาเฉพาะส่วนที่คัน ถ้าไม่คันหรือไม่รู้ตัวว่าคันแล้วไปเกานั่นก็ over design แล้ว
ตอนนี้มันกลับกันนิดนึงครับสำหรับทีมผม คือทีมผมใช้การเริ่ม design จาก MVP เพราะมันทำให้เขียนเทสต์โค้ดได้ง่ายครับ สามารถแบ่งแยกงานได้เป็น step ชัดเจน ว่า
1) Discuss กันระหว่าง Dev,QC ช่วยกัน list flow สำหรับ User Story คล้ายๆกับในการทำ Use Case Detail คือ list Normal Flow, Alternate Flow ทั้้งหมด จากนั้นแยกย้ายไปทำ โดย QA ก็ไปทำเทสต์สคริปท์ของเค้า ส่วน Dev ก็มาทำข้อ 2) ต่อ
2) ทำ sequence diagram สำหรับ Normal Flow (ไม่ได้เขียน sequence สำหรับทุก flow ที่เกิดขึ้นใน user story นั้นแต่เอาแค่โฟล์หลัก เพื่อให้รู้ structure ของคลาส) ขั้นนี้จะทำได้ง่ายและเร็ว ถ้าเรามี pattern อยู่ในใจ สามารถบอกได้เลยว่าคลาสควรจะแบ่งเป็นกี่เลเยอร์ จะมีการคุยกันยังไง ทำให้น้องทั้งมือใหม่ที่ยังไม่เคยเจอปัญหาและมือเก่าที่นั่งรื้อโค้ดกันมาด้วยกัน ก็สามารถทำงานได้ในมาตรฐานเดียวกัน (มือใหม่อาจจะมีมือเก่ามาช่วยรีวิวในช่วงแรกๆ)
3) พอเราได้โฟลว์คร่าวๆมาจาก sequence diagram เราจะเริ่มเขียนเทสต์โค้ดก่อน โดย derived จากเทสต์เคสที่ออกแบบเอาไว้สำหรับ แต่ละ user story เราเน้นเรื่อง traceability มาก ว่าเทสต์เคสที่เขียนแต่ละตัวต้อง derived ย้อนกลับไปถึง requirement ใน requirement management system ของ product manager
4) เขียนโค้ดเพื่อทำให้เทสต์เคสผ่าน
แก้คำผิดครับ 1) Dev,QA
เพิ่มเติม:
ผมว่าการที่ทำให้น้องแต่ละคนในทีมทำงานได้มาตรฐานใกล้เคียงกันเป็นเรื่องสำคัญ เพราะว่ามันมีผลไปหลายอย่างครับ ตั้งแต่ความแม่นของการทำ Estimation เพื่อเอาไป commit plan รวมไปถึงคุณภาพของโค้ดโดยรวมที่เราต้องดูแลให้ลูกค้าด้วย
ครับปรับตามสภาพองค์กรณ์ไปนั่นแหละถูกแล้วครับ
สุดท้ายแล้วผลลัพธ์จะออกเป็น MVP ทั้งหมดก็ไม่ใช่ประเด็นที่ต้องการสื่อครับ
ผมแค่อยากสื่อว่า ทุกคนได้รู้ว่าเรากำลังแก้ปัญหาอะไรอยู่ ได้เจอปัญหาด้วยตัวเองแล้วได้ลอง refactoring ไปเป็น MVP สักครั้งเพื่อให้รู้ว่า “เออ เราเจอปัญหาจริงๆ แล้ว MVP มันช่วยแก้ได้จริงๆ แหะ”
อย่างน้อยสักครั้งในชีวิต
เสริมอีกนิดครับว่าหลังจากทำ TDD แล้วเจอปัญหานั้นด้วยตัวเองสักครั้งสองครั้ง แล้วได้ลอง refactoring กับมือตัวเอง จากนั้นจะลัดขั้นตอนไปบาง step บ้างก็ไม่เป็นไร ไม่ต้องเริ่ม process เดิมใหม่ทั้งหมด
ส่วนจะลัดเยอะลัดน้อยอาศัยสัญชาตญาณบอกความ comfortable ครับ
โหมดนี้ผมจะเรียกว่า “in the mood” โหมด คือเป็นโหมดที่เราเจออะไรเดิมๆ
พอเราลัดไปเยอะเกินจนรู้สึกไม่ปลอดภัยก็ลด speed ลงสู่โหมด “โง่” เพื่อทำ spike solution ต่อ
เปรียบเทียบเหมือนขับรถนะครับ
โหมดแรกเหมือนขับรถกลับบ้าน ทางเดิมที่คุ้นเคย ทุกเลี้ยว ทุกมุก รู้ไส้รู้พุง
โหมดสองเหมือนขับรถไปที่ๆ ไม่รู้จัก ขับช้าๆ ชิดซ้าย หูตาระแวดระวัยเป็นพิเศษ
ผมว่าปัญหาคือ คำว่า “พอผ่าน” ของแต่ละคนไม่เท่ากัน
สำหรับผม คำว่า “พอผ่าน” และการที่จะไม่ over design คือ
การทำ Model-First ครับ ผมจะไม่ทำ Database ก่อน ฉะนั้นจึงตัดปัญหาเรื่อง 1NF หรือ 3NF ไปได้
พอผมได้ story ได้ requirement มาทั้งหมด จะขึ้น design ครับ โดยขึ้น object model ก่อนเลยครับ ตามมาด้วย service model แล้วก็ Test ความครบถ้วน functional และ non-functional ในหัวข้อพวก quality attribute ต่างๆด้วย (เนื่องจากเป็น architect ด้วย) ดูว่า object model มี ครบที่ต้องการหรือเปล่า อะไรประมาณนี้
ซึ่ง model พวกนี้ ผมจะไม่ทำเผื่อ ครับ อะไรที่จะต้อง แก้ภายหลัง ก็คือต้องแก้ ครับ เลี่ยง ไม่ได้ ซึ่งอาจจะเกิดมาจาก change หรืออะไรก็ตาม แต่ถ้าข้อไหน คิดแล้วว่ามัน แปลกๆ ผมก็เผื่อไว้อยู่ดี ครับ แต่ เคส ที่จะเผื่อเกิด น้อยมากครับ
แถม effort ที่ได้ไปจากผมก็น้อยนิดซะเหลือเกิน เมื่อเทียบกับ effort โดยรวม ไม่ถึง 1%
+1 ครับ
อืมมม อ่าน comment ของหลายๆคนแล้วอยากให้ลองไปงาน NoSQL จังเลยครับ
คือ บางกรณีข้อมูลบางอย่างใช้แค่ 1NF ก็พอจริงๆ เช่น Transaction Log หรือ บางทีก็มีเก็บเป็น List ของข้อมูลใน Field เช่นงานพวกเก็บค่า User Preference เป็นต้น
มันแล้วแต่ความเหมาะสม มิใช่ว่าต้องเป็น 3NF เสมอ
@bomber ผมถึงได้ใส่ไว้ว่าเป็น OLTP ไงครับ
แต่เรื่อง NoSQL นี่น่าสนใจครับ คร่าวๆสั้นๆมันคืออะไรเหรอครับ
สรุปสั้นๆ มันคือ database ทางเลือกอื่นที่ไม่ใช่ Relational Database ที่เราคุ้นเคยนะครับ มีหลายรสให้เลือกครับ แตกต่างกันไปตามลักษณะ domain ที่พยายามแก้ปัญหา
ยาวจัง อย่างกะ ดราม่า กว่าจะอ่านจบได้รับความรู้เพิ่มขึ้นมากมาย ขอบคุณทั้งคนเขียนและคนเม้นท์
อันนี้เดี๋ยวพี่แก้ให้
**** น้อง jua ลืมแก้ URL ของ Post ให้เป็นภาษาอังกฤษนะครับ
มันเหมือนดราม่าเพราะความไม่ชัดเจนในการยกตัวอย่างของผมเองครับ แถมยังลืมแก้ URL อีก (-/\-)
ยอมรับว่าตัวอย่างที่ยกมามันก็ยังคลุมเครือจริงๆแหละครับ ในใจคิดการ design object แต่เปลี่ยนไปเป็น *NF ของ database เพราะอยากให้ส่วนอื่น (ที่ไม่เกี่ยวกับ agile) มันง่าย รองรับผู้อ่านได้เยอะๆ แต่อาจจะก้าวผิดก็ได้ (T-T)
ขอบคุณสำหรับทุกๆ comments ครับ ผมเห็นด้วยกับทุกๆ comments เลยนะครับ comments ของทุกๆท่าน ช่วยมาถ่วงดุลย์ส่วนที่ขาดไปทำให้กระทู้นี้สมบูรณ์ขึ้นครับ ^ ^
เท่าที่ผมอ่านความเห็นจากทุกๆท่าน สรุปได้ว่าบทนี้ล่อแหลมเพราะคำว่า”พอผ่าน”แต่ละท่านไม่เท่ากัน (แม่นไม่แม่นอยู่ที่ประสบการณ์ในการ design และความเข้าใจใน business domain) ตรงนี้ผมเห็นด้วยครับว่าควรระวัง
แต่ผมเห็นว่าหลายๆท่านเห็นพ้องด้วยว่าไม่ว่าคนๆหนึ่งจะคุ้นเคยกับ business domain หรือมีประสบการณ์การ design มาก/น้อย แค่ไหนก็ตาม ถ้า test นั้นเริ่ม drive design หน้าตาของ architecture จะต้องออกมาไม่เหมือนกันครับ เรียนรู้จากความต่างของ architecture ผลลัพธ์ที่ออกมา เพื่อพัฒนา skills ด้านอื่นๆ แล้วเราจะเร็วยิ่งๆขึ้นไปอีกครับ
ใครบ้างครับที่รู้สึกว่าทุกวันนี้ทำงานไปวันๆแล้วปีหนึ่งที่ผ่านมาไม่ได้เก่งขึ้นซักเท่าไหร่เลย? ใครบ้างที่กำลังหวั่นไหวว่าเราย่ำอยู่กับที่? ถ้าท่านลงมือ develop test มาคลุม code แล้ว ก็ลองใช้ประโยชน์จากความยืดหยุ่นที่สร้างมาดูครับ อย่างที่ผมสรุปไว้ จริงๆมันเหมือนกับการแทง ไม่ได้แปลว่าจะถูกเสมอไป แต่แค่มี test แล้วเวลาเสียมันเสียน้อยลงเท่านั้น
May agileness files under your wings ครับ!
อ่อ ลืมบอกว่าผมเปลี่ยนจาก ‘เพราะอันที่แล้วมันห่วย’ >> ‘เพราะอันที่แล้วมันอาร์ต’ นะครับ จากที่เก็บ feedback เพิ่มเติมมา มีผู้อ่านที่ชอบอันที่แล้วมากกว่าอันนี้อยู่บ้างเหมือนกัน เลยคิดว่าเปลี่ยนชื่อซักหน่อยดีกว่า ^ ^”
โดยส่วนตัวแล้วชอบชิ้นงาน version ที่แล้วมากกว่า แต่ชอบแนวทางของ version นี้มากกว่า ใกล้ถึงบทสุดท้ายแล้วครับ ที่วางแผนไว้น่าจะมีถึง level 4 แล้วจะสรุปผลครับ แล้วปริศนาทุกอย่างจะกระจ่าง ขอเอาชื่อปู่คินดะอิจิเป็นเดิมพันครับ!
[...] Agile ที่ level 1 (ทั้งเก่าและใหม่) ผมพยายามดันให้ลดการเผื่อ [...]