วันอาทิตย์ที่ 8 กุมภาพันธ์ พ.ศ. 2558

agile - แนวความคิดใหม่ในการพัฒนา Software - aciTH - Blog


Home‎ > ‎

agile - แนวความคิดใหม่ในการพัฒนา Software

Agile คืออะไร
เป็นหลักการในการพัฒนา software แบบใหม่ที่เน้น...
  • Rapid and flexible response to change
  • ทำให้การพัฒนาว่องไว
  • มีการทำเรื่อยๆไม่ต้องหยุด แม้มีอะไรมากระทบก็ไม่เป็นไร
  • เมื่อมีการเปลี่ยนแปลง เราสามารถรองรับความเปลี่ยนแปลงนั้นได้อย่างรวดเร็ว ไม่ตายตัว

วัตถุประสงค์ของ Agile

  1. เน้นว่าใครถนัดอะไร และการพูดคุยสื่อสารกัน มากกว่า การยึดติดที่เครื่องมือและกระบวนการ เช่นเปลี่ยนให้โปรแกรมเมอร์ไปคุยกับลูกค้าแทน ลูกค้าบอกอะไรมาก็ทำตามนั้นได้เลย
  2. ให้ทำงานโดยยึดที่ผลผลิตหรือ software เป็นหลัก เช่น เดิมเน้นเอกสารแต่ Agile ไม่สนมากนัก แต่สนทีี่ว่าเรามี sw หรือของส่งให้ลูกค้าหรือยัง
  3. ให้ความสำคัญเรื่องของการติดต่อสื่อสาร เช่น เดิมมีสัญญาหรือ contact กันแต่ Agile ไม่สนใจ ให้มองที่ความสัมพันธ์ระหว่างผู้พัฒนาและลูกค้า
  4. ยอมรับความเปลี่ยนแปลง เช่น เดิมต้องวางแผนให้ครบเป็นอย่างดี และทำตามแผน(gantt chart) ให้ได้ แต่ Agile ไม่ต้องทำตามแผนแต่เน้นการสนองความเปลี่ยนแปลงที่เกิดขึ้นได้

หลักการ Agile

  • เน้นความพอใจให้ลูกค้า ลูกค้าชอบ มีการส่งมอบ software อย่างต่อเนื่อง
  • ยอมรับ requirement ที่เปลี่ยนแปลง
  • มีการส่งมอบงานบ่อยๆ (ทุกๆ 2 สัปดาห์)
  • ลูกค้าและผู้พัฒนา้ต้องทำงานร่วมกัน (โปรแกรมเมอร์ไปทำงานที่ site ลูกค้า) ต้องเจอกันทุกวันจนโปรเจคเสร็จ
  • การทำงานต้องปล่อยให้ทีมงานมีอำนวจการตัดสินใจเองได้ ปล่อยให้เค้าทำงาน ไว้ใจกันและทีมงานก็ต้องมีความรับผิดชอบระดับนึง
  • การติดต่อกัน ต้องคุยซึ่งๆหน้า ห้ามอีเมลล์หรือโทร
  • วัดความก้าวหน้าของงาน(KPI) ที่ software
  • กระบวนการทำงาน ให้ทำไปเรื่อยๆ อย่าหวือหวา ค่อยๆทำ ส่งงานทีละนิด ช่วยทำให้คุณภาพชีวิตของผู้พัฒนาดีขึ้น
  • ผู้พัฒนา สปอนเซอร์ ลูกค้า ต้องมีการทำไปเรื่อยๆ คงที่ ไม่เร็วเกินหรือช้าเกิน
  • ทีมงานต้องให้ความสนใจกับเทคนิคต่างๆ มีการแชร์กัน
  • เน้นความง่าย ออกแบบง่ายๆ พื้นๆ ไม่ซับซ้อน ทำให้ดูแลแก้ไขง่ายเมื่อพบความเปลี่ยนแปลง
  • ทีมมีความรับผิดชอบในกระบวนการของตัวเอง
  • มีการนัดพบแลกเปลี่ยนกันสม่ำเสมอ

โมเดลของ Agile (AM : Agile Modeling)

  • เลือกบางหลักการมาทำ
  • เป็นวิธีนึงที่จะเอาหลักการของ Agile มาจัดการกับเอกสารและระบบเดิมที่มีอยู่ได้
  • ใน Agile ประกอบด้วย
    1. value ผลลัพธ์
    2. principle หลักการ
    3. practices วิธีปฏิบัติ
  • ทั้งสามอย่างนี้เป็นส่วนหนึ่งในโมเดล Agile ที่สามารถนำมาพัฒนา Software ให้มีประสิทธิภาพ และเกิด overhead น้อย
  • ให้มอง Agile เป็นส่วนขยายของกระบวนการพัฒนา Software แบบเดิมได้
    • ให้ Agile เข้าไปกำกับ ดูว่าของเดิมที่มีอยู่อันไหนสำคัญก็ทำ ไม่สำคัญก็ละ
    • นำ Agile มาจัดลำดับความสำคัญ ดูว่ากิจกรรมไหน ควรทำ ไม่ควรทำ

amEnhance.png

 Value (ผลลัพธ์)

  • เน้นติดต่อสื่อสาร
  • เน้นความง่าย ไม่ซับซ้อน
  • เน้น feedback จากลูกค้า
  • เน้นความกลัาตัดสินใจ
  • เน้นความเคารพกันและกัน

Core Principle (หลักการ)

  • ง่าย ไม่เวอร์เกิน
  • รับ requirement พร้อมเปลี่ยนแปลงได้ตลอดเวลา
  • เ้น้นปัจจุบีนเป็นหลัก
  • ทำ model ตามความจำเป็นเท่านั้น
  • พยายามใช้ multiple model มองหลายๆมุมมอง
  • มีการตอบกลับเร็ว
  • SW ถือเป็นจุดมุ่งหมายหลัก
  • ให้แบกสัมภาระเบาๆ
  • Supplement Principle
    • เ้น้น content มากกว่า representation(ที่ใช้ UML เขียน) ไม่เน้นเครื่องมือ เน้นที่เน้อหาข้างใน
    • ติดต่อกันอย่างเปิดเผย และตรงไปตรงมา

Core Practice (แนวทางปฏิบัติ /ลงมือทำ)

  1. จัดประชุม รวบรวม Active stakeholder เท่านั้น บางมีอาจมี None stakeholder เข้ามาฟังได้ แต่ห้ามออกความคิดเห็น ห้ามถาม ห้ามติดต่อ ห้ามแสดงไอเดีย
  2. นำ Artifact มาใช้ให้ถูกต้อง
    • Note : Artifact คือชิ้นส่วนของงานที่เราทำระหว่างการพัฒนาระบบเช่น อีเมลล์, source code,จดหมาย,ใบเชิญประชุม ถ้า Artifact ใดถูกเลือกมาใช้ในการทำงาน เรียกว่า "work products" และถ้า work products นี้ ถูกส่งมอบให้ลูกค้า้เรียกว่า "Deliverable"
  3. พยายามเป็นเจ้าของงาน สามารถทำงานแทนกันและกันได้
  4. พยายามใช้โมเดลแบบคู่ขนาน จะได้มองต่างมุม เพื่อเก็บรายละเอียดของระบบให้ครบ
  5. ทำให้เนื้อหาง่าย
  6. พยายามวาดรูปไม่ให้ซับซ้อน
  7. พยายามให้โมเดลเข้าถึงได้ทุกคน
  8. สามารถเปลี่ยน Artifact นึงไปอีกอันได้
  9. ใช้โมเดลแบบเล็กก่อนค่อยขยาย
  10. พยายามให้ผู้อื่นมีส่วนร่วมในการทำโมเดล
  11. พิสูจน์ด้วยการลองเขียน code ดู (จาก code เริ่มต้นตั้งแต่แรก)
  12. ใช้เครื่องมือง่ายๆในการทำงาน เช่น กระดาษ,กระดานดำ
  • Supplement Practices
    • ทำให้เป็นาตรฐาน
    • ค่อยๆ สร้างให้มีรูปแบบ เมื่อถึงเวลาค่อยใช้
    • โมเดลไม่ใช้ ให้โยนทิ้งไปเลย เพราะจะได้ไม่เสียเวลามาดูแล
    • เน้น contract (สัญญาระหล่างระบบที่สัมพันธ์กันอยู่) พยายามจัด contract ให้เป็นทางการ เช่น web service มี signature อะไรบ้างใน function call
    • การ update code เฉพาะตอนที่มีปัญหา

