บทความนี้ผมเขียนตั้งแต่ 24 November 2015 at 12:54:37 PM GMT+7 ที่ผมเขียนแบบนี้เพราะการพูดถึง การทำงาน แบบ Agile มานานมาก แต่ผมคงไม่ได้จะมาดูถูกใคร แต่บางองค์กรพึ่งจะเริ่ม adoption คงไม่ต้องพูดถึง Technology Stack อื่น ๆ หรอกครับ ผมขอไม่อนุญาติเรียบเรียงใหม่ ไม่อยากขิงใคร
Agile คืออะไร เป็นหลักการในการพัฒนา software แบบใหม่ที่เน้น…
Rapid and flexible response to change
ทำให้การพัฒนาว่องไว
มีการทำเรื่อยๆไม่ต้องหยุด แม้มีอะไรมากระทบก็ไม่เป็นไร
เมื่อมีการเปลี่ยนแปลง เราสามารถรองรับความเปลี่ยนแปลงนั้นได้อย่างรวดเร็ว ไม่ตายตัว
วัตถุประสงค์ของ Agile
1. เน้นว่าใครถนัดอะไร และการพูดคุยสื่อสารกัน มากกว่า การยึดติดที่เครื่องมือและกระบวนการ เช่นเปลี่ยนให้โปรแกรมเมอร์ไปคุยกับลูกค้าแทน ลูกค้าบอกอะไรมาก็ทำตามนั้นได้เลย
2. ให้ทำงานโดยยึดที่ผลผลิตหรือ software เป็นหลัก เช่น เดิมเน้นเอกสารแต่ Agile ไม่สนมากนัก แต่สนทีี่ว่าเรามี sw หรือของส่งให้ลูกค้าหรือยัง
3. ให้ความสำคัญเรื่องของการติดต่อสื่อสาร เช่น เดิมมีสัญญาหรือ contact กันแต่ Agile ไม่สนใจ ให้มองที่ความสัมพันธ์ระหว่างผู้พัฒนาและลูกค้า
4. ยอมรับความเปลี่ยนแปลง เช่น เดิมต้องวางแผนให้ครบเป็นอย่างดี และทำตามแผน(gantt chart) ให้ได้ แต่ Agile ไม่ต้องทำตามแผนแต่เน้นการสนองความเปลี่ยนแปลงที่เกิดขึ้นได้
Note: ถ้าเรามีโปรเจคเก่าที่สามารถต่อเนื่องได้ ดังนั้นแสดงว่าเรามี Asset เดิมเพื่อมาตั้งต้นทำโปรเจคใหม่ เพราะฉะนั้นงานใหม่เราก็สามารถนำ Asset มาส่งมอบไปก่อนก็ได้
หลักการ Agile
เน้นความพอใจให้ลูกค้า ลูกค้าชอบ มีการส่งมอบ sw อย่างต่อเนื่อง
ยอมรับ requirement ที่เปลี่ยนแปลง
มีการส่งมอบงานบ่อยๆ (ทุกๆ 2 สัปดาห์)
ลูกค้าและผู้พัฒนา้ต้องทำงานร่วมกัน (โปรแกรมเมอร์ไปทำงานที่ site ลูกค้า) ต้องเจอกันทุกวันจนโปรเจคเสร็จ
การทำงานต้องปล่อยให้ทีมงานมีอำนวจการตัดสินใจเองได้ ปล่อยให้เค้าทำงาน ไว้ใจกันและทีมงานก็ต้องมีความรับผิดชอบระดับนึง
การติดต่อกัน ต้องคุยซึ่งๆหน้า ห้ามอีเมลล์หรือโทร
วัดความก้าวหน้าของงานที่ SW
กระบวนการทำงาน ให้ทำไปเรื่อยๆ อย่าหวือหวา ค่อยๆทำ ส่งงานทีละนิด ช่วยทำให้คุณภาพชีวิตของผู้พัฒนาดีขึ้น
ผู้พัฒนา สปอนเซอร์ ลูกค้า ต้องมีการทำไปเรื่อยๆ คงที่ ไม่เร็วเกินหรือช้าเกิน
ทีมงานต้องให้ความสนใจกับเทคนิคต่างๆ มีการแชร์กัน
เน้นความง่าย ออกแบบง่ายๆ พื้นๆ ไม่ซับซ้อน ทำให้ดูแลแก้ไขง่ายเมื่อพบความเปลี่ยนแปลง
ทีมมีความรับผิดชอบในกระบวนการของตัวเอง
มีการนัดพบแลกเปลี่ยนกันสม่ำเสมอ
Note: การทำงานในขั้นแรก ก็อาจมีการส่งมอบของได้เป็น หน้าจอ, prototype,infrastructure โดยขั้นแรกอาจมองว่า proogress เราเท่ากับ 0 เปอร์เซ็นต์ (เพราะยังไม่มี SW เกิดขึ้น)
โมเดลของ Agile (AM : Agile Modeling)
เลือกบางหลักการมาทำ
เป็นวิธีนึงที่จะเอาหลักการของ Agile มาจัดการกับเอกสารและระบบเดิมที่มีอยู่ได้
ใน Agile ประกอบด้วย
1. value ผลลัพธ์
2. principle หลักการ
3. practices วิธีปฏิบัติ
ทั้งสามอย่างนี้เป็นส่วนหนึ่งในโมเดล Agile ที่สามารถนำมาพัฒนา SW ให้มีประสิทธิภาพและเกิด overhead น้อย
ให้มอง Agile เป็นส่วนขยายของกระบวนการพัฒนา SW แบบเดิมได้
ให้ Agile เข้าไปกำกับ ดูว่าของเดิมที่มีอยู่อันไหนสำคัญก็ทำ ไม่สำคัญก็ละ
นำ Agile มาจัดลำดับความสำคัญ ดูว่ากิจกรรมไหน ควรทำ ไม่ควรทำ
AM Value (ผลลัพธ์)
เน้นติดต่อสื่อสาร
เน้นความง่าย ไม่ซับซ้อน
เน้น feedback จากลูกค้า
เน้นความกลัาตัดสินใจ
เน้นความเคารพกันและกัน
AM Core Principle (หลักการ)
ง่าย ไม่เวอร์เกิน
รับ requirement พร้อมเปลี่ยนแปลงได้ตลอดเวลา
เ้น้นปัจจุบีนเป็นหลัก
ทำ model ตามความจำเป็นเท่านั้น
พยายามใช้ multiple model มองหลายๆมุมมอง
มีการตอบกลับเร็ว
SW ถือเป็นจุดมุ่งหมายหลัก
ให้แบกสัมภาระเบาๆ
AM Supplement Principle
เ้น้น content มากกว่า representation(ที่ใช้ UML เขียน) ไม่เน้นเครื่องมือ เน้นที่เน้อหาข้างใน
ติดต่อกันอย่างเปิดเผย และตรงไปตรงมา
AM Core Practice (แนวทางปฏิบัติ /ลงมือทำ)
1. จัดประชุม รวบรวม Active stakeholder เท่านั้น บางมีอาจมี None stakeholder เข้ามาฟังได้ แต่ห้ามออกความคิดเห็น ห้ามถาม ห้ามติดต่อ ห้ามแสดงไอเดีย
2. นำ Artifact มาใช้ให้ถูกต้อง
o Note : Artifact คือชิ้นส่วนของงานที่เราทำระหว่างการพัฒนาระบบเช่น อีเมลล์, source code,จดหมาย,ใบเชิญประชุม ถ้า Artifact ใดถูกเลือกมาใช้ในการทำงาน เรียกว่า “work products” และถ้า work products นี้ ถูกส่งมอบให้ลูกค้า้เรียกว่า “Deliverable”
3. พยายามเป็นเจ้าของงาน สามารถทำงานแทนกันและกันได้
4. พยายามใช้โทเดลแบบคู่ขนาน จะได้มองต่างมุม เพื่อเก็บรายละเอียดของระบบให้ครบ
5. ทำให้เนื้อหาง่าย
6. พยายามวาดรูปไม่ให้ซับซ้อน
7. พยายามให้โมเดลเข้าถึงได้ทุกคน
8. สามารถเปลี่ยน Artifact นึงไปอีกอันได้
9. ใช้โมเดลแบบเล็กก่อนค่อยขยาย
10. พยายามให้ผู้อื่นมีส่วนร่วมในการทำโมเดล
11. พิสูจน์ด้วยการลองเขียน code ดู (จาก code เริ่มต้นตั้งแต่แรก)
12. ใช้เครื่องมือง่ายๆในการทำงาน เช่น กระดาษ,กระดานดำ
AM Supplement Practices
ทำให้เป็นาตรฐาน
ค่อยๆสร้างให้มีรูปแบบ เมื่อถึงเวลาค่อยใช้
โมเดลไม่ใช้ ให้โยนทิ้งไปเลย เพราะจะได้ไม่เสียเวลามาดูแล
เน้น contract (สัญญาระหล่างระบบที่สัมพันธ์กันอยู่) พยายามจัด contract ให้เป็นทางการ เช่น web service มี signatureอะไรบ้างใน function call
การ update code เฉพาะตอนที่มีปัญหา
Note : Design By Contract (อย่างเป็นทางการ)
A เรียกใช้ B เพื่อจับบริการที่ B มีให้ , A ต้องรู้ว่า B มีอะไรให้ใช้ และใช้แล้วได้อะไร แบบนี้เป็น contract ระหว่าง A-B เช่น การถอนเงิน A (client), B (บัญชีเงินฝาก)
1. Pre Condition (เขียนเงื่อนไขที่เป็นจริง ก่อนไปใช้บริการ)
o WDAmount <= -100
2. Post condition (เงื่อนไขใดๆ เมื่อไปเรียกใช้บริการแล้ว มีอะไรที่เป็นจริงบ้าง) New Balance =
o Balance – WDAmount
3. Invariant (เงื่อนไขใดๆ ที่จะต้องเป็นจริง ตลอดเวลา ในขณะที่ B ทำงานอยู่)
o Balance >= 100 B.
เทคนิคการพัฒนาแบบ 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
ตัวอย่างการเขียน
Test case No.
Desc.
Inputs
Expected Outputs
Actual Outputs
Remark
1.
ชื่อ pathname
A=5,B=2
X=5
X=-5
2.
ชื่อ pathname
C=8
X=2
X=2
รูปแบบวิธีการที่ทำเอา Agile มาใช้
1. Agile UP
2. XP (eXtream Programming)
3. FDD (Feature Driven Development)
4. Scrum
Extreme Programming (XP)
อ่านเพิ่มเติมที่นี่
XP เน้นความพึงพอใจเป็นหลัก
ทีมงานทำ XP ต้องมีทักษะในการทำด้านเทคนิค เพื่อพัฒนา Software
โปรเจคที่ทำไม่ควรใหญ่มาก และทีมงานที่ทำไม่ควรเกิน 10 คน (ถ้างานเยอะ ลูกค้าหลายคน ทำให้ยุ่ง)
งานต้องหั่นได้ ข้อดีคือ การทำงานด้วย OO ทำให้ระบบเชื่อมต่อกันได้ง่ายไร้รอยตะเข็บ
ปัจจัยพื้นฐาน
communication : เน้นเรื่องการพบปะพูดคุย (หลักการ Agile)
Simplicity : ออกแบบและเขียนโปรแกรมให้ง่าย ไม่เน้น performance มากนัก เน้นเรื่องแก้
Feedback : เน้นเรื่องลูกค้า feedback เราเปลียนได้เรื่อยๆ โดยใช้ refactor
Courage : เราต้องสามารถตัดสินใจเองได้ โปรแกรมเมอร์มีความกล้าในการตัดสินใจ
12 กิจกรรมหลัก
1. วางแผนเกมส์
2. พยายามซอยงานให้ถี่ๆ
3. มีตัวกลางคั่นระหว่าง user และตัวเรา (มองว่าคนที่เชื่อนผ่านตัวเราให้ผ่าน metaphor)
4. ออกแบบให้ง่าย
5. ทดสอบเสมอ
6. แก้ code บ่อยๆ (refactoring)
7. ทำงานเป็นคู่ (pair programming)
8. Team code ownership
9. ทำการรวบรวมงานอย่างต่อเนื่อง(เพราะงานที่ทำเราแบ่งเป็นชิ้นเล็กๆ)
10. ทำงานไปเรื่อยๆ ไม่หักโหม ห้ามว่าง
11. มองทีมเป็นหนึ่ง
12. ใช้มาตรฐานการ code แบบเดียวกัน กรณีใน OO มีมาตรฐานเช่น (1) 1 class มี 1 file (2) ตั้งชื่อ ns เป็นมาตรฐาน
Agile_software_development.pdf
บทความนี้ผู้เขียนตั้งใจเขียนเล่าประสบการณ์การทำงานโครงการที่ใช้วิธีการพัฒนาซอฟท์แวร์แบบ Agile ในองค์กรแห่งหนึ่ง การที่ได้มีโอกาสได้ร่วมทีมที่ใช้วิธีการนี้ทำให้ได้เห็นมุมมองที่แตกต่างจากการอ่านหรือได้ยินจากผู้อื่น เลยคิดว่าน่าจะเป็นประโยชน์สำหรับผู้อ่านที่จะได้ศึกษาและนำไปประยุกต์ใช้หรือเสริมกับกระบวนการพัฒนาที่ใช้อยู่
สิ่งสำคัญที่ควรรำลึกเสมอคือ วิธีการแบบ Agile ไม่มีกฏตายตัวว่าต้องขั้นตอนหนึ่งสองสาม ตัว Agile เองเป็นหลักการหลวมๆที่เน้นเรื่องคน และการสื่อสารระหว่างทีมให้มีประสิทธิภาพในกระบวนการที่มีขั้นตอนที่ไม่ซับซ้อน ขั้นตอนใดที่สร้างความยุ่งยาก หรือไม่เหมาะกับสภาพแวดล้อมขององค์กร ก็ต้องปรับแต่งให้เหมาะสม ปัจจุบันมีหลายสำนักที่กำหนดวิธีการพัฒนาที่จัดอยู่ในกลุ่ม Agile ได้แก่ XP, Scrum, Agile Modeling, Lean เป็นต้น การเลือกใช้เทคนิคไหนคงต้องขึ้นอยู่กับความพร้อมขององค์กร ดั่งเช่นตัวอย่างองค์กรสมมติที่ผมจะเล่าให้ฟังดังนี้
บริษัทร่ำรวยเป็นบริษัทขนาดใหญ่ที่มีพนักงานหลายพันคน ทีมไอทีมีคนระดับร้อยคน อยู่กระจายตามชั้นต่างๆของตึก ทีมไอทีที่นี่พัฒนาซอฟท์แวร์ระดับองค์กรเอง โดยใช้เทคโนโลยีจาวา ต่อเชื่อมกับระบบเมนเฟรม เพื่อให้พนักงานและลูกค้าสามารถใช้แอพพลิเคชั่นผ่านเวบจากที่ใดก็ได้ ปัจจุบันระบบกำลังพัฒนาเวอร์ชั่นใหม่ เพิ่มฟีเจอร์หลักที่ยังไม่เคยทำมาก่อน และต้องใช้ร่วมกับระบบปัจจุบันที่มีความซับซ้อน และต้องทำให้เสร็จภายในเวลาจำกัดไม่กี่เดือน บ.ร่ำรวยมองว่าด้วยกระบวนการและทีมงานที่มีอยู่ปัจจุบันไม่สามารถพัฒนาซอฟท์แวร์ให้เสร็จทันตามเวลาที่กำหนดแน่ๆ เค้าเลยอยากจ้างบริษัทที่ปรึกษามาช่วยพัฒนาและบริหารโครงการให้
องค์กรที่นี่ไม่เคยใช้วิธีการพัฒนาแบบ Agile มาก่อน ดังนั้นคนในแผนกไอทีและผู้บริหารไอทีเองก็ไม่แน่ใจว่าวิธีการนี้จะใช้ได้กับองค์กรตนหรือไม่ สิ่งที่บริษัทเลือกทำ คือ การทดสอบกระบวนการนี้กับโครงการนำร่องเล็กๆ แล้วดูผลลัพธ์ทั้งจากซอฟท์แวร์ที่พัฒนาขึ้นและจากความเห็นของทุกคนที่เกี่ยวข้องกับโครงการนี้ ผลปรากฏว่าผลลัพธ์ออกมาดีประทับใจคนที่เกี่ยวข้อง ทำให้บ.ร่ำรวยเชื่อมั่น และเดินหน้าเต็มกำลังกับวิธีการพัฒนาวิธีนี้ และให้บริษัทที่ปรึกษานี้รับผิดชอบด้านการบริหารโครงการ จัดทำ และประสานงานกับทุกฝ่าย
สิ่งสำคัญของการบริหารโครงการขนาดใหญ่ ก็คือการวางแผน บริหารทรัพยากร แต่การวางแผนแบบไหนถึงจะไม่มากเกินไป จนทำให้เสียเวลาเกินเหตุ และไม่น้อยไปจนกระทั่งไม่รู้ว่าทีมไหนรับผิดชอบส่วนไหน บริษัทร่ำรวยเอง มีการแบ่งงานคร่าวๆในรูปแบบของ Use Case ในหน่วยหลายสิบตัว แต่แต่ละตัวมีขนาดใหญ่และซับซ้อน เพราะครอบคลุมไปถึงกระบวนการธุรกิจครบวงจร แต่ก็นับว่าเป็นจุดเริ่มต้นที่ดี คราวนี้เราจะแบ่งงานให้กับทีมที่มีพนักงาน ที่ปรึกษา และ contractor จำนวนหลักร้อยอย่างไร ผมคงขอยกไปเล่ารายละเอียดในตอนต่อไป สำหรับตอนนี้ผมอยากจะสรุปขั้นตอนที่เป็น best practices คร่าวๆไว้เพื่อเป็นหัวข้ออธิบายในตอนต่อๆไปดังนี้
ระดับโครงการรวม
- แผนการจัดการโครงการรวม พูดถึงการแบ่งงาน ทรัพยากรที่ใช้ รวมถึงการแบ่งทีม และการวางแผนเวลา
- กำหนด Weekly sprint update ที่กำหนดเวลาไม่เกินสี่สิบห้านาทีทุกอาทิตย์ เพื่อให้ทุกคนเข้าประชุมฟังความคืบหน้าของทุกทีม และ/หรือ พูดถึงปัญหาที่ทีมใดๆมี เผื่อทีมอื่นๆจะสามารถช่วยเหลือได้
- ใช้ Gantt chart ในการวางแผน และติดตามความคืบหน้าของแต่ละทีม ใช้ Burn up chart และตารางแผนงานที่แต่ละทีมวางแผนจะทำในแต่ละสัปดาห์และผลงานในอาทิตย์ที่ผ่านมา
- บริหารโครงการโดยลดขั้นตอนที่ไม่จำเป็นออกให้มากที่สุด รวมไปถึงตัดสินใจกล้าที่จะตัดฟีเจอร์ที่ไม่สำคัญออกหรือที่สำคัญน้อยกว่าเลื่อนไปอยู่ในเวอร์ชั่นถัดไป
ระดับทีม
1. กำหนดบทบาทภายในทีม โดยมีผู้บริหารโครงการ เป็นผู้ประสานงานภายในทีม และระหว่างทีม นักวิเคราะห์ที่ติดต่อกับผู้ใช้ระบบและเป็นตัวแทนลูกค้า นักพัฒนาที่เป็นคนพัฒนาซอฟท์แวร์ และนักทดสอบที่ควบคุมคุณภาพของผลงานให้อยู่ในระดับที่ต้องการ โดยคนๆหนึ่งอาจสวมบทบาทมากกว่าหนึ่งก็ได้ ขึ้นอยู่กับขนาดของทีม ภายในแต่ละบทบาทที่มีมากกว่าหนึ่งคน ก็จะมีการกำหนดผู้นำ ที่เป็นคนตัดสินใจและประสานงานกับผู้นำด้านนั้นของทีมอื่น
2. การประชุม Release Planning ซึ่งรายเดือนหรือน้อยกว่านั้น ตามแผนการกำหนดการ release
3. การประชุม Iteration Planning Meeting ประจำสัปดาห์ เพื่อวางแผนว่าอาทิตย์นี้จะทำ user story ไหนบ้าง และโหวตว่าแต่ละเรื่องจะใช้เวลาเท่าไร
4. การประชุม Stand up meeting ทุกเช้าที่ทุกคนต้องยืนประชุม เพื่อบังคับไม่ให้แต่ละคนคุยนาน โดยแต่ละคนจะรายงานความคืบหน้าสิ่งที่ตนทำในวันที่ผ่านมา ปัญหาที่ติดอยู่ และสิ่งที่จะทำในวันนี้
5. สำหรับทีมพัฒนา
5.1 ระบบรองรับ เช่น source version control, continuous integration tool, IDE, unit test, software metrics/analysis, bug tracking, instant messaging
5.2 การพัฒนาโดยใช้ user story card, pair programming, refactoring, test driven development และแต่ละ user story ต้องมีการทดสอบและรับรองโดยผู้ใช้หรือตัวแทนผู้ใช้
5.3 ใช้ฝาผนังให้เกิดประโยชน์ โดยการอัพเดทสถานะโครงการ ใครๆก็สามารถทราบความคืนหน้าของโครงการได้โดยการเดินมาอ่าน
6. การประชุม retrospective ทุกๆอาทิตย์เพื่อฟังความเห็นของทุกคนในทีมว่าในแต่ละอาทิตย์เห็นข้อดี ข้อที่ควรปรับปรุง และแนะนำสิ่งที่นำไปปฏิบัติได้
ที่มา http://www.thaidev.org/?p=64
Agile Software Development – Document Transcript
Agile Software Development: case of small team and small project
เกริ่น
แม้บทความนี้จะเขียนขึ้นเพื่อเสนอวิธีการพัฒนาซอฟต์แวร์ขนาดเล็กแบบ Agile แต่ผมต้องขอออกตัวก่อนว่าข้อเสนอส่วนใหญ่นั้นเกิดจากจากสังเคราะห์ข้อมูลที่ศึกษามาจากแหล่งต่างๆ ผมยังไม่ได้ทดลองวิธีการเหล่านี้ด้วยตัวเอง ดังนั้นความถูกต้องของข้อเสนอเหล่านี้ย่อมถูกจำกัดด้วยความคิดความเข้าใจไม่ใช่ประสบการณ์ตรง
อย่างไรก็ตามผมเองได้มีประสบการณ์การพัฒนาซอฟต์แวร์ที่แบบไม่ Agile มาพอสมควรและประสบปัญหาต่างๆ ที่เกิดจากความไม่ Agile นี้ สาเหตุใหญ่ที่ผมเขียนบทความนี้ขึ้นก็เพื่อเป็นสรุปแนวทางวิธีการพัฒนาซอฟต์แวร์สำหรับตัวเองในงานครั้งถัดๆ ไปเพื่อไม่ให้พบกับปัญหาเหล่านั้นอีก ดังนั้นหากข้อเสนอต่างๆ ในบทความนี้สามารถลดปัญหาในการพัฒนาซอฟต์แวร์ของผู้อ่านได้บ้างก็ถือว่าบทความนี้ได้ประสบความสำเร็จเกินจุดประสงค์ของมันแล้วครับ
ทำความรู้จัก Agility
การพัฒนาซอฟต์แวร์แบบ Agile เป็นแนวคิดเกิดขึ้นไม่นานนี้นั้นคือปี ค.ศ. 2001 หลังจากนั้นก็มีการให้คำอธิบายผ่านเว็บไซต์และหนังสือมากมาย แต่ความหมายของ Agility ที่ผมคิดว่าเป็นการสรุปความที่ดีและขอยกมาในที่นี้คือ
” The ability to move faster than those things that can harm your project…”
Agility คือความสามารถในการจัดการความเปลี่ยนแปลงก่อนนี้ความเปลี่ยนแปลงนั้นจะส่งผลเสียต่องานของเรานั้นเอง
เราสามารถสังเกตได้ว่าความเปลี่ยนแปลงในวงการพัฒนาซอฟต์แวร์นั้นเกิดขึ้นในหลายระดับพร้อมๆ กัน ตั้งแต่การเปลี่ยนแปลงที่เกิดขึ้นจากตัวเราเอง (แก้บั๊กโปรแกรม) จากผู้ใช้/ลูกค้า (เปลี่ยน Requirement) และจากโลกภายนอก (เปลี่ยน OS ภาษา เทคโนโลยีใหม่ๆ ทุกปี) ด้วยความถี่และความหลากหลายของความเปลี่ยนแปลงนี้เองเป็นเหตุผลหลักที่ทำให้การทำงานแบบ Agile มีความจำเป็นกับคนในวงการพัฒนาซอฟต์แวร์มากกว่าในวงการอื่นๆ
ตาราง SEQ ตาราง * ARABIC 1 เปรียบเทียบความเปลี่ยนแปลงในระดับต่างๆ ในแต่ละวงการ
ความเปลี่ยนแปลงจากผู้ทำงาน(ทำงานผิดพลาด บั๊ก)จากลูกค้า/ผู้ใช้(เปลี่ยนฟีเจอร์ / Requirement) จากโลกภายนอก(ความรู้ใหม่ ทักษะใหม่ๆ)การก่อสร้างX–การออกแบบกราฟฟิคXX-การพัฒนาซอฟต์แวร์XXX
เข้าสู่ Agility
ทีมที่จะสามารถทำงานแบบ Agile จำเป็นต้องมีจุดมุ่งหมายที่จะทำงานให้สำเร็จที่ตรงกันก่อน นั้นคือมีความกล้า ความกระตือรือร้น และเปิดกว้างที่จะรับความคิดใหม่ๆ มิฉะนั้นข้อปฏิบัติต่างๆ จะกลับสร้างความล้มเหลวมากขึ้น
และต่อไปนี้คือข้อเสนอต่างๆ ซึ่งออกแบบมาสำหรับทีมพัฒนาซอฟต์แวร์งานซีเนียร์โปรเจค (เป็นซอฟต์แวร์ขนาดเล็ก ทีมไม่เกิน 4 คน ระยะเวลางานไม่เกิน 1 ปี) อย่างไรก็ตาม ผมเชื่อว่าข้อเสนอเหล่านี้สามารถประยุกต์ใช้ในสถานการณ์อื่นๆ ได้
Release ถี่เดือนละครั้ง
การพัฒนาซอฟต์แวร์ให้สามารถออกเวอร์ชั่นที่ใช้งานได้ตั้งแต่เนิ่นๆ มีประโยชน์ในหลายๆ ด้าน
แก้ปัญหาการ Integration และ Deployment ได้ตั้งแต่ปัญหายังเล็ก เพราะการ release แต่ละรอบเป็นการตรวจสอบปัญหาดังกล่าว และทำให้เกิดความมั่นใจได้ว่าถ้าสุดท้ายมีปัญหาด้านการ Integration หรือ Deployment เรายังสามารถนำเอางานเวอร์ชั่นก่อนมาใช้ได้
ประสิทธิภาพด้านเวลา
การออกเวอร์ชั่นในแต่ละเวอร์ชั่นนั้นเราจะบังคับให้เราคัดทำแต่สิ่งที่สำคัญที่สุดในเวลาที่เหลือ
การแบ่งเวอร์ชั่นย่อยๆ ทำให้เรามองเห็นเป้าหมายที่อยู่ไม่ไกล และเกิดแรงผลักดันในการทำงานที่มองเห็นเป้าหมายใกล้ๆ
ประเมินผลงานได้บ่อย เพราะแต่ละรอบที่ release ความรู้ความเข้าใจในเกี่ยวกับโปรเจคเราจะเพิ่มขึ้นมากกว่าก่อนเริ่มงานที่ยังไม่เห็นภาพอยู่มาก เราสามารถนำความเข้าใจตรงนี้ไปใช้ในการออกแบบรายละเอียดหรือเพิ่ม/ลดความสำคัญในประเด็นต่างๆ (เช่น การเพิ่มประสิทธิภาพการจัดการหน่วยความจำและลดความเร็ว)
ความมั่นใจว่างานจะไม่เสียในตอนสุดท้ายในตอน Deployment และการเห็นงานค่อยๆ ก้าวหน้าขึ้นทุกๆ เดือนจะทำให้เราทำงานอย่างมีความสนุกมากขึ้น
สิ่งที่ควรทำเพื่อให้สามารถ release ได้อย่างสะดวกมากขึ้นคือการทำ automation installer เพื่อให้ทดสอบการ deployment ได้อย่างรวดเร็ว
Design แค่ภาพรวมเพื่ออ่านกันเอง
การออกแบบสิ่งที่ไม่ทำไม่ได้ เพราะการพิจารณาเปรียบเทียบข้อดีข้อเสียของโครงสร้างของระบบและความสัมพันธ์ระหว่างส่วนย่อยของระบบนั้น จะทำให้เราเกิดความเข้าใจในงานของเรามากขึ้น
แต่ถ้าเราออกแบบไปถึงรายละเอียด Method, data type, parameters หรือลำดับการทำงานต่างๆ ที่แน่ชัด เราจะพบว่าสิ่งที่ออกแบบไว้ยังดีไม่พอเมื่อเขียนโค้ดจริงไปถึงส่วนที่ออกแบบไว้ เพราะเมื่อได้เขียนโค้ดเราจะมีความเข้าใจในงานมากขึ้นมาก โดยเฉพาะในงานที่ใช้เทคโนโลยีที่ยังไม่คุ้นเคยมาก่อน เราจึงไม่ควรเสียเวลาออกแบบอย่างละเอียดหรือทำเอกสารที่เป็นทางการไปกว่าเขียนคร่าวๆ ลงกระดาษหรือไวท์บอร์ดตั้งแต่เริ่มต้นงาน
การออกแบบที่ควรมีลักษณะดังนี้
กำหนดเพียงทิศทางในการพัฒนา เช่น พิจารณา Class ที่น่าจะมีและระบุชื่อ หน้าที่ และความสัมพันธ์กับ Class อื่นในงานต่างๆ
Reversibility นั้นคือสามารถแก้ปรับเปลี่ยนส่วนต่างๆ ในภายหลังได้โดยกระทบต่อระบบอื่นๆ เพียงเล็กน้อย
Simple นั้นคือไม่ทำงานอะไรเกินจากสิ่งที่จำเป็น เพื่อใช้เวลาอย่างมีประสิทธิภาพ
เขียน Test
นักพัฒนาซอฟต์แวร์จำนวนมากปฏิเสธการเขียน Test ด้วยเหตุผลต่างๆ แต่ที่จริงแล้วการ Test ไม่ว่าจะเขียนก่อนหรือหลังการโปรแกรม นั้นมีผลต่อความสำเร็จในหลายๆ ด้าน ได้แก่
เพิ่มคุณภาพ Code
ช่วยลดบั๊กในโปรแกรม เป็นผลโดยตรง
เราสามารถ refactor code ได้โดยไม่เสียเวลาตรวจสอบบั๊กเอง
แก้บั๊กได้เร็วขึ้น เพราะมี Test คอยบอกอาการ
เพิ่มคุณภาพ Design
ถ้าเราเขียน Design ก่อน Test เมื่อพบว่า method ใด Test ลำบากแสดงว่า method นั้นซับซ้อนเกินไป
ถ้าเราเขียน Test ก่อน Design เรามักจะ Design ได้งานที่ไม่ซับซ้อนเกินการใช้งานจริง (เหมือนที่การออกแบบโดยเริ่มด้วยออฟเจคมักจะเป็น)
เพิ่มคุณภาพ Document เพราะ Test ที่ดีจะสื่อถึงการทำงานของ method นั้นอย่างครอบคลุมเราสามารถเอา ข้อมูล Test ไปทำเอกสารได้ดี
เครื่องมือในการเขียน Test ในมีอยู่ในเกือบทุกภาษาให้เลือกใช้ เครื่องมือหลักที่ใช้ Test ได้แก่ Unit Test ใช้ Test ส่วนที่ไม่มี side-effect หรือไม่เกี่ยวข้องกับส่วนอื่นๆ และเขียน Mock เพื่อ Test ส่วนที่จำเป็นต้องติดต่อกับส่วนอื่นๆ
การเขียน Test ทำให้เราทราบปัญหาและเข้าไปแก้ได้เร็วขึ้นมาก ตั้งแต่ตอนเขียน Test เสร็จและหรือตอน refactor ในภายหลัง และยังเกิดผลพลอยได้ที่คำคัญทั้งในด้าน design และ documentation
เขียน Code ให้เอาไปใช้ต่อง่าย
โปรแกรมแต่ละส่วนที่เราเขียนหนึ่งครั้ง จะถูกอ่านต่อหลายต่อหลายครั้ง โดยเฉพาะเวลาทำงานเป็นทีม การลงทุนให้เวลากับการ Coding ให้สะอาดและสวยงามหนึ่งครั้งจึงคุ้มค่าเมื่อเทียบกับผลที่สามารถเพิ่มประสิทธิภาพในการ maintain code ได้เป็นอย่างดี ซึ่งหลักการเขียน Code โดยย่อมีดังนี้
อ่านง่าย
code ให้เข้าใจว่าโปรแกรมส่วนนี้ “ทำอะไร” ได้เองโดยไม่ต้องอ่าน comment
comment ให้เข้าใจว่าโปรแกรมส่วนนี้ “มีเพื่ออะไร” (ในหลายๆ แพลตฟอร์มเราสามารถทำ documentation จาก comment ได้อัติโนมัติ เช่น .NET ใช่ nDoc Java ใช้ Javadoc)
ใช้ enum
ไม่ quick hack ให้โปรแกรมทำงานได้โดย +1 -1 โดยผู้อ่านไม่สามารถเข้าใจได้
ไม่พยายามเขียนให้ดูฉลาดหรือเน้นด้านประสิทธิภาพเกินไปจนอ่านได้ยาก
Test ง่าย
แยกส่วนที่เป็น query(ส่วนที่ให้สถานะของออปเจค) ออกจาก command(ส่วนที่เปลี่ยนแปลงสถานะของออปเจค) และ query จะต้องไม่มี side-effect กับส่วนอื่น ทำให้ Test ง่าย
เขียน Class ที่เล็กไม่ซับซ้อนหรือรับหน้าที่หลายอย่าง method แต่ละ method ควรทำงานแค่อย่างเดียวในระดับของ abstraction นั้นๆ
Debug ง่าย
Handle หรือ propagate exception ให้ครอบคลุม (ไม่ทำการ catch ว่างเปล่าทิ้งไว้)
ใส่ error message ที่เป็นประโยชน์เอาไว้ใน exception เพื่อทราบสาเหตุของปัญหาอย่างรวดเร็ว
เราอาจแยกประเภทของ error message เพื่อให้ทราบวิธีรับมือกับปัญหาที่เกิดขึ้น ได้แก่
Program defects ผู้พัฒนาต้องกลับไปแก้โปรแกรมเท่านั้น
Environment problems ผู้ดูแลระบบสามารถแก้ไขได้
User Error ไม่ต้องแก้ไขใดๆ ผู้ใช้เพียงใส่ค่าใหม่ในรูปแบบที่ถูกต้อง
ข้อปฏิบัติเหล่าจะช่วยเพิ่มประสิทธิภาพในการ maintain โปรแกรม และทำให้ไม่เกิดปรากฏการณ์ที่ทุกคนคุ้นเคย นั้นคือ “แก้ยังไงก็ได้ อย่าเข้าไปแตะ class/method นั้น”
ตามทันความเปลี่ยนแปลงด้วยการสื่อสาร
ในการพัฒนาซอฟต์แวร์แบบที่ไม่ Agile ใช้ลงทุนในการทำ documentation ที่สมบูรณ์ตั้งแต่ต้นเพื่อใช้เป็นเครื่องมือสื่อสารในการทำงานให้ตรงกันในทีม แต่เราจะเห็นได้ว่าการออกแผนงานที่ละเอียดเกินไปตั้งแต่แรกมีโอกาสสูงที่จะพบว่าควรเปลี่ยนแผนเพื่อคุณภาพที่ดีขึ้นหรือแผนใช้ไม่ได้ จึงพัฒนาซอฟต์แวร์แบบ Agile จึงหลีกเลี่ยงการทำ documentation ที่ในอนาคตจะไม่ได้ใช้
ผลที่ตามมาคือเราจำเป็นต้องมีเทคนิคการสื่อสารแบบอื่นๆ ที่สามารถสร้างความเข้าใจให้ตรงกันได้เกี่ยวกับแผนงานและรายละเอียดของงานได้เหมือนเอกสาร ขณะที่มีความยืดหยุ่นสามารถเปลี่ยนแปลงได้ตลอดเวลา และมีประสิทธิภาพสูง
เทคนิคในการสื่อสารแบบ Agile เช่น
Stand up meeting คือการประชุมที่กำหนดให้เจอหน้ากันเป็นประจำ เช่น อาทิตย์ละ 2 ครั้ง โดยในที่ประชุมทุกคนจะต้องยืนเพื่อเป็นกลวิธีให้ทุกคนใช้เวลาพูดคุยอย่างมีประสิทธิภาพ โดยสิ่งที่ทุกคนต้องพูดคือการตอบคำถาม 3 ข้อคือ
ก่อนเข้าประชุมได้ทำอะไรไปบ้าง
จะทำอะไรให้บ้างก่อนประชุมครั้งต่อไป
การที่ทำมามีปัญหาอะไรเกิดขึ้นบ้าง
เวลาในการประชุมไม่เกินควรคนละ 3 นาที อย่างไรก็ตามสามารถนัดคุยเพิ่มเติมเพื่อข้อความช่วยเหลือหรือรายละเอียดหลัง stand up meeting ได้
Project Management Software โดยในที่นี้จะขอแนะนำ PivotalTrakcer เพราะเป็นเครื่องมือที่ออกแบบมาเมื่อการพัฒนาซอฟต์แวร์แบบ Agile มีข้อดีต่างๆ ดังนี้
สนับสนุนการ Design ให้เป็นสัดส่วนและเล็กด้วยการแบ่งงานเป็น user story
สนับสนุนให้ให้ความสำคัญกับงานที่เกิดประโยชน์จริงต่อผู้ใช้ ด้วยการไม่ให้แต้มการทำงานกับงานที่ไม่เกิดประโยชน์ต่อผู้ใช้ หรืองานแก้บั๊กของตัวเอง
สนับสนุนการ review code
สามารถประเมินความเร็วในการทำงานและช่วยแสดงแนวโน้มที่จะทำงานเสร็จทำกำหนดการ
รูป SEQ รูป * ARABIC 1 ตัวอย่างการใช้งานบน PivotalTracker
Mailing list เพื่อใช้ส่งประเด็นข้อมูลต่างๆ เพื่อให้สร้างความเข้าใจและใช้เป็นพื้นที่แชร์ความรู้ เช่น ส่ง CRC Design แบบใหม่ๆ ที่เขียนใส่กระดาษแล้วสแกนเข้ามา ส่งคำอธิบายหรือลิงค์วิธีการแก้ปัญหาที่คนในทีมต้องการ
Message ใน version control เป็นสิ่งที่ควรทำอยู่แล้ว
เราใช้ Stand up meeting เพื่อสื่อสารเรื่องความคืบหน้าของงานและคนในทีมในปัจจุบัน ใช้ PivotalTracker เพื่อสื่อสารภาพรวมของความคืบหน้าตั้งแต่อดีตจนถึงอนาคต และใช้ mailing list เพื่อสื่อสารแนวคิดความรู้ความเข้าใจเกี่ยวกับงานที่ค่อยๆ วิวัฒนาการตามการทำงานของเราไป
สรุป
ผมหวังว่าบทความนี้จะช่วยทำให้การพัฒนาซอฟต์แวร์ของทีมขนาดเล็กที่พัฒนาซอฟต์แวร์ขนาดเล็กมีประสิทธิภาพที่ดีขึ้นหลังจากนำเอาข้อเสนอต่างๆ ไปปฏับัติ และหวังว่าจะช่วยกระตุ้นความสนใจเกี่ยวกับการพัฒนาซอฟต์แวร์แบบ Agile ให้กับทุกๆ คนด้วย
เทคนิคการพัฒนาซอฟต์แวร์แบบ Agile นั้นยังมีอยู่อีกมาก ที่ไม่ได้กล่าวถึงในบทความนี้ เช่น เทคนิคสร้างบรรยากาศการทำงานให้เหมาะกับการทำงานแบบ Agile, เทคนิคการตามให้ทันเทคโนโลยีที่เปลี่ยนแปลงอย่างรวดเร็ว, วิธีการรับมือการกับการทำจริงกับลูกค้าที่มักเปลี่ยนแปลง requirement หรือการตรวจสอบโปรแกรมแบบ pair programming เป็นต้น เราสามารถคัดเลือกเอาวิธีการต่างๆ เหล่านี้มาประยุกต์ใช้ตามสภาพแวดล้อมที่ต่างกัน (ขนาดทีม ขนาดโปรเจค ลักษณะองค์กร) ได้อย่างเหมาะสมในรูปแบบที่ต่างๆ กันได้
