Monthly Archives: March 2013

บั๊กสำคัญกว่าฟีเจอร์ใหม่

หนึ่งในปัญหาที่ทุกๆ ทีมพัฒนาซอฟแวร์จะต้องเจอคือโปรแกรมมีบั๊ก ทั้งที่คาดการเอาไว้และไม่ได้คาดการเอาไว้ และปัญหาที่ตามต่อมาคือ เราจะแก้บั๊กดี หรือจะทิ้งมันไว้ก่อนแล้วไปทำฟีเจอร์อื่นๆ ให้เสร็จดี

โดยปกติแล้วผมจะให้ความสำคัญกับการแก้บั๊กมากกว่าการพัฒนาฟีเจอร์ใหม่เสมอๆ ครับ

ก่อนอื่นผมขอทำความเข้าใจก่อนว่า ผมแบ่งบั๊กออกเป็น 2 ประเภทครับ คือ บั๊กที่ต้องแก้ และบั๊กที่ไม่ต้องแก้

ตัวอย่างของบั๊กที่ไม่ต้องแก้ ได้แก่

  • บั๊กที่ QA ใช้ท่าพิสดารในการหามา และมีโอกาสน้อยมากที่ user จะทำเช่นเดียวกันให้เกิดบั๊กนั้น
  • บั๊กที่เกิดจากข้อมูลเก่าบางส่วนมีความผิดพลาด ไม่เกิดกับข้อมูลใหม่ และถ้าแก้ไขข้อมูลเก่านั้นแล้วบั๊กจะหายไป
  • บั๊กที่ไม่ทำอันตรายต่อผู้ใช้งาน และผู้ใช้งานไม่รู้สึกว่ามันเป็นบั๊ก

โดยทั้งนี้ทั้งนั้นขึ้นอยู่กับว่าธรรมชาติของระบบที่เราพัฒนามีความอ่อนไหวต่อบั๊กแค่ไหนด้วย บั๊กในกลุ่มนี้ผมแนะนำว่าให้ลบมันทิ้งไปจาก bug tracker เลยครับ ถ้ามันโผล่กลับมาอีกก็แปลว่ามันเริ่มสำคัญมากขึ้น ค่อยนำกลับมาคิดใหม่ว่าจะแก้ดีหรือไม่

แต่ในส่วนของบั๊กที่ต้องแก้ ผมจะแก้ทันทีครับ ไม่ว่าผมจะพัฒนาฟีเจอร์ใหม่อื่นอะไรอยู่ก็ตาม โดยอยู่ภายใต้เงื่อนไขที่สำคัญมากอย่างนึงคือ ทุกๆ ฟีเจอร์ที่เราทำ เรามีการจัดลำดับความสำคัญเสมอ

If a thing is worth doing, it is worth doing well.

บั๊ก เป็นสิ่งที่เกิดจากฟีเจอร์ที่เราทำไปก่อนหน้าฟีเจอร์ปัจจุบัน ซึ่งแปลว่าฟีเจอร์น้ันเราเลือกที่จะให้ความสำคัญกับมันมากกว่าฟีเจอร์ปัจจุบัน บั๊กของฟีเจอร์นั้นก็ต้องสำคัญกว่าฟีเจอร์ปัจจุบันด้วยเช่นกัน

ถ้าเมื่อไหร่ที่เรามีความรู้สึกว่าบั๊กสำคัญน้อยกว่าฟีเจอร์ที่กำลังทำอยู่ แปลว่างานที่เราทำอยู่มีปัญหาการจัดการลำดับความสำคัญครับ ควรรีบกลับไปแก้อย่างเร่งด่วน

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

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

Advertisements

ย้อนกลับไปมองความคิดในเรื่องการพัฒนาซอฟแวร์

ตอนแรกตั้งใจว่าจะเขียนบล็อกเกี่ยวกับการพัฒนาซอฟแวร์อีกบล็อกนึง หลังจากร่างเรื่องที่จะเขียนเสร็จก็รู้สึกตะหงิดใจว่าเคยเขียนอะไรแบบนี้ไปแล้วหลายครั้ง เลยมาลองเปิดย้อนอ่านบล็อกของตัวเองดู พบว่าเขียนไปหมดแล้วจริงๆด้วย สิ่งที่โน้ตไว้ตั้งใจจะเขียนไม่มีอะไรใหม่เลย เลยขอเปลี่ยนเป็นบล็อกรวบรวมสิ่งเหล่านั้นที่เคยคิดและเขียนไปตลอด 2 ปีที่ผ่านมาแทนละกัน

Importances of Rapid Feedback แนวคิดในการทำงานคือต้องพยายามให้เกิดฟีดแบ็คเร็วๆ เพื่อที่จะได้ไม่เดินหลงทาง

My view of TDD ประโยชน์และสไตล์การทำ TDD ของตัวเอง น่าประหลาดใจมากที่ ณ วันนี้ลำดับขั้นตอนยังเหมือนวันนั้นเป๊ะๆ

Pull Systems in Software development อีกบล็อกเกี่ยวกับฟีดแบ็คและการปรับปรุง

Intro to fun automate testing เทสที่ดีเป็นอย่างไร มีแนวทางทำให้เกิดเทสที่ดียังไง

Making CHANGE possible ทำอย่างไรให้เรายังสามารถแก้ตามฟีดแบ็คได้เสมอ

Continuous integration คือ อะไร หนึ่งในวิธีการสร้างฟีดแบ็ค

สิ่งที่บริษัท/ทีม โปรเจ็คพัฒนาซอฟต์แวร์ “ควรทำ” (ฉบับไว้อ่านเอง)

Agile 101 agile สำหรับผมมี 3 ข้อ feedback, change, bring value

Trunk Based Development หนึ่งในวิธีทำให้ continuos integration และชีวิตการพัฒนาซอฟต์แวร์เป็นไปอย่างราบรื่น

ประสบการณ์ที่เก็บได้ตามทาง ยำๆ หลายเรื่องที่พบเจอตอนนั้นเข้าด้วยกัน

QA first and Specification by Example Book วิธีการทำให้กระบวนการ QA มีประสิทธิภาพมากขึ้น บั๊กเด้งไปมาระหว่าง dev กับ qa น้อยลง

Fundamental of successful software development? ค้นหาปัญหาและโฟกัสในการแก้ปัญหานั้น

หนึ่งปีในสิงคโปร์ ภาคโปรแกรมเมอร์

เข้าใกล้ Continuous Deployment ไปอีกหนึ่งก้าว dev<->deploy cycle ของบริษัท ที่ตอนนี้ไม่ได้ใช้แล้ว

The Deep Synergy Between Testability and Good Design เทสยากแปลว่าดีไซน์มีปัญหา

Test อะไรบ้าง? เติมเต็มเกี่ยวกับเรื่องการเทสและ TDD

ถ้าลองไล่ตามอ่านดูจะพบว่าในช่วงแรกๆ ผมเขียนด้วยภาษาที่ไม่มั่นใจ เพราะตอนนั้นอยู่ในช่วง อ่านหนังสือมาเขียน หรือฟังการบรรยายมาเขียน

2 ปีผ่านไปด้านเนื้อหาไม่มีอะไรต่างไป สิ่งที่ต่างคือประสบการณ์ที่มากขึ้น ก็มีความมั่นใจมากขึ้น รู้อะไรควรไม่ควร ณ เวลาใดๆ มากขึ้น