เมื่อเกิดเหตุการณ์แบบนี้ขึ้น เราจะแก้ปัญหายังไง?

  • เราเป็นทีมที่ใช้ Agile Framework
  • ทีม Dev มีคนมากกว่า QA มาก ประมาณว่า Dev 4 คน QA 1 คน
  • อยากได้ Automate test ในมุมมอง System (end-to-end) Test ให้ cover มากกว่า 80%

หลายครั้งคนเป็นหัวหน้าจะมองแค่ Output ว่าอยากได้อะไรโดยไม่สน Input และ Process ระหว่างกลาง ความอันตรายของสิ่งนี้คือความสุขใจของคนในทีมจะถูกทำลายลงได้อย่างรวดเร็ว ถึงกระนั้นคนเป็นหัวหน้าก็ยังไม่สนใจอยู่ดี (เยี่ยมไปเลย) ถ้าเราเป็นคนที่อยู่ในทีม เราเป็นคนที่สนใจ Input และ Process ระหว่างกลาง … เราควรจะจัดการอย่างไร?

ผลการวิเคราะห์ได้ออกมาว่างานจะไปโหลดที่ QA เยอะมาก (ขอไม่เรียกว่าทีมเพราะมีอยู่คนเดียว) เพราะนอกจากจะต้องรับมือกับ Dev ตั้ง 4 คนแล้วยังต้องมาจัดการงานที่เป็น Automate test ด้วย (เอา Coverage ตั้ง 80%+) เราจะทำอะไรได้บ้างที่จะช่วยลดความกดดันตรงนี้ของ QA ผู้โชคร้าย ถึงจุดนี้ขอนำเสนอว่าเราน่าจะสร้างหลักการทำงานใหม่ขึ้นมาซักสองข้อคือ

  1. เราเป็นทีมเดียวกัน
  2. เราจะลองใช้ Kanban

ขยายความนิดนึงเรื่อง Kanban … หลักการง่ายๆมีแค่สองข้อ (1) Visualize Workflow (ทำอะไรคล้ายๆ Scrum หรือ Agile Board) และ (2) Limit Number of Work-In-Progress (WIP) หมายถึงว่าในแต่ละช่องเราจะกำหนดไปว่าจะมีงานอยู่ในนั้นได้มากสุดกี่งาน ตรงนี้มีไว้เพื่อสร้าง Focus ในทีมว่าควรพยายามทำงานให้เสร็จเป็นชิ้นๆและเพื่อช่วยในการแสดงให้เห็นถึงคอขวดที่เกิดขึ้นในกระบวนการทำงานของเรา

Kanban
แล้วจะใช้หลักการสองข้อที่ว่ามาแก้ปัญหานี้ได้อย่างไร?

  1. เราเป็นทีมเดียวกันคือเรามีสัญญาร่วมกันว่าเราจะช่วยกันทำงานอย่างจริงจัง ในกรณีนี้ Dev จะมาช่วย support QA ในการเตรียม Automate test
  2. เมื่อเพิ่มหลักการของ Kanban เข้าไป เราจะเห็นได้ชัดเจนขึ้นว่า ณ ตอนนี้ใครต้องการความช่วยเหลือในเรื่องงานบ้างและด้วยสัญญาที่มีทุกคนจะไม่รับงานใหม่จนกว่าจะไปช่วยกันทำงานที่ติดปัญหาอยู่ให้เสร็จก่อน

ประโยชน์คืออะไรบ้างหละ? ถ้าทำได้จริง … ที่เห็นได้ชัดคือ

  1. ทุกคนเป็นทีมเดียวกันจริงๆ
  2. Dev ได้มีโอกาสเรียนรู้งาน QA มากขึ้น
  3. งานเสร็จเป็นชิ้นๆด้วยคุณภาพที่ดี (ดูรูป — ถ้าเรากำหนด WIP = 2 เราจะทำงานสองงานแรกเสร็จภายใน 10 วันซึ่งเร็วกว่า WIP = 4)

WIP


ปัญหาที่จะตามมา? เท่าที่เห็นตอนนี้คือถ้า Dev ไม่ชอบงาน QA? มันอาจจะเกิดเหตุการณ์แบบนี้

  1. Dev รับปากแต่ไม่ช่วยจริงๆจังๆ
  2. Dev เบื่อและไม่มีความสุขในการทำงาน ทางแก้มีมั้ย?

ลองดูว่าแนวทางนี้เหมาะสมกับทีมเรามั้ย … หมุนเวียนให้ Dev แต่ละคนมาช่วยงาน QA เป็น Sprint ไปเพื่อสร้างอัตราส่วนที่สมดุลมากขึ้นจาก 4 : 1 กลายเป็น 3 : 2 คอขวดที่ QA ก็น่าจะน้อยลง อีกอย่าง Dev คนไหนที่ไม่ชอบงาน QA ก็ไม่ต้องทนทำแบบชั่วลูกชั่วหลาน แต่เราจะสับเปลี่ยนหมุนเวียนกันอย่างยุติธรรม

Ratio3_2
ปัญหาสุดท้าย … ท่านหัวหน้าใหญ่จะว่าอย่างไร?

 

