Archive | มั่วๆ RSS feed for this section

ล้างไพ่

อาบน้ำอยู่ก็คิดถึงวิธีนี้ขึ้นมา คิดว่าไม่ได้ใหม่อะไรแต่มันไม่มีอยู่ในขั้นตอนการทำงานปัจจุบัน แต่น่าจะทำให้ QA กะ Dev ทำงานมีความสุขขึ้นอีกเล็กน้อยเพราะไม่เห็นอะไรยาวเป็นหางว่าวเหมือนปัจจุบัน เริ่มจาก Milstone1 เป็นช่วงที่ปั้นโครงของระบบทั้งหมดว่าหน้าตาจะเป็นอย่างไร Feature หลักเป็นอย่างไรบ้าง เป็นตัวกำหนดว่าสิ่งที่ทำคืออะไร Milestone2 หลังจาก Milestone1 ถูกโยนให้ QA และได้ Feedback มาแล้ว Milestone นี้จะเลือก Feedback บางอย่างมาทำ จากนั้นโยน Feedback ที่เหลือทิ้งทั้งหมด ไม่มีการเอามาจัดคิวใดๆ ทั้งสิ้น Milestone3 ทำเหมือน Milestone2 คือหลังจากได้รับ Feedback จาก QA ก็เลือกแล้วโยนทิ้ง ทำแบบนี้ไปเรื่อยๆ จน Release ไม่มีการเก็บ Feedback ที่ไม่ได้ทำเอาไว้ Feedback ที่ว่าอาจเป็น Bug, Requirement ที่ลิมทำ หรืออะไรก็แล้วแต่ที่ Dev ลืม ที่ทำแบบนี้เพราะว่า Feedback ทั้งหลายที่เก็บไว้เมื่อมันไม่ถูกเลือก [...]

Read full story Comments { 10 }

Team rule

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

Read full story Comments { 12 }

Test-Driven JavaScript Development

วันนี้หยิบหนังสือที่พึ่งซื้อมารีวิวซะหน่อยหลังจากที่ไม่ได้เขียนถึงนานตั้งแต่มีนาคมปีที่แล้ว เพราะไม่ได้ซื้อหนังสืออะไรใหม่เกี่ยวกับด้านนี้อีกเลย (จริงๆ ก็มีอีกเล่มนึงที่ซื้อคู่กันตอนทำ prosody ไว้เขียนถึงคราวหน้าละกัน) ที่ซื้อเล่มนี้มีเหตุผลง่ายๆ เพราะไม่รู้จะเขียน UnitTest ใน JavaScript ยังไง หนังสือที่ว่าก็ตามชื่อ Post นี้เลย Test-Driven JavaScript Development หนังสือเล่มนี้มีด้วยกันสี่ส่วน เริ่มจากแนะนำว่า Test-Driven Development คืออะไรต้องทำอะไรบ้าง UnitTest เขียนยังไง คนที่เขียน UnitTest ในภาษาอื่นมาก่อนแล้วก็ข้ามๆส่วนนี้ไปก็ได้ ตามมาด้วยส่วนที่พูดถึง JavaScript ว่าเขียนยังไงบ้างคนเขียน JavaScript เป็นอยู่แล้วก็ข้ามไปได้อีกนั่นแหละ (ข้ามมาสอง Part หละ!) ทั้งสอง Part ถ้าอ่านละเอียดๆ ก็จะมีแนะนำ Pattern ว่าจะเขียนยังไงให้ดูสวยและเขียน/เรียกใช้ UnitTest ง่ายอยู่ด้วยไม่มากเท่าไหร่แต่ก็พอให้เห็นว่าจะเขียนยังไงได้บ้าง มาถึงส่วนที่สาม ส่วนนี้จะพูดถึงการพัฒนาแบบ Test-Driven จริงๆหละว่าคนเขียนทำอะไรอย่างไรบ้างใช้เทคนิคไหน Pattern ที่ใช้หน้าตาอย่างไร จะเขียน Test กับพวก Ajax อย่างไร [...]

Read full story Comments { 0 }

Software Development Team

หลังจากทำงานมาสี่ปี เจอปัญหามามากมาย ได้แก่ Component ต่างๆ ไม่มีใครสามารถเล่าได้ หรือรันให้ดูเป็นส่วนว่ามันทำงานอย่างไร ต้องเข้าไปอ่าน Code แล้วลองรันดูเอง ถึงจะรู้ จะรันโค้ดส่วนต่างๆ ได้ต้อง setup นู่นนี่นั่น ขึ้นมาก่อนถึงจะรัน test ได้ รันแล้วยังคงไม่รู้อยู่ดีว่ามันทำงานยังไง เพราะตอนรันไม่มีคนมาอธิบาย ตอนอธิบายก็คือเป็นการสอนกลุ่มใหญ่ ดูสไลด์เอา บางครั้งถึงกับรันไม่ได้เลย จนเหนื่อยใจเลิกรัน test กันไป เมื่อมีการแก้ไข Component ไม่สามารถรู้ได้ว่าสิ่งที่เพิ่มไป ทำให้ของเก่าพังหรือป่าว ต้องถึงมือ QA ก่อนถึงจะรู้! เมื่อถึงมือ QA แล้วกลับมาแก้ก็ไม่รู้ไปพังส่วนไหนอีก ตอนทำงานพร้อมกันหลายๆ ส่วนแล้วเอามารวมกัน ไม่สามารถรู้ได้ว่าทำให้โค้ดคนอื่นพังป่าว เวลา Merge version ใหญ่ๆ ไม่สามารถบอกได้เลยว่าทุกอย่างยังทำงานถูกต้อง Code แต่ละคนแม้ส่วนใหญ่จะใช้รูปแบบเหมือนกัน แต่เวลามีน้องใหม่เข้ามาทำงาน ไม่มีการบอกกล่าวก็เจอรูปแบบประหลาดไปเต็มๆ เนื่องจาก แก้แล้วแก้อีก เพราะแก้เสร็จก็ทำให้เกิดปัญหาอีกอย่าง ทำให้งานไม่เสร็จซักที ช่วงสองสามเดือนที่ผ่านมา อาการพวกนี้เริ่มเข้าขั้นวิกฤต สามารถแก้แบบปะผุไปล่วงหน้าได้บ้าง [...]

Read full story Comments { 7 }

Software Development from Twitter (and G+)

เรื่องนี้มาจากสิ่งที่คุยกันใน Twitter หาจุดเริ่มต้นนานมาก เพราะคุยกันไม่ได้ติดต่อกันเท่าไหร่ ยกเว้นช่วงหลังที่ @visibletrap ปล่อยมาเป็นชุดเลย เรื่องก็น่าจะเริ่มจาก Tweet ชุดนี้มั้ง (22 กรกฎา) @visibletrap: “ตามคำขอ [Blog] Refactoring DOJO http://t.co/w6NQIW6 cc @teerapapc @m3rlinez @llun: @visibletrap อยากเห็น Agile ในบริษัทที่ทำ Product ของตัวเองอ่ะ (เรียกว่า Software House ป่าวหว่า) เพราะบริษัทเหล่านี้มักไม่มีการคุมเวลา @visibletrap: @llun น่าจะมีนะ แต่ยังไม่เคยรู้ข้างในจริงๆ อย่าง Pivotal เค้าก็มี product เค้า อย่าง google เคยได้ยินว่าทีม adwords ก็ทำ @llun: @visibletrap ใช่แต่บริษัทที่ทำ Agile และรู้จักตอนนี้ส่วนใหญ่คือทำ Product ตาม Requirement [...]

Read full story Comments { 0 }