Project Planning in Agile by

30
Jun
0

ไปงาน Agile Thailand 2012 มาครับ เลยขอ blog เก้บไว้หน่อย (เดี๋ยวจะลืม) เป็นเรื่องของการวางแผน Project Planning style Agile โดยมีหลักเบื้องต้นที่ต้องทำความเข้าใจกันก่อนคือ Agile ถูกออกแบบมาสำหรับรองรับการเปลี่ยนแปลงที่เกิดขึ้นตลอดเวลา (โดยเฉพาะอย่างยิ่ง Requirement) ดังนั้นอาจพบเห็นความไม่แน่นอนในหลายๆ อย่างระหว่างวางแผน ผิดกับการวางแผนทั่วๆ ไปที่พยายามจะวางแผนที่แน่นอนให้ได้เช่น

  • คุม Spec ให้นิ่ง Requirement ไม่เปลี่ยน (เป็นไปไม่ได้)
  • กำหนดระยะเวลาเสร็จที่แน่นอนให้ได้ เพื่อจะได้เอาไปบอกลูกค้าได้ถูก (อันนี้ไม่ว่าจะ plan แบบไหนก็คือการเดาด้วยกันทั้งสิ้น)
  • ถ้า Requirement เปลี่ยน ต้องแก้ให้ทันตามที่ลูกค้าต้องการ (ถ้ารับเละ ไม่ดูแรงของทีมงานก็ตายสถานเดียวครับ)