ขอเพิ่มเติมบทความนิดนะครับ พอดีคุณ Kamon เขียนแนะนำแนวทางปฏิบัติที่ควรจะเป็นในเรื่อง Quality Assurance ใน Agile Team ไว้ที่นี่ครับ ลองอ่านดูนะครับ ได้ประโยชน์มากครับ ส่วนผมเองขออธิบายเพิ่มเติมดังนี้ครับ

 

ขอบคุณสำหรับคำแนะนำดีๆครับและต้องขออภัยที่ข้อเขียนของผมคลุมเครือและไม่ครบถ้วนในมุมมอง QA, Tester, และ Testing

ความตั้งใจที่ผมจะสื่อคือภาพของปัญหาในบริบทที่ชัดเจนนั่นคือ “หัวหน้าทีม Tester (เลี่ยงไม่ใช้คำว่า QA นะครับ) ต้องการให้ทีมของเค้าทำ Automate Test Script ในระดับ System (end-to-end) testing ให้ cover อย่างน้อย 80%” เผอิญว่าทีมนี้มีความแตกต่างของจำนวน Developer กับ Tester ที่มากเกินไป (4 ต่อ 1) ทำให้เกิดปัญหาว่า Tester ทำงานของเค้าไม่ทันครับ งานที่ไหลเข้ามาจาก Developer มันเยอะเกินไปมาก ฮ่าๆๆ

เมื่อเกิดปัญหาเช่นนี้ เราในฐานะคนรับผิดชอบจะมองแต่ Long-term solution ด้วยการปรับกระบวนการทำงานแบบหน้ามือเป็นหลังมือแบบนั้นคงไม่ได้ ปัจจัยนอกเหนือการควบคุมของเรามันมากเกินไป เรื่องคน เรื่องทักษะ เรื่องโครงสร้างทีม เรื่องเวลา ปัญหาที่อยู่ข้างหน้าต้องได้รับการแก้ไขโดยเร็วซึ่งในกรณีนี้ ผมจะลอง (ย้ำว่าลองนะครับ) ใช้วิธีที่ผมเขียนไว้ในการทำให้ปัญหานี้เบาบางลงเพราะผมคิดว่ามันเป็นแนวทางที่น่าจะเหมาะสมกับสถานการณ์ที่สุด เป็นวิธีที่ถูกต้องมั้ย ผมคงตอบไม่ได้ตอนนี้ครับ ถ้าไม่ถูกก็พยายามหาทางปรับปรุงแก้ไขกันต่อไป

ผมไม่มีข้อขัดข้องอะไรกับข้อเขียนของคุณ Kamon เรื่องกระบวนการทำงาน เรื่องหน้าที่รับผิดชอบของแต่ละคนในทีมครับ ถ้าทำได้จริงก็คงจะดีมาก ใครที่ได้อยู่ในสภาพแวดล้อมการทำงานแบบนี้ผมคิดว่าโชคดีและยินดีด้วยครับ แต่โลกแห่งความเป็นจริงของผมตอนนี้มันไม่ใช่ (อาจจะโลกแคบ) ทฤษฎีก็เรื่องนึงปฏิบัติก็อีกเรื่องนึง ผมเข้าใจว่ามีอีกหลายคน หลายทีม หลายบริษัทยังไปไม่ถึงจุดนั้น ทุกคนมีปัญหาเฉพาะหน้าให้ต้องแก้กันไปครับ ผมเพียงแค่นำเสนอแนวคิดต่อปัญหาในบริบทที่ชัดเจนดังกล่าวมา ไม่ได้ต้องการจะสื่อว่าอัตราส่วนของ Developer กับ Tester ต้องเป็น 1 ต่อ 1 หรือ x ต่อ y ครับ ขออภัยอีกครั้งที่ผมอธิบายได้ไม่ชัดเจนครับ

ป.ล. 1: Developer ทีมนี้ก็มีทำ Automate Testing ในระดับ Unit นะครับ ไม่ใช่ว่าผลักภาระ Testing ทั้งหมดไปให้ Tester ครับ

ป.ล. 2: ผมได้ยินมาบ่อยว่า “ถ้าทำ Agile หรือ Scrum ครึ่งๆกลางๆก็อย่าเรียกตัวเองว่าเป็น Agile/Scurm Team เลย” หรือ ”ถ้าบอกว่าตัวเองเป็น Scrum Master แต่ไม่ได้ทำตัว วางตัวตามที่หนังสือบอกไว้ว่าต้องทำก็อย่าเรียกตัวเองว่า Scrum Master เลย” สำหรับผมจะเป็น Agile หรือ Scrum หรือไม่ไม่ได้เป็นสาระสำคัญอะไรเลย สิ่งสำคัญคือเราเข้าใจในหลักการอย่างเพียงพอที่เราจะเลือกประยุกต์ใช้สิ่งเหล่านั้นให้เหมาะสมกับลักษณะงาน ลักษณะคน โครงสร้างและธุรกิจขององค์กร เป็น Agile/Scrum Team ไม่ได้การันตีความสำเร็จ หรือเป็น Agile/Scrum แบบครึ่งๆกลางๆแล้วจะต้องล้มเหลว

