เกี่ยวกับ Korn4D

Agile, Lean, Toyota Way, Scrum, Buddhism, XP

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


มีมิตรสหายท่านหนึ่งถามไว้ใน 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

Agile Coach DNA


มีโอกาสได้ร่วมงานกับทีมงานด้านการขายของบริษัทแห่งหนึ่ง รู้สึกประทับใจที่เขามีการการกำหนด DNA ด้วย เป็นไปตามหลักการที่เปลี่ยนจาก KPI เป็น KBI (Key Behavior Indicator) กล่าวคือเน้นที่การปรับพฤติกรรม มากกว่า วิ่งหาแต่ผลงานอย่างเดียว เพราะทำให้เกิดอาการ “งานได้ผล แต่คนเสียหาย”

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

Story Point is not size


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

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


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

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

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

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

อปริหานิยธรรม – ธรรมะที่ต้องสร้างเอง


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

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


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

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

ทุกคนควรโค้ดได้ จริงหรือ?


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