เป็นต้น ซึ่งถ้าทีมงานหรือบริษัทของคุณไม่ได้เป็นบริษัทขนาดใหญ่ (ทีม Programmer 1 ทีมใหญ่กว่า 3 คน) ก็คงไม่ค่อยเห็นภาพอะไรนัก เนื่องจากคนน้อย การบริหารจัดการก็คือการคุยกันเรื่อยๆ เป็นระยะๆ จะดีที่สุดนั่นเอง แต่แม้คนจะน้อย Agile ก็จะช่วยจัดการจัดสรรปันส่วนงานต่างๆ ให้เป็นระเบียบขึ้น ง่ายต่อการเห็นภาพรวมของ project มากขึ้น เรามาดูขั้นตอนการทำงานแบบ Agile กันดีกว่า โดยทีมงานจะแบ่งเป็นสองตำแหน่งหลักคือ Product Owner (คนที่คุยกับลูกค้า รู้ว่าลูกค้าต้องการอะไร) และ Programmer มีขั้นตอนทำงานดังนี้ (ผมจะเขียนเน้นไปทาง Practice ของ Scrum นะครับ แต่ขั้นตอนการสร้าง card จะคล้ายๆ กันหมด)

  1. Product Owner ไปคุยกับลูกค้า แล้วมาขายฝันให้ทีมว่าจะมีโปรเจคนี้ๆ ลูกค้าอยากได้อะไรบ้าง โดยสมมติว่าลูกค้าอยากให้เราเขียนระบบ Forum ของเว็บไซต์ของเขา
  2. Product Owner เขียนสรุป Requirement ออกมาเป็น User Story ในรูปแบบ Card 1 Story ต่อ 1 Card ซึ่งมี template ของ Story คือ ”As a <role>, I want <goal/desire>” เช่น “ในฐานะ guest ต้องดู forum ได้”, “ในฐานะ member ต้องตั้งกระทู้ใหม่ได้” ซึ่งการสร้างแต่ละ Story ควรจะรู้ด้วยว่าทำไปเพื่ออะไร (ไม่งั้นก็ทำฟรี ไม่มีประโยชน์) ตรงนี้ต้องระวังว่าห้ามเขียนเป็นรูปของ Task เช่น setup database, เขียน function a() ต้องเป็น story ที่ลูกค้าอ่านเข้าใจ และถ้าเสร็จออกมาให้ทดลองใช้แล้วลูกค้าจะได้ประโยชน์อย่างชัดเจน (เช่นเขียนว่าระบบค้นหากระทู้ ไม่ใช่ function search)
  3. เมื่อสรุปเสร็จทั้งหมด Product Owner ก็จะเรียงลำดับความสำคัญของ Feature ที่ลูกค้าอยากเห็นก่อน-หลัง ซึ่ง story ไหนที่เป็นฐานในการทำ Story ถัดไปควรจะมาก่อน Story ที่ต้องต่อยอดจาก story นั้นๆ รวมไปถึง Feature ที่มีโอกาสเปลี่ยนแปลงสูงก็ควรจะอยู่หลังๆ ด้วย (เผื่อลูกค้าเปลี่ยนใจจะได้เสียหายน้อยที่สุด)
  4. แต่ละ Story Product Owner จะต้องเขียน Exit Criteria เพื่อสรุปว่าจากหน้าจอของผู้ใช้ที่เกี่ยวข้องกับ story นี้ เช่น คลิกปุ่มที่หนึ่งจะต้องไปหน้าไหน search ชื่อได้, search topic ได้, ถ้าไม่พิมพ์เลยต้องแสดง error เป็นต้น ทั้งหมดนี้แยกมาเป็นข้อๆ ซึ่งสำหรับโปรแกรมเมอร์แล้วจะเหมือนได้ Test Case มาโดยอัตโนมัติเอาไปทำ TDD ต่อได้ง่ายขึ้นมากเลยทีเดียว (มีคนคิดมาให้แล้วนั่นเอง) แต่ถ้า story ไหนยังไม่แน่นอน เผื่อเปลี่ยนทีหลังก็ยังไม่ต้องเขียน Exit Criteria (ในที่นี่สมมติว่า Product Owner คือ Tester ในคนเดียวกันนะครับ)
  5. นำ Story Card ที่พร้อมแล้วมาวางเรียงบนโต๊ะ ประชุมร่วมกับทีม Programmer ว่าแต่ละหัวข้อควรจะให้คะแนนความยาก (Story Point) เท่าไหร่ดี โดยมีคะแนนตั้งแต่ 1,2,3,5,8,13,… เป็น Fibbonanci ซึ่งทุกคนจะโหวตแต่ละ Card พร้อมกันว่าได้เท่าไหร่ โดยอาศัยการเปรียบเทียบกันเองระหว่าง story ที่วางอยู่ด้วยกัน ซึ่งจะทำได้ง่ายกว่าประมาณด้วยเวลามาก (แต่ละคนไม่มีทางประมาณเวลาที่ใช้ทำออกมาได้ตรงกันหรอก จริงไหม? แต่ถ้าเป็นการเทียบความยากกันเอง จะได้ข้อสรุปง่ายกว่ามาก) แล้วมาดูกันว่าคะแนนต่างกันมากไหม หากแต่ละคนให้คะแนนต่างกันมากก็ต้องคุยกันว่าทำไมจึงให้แบบนั้น (เป็นสัญญาณว่าเกิดความเข้าใจไม่ตรงกันของคนในทีม รีบทำความเข้าใจให้ตรงกันซะ!) แล้วโหวตใหม่ จนกว่าจะได้คะแนนเท่ากันหมด ขั้นตอนนี้เรียกว่า Planning Poker ครับ ตรงนี้ Story Point ไม่ใช่เวลาที่จะทำเสร็จนะครับ มันคือค่าความยาก(หรือความเสี่ยง) ของงานแต่ละอย่าง ยิ่งเลขมาก จะยิ่งยากขึ้นมากตาม ซึ่งถ้าเลขเยอะมากๆ ควรจะแตก Story ออกให้เล็กลงเป็น Card 2 ใบครับ และแน่นอนว่าควรแตกเฉพาะอันที่ Requirement ไม่เปลี่ยนแน่ๆ แล้ว
  6. นำ Story Point ของ Card ทั้งหมดมาบวกรวมกันก็จะได้ค่าความยากของ Project นี้ ทีนี้ละครับเราก็จะได้ Estimate ของเวลาการทำงานออกมาแล้ว โดยเทียบกับ project เก่าๆ เอาเช่น project a มี story point 30, project b มี story point 50 project b น่าจะใช้เวลาทำนานกว่าแน่ๆ และจากค่าเฉลี่ยของการทำงานที่ผ่านมา ทีมของเราทำงานได้ 5 point ต่อ 1 สัปดาห์ ดังนั้นน่าจะใช้เวลาใน project b ทั้งสิ้น 10 สัปดาห์ (ต้องไม่ลืมว่าทั้งหมดนี้คือการเดาครับ 55 แต่เป็นการเดาแบบมีหลักการมากขึ้น) ซึ่งเวลานี้ต้องไม่ลืมว่ามันคือ Speed ของทีมที่ทำทีมเดียว ไม่สามารถสรุปได้ว่าอีกทีมเข้ามาทำจะใช้เวลาในการทำเท่ากัน
  7. เริ่มแบ่งงานออกเป็นรอบๆ ซึ่งถ้าเป็น Scrum จะเรียกว่า Sprint ส่วนใหญ่จะอยู่ที่ 1-2 อาทิตย์ต่อ Sprint ถ้าเป็น Agile Practice อื่นก็จะแตกต่างกันไปว่าจะแบ่งรอบการทำงานเป็นอย่างไร โดย Story ที่ลูกค้ายังเอาแน่กับชีวิตไม่ได้ เราก็ทิ้งไว้ก่อนถูกไหมครับ(แต่เราขึ้น Story ไว้แล้ว ให้คะแนนเยอะเวอร์ๆ ไปก่อน) ซึ่งเราจะแตก Story ที่มี Story Point เยอะๆ ในงานรอบแรกๆ ก่อน ยังไม่ต้องทำทุก Story เพราะ เดี๋ยว Story หลังๆ ทำไปเดี๋ยวมันก็เปลี่ยน จะทำค่อยแตก Story ทีเดียวดีกว่า
  8. ทีม Programmer ลงมือทำตาม Story Card โดยใครอยากหยิบอันไหนใน Sprint นั้นๆ มาทำก่อนก็ตามใจ หรือจะคุยกันเองว่าให้ Senior ทำอันยาก Junior ทำอันง่ายก็ว่ากันไป ย้าย Card จากช่อง Backlog ไปช่อง Doing พอทำเสร็จก็ย้าย Card จากช่อง Doing ไป Done เป็นต้น
  9. สำคัญมากคือต้องคุยกันในทีมว่าก่อนจะย้ายเข้า Done นั้นคือต้องทำ อะไรเสร็จแล้ว (Definition of Done) เช่น ต้อง Test เสร็จก่อนถึงจะย้ายเข้า Done ถ้ายังไม่ Test ถือว่างานยังไม่เสร็จ ห้ามย้ายเข้า Done เด็ดขาด เป็นต้น
  10. เมื่อทำจบหนึ่ง Sprint ก็มาลองวิเคราะห์กันดูในทีมว่าทำได้ตามเป้าไหม เกิด Bug ที่ไม่คาดคิดหรือไม่ แล้วจะ Weight อย่างไรระหว่าง Bug ที่เกิดกับงาน Story ในรอบถัดไปที่จ่อคิวอยู่ ตรงนี้ขึ้นกับการตัดสินใจของทีมแล้วครับ ถ้าเกิด Bug นั้นต้องแก้แน่ๆ และสำคัญมาก ทำให้ต้องเลื่อนเวลาการทำงานออกไป ทีมปั่นกันไม่ไหวแน่ๆ ก็ต้องบอกลูกค้าแต่เนิ่นๆ แต่ประชุมหาทางแก้ไขกับลูกค้าเจรจาขอตัด feature หรืออะไรก็ว่าไป ไม่ใช่วันสุดท้ายพึ่งมาบอก แบบนี้ลูกค้าจะเครียดได้ครับ 55
  11. วนทำข้อ 8 ไปเรื่อยๆ จนงานเสร็จครับ

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

แถมท้ายเว็บดีๆ ที่ช่วยในการทำ Story Card ได้อย่างดีเยี่ยมครับ

http://www.trello.com

Enjoy this article?

Consider subscribing to our RSS feed!

ไม่มีความเห็น

ยังไม่มีความเห็น

ใส่ความเห็น

RSS feed for comments on this post

 เราชนะรอบ 4 | ยืมเงิน 3000 ด่วน | แอพกู้เงิน | แอพเงินด่วน | สินเชื่อออนไลน์อนุมัติทันที | Site Map | กู้เงินก้อน | กระเป๋าตัง | thisshop และ ยืมเงินฉุกเฉิน 5000 ด่วน