r10 - 05 May 2012 - 16:31:58 - WeerachaiChansudYou are here: SETEC Wiki >  Knowledge Web  > SoftwareEngineeringCategory > Agile
-- CharinyaKlakhang - 13 Oct 2006

Agile

ที่มา : สรุปมาจากหลักสูตรอบรม Software Development Life Cycle with Agile Modeling

สรุปโดย : ชรินทร์ญา กล้าแข็ง

เนื้อหา

Agile เป็นแนวคิดใหม่สำหรับการพัฒนาซอฟต์แวร์ ที่พยายามที่จะแทรกตัวเข้าไปใน methodology แบบเดิม เพื่อให้งานสั้นลง

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 มาจัดลำดับความสำคัญ ดูว่ากิจกรรมไหน ควรทำ ไม่ควรทำ

amEnhance.png

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 มาใช้ให้ถูกต้อง
    • 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 (อย่างเป็นทางการ)

contract.png
A เรียกใช้ B เพื่อจับบริการที่ B มีให้ , A ต้องรู้ว่า B มีอะไรให้ใช้ และใช้แล้วได้อะไร แบบนี้เป็น contract ระหว่าง A-B เช่น การถอนเงิน A (client), B (บัญชีเงินฝาก)
  1. Pre Condition (เขียนเงื่อนไขที่เป็นจริง ก่อนไปใช้บริการ)
    • WDAmount <= -100
  2. Post condition (เงื่อนไขใดๆ เมื่อไปเรียกใช้บริการแล้ว มีอะไรที่เป็นจริงบ้าง) New Balance =
    • Balance – WDAmount
  3. Invariant (เงื่อนไขใดๆ ที่จะต้องเป็นจริง ตลอดเวลา ในขณะที่ B ทำงานอยู่)
    • 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

รูปแบบวิธีการที่นำเอา 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 เป็นมาตรฐาน

toggleopenShow attachmentstogglecloseHide attachments
Topic attachments
I Attachment Action Size Date Who Comment
pngpng amEnhance.png manage 19.4 K 13 Oct 2006 - 08:40 CharinyaKlakhang  
pngpng contract.png manage 1.0 K 13 Oct 2006 - 09:19 CharinyaKlakhang  
pdfpdf Agile_software_development.pdf manage 508.3 K 20 Jul 2007 - 17:40 CharinyaKlakhang  
Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r10 < r9 < r8 < r7 < r6 | More topic actions
MSTI.Agile moved from SoftwareTesting.Agile on 09 May 2006 - 05:19 by PatipatTumsangthong
 
Powered by SETEC Wiki
Copyright ©2014 by National Electronics and Computer Technology Center, NECTEC.
Ideas, requests, problems regarding SETEC Wiki? Send feedback