เทคนิคการพัฒนาแบบ Agile

  • Agile model driven development (AMDD)
  • Code Refactor : เป็นการ redesign code คือให้แก้ code เดี๋ยวนั้นแ้ล้ว design เปลี่ยนเอง
  • Pair Programming : จับทีมทำงานเป็นคู่ 2 คนทำงานร่วมกัน ทำที่เดียวกัน ให้เครื่องเดียว 2 คน,แชร์กันใช้,คนนึงทำ-คนนึงดู(มีการตรวจสอบกันไปด้วย)
  • Test Driven Development(TDD) : เป็๋นเทคนิคในการเขียน test case เขียน test case ก่อนและค่อยทำการ implement code

รูปแบบวิธีการที่ทำเอา Agile มาใช้

  1. Agile UP
  2. XP (eXtream Programming)
  3. FDD (Feature Driven Development)
  4. Scrum

Extreme Programming - aciTH - Blog


Home‎ > ‎

Extreme Programming

Extreme Programming
    เมื่อมีปัญหา ก็ต้องมีคนพยายามหาทางแก้ ในรอบสิบปีที่ผ่านมา มีหลักในการพัฒนา Software เกิดขึ้นใหม่มากมาย วันนี้เราจะมาพูดกันถึง Extreme Programming ซึ่งถ้าพูดไปแล้ว มันเป็นหลักที่มีสีสรรที่สุด ทำไมถึงเป็นอย่างนั้น เราค่อยๆ มาดูกัน ก่อนอื่นเรามารู้จักที่มากันก่อน

ที่มา
    Extreme Programming เป็นผลงานของ Programmer กลุ่มหนึ่ง มันผิดกับ Methodology ตัวอื่นๆ ที่ส่วนมากสร้างโดยนักวิจัย ถ้าผมจะเปรียบเทียบ ผมว่ามันน่าจะเปรียบได้กับ ระบบเถ้าแก่ vs MBA  
    Extreme Programming (XP)มันลูกทุ่งดี เหมือนกันการลองผิดลองถูกแบบเถ้าแก่ ซึ่งการทำงานเน้นคล่องตัว ผิดกับ MBA ซึ่งเน้นหนักไปทางทฤษฏี XP พยายามล้มความคิดของการที่ต้องทำเอกสารมากมาย มาทำเฉพาะที่จำเป็น ซึ่งตรงกันข้ามกับแบบอื่นที่พยายามที่ต้องบันทึกทุกอย่างที่ทำเพื่อใช้ในการ Audit แต่มันก็เป็นดาบสองคมครับ เพราะจุดนี้เป็นจุดที่สร้างความไม่น่าเชื่อถือให้กับ XP มาก แต่นั่นแหละครับ XP เกิดจาก Programmer ธรรมชาติของ Programmer ก็ไม่ค่อยชอบทำ Document อยู่แล้ว แต่ก่อนที่จะสรุปว่าดีหรือไม่นั้น ค่อยๆ พิจารณากันก่อนครับ คุณอาจจะชอบลูกทุ่งแบบนี้ก็ได้
    XP เริ่มจริงๆ จาก Programmer 2 คนคือ Kent Beck และ Ward Cunningham ในต้นยุค 90 ทำงานอยู่ที่ Tektronics เขียนโปรแกรมโดยใช้ภาษา SmallTalk จากประสบการณ์ก่อนหน้าที่พบปัญหาจาก Waterfall มาก่อน ทั้ง 2 จึงค่อยๆ ปรับปรุงวิธีการต่างๆ จนสุดท้ายมาเป็น XP ที่เราเห็นกันทุกวันนี้ ทีมของ Tektronics ทุกวันนี้ มีชื่อโด่งดังกันหลายคน โดยเฉพาะ Erich Gamma ผู้เป็นหนึ่งในผู้ที่คิดค้น Design Patterns กับ Eclipse และ Martin Fowler ผู้โด่งดังจากการเขียนหนังสือหลายเล่ม กลุ่มนี้ถือได้ว่าเป็นปรมาจารย์ด้าน OOP ในยุคแรก
Embrace Changes
    แนวคิดของ XP และแนวคิดทางวิศวกรรม นั้นต่างกันที่สุดก็ตรงนี้ครับ แนวคิดทางวิศวกรรมพยายามที่ทำให้มั่นใจได้ว่า ทุกอย่างต้องถูกต้อง เช่นการสร้างตึกต้องมีการคำนวณโดยละเอียด สร้างแล้วไม่ถล่มลงมาเอง ทุกอย่างพลาดไม่ได้ เพราะอะไรผิดแล้วกลับมาแก้ใหม่ได้ยาก ดังนั้นจึงเน้นไปที่ขั้นตอนการวางแผน แต่พอนำมาประยุกต์กับงานเขียนโปรแกรมจึงกลายเป็น Waterfall ไป เพราะธรรมชาติของการเขียนโปรแกรมนั้นไม่เหมือนกับการสร้างตึกครับ เราไม่มีทางที่จะเค้นเอาความต้องการของผู้ใช้ออกมาได้ 100% ประกอบกับ เมื่อเวลาผ่านไปการเปลี่ยนแปลงต้องมีครับ เนื่องจาก Business Rules มีการปรับปรุงตลอดเวลา เอาง่ายๆ ที่มักนิยมกัน ก็คือเรื่องภาษี ที่มีการเปลี่ยนแปลงอยู่เสมอ ถ้าอ่านหนังสือที่คนเขียนเป็นอเมริกัน ตัวอย่างนี้จะถูกหยิบยกมาพูดถึงเสมอ เพราะคนอเมริกันคิดว่า ภาษีเป็น 1 ใน 4 อย่างของชีวิตที่หลีกไม่พ้นครับ
    XP มาแนวพุทธครับ ใดๆ ในโลกล้วนอนิจจัง ดังนั้น เราต้อง Embrace Changes คือยอมรับความเปลี่ยนแปลงอย่างหน้าชื่นตาบาน จงอย่าได้คิดเราสามารถทำให้เสร็จในทีเดียว มันต้องมีทีที่ 2 ที่ 3 ต่อไปเรื่อยๆ ตราบใดที่ชีวิตยังไม่สิ้น ความเปลี่ยนแปลงย่อมเปลี่ยนแปลงตลอด ดังนั้น เราไม่ควรมองความเปลี่ยนแปลงเป็นวิกฤต แต่หากมันเป็นโอกาสต่างหาก (ว่าเข้าไปนั่น)
    XP รองรับความเปลี่ยนแปลงอย่างไร เราค่อยๆ มาดูกัน
