โปรเจ็คมีกี่แบบ


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

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

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


มีมิตรสหายท่านหนึ่งถามไว้ใน 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 แล้วจะเป็นอไจล์ เสมอไป

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 นี้ อ่านเพิ่มเติม

ว่าด้วยปัญหาอไจล์?


วันก่อน มีพี่ท่านหนึ่งโพสทำนองว่า “อไจล์แค่ที่ Development ไม่ช่วยอะไร” แล้วก็มีพี่อีกท่านหนึ่งตอบว่า “อไจล์แค่ที่ Management ก็ไม่ช่วยอะไรเหมือนกัน” มาคิดดูก็ถูกทั้งคู่ งั้น อไจล์ที่ไหนดีนะ ที่ Marketing ดีมั้ย? หรือ ที่ HR หรือ เอามันทั้งบริษัทครั้งเดียวแบบ Big Bang ดี คิดไปคิดมา คำครูอาจารย์ก็ผุดขึ้นมาว่า “คำตอบที่ถูกต้อง มาจากคำถามที่ถูกต้อง” เอ้อจริง “อไจล์ที่ไหนดี?” อาจจะไม่ใช่คำถามที่ถูกต้องกระมัง แล้วคำถามอะไรล่ะจึงจะถูกต้อง คิดวนไปมาจนจู่ๆ ก็ผุดขึ้นมาอีกว่า “เราอไจล์ไปทำไมนะ?” เพิ่มคุณภาพ หรือเปล่า? หรือว่า “ทำให้ลูกค้าพอใจ” หรือ “ทำให้กำไรมากขึ้น” สุดท้ายคำครูก็ผุดขึ้นมา อ่านเพิ่มเติม

Maxwell Curve : ทำไมยิ่งลงแรงมากยิ่งได้งานน้อย


ถอดความจาก The Maxwell Curve: Getting more production by working less!

Maxwell Curve

เรื่องมีอยู่ว่าระหว่างที่เจฟ ซัทเทอร์แลนด์(Jeff Sutherland) ทำงานเป็นโค้ชให้กับ OpenView Venture Partners หนึ่งในผู้บริหาร(Scott Maxwell) ได้มาหาเขาพร้อมกับกราฟ หน้าตาเหมือนข้างบน เขาตั้งชื่อมันว่า “เส้นโค้งของแมกซ์เวล” (Maxwell Curve) อ่านเพิ่มเติม