เมื่อเราพัฒนา software สิ่งที่เราจะต้องเจอตั้งแต่ตอนต้นเลยก็คือ requirement เพราะถ้าไม่มี requirement ก็ไม่ต้องคิดต่อแล้วว่าจะพัฒนาอะไร ซึ่ง software development process ทุก process จะพูดเรื่อง requirement ทั้งนั้น อยู่ที่ว่าจะลงรายละเอียดมากหรือน้อยก็ว่ากันไป Scrum process เองก็เช่นเดียวกัน

บทความนี้จะเป็นการเจาะการพัฒนา Product Backlog นะครับ เมื่อได้ list ของ backlog แล้ว ก็จะเอาไปใช้ในตอนต่อๆ ไป ถ้าใครยังไม่ได้อ่านตอนก่อน ก็ไปอ่านบทความตอนที่ 5.1 และ 5.2 ก่อนครับ จะได้ไม่งง

หมายเหตุ สำหรับใครที่อ่านไปแล้ว ผมขอเปลี่ยนเลขตอน จากตอนที่ 5.3 ไปเป็นตอนที่ 6 นะครับ เพราะเนื้อหามันค่อนข้างจะเป็นเรื่องเฉพาะเกี่ยวกับการทำ Product Backlog และ Requirement ตอนต่อไปก็เป็นเรื่องเฉพาะอีก ก็เลย run เลขใหม่ดีกว่า ^^

ผมคิดว่าหลายคนคงจะเคยเห็นรูปที่ผมเอามาใช้เปิดบทความนะครับ เป็นเรื่องโจ๊ก (แต่เจอเข้าจริงก็คงขำไม่ออก -_-!) ที่เกี่ยวกับความเข้าใจใน requirement ที่แตกต่างกันตังแต่ ลูกค้า, SA, มาถึงนักพัฒนา จนกระทั่ง deploy คนละเรื่องกันเลย … และจากที่ผมเคยช่วยงานเป็น pre-sale ขาย tool ของ Borland ผมจะเห็น slide อันนึงที่มาจากผลวิจัยของการ์ดเนอร์ที่เค้าสรุปมาว่า สาเหตุที่เป็นต้นตอของปัญหาในการพัฒนา software ที่เจอมากที่สุดก็คือ มาจาก requirement ซึ่งแนวทางการทำงานของ Agile ที่เป็น iteration ก็เพื่อป้องกันและแก้ปัญหาเรื่อง requirement นี่แหละ

ในบทความนี้ผมจะไม่เน้นว่า จะทำยังไงจึงจะได้ requirement ที่ดีและถูกต้องมากนัก แต่ผมจะเน้นไปที่เทคนิคของทีมที่ทำ Agile มักจะเอามาใช้กันมากกว่าครับ เพราะไม่ว่าคุณจะใช้ process แบบไหน คุณก็ต้องทำให้ requirement ที่ได้มันถูกต้องเสมอ

ผมแนะนำหนังสือ 2 เล่มนี้ครับ คือ Software Requirement และ More About Software Requirement ลองไปอ่านดู

Requirement กับการพัฒนา software แบบ Agile

ที่จริงขั้นตอนการพัฒนา Product Backlog นั้น ง่ายมากครับ มี 2 ขั้นตอนเอง คือ

1) ให้ Product Owner เขียนสิ่งที่เค้าต้องการเป็นข้อๆ และ
2) เรียงลำดับความสำคัญของ requirement เหล่านั้น

แค่นี้แหละครับเสร็จแล้ว ง่ายมาก แต่การทำจริงมันไม่หมูแบบนี้ เพราะรับรองว่าพอเอาไปใช้จริง แต่ละคนจะมีวิธีที่พิสดารจนคุณเองอาจจะคิดว่า “เฮ้ย … คิดได้ไงเนี่ยะ” เพราะฉะนั้นวิธีการที่จะทำให้ไปในแนวทางเดียวกันมากที่สุดก็คือ เอา Agile Principles ที่เกี่ยวข้องมาเป็นกรอบครับ …