XP Life Cycle
    การเขียนโปรแกรมตั้งแต่ต้นจนจบในทีเดียวนั้น ผมแสดงให้เห็นจากข้างบนแล้วว่า มีผลร้ายมากกว่าดี เมื่อ Waterfall รอบแรกเสร็จ ผมเชื่อว่าเราเองก็ไม่อยากจะแก้ แต่มันเลี่ยงไม่พ้นครับ ในมุมมองของผู้ใช้ ก็คิดว่า ทำไมโปรแกรมมันห่วยจังไม่ตรงกับความต้องการเลย ส่วนในมุมมองของโปรแกรมเมอร์ ก็คิดว่า ถ้าอยากได้แบบนี้ทำไมไม่บอกตั้งแต่แรก เหตุการณ์มันจะเลวร้ายลงเมื่อ Waterfall รอบต่อๆ มา โปรแกรมเมอร์พาลคิดไปว่า ตัวเองมีกรรมจริงๆ ไปเจอผู้ใช้ที่แย่ที่สุดในโลก
    เท่านั้นยังไม่พอ ถ้าใครเคยเขียนโปรแกรมมาเยอะๆ จะรู้ว่า การแก้โปรแกรมมันยุ่งยากมาก มันจะกระทบไปเป็นลูกโซ่ แก้หนึ่งที่ กระเทือนไปหลายโปรแกรม แก้ยากกว่าเขียนครับ เชื่อรึเปล่ากับ Version ที่ผู้ใช้ยอมจ่ายตัง กับ Version แรกที่ส่งมอบ มักจะต่างกันแบบหน้ามือเป็นหลังมือ เรื่องนี้เป็นเรื่องธรรมดามากครับ
    เท่านั้นยังไม่พอ (อีกที) ถ้าเป็นบริษัทที่ดีหน่อย เมื่อทำโครงการจนเสร็จ เขาก็ไม่สามารถทิ้งได้เลย ต้องตาม Maintenance จะทำอย่างไรได้ครับ เขาต้องทิ้งคนไว้อย่างน้อย 2 คน เพื่อดูแลระบบ เวลาผ่านไป จำนวนคนจะบวมขึ้นไปเรื่อยๆ
    เท่านั้นยังไม่พอ (ทีที่ 2) มันเกิดปัญหาเรื่องการแบ่งงานครับ คนโน้นทำเยอะ คนนี้ทำน้อย ไม่ว่าคุณจะแบ่งอย่างไร มันก็ไม่มีทางยุติธรรมครับ ดูเหมือนว่าจะยุติธรรมในตอนแรก แต่พอทิ้งเวลาไป บางระบบที่ว่ายาก กลับง่าย หรือตรงกันข้าม เวลาทีมไหนหนัก ทีมที่เหลือก็ช่วยไม่ได้ คนที่ทำงานหนักเกินไปก็จะน้อยใจ ชิงตัดช่องน้อยแต่พอตัว ที่เหลือก็จะเป็นขยะก้อนใหญ่มีเหลือเอาไว้ให้คนที่ยังอยู่ครับ
    XP เห็นปัญหาเหล่านี้ จึงออกแบบวิธีการพัฒนาโปรแกรมเสียใหม่ โดยที่พยายามเริ่มเขียนโปรแกรมให้เร็วที่สุด แต่ก็ไม่ใช่เร็วแบบไม่มีสาระนะครับ XP บอกว่า จะทำการ Survey เบื้องต้นก่อน อาจจะใช้เวลาเพียง 2 อาทิตย์ แล้วเริ่มเขียนโปรแกรมเลย แต่โปรแกรมที่เขียนนั้น ไม่ได้ครบถ้วน เขียนเพียงคร่าวๆ เช่นจำนวน Field มีเพียง 4-5 fields ก็พอ (ถ้าเต็มรูปอาจมีถึง 50-60 fields) ตั้งใจไว้ว่า ใช้เวลา 2-6 อาทิตย์เท่านั้น จะส่งมอบได้ แต่ไม่ใช่ว่าเสร็จเพียงโปรแกรมเดียวแล้วส่งนะครับ โปรแกรมจะต้องไหลตั้งแต่ต้นจนจบ ถ้าทำระบบคลังสินค้า ก็ต้องมีโปรแกรมตั้งแต่การรับเข้า ไปจนกระทั่งปิดบัญชีไปเลย โปรแกรมต้องไหลตั้งแต่ต้นจนจบเสมอครับ
    จากนั้นก็ส่งมอบโปรแกรม แน่นอนครับ โปรแกรมมันยังไม่สมบูรณ์ แต่ก็พอมองเห็นภาพคร่าวๆ ซึ่งธรรมชาติแล้ว จะต้องถูกผู้ใช้ Comment กันเพลินครับ ไม่เป็นไร อย่าทิ้ง Comment ของ User ไปเสียเปล่าๆ ครับ XP กำหนดให้มีกระดาษแข็งขนาดเท่ากับบัตรรายการที่ใช้ในห้องสมุด ให้ผู้ใช้เขียนเอาเลยครับ ว่าอยากให้ปรับปรุงโปรแกรมอย่างไรบ้าง 1 เรื่องต่อหนึ่งใบครับ ซึ่ง XP เรียกสิ่งนี้ว่า User Story
    เมื่อประชุมเสร็จ ยังไม่ต้องรีบกลับไปเขียนโปรแกรม ประชุมกันก่อนครับ เอา User Story แต่ละใบมาวิเคราะห์ดู ถ้าต้องการทำให้ได้ความสามารถตามใบที่กำหนด ต้องใช้เวลาเท่าไร ระบุเวลาลงไปในทุกใบครับ จากนั้นก็เอาไปให้ผู้ใช้เลือก เมื่อผู้ใช้เลือกแล้ว เราก็พัฒนาโปรแกรมตามนั้นเลยครับ
    นั่นคือ 1 รอบของวงจรชีวิตแบบ XP  ในการทำงานจริงๆ จำนวนรอบไม่แน่นอนครับ แต่ยังไรก็ตาม แต่ละรอบ ก็จะมีหน้าตาแบบนี้ครับ คือทำงานตาม User Story ที่กำหนด เสร็จแล้วส่งมอบให้ผู้ใช้เลือก User Story อีก จริงๆ แล้วผู้ใช้มีสิทธิเขียน User Story ได้ทุกเวลาครับ
