คำถามเกี่ยวกับ 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 มีอะไรบ้าง
- Card … ก็การ์ดอะครับ ที่แปะบนบอร์ดนั้นแหละ … โอ้ เรามีแล้ว กู๊ด
- Confirmation … ก็เขียนไว้หลังการ์ดครับว่า Acceptance Criteria มีอะไรบ้าง … โอ้ว โคตรละเอียดไม่ต้องห่วง
- 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 เดือน … ถามเพื่อนๆว่า “อยากทำให้เค้ามั้ยครับเนี่ย?”
จบ 
