Agile ???????

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

แบบเดิมได้

o ให้ Agile เข้าไปกากับ ดูว่าของเดิมที่มีอยู่อันไหนสาคัญก็ทา

ไม่สาคัญก็ละ

o นา Agile มาจัดลาดับความสาคัญ ดูว่ากิจกรรมไหน ควรทา

ไม่ควรทา









AM Value (ผลลัพธ์)



 เน้นติดต่อสื่อสาร

 เน้นความง่าย ไม่ซับซ้อน

 เน้น feedback จากลูกค้า

 เน้นความกลัาตัดสินใจ

 เน้นความเคารพกันและกัน



AM Core Principle (หลักการ)



 ง่าย ไม่เวอร์เกิน

 รับ requirement พร้อมเปลี่ยนแปลงได้ตลอดเวลา

 เีน้นปัจจุบีนเป็นหลัก

 ทา model ตามความจาเป็นเท่านั้น

 พยายามใช้ multiple model มองหลายๆมุมมอง

 มีการตอบกลับเร็ว

 SW ถือเป็นจุดมุ่งหมายหลัก

 ให้แบกสัมภาระเบาๆ

 AM Supplement Principle

o เีน้น content มากกว่า representation(ที่ใช้ UML เขียน)



ไม่เน้นเครื่องมือ เน้นที่เน้อหาข้างใน

o ติดต่อกันอย่างเปิดเผย และตรงไปตรงมา







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

o ทาให้เป็นาตรฐาน



o ค่อยๆสร้างให้มีรูปแบบ เมื่อถึงเวลาค่อยใช้



o โมเดลไม่ใช้ ให้โยนทิ้งไปเลย



เพราะจะได้ไม่เสียเวลามาดูแล

o เน้น contract (สัญญาระหล่างระบบที่สัมพันธ์กันอยู่)



พยายามจัด contract ให้เป็นทางการ เช่น web service มี

signatureอะไรบ้างใน function call

o การ update code เฉพาะตอนที่มีปัญหา









 Note : Design By Contract (อย่างเป็นทางการ)

A เรียกใช้ B เพื่อจับบริการที่ B มีให้ , A ต้องรู้ว่า B มีอะไรให้ใช้

และใช้แล้วได้อะไร แบบนี้เป็น contract ระหว่าง A-B เช่น การถอนเงิน

A (client), B (บัญชีเงินฝาก)

1. Pre Condition (เขียนเงื่อนไขที่เป็นจริง ก่อนไปใช้บริการ)

o WDAmount = 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

o ตัวอย่างการเขียน







Test

Expected Actual

case Desc. Inputs Remark

Outputs Outputs

No.

ชื่อ

1. A=5,B=2 X=5 X=-5

pathname

ชื่อ

2. C=8 X=2 X=2

pathname



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



1. Agile UP

2. XP (eXtream Programming)

3. FDD (Feature Driven Development)

4. Scrum



Extreme Programming (XP)

อ่านเพิ่มเติมที่นี่

 XP เน้นความพึงพอใจเป็นหลัก

 ทีมงานทา XP ต้องมีทักษะในการทาด้านเทคนิค เพื่อพัฒนา

Software

 โปรเจคที่ทาไม่ควรใหญ่มาก และทีมงานที่ทาไม่ควรเกิน 10 คน

(ถ้างานเยอะ ลูกค้าหลายคน ทาให้ยุ่ง)

 งานต้องหั่นได้ ข้อดีคือ การทางานด้วย OO

ทาให้ระบบเชื่อมต่อกันได้ง่ายไร้รอยตะเข็บ



 ปัจจัยพื้นฐาน

o communication : เน้นเรื่องการพบปะพูดคุย (หลักการ



Agile)

o Simplicity : ออกแบบและเขียนโปรแกรมให้ง่าย ไม่เน้น



performance มากนัก เน้นเรื่องแก้

o Feedback : เน้นเรื่องลูกค้า feedback เราเปลียนได้เรื่อยๆ



โดยใช้ refactor

o 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

คร่าวๆไว้เพื่อเป็นหัวข้ออธิบายในตอนต่อๆไปดังนี้

ระดับโครงการรวม

1. แผนการจัดการโครงการรวม พูดถึงการแบ่งงาน ทรัพยากรที่ใช้

รวมถึงการแบ่งทีม และการวางแผนเวลา

2. กาหนด Weekly sprint update

ที่กาหนดเวลาไม่เกินสี่สิบห้านาทีทุกอาทิตย์

เพื่อให้ทุกคนเข้าประชุมฟังความคืบหน้าของทุกทีม และ/หรือ

พูดถึงปัญหาที่ทีมใดๆมี เผื่อทีมอื่นๆจะสามารถช่วยเหลือได้

3. ใช้ Gantt chart ในการวางแผน และติดตามความคืบหน้าของแต่ละทีม

ใช้ Burn up chart

และตารางแผนงานที่แต่ละทีมวางแผนจะทาในแต่ละสัปดาห์และผลงาน

ในอาทิตย์ที่ผ่านมา

4. บริหารโครงการโดยลดขั้นตอนที่ไม่จาเป็นออกให้มากที่สุด

รวมไปถึงตัดสินใจกล้าที่จะตัดฟีเจอร์ที่ไม่สาคัญออกหรือที่สาคัญน้อยก

ว่าเลื่อนไปอยู่ในเวอร์ชั่นถัดไป

ระดับทีม

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 เป็นต้น

เราสามารถคัดเลือกเอาวิธีการต่างๆ

เหล่านี้มาประยุกต์ใช้ตามสภาพแวดล้อมที่ต่างกัน (ขนาดทีม

ขนาดโปรเจค ลักษณะองค์กร) ได้อย่างเหมาะสมในรูปแบบที่ต่างๆ

กันได้

ธัชพล ษรานุรักษ์9 สิงหาคม 2552