1) Develop Product Backlog list

Product Backlog คือ list ของ requirement อยู่ในรูปของตาราง ใส่ใน excel ก็ได้ครับ ง่ายๆ เริ่มต้นในแต่ละข้อก็มีแค่ Backlog Number กับ Description แค่ 2 column หรืออาจจะใส่ requirement name ไปด้วย เพื่อใช้เป็นชื่อสั้นๆ ในการสื่อสารกัน ผมเอา requirement ของระบบขายของทาง internet มาเป็นตัวอย่างก็แล้วกัน

สมมุติผมรับงานพัฒนา web e-commerce ชื่อ TheThaiHandMade.com (ย้ำว่าสมมตินะครับ อุปโลกน์ขึ้นมาล้วนๆ) เค้าอยากจะจ้างให้บริษัทเราทำ web ขายของให้บริษัทเค้าหน่อย เค้าอยากให้ระบบ online ได้ใน 3 เดือนข้างหน้า … ok ผมในฐานะที่เป็น Scrum master ก็ไปกับ sale และ pre-sale เพื่อไป present ผลงานของบริษัทและรูปแบบการทำงานร่วมกัน

หลังจากที่ผมไปตกลงวิธีการทำงานกับเค้าแล้วว่า ทางลูกค้าต้องมี Product Owner ให้ผมนะ เราจะ update งานและส่งมอบส่วนของกันเป็น iteration … ลูกค้า happy มาก (ตอนแรกก็งี้แหละ ^^) ก็ OK จะจ้างเรา ผมก็นัดทีมงานที่เป็น​ Business Analyst และ System Architect ไปกับผม ทางลูกค้ากำหนด Business Solution มาเป็น Product Owner ให้ผม 1 คน แล้วเราก็ให้ Product Owner เค้าเขียนสิ่งที่อยากให้ web ทำได้ … ผมมีเทคนิคที่เสริมตรงนี้ให้ครับ

Practice #1 : ให้ Product Owner เป็นคนเขียน คุณอย่าเขียนเองเด็ดขาด ไม่ใช่เราจะอู้นะ แต่ให้เหตุผลว่าถ้าคุณเขียนเอง คุณจะเผลอใส่สิ่งที่คุณคิดเองเออเอง หรือไม่ก็มักจะเขียนด้วยภาษาเชิงเทคนิค เดี๋ยวจะผิดไปกันใหญ่ … ถ้าเค้าเขียนเอง รับรองว่าได้ requirement ตรงตามที่ต้องการแน่นอน ไม่มี technical term ด้วย ^^

ถ้า Product Owner อ้างว่าไม่มีเวลา ให้กลับไปคุยกับคนจ่ายเงินให้หาคนที่มีเวลาและทำงานได้แทน Product Owner คนนี้ เพราะคนๆ นี้จะต้องให้ความสำคัญกับ project นี้เป็น priority แรก หรือถ้าคนจ่ายเงินรับเป็น Product Owner เองแต่เค้าไม่มีเวลา ก็ต้องหาคนที่จะมาเป็น proxy ให้เรา ถ้าทำไม่ได้ นี่คือความเสี่ยงข้อแรกที่จะทำให้ project fail

Practice #2 : แนะนำ product owner ว่า ในแต่ละข้อ เขียนแค่สั้นๆ ไม่เกิน 3 ประโยค เพื่อให้เนื้อหากระชับ รวบรัด ไม่เยิ่นเย้อ ถ้าเป็น XP เค้าให้เขียนใส่กระดาษ post-it จะได้บังคับ Product Owner ให้เขียนได้ทีละน้อยๆ ครับ

Practice #3 : เริ่มแรก ปล่อยให้ Product Owner มีอิสระที่จะเขียนตามใจปราถนา อยากเขียนอะไรก็เขียนไป เค้าจะได้พุ่งสมาธิไปที่สิ่งที่ระบบควรจะทำได้จริงๆ ก่อน อย่าลืมว่าเค้าไม่เคยเป็น Product Owner มาก่อน เค้าอาจจะไม่เคยเขียน requirement เอง ถ้าเราไปตีกรอบโน่นนี่ เดี๋ยวเค้าจะกังวล เขียนไม่ออก เพราะฉะนั้นปล่อยไปก่อนครับ

Agile Principles ที่เกี่ยวข้องกับขั้นตอนนี้และ practice ทั้ง 3 ข้อนี้ คือ Business people and developers must work together daily throughout the project. และ core value คือ Customer Collaboration Over Contract Negotiation ครับ

จากตัวอย่าง Product Owner ของเราก็เขียนออกมาประมาณนี้ครับ …

Backlog #1 – Product List – website ThaiHandMade จะต้องมีหน้าจอแสดงรายการสินค้า hand made จากภาคต่างๆ ทั่วประเทศไทยได้ สามารถ click เข้าไปดูรายละเอียดของสินค้าได้

Backlog #2 – Update Products – สามารถเพิ่ม ลบ รายการสินค้าได้ สามารถแก้ไขรายละเอียดสินค้าได้

Backlog #3 – Order Tracking – สามารถติดตามสถานะของการส่งสินค้าได้

Backlog #4 – Update on Facebook – สามารถ upload ข้อมูลสินค้าและ promotion ใหม่ๆ ขึ้นบนหน้า Facebook  Fan Page ของ website ได้

Backlog #5 – Tweet to Twitter – ระบบจะต้องสามารถส่งข้อความ update ไปยัง twitter ได้ผ่านทาง admin page ของระบบเอง

เอาแค่นี้ก่อน … (ที่จริงควรจะมีมากกว่านี้อีกมาก แต่แค่นี้ก็จุกแล้ว 555) คุณอาจจะมองว่า นี่มันยอดของภูเขาน้ำแข็งที่โผล่ขึ้นมาให้เห็นแค่ 5% นี่หว่า … ไม่ … 1% มากกว่า … ครับ ถูกต้องเลย เรายังมีงานที่ต้องทำกันอีกมาก แต่เริ่มต้นอย่าเพิ่งไปลง detail อะไรให้มาก เอาให้เรียบง่ายที่สุดก่อน อย่าเพิ่งไปกังวลกับรายละเอียดก่อน เราจะค่อยๆ เพิ่มลงไปทีหลังครับ

จุดที่ผมอยากให้สังเกตุก่อนคือ ใน backlog แต่ละข้อครับ …

สังเกตุว่า ใน Backlog #1 นั้นจะมี 2 เรื่อง คือแสดง list รายการ และแสดง detail อย่างละเอียดของสินค้ารายการหนึ่งๆ ในกรณีนี้ผมแนะนำให้แตกรายการเป็น 2 Backlog ครับ มันเป็นที่มาของ practice ในข้อต่อไป คือ

Practice #4 : Product Backlog ในแต่ละข้อ ทำแค่เรื่องเดียวเท่านั้น (เรื่องหนึ่งๆ อาจจะกระจายอยู่ในหลายข้อก็ไม่เป็นไร) เพราะเมื่อมันทำเรื่องเดียว การพัฒนาข้อนั้นๆ ก็จะง่ายกว่าทำทีเดียวหลายเรื่อง การ design หรือการ test ก็จะง่ายตามไปด้วย เพราะทำทีละเรื่อง

Agile Practice ที่เกี่ยวข้องคือ Simplicity–the art of maximizing the amount of work not done–is essential.

ใน Backlog #2 ก็เดาได้เลยครับว่า ไม่ได้มีแค่ front page แล้ว ต้องมี web admin ให้ใช้ด้วย เราสามารถแตกย่อยได้เหมือนกัน ก็แตกกันไป ผมขอไม่ลง detail นะครับ

ใน Backlog #3 นั้นมีปัญหาเรื่องกำกวมครับ ปัญหาก็คือว่า การ track order นั้นทำโดยใคร ลูกค้า, หรือ admin,  หรือทั้งคู่ เมื่อเจอ Backlog ลักษณะนี้ คือไม่รู้ว่า requirement ข้อนั้นมีไว้เพื่อใคร ก็ให้เพิ่ม format ให้กับ Product Backlog แบบนี้ครับ

Practices #5 : ใน Backlog แต่ละข้อ ให้เขียนอยู่ในรูปแบบที่มี role, description, และ reason เพื่อช่วยอธิบาย backlog ข้อนั้นๆแบบนี้ครับ

ในฐานะของ​ ______________
ฉันต้องการให้ _____________ สามารถ ______________
ซึ่งนั่นจะทำให้ ______________________

มันมาจากภาษาอังกฤษว่า “As ____ I wants the system shall be able to ____ So that ___”

เมื่อแก้ใหม่ Backlog #3 ก็จะเป็น

Backlog #3 – Order Tracking -
ในฐานะของ [ ลูกค้าที่เข้ามาซื้อสินค้าใน web ]
ฉันต้องการให้ระบบ  [ มี page ให้ฉันสามารถติดตามสถานะของการส่งสินค้าได้  ]
ซึ่งนั่นจะทำให้   [  ฉันสามารถติดตามสินค้าที่สั่งซื้อ และใช้เป็นข้อมูลอ้างอิงกับทาง website ในกรณีที่สินค้ามาไม่ถึงหรือสูญหายได้  ]

ชัดเจนไหมครับ ^_^

สังเกตุว่า พอมีกรอบมาบังคับ การเขียนแต่ละประโยคจะชัดเจนขึ้นมาทันทีว่าตกลง backlog ข้อนี้ใครเป็น user ที่จะใช้มัน ระบบจะต้องทำอะไรได้ และ “เพื่ออะไร” ซึ่งมันจะเป็นเครื่องมือที่ทำให้ product owner เขียน Backlog ด้วยความตั้งใจมากขึ้นกว่าเดิมด้วย สามารถแยก priority ของ requirement ได้ง่ายด้วยว่า ตกลง backlog ข้อนี้สำคัญ หรือจะมีก็ได้ไม่มีก็ไม่เป็นไร (พวก “nice-to-have” requirement)

การเขียนแบบนี้จะมีประโยชน์กับทีมพัฒนามาก เพราะมันจะช่วยขุด requirement ที่ Product Owner นึกไม่ออกในครั้งแรกขึ้นมาด้วย และจะทำให้เราสามารถกำหนดแนวทางการ test ได้ตั้งแต่ตอนต้นๆ project เลย (จาก block ของ So that ไง ถ้า test แล้วไม่ได้ตามนั้น ก็แสดงว่าไม่ผ่านครับ)

ก่อนจะไปเรื่องถัดไป ผมฝาก Practice ให้อีกข้อครับ

Practice #6 : อย่าเชื่อ Product Owner ไปซะทุกอย่าง

อย่าลืมว่า Product Owner ตามตัวอย่างนั้น ลูกค้ามอบหมายให้ Business Solution แค่คนเดียวมาเป็น Product Owner … ขนาดทีมพัฒนาผมยังพา BA กับ Architect ไปกับผมด้วยเลย

เพราะฉะนั้น เมื่อได้รายการของ Product Backlog มาแล้ว ให้เอา Backlog เหล่านั้นไป validate กับคนที่เกี่ยวข้องกับ website นั้นทั้งทางตรงและทางอ้อมด้วย (ส่วนใหญ่ในหนังสือจะเรียกว่า Stakeholder ครับ) และถึงแม้ว่า Product Owner จะเป็นเจ้าของเอง ก็ยังต้องเอาไป validate กับคนที่เกียวข้องเพื่อรับ feedback อยู่ดี เพราะเจ้าของบริษัทอาจจะอยู่บนที่สูง อาจจะมองข้ามอะไรบางอย่างไปก็ได้ครับ

แต่สิ่งที่ต้องระวังในข้อนี้ก็คือว่า เมื่อเราเอา product backlog ไป validate กับ Stakeholder คนอื่น เราต้องรู้ด้วยว่าเค้าเป็น “หมู” หรือ “ไก่” จำได้ใช่ไหมครับ ถ้าเป็นหมู Scrum master ต้องย้ำ product owner ว่าเค้าต้องลงมาเป็นหมูกับเรานะ ไม่งั้น project อาจจะมีปัญหาได้ หรือถ้าเค้าไม่ได้เป็นหมู แต่จู้จี้ต้องมีอย่างนั้นต้องได้อย่านี้ ก็ลากเค้าเข้ามาเป็น Product Owner ด้วยซะเลย แต่ถ้าเค้าจะเป็นแค่ไก่ เราก็แค่รับฟังแล้วมาสรุปกันว่าจะเอาสิ่งที่เค้าบอกมาใส่ในระบบด้วยหรือไม่ครับ นั่นคือ อย่าให้คนที่ไม่เกี่ยวข้องชักใบให้เรือเสียครับ

Practice #7 : Scrum master ต้องใช้แนวคิดของ Ham&Egg เพื่อกัน “ไก่” ออกจาก “หมู”

2) Define Priority to Product Backlog

เมื่อเราได้รายการของ Product Backlog เราก็ให้ Product Owner กำหนดความสำคัญของแต่ละ backlog ใช้ practice ข้อนี้ครับ

Practice #8 : กำหนด priority โดยใช้ตัวเลขหลัก 10 ไล่ไปเรื่อยๆ 20, 30 … เช่น backlog ที่สำคัญที่สุด ให้เท่ากับ 10  ข้อไหนที่สำคัญเท่าๆ กัน ก็ให้เลขเดียวกัน ข้อไหนสำคัญน้อยกว่าก็เป็น 20 และ 30 ไป
(ที่มา Head First Software Development, Chapter: Software Requirement)

สาเหตุที่กำหนดเป็นตัวเลข ก็เพราะว่าถ้ากำหนดเป็น high/medium/low มันจะแยกความแตกต่างไม่ได้และกำกวมเมื่อมี priority เพิ่มขึ้นมาภายหลัง เช่น นอกจาก high อาจจะมี medium-high, very-high, super-high, ultra-high … ตกลงอันไหน high กว่ากัน ต้องมานั่งอธิบาย hi-lo กันอีก (… อืม เริ่มเฉียดคุกแล้ว) เอาเป็นตัวเลขนี่ละครับ เปรียบเทียบง่ายดี

นอกจากนั้นยังมีประโยชน์ในกรณีที่มีการแทรก priority ด้วย เช่น กำหนดกลุ่มของ backlog ให้มี 10 กับ 20 ไปแล้ว แต่มีงานที่เพิ่งนึกได้ว่าสำคัญกว่า 20 แต่ไม่เท่า 10 เราก็ให้ 15 จะได้ไม่ต้องเสียเวลามาเพิ่ม priority ใหม่ แต่ถ้ามันมีการแทรกมากๆ แสดงว่าเราบริหารไม่ดีนะครับ อาจจะเก็บ requirement ไม่ดีเลยต้องแทรกงานอยู่เรื่อย หรือลูกค้าขอเปลี่ยนอยู่เรื่อย มันก็จะสะท้อนออกมาให้เห็นใน Product Backog ทันทีเลยครับ

คำถามต่อไปก็คือ เราจะเอาอะไรมาเป็นเกณฑ์ในการวัดความสำคัญของ backlog เหล่านั้น … ในหนังสือเรื่อง The Art of Agile Development พูดถึงเรื่องของ Business Value เอาไว้ ซึ่งแต่ละ requirement จะมี business value ที่ไม่เท่ากัน วิธีการก็คือ ให้ Product Owner ประเมินว่า backlog ข้อไหนที่ มีคุณค่าต่อ business ของเค้ามากกว่ากัน ก็ให้ข้อนั้นมี priority ที่สูงกว่าครับ

Practice #9 : กำหนด priority ของ Product Backlog ตาม “Business Value”

Business Value นั้นก็จะแตกต่างกันออกไปตามแต่ละธุรกิจและเหตุการณ์ ยกตัวอย่างเช่น โทรศัพท์ Windows Phone 7 ของ Microsoft จะเห็นได้ชัดเจน ถ้าใครตามเทคโนโลยีพวกนี้ก็จะรู้ว่า MS นั้นเสียเชิงมวยทางด้าน Smart mobile ให้กับ iPhone และ Android ชนิดที่ไปไม่เป็นเลย เพราะเมื่อก่อนถ้าพูดถึง smart mobile ละก็ คนต้องนึกถึง Windows Mobile เป็นอันดับต้นๆ แต่กลับพลาดท่าให้กับผู้ที่มาทีหลัง เมื่อ WP7 ออกวางตลาด feature ที่ MS เองเคยปรามาสคู่แข่งว่าไม่มี ของตัวเองก็กลับไม่มีเหมือนกัน นั่นเป็นเพราะว่า Business Value ไม่ได้อยู่ที่มีหรือไม่มี feature เหล่านั้น แต่มันอยู่ที่ MS ต้องมีอะไรบางอย่างที่ออกมาขัดตาทัพและสร้างความแตกต่างเพื่อดึงคนกลับมาก่อนได้ ที่เหลือค่อยว่ากันไปเพราะมันออก update ตามมาได้ Backlog ที่ได้และมี priority สูงสุดจึงต้องตอบโจทย์เหล่านั้นนั่นเอง

เพราะฉะนั้น เมื่อกำหนด priority ของ Product Backlog คนที่เป็น Scrum master จะต้องถามย้ำกับ Product Owner ให้ชัดเจนว่าเราพัฒนาระบบนี้เพื่ออะไร ข้อไหนที่มีคุณค่าต่อธุรกิจของเค้ามากกว่ากัน และในกรณีที่ไม่สามารถพัฒนาให้เสร็จทัน คุณอยากเห็นอะไรก่อน ซึ่ง Product Backlog จะเป็นเครื่องมือชิ้นแรกที่เป็นตัวผลักดันให้การพัฒนา software เป็นไปในรูปของ Iterative & Incremental ครับ

จากตัวอย่าง web TheThaiHandMade.com เป็นไปได้ที่ Backlog #4 และ #5 อาจจะมี priority ต่ำกว่า เพราะถ้าไม่มี 2 ข้อนี้ ระบบก็ยังทำงานได้ มันเป็นแค่ marketing feature เท่านั้น ทำ manual ยังได้เลย

การกำหนด priority ยังช่วยรับมือกับความเสี่ยงที่อาจจะตามมาได้ด้วย เช่น ถ้าทำไม่ทันจริงๆ คุณก็ต่อรองให้เอาคนของคุณไปนั่งทำ manual ให้เค้าก่อน แล้วรีบพัฒนาส่วนนั้นให้เสร็จตามไป ลูกค้าเค้าก็ ok แหละครับ เพราะงานเค้าเดินไปได้ จริงไหม ^_^

เมื่อเราได้ Product Backlog แล้ว เราก็กลับไป meeting กับ The Team เพื่อทำความเข้าใจและเตรียมการวางแผน ออกแบบ และประมาณการ (ในตัวอย่าง มาเฉพาะ senior) ซึ่งเมื่อเอาไปคุยกันก็เป็นไปได้ที่อาจจะมีบางจุดที่ไม่ clear ว่ามันคืออะไร หรือต้องทำยังไง … นั่นคือ อย่าไปคิดว่าทำครั้งเดียวสร็จ มันต้องมีรอบที่ 2 รอบที่ 3 แน่ๆ เพราะฉะนั้น…

Practice #10 : การพัฒนา Product Backlog ทำครั้งเดียวไม่จบแน่นอน เพราะฉะนั้นให้เอาแนวคิดของ Iterative & Incremental มาใช้ด้วย ถ้าติดตรงไหนก็กลับไปถาม Product Owner แล้วเอามาแก้ไขใหม่ ทำซ้ำไปเรื่อยๆ จนกว่าจะลงตัวครับ ห้ามคิดเองเออเองเด็ดขาด

สังเกตุว่า ถ้า Product Owner ทำงานอยู่กับ The Team ตลอดเวลาได้ Practice ข้อก็ไม่จำเป็นเลยครับ เพราะสงสัยอะไรเค้าก็อยู่ให้ถามตลอดครับ แค่หันหน้าไปถามเท่านั้นเอง ไม่ต้องคิดว่าเป็นรอบๆ หรือต้องนัด meeting อะไรให้วุ่นวาย

Agile Principles ที่เกี่ยวข้อง คือ The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. และ Business people and developers must work together daily throughout the project.

Conclusion

Scrum ไม่ได้เน้น format ของ Backlog ว่าจะต้องมี detail แค่ไหน เพราะ format เหล่านั้นขึ้นอยู่กับความ “จำเป็น” ตามแต่ละบริษัทหรือหน่วยงานนั้นๆ ว่าต้องมีอะไรบ้าง สิ่งที่จำเป็นสำหรับ Backlog นั้นมีแค่นี้ครับ ถ้ามันไม่ชัดเจนก็ใส่ detail ลงไป แต่อย่าใส่ detail ให้เกินจาก scope ของ Backlog ข้อนั้นๆ และอย่าเพิ่งลงรายละเอียดเกี่ยวกับเรื่องเทคนิคหรือเทคโนโลยีครับ ยังมีเวลาให้คุณทำอีกเยอะเลย ถ้าอยากได้ตัวอย่างของ Product Backlog ก็ลอง google ดูนะครับ

ผมคิดว่าการที่ให้ Product Owner เป็นคนเขียน Product Backlog เองนั้น เป็นอุบายอย่างหนึ่งที่ Scrum พยายามลดความผิดพลาดจากการสื่อสารเรื่อง requirement ลง ในความเป็นจริงมันก็ไม่ได้ทำให้ปัญหานี้มันหมดไปนะครับ เพราะคนเรายังไงมันก็ต้องมีผิดพลาดกันได้เสมอ จึงต้องอาศัย practice อื่นๆ ประกอบกันเพื่อช่วยลดความผิดพลาด และช่วยให้แก้ไขได้ง่ายขึ้นเมื่อมีปัญหา ซึ่งมันก็จะสะท้อนออกมาในรูปของ practice ต่างๆ ตามที่แนะนำไปแล้ว และถึงแม้ว่าวิธีการเหล่านี้จะไม่ work กับงานของคุณ เหล่า Guru ทั้งหลายก็ไม่ได้ห้ามไม่ให้คุณใช้วิธีอื่น เพราะใน principle ก็มีข้อแนะนำว่าถ้ามันไม่ work หรือมีวิธีการที่ดีกว่าก็ให้ปรับไปใช้และคอย improve คุณภาพของงานอยู่เสมอครับ เพียงแต่เค้าแนะนำว่าให้ลองทำดูก่อนว่ามัน work ไหม (เพราะมีหลายคนที่ทำก่อนคุณแล้วก็มีทั้ง work และไม่ work) และถ้าไม่ work ก็ให้หาต้นตอของปัญหา ศึกษาจาก forum ต่างๆ ที่เค้าใช้จริง หาแนงทางใหม่เพื่อแก้ปัญหากันต่อไปครับ

ตอนนี้ค่อนข้างยาวทีเดียวเมื่อเทียบกันตอนก่อนๆ (เล่นเอาเหนื่อยเลย …) ในตอนต่อไปเราจะมาว่ากันเรื่อง Release Planning Meeting ครับ แต่คิดว่าคงไม่จบในตอนเดียวแน่เลย การ planning & estimating มันไม่เคยง่ายอยู่แล้ว … อ้ากกก … เอาเป็นว่ารอติดตามกันต่อ อย่าเพิ่งเบื่อนะครับ นี่เพิ่งเริ่มของจริงเอง ^_^