Small Release
    เรามาวิเคราะห์วงจรนี้กัน จะเห็นได้ว่า วงจรนี้เป็นการพัฒนาโปรแกรมแบบก้นหอย ไม่ใช่แบบน้ำตก พัฒนาแบบเพิ่มเติมทีละนิด หรือที่เรียกว่า Continuous Integrate ผมขอเรียกว่าแบบก้นหอยก็แล้วกัน เมื่อพบปัญหาว่าเราหลงทาง ก็พร้อมที่จะรื้อทิ้งได้เลยในรอบแรกๆ ซึ่งเราจะไม่ต้องเสียดายอะไรมากนัก ผิดกับ Waterfall หลังจากรอบแรกออกไปแล้วหลงทาง โปรแกรมเมอร์แทบกระอักเลือดครับ
    วิธีแบบก้นหอยแบบนี้  Methodology สมัยใหม่ทุกตัวใช้ครับ ไม่มี Methodology ใหม่ๆ ตัวใดเลยที่มีแนวคิดแบบ Waterfall ถนนทุกสายมุ่งมาทางนี้หมดครับ
    การนำเอาโปรแกรมให้ผู้ใช้ได้เห็น (ถึงแม้ว่าโปรแกรมยังไม่สมบูรณ์ก็ตาม) มีข้อดีหลายข้อครับ ข้อแรกคือผู้ใช้จะเห็นว่าเราคิดอย่างไร เราแปลงเอาความคิดของเขา มาเป็น Model ทางคอมพิวเตอร์อย่างไร ถ้าผิดไปเลย ก็ไม่มีปัญหาครับ โปรแกรมเมอร์น้อมรับกลับไปรื้อทิ้ง แล้วกลับมาพร้อมกับ Model ที่ถูกต้องใกล้เคียงความเป็นจริงขึ้นในรอบต่อๆ ไป วิธีนี้เป็นวิธีที่ดีที่ทำให้ผู้ใช้เปิดปากบอกความต้องการครับ ถ้าเขาไม่เห็นอะไรเลย ก็จะนึกภาพไม่ออก  ก็เลยไม่รู้ว่าจะบอกอะไรเราดี เขาจะต้องพูดทำนองว่า ไปทำมาได้ดูก่อน  แต่ถ้าเขาเห็นโปรแกรม เขาจะ Comment ได้สบายเลยครับ
    แต่คำว่า Small Release นี่เป็นคนละเรื่องกับ Prototype นะครับ Prototype มันเป็นเพียงต้นแบบ อาจจะมีเพียงหน้าจอให้ผู้ใช้ดู ให้เห็นภาพรวมว่า โปรแกรมจะออกมามีลักษณะหน้าตาอย่างไร แต่มันเป็นการจำลองเหตุการณ์ในอนาคต ทำงานไม่ได้จริง ผิดกับก้นหอยแบบนี้นะครับ โปรแกรมทำงานได้จริงๆ เพียงแค่ไม่ครบถ้วน ถ้าเป็นงานทางธุรกิจ เราสามารถทดลองโปรแกรมจนออกรายงานตัวสุดท้ายได้ เพียงแต่ว่าข้อมูลที่แสดงมันอาจจะดูด้วนๆ เท่านั้น
    ถ้านึกเปรียบเทียบกับ Waterfall เราจะเห็นได้ว่า ก้นหอยรอบแรก ก็เทียบได้กับการส่งมอบโปรแกรมครั้งแรกของ Waterfall เหมือนกัน แต่แตกต่างกันตรงที่  Waterfall ผู้ใช้ตั้งความหวังไว้มาก (แล้วผิดหวังในที่สุด) ผิดกับก้นหอยรอบแรก ซึ่งผู้ใช้ก็ไม่ได้คาดหวังอะไรไว้มาก ดังนั้น ความผิดหวังซึ่งส่งผลกระทบกับมายังตัวโปรแกรมเมอร์จึงรุนแรงต่างกัน ถ้าเรามองมุมของโปรแกรมเมอร์ ก็ได้ความรู้สึกที่แตกต่างเช่นเดียวกัน ถ้าเป็น Waterfall โปรแกรมเมอร์ต้องพยายามสุดฤทธิ์ที่จะเลี่ยงการแก้ เพราะรู้ว่า ถ้าแก้แล้ว ส่งผลกระทบไปสู่โปรแกรมอื่น อีกหลายตัว จนเราได้ยินอมตะวาจาของโปรแกรมเมอร์ที่ว่า "เขียนใหม่ง่ายกว่าแก้" อยู่เสมอๆ แต่สำหรับแบบก้นหอยแล้ว เราเพิ่งลงทุนลงแรงไปนิดเดียว รื้อทิ้งไม่ใช่เป็นเรื่องที่ต้องทำใจอะไรมากนัก ส่วนรอบต่อๆ ไป โอกาสที่จะถูกรื้อมีน้อยลงเรื่อยๆ ตามจำนวนรอบ เนื่องจากผู้ใช้เป็นผู้กำหนดหางเสือเสียเอง โอกาสที่ไม่ตรงตามความต้องการจึงมีน้อย ทั้งหมดนี้ส่งผลให้สุขภาพจิตของโปรแกรมเมอร์และผู้ใช้ดีขึ้น จะได้ยิ้มเข้าหากันได้อย่างสนิทใจ
    เรื่องก้นหอยนี้ ไม่ใช่เป็นเรื่องใหม่ในโลกของคอมพิวเตอร์นะครับ ถ้าใครเคยเขียนเรียนเรื่อง Heuristics ก็ขอให้รู้ว่ามันก็คือเรื่องเดียวกัน แนวคิดของเรื่อง Heuristics เป็นแนวคิดของการไต่เขาครับ เคยมีคนสงสัยว่า มันไต่ได้อย่างไร เรื่องนี้ผมเองก็ไม่เคยปีนเขาจริงๆ กับเขา ก็เอาเป็นว่าฟังคนอื่นแล้วมาเล่าต่อ ผิดถูกก็อย่าต่อว่ากันนะครับ
    ลองนึกภาพดูนะครับ ถ้าคุณต้องการปีนภูเขาที่มีหิมะขาวโพลน ทัศนวิสัยแย่มาก เพราะหิมะกำลังตกหนัก แทบมองไม่เห็นอะไรเลย เป็นคุณ คุณจะทำอย่างไร เครื่องมือพื้นฐานที่คุณมีก็คือ เข็มทิศ และเครื่องมือวัดความสูง (Altimeter) จากนั้นคุณก็เดินไปสักช่วงเวลาหนึ่ง เช่น 5 นาที จากนั้นคุณต้องเอาเครื่องมือทั้ง 2 มาตรวจดูว่ายังถูกอยู่หรือไม่ บางที คุณอาจจะเดินขึ้น แต่เดินขึ้นแบบเฉียงๆ นอกจากทำให้ช้าแล้ว ยังต้องย้อนเดินชดเชยอีก ถ้าคุณเดินแล้วนับก้าว คุณจะได้ระยะทางคร่าวๆ เมื่อคำนวณร่วมกับเข็มทิศและเครื่องมือวัดความสูง คุณจะรู้ได้ทันทีว่ายังตรงเป้าหรือไม่ หรือเอียงซ้ายขวาไปเท่าไร รอบต่อไปจะได้ปรับทิศทางได้ถูก จะเห็นว่าการทำงานนั้นเป็นรอบๆ เช่นเดียวกันกับวิธีก้นหอยข้างต้น
    วิธีนี้ก็เป็นวิธีเดียวกันกับวงจร PDCA (Plan Do Check Action) ที่โด่งดังมากจาก ระบบ ISO 9002:2000 และ TQM วงจรนี้เริ่มจากการวางแผนก่อน เมื่อวางแผนแล้ว ก็ลองทำดู พอทำแล้ว ก็ตรวจสอบว่ามันได้ตามแผนหรือไม่ แล้วถ้ามันดี ก็ทำเป็นกฎใช้งานเลย แต่ถ้าไม่ดี ก็เริ่มวงจรนี้ให้ ทำไปเรื่อยๆ ครับ เห็นได้ว่า มันก็เรื่องเดียวกันกับก้นหอยครับ ซึ่งมันเป็นวิธีที่ตะล่อมเข้าหาเส้นชัยครับ ซึ่งผิดกับ Waterfall คือเรามุ่งไปที่เส้นชัยเลย หลับหูหลับตามุ่งไป เช่น ถ้าคุณอยากไปเชียงใหม่ คุณรู้แล้วว่าต้องไปทิศนี้ คุณก็มุ่งไปเลย แผนที่ หรือป้ายข้างทางไม่มีไม่สน มุ่งอย่างเดียว สุดท้ายคุณอาจจะไปโผล่ที่นราธิวาสก็ได้
    การทำงานเป็นรอบยังมีจุดแข็งอีกอย่างครับ คือผู้ใช้และโปรแกรมเมอร์นี้ มีความสัมพันธ์ที่ดี ผู้ใช้จะเห็นความคืบหน้าตลอดเวลา ไม่ใช่หายหัวไป 1 ปี กลับมาจำหน้ากันไม่ได้แล้ว ความรู้สึกมันดีกว่ากันครับ ผมขอนอกเรื่องหน่อย ผมเคยเขียนโปรแกรมให้ลูกค้า มันต้องทำการคำนวณอะไรสักอย่าง ใช้เวลาประมาณ 1 นาที ผู้ใช้บ่นอุบเลยครับ ว่ารอนานมาก แต่พออีกโปรแกรม ผู้ใช้คนเดิม ผมมี Progress Bar แสดงความคืบหน้าเป็นระยะ โปรแกรมตัวนั้น 3 นาที แต่ผู้ใช้ไม่บ่นเลย คงเห็นนะครับว่าผมต้องการสื่ออะไร