ผมเคยอยู่ในทีม (ทีมที่ผมภูมิใจมาก) ที่ทำ Agile แบบครึ่งๆกลางๆแต่ตลอดเวลา 5 ปีที่ผ่านมาทีมนี้สามารถส่งมอบงานได้ตรงตามเวลา ครบทุก Feature ด้วยคุณภาพที่ดี และ Product ก็ขายดีติดอันดับของบริษัทมาตลอด ที่แปลกคืออัตราส่วนของ Developer กับ Tester เกือบจะเป็น 1 ต่อ 1 แถมมี Phase System Test แยกออกมาไว้ทำ Regression Test อีกต่างหาก ซึ่งช่วงนั้นผมและเพื่อนๆ Developer ยังเคยไปช่วย Tester ทำ Testing อยู่บ่อยๆทำให้อัตราส่วนเกือบจะเป็น 1 ต่อ 1.2 ด้วยซ้ำ แต่คุณภาพก็ออกมาดี ทีมเราก็มีความสุขมากทีเดียวครับ

ขอบคุณครับ


คำถามเกี่ยวกับ Agile Development จากทางบ้านครับ ผมตอบจากความคิดตัวเองนะ ลองดูครับว่าคิดเหมือนกันมั้ย


การปรับเปลี่ยนกระบวนการทำงานมาเป็น Agile Development ควรเริ่มจากเล็กๆก่อน

ผมจะตอบว่า “ถูก” ก็ต่อเมื่อเราเข้าใจอย่างถ่องแท้ก่อนว่า “เล็ก” ในความหมายนี้แปลว่าอะไร ถ้าเล็กคือแค่ Product Team, Development Team และ QA Team แบบนี้ไปไม่รอดครับเพราะบริษัทนี้ไม่ได้มีแค่คนสามกลุ่ม เหตุการณ์ที่จะเกิดขึ้นคือ ทำ Software เสร็จตามหลักการทุกอย่างเลยนะ แต่ทำ Production Deployment ไม่ได้เพราะทีม Technical Operations ไม่ยอม ทำไมไม่ยอมหละ? ก็เพราะ Operational Requirements ไม่ได้อยู่ใน Product Backlog มาตั้งแต่ต้น พวก Transaction log, Monitoring log, หรือพวก Capacity figures (CPU Consumption, Memory Usage) ไม่มี แบบนี้ทีม Ops ก็ support ไม่ได้ครับ พอไม่ได้เค้าก็ไม่ยอมให้เอาระบบที่ไม่ผ่านมาตรฐานเค้าขึ้นไปอยู่บน Production Environment หรอก … แบบนี้ควรเริ่ม ”เล็กๆ” อยู่มั้ย?


ถ้าเป็นธุรกิจที่ต้องมีระบบหลังบ้าน เช่น ธนาคาร, บริษัทประกัน, Call Center หรือระบบจ่ายเงินเดือน (Payroll) ของฝ่ายบุคคล สิ่งที่สำคัญคือพวกรายงานต่างๆซึ่งจะมีอีกทีมที่รับผิดชอบคอยตรวจสอบความถูกต้องของยอดเงิน ข้อมูลลูกค้า/พนักงาน หรือ Transaction ต่างๆอยู่ เราไม่ถามเค้าเลยครับว่า Software ตัวที่เราทำอยู่มีผลกระทบยังไงกับกระบวนการทำงานของทีมนี้บ้าง ถึงเวลา Software เสร็จ ทีมนี้เค้าก็ไม่ยอมหรือไม่เต็มใจให้ Release หรอกครับเพราะ Software ตัวนี้ไม่มีระบบรายงานฝังอยู่นั้น … แบบนี้ควรเริ่ม “เล็กๆ” อยู่มั้ย?

นี่แค่ตัวอย่างครับ ยังไม่ได้พูดถึงกลุ่มงานอื่นๆในกระบวนการ Software Development เองเช่น ทีม Design, ทีม Architect, ทีม Hardware/Network ต่างคนก็ต่างมีความต้องการของตัวเอง มีประเด็นของตัวเอง

ถ้ามันเป็นตามที่ผมพูดมาจริงขอถามว่ามันเป็นไปตามหลักการของ Agile Development ที่ว่า “Working Software” มั้ยครับ? ไม่เลย มันจะไปเวิร์คได้ไงอะก็เมื่อจุดนั้นก็ติด จุดนี้ก็ขาด มันผิดตั้งแต่แรกแล้วครับที่คิดว่า “เล็กๆ” คือ Product Team, Development Team และ QA Team ถ้าเป็นแบบนี้นะมันจะกลายเป็นว่าทำผ่านไปซักพักถึงได้เริ่มรู้ตัวว่า อ่าว เวรล่ะ ลืม Ops, ลืมเรื่องรายงาน, ลืม Setup server, ลืมบอกทีม Hardware ว่าขอเปลี่ยน OS version สุดท้ายแล้ว Working/Shippable/Stable software at the end of every sprint ก็เป็นแค่คำพูดสวยหรูที่ไม่ได้เป็นจริงในทางปฏิบัติ

