Extreme Programming Model

  
 
Extreme Programming Model
                    Extreme Programming Rule & Practicesหลังจากได้ศึกษา Google Development Process มานิดหน่อย ได้รู้ว่าหัวใจหลักของ Google ใช้ XP เป็น process การทำงาน เลยคิดว่าน่าจะศึกษา XP development process แบบจริงๆจังๆสักที ก็เลยลองศึกษาหาข้อมูลดู ซึ่งปกติผมจะทำ short note เอาไว้ด้วย เลยคิดว่าน่าจะเอามาแชร์ซะเลย จะได้มาช่วยกันทำความเข้าใจ แล้วเอามาถกกันนะครับหัวใจหลักของ XP มีอยู่ 4 องค์ประกอบได้แก่Planning
•เขียน User Stories
•ทำ Release Planning เพื่อให้ได้ Schedule
•มี Small Release บ่อยๆ
•แบ่ง project ออกเป็น iterations
•ทำ Iteration Planning ตอนเริ่มทุก iteration
•Move people around
•stand-up meeting ทุกๆวัน
•Fix XP กล้าเปลี่ยน process หากมีปัญหาหรือไม่เข้ากับงาน

Designning
•Simplicity พยายามออกแบบระบบที่ง่ายที่สุดที่ทำงานได้
•ใช้ชื่อที่สื่อและง่ายต่อการเข้าใจ System Metaphor
•ใช้ CRC cards สำหรับการ design
•สร้าง spike solution เพื่อลด risk - ทดลองทำ POC เพื่อดูว่าทำได้จริง
•ไม่ใส่ function ที่ยังไม่ต้องการ (added early) - มีเพียง 10% ของสิ่งที่ทำเพิ่มเท่านั้นที่จะถูกใช้จริง ดังนั้นอย่าเสียเวลาไปกับ 90% ที่ไม่ได้ใช้ ให้ concentrate ที่ feature function ปัจจุบันเท่านั้น
•Refactor ทุกๆครั้งเมื่อมีโอกาส

Coding
•ต้องมี user อยู่ตลอดเพื่อถามปัญหาได้ทันที always available
•มี standard ที่ตกลงกันในการเขียน code
•เขียน unit test ก่อน
•ใช้ pair programmed ในการเขียน code
•ให้ integrate code ทีละคู่ อย่ารวมทีเดียวหมด และให้ทำบ่อยๆ ให้มากกว่าสัปดาห์ละครั้ง
•Integrate บ่อยๆ - ให้ release code ขึ้น repository ให้บ่อยที่สุด ทุกๆ 2-3 ชม.
•ใช้ Collective Code Ownership ทุกคนใช้ code ร่วมกัน สามารถแก้ code คนอื่นเพื่อแก้ bug และ refactor ได้
•ปล่อย optimization ไว้สุดท้าย - Make it work, Make it right, then make it fast
•ไม่ทำ overtime - ให้ใช้ release planning meeting แก้ project scope หรือ timing แทน การเพิ่มคนก็ไม่ช่วยให้ดีขึ้นหากเมื่อ project เริ่ม late แล้ว

Testing
•ทุกๆ code ต้องมี unit test
•ทุกๆ code ต้องผ่าน unit test ก่อนจะ release
•เมื่อเจอ bug ให้สร้าง test case สำหรับ case นี้ทันที
•ทำ Acceptance Test บ่อยๆ และมีการ publish ผลที่ได้

----------------------------------------------------------------------------------------------------User Stories
•จุดประสงค์คล้ายกับ Use case
•เขียนโดยลูกค้า ว่าระบบต้องทำอะไรให้แก่เขาได้บ้าง (output ของระบบโดยรวม)
•คล้ายกับ Usage Scenarios แต่ไม่ได้จำกัดแค่เรื่อง UI
•อยู่ใน format ของ three sentences โดยไม่มี technology เข้ามาเกี่ยวข้อง
•User stories จะช่วยในการสร้าง Acceptance Test
•User stories ต่างจาก requirements specification ตรงที่มันมีรายละเอียดน้อยกว่า โดยให้รายละเอียดเพียงพอที่จะ estimate ได้ว่าเรื่องราวทั้งหมดจะใช้เวลาทำเท่าไร
•หลังจากได้วันแล้วก็จะไปคุยกับลูกค้า หน้าต่อหน้า เพื่อให้ได้ข้อมูลรายละเอียดเพิ่มเติม
•Developers จะทำการกะระยะเวลาพัฒนาในแต่ละเรื่อง (Story) โดยแต่ละเรื่องอาจจะใช้เวลา 1, 2 หรือ 3 สัปดาห์ เป็น "Ideal development time"
•หาก story ใดใช้เวลามากกว่า 3 weeks ควรจะแตกออกเป็น story ย่อยๆ ให้ได้
•หากใช้เวลาน้อยกว่า 1 week แสดงว่าลง detail มากเกินไป
•User stories ประมาณ 80 story +-20 เป็นเลขที่ดีที่สุดสำหรับทำเป็น release plan
•สิ่งที่แตกต่างระหว่าง stories และ requirement doc. อีกอย่างคือ จะ focus ที่ความต้องการของ user เป็นหลัก และต้องพยายามหลีกเลี่ยงการระบุถึง technology, database, algorithms และ Focus ตรงที่ความต้องการ user มากกว่าจะเป็น UI layout