ผู้ใช้เลือก User Story
    ถ้ามีคนถามคุณว่า ระหว่าง เครื่องคอมพิวเตอร์ Desktop กับ Note Book คุณอยากได้อะไร ผมเชื่อว่าเกือบทุกคนคงตอบว่า Note Book แต่ถ้าผมเปลี่ยนคำถามว่า Desktop ราคา 30,000 บาท กับ Notebook ราคา 90,000 บาท คุณจะเลือกอะไร ผมเชื่อว่าเสียงเริ่มแตก บางคนยังยืนยัน Note Book แต่บางคนเปลี่ยนใช้ไปซื้อ Desktop เงินมันทำให้คนรอบคอบขึ้นครับ
    แนวคิดแบบนี้เป็นวิธีเดียวกันที่ XP ใช้ เมื่อผู้ใช้เขียน User Story ระบายความในใจออกมาเต็มที่แล้ว โปรแกรมเมอร์ต้องกำหนดเวลาลงไปในแต่ละ User Story ผู้ใช้ต้องชั่งครับ ระหว่างของที่อยากได้ กับระยะเวลาที่จะได้ ในเมื่อผู้ใช้เป็นผู้ถือหางเสือเองครับว่าอยากได้อะไร ซึ่งมันเป็นสิ่งที่ดีสำหรับผู้ใช้ แต่ไม่ดีสำหรับโปรแกรมเมอร์ แต่นั่นแหละครับ มันถูกชดเชยไปกับระยะเวลาที่ระบุ ถ้าผู้ใช้เลือกอะไรยากๆ เขาจะรู้เลยว่าเขาต้องรอนาน แต่มันจะไม่มีการบ่นในใจเลยครับ
    คุณอาจจะแย้งผมว่า ไม่เห็นมีประโยชน์อะไรเลยที่ให้ผู้ใช้เลือก สุดท้ายเราชาวโปรแกรมเมอร์ก็ต้องทำตาม User Story ทุกใบอยู่แล้ว เรื่องนี้มีประเด็นครับ คือใบ User Story ที่ผู้ใช้เลือก แน่นอนครับ มันต้องเป็นใบที่สำคัญในสายตาของเขา ซึ่งถ้าเราทำได้ตามนั้น โดยมากมันจะส่งผลให้ผู้ใช้สามารถเริ่มใช้โปรแกรมได้ก่อนครับ คือไม่ต้องรอให้ระบบทั้งหมดเสร็จสิ้นก่อน พอมันถึงจุดที่ผู้ใช้พอใจ เขาจะเริ่มงานได้เลย ส่งผลให้โปรแกรมเริ่มใช้ได้เร็วขึ้นครับ ส่วน User Story ที่เหลือ ก็ไม่จำเป็นต้องรีบทำ หรืออาจจะไม่จำเป็นต้องทำเลยก็ได้ ต่อรองกับผู้ใช้ได้สบายครับ เราก็สามารถส่งมอบโปรแกรมได้เร็ว และในที่สุด ผู้ใช้จะพึงพอใจมากขึ้นมากครับ
Onsite Customer
    ถ้าอ่านมาถึงตรงนี้ คุณจะเห็นได้ว่าผมไม่ได้พูดถึงคำว่า System Analyst เลยครับ เพราะ XP ถือว่าคำนี้เป็นคำฟุ่มเฟือย ไม่ควรใช้ XP ไม่มีตำแหน่งนี้ครับ มีแต่คำว่า Developer ซึ่งในที่นี่ผมใช้คำว่าโปรแกรมเมอร์นั่นเอง XP ถือว่าโปรแกรมเมอร์ทุกคนเป็นผู้ออกแบบด้วย ไม่มีคนใดคนหนึ่งที่รับผิดชอบเรื่องการออกแบบโดยเฉพาะครับ ปัญหาก็คือว่า มันจะสมบูรณ์หรือ
    ตามประสบการณ์ของผม ผมมองตำแหน่ง SA ไม่ค่อยมีค่าครับ สิ่งที่ SA เก่งในสายตาผม ก็คือจิตวิทยาที่จะคุยกับผู้ใช้แล้วดึงข้อมูลออกมาให้ได้มากที่สุด เรื่องนี้สอนกันไม่ได้ ดังนั้น SA เราจึงเห็นผู้หญิงทำงานตำแหน่งนี้ไม่ใช่น้อย
    มาถึง XP สิ่งที่ XP ทำทดแทนความสามารถของ SA ก็คือ การดึงเอาผู้ใช้มาเป็น SA แทนเลย XP ใช้ User Story เป็นเครื่องมือดูดข้อมูลของผู้ใช้ ซึ่งต้องรวมไปถึงการที่ผู้ใช้เห็นโปรแกรมเป็นรอบๆ มันเป็นการกระตุ้นให้เข้ามากลมกลืนกับทีมโดยไม่รู้ตัว และ User Story นี่เองใช้แทนใบ Spec ที่ได้จาก SA ครับ
