จากหนังสือ The Nature of Software Development
ในบทที่ 18 อธิบายเรื่อง To Speed Up, Build with Skill
นั่นคือ ถ้าต้องการความเร้วในการพัฒนาที่เพิ่มขึ้น
สิ่งที่คุณต้องลงทุนคือ การสร้างและ เพิ่มความสามารถในด้านต่างๆ
ให้กับทีมที่เกี่ยวข้องในการพัฒนา software ด้วยนะ !!
ในช่วงเริ่มต้นของการพัฒนา
เราจะทำการพัฒนาแบบ feature-by-feature
พัฒนาอยู่ในช่วงเวลาสั้นๆ
แต่สิ่งที่ได้รับกลับมาอย่างรวดเร็วก็คือ
ความล้มเหลวที่รวดเร็วเช่นกัน !!
ซึ่งมันเป็นเรื่องปกติ ที่จะเกิดขึ้น
และเราจะรับมือกับมันอย่างไรดีล่ะ ?
คำถามที่ทีมมักจะพบเจอ คือ
เราไม่สามารถสร้าง feature เหล่านี้ได้ในเวลา 2 สัปดาห์หรอกนะ ..
คำตอบ
ใช่ สร้างไม่ได้หรอก มันเป็นปัญหาพื้นฐานเลย
บ่อยครั้งพบว่า ทีมไม่สามารถส่งมอบ feature ต่างๆ ได้
เนื่องจากไม่สามารถ integrate ส่วนการทำงานต่างๆ ได้ภายใน 2 สัปดาห์
สิ่งที่น่ากลัวคือ งั้นขอเพิ่มเวลาเป็น 3-4 สัปดาห์ก็แล้วกัน
มันเป็นแนวคิดที่น่ากลัวมากมาย …
ดังนั้นแนวทางที่ดีกว่าคืออะไรล่ะ ?
ลองถามทีมพัฒนาสิว่า
ถ้า 2 สัปดาห์ยังไม่เสร็จ ดังนั้นลดให้เหลือสัก 1 สัปดาห์ดีไหม !!
ลองทำดูสิ … และสังเกตุสิ่งที่เปลี่ยนแปลงของทีม ว่าป็นอย่างไร
ทั้งการพัฒนา การ integrate การทดสอบ และ การติดตั้ง
เมื่อเวลาผ่านไป คำกล่าวที่มักจะได้ยินจากทีม คือ
เราไม่สามารถสร้าง feature เหล่านี้ได้ในเวลา 1 สัปดาห์หรอกนะ …
คำตอบ
งั้น สามารถพัฒนา feature เหล่านี้ให้เสร็จภายในวันเดียวได้ไหมล่ะ ?
แน่นอนว่า คำตอบคือ ทำไม่ได้หรอกนะ !!
ในใจทีมก็คิดว่า เป็นสัปดาห์ยังไม่เสร็จ แล้ว 1 วันจะเสร็จได้อย่างไร !!
… แต่ที่น่าสนใจ คือ แล้วในวันพรุ่งนี้คุณวางแผนว่าจะทำอะไรล่ะ
หรือว่า ไม่มีอะไรทำให้มันเสร็จเลยหรือ !!
ดังนั้น จะมาทำไมกันล่ะ ?
คำถาม
ปัญหาที่ทีมเจออยู่ตอนนี้คืออะไร ?
คำตอบ
การสร้าง software แบบ incremental หรือแบบ feature-by-feature มันไม่ได้ง่ายเลยไงล่ะ
ดังนั้น การพูดคุยกับทีมที่ทำงาน
จะช่วยทำให้ทีมเห็นปัญหา เพื่อปรับปรุงให้ดีขึ้น
ทั้งเวลาในการพัฒนา
ทั้งเวลาในการ integrate
ทั้งเวลาในการทดสอบ
ทั้งเวลาในการ deploy
ส่วนทางเจ้าของ product ยิ่งต้องจัดการปัญหาต่างๆ ด้วยเช่นกัน
นั่นคือ ต้องเข้าใจการพัฒนาแบบ feature-by-feature ด้วยเช่นกัน
แน่นอนว่า จะเห็น feature เหล่านั้นออกมาอย่างสม่ำเสมอ
และสิ่งที่ต้องทำก็คือ จัดเรียงความสำคัญของ feature
เพื่ออธิบาย และ ส่งมอบให้ทีมพัฒนาต่อไป
โดยสิ่งที่สนใจมากที่สุดคือ software/product ที่ทีมสร้างออกมา
บ่อยครั้ง ทีมมักจะพูดว่า
เราไม่สามารถที่ release feature อะไรได้เลย จนกว่าจะทดสอบมัน !!
แน่นอนว่า ทางเจ้าของ product ไม่สามารถยอมรับได้แน่นอน
ถ้า feature อะไรที่มันพัฒนาเสร็จไปแล้ว
โดยตีกลับ หรือ แจ้ง defect กลับมาจากทีม QA
ซึ่งมันส่งผลกระทบต่อการวางแผนงานแบบสุดๆ
เพราะว่า มันคือการทำซ้ำๆ ในเรื่องเดิมๆ อีกแล้ว
มันน่าเบื่ออย่างมากมาย !!
คำถาม
แล้วเราจะแก้ไขปัญหานี้อย่างไรดีล่ะ ?
คำตอบ
วิธีการมันเรียบง่ายมากๆ นะ แต่ทำยากสุดๆ มาดูกัน
เป้าหมายหลักของวิธีการนี้ อยู่บนแนวคิดที่ว่า
เมื่อทีมส่งมอบ feature ไปยังทีม QA แล้ว
จะต้องไม่มี defect ถูกตีกลับมาเลย !!
ดังนั้น สิ่งที่ทีมพัฒนาต้องทำคือ
ต้องนำแนวปฏิบัติพวก
- ATDD (Acceptance Test-Driven Development)
- TDD (Test-Driven Development)
มาใช้งานอย่างจริงจัง และ จริงใจ
มันทำให้เราเพิ่มความเชื่อมั่นทั้งของทีมพัฒนา และ ทีมอื่นๆ
แน่นอนว่าในทีมต้องมีผู้เชี่ยวชาญเรื่องพวกนี้ด้วย !!
แต่บ่อยครั้ง พบว่าเราต้องการ สิ่งที่เรียกว่า resource
เช่น developer, tester, DBA, UX/UI designer เป็นต้น
มาอยู่ในทีมในรูปแบบ Cross-functional team
และนำความรู้ความสามารถเหล่านั้นมาสอนให้คนในทีม
ซึ่งเป็นวิธีการที่ดีที่สุดแล้ว
แต่ … มันต้องใช้เวลานานเลยนะเออ !!
กลับมาคิดใหม่สิว่า คุณต้องการทั้งหมดตั้งแต่เริ่มต้นเลยหรือไง ?
การพัฒนา software นั้น จำเป็นต้องใช้เวลา
การศึกษาและเรียนรู้ก็เช่นกัน
ดังนั้น สิ่งที่ทีมพัฒนาสามารถใช้ในการปรับปรุงคุณภาพของทีมได้
คือ Definition of Done (DoD)
Definition of Done (DoD)
มันคือ ข้อตกลงระหว่างทีม และ เจ้าของ product
ใช้เพื่อควบคุมคุณภาพของแต่ละ feature ที่จะส่งมอบนั่นเอง
โดย DoD นั้นจะเพิ่มขึ้นในทุกๆ รอบของการทำงาน
สุดท้าย DoD จะครบทั้งหมดตามที่ตกลงกันไว้
ตัวอย่างเช่น
ในรอบแรกๆ ของการทำงาน อาจจะไม่มีการ integrate ระบบต่างๆ เข้าด้วยกัน
ซึ่งนั่นมันแย่มากๆ เลยใช่ไหม
สามารถทดสอบได้บนเฉพาะเครื่องที่พัฒนาเท่านั้น
ดังนั้น เราควรปรับปรุง DoD ให้ทุกๆ feature นั้น
ต้องมารวมกัน และ สามารถทำงานได้บนเครื่อง Server เท่านั้น
ด้วยการ build แบบอัตโนมัติ … อะไรประมาณนี้
และแน่นอนว่า มันส่งผลกระทบต่อจำนวน feature ที่ทีมจะส่งมอบได้
นั่นคือ feature น้อยลงไปกว่าเดิม
แต่ว่ามันดีต่อเจ้าของ product และในแง่ของ business ด้วย
และสุดท้ายคุณสามารถส่งมอบ software ที่ทำงานได้จริงๆ
ต่อจากนั้น เมื่อคุณทำการ integrate กันบ่อยๆ แล้ว
อาจจะเหิดปัญหาเรื่องของคุณภาพของ software ที่มันแย่
ดังนั้น คุณจึงต้องการการทดสอบขึ้นมา
ซึ่งสามารถนำไปเพิ่มใน DoD ได้อีกนั่นเอง
จะเห็นได้ว่า มันทำให้เราได้เรียนรู้ว่า และ ค้นพบ
ตั้งแต่เริ่มต้นการทำงาน จน ไปถึงปลายทาง
มันทำให้เราเข้าใจในตัว product และความต้องการของเจ้าของ product มายิ่งขึ้น
และเมื่อเราเข้าใจมากยิ่งขึ้น
ก็จะสามารถสร้าง software ที่มีคุณค่าได้มากขึ้น
แต่ว่า มันก็ยังช้าอยู่ดีนะ !!!
แน่นอนว่าในช่วงแรกๆ คุณจะรู้สึกว่ามันช้าลง
แต่เมื่อทุกอย่างเริ่มเข้าที่เข้าทาง
มันจะเริ่มดีขึ้นเรื่อยๆ รวมทั้งมีคุณภาพที่ดีขึ้น
ของแบบนี้มันต้องใช้เวลานะครับ
จำไว้ว่า สิ่งที่เราต้องการก็คือ
software ที่สามารถใช้งานได้
software ที่พร้อมติดตั้ง และ ปล่อยให้ใช้งาน
software ที่ถูกสร้างออกมาในทุกๆ 2 สัปดาห์
และต้องผ่านการออกแบบ และ ทดสอบ เรียบร้อย
ดังนั้น ทีมต้องทำเรื่องต่างๆ เหล่านี้ในทุกๆ วัน
จำนวน feature มันจะไม่เยอะในช่วงแรกๆ
แต่ feature ที่คุณสร้างออกมานั้น มันเสร็จจริงๆ
ไม่ใช่ต้องกลับมานั่งแก้ไข defect ต่างๆ อีก !!
ที่สำคัญเราทำการพัฒนา feature ที่มีคุณค่าและความสำคัญสูงสุดด้วยนะ
ซึ่งสิ่งที่ส่งมอบมันมีคุณค่าต่อลูกค้าอย่างมาก
และที่สำคัญ software มันทำงาน และ ใช้งานได้จริงๆ !!
รวมทั้งเรายังได้แก้ไขปัญหา ต่างๆ ตั้งแต่เริ่มทำงาน
มันจะช่วยลดปัญหา และ เพิ่มประสิทธิภาพการทำงานขึ้นมาตลอดเวลา
และคุณได้พัฒนาตัวเองอยู่ตลอดเวลาอีกด้วย
สุดท้ายแล้ว
ทีมที่ทำงานได้รวดเร็วที่สุดคือ
ทีมที่ทำงานเป็นทีม ไปด้วยกัน
และไปในเส้นทางที่ดีอยู่อย่างเสมอครับ …
แน่นอนว่า ต้องลงทุนกับทีม เพื่อเสริมสร้างความสามารถของทีมด้วยเช่นกัน …
ลองคิดดูเอาเองแล้วกัน
ว่าคุณต้องการเจอปัญหา และ แก้ไขมันตั้งแต่เริ่มต้น
และต้องการไปเจอช่วงท้ายๆ …