Release Planning
•มี meeting เพื่อทำ release plan ซึ่งกำหนดภาพรวมของ project และจะนำมาใช้ทำ iteration plan
•กำหนดวันที่ทุกคนสามารถ commit ได้ ต้องได้รับการตัดสินใจจากทั้งฝั่ง technical และ business
•ทำการประเมิน user story แต่ละเรื่อง เพื่อกำหนดเป็น ideal programming weeks โดยแต่ละ ideal programming week หมายถึงทำงานนั้นงานเดียวไม่มีเรื่องอื่นมากวน แต่ต้องรวม testing แล้วด้วย แล้ว business ทำการตัดสินใจว่า story ไหนสำคัญกว่า story ไหน
•business และ developer ร่วมกันกำหนด release แรกว่าจะมี story ใดบ้าง
•ให้ทำการ deliver ระบบที่ใช้งานได้หรือ test ได้ตรงตาม business อยู่เรื่อยๆเพื่อรับ requirement ใหม่และปรับปรุงระบบให้ดีตลอดเวลา
•ห้ามลดเวลาการทำงานเด็ดขาด หาก plan ไม่ได้ตามที่ management ต้องการ แต่ให้ทำการ negotiate ตัว release plan แทน
Release Plan
•release plan ที่ดีขึ้นอยู่กับ Scope, Resource, Time, Quality ฝ่ายบริหารสามารถเลือกได้แค่ 3 ตัวจาก 4 เท่านั้น
•scope คือจำนวนงานที่จะเสร็จ
•resource คือคนที่จะทำ
•time คือเวลาที่ใช้ release
•quality คือคุณภาพของ software ที่ได้รับการ test อย่างดี
•release plan คือการกำหนดว่าแต่ละ user stories ที่จะถูก implement จะ release วันไหนและ release ไหน
•Stories จะถูกทำเป็น acceptance test ในแต่ละ iteration เพื่อให้แน่ใจว่าแต่ละ iteration ทำงานได้ถูกต้อง
Project velocity
•project velocity คือวิธีการตรวจวัดความคืบหน้าของ project
•โดยทำการประเมิน user stories ที่จะเสร็จในแต่ละ iteration
•รวมผลการประเมิน task ที่เสร็จในแต่ละ iteration plan
•ในแต่ละ iteration planning ลูกค้าสามารถเลือก user stories จำนวนเท่ากับ iteration ที่แล้วก่อน แล้วหลังจากประเมิน task ของ iteration แล้วหากเกินค่อยปรับเปลี่ยน
•ให้ทำการ re-estimate และ re-negotiate ใน release plan หาก project velocity มีการเปลี่ยนแปลง
•ไม่ต้องเสียเวลาหาร project velocity ด้วยระยะเวลาของ iteration หรือจำนวนของคน เพราะแต่ละ project มีคุณลักษณะไม่เหมือนกัน แต่ให้ดูที่จำนวนของงานที่เสร็จในแต่ละ iteration เป็นสำคัญ
•การรวบรวมข้อมูลให้มากที่สุดตั้งแต่ต้นไม่ช่วยอะไร เพราะมันเป็นแค่การเดา ให้ทำการ estimate overall project ดีกว่า
Iterative Development
•Iterative Development ช่วยเพิ่มความเร็วในการพัฒนาระบบ
•โดยแบ่งเวลาการพัฒนาเป็น 1-3 week โดยต้องพยายามให้ไม่เกินเด็ดขาด เพราะเป็นการ measuring progress ของ plan ของระบบในxp
•ห้าม schedule ตัว programming task ก่อนเด็ดขาด ให้ทำ iteration plan ก่อนเริ่ม iteration นั่นๆเสมอ (Just-in-time planning)
•ห้าม implement อะไรก็ตามที่อยู่นอกเหนือ iteration เด็ดขาด ไม่ต้องเผื่ออนาคต เพราะมันอาจจะไม่เคยได้ใช้ ถ้าต้องใช้ค่อยทำ หากต้องทำการ redesign ก็ต้องทำ ไม่ต้องทำเผื่อก่อน
•กำหนด deadline ของ iteration seriously! พยายาม track งานภายใน iteration และหากมีแนวโน้มว่าจะไม่เสร็จ ให้ทำการเรียกประชุม iteration planning ใหม่ กำหนดเวลาใหม่ หรือทำการย้าย task ไปก่อน
•เน้นไปที่ task ที่มี priority สูงที่ได้จาก user ก่อนเป็นหลัก
Iteration Planning
•Iteration Planning เป็น meeting ที่มีทุกครั้งก่อนเริ่มแต่ละ iteration
•เลือก user stories ที่จะนำมาทำ จาก release plan โดย customer เอง โดยดูจากความสำคัญเป็นหลัก
•Feature ที่ Fail จากการทำ acceptance tests ให้นำมาเลือก fix ในคร่าวนี้ด้วย
•user stories และ failed test จะถูกมาแตกย่อยเป็น programming task
•user stories เป็นภาษาของ user แต่ programming task เป็นภาษาของ developer
•Developer สมัครใจทำ task และ estimate เวลาที่จะใช้ทำ
•แต่ละ task ควรกำหนดเป็น 1,2, หรือ 3 ideal programming days (ไม่มีอะไรมาแทรก)
•Task ที่เกิน 3 วันควรแตกเป็น task ย่อย
•ให้นำวันที่ได้มารวม หากวันที่ได้มากกว่า iteration ที่แล้ว customer จะต้องเลือก user stories ที่จะเอาออกไป (snow plowing) แต่หากได้วันน้อยกว่า iteration ที่แล้ว สามารถเพิ่ม story ได้
•ห้ามเพิ่มหรือ design เผื่อเด็ดขาก ให้ใช้วิธีการ refactoring
•ห้ามต่อเวลา task หรือ story estimate เด็ดขาด

CRC cards
•Class, Responsibilities, and Collaboration
•ทุกๆคนในทีมมีส่วนร่วมในการ design
•แต่ละ CRC card แสดงถึง Object
•Class ของ object เขียนบนหัวของ card
•Responsibilities ของ class ให้ list ลงมาด้านซ้าย
•Collaborating classes ให้ list ลงมาด้านขวา ข้างๆ Responsibilities
•แต่ทางปฏิบัติอาจจะเขียนแค่ชื่อ Class เท่านั้น
•CRC session เริ่มจากมีคนต้องการจำลองการทำงานของระบบ โดยดูจากการส่ง message หากันระหว่าง object
•หากมีจำนวนคนพูดมากเกินหรือมีคนพยายามย้าย card ตลอดเวลา ให้จำกัดคนที่จะขึ้นพูดหรือย้าย card

Spike Solution
•เป็น POC เพื่อทดสอบแนวคิดการแก้ปัญหา และปัญหาด้านการ design
•เป็นเพียงโปรแกรมง่ายๆที่ใช้ทดสอบ expect ว่าจะทิ้งไปไม่ได้ใช้ แค่ทดลอง
•ใช้เพื่อ estimate user story ได้แม่นยำขึ้น

Refactor
•ปรับโครงสร้าง ลบสิ่งที่ไม่จำเป็น แก้ไขตัวแปร รวมสิ่งต่างๆเข้าด้วยกัน
•keep design simple as you can
•พยายามทำ code ให้สะอาด เข้าใจง่าย แก้ไขง่าย และต่อเติมได้ง่าย
•ยากที่จะปฏิบัติช่วงแรก เนื่องจากเริ่มต้นเรามักมี design ในใจที่ดีอยู่แล้ว แต่ต้องปล่อยมันไป ให้ทำเท่าที่จะสามารถทำให้ระบบทำงานได้ตอนนี้ แล้วค่อยมา refactor ที่หลังเพราะการ refactor ที่หลังจะดีกว่าที่คิดไว้ตอนแรกแน่นอน (เข้าหลักอย่าเผื่อไว้ก่อน เพราะจะไม่ได้ใช้ หรือไม่ก็อนาคตจะมีสิ่งที่ดีกว่า)quantity

Pair Programming
•Code ที่ถูกเขียนควรเกิดจากคน 2 คนช่วยกันเขียนขึ้นมา
•คน 2 คนใช้ คอมพิวเตอร์เครื่องเดียวกัน จะได้ปริมาณเท่ากับแยกกันทำ แต่ได้คุณภาพที่ดีกว่าเสมอ ท้าพิสูจน์ เหตุผลเพราะ code ที่คุณภาพดีจะทำให้งานทำได้เร็วขึ้นนั่นเอง
•คน 2 คนช่วยกันทำ สามารถแลกเปลี่ยน keyboard และ mouse กันได้ โดยคนนึ่งคิดและพิมพ์ อีกคนจะคิดถึง design ว่าอะไรควรอยู่ตรงไหน ควรจะปรับอย่างไรให้เข้าใจง่าย

Collective Code Ownership
•ส่งเสริมให้ทุกๆคนมีส่วนร่วมกับ idea ใหม่ๆในทุกๆส่วนของ project
•ทุกคนใช้ code ร่วมกัน สามารถแก้ code คนอื่นเพื่อแก้ bug และ refactor ได้
•ทุกๆ developer สร้าง unit test สำหรับ code ตัวเอง
•source code เวลาขึ้น repository ต้องมี unit test
•code ที่จะขึ้น repository ต้องผ่าน unit test 100% เท่านั้น