อไจล์โปรเจ็คเสร็จไปกี่เปอร์เซ็นต์แล้ว?


มีมิตรสหายท่านหนึ่งถามไว้ใน agile66 ว่า จะดูใน Jira อย่างไรว่าโปรเจ็คเสร็จหรือ complete ไปกี่เปอร์เซ็นต์แล้ว? เรื่องนี้ซับซ้อน เกินว่าแค่เรื่องการใช้ tool

การถามว่า เสร็จไปกี่เปอร์เซ็นต์? นั้นย่อมเป็นแนวความคิด (paradigm) แบบเก่า คือ มีความเชื่อที่ว่า “งานเสร็จเมื่อทำได้ครบตามที่วางแผนไว้” ซึ่งไม่เป็นไปตาม manifesto ข้อที่ว่า “Responding to change over Following a plan” กล่าวคือถ้าเราเชื่อ agile manifesto เราก็จะเชื่อว่า ขอบเขตในแผน ไม่ใช่ ขอบเขตที่แท้จริงของโปรเจ็ค เพราะความเปลี่ยนแปลงเกิดขึ้นได้ตลอดเวลา นั่นย่อมหมายความว่า เราไม่สามารถหาได้ว่า เราทำโปรเจ็คเสร็จไปแล้วกี่เปอร์เซ็นต์นั่นเอง

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

คำถามที่สำคัญในเรื่องนี้คือ ใคร ที่อยากรู้ ตัวเลข เปอร์เซ็นต์นี้ และอยากรู้ไปทำไม? ความจริงแล้ว ไม่มีใครอยากรู้หรอก ที่เขาหาตัวเลขนี้เป็นเพราะเขาอยากรู้ว่า โปรเจ็คจะ “เสร็จ” เมื่อไรต่างหาก ซึ่งการใช้ เปอร์เซ็นต์ที่ว่า ในการตอบคำถามนี้เกิดจาก ความเชื่อที่ว่า ความคืบหน้าของโปรเจ็ค เป็นลักษณะคงที่ (linear) แต่เรารู้ชัดเจนแล้ว ว่าไม่ใช่ (non-linear)

วิธีตอบคำถามนี้ในทางอไจล์ทำได้ง่ายๆ โดย ใช้ ขอบเขตที่เหลือ (Remaining Scope) หารด้วย ความสามารถของทีม (Velocity) ก็จะตอบคำถามได้โดยง่าย ตัวอย่างเช่น ใน Product Backlog มี work items เหลือรวม 200 point และ ทีมมี velocity 20 point ย่อมหมายความ ทีมต้องการเวลาอีกประมาณ 10 sprints/iterations จึงจะสามารถ ส่งมอบได้ทั้งหมด (ซึ่งไม่ได้หมายความว่าต้องส่งมอบทั้งหมดก็ได้)

สิ่งสำคัญคือ อไจล์ เป็น mindset ไม่ใช่ว่า ทำงานเป็นทีม เป็น sprint แล้วจะเป็นอไจล์ เสมอไป

Advertisements

Story Point is not size


เร็วๆ นี้ ผมพบว่า มีหลายคนเข้าใจผิดเกี่ยวกับการใช้งาน Story Point ในการ estimate งาน ว่าเป็นขนาดของงาน(Size) ซึ่งก็ดูเผินๆ ก็เหมือนจะไม่ผิดอะไร แต่แค่ความคลาดเคลื่อนเล็กน้อยตรงนี้ทำให้เกิดความเข้าใจผิดตามมามากมาย
อ่านเพิ่มเติม

ทำไมเราจึงวางแผนให้มี Bug?


ในบรรดากระบวนการสร้างซอฟแวร์ ขั้นตอนที่ผมว่าผิดปกติที่สุดคือการทำ UAT

เหตุใดจึงเป็นเช่นนั้น?

UAT นั้นย่อมาจาก User Acceptance Test แปลเป็นภาษาง่ายๆ ว่า “การทดสอบเพื่อตรวจรับโดยผู้ใช้” ซึ่งก็ดูจะไม่ผิดปกติอันใด เมื่อเราทำของให้เขา เขาก็ต้องมาตรวจรับ แต่สิ่งที่ผิดปกติ คือ “การทดสอบ”

อ่านเพิ่มเติม

โค้ชอไจล์ขี้โกหก


ผมได้รับฟีดแบ็คว่าให้คำแนะนำสองครั้งไม่เหมือนกันจากหลายโอกาส จนต้องมาพิจารณาตัวเองว่า หรือเราจะเป็นคนขี้โกหก

อ่านเพิ่มเติม

Maximize Value vs Maximize Profit


เมื่อวานได้มีโอกาสเข้าคลาสที่อยากเข้ามานาน แต่ที่ติดใจกลับเป็นเพื่อนร่วมคลาสท่านหนึ่งที่กรุณาพยามแก้ไขความเข้าใจของผมเกี่ยวกับการทำ prioritization ว่า อันที่จริง ไม่ใช่เรียงตาม value ของ customer แต่เป็นของบริษัทเราต่างหาก

ท่านได้ตั้งคำถามชี้ชวนว่า สมมติ มี ลูกค้าสองราย รายหนึ่ง ถ้าเราไม่ทำของให้ ก็อาจจะถึงขั้น ล้มละลายแต่มีเงินจ่ายแค่ แสนเดียว แต่มีลูกค้าอีกราย มีเงินจ่ายหนึ่งล้าน เราจะทำให้ใคร ถ้าเราเลือกรายที่สองก็แสดงว่าเราเลือก value ของเรา ไม่ใช่ของลูกค้า ผมพยายามอธิบาย แต่เนื่องจากเวลาไม่อำนวยจึงไม่มีโอกาสได้พูดคุยกันต่อ ได้แต่เก็บความสงสัยว่าเบื้องลึกเช่นไร จึงทำให้ท่านคิดเช่นนั้น
นอนคิดอยู่คืนหนึ่งจึงได้ข้อสรุปกับตัวเองว่า ท่านผู้นั้นคงจะมีความเชื่อในเรื่อง zero-sum game ซึ่งเชื่อว่า เมื่อมีฝ่ายหนึ่งได้ต้องมีอีกฝ่ายหนึ่งเสีย
อ่านเพิ่มเติม

User Story คืออะไรกันแน่?


หลายคนเมื่อเริ่มหัดใช้อไจล์ก็จะได้รู้จัก User Story ซึ่งมักจะถูกสอนว่า ต้องเขียนในรูปแบบ “As a , I want to so that ” ซึ่งฟังดูก็ง่ายดี แต่พอเอาไปใช้งานจริง กลับรู้สึกสับสน งงงวย ไม่รู้ที่ทำมันถูกหรือผิด หรือเอาว่าถูกตามรูปแบบเป๊ะๆ แต่ทำไมมันไม่ค่อยเวิร์คยังไงไม่รู้ อ่านเพิ่มเติม

Acceptance Criteria คืออะไร?


หลายคนพอเริ่มใช้อไจล์ ก็ได้รับคำแนะนำให้แบ่งงานเป็น user story และที่สำคัญคือมีการกำหนด Acceptance Criteria หรือที่บางคน เรียกย่อๆ ว่า AC ให้กับแต่ละ user story ทีนี้ก็เกิดคำถามตามมามากมายเกี่ยวกับเจ้า Acceptance Criteria นี้ อ่านเพิ่มเติม