1. Planning
เขียน User Stories
ทำ Release Planning เพื่อให้ได้ Schedule
มี Small Release บ่อยๆ
แบ่ง project ออกเป็น iterations
ทำ Iteration Planning ตอนเริ่มทุก iteration
Move people around
stand-up meeting ทุกๆวัน
กล้าเปลี่ยน process หากมีปัญหาหรือไม่เข้ากับงาน
2. Designning
Simplicity พยายามออกแบบระบบที่ง่ายที่สุดที่ทำงานได้
ใช้ชื่อที่สื่อและง่ายต่อการเข้าใจ System Metaphor
ใช้ CRC cards สำหรับการ design
สร้าง spike solution เพื่อลด risk - ทดลองทำ POC เพื่อดูว่าทำได้จริง
ไม่ใส่ function ที่ยังไม่ต้องการ (added early) - มีเพียง 10% ของสิ่งที่ทำเพิ่มเท่านั้นที่จะถูกใช้จริง ดังนั้นอย่าเสียเวลาไปกับ 90% ที่ไม่ได้ใช้ ให้ concentrate ที่ feature function ปัจจุบันเท่านั้น
Refactor ทุกๆครั้งเมื่อมีโอกาส
3. 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 แล้ว
4. Testing
ทุกๆ code ต้องมี unit test
ทุกๆ code ต้องผ่าน unit test ก่อนจะ release
เมื่อเจอ bug ให้สร้าง test case สำหรับ case นี้ทันที
ทำ Acceptance Test บ่อยๆ และมีการ publish ผลที่ได้
5. User Strories
จุดประสงค์คล้ายกับ 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 ได้ ต้องได้รับการตัดสินใจจากทั้งฝั่ง techical และ 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 แทน
6. 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 ทำงานได้ถูกต้อง
7. 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 ดีกว่า
8. Iterative Development
Iterative Development ช่วยเพิ่มความเร็วในการพัฒนาระบบ
โดยแบ่งเวลาการพัฒนาเป็น 1-3 week โดยต้องพยายามให้ไม่เกินเด็ดขาด เพราะเป็นการ measuring progress ของ plan ของระบบในxp
ห้าม schedule ตัว programming task ก่อนเด็ดขาด ให้ทำ iteration plan ก่อนเริ่ม iteration นั่นๆเสมอ (Just-in-time planing)
ห้าม implement อะไรก็ตามที่อยู่นอกเหนือ iteration เด็ดขาด ไม่ต้องเผื่ออนาคต เพราะมันอาจจะไม่เคยได้ใช้ ถ้าต้องใช้ค่อยทำ หากต้องทำการ redesign ก็ต้องทำ ไม่ต้องทำเผื่อก่อน
กำหนด deadline ของ iteration seriously! พยายาม track งานภายใน iteration และหากมีแนวโน้มว่าจะไม่เสร็จ ให้ทำการเรียกประชุม iteration planning ใหม่ กำหนดเวลาใหม่ หรือทำการย้าย task ไปก่อน
เน้นไปที่ task ที่มี priority สูงที่ได้จาก user ก่อนเป็นหลัก
9. 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 เด็ดขาด
10. 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
11. Spike Solution
เป็น POC เพื่อทดสอบแนวคิดการแก้ปัญหา และปัญหาด้านการ design
เป็นเพียงโปรแกรมง่ายๆที่ใช้ทดสอบ expect ว่าจะทิ้งไปไม่ได้ใช้ แค่ทดลอง
ใช้เพื่อ estimate user story ได้แม่นยำขึ้น
12.Refactor
ปรับโครงสร้าง ลบสิ่งที่ไม่จำเป็น แก้ไขตัวแปร รวมสิ่งต่างๆเข้าด้วยกัน
13. keep design simple as you can
พยายามทำ code ให้สะอาด เข้าใจง่าย แก้ไขง่าย และต่อเติมได้ง่าย
ยากที่จะปฏิบัติช่วงแรก เนื่องจากเริ่มต้นเรามักมี design ในใจที่ดีอยู่แล้ว แต่ต้องปล่อยมันไป ให้ทำเท่าที่จะสามารถทำให้ระบบทำงานได้ตอนนี้ แล้วค่อยมา refactor ที่หลังเพราะการ refactor ที่หลังจะดีกว่าที่คิดไว้ตอนแรกแน่นอน (เข้าหลักอย่าเผื่อไว้ก่อน เพราะจะไม่ได้ใช้ หรือไม่ก็อนาคตจะมีสิ่งที่ดีกว่า)
14. 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% เท่านั้น
[/b]
Reply With Quote