Pair Programming
    มาถึงปัญหาที่เจ้าของโครงการมักจะเจอ คือโปรแกรมเมอร์ลาออก จะทำอย่างไร สำหรับ XP แล้ว วิธีเบื้องต้นที่คนอื่นเห็นก็คือ การใช้ Pair Programming มันคืออะไร
    Pair Programming คือการที่ให้โปรแกรมเมอร์ 2 คนจับคู่กันเขียนโปรแกรม แต่ไม่ใช่จับคู่แบบธรรมดานะครับ XP บอกว่า จับคู่กันแล้ว ใช้จอเดียว เครื่องเดียว และ Keyboard เดียว นั่นหมายความว่า คนหนึ่งเขียน แต่อีกคนดูครับ
    งงดูไหมครับ ถ้าคิดตามคณิตศาสตร์อย่างง่าย ปริมาณผลงานมันอาจจะหาร 2 เลย แต่ทาง XP บอกว่า การทำอย่างนี้ นอกจากมันจะไม่ได้หาร 2 แล้ว มันอาจจะมากกว่าคูณ 2 เสียอีก ทำไมถึงเป็นเช่นนั้น
    XP บอกว่า 2 หัวดีกว่าหัวเดียว ถ้าใช้คนเดียวเขียน อาจจะคิดนาน ผลงานไม่ดี แต่ถ้าใช้ 2 คนเขียน ผลงานมันจะดีขึ้น เพราะมันจะหล่อหลอมมาจากความคิดของ 2 คน อะไรที่ยากกลับทำให้ง่ายลงเยอะ แถมการเขียนโปรแกรมยังเป็นระเบียบแบบแผนขึ้น มีการขัดเกลา Code ให้มันดูอ่านง่ายขึ้น
    แต่เรื่อง Pair Programming มันเป็นศาสตร์ที่ยากมากครับ คุณจะจับเอาโปรแกรมเมอร์ 2 คนที่ความรู้ต่างกันมาก ก็ไม่ประสบผลสำเร็จ  ถ้า Ego สูงกันทั้งคู่ ก็ไม่สำเร็จ เรื่องนี้ผมยอมรับครับว่า เป็นเรื่องที่ยากที่สุด เป็นสิ่งที่ผมลองทำดูแล้วไม่ประสบผลสำเร็จ สุดท้ายต้องยกเลิกไป เป็นตัวใครตัวมันเหมือนเดิม อาจจะเป็นเพราะผมยังบริหารมันไม่ดีพอก็ได้ ถ้าใครลองดูได้ผลเป็นอย่างไร ช่วยบอกด้วยครับ

Collective Ownership
    ที่ผมเกริ่นนำไปเรื่อง Pair Programming ส่วนมากจะเข้าใจว่า Pair Programming ออกแบบมาเพื่อลดปัญหาการลาออก มันก็ใช่ครับ แต่มันก็เป็นส่วนเล็กน้อยเท่านั้น เพราะถ้าลาออกไปทั้งคู่ โปรแกรมที่ทั้งสองดูแล ก็จะกลายเป็นสีดำ มืดๆ เหมือนเดิม
    ทางออกที่แหวกแนวของ XP ก็คือการใช้วิธีที่เรียกว่า Collective Ownership มันคืออะไร น่าสนใจ หลักการของมันก็คือ โปรแกรมแต่ละตัวจะไม่มีเจ้าของอย่างแท้จริง แต่ไม่ใช่ไม่มีเจ้าของนะครับ ใครทำ คนนั้นก็เป็นเจ้าของ
    ฟังดูแปลกไหมครับ หลักการของ XP ก็คือ พอผู้ใช้เลือก User Story แล้ว XP ใช้วิธีอาสาครับ ไปจับคู่ Pair Programming มา จะคู่กับใครก็ได้ในรอบนี้ แล้วเอา User Story ไปทำ จะเห็นได้ว่า คู่ก็เปลี่ยนไป โปรแกรมก็เปลี่ยนไป ดังนั้น แต่ละคนก็จะได้จับทุกส่วนของโปรแกรม ทำให้ถ้ามีใครลาออก ผลกระทบจะน้อยมาก และ XP ก็ไม่ได้ห้ามการถามข้าม Pair นะครับ ถามกันได้ตลอด
    การทำอย่างนี้ นั่นก็คือทุกๆ รอบที่ทำ ทุกคนจะเป็น SA ช่วยกันทั้งหมด หลายหัวดีกว่าหัวเดียวครับ และที่สำคัญก็คือ มันไม่ซ้ำซากครับ ถ้าเราใช้วิธี Waterfall เราต้องจับโปรแกรมใดโปรแกรมหนึ่งไปตลอด จนเบื่อกันไปข้างหนึ่ง แต่สำหรับ XP มันจะเปลี่ยนไปเรื่อยๆ ความรู้สึกท้าทายก็จะเข้ามา ไม่แปลกหรอกครับ ก็คนออกแบบหลักนี้เป็นโปรแกรมเมอร์ ก็ย่อมต้องเข้าใจหัวอกโปรแกรมเมอร์ด้วยกัน

Scrum เพื่อเสริม XP


 0


Photo

Scrum เพื่อเสริม XP

Posted by Bomber , 04 October 2007 · 5977 views
SCRUM

Scrum เป็นหนึ่งใน implementation หลายๆวิธีที่อยู่ในค่าย Agile Software Development ในเมืองไทยตอนนี้กระแส Agile เริ่มมาแรงมากขึ้นเรื่อยๆ หน่วยงาน หรือบริษัทต่างๆก็เริ่มประยุคต์ใช้กันมากขึ้น หรือไม่ก็มีแนวโน้มว่าอยากจะทดลองใช้ดู ซึ่งเป็นแนวโน้มที่ดีมาก เพราะ Agile เน้นที่การทำให้ทุกฝ่ายมีความสุข

ลูกค้ามีความสุข เพราะได้เห็นผลงาน ได้เห็นความคืบหน้าชัดเจน ได้เปลี่ยน requirement บ่อยๆอย่างที่อยากได้

คนทำงานก็มีความสุข เพราะทำงานไม่หนักเกินไป มี balance ของชีวิต เห็นอนาคตชัดเจนว่าวันนี้จะทำอะไร มีอะไรให้ทำหรือเปล่า แล้วอนาคตอันใกล้มีอะไรรออยู่

Project Manager ก็มีความสุขเพราะ track งานง่าย คุยกับลูกค้าได้ง่ายขึ้น ไม่ต้องมาปวดหัวกับความเอาแต่ใจของลูกค้ากับคนทำงาน ที่มักไม่ตรงกันอยู่เลย ลูกค้าอยากให้ทำแต่คนทำงานไม่อยากทำไม่เห็นจะ make sense เลย

พอใช้ Agile มันตอบโจทย์ทุกอย่าง มีความสุขกันทุกคน งานเสร็จ ทำงาน happy เงินก็ได้ project จบเร็วไม่ยืดเยื่อ

กลับมาที่เรื่อง Scrum ปกติแล้ว พอพูดถึง Agile มีแต่คนนึกถึง XP จนเดี๋ยวนี้คนทั่วไปคิดว่า Agile=XP ไปแล้ว ซึ่งจริงๆแล้วไม่ใช่ XP เป็นแค่น implement หนึ่งของ Agile เมื่อก่อนหน่วยงานผมเริ่มต้นก็ใช้ XP เช่นกัน แต่ XP เองก็มีข้อเสียหลายๆข้อที่ไม่ค่อยจะเหมาะกับลักษณะงานและสังคมของความเป็นไทย ปรับไปปรับมาหลังๆมันก็เลยกลายเป็น Scrum ไปแบบไม่รู้ตัว แล้ว Scrum มันต่างจาก XP อย่างไรล่ะ?

เวลาผมถามใครๆว่าถ้าพูดถึง XP จะนึกถึงอะไรบ้าง คำตอบแรกที่ได้คือ Pair Programing ใช่หรือไม่ 
:)
 แล้วสิ่งต่อไปละ? Unit Test First ใช่หรือไม่? มีอะไรอีกไหมครับ? User story ไง? มีอีกไหมครับ?.............................ถึงตอนนี้จะเริ่มเงียบ เพราะเริ่มนึกไม่ออก

คุณจะตอบเหมือนคำตอบด้านบนไหมครับ? ผมเดาว่าไม่ใช่ก็ใกล้เคียงล่ะ นั่นแปลว่า XP นั้นเน้นเรื่อง Development เป็นสำคัญใช่ไหมครับ? ส่วนตัวผมคิดว่าใช่ เพราะชื่อมันบอกอยู่แล้วว่าเป็น eXtreme Programming

แล้วนั่นคือปัญหาของผมครับ XP เน้นเรื่อง development มากๆ จนอ่อนเรื่อง Project Management คือมันมีเนื้อหาหรือรูปแบบที่กว้างเกินไป ทำให้ implement ลำบาก และต้องใช่การตีความค่อนข้างมาก การ track งานเลยมีประสิทธิภาพไม่เต็มที่ จุดนี้ Scrum ช่วยได้มากครับ
Scrum คืออะไร?

Scrum เป็น development process ที่อยู่บนพื้นฐานของ Sprint ให้นึกถึงเวลาวิ่งแข่งระยะไกล เวลาวิ่งเราจะวิ่งเต็มแรงไม่ได้ใช่ไหมครับ เพราะหากวิ่งเต็มแรงเราจะเหนื่อยเสียก่อน อย่าว่าแต่จะชนะหรือเปล่าเลย อาจจะไม่ถึงเส้นชัยเสียด้วยซ้ำ วิธีการเราคือจะวิ่งแบบออมแรงไว้ก่อน แล้ว sprint เป็นช่วงๆไปตามช่วง check point ต่างๆ เช่นกันครับ Scrum ก็จะ sprint เป็นช่วงๆ ตามหลักการแล้วคือช่วงละ 2-4 สัปดาห์ โดยจะเป็นช่วงที่เราจะวิ่งกันอย่างเต็มที่เต็มขีดจำกัด หลังจบ sprint ก็จะพักบ้างสัก 3-5 วันให้เบาๆหน่อยก่อนที่จะ sprint กันต่อ (อันนี้จะผิดกับวิ่งแข่งหน่อย เพราะปกติเราจะ sprint สั้นๆ แต่ออมแรงยาวๆ แต่ scrum จะ sprint ยาวๆ แต่พักสั้นๆ 55555555)
Concept ของ Scrum 
ประกอบไปด้วย 3 หัวข้อหลักคือ
1. ว่าด้วยเรื่องของทีมงาน (Role)
2. ว่าด้วยเรื่องของวิธีการทำงาน (Process)
3. ว่าด้วยเรื่องของการประเมินและติดตามงาน (Demonstration and Evaluation)

แค่ 3 หัวข้อหลักบนก็แทบจะเสริมส่วนที่ XP ขาดไปได้ครบสมบูรณ์แบบ เห็นด้วยไหมครับ 
:)


ว่าด้วยเรื่องของทีมงาน (Role)
ในทีมงานจะประกอบไปด้ย 3 Roles หลักๆได้แก่

Scrum Team คือคนทำงานจริงๆ มีประมาณ 5-9 คน แต่ละคนไม่ได้กำหนดงานตายตัว สามารถทดแทนกันได้เสมอ โดยคนในทีมงานมีหน้าที่ประเมินเวลาของ task ที่จะต้องทำ แจกจ่ายงานและ assign งานกันเอง ส่วนวิธีการทำงานไม่ได้กล่าวถึงไว้มากนัก จุดนี้ผมใช้ XP ผสมเข้าเต็มที่คือทำงานเป็น pair, การทำ unit test (แม้จะไม่เอื้อนัก) และอื่นๆตามแบบฉบับของ XP

Product Owner เป็นตัวแทนของลูกค้า ทำหน้าที่จัดการเรื่อง product backlog ทั้งคิด ทั้งรวบร่วม พร้อมทั้งต้องเป็นคนเผยแพร่ product backlog ให้ทุกคนได้รับรู้ ได้เห็นกันง่ายๆ เพื่อให้คนในทีมเห็นอนาคตว่าจะมีอะไรรออยู่ข้างหน้า คนนี้เป็นคนเขียน User Story ด้วยครับ

Scrum Master ทำหน้าที่ดูแลทีมงาน เป็นโค้ชของทีมงาน และเป็นคนรับผิดชอบคุณภาพของผลงาน จัดลำดับความสำคัญของงาน แตก task ของ user story ออกมา lead การประชุม daily scrum ตัดสินใจในเรื่องต่างๆตามความเหมาะสมไม่ว่าจะเป็นเรื่องของ design หรือ architecture ของระบบ (ย้ำว่าตัดสินใจไม่ใช่คนออกแบบ คนออกแบบคือ scrum team)

ว่าด้วยเรื่องของวิธีการทำงาน (Process)
โดยเนื้อหามี 3 ส่วนหลักๆ ได้แก่

Backlog เป็นรายการของ feature ที่ต้องทำ คำว่า feature นี้รวมถึง request จากลูกค้า bug fix และ specification ของตัว product โดยคนทำคือ product owner ซึ่งจะจัดลำดับ feature ตามความสำคัญ จัด list เพื่อนำเข้า sprint และจัดการกับรายละเอียดต่างๆของ feature เช่นต้องจัดทำ user story สำหรับแต่ละ feature เป็นต้น

Sprint phase คือช่วง iteration นั่นเอง โดยมีกำหนดไม่เกิน 30 วัน ซึ่งก่อนเริ่ม sprint ก็จะมีการนำ product backlog มาจัดลำดับความสำคัญเพื่อเลือกมาเป็น sprint backlog จากนั้น scrum team จะดู backlog และแตกเป็น task ย่อยๆออกมาและทำการ estimate เวลาที่ใช้ในแต่ละ task หลังจากได้เวลาและต่อรองกันระหว่างทีมงานแล้ว ก็จะได้ list ของ task และ list ของ backlog ที่จะทำภายใน sprint ขึ้นมา

Daily scrum คล้ายกับ standup meeting โดยทุกๆวัน scrum master และ scrum team จะมีการประชุมกันเพื่อจัดว่าเมื่อวานทำอะไรไปบ้าง และวันนี้จะทำอะไรบ้าง มีการถกกันเพื่อแก้ไขปัญหาที่เจอเมื่อวาน และจัดการ assign task ให้กับทีมงาน

จาก 3 หัวข้อด้านบน จะเห็นว่ามันดูหลวมๆอยู่ดีไม่ใช่หรือ? จริงแล้วก็ใช่ แต่มันไม่ได้หมดแค่นั้น มันมี tool ที่นำมาช่วยเรื่องพวกนี้อยู่พอควร ไม่ว่าจะเป็น index card, planning poker , scrum checklist , Niko-niko calendars ซึ่ง tool แต่ละตัวใช้ได้ดีมีประโยชน์มากในการช่วยขับเคลื่อน process ซึ่งลองไปค้นหาข้อมูลศึกษาดูนะครับ ไว้ผมมีเวลาจะลองเขียนแต่ละตัวให้อ่านกัน

ว่าด้วยเรื่องของการประเมินและติดตามงาน (Demonstration and Evaluation)
จุดเด่นของ scrum คือเราสามารถวัดผลของการทำงานได้ และได้ดีมากๆด้วย ด้วย burn-down chart ที่เรียบง่าย และธรรมดา แต่มันทำให้เห็นสภาพของ sprint ได้อย่างชัดเจน โดยหลักการแล้วก็คือ graph ของงาน โดยแกน y เป็น จำนวน task ที่เหลือ และ แกน x เป็นวันแต่ละวันของ sprint โดยในแต่ละ dairy scrum เราจะมีการ update graph กัน เพื่อให้เห็นภาพความคืบหน้าของงาน และหลังจากจบ sprint เราก็จะเอา graph นี้แหละมาประเมินผลงานของทีมงาน โดยมาดูในแต่ละจุดว่าเหตุใดบางช่วง graph จึงเป็นแนวนอนไม่ดิ่งลงมา burn-down chart จะมีประสิทธิภาพมากเมื่อใช้คู่กับ index card เพราะจะทำให้ plot graph ได้ง่าย และรู้สถานการณ์ภายใน sprint ได้ดี
สรุป
และนี่คือทั้งหมดของ scrum ดูหลวมๆ แต่จริงๆแล้วยังมี detail อีกพอควรในแต่ละ tool ที่ใช้งาน ซึ่ง tool ต่างๆก็จะพุดขึ้นมาเรื่อยๆตาม idea ของคนในโลก อย่างเรื่องของ index card นี่ก็ไม่ได้เป็นหัวข้อหลักใน scrum แต่มีคนคิดขึ้นมาเพื่อทำให้ burn-down chart มีประสิทธิภาพมากขึ้น

หากคุณทดลองใช้ XP แล้วพบปัญหาเรื่องการ manage งานอย่างผม ลองประยุกต์ใช้ scrum เข้าไปเสริมสิครับ จะช่วยได้มากทีเดียว

reference: wikipedia, infoQsofthouse
 

  •  
  • Like
    3
  •  
  •  
  •  
  •  
  •  
  •  
  •  



ขอบคุณที่นำประสบการณ์มาแบ่งปันนะครับ -/\-

ทำให้ผมเข้าใจ Agile ขึ้นอีกระดับหนึ่งเลย ก่อนหน้านี้ผมคิดว่า scrum เป็นแค่ practice หนึ่งใน XP เสียอีก แต่พอกลับไปอ่านดู ผมถึงได้รู้ว่า ผมเข้าใจผิดแล้ว Scrum เป็น Agile process อีกอย่างหนึ่งเลย

Quote
"At the time of this writing there were many agile processes to choose from. These
include SCRUM[1], Crystal[2], Feature Driven Development[3], Adaptive Software Development
(ADP)[4], and most significantly, Extreme Programming[5]." -- http://www.objectmen...gileProcess.pdf

-------------------------------------------------
1. www.controlchaos.com
2. crystalmethodologies.org
3. Java Modeling In Color With UML: Enterprise Components and Process, Peter Coad, Eric Lefebvre, and Jeff De Luca,
Prentice Hall, 1999
4. [Highsmith2000]
5. [BECK99], [Newkirk2001]
Product owner นี่หมายถึง คนในทีมเราแต่ทำตัวเหมือนเป็นลูกค้า หรือเปล่าคะ?
ชอบ idea ของ burn-down chart กับ index card มากๆ เลยค่ะ ทำให้มองเห็นภาพการทำงานได้ดี
ดูเหมือน Scrum จะเน้นการ evaluate งานมากกว่า XP นะคะ

ไม่เคยทราบการทำงานของ scrum เลย เิพิ่งอ่านจากที่คุณ bomber เขียน เป็นครั้งแรกค่ะ

ขอบคุณมากๆ นะคะืที่แชร์ให้ฟัง
natty, on Oct 4 2007, 12:39 PM, said:
Product owner นี่หมายถึง คนในทีมเราแต่ทำตัวเหมือนเป็นลูกค้า หรือเปล่าคะ?
ใช่แล้วครับ เพราะ concept XP บอกว่าควรมี fulltime customer นั่งอยู่ด้วย แต่ความเป็นจริง มันทำไม่ได้หรอกครับ ใน scrum เลยมี Product Owner มาแก้ไขในจุดนี้ คือ คนๆนี้จะเปรียบเสมือนลูกค้า เป็นคน interface กับลูกค้าโดยตรง และรับ requirement จากลูกค้า แล้วแปลเป็น product backlog พร้อมทั้งเขียน user story ด้วย ซึ่งงานเหล่านี้จะหวังให้ลูกค้าทำคงเป็นได้แค่ความฝันเ่ท่านั้น
อืมๆ จริงๆ ทุกวันนี้แทบจะลืมคิดไปเลยว่า ทำไมไม่ทำลูกค้าสมมติขึ้นมา ในเมื่อหาตัวลูกค้าไม่ได้ (เป็นประจำ)

ขอบคุณสำหรับคำอธิบายค่ะ
ของดีมีประโยชน์ ขอบคุณที่มาย่อยให้ฟังครับ
natty, on Oct 6 2007, 11:36 PM, said:
อืมๆ จริงๆ ทุกวันนี้แทบจะลืมคิดไปเลยว่า ทำไมไม่ทำลูกค้าสมมติขึ้นมา ในเมื่อหาตัวลูกค้าไม่ได้ (เป็นประจำ)
เอ ลูกค้าสมมตินี่คุณ natty หมายความว่ายังไงเหรอครับ ที่คุณ Bomber อธิบายก็คือ ตัวแทนลูกค้า ซึ่งก็ต้องติดต่อลูกค้าตัวจริงอยู่ดีครับ
Pink Dragon, on Oct 10 2007, 12:11 AM, said:
natty, on Oct 6 2007, 11:36 PM, said:
อืมๆ จริงๆ ทุกวันนี้แทบจะลืมคิดไปเลยว่า ทำไมไม่ทำลูกค้าสมมติขึ้นมา ในเมื่อหาตัวลูกค้าไม่ได้ (เป็นประจำ)
เอ ลูกค้าสมมตินี่คุณ natty หมายความว่ายังไงเหรอครับ ที่คุณ Bomber อธิบายก็คือ ตัวแทนลูกค้า ซึ่งก็ต้องติดต่อลูกค้าตัวจริงอยู่ดีครับ

ก็หมายถึงแบบเดียวกันกับคุณ Bomber ค่ะ คือว่า ตัวแทนลูกค้า จะทำให้เราสามารถคุยได้เหมือนเป็นลูกค้า ซึ่งคนๆ นี้จะเป็นคนที่ต้องไปอยู่ใกล้ชิดลูกค้าและนำทุกอย่างมาบอกกับทีม อืม อธิบายไม่ค่อยถูก แต่คิดว่า เข้าใจตรงกันกับความหมายของคุณ Bomber และ คุณ Pink Dragon นะคะ

มีอะไรจะเสริมให้เข้าใจมากขึ้นก็เชิญได้นะคะ
ในหนังสือ eXtreme Programming Installed หรือ Planning เนี่ยแหล่ะ ก็กล่าวเกี่ยวกับปัญหาต่าง ๆ ที่อาจจะเกิดขึ้นกับการใช้งานจริง เรื่อง Fulltime User (Customer) เป็นเรื่องสำคัญมากเรื่องนึง

ในหนังสือพูดถึงการสร้าง Pseudo User ขึ้นมา โดยจำลองคนมาซักคนหรือกลุ่ม แล้วติ๊งต่างว่าเป็น User แต่มีข้อแม้ว่า ต้องหาโอกาสให้ Pseudo User ไปเจอ Actual User ให้มากที่สุดเพื่อจะได้ปรับความเข้าใจอย่างต่อเนื่อง

ปล. กลับไปผมต้องเจอสกรัมเหรอเนี่ย
ขอบคุณมากครับกำลังต้องการพอดีเลย
เข้ามาที่นี่อีกทีเพราะหาความหมายของ Scrum  
:)
 อธิบายได้เห็นภาพมากครับ ถึงจะเก่าแต่ก็มีประโยชน์