ทางที่ดีกว่า … ก็คงเห็นชัดแล้วว่าไปนั่งทบทวนคำว่า “เล็กๆ” ซะใหม่โดยเร็ว ความหมายของมันคือ Working Cross-Functional Team ที่เล็กที่สุดที่ประกอบด้วยคนจากทุกแผนกที่อยู่ในบริษัทต่างหาก Software ไม่ได้สร้างมาได้เพราะ Product Team, Development Team และ QA Team เท่านั้น และมันก็ไม่ได้ถูกสร้างมาให้เฉพาะลูกค้านอกบริษัทใช้ครับ คิดถึงคนข้างในบ้านก่อนครับ

Product Owner มีหน้าที่เขียน Story Card ให้ละเอียดที่สุด

ถูกครึ่งเดียวครับ ใช่ Product Owner มีหน้าที่เขียน Story Card แต่ไม่ใช่ว่าต้องละเอียดที่สุดเพราะอะไรเดี๋ยวเล่าครับ อีกอย่างคือไม่ใช่ว่าจะมีแค่ Product Owner ที่เขียน Story Card ได้นะ คนอื่นในทีมก็เขียนได้หรือช่วยในการให้ข้อมูลเพิ่มเติมใน Story Card แต่ละใบได้ แล้วทำไมไม่ต้องเขียนให้ละเอียดที่สุดหละ? ถามนิดครับ ไอ้ที่เราเคยเขียนละเอียดที่สุดอะครับคุ้นๆมั้ยว่ามันคืออะไร? … นึกไม่ออกบอกให้ มันก็ Product Functional Spec, Software Requirement Spec, Application Functional Spec ชื่ออะไรก็แล้วแต่เหอะ มันก็ไม่ต่างกันหรอกครับ แค่พวก Story Card นี้เป็นชิ้นเล็กๆ พวกนั้นเป็นเอกสารฉบับใหญ่ๆ ผมถามนิดรู้ได้ไงว่าให้เขียน Story Card แบบละเอียดแบบสุดๆแล้วมันจะไม่มีอะไรเปลี่ยนแปลงระหว่างที่มันแปะอยู่บนบอร์ดในช่อง To-Do มั่นใจขนาดนั้นเลย? นี่มันเป็น Waste อย่างหนึ่งในโปรเจกต์ครับ


อะ ต่อให้มันไม่เปลี่ยนเลยนะ มันก็ไม่ใช่ Story Card ที่ดีหรอกครับ จะชี้ประเด็นให้กระจ่างเราต้องรู้ก่อนว่าองค์ประกอบของ Story Card มีอะไรบ้าง

  1. Card … ก็การ์ดอะครับ ที่แปะบนบอร์ดนั้นแหละ … โอ้ เรามีแล้ว กู๊ด
  2. Confirmation … ก็เขียนไว้หลังการ์ดครับว่า Acceptance Criteria มีอะไรบ้าง … โอ้ว โคตรละเอียดไม่ต้องห่วง
  3. Conversation … ??? … ??? งงซิครับ ไม่ต้องมีแล้วครับ Conversation มีทำไมอะก็เค้าเขียนมาให้หมดแล้วไงในการ์ดอะ ทีมก็เอาไปทำตามนั้นแหละ

Conversation นี่แหละครับที่หายไป แล้ว “Individual interaction over process and tool” หละครับ หายไปด้วยมั้ย? ถึงไม่หายแบบ 100% แต่มันก็ไม่ได้เป็นการเอื้ออำนวยให้เกิดการพูดคนแบบคนต่อคนเลยครับ กลายเป็นงานจะเกิดขึ้นได้ต้องมีการทำ Deliverable Hand-Over มันเป็นแบบนี้ครับ ฉันไม่เริ่มงานถ้าเธอเขียน Story Card ไม่ละเอียด, ฉันไม่เริ่มงานถ้าหน้า Mock-Up ยังไม่มี, ฉันไม่เริ่มงานถ้ายังไม่ได้ตกลง High-Level Architectural Flow กับทีม Architect มัน Flexible ตรงไหน? Agile ยังไงครับ?

ใช่ครับที่ Story Card ควรจะถูกเขียนโดย Product Owner แต่เอาแค่ให้คนอ่านรู้เรื่องก็พอครับ “As a user, I want to be able to fix this problem, so that I can perform the next action.” ใส่ Confirmation (Acceptance Criteria) เข้ามาเท่าที่รู้ เท่าที่เข้าใจ แล้วไปคุยกับทีมครับ คุยกัน คุยกัน ใครมีข้อสงสัย ปัญหา ความกังวัล คำแนะนำอะไรก็ว่ากันมา Individual interaction ครับ ถ้าจะยึดติดการทำงานแบบ Silo อย่ามาใช้ Agile ครับ เสียเวลา ไม่รอดหรอก

Development Team มีหน้าที่ทำตามสิ่งทีเขียนใน Story Card ส่วน QA Team ก็เทสตามสิ่งที่บอกใน Story Card

นี่ไงครับผมที่ตามมาจากการยึดติดอยู่ที่ Story Card อย่างไม่มีเหตุผล มันเป็นแบบนี้ครับ ตอนทำ Product Demo Session มีคำถามว่า ทำไมไอ้นั่นไม่เป็นแบบนั้น ไอ้นี่ไม่เป็นแบบนี้ … คำตอบจากคนในทีมคือ อ๋อครับ จริงๆผมก็อยากให้เป็นแบบนั้นแหละ แต่ในการ์ดเขียนมาว่าต้องเป็นอีกแบบ??? อะไรครับนี่ ฮ่าๆๆ เหนื่อยอะ ไม่เห็นด้วยกับสิ่งที่อยู่ใน Story Card ก็พูดซิครับ Product Owner ไม่ถูกเสมอไปหรอก คุยกันซิครับ สำหรับผมมันแสดงให้เห็นเลยว่าหลังจากทำ Sprint Planning แล้ว Development Team ไปทาง Product Owner ไปอีกทาง ลาก่อนครับ Agile Development เลวร้ายกว่านั้นคือถ้ามีคำถามขึ้นมาหลังจากทำ Story นี้จบว่าทำไมไม่เทสตรงนี้ด้วยหละ คำตอบคือก็ไม่มีเขียนไว้ใน Story Card … ถ้าเพื่อนๆเป็นคนฟังจะรู้สึกยังไงครับ? สำหรับผมคือ ไม่เขียน ไม่ทำ ไม่คิด ไม่สน การทำงานแบบนี้จะสร้างสิ่งที่มีคุณภาพได้มั้ยครับ?


หลักการของ Agile เน้นการทำงานเป็นทีมมาก Agile Team ไม่ต้องการคนที่เก่งจัดแต่ไม่เอาเพื่อน ไม่ต้องการพวก One Man Show หรือ Super Hero ครับ เพราะ Agile คิดว่าเราทุกคนมีส่วนรับผิดชอบร่วมกันใน Product ที่เรากำลังพัฒนา ดังนั้นเมื่อไร Product Owner มีหน้าที่แค่เขียน Developer แค่โค๊ด QA แค่เทส นี่ไม่ใช่ Agile Team ครับ (สำหรับผมนะ) ไม่มีใครรู้ทุกเรื่องหรือรอบคอบทุกอย่างหรอกครับ ถ้ายึดติดแต่สิ่งที่ Product Owner บอกมาอย่างเดียวก็จบครับ ผมบอกได้เลยว่าต่อให้คนที่มีประสบการณ์น้อยที่สุดในทีมหลายๆครั้งเค้าก็มีความคิดหรือข้อเสนอแนะที่คนมีประสบการณ์ทั้งทีมรวมกันก็คิดไม่ได้ อย่าปล่อยให้มี Super Hero ในทีมครับ

Story Card ที่จะเอามาพิจารณาตอนทำ Sprint Planning ได้ต้องเป็น Story Card เก่าที่เขียนไว้เรียบร้อยแล้ว

ฮ่าๆๆ เอาเข้าไปครับ ไม่รู้ไปได้ความคิดแบบนี้มาจากไหนเหมือนกันนะ ผมถามกลับไปครับว่ารู้มั้ยว่าหนึ่งในหลักการที่เป็นหัวใจของ Agile Development คือ “Responsive to change over following a plan” แล้วที่กำลังเข้าใจหรือทำอยู่เนี่ยมัน Responsive to change ตรงไหนไม่ทราบ? Story Card ที่จะถูกหยิบเข้า Sprint หรือไม่มันวัดกันที่ความสำคัญ (Priority) ครับไม่ใช่อายุใครถูกเขียนก่อนเขียนหลัง (ไปกันใหญ่สุดๆ)


ถ้าเรายึดหลักนี้นะ ระหว่างทำ Product Demo Session มีข้อเสนอแนะจากหัวหน้ามาว่า “ผมคิดว่า Workflow มันไม่ถูกนะ ทำแบบนี้ลูกค้าต้องงงแน่เลย ควรปรับเป็นแบบนี้มากกว่า … สำคัญนะครับควรต้องรีบแก้เลย” Product Owner จดยิกๆมาล่ะ วันรุ่งขึ้นทำ Sprint Planning สำหรับ Sprint ใหม่ เพื่อนผมถามว่า “วันนี้เราจะหยิบเรื่องที่ได้คำแนะนำเมื่อวานมาพิจารณาด้วยมั้ยครับ?” คำตอบ “คงไม่ได้ครับ เพราะเราจะพิจารณาจาก Story Card เก่าก่อน อันนั้นยังเขียนไม่เรียบร้อย” ฮ่าๆๆ คิดเอาเองนะครับว่านี่มันคืออะไร

นอกจากจะเข้าใจผิดอย่างใหญ่หลวงแล้วยังฝังใจมากด้วยว่า Story Card ที่ดีคือ Story Card ที่มีรายละเอียดเยอะที่สุดเท่าที่จะเป็นไปได้ (ข้อที่สองอะครับ) ถ้าเขียนไม่เสร็จฉันไม่มีสิทธิมีเสียงในการขอให้ทีมหยิบเข้ามาพิจารณาใน Sprint Planning มันช่าง Responsive to change เสียนี่กระไร สาธุ

ต้องมี Product Manager และ Product Owner

อันนี้ตอบยากนะครับเพราะผมก็ไม่เข้าใจโครงสร้างองค์กรนี้แบบลึกซึ้งเหมือนกัน แต่จากความเห็นส่วนตัว Agile Team ควรจะมีโครงสร้างที่แบนที่สุด (Flat Organization) เท่าที่จะเป็นไปได้เพื่อช่วยให้การสื่อสารและทำงานร่วมกันมีประสิทธิภาพสูงสุด ดังนั้นในกรณีนี้ถ้า Product Manager และ Product Owner เป็นคนละคนกันแล้วมีส่วนร่วมในการตัดสินใจทั้งคู่ อันนี้จะเป็นปัญหาแล้วหละครับ


หรือการทำงานจะเป็นว่า Product Manager มีหน้าที่เขียน Business Requirement แบบใหญ่ๆแล้วส่งให้ Product Owner ทำเป็น Story Card (ไม่ว่าจะ Epic, User Story ก็ตามแต่) จากนั้น Product Owner เป็นคนไปคุยกับ Agile Team (Development/QA/อื่นๆ) อีกต่อหนึ่งเพื่อให้เข้าใจถึงสิ่งที่ Product Manager ต้องการ วันสุดท้ายของ Sprint ก็เอา Product มาทำ Demo ให้ Product Manager ดูว่ามันใช่ตามที่เค้าต้องการมั้ย แบบนี้รึเปล่าผมไม่แน่ใจ

แต่ที่พอจะเดาได้เลยคือ Product Manager ซึ่งเป็นคนที่อยากได้นั่นได้นี่จะไม่มีโอกาสได้คุยกับ Agile Team ตรงๆ ทุกอย่างผ่าน Product Owner ซึ่งตามหลักการจะเป็นคนที่ต้องรู้เรื่อง Technical พอมาดูข้อนี้แล้วผมก็สงสัยว่าทำแบบนี้ไปเพื่ออะไร มันจะเป็นยังไงหละถ้า Product Manager และ Product Owner จะเป็นคนคนเดียวกัน แล้วก็คุยกับ Agile Team โดยตรง การสื่อสารความสัมพันธ์มันจะดีกว่านะ จะไปทำให้มันยากด้วยการไปหาคนอีกคนมาขั้นกลางทำไม

หรือเป็นเพราะ Product Manager ไม่รู้ Technical เลย ถ้าเป็นแบบนั้นจริงก็ต้องพัฒนาตัวเองขึ้นมาครับ คนรู้ Technical ก็อยู่ใน Agile Team นั่นแหละ ยิ่งไปจับพวกเขาแยกกันทำงานยิ่งแย่ไปใหญ่ Product Manager ก็ไม่รู้ Technical ส่วน Agile Team ก็ไม่รู้เรื่อง Business ผมไม่เห็นข้อดีมันเลยนะที่ทำแบบนี้ ไม่แน่ใจคนอื่นคิดยังไง

อยากได้ความโปร่งใสในการทำ Software

อันนี้เห็นด้วยมากครับว่าเราควรมีความโปร่งใสในการทำงานและ Agile Development ก็ตอบโจทย์นี้ได้ดีเลยครับสำหรับ Software Development การมี Agile Board, การมี Sprint Planning, การมี Story Point, การมี Velocity, การมี Burndown Chart, การมี Retrospective, และอื่นๆ อันนี้คนในฝั่ง Business น่าจะรู้สึกว่าเข้าถึงการทำงานของ Development หรือ QA มากขึ้น แต่ …


ในทางกลับกันหละครับ ผมเป็น Developer ผมอยากรู้อยากเห็นความโปร่งใสในงานฝั่ง Business บ้างได้มั้ย มีให้ผมดูมั้ยครับ บางคนอาจจะบอกว่านี่ไง Requirement ตอนนี้ก็ทำให้เล็กลงมาจนเป็น User Story แล้วไงยังไม่พอใจอีกหรอ ขอบคุณครับ แต่ผมยังไม่พอใจ ผมอยากถามว่าแล้วคุณรู้ได้ยังไงว่า User Story นั้นอะเป็นสิ่งที่ลูกค้าคุณต้องการจริงๆ มีการสำรวจตลาดจริงมั้ย มีการคุยกับกลุ่มลูกค้าบ้างรึเปล่า หลักฐานอยู่ไหนครับ ข้อมูลของลูกค้าที่คุณได้มาหนะมันมีความสัมพันธ์ยังไงกับ User Story ที่คุณมาสั่งให้ผมทำครับ? อีกอย่างคุณมีระบบวัดผลอะไรเป็นชิ้นเป็นอันมั้ยว่าเมื่อ Release ออกไปแล้วบรรลุวัตถุประสงค์ที่ตั้งไว้มั้ย เช่น มีคนใช้มากขึ้นหรอ? มีรายได้เพิ่มขึ้นเพราะ Feature ใหม่ที่เพิ่งใส่เข้าไปมั้ย? มี Business KPIs หรือ Metrics ให้ดูมั้ยครับ?

Agile Development ให้ความสำคัญกับคำว่า Team มากด้วยความเชื่อที่ว่าการทำงานเป็นทีมจะช่วยให้งานเสร็จเร็วขึ้น มีคุณภาพมากขึ้น และได้ประสิทธิภาพสูงสุด ถามว่าจับคนกลุ่มหนึ่งมารวมกันแล้วเรียกว่า Team มันใช่มั้ยครับ? คงไม่ง่ายแบบนั้นหรอก เพราะสำหรับผมสิ่งสำคัญที่จะสร้างความเป็น Team ขึ้นมาได้คือคำว่า Trust หรือความเชื่อถือ ความเชื่อมั่นซึ่งกันและกัน และ Trust สร้างได้จากความโปร่งใสในทุกจุด ทุกมุมของการทำงาน นั่นหมายรวมถึงความโปร่งใสในทีม Business ด้วยครับ สำหรับเพื่อนๆที่อยู่ทีม Development หรือ QA ก็ตามเคยมั้ยครับที่สงสัยว่าจะทำ Feature นี้ไปทำไม เขียนก็ยาก เทสก็ยาก ใช้ก็ยิ่งโคตรยาก ผมเดาว่าคงมีบ้างแหละแต่ก็พูดหรือเถียงอะไรคนที่สั่งให้ทำไมได้ต้องทนทำไปด้วยความไม่เชื่อมั่นใน Software ของตัวเอง แล้วสุดท้ายพอ Release ออกไปกลับไม่มีคนใช้ ขายไม่ออก ลูกค้าไม่เข้าใจว่ามันคืออะไร … ผ่านไป 1 เดือนทีม Business จะมาพร้อมกับ Requirement ชุดใหม่ที่อยากให้ทำเสร็จภายใน 2 เดือน … ถามเพื่อนๆว่า “อยากทำให้เค้ามั้ยครับเนี่ย?”

จบ  :twisted:

Mindly_in_Blog_Post_608


สวัสดีครับ Chapterpiece Meeting ครั้งที่ 7 ครับ … ครั้งนี้ขอให้เป็นเรื่อง Agile Development เบื้องต้น (ย้ำว่า เบื้องต้น) สำหรับเพื่อนๆที่สนใจแต่ยังไม่มีโอกาสได้เรียนรู้เรื่องนี้ครับ ผมตั้งใจไว้ว่าครั้งนี้จะเป็นกลุ่มเล็กๆเพราะอยากดูแลทุกคนอย่างทั่วถึงลงรายละเอียดให้ได้เยอะที่สุดเท่าที่ทำได้ และอีกอย่างคือสถานที่ครั้งนี้อาจจะไม่เอื้ออำนวยให้จัดมีตติ้งแบบกลุ่มใหญ่ครับ


ChapterpieceMeeting7_598
มีตตี้งครั้งนี้มีเงื่อนไขสองข้อครับ

  1. ผมขอให้มีตติ้งครั้งนี้เป็นของเพื่อนๆที่ยังไม่มีโอกาสได้เรียนรู้เรื่อง Agile Development เท่านั้นครับ เพราะสิ่งที่ผมจะเล่าในครั้งนี้จะเป็นเรื่องเบสิกเบื้องต้นจริงๆซึ่งอาจจะไม่มีประโยชน์สำหรับคนที่รู้เรื่องนี้อยู่แล้ว
  2. ผมขออนุญาตพูดคุยแบบตัวต่อตัวกับเพื่อนๆที่มามีตติ้งครั้งนี้เพื่อเก็บข้อมูลเกี่ยวกับ Mindly.Me เวปไซต์ที่ผมกำลังพยายามปลุกปั้นมันอยู่ครับ วัตถุประสงค์ของการพูดคุยครั้งนี้คือเพื่อเรียนรู้จากทุกคนเกี่ยวกับปัญหาในการวางแผนท่องเที่ยว ผมจะเล่าให้ฟังว่าผมมองว่าเรื่องนี้เป็นปัญหาอย่างไรแล้วเพื่อนๆมองว่ามันเป็นปัญหาเหมือนผมมั้ยครับ

ไม่ต้องกังวลครับผมไม่มีอะไรมาขายหรือชักชวนอย่างอื่นเลยครับ ฮ่าๆๆ สำหรับเพื่อนๆที่อยากรู้เรื่อง Agile Development เบื้องต้นและยินดีพูดคุยกับผมเรื่อง Mindly.Me เชิญลงทะเบียนจ่ะ … 5 คนนะครับ


คลิ๊กที่นี่เพื่อลงทะเบียนครับ

ขอบคุณครับ :D

Mindly_in_Blog_Post_608


ต่อกันเรื่อง Project Dashboard นะครับ จากบทความความซับซ้อนกับความคืบหน้าเราใช้ค่าความซับซ้อน (Complexity) ของงานแต่ละงานเข้ามาช่วยในการคำนวณหาความคืบหน้าโดยรวมของทั้งโปรเจกต์แล้วก็ต่อไปถึงการคำนวณหาวันเสร็จของโปรเจกต์ แน่นอนครับเมื่อมีการคำนวณต่อเนื่องเป็นโดมิโน่แบบนี้ถ้าค่าความซับซ้อนคลาดเคลื่อนมันก็จะทำให้ค่าอื่นๆที่ตามมาคลาดเคลื่อนไปหมด แล้วมันจะคลาดเคลื่อนได้ยังไงหละ? ขอเล่าจากประสบการณ์จริงครับ


Team “ME” vs. Team “YOU”

สาเหตุใหญ่ที่สำคัญที่สุดเลยคือเราไม่ได้กำหนดค่าความซับซ้อนนี้ร่วมกันครับ “เรา”ในที่นี้คือทีมงานทั้งหมดที่มีส่วนร่วมในโปรเจกต์ครับ ชัดเจนที่สุดจากภาพตัวอย่างข้างล่างคือ Development Team รับผิดชอบ Implement ส่วน QA Team รับผิดชอบ Test ตัวเลขความซับซ้อนที่ได้ก็ต่างคนต่างคิดกันมาและเพราะมุมมองต่อความยากของงานที่ต่างกันทำให้ความซับซ้อนในแต่ละระดับของ Development Team จะไม่เท่ากับ QA Team


Complexity_Problem
รูปบนคือ Dashboard ที่แสดงให้เห็นว่า โอ้ โปรเจกต์ดีเลย์แน่ๆ เพราะว่าผ่านไปครึ่งทางของเวลาแล้วยังทำงานได้ไม่ถึง 50% เลย อ่าว แต่รูปด้านล่างกลับบอกว่าโปรเจกต์ยังไปได้ตามที่วางแผนไว้นี่ สังเกตเห็นความแตกต่างใช่มั้ยครับ มันคือค่าความซับซ้อนของงานฝั่ง QA Team ที่ลดลง อันนี้เกิดจากเมื่อเราจับทุกทีมเข้ามานั่งคุยกันจริงๆจังๆแล้วกลับพบว่า เฮ้ย มุมมองตอนแรกต่อค่าความซับซ้อนของงานเราไม่เหมือนกันนี่ จริงๆแล้วที่ Development บอกว่า 2 หนะมันก็ความหมายเดียวกับที่ QA มองว่า 2 เลย ไม่ใช่ 3 เหมือนตอนแรกที่ใส่ค่ามา … ตรงนี้ก็จะเกิดการปรับค่าความซับซ้อนของทุกงานที่มีแล้วการคำนวณความคืบหน้าโดยรวมและวันเสร็จของโปรเจกต์ก็จะได้ค่าใหม่มาซึ่งดูดีขึ้น :D

Rule Zero – Team “US”

รู้สาเหตุปัญหา ทางแก้ก็จะตามมา นั่นก็คือจับทุกทีมเข้ามาร่วมกำหนดค่าความซับซ้อนร่วมกันเลยครับ จะให้ดีเราควรเปลี่ยนวิธีการเขียน Task ใน Project Plan เราใหม่ให้เป็นลักษณะของ User Story ไปเลยครับ นั่นคือไม่ต้องแยก Task Implement, Test หรือ Fix แล้ว จับรวมกันเป็น Task เดียวเลย นอกเหนือจากเราจะได้ค่าความซับซ้อนที่เป็นมาตรฐานแล้วเราจะได้ประโยชน์มากในแง่ของการทำงานเป็นทีมร่วมกันครับ เพราะการมี Task เดียว Implement เสร็จก็ไม่ใช่ว่า Task เสร็จเหลือ Test เหลือ Fix อีกซึ่งตามสามัญสำนึก (ถ้าไม่มีก็ต้องสร้างขึ้นมา) ทุกคนที่รับผิดชอบ Task นี้ต้องช่วยกันทำงานผลักดันให้มันเสร็จให้ได้ตามที่สัญญาไว้ รักๆกันไว้ครับ

ป.ล. ความรู้ Agile Development เบื้องต้นครับ - http://goo.gl/BDDqo
ป.ล. เกี่ยวกับ User Story โดยเฉพาะครับ - http://goo.gl/uXVo8


Mindly_in_Blog_Post_608

Download Project Dashboard + Gantt Chart

Posted by kannique On April - 13 - 2013ADD COMMENTS

คุณสมบัติอย่างหนึ่งของ Dashboard หรือ Report ที่ดีก็คือความชัดเจนของข้อมูลสำคัญครับ ประมาณว่าเห็นปร๊าดเดียวรู้เลยว่ามันคืออะไร เช่น รู้เลยว่ารายได้เพิ่มขึ้นหรือจำนวนลูกค้าลดลงเมื่อเทียบกับเดือนที่แล้ว สำหรับ Project Management ง่ายสุดก็คือสถานะของงานแต่ละงานที่เราทำ แล้วอะไรจะโดดเด่นชัดเจนและดึงดูดความสนใจเราได้มากกว่าสี? คงไม่มี ฮ่าๆ


ผมปรับปรุง Dashboard ล่าสุด (ดาวน์โหลดที่นี่) ด้วยการเพิ่ม Gantt Chart พร้อมสีสันสวยงามที่บอกสถานะปัจจุบันของงานที่เรามีทั้งหมดครับ ผมแบ่งสถานะของงานออกเป็นหลายกลุ่มอยู่นะ ตามรูปครับ

GanttChart
ขอบคุณครับ  :-D