Soumettre la recherche
Mettre en ligne
Agile Software Development
•
Télécharger en tant que DOCX, PDF
•
5 j'aime
•
3,542 vues
Thatchaphol Saranurak
Suivre
Technologie
Signaler
Partager
Signaler
Partager
1 sur 14
Télécharger maintenant
Recommandé
Agile Process
Agile Process
Clipping Path Asia
Sw evo 2_model
Sw evo 2_model
Natural Stupidity
System Development Life Cycle
System Development Life Cycle
eiszer
การพัฒนาซอฟแวร์
การพัฒนาซอฟแวร์
karmpu
บทนำ วิศวกรรมซอฟต์แวร์
บทนำ วิศวกรรมซอฟต์แวร์
ฝ่ายวิชาการ วิชาการ
SDLC
SDLC
หนุ่มน้อย สามัญชน
การพัฒนา Software
การพัฒนา Software
Anussara Thathaisong
Software Engineering Process
Software Engineering Process
Worawut Ramchan
Recommandé
Agile Process
Agile Process
Clipping Path Asia
Sw evo 2_model
Sw evo 2_model
Natural Stupidity
System Development Life Cycle
System Development Life Cycle
eiszer
การพัฒนาซอฟแวร์
การพัฒนาซอฟแวร์
karmpu
บทนำ วิศวกรรมซอฟต์แวร์
บทนำ วิศวกรรมซอฟต์แวร์
ฝ่ายวิชาการ วิชาการ
SDLC
SDLC
หนุ่มน้อย สามัญชน
การพัฒนา Software
การพัฒนา Software
Anussara Thathaisong
Software Engineering Process
Software Engineering Process
Worawut Ramchan
Tools
Tools
Supattra Sansong
การพัฒนาซอฟแวร์
การพัฒนาซอฟแวร์
Watinee Poksup
การพัฒนา Software
การพัฒนา Software
Anussara Thathaisong
System Development Life Cycle S D L C
System Development Life Cycle S D L C
Kapook Moo Auan
Task004
Task004
Shine Onine
วงจรการพัฒนาโปรแกรม
วงจรการพัฒนาโปรแกรม
เซอร์เอส เวิ้นเว่อ
แนวทางการพัฒนาซอฟต์แวร์คุณภาพ
แนวทางการพัฒนาซอฟต์แวร์คุณภาพ
Rapeepan Thawornwanchai
The system-analysis-and-design
The system-analysis-and-design
tumetr
Activity 4
Activity 4
Saralee Kenhuad
กิจกรรมที่ 4 วงจรการพัฒนาโปรแกรม
กิจกรรมที่ 4 วงจรการพัฒนาโปรแกรม
draught
Software
Software
LittleBird Kaewkongpan
Sdlc
Sdlc
น้องหนุ่ม เกี๊ยวห่อไข่
Software
Software
LittleBird Kaewkongpan
System development life cycle sdlc
System development life cycle sdlc
Kapook Moo Auan
Activity4
Activity4
NuBaitong Promputta
5
5
pop Jaturong
วงจรการพัฒนาโปรแกรม
วงจรการพัฒนาโปรแกรม
draught
Presentation1
Presentation1
LumpEr Laurie
Activity4_naka
Activity4_naka
NuBaitong Promputta
Activity4
Activity4
NuBaitong Promputta
The Heart Of Agile
The Heart Of Agile
Kulawat Wongsaroj
Jump start a new agile project with Eidos
Jump start a new agile project with Eidos
Kulawat Wongsaroj
Contenu connexe
Tendances
Tools
Tools
Supattra Sansong
การพัฒนาซอฟแวร์
การพัฒนาซอฟแวร์
Watinee Poksup
การพัฒนา Software
การพัฒนา Software
Anussara Thathaisong
System Development Life Cycle S D L C
System Development Life Cycle S D L C
Kapook Moo Auan
Task004
Task004
Shine Onine
วงจรการพัฒนาโปรแกรม
วงจรการพัฒนาโปรแกรม
เซอร์เอส เวิ้นเว่อ
แนวทางการพัฒนาซอฟต์แวร์คุณภาพ
แนวทางการพัฒนาซอฟต์แวร์คุณภาพ
Rapeepan Thawornwanchai
The system-analysis-and-design
The system-analysis-and-design
tumetr
Activity 4
Activity 4
Saralee Kenhuad
กิจกรรมที่ 4 วงจรการพัฒนาโปรแกรม
กิจกรรมที่ 4 วงจรการพัฒนาโปรแกรม
draught
Software
Software
LittleBird Kaewkongpan
Sdlc
Sdlc
น้องหนุ่ม เกี๊ยวห่อไข่
Software
Software
LittleBird Kaewkongpan
System development life cycle sdlc
System development life cycle sdlc
Kapook Moo Auan
Activity4
Activity4
NuBaitong Promputta
5
5
pop Jaturong
วงจรการพัฒนาโปรแกรม
วงจรการพัฒนาโปรแกรม
draught
Presentation1
Presentation1
LumpEr Laurie
Activity4_naka
Activity4_naka
NuBaitong Promputta
Activity4
Activity4
NuBaitong Promputta
Tendances
(20)
Tools
Tools
การพัฒนาซอฟแวร์
การพัฒนาซอฟแวร์
การพัฒนา Software
การพัฒนา Software
System Development Life Cycle S D L C
System Development Life Cycle S D L C
Task004
Task004
วงจรการพัฒนาโปรแกรม
วงจรการพัฒนาโปรแกรม
แนวทางการพัฒนาซอฟต์แวร์คุณภาพ
แนวทางการพัฒนาซอฟต์แวร์คุณภาพ
The system-analysis-and-design
The system-analysis-and-design
Activity 4
Activity 4
กิจกรรมที่ 4 วงจรการพัฒนาโปรแกรม
กิจกรรมที่ 4 วงจรการพัฒนาโปรแกรม
Software
Software
Sdlc
Sdlc
Software
Software
System development life cycle sdlc
System development life cycle sdlc
Activity4
Activity4
5
5
วงจรการพัฒนาโปรแกรม
วงจรการพัฒนาโปรแกรม
Presentation1
Presentation1
Activity4_naka
Activity4_naka
Activity4
Activity4
En vedette
The Heart Of Agile
The Heart Of Agile
Kulawat Wongsaroj
Jump start a new agile project with Eidos
Jump start a new agile project with Eidos
Kulawat Wongsaroj
Confession of an Agile Addict
Confession of an Agile Addict
Kulawat Wongsaroj
กระบวนการออกแบบรายละเอียดซอฟต์แวร์
กระบวนการออกแบบรายละเอียดซอฟต์แวร์
Sitdhibong Laokok
Agile User Experience
Agile User Experience
ACM
Agile modeling
Agile modeling
Fahmi Hamdani
Dynamic System Development Method
Dynamic System Development Method
Baguio Central University
อไจล์คืออัลไล Agile Introduction @Mahidol ICT
อไจล์คืออัลไล Agile Introduction @Mahidol ICT
Kulawat Wongsaroj
Kanban @ Agile Thailand 2012
Kanban @ Agile Thailand 2012
Kulawat Wongsaroj
SA Chapter 3
SA Chapter 3
Nuth Otanasap
How to เสร็จเร็ว (Use Agile for your project with team)
How to เสร็จเร็ว (Use Agile for your project with team)
Jirayut Nimsaeng
DSDM
DSDM
Bilal Shah
En vedette
(12)
The Heart Of Agile
The Heart Of Agile
Jump start a new agile project with Eidos
Jump start a new agile project with Eidos
Confession of an Agile Addict
Confession of an Agile Addict
กระบวนการออกแบบรายละเอียดซอฟต์แวร์
กระบวนการออกแบบรายละเอียดซอฟต์แวร์
Agile User Experience
Agile User Experience
Agile modeling
Agile modeling
Dynamic System Development Method
Dynamic System Development Method
อไจล์คืออัลไล Agile Introduction @Mahidol ICT
อไจล์คืออัลไล Agile Introduction @Mahidol ICT
Kanban @ Agile Thailand 2012
Kanban @ Agile Thailand 2012
SA Chapter 3
SA Chapter 3
How to เสร็จเร็ว (Use Agile for your project with team)
How to เสร็จเร็ว (Use Agile for your project with team)
DSDM
DSDM
Similaire à Agile Software Development
P ort80 bkk-codeigniter
P ort80 bkk-codeigniter
Somkiat Puisungnoen
โปรแกรม Net beans
โปรแกรม Net beans
BoOm mm
การพัฒนาซอฟแวร์
การพัฒนาซอฟแวร์
karmpu
Lazy Dev Helper 2004
Lazy Dev Helper 2004
Thanarak Kaoram
การเขียนโปรแกรมด้วยVb 6.0
การเขียนโปรแกรมด้วยVb 6.0
ณัฐพล บัวพันธ์
THPHP => Agile testing
THPHP => Agile testing
Somkiat Puisungnoen
Introduction Software Factory v1.1
Introduction Software Factory v1.1
Lek Pongpatimet
Netbeans and Android Appliation
Netbeans and Android Appliation
Sedthawoot Pitapo
Gor8
Gor8
LiftzaNg Kab
Netbeans
Netbeans
Tay Atcharawan
Lesson1 programing concept
Lesson1 programing concept
skiats
การเขียนโปรแกรมด้วย Net beans
การเขียนโปรแกรมด้วย Net beans
Apisit Song
Lesson 4 (misson)2
Lesson 4 (misson)2
จงฉีกกระชาก อาชิโซกิจิโซ
Lesson 4 (misson)2
Lesson 4 (misson)2
จงฉีกกระชาก อาชิโซกิจิโซ
Lesson 4 (misson)
Lesson 4 (misson)
จงฉีกกระชาก อาชิโซกิจิโซ
ใบงานที่ 5 เฟินสวย
ใบงานที่ 5 เฟินสวย
ValenKung
Activity4
Activity4
NuBaitong Promputta
ใบงานที่ 3 เรื่อง ขอบข่ายและประเภทของโครงงาน
ใบงานที่ 3 เรื่อง ขอบข่ายและประเภทของโครงงาน
Moomy Momay
J2 ee คืออะไร
J2 ee คืออะไร
pasinee lungprasert
Jenkins, Git, MSBuild, NUnit
Jenkins, Git, MSBuild, NUnit
Tinnapat Buaruang
Similaire à Agile Software Development
(20)
P ort80 bkk-codeigniter
P ort80 bkk-codeigniter
โปรแกรม Net beans
โปรแกรม Net beans
การพัฒนาซอฟแวร์
การพัฒนาซอฟแวร์
Lazy Dev Helper 2004
Lazy Dev Helper 2004
การเขียนโปรแกรมด้วยVb 6.0
การเขียนโปรแกรมด้วยVb 6.0
THPHP => Agile testing
THPHP => Agile testing
Introduction Software Factory v1.1
Introduction Software Factory v1.1
Netbeans and Android Appliation
Netbeans and Android Appliation
Gor8
Gor8
Netbeans
Netbeans
Lesson1 programing concept
Lesson1 programing concept
การเขียนโปรแกรมด้วย Net beans
การเขียนโปรแกรมด้วย Net beans
Lesson 4 (misson)2
Lesson 4 (misson)2
Lesson 4 (misson)2
Lesson 4 (misson)2
Lesson 4 (misson)
Lesson 4 (misson)
ใบงานที่ 5 เฟินสวย
ใบงานที่ 5 เฟินสวย
Activity4
Activity4
ใบงานที่ 3 เรื่อง ขอบข่ายและประเภทของโครงงาน
ใบงานที่ 3 เรื่อง ขอบข่ายและประเภทของโครงงาน
J2 ee คืออะไร
J2 ee คืออะไร
Jenkins, Git, MSBuild, NUnit
Jenkins, Git, MSBuild, NUnit
Plus de Thatchaphol Saranurak
Computer Science in Saarland
Computer Science in Saarland
Thatchaphol Saranurak
Max flows via electrical flows (long talk)
Max flows via electrical flows (long talk)
Thatchaphol Saranurak
เรียนต่อเยอรมนีที่ Saarland University
เรียนต่อเยอรมนีที่ Saarland University
Thatchaphol Saranurak
Summary of "A Universally-Truthful Approximation Scheme for Multi-unit Auction"
Summary of "A Universally-Truthful Approximation Scheme for Multi-unit Auction"
Thatchaphol Saranurak
A Universally-Truthful Approximation Scheme for Multi-unit Auction
A Universally-Truthful Approximation Scheme for Multi-unit Auction
Thatchaphol Saranurak
แข่งเขียนโปรแกรม
แข่งเขียนโปรแกรม
Thatchaphol Saranurak
Agile Practices
Agile Practices
Thatchaphol Saranurak
No-Mouse Word Processor
No-Mouse Word Processor
Thatchaphol Saranurak
Augmented Reality -- very brief
Augmented Reality -- very brief
Thatchaphol Saranurak
Plus de Thatchaphol Saranurak
(9)
Computer Science in Saarland
Computer Science in Saarland
Max flows via electrical flows (long talk)
Max flows via electrical flows (long talk)
เรียนต่อเยอรมนีที่ Saarland University
เรียนต่อเยอรมนีที่ Saarland University
Summary of "A Universally-Truthful Approximation Scheme for Multi-unit Auction"
Summary of "A Universally-Truthful Approximation Scheme for Multi-unit Auction"
A Universally-Truthful Approximation Scheme for Multi-unit Auction
A Universally-Truthful Approximation Scheme for Multi-unit Auction
แข่งเขียนโปรแกรม
แข่งเขียนโปรแกรม
Agile Practices
Agile Practices
No-Mouse Word Processor
No-Mouse Word Processor
Augmented Reality -- very brief
Augmented Reality -- very brief
Agile Software Development
1.
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
Télécharger maintenant