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

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

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

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

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

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

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

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

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

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

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

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

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

Advertisements

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

  1. jemmy

    กำลังเจอปัญหานี้อยู่เหมือนกัน

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

    Reply
  2. wiennat

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

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

    แต่ถ้าหมายถึงว่าให้ mark ไว้ว่าเป็น Won’t fix ก็เห็นด้วยครับ

    Reply
    1. Tap Post author

      ถ้าเราไม่ลบทันทีแล้วเราจะลบตอนไหนอะครับ ผมไม่เห็นประโยชน์ของการเก็บ ข้อมูลพวก won’t fix เอาไว้ ผมว่า feature/bug list ที่โล่งๆ มีแต่สิ่งที่เราจะทำแน่ๆ ให้ความรู้สึกดีกว่าเยอะ ยิ่งสำหรับ software ที่รับพัฒนามันอย่างต่อเนื่องเปลี่ยนเวอร์ชั่นบ่อยๆ ทิ้งๆไว้ เราจะบอกไม่ได้เลยว่ามันยังอยู่หรือมันหายไปแล้ว

      ถ้าบั๊กที่ลบไปมันกลับมาอีกแต่เราจำไม่ได้ ก็แปลว่ามันนานพอสมควรที่จะเกิดอีกครั้ง ซึ่งแปลว่าเมื่อเราได้รับรายงานครั้งที่ 2 แล้วเราจะมองว่ามันเป็นบั๊กที่เพิ่งได้รับการรายงานมาใหม่ก็คงไม่เสียหายอะไร

      ถ้ามันมา 3-4-5 ครั้งก็คงจำได้และควรจะแก้แล้วหละครับ

      Reply
      1. wiennat

        >ถ้าเราไม่ลบทันทีแล้วเราจะลบตอนไหนอะครับ

        ถ้ามันสมควรที่จะได้รับการแก้ไขในเวลาต่อมา มันจะถูก reopen และ fix เองครับ ถ้ามีคน submit bug นี้เข้ามาใหม่ มันก็ควรจะถูก merge มาเป็น bug เดียวกันไปเลย

        >ถ้ามันมา 3-4-5 ครั้งก็คงจำได้และควรจะแก้แล้วหละครับ
        ถ้ามันมาตอนที่เราไม่ได้ดูแล project/feature นี้แล้ว การปิด bug นี้ไว้แบบ won’t fix น่าจะดีกว่าลบไปนะครับ เพราะอย่างน้อยมันก็ช่วยให้คนที่มาดูแลต่อจากเราได้รู้ว่าทำไมเราถึงไม่แก้ไปในตอนนั้น

      2. Tap Post author

        >ถ้ามันสมควรที่จะได้รับการแก้ไขในเวลาต่อมา มันจะถูก reopen และ fix เองครับ ถ้ามีคน submit bug นี้เข้ามาใหม่ มันก็ควรจะถูก merge มาเป็น bug เดียวกันไปเลย
        แต่ถ้ามันไม่ถูกแก้ไขมันก็จะอยู่ต่อไปตลอดกาลอะครับ ซึ่งเมื่อถึงจุดหนึ่งมันจะไม่่มีใครรู้ว่ามันยัง relevance อยู่หรือเปล่า กลายเป็นขยะไป

        >ถ้ามันมาตอนที่เราไม่ได้ดูแล project/feature นี้แล้ว การปิด bug นี้ไว้แบบ won’t fix น่าจะดีกว่าลบไปนะครับ เพราะอย่างน้อยมันก็ช่วยให้คนที่มาดูแลต่อจากเราได้รู้ว่าทำไมเราถึงไม่แก้ไปในตอนนั้น
        วิธีนี้มันฟังดูเป็นวิธีที่ควรทำ แต่ในความเป็นจริงแล้วลองคิดถึง list ที่มีเป็นร้อยรายการขึ้นไปนะครับ สิ่งที่ผมเจอคือ แม้แต่บั๊กที่ตัวเองเป็นคนดูแลที่จำได้ว่ามี issue อยู่ หลายๆครั้งยังหามันไม่เจอเลยว่ามันอยู่ที่ไหน ถ้าเป็นคนอื่นมาทำต่อจากเรายิ่งจะยากไปกันใหญ่ ต้องเป็นคนที่ละเอียดจริงๆ อะครับ ถึงจะพยายาม search หาด้วยหลายๆ keyword โดยหวังว่าจะเจอ issue เก่าที่คนอื่นเคยทำไว้อยู่

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s