วันก่อนครับ ในขณะที่ขับรถไปกับเพื่อนสนิทท่านหนึ่งก็ได้คุยกันไปเรื่อยๆ คุยไปคุยมาก็นึกถึงเรื่องที่ทำให้ผมเริ่มสนใจใน Agile ขึ้นมาได้ เลยอยากมาแชร์
นั่นคือเรื่อง Estimation หรือแปลเป็นไทยก็คือการ ประเมิน
ผมมีปัญหากับการประเมินมากๆ รู้สึกแย่สุดๆเวลาที่ต้องประเมินงานสักงานหนึ่ง ต้อบมาตอบคำถามว่า งานนี้ต้องใช้เวลาเท่าไหร่ หรือ บั๊กนี้ต้องใช้เวลาเท่าไหร่ในการแก้ WTF! ผมจะไปตอบได้ยังไง
มีผู้ใหญ่ท่านหนึ่งบอกผมว่าให้ทำบ่อยๆ เดี๋ยวจะประเมินแม่นขึ้นเรื่อยๆเอง
แต่ผมว่า งานแต่ละงาน มันมีรายละเอียดไม่เหมือนกันนะ ผมนึกไม่ออกเลยว่าเราจะประเมินแบบนี้แม่นขึ้นได้ยังไง
เพราะฉะนั้น สิ่งที่ทำได้ก็มีเพียงการเดาเท่านั้นแหละครับ ก็เลือกตัวเลขขึ้นมาสักตัวแล้วก็ลงเวลาไป
ทีนี้ก็จะมีคำถามต่อมาอีกว่า เฮ้ยตัวเลขนี้มาได้ยังไง เยอะไปมั้ย ฯลฯ ต้องมานั่งต่อรองกันอีก เป็นเรื่องที่ผมเหนื่อยหน่ายมาก
ผมจึงเริ่มออกตามหาว่าโลกภายนอกเขาทำกันยังไงนะ หลักการที่ถูกต้องมันคืออะไร ก็เลยได้เจอคลิปวีดีโอในเว็บ Youtube เข้าอันหนึ่ง (ผมหาเท่าไหร่ก็หาไม่เจอ เนื่องจากมันนานมากๆแล้ว เลยไม่สามารถหามาแปะตรงนี้ได้ ขอโทษด้วยครับ -/\-) เป็นการแนะนำ Session ของงานสัมมนางานไหนสักงานหนึ่งนี่แหละ เมื่อประมาณปี 2011-2012
ในคลิปนั้นเป็นลุงหัวเกรียนๆคนหนึ่งออกมาขายของ แกเล่าให้ฟังว่า เวลาเราประเมินว่างานงานหนึ่งมันใหญ่ขนาดไหนนี่เราทำยังไง เราก็กะๆเอาใช้มั้ยครับ แต่เราไม่มีทางรู้ได้หรอกว่ามันใหญ่หรือเล็กจริงๆ
ลองเอาขวดน้ำขวดหนึ่งมาวาง แล้วลองกะดูสิว่าขวดนี้มันใหญ่หรือเล็ก ทำไม่ได้ใช้มั้ยล่ะ
ทีนี้ มันจะดีกว่ามั้ยถ้าเรามีขวดน้ำที่ใหญ่กว่ามาวางคู่กันให้เทียบได้ง่ายๆ อันนี้เป็นการประเมินแบบ Relative เป็นเทคนิคการEstimateอันหนึ่งที่ใช้ใน Agile ครับ
ผมนี่อึ้งไปเลยครับ โคตรจะ make sense มันมีวิธีแบบนี้ในโลกด้วยเหรอวะเนี่ย
หลังจากดูจบ ผมก็ไม่รอช้ารีบหาข้อมูลทันทีว่าตาลุงหัวเกรียนนี่คือใครกัน แล้วก็ได้เข้าร่วมชั้นเรียน Spartan ได้รู้จักกับเหล่าเกรียนส์ SPRINT3R และนั่นก็คือจุดเริ่มต้นเส้นทาง Agile ของผมครับ
ป.ล.ผมยังตามหาวีดีโอนี้อยู่นะ ใครเจอรบกวนแจ้งเบาะแสด้วย -/\-
Tuesday, May 26, 2015
Sunday, May 17, 2015
อย่าเพิ่งรีบเก็บโต๊ะตอนกำลังกิน
สวัสดีครับ วันนี้มาฟังพี่ปุ๋ย เจ้าของ somkiat.cc แบ่งปันเรื่องการเขียนบล็อก
มีสิ่งที่ดีเก็บกลับมาใช้ได้หลายอย่าง แต่ที่อยากนำมาแบ่งปันในบทความนี้คือเรื่องวิธีการเขียน
พี่ปุ๋ยแนะนำว่า เขียนให้เสร็จไปก่อนแล้วค่อยกลับมาดูเพื่อแก้ไขมันทีหลัง
สาเหตุสำคัญเลยที่เวลาเรากำลังพยายามเขียนบล็อกแล้วล้มเหลวคือ "เขียนไปแล้วแก้ไป"
พิมพ์ไปสองสามตัว แล้วก็ย้อนกลับมาดู เอ๊ะ มันดูดีมั้ยนะ แก้ตรงนี้หน่อยดีกว่า ประโยคนี้จะโดนคนด่ามั้ย เฮ้ยอันนี้พิมพ์ผิด อ้าวอ่านไม่รู้เรื่อง ฯลฯ ส่วนใหญ่แล้วจะกลัวไปเองด้วยนะ แล้วก็พิมพ์ๆแก้ๆมันอยู่อย่างนั้น ถ้าโชคดีก็เข็นจนเสร็จได้
แต่ส่วนใหญ่แล้ว ผมจะเลิกเขียน แล้วก็ปล่อยให้มันอยู่สถานะ draft ไปทั้งอย่างนั้น
แน่นอนว่าไอ้ draft พวกเนี้ย เราไม่เคยเอามาเขียนต่อจนมันเสร็จเลย!
เรื่อง draft นี่พี่ปุ๋ยแกแนะนำให้ลบทิ้งไปให้หมดครับ เพราะถ้าคุณทิ้งไว้นาน ก็คงลืมไปหมดแล้วล่ะ ว่าจะเขียนต่อยังไง
ที่ไอ้คำแนะนำที่ว่าให้เขียนๆไปก่อนเนี่ย ก็มีอยู่ใน Online course ของ Coursera เหมือนกันครับ ในชั้่นเรียน Learning how to learn ซึ่งก็มีนักเขียนมือโปรมาแชร์เกี่ยวกับวีธีการเขียนหนังสือเหมือนกัน คำแนะนำก็ประมาณนี้เลย คือ
"Don't clean table while you are dining."
ขออภัย ผมจำประโยคแบบเป๊ะๆไม่ได้ แต่ใจความก็ราวๆนี้แหละ ซึ่งก็เป็นที่มาของชื่อบทความนี้นั่นเองครับ ถ้าสนใจก็ไปลงเรียนกันได้ครับ เป็นชั้นเรียนที่ดีมากๆ เลยครับ แนะนำๆ
คำแนะนำนี้สามารถนำไปปรับใช้กับการเขียนโค้ดได้เหมือนกันนะครับ
ขอยกขั้นตอนของ TDD มาแปะ มีอยู่ว่า
การเขียนให้เสร็จไปก่อนค่อยกลับมาแก้เนี่ย ก็คือ Make it work หรือสรุปอีกทีก็คือการทีเราเลือกแก้ทีละปัญหานั่นเองครับ
ตรงนี้มีคำอธิบายเพิ่ม +Chokchai Phatharamalai เคยเล่าให้ฟัง ก็คือตอนที่เราเขียนกับตอนที่เราแก้เนี่ย มันใช้สมองคนละซีกกันครับ ตอนเขียนทีแรก เราใช้สมองด้านเหตุผล แต่ตอนที่แก้ไขหรือตกแต่ง ใส่รูป ฯลฯ เราใช้ด้านอารมณ์ ซึ่งตรงนี้สมองของเราจะมีจังหวะของมันครับ เรื่องพวกนี้มีอยู๋ในชั้นเรียน Learning how to learn เช่นกัน
ผมว่าแนวคิดนี้นำไปปรับใช้ได้กับหลายๆอย่างเลยนะครับไม่ใช่แค่การเขียน ลองดูครับผม
มีสิ่งที่ดีเก็บกลับมาใช้ได้หลายอย่าง แต่ที่อยากนำมาแบ่งปันในบทความนี้คือเรื่องวิธีการเขียน
พี่ปุ๋ยแนะนำว่า เขียนให้เสร็จไปก่อนแล้วค่อยกลับมาดูเพื่อแก้ไขมันทีหลัง
สาเหตุสำคัญเลยที่เวลาเรากำลังพยายามเขียนบล็อกแล้วล้มเหลวคือ "เขียนไปแล้วแก้ไป"
พิมพ์ไปสองสามตัว แล้วก็ย้อนกลับมาดู เอ๊ะ มันดูดีมั้ยนะ แก้ตรงนี้หน่อยดีกว่า ประโยคนี้จะโดนคนด่ามั้ย เฮ้ยอันนี้พิมพ์ผิด อ้าวอ่านไม่รู้เรื่อง ฯลฯ ส่วนใหญ่แล้วจะกลัวไปเองด้วยนะ แล้วก็พิมพ์ๆแก้ๆมันอยู่อย่างนั้น ถ้าโชคดีก็เข็นจนเสร็จได้
แต่ส่วนใหญ่แล้ว ผมจะเลิกเขียน แล้วก็ปล่อยให้มันอยู่สถานะ draft ไปทั้งอย่างนั้น
แน่นอนว่าไอ้ draft พวกเนี้ย เราไม่เคยเอามาเขียนต่อจนมันเสร็จเลย!
ขโมยรูปมาจาก facebook ของพี่ปุ๋ย https://www.facebook.com/photo.php?fbid=10153321436038588&set=a.424501298587.197700.590338587&type=1&permPage=1
เรื่อง draft นี่พี่ปุ๋ยแกแนะนำให้ลบทิ้งไปให้หมดครับ เพราะถ้าคุณทิ้งไว้นาน ก็คงลืมไปหมดแล้วล่ะ ว่าจะเขียนต่อยังไง
ที่ไอ้คำแนะนำที่ว่าให้เขียนๆไปก่อนเนี่ย ก็มีอยู่ใน Online course ของ Coursera เหมือนกันครับ ในชั้่นเรียน Learning how to learn ซึ่งก็มีนักเขียนมือโปรมาแชร์เกี่ยวกับวีธีการเขียนหนังสือเหมือนกัน คำแนะนำก็ประมาณนี้เลย คือ
"Don't clean table while you are dining."
ขออภัย ผมจำประโยคแบบเป๊ะๆไม่ได้ แต่ใจความก็ราวๆนี้แหละ ซึ่งก็เป็นที่มาของชื่อบทความนี้นั่นเองครับ ถ้าสนใจก็ไปลงเรียนกันได้ครับ เป็นชั้นเรียนที่ดีมากๆ เลยครับ แนะนำๆ
คำแนะนำนี้สามารถนำไปปรับใช้กับการเขียนโค้ดได้เหมือนกันนะครับ
ขอยกขั้นตอนของ TDD มาแปะ มีอยู่ว่า
- Make it work.
- Make it right.
- Make it fast.
การเขียนให้เสร็จไปก่อนค่อยกลับมาแก้เนี่ย ก็คือ Make it work หรือสรุปอีกทีก็คือการทีเราเลือกแก้ทีละปัญหานั่นเองครับ
ตรงนี้มีคำอธิบายเพิ่ม +Chokchai Phatharamalai เคยเล่าให้ฟัง ก็คือตอนที่เราเขียนกับตอนที่เราแก้เนี่ย มันใช้สมองคนละซีกกันครับ ตอนเขียนทีแรก เราใช้สมองด้านเหตุผล แต่ตอนที่แก้ไขหรือตกแต่ง ใส่รูป ฯลฯ เราใช้ด้านอารมณ์ ซึ่งตรงนี้สมองของเราจะมีจังหวะของมันครับ เรื่องพวกนี้มีอยู๋ในชั้นเรียน Learning how to learn เช่นกัน
ผมว่าแนวคิดนี้นำไปปรับใช้ได้กับหลายๆอย่างเลยนะครับไม่ใช่แค่การเขียน ลองดูครับผม
Saturday, May 16, 2015
เขียนเทสนี่มันยากจริงๆ
เราไม่ชอบเขียนเทสเพราะอะไรกันนะ
ย้อนกลับไปสมัยผมเริ่มทำงานใหม่ๆ ก็ถูกบอกให้เขียนเทสเหมือนกัน
แต่ไม่มีใครบอกว่าต้องทำยังไง
เลยทำไปแบบงงๆ เขียนโปรแกรมให้มันทำงานได้ก่อนก็แล้วกัน
พองานเสร็จ เราจะมาเขียนเทส ก็พบว่า ทำไมมันยากจังวะ
เท่าที่นึกได้ก็ประมาณนี้ สุดท้ายแล้ว ก็ไม่มีใครทำ ทำยาก เสียเวลา เวลา Requirement เปลี่ยนทีนึง เทสที่เขียนไว้ก็พัง ต้องมาแก้อีก ยิ่งเสียเวลาเข้าไปใหญ่ กว่าจะดีบั๊กจนแก้ได้ ไม่ได้มีเวลาขนาดนั้นนะว้อย
แล้วก็เลิกเขียนเทสกันไปในที่สุด มีใครมีอาการคล้ายๆผมอย่างนี้บ้างไหมครับ :)
ย้อนกลับไปสมัยผมเริ่มทำงานใหม่ๆ ก็ถูกบอกให้เขียนเทสเหมือนกัน
แต่ไม่มีใครบอกว่าต้องทำยังไง
เลยทำไปแบบงงๆ เขียนโปรแกรมให้มันทำงานได้ก่อนก็แล้วกัน
พองานเสร็จ เราจะมาเขียนเทส ก็พบว่า ทำไมมันยากจังวะ
- เขียนเทสนี่มันเขียนยังไง ไม่เห็นมีใครมาบอก ในมหาลัยก็ไม่ได้สอน
- Test case เค้าออกแบบกันยังไง
- อยากจะเทสแค่หน่อยเดี่ยว ทำไมต้อง setup นู่นนี่นั่นเต็มไปหมด
- แล้ว UI ล่ะ จะเทสยังไง
- Database ต้องมา Roll back ทุกครั้งที่รัน unit test เนี่ยนะ !?
เท่าที่นึกได้ก็ประมาณนี้ สุดท้ายแล้ว ก็ไม่มีใครทำ ทำยาก เสียเวลา เวลา Requirement เปลี่ยนทีนึง เทสที่เขียนไว้ก็พัง ต้องมาแก้อีก ยิ่งเสียเวลาเข้าไปใหญ่ กว่าจะดีบั๊กจนแก้ได้ ไม่ได้มีเวลาขนาดนั้นนะว้อย
แล้วก็เลิกเขียนเทสกันไปในที่สุด มีใครมีอาการคล้ายๆผมอย่างนี้บ้างไหมครับ :)
Saturday, May 2, 2015
การต่อ Micro Block กับการเขียนโค้ด
สวัสดีครับ วันนี้ผมได้นำเอาตัวต่อ Micro block (ของก็อป แหะๆ) ที่ซื้อมาดองไว้นานมาแล้ว เอามาต่อเล่นเสียที
โดยในการต่อจะมีเทคนิคอย่างหนึ่งที่ผมค้นพบเอง ซึ่งก็มั่นใจว่าไม่ใช่ผมคนเดียวหรอกที่มีเทคนิคแบบนี้ เอาเป้นว่าผมยังไม่เคยเจอบทความหรืออะไรก็ตามที่แนะนำเทคนิดการต่อลักษณะนี้อย่างจริงจังก็แล้วกันนะ
โอเค กลับมาที่การต่อ Micro block ของผมนี่ ขอเล่าย้อนไปสักเล็กน้อยตอนที่ผมเริ่มซื้อมาต่อกล่องแรก ก็ไม่มีอะไรมาก ก็กางคู่มือความหาชิ้นส่วนจากในกองมาต่อๆ จนเสร็จ
แต่ผมค้นพบว่า การคุ้ยหาชิ้นส่วนมาจากกองนั้นมันเหนื่อยเอามากๆ
ยิ่งถ้าเป็นตัวที่รายละเอียดสูงๆล่ะก็ ยิ่งเหนื่อยมากขึ้นไปอีก -_-'
แถมความแสบของเจ้าตัวต่อจีนแดงนี้อีกอย่างหนึ่งคือ มันให้ชิ้นส่วนมาไม่ครบ!!
ลองคิดดูนะฮะ ว่ามันปวดร้าวแค่ไหน ที่ชิ้นส่วนที่คุณหามาเนิ่นนานน่ะ มันไม่มีอยู่อ่ะ ;_;
นี่อาจจะเป้นสาเหตุของการดองเรื่องต่างๆเอาไว้ของมนุษยชาติก็ได้นะครับ แหะๆๆ
โอเค กลับมาเข้าเรื่อง ที่นี้ตัวต่อๆมาผมก็พยายามแก้ไขปัญหานี้ครับ ด้วยการแบ่งแยกมันออกเป็นกองๆ ตามประเภท และ สี ของมันซะ แบบในรูป
ที่นี้การต่อก็เป็นเรื่องง่ายกว่าเดิมหลายเท่าเลยครับ เราสามารถหาชิ้นส่วนที่เราต้องการได้เร็วมากๆ ชิ้นส่วนไหนมันไม่มีมาให้ ก็หาชิ้นสีอื่นที่เหลือเยอะๆมาแทนได้ง่ายมาก
ที่ว่ามานั้นมันทำให้ผมนึกถึงข้อความนี้ในบทที่ 10 ของหนังสือ Clean code ของ Robert C. Martin ครับ
"Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?"
ลองกลับไปมองดูโค้ดของเรานะครับว่าเราได้จัดการมันดีพอหรือเปล่า มันถูกออกแบบให้อยู่ตามชั้นวางหรือลิ้นชักมีฉลากติดตามหน้าที่ของมันอย่างดี ให้เวลาจะนำมาใช้ก็ทำได้ง่าย หรือมันกองรวมๆกันอยู่เวลาจะหยิบมาใช้ที่นึงต้องใช้เวลาคุ้ยเป็นวันๆ กว่าจะได้ใช้ แล้วกว่าจะทำให้ฟีเจอร์ที่เรากำลังจะทำมันใช้ได้อีกละ บางทีหาไม่เจอละ หรือมันพันกับชิ้นส่วนอื่นยุ่งมากๆ ก็ทำใหม่เลยละกัน โอ... เหนื่อยน่าดูเลยนะครับนั่น
อันนี้เป็นลิงค์ของหนังสือ Clean code ครับ http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
เออ เอามาโยงกันได้ไงนะ สงสัยผมจะจินตนาการมากไปละ
อ้อ ของแท้เขาเรียกว่า Nano block นะครับ ถ้าใครมีทุนทรัพย์ก็ช่วยอุดหนุนเขาหน่อยนะ ผมเองก็มีอยู่บ้างตัวสองตัวครับ อิอิ
โดยในการต่อจะมีเทคนิคอย่างหนึ่งที่ผมค้นพบเอง ซึ่งก็มั่นใจว่าไม่ใช่ผมคนเดียวหรอกที่มีเทคนิคแบบนี้ เอาเป้นว่าผมยังไม่เคยเจอบทความหรืออะไรก็ตามที่แนะนำเทคนิดการต่อลักษณะนี้อย่างจริงจังก็แล้วกันนะ
โอเค กลับมาที่การต่อ Micro block ของผมนี่ ขอเล่าย้อนไปสักเล็กน้อยตอนที่ผมเริ่มซื้อมาต่อกล่องแรก ก็ไม่มีอะไรมาก ก็กางคู่มือความหาชิ้นส่วนจากในกองมาต่อๆ จนเสร็จ
แต่ผมค้นพบว่า การคุ้ยหาชิ้นส่วนมาจากกองนั้นมันเหนื่อยเอามากๆ
ยิ่งถ้าเป็นตัวที่รายละเอียดสูงๆล่ะก็ ยิ่งเหนื่อยมากขึ้นไปอีก -_-'
แถมความแสบของเจ้าตัวต่อจีนแดงนี้อีกอย่างหนึ่งคือ มันให้ชิ้นส่วนมาไม่ครบ!!
ลองคิดดูนะฮะ ว่ามันปวดร้าวแค่ไหน ที่ชิ้นส่วนที่คุณหามาเนิ่นนานน่ะ มันไม่มีอยู่อ่ะ ;_;
นี่อาจจะเป้นสาเหตุของการดองเรื่องต่างๆเอาไว้ของมนุษยชาติก็ได้นะครับ แหะๆๆ
โอเค กลับมาเข้าเรื่อง ที่นี้ตัวต่อๆมาผมก็พยายามแก้ไขปัญหานี้ครับ ด้วยการแบ่งแยกมันออกเป็นกองๆ ตามประเภท และ สี ของมันซะ แบบในรูป
ที่นี้การต่อก็เป็นเรื่องง่ายกว่าเดิมหลายเท่าเลยครับ เราสามารถหาชิ้นส่วนที่เราต้องการได้เร็วมากๆ ชิ้นส่วนไหนมันไม่มีมาให้ ก็หาชิ้นสีอื่นที่เหลือเยอะๆมาแทนได้ง่ายมาก
ที่ว่ามานั้นมันทำให้ผมนึกถึงข้อความนี้ในบทที่ 10 ของหนังสือ Clean code ของ Robert C. Martin ครับ
"Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?"
ลองกลับไปมองดูโค้ดของเรานะครับว่าเราได้จัดการมันดีพอหรือเปล่า มันถูกออกแบบให้อยู่ตามชั้นวางหรือลิ้นชักมีฉลากติดตามหน้าที่ของมันอย่างดี ให้เวลาจะนำมาใช้ก็ทำได้ง่าย หรือมันกองรวมๆกันอยู่เวลาจะหยิบมาใช้ที่นึงต้องใช้เวลาคุ้ยเป็นวันๆ กว่าจะได้ใช้ แล้วกว่าจะทำให้ฟีเจอร์ที่เรากำลังจะทำมันใช้ได้อีกละ บางทีหาไม่เจอละ หรือมันพันกับชิ้นส่วนอื่นยุ่งมากๆ ก็ทำใหม่เลยละกัน โอ... เหนื่อยน่าดูเลยนะครับนั่น
อันนี้เป็นลิงค์ของหนังสือ Clean code ครับ http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
เออ เอามาโยงกันได้ไงนะ สงสัยผมจะจินตนาการมากไปละ
อ้อ ของแท้เขาเรียกว่า Nano block นะครับ ถ้าใครมีทุนทรัพย์ก็ช่วยอุดหนุนเขาหน่อยนะ ผมเองก็มีอยู่บ้างตัวสองตัวครับ อิอิ
Subscribe to:
Posts (Atom)