บทที่ 4 กระบวนการอาไจล (An Agile View of Process)

บทที่ 4 กระบวนการอาไจล (An Agile View of Process)

บทที่ 4 กระบวนการอาไจล (AGLIE)
4.1 อะไรคืออาไจล 4.2 อะไรคือกระบวนการอาไจล 4.3 แบบจำลองกระบวนการอาไจล (Aglie Precess Models) 4.4 บทสรุปท้ายบท

แนวคิดที่สำคัญ (Key Concepts)
Agile manifesto คำแถลงการณ์อาไจล Agile modeling การสร้างแบบจำลองอาไจล Agile process models แบบจำลองกระบวนการอาไจล Agility ความคล่องตัว รวดเร็ว ปรับเปลี่ยนง่าย Agility principles หลักการอาไจล ASD เอ เอส ดี Crystal คริสตัล DSDM ดี เอส ดี เอ็ม Extreme programming เอ็กซ์ทรีมโปรแกรมมิ่ง FDD เอฟ ดี ดี Polities การเมือง Refactoring รีแฟคเตอริ่ง Scrum สครัม Team characteristics ลักษณะเฉพาะตัวของทีมงาน

ในปี ค.ศ กลุ่มพันธมิตรอาไจลที่ประกอบด้วย Kent Beck และผู้เชี่ยวชาญด้านการพัฒนาซอฟแวร์ที่มีชื่อเสียงอีก 16 ท่าน ได้ลงนามในคำแถลงการณ์เรื่องวิธีการพัฒนาซอฟต์แวร์แบบอาไจล เนื้อความของแถลงการณ์มีอยู่ว่า “ เราได้คนพบวิธีการพัฒนาซอฟท์แวร์ที่ดีกว่าเดิม โดยการปฏิบัติด้วยตนเองและช่วยผู้อื่นให้ปฏิบัติตามได้ ทำให้เราได้เห็นคุณค่าของสิ่งเหล่านี้คือ การให้ความสำคัญแก่แต่ละบุคคลและปฏิสัมพันธ์มากกว่ากระบวนการและเครื่องมือ การให้ความสำคัญแก่ซอฟต์แวร์ที่ทำงานได้จริง มากกกว่าเอกสารที่ละเอียดลออ การให้ความสำคัญแก่การทำงานร่วมกับลูกค้า มากกว่าการต่อรองตามสัญญา การให้ความสำคัญแก่การตอบสนองต่อการเปลี่ยนแปลง มากกว่าการปฏิบัติตามแผน นั่นคือที่ใดให้ความสำคัญแก่รายการด้านขวามือ เราจะให้ความสำคัญแก่รายการด้านซ้ายมือ ”

4.1 อะไรคืออาไจล วิศวกรรมซอฟต์แวร์อาไจล รวมเอาหลักการและชุดแนวทางการพัฒนาเข้าด้วยกัน หลักการมุ่งที่จะสร้างความพึงพอใจแก่ลูกค้าและสามารถส่งมอบซอฟต์แวร์แบบค่อยเพิ่มขึ้นแก่ลูกค้าโดยใช้ทีมงานขนาดเล็กที่กระตือรือร้น ใช้วิธีการแบบไม่เป็นทางการผลิตงานวิศวกรรมซอฟต์แวร์น้อยเท่าที่จำเป็น และใช้วิธีการพัฒนาที่เรียบง่าย ส่วนแนวทางการพัฒนาเน้นการส่งมอบมากกว่าการวิเคราะห์ออกแบบ (แต่ยังจำเป็นต้องวิเคราะห์ออกแบบอยู่) และการสื่อสารอย่างต่อเนื่องกับลูกค้า

4.1 อะไรคืออาไจล Ivar jacobsm ได้ให้ความเห็นที่เป็นประโยชน์เกี่ยวกับวิธีการอาไจล ดังนี้ “วิธีการอาไจล ได้กลายเป็นคำพูดที่นิยมพูดกันในการอธิบายกระบวนการซอฟต์แวร์สมัยใหม่ วิธีการทุกอย่างกลายเป็นแบบอาไจล ทีมอาไจลเป็นทีมเล็กๆ ที่สามารถตอบสนองต่อการเปลี่ยนแปลง การเปลี่ยนแปลงทุกๆ สิ่งของการพัฒนาซอฟต์แวร์ การเปลี่ยนแปลงของตัวซอฟต์แวร์ที่ถูกสร้างขึ้น การเปลี่ยนแปลงตัวทีมงาน การเปลี่ยนแปลงไปสู่เทคโนโลยีใหม่ๆ การเปลี่ยนแปลงทุกชนิดที่อาจมีผลต่อผลิตภัณฑ์หรือต่อโครงการที่สร้างผลิตภัณฑ์ควรจะต้องมีกลไกรอบรับการเปลี่ยนแปลงแบบฝังตัวในทุกสิ่งทุกอย่างที่เราทำกับซอฟต์แวร์ กลไกบางอย่างที่เป็นจิตวิญญาณของซอฟต์แวร์ ทีมงานอาไจลควรระลึกไว้ว่า ซอฟต์แวร์ถูกพัฒนาโดยบุคคลอิสระที่ทำงานในทีม ความเชี่ยวชาญของบุคคลเหล่านี้ รวมทั้งความร่วมมือ เป็นหัวใจหลักของความสำเร็จของโครงการ”

กฎ 12 ข้อ ของวิธีการอาไจล
ความสำคัญสูงสุดของเราคือ ทำให้ลูกค้าพอใจ ทั้งในระยะเริ่มต้นและการส่งมอบอย่างต่อเนื่องของซอฟต์แวร์ที่มีคุณค่า จงต้อนรับความต้องการที่เปลี่ยนไป แม้ว่าการพัฒนาจะดำเนินไปมากแล้ว อาไจลจะยอมรับการเปลี่ยนแปลงเพื่อประโยชน์ของลูกค้า ส่งมอบงานบ่อยๆ ตั้งแต่ทุก 2 สัปดาห์ ถึงทุกๆ 2 เดือน นักธุรกิจและนักพัฒนาระบบต้องทำงานร่วมกันทุกวันตลอดเวลาโครงการ ให้ใช้ผู้ที่มีแรงจูงใจในโครงการเตรียมการสนับสนุนและเตรียมสภาพแวดล้อมให้ตามที่คนเหล่านั้นต้องการและเชื่อมั่นว่าเขาจะทำงานได้สำเร็จ วิธีการที่ได้ผลดีที่สุดในการส่งผ่านข่าวสารคือการคุยกันต่อหน้า

กฎ 12 ข้อ ของวิธีการอาไจล
ซอฟต์แวร์ที่ทำงานได้เป็นตัววัดความก้าวหน้าที่สำคัญที่สุด กระบวนการอาไจลให้ความสำคัญกับการพัฒนาที่ยั่งยืน ผู้ให้ทุน ผู้พัฒนา และผู้ใช้งานควรจะร่วมมือกันสร้างความก้าวหน้าอย่างไม่หยุดยั้ง การใส่ใจในการออกแบบให้ดี และความเป็นเลิศทางเทคนิคอย่างสม่ำเสมอจะช่วยเสริมวิธีอาไจล ความเรียบง่าย ศิลปะของการลดงานที่ไม่จำเป็น เป็นเรื่องสำคัญยิ่งยวด สถาปัตยกรรม ความต้องการ และงานออกแบบที่ดีที่สุด เกิดขึ้นมาเองจากทีมงานที่มีการจัดระเบียบในตัวเอง ทีมงานมีความสามารถในการสะท้อนภาพตัวเอง ในเรื่องจะทำงานให้ได้ผลลัพธ์ที่ดีขึ้นอย่างไร และสามารถปรับตัวไปสู่พฤติกรรมที่นำไปสู่วิธีที่ดีขึ้นได้ โดยกระบวนการดังกล่าวควรเกิดขึ้นเป็นระยะๆ ตามปกติ

4.2 อะไรคือกระบวนการอาไจล
กระบวนการอาไจลจัดการกับโครงการซอฟต์แวร์ส่วนใหญ่ ที่มีข้อสมมติฐาน 3 ข้อ คือ เป็นเรื่องยากที่จะทำนายล่วงหน้าว่า ความต้องการซอฟต์แวร์ส่วนใดจะคงอยู่และส่วนใดจะเปลี่ยนแปลงไป ซอฟต์แวร์หลายๆ ประเภทการออกแบบและการก่อสร้างจะซ้อนทับกัน นั้นคือกิจกรรมทั้งสองควรจะทำร่วมกันไปเป็นจังหวะ ดังนั้น จึงเป็นเรื่องยากที่จะทำนายว่าควรออกแบบเท่าไรก่อนการก่อสร้างจะเริ่มต้นขึ้นได้ การวิเคราะห์ ออกแบบ ก่อสร้าง และทดสอบ มักจะไม่สามารถทำนายได้อย่างที่ต้องการจากมุมมองของการวางแผนงาน

4.2.1 การเมืองเรื่องการพัฒนาอาไจล
“วิธีการแบบอาไจลก็เป็นแค่กลุ่มแฮกเกอร์ ที่ต่อไปจะพบกับความแปลกใจเมื่อต้องขยายขนาดของระบบของเล่นให้ใช้งานได้จริงในระดับวิสาหกิจ” ฝ่ายสนับสนุนการพัฒนาแบบดั้งเดิม “วิธีการแบบดั้งเดิมเป็นเรื่องไม่มีสาระของผู้ที่ต้องการผลิตเอกสารอันไม่มีที่ติมากกว่าระบบที่ทำงานได้ตามความต้องการทางธุรกิจ” Jim Highsmith

4.2.1 การเมืองเรื่องการพัฒนาอาไจล
ได้มีการถกเถียงกันอย่างมากเกี่ยวกับประโยชน์และการประยุกต์ใช้งานพัฒนาแบบ อาไจลเปรียบเทียบกับวิศวกรรมซอฟต์แวร์แบบเดิม การโต้เถียงเหล่านี้มีความเสี่ยงที่จะกลายเป็นสงครามน้ำลาย และความมีเหตุผลจะหมดไป เหลือเพียงการเอาชนะกัน ดังนั้น จึงควรใช้ประโยชน์จากแนวคิดดีๆ ของทั้งสองค่ายจะดีกว่า

4.2.2 ปัจจัยบุคคล มีความสามารถ (Competence) รวมไปถึงความเฉลียวฉลาด มีสัญชาตญาณที่ดี มีความเชี่ยวชาญในซอฟต์แวร์ที่ต้องใช้และมีความรู้เกี่ยวกับกระบวนการที่ทีมงานได้เลือกใช้ มีเป้าหมายร่วมกัน (Common Focus) แม้ว่าสมาชิกแต่ละคนในทีมจะทำงานย่อยที่แตกต่างกัน และมีความเชี่ยวชาญแตกต่างกัน แต่ทุกคนควรมีเป้าหมายเดียวกัน ซึ่งช่วยให้กระบวนการเข้ากันได้กับความจำเป็นของทีมงาน มีความร่วมมือกัน (Collaboration) วิศวกรรมซอฟต์แวร์ไม่ว่าจะใช้กระบวนการใดก็ตามเป็นเรื่องเกี่ยวกับการประเมิน การวิเคราะห์ และการใช้ข่าวสารที่ได้สื่อสารกันภายในทีมงาน เพื่อบรรลุงานเหล่านี้ สมาชิกในทีมต้องร่วมมือกัน และร่วมมือกับลูกค้า และนักธุรกิจด้วย

4.2.2 ปัจจัยบุคคล มีความสามารถในการตัดสินใจ (Decision-marking Ability) ผู้จัดการจะต้องระลึกไว้เสมอกว่า ทีมอาไจลจะพบกับปัญหาความคลุมเครืออยู่เสมอ ปัญหาที่พบและแก้ไขได้ทุกวัน อาจจะเป็นประโยชน์กับทีมงานในภายหลังก็ได้ ความเชื่อใจและเคารพซึ่งกันและกัน (Mutual Trust and Respect) ทีมอาไจลต้องเป็นอันหนึ่งกันเดียวกัน ต้องแสดงออกด้วยความมั่นใจ เชื่อใจและเคารพกัน เพื่อให้ทีมกลายเป็น “กลุ่มที่แข็งแรง” มีการจัดระเบียบตนเอง (Self-organization) หมายถึง ทีมจัดระเบียบตนเองในงานที่ต้องทำให้เสร็จ ทีมจัดระเบียบกระบวนการเพื่อรองรับสิ่งแวดล้อมให้ดีที่สุด และทีมจัดระเบียบตารางงานเพื่อส่งมอบรุ่นของซอฟต์แวร์ได้สำเร็จอย่างดีที่สุด

4.3 แบบจำลองกระบวนการอาไจล
4.3.1 Extreme Programing – XP 4.3.2 Adaptive Software Development – ASD 4.3.3 Dynamic System Development Method - DSDM

4.3.1 Extreme Programing – XP
งานหลักๆ เป็นของ Kent Beck ที่เผยแพร่ต่อสาธารณะชนในปี 1999 งานถัดๆ มาโดย Jeffries และคณะเกี่ยวกับรายละเอียดของ XP งานเพิ่มเติมโดย Beck และ Fowler ในการวางแผน XP ช่วยเสริมรายละเอียดของวิธีการนี้

กระบวนการ Extreme Programing
Planning design coding test User stories value acceptance test criteria iteration plan Release Software increment Project velocity computed Simple design CRC cards Unit test Acceptance testing Spike solution prototypes refactoring Continuous integration Pair programing

การวางแผน กิจกรรมการวางแผนเริ่มต้นด้วยการสร้างชุดของเรื่องเล่า หรือเรื่องเล่าของผู้ใช้งาน (Story or User Stories) ที่อธิบายหน้าที่การทำงานและลักษณะของซอฟท์แวร์ที่ผู้ใช้ต้องการ ลูกค้ากำหนดคุณค่าหรือความสำคัญให้กับแต่ละเรื่อง จากนั้นทีม XP กำหนดและประเมินค่าใช้จ่าย (Cost) ในแต่ละเรื่อง ลูกค้าและทีม XP ร่วมกันตัดสินใจทำข้อตกลงพื้นฐาน (เรื่องที่จะทำ วันส่งมอบ และอื่นๆ)

การออกแบบ XP ทำการออกแบบตามหลัก KIS (Keep it simple) โดยออกแบบที่ธรรมดาก่อนออกแบบที่ซับซ้อน ถ้ามีปัญหาการออกแบที่ยากลำบากสำหรับเรื่องเล่าใด XP แนะนำให้สร้างต้นแบบที่ทำงานได้จริงของส่วนนั้นโดยทันที (Spike Solution) เพื่อลดความเสี่ยงเมื่อการ Implement เริ่มขึ้นจริงๆ งานออกแบบใน XP จะเกิดขึ้นทั้งก่อนและหลังการเขียน code เริ่มต้นขึ้น

การเขียน Code XP แนะนำว่าเมื่อมีเรื่องเล่าและงานออกแบบขั้นต้นแล้ว ไม่ควรเริ่มเขียน Code ในทันที แต่ควรพัฒนาชุดของตัวทดสอบระดับหน่วยที่จะทำงานกับเรื่องเล่าที่จะสร้างขึ้นก่อน เมื่อตัวทดสอบระดับหน่วยได้ถูกสร้างขึ้นแล้ว นักพัฒนาควรมุ่ง Implement ซอฟต์แวร์ให้ทำงานผ่านการทดสอบได้ แนวคิดสำคัญในการเขียน Code เป็นที่รู้จักกันดีกว่า เป็นการทำงานแบบ XP เรียกว่าการโปรแกรมเป็นคู่ (Pair Programing) XP แนะนำให้คนสองคนทำงานร่วมกันสำหรับการ Code เรื่องเล่าเรื่องหนึ่งๆ โดยนั่งทำบนคอมพิวเตอร์เครื่องเดียวกัน อันเป็นกลไกที่จะช่วยแก้ไขปัญหาเฉพาะหน้า และการควบคุมคุณภาพเฉพาะหน้า

การทดสอบ ตัวทดสอบระดับหน่วยเกิดขึ้นก่อนการเขียน Code ตัวทดสอบควร Implement ด้วยเครื่องมือที่ช่วยให้ทำงานได้โดยอัตโนมัติ เพื่อส่งเสริมกลยุทธ์การทดสอบเชิงถดถอย (Regression Testing) การทดสอบการยอมรับของ XP เรียกว่า การทดสอบของลูกค้าด้วย ตัวทดสอบกำหนดมาโดยลูกค้า และทดสอบหน้าที่การงานและลักษณะของระบบโดยรวมที่ลูกค้ามองเห็นได้

4.3.2 การพัฒนาซอฟท์แวร์ปรับตัว Adaptive Software Development (ASD)
Jim Highsmith เสนอให้ ASD เป็นเทคนิคสำหรับสร้างระบบที่ซับซ้อน ปรัชญาเบื้องหลัง ASD เน้นการทำงานร่วมกันระหว่างบุคคล และการจัดระเบียบทีมงานด้วยตนเอง “การจัดระเบียบตนเองเป็นคุณสมบัติของระบบปรับตัวที่ซับซ้อน คล้อยคลึงกับกลุ่มก้อนของโปรตีนที่ปล่อยพลังงานสร้างสรรค์ออกมา ในเวลาที่ได้ผลลัพธ์ในการแก้ไขปัญหาเฉพาะหน้า การจัดระเบียบตนเองเกิดขึ้นเมื่อเอเจนต์อิสระ เช่น เซลล์ในร่างกาย สปีชีส์ในระบบนิเวศ หรือนักพัฒนาระบบในทีมงาน ร่วมมือกันสร้างสรรค์ผลลัพธ์ผุดบังเกิด” Jim Highsmith

การพัฒนาซอฟต์แวร์แบบปรับตัว
speculation collaboration learning Adaptive cycle planning mission statement project constraints basic requirements time-boxed release plan Release Software increment adjustments for subsequent cycles Requirements gathering JAD mini-specs Components implemented/tested focus groups for feedback formal technical reviews postmortems

การคาดเดา (Speculation) ในช่วงการคาดเดา โครงการเริ่มต้นขึ้นและมีการทำแผนวงจรการปรับตัว โดยใช้ข้อมูลเบื้องต้น ได้แก่ข้อความแสดงภารกิจของลูกค้า เงื่อนไขต่างๆ ของโครงการและความต้องการพื้นฐานเพื่อกำหนดชุดของวงจรรีลีส คือ รุ่นต่างๆ ของซอฟต์แวร์ที่โครงการจะต้องผลิต

ความร่วมมือ (Collaboration) จูงใจบุคคลให้ทำงานร่วมกัน ในทางที่เพิ่มพูนผลลัพธ์ที่สร้างสรรค์และเฉลียวฉลาด บุคคลที่ทำงานด้วยกันต้องมีความไว้ใจกันเพื่อ 1. การวิพากษ์วิจารณ์โดยปราศจากความขมขื่น 2. การช่วยเหลือกันโดยปราศจากความเสียใจ 3. การทำงานอย่างหนักเท่าเทียมกัน 4. มีความชำนาญเฉพาะที่จะเป็นประโยชน์ต่องานที่ทำ 5. มีการพูดคุยถึงปัญหาหรือข้อกังวลสงสัยในทางที่ไปสู่กระทำที่ได้ประสิทธิผล

การเรียนรู้ (Learning) ทีม ASD เรียนรู้ได้ 3 วิธี คือ 1. กลุ่มเฉพาะทาง (Focus group) เมื่อลูกค้า/ผู้ใช้งานให้ผลตอบกลับในการใช้งานของซอฟต์แวร์ที่มอบไป สิ่งนี้จะเป็นตัวบ่งชี้ว่าผลิตภัณฑ์ได้ตอบสนองความจำเป็นทางธุรกิจหรือไม่ 2. การทบทวนเทคนิคอย่างเป็นทางการ (Formal Technical Review) ทีม ASD มีการทบทวนซอฟต์แวร์ที่กำลังพัฒนาอยู่ ขณะเดียวกันมีการปรับปรุงคุณภาพและเรียนรู้ไปพร้อมๆ กัน 3. การตรวจสอบภายหลัง (Postmortems)

4.3.3 วิธีการพัฒนาระบบไม่หยุดนิ่ง Dynamic Systems Development Method (DSDM)
วิธีการพัฒนาระบบไม่หยุดนิ่ง (DSDM) เป็นวิธีการพัฒนาซอฟต์แวร์อาไจล “มีการกำหนดกรอบงานสำหรับสร้างและบำรุงรักษาระบบที่มีข้อจำกัดด้านเวลา โดยใช้การสร้างต้นแบบอย่างค่อยเพิ่มขึ้นในสิ่งแวดล้อมที่มีการควบคุม” DSDM เป็นกระบวนการวนซ้ำเช่นเดียวกับ XP และ ASD แต่ว่าแต่ละรอบของวงจร DSDM จะเป็นไปตามกฎ 80% คือทำงานให้เพียงพอเท่าที่จำเป็นในแต่ละรุ่น เพื่อให้เคลื่อนไปสู้รุ่นที่เพิ่มขึ้นถัดไป ส่วนรายละเอียดที่เหลือสามารถทำให้เสร็จได้ภายหลัง เมื่อได้รับการร้องขอให้มีการเปลี่ยนแปลง

การศึกษาความเป็นไปได้ (Feasibility Study) จัดทำความต้องการและข้อจำกัดทางธุรกิจพื้นฐานของแอพพลิเคชั่นที่จะสร้าง ประเมินว่าแอพพลิเคชั่นมีความเป็นไปได้ สำหรับกระบวนการ DSDM หรือไม่

การศึกษาด้านธุรกิจ (Business Study) จัดสร้างความต้องการเชิงข่าวสารและเชิงหน้าที่ของแอพพลิเคชั่น นิยามสถาปัตยกรรมและระบุความต้องการในการบำรุงรักษาแอพพลิเคชั่น

การทำวนซ้ำแบบจำลองเชิงหน้าที่ (Functional Model Iteration) นำต้นแบบที่สร้างขึ้นระหว่างการทำวนซ้ำการสร้างแบบจำลองเชิงหน้าที่มาดูใหม่ เพื่อให้มั่นใจว่าแต่ละตัวมีลักษณะที่ทำงานตามที่ธุรกิจสำหรับผู้ใช้งานสุดท้ายได้จริง

การอิมพลีเม้นต์ (Implemetation) ใช้งานรุ่นของซอฟต์แวร์ล่าสุดภายใต้สิ่งแวดล้อมการทำงานจริง 1. รุ่นของซอฟต์แวร์อาจไม่ต้องสมบูรณ์ร้อยเปอร์เซ็นต์ หรือ 2. การร้องขอการเปลี่ยนแปลงอาจเกิดขึ้นได้ขณะใช้งานอยู่ ในกรณีใดกรณีหนึ่งานพัฒนา DSDM จะดำเนินต่อเนื่องไป โดยย้อนกลับไปทำกิจกรรมการทำวนซ้ำแบบจำลองเชิงหน้าที่

DSDM อาจใช้ร่วมกับ XP เพื่อกำหนดแบบจำลองกระบวนการที่เป็นรูปเป็นร่างคือวงจรชีวิต DSDM บวกกับกลไกการปฏิบัติของ XP ในการสร้างรุ่นซอฟต์แวร์แบบค่อยเพิ่มขึ้น นอกจากนี้ แนวคิด ASD ในการร่วมมือกันและทีมจัดระเบียบตนเอง ก็อาจประยุกต์ใช้กับกระบวนการนี้ได้เช่นกัน

4.3.4 สครัม (Scrum) Scrum มาจากกิจกรรมที่เกิดขึ้นในการแข่งขันรักบี้ Scrum เป็นกระบวนการอาไจลที่พัฒนาโดย Jeff Sutheland ในช่วงต้นทศวรรษ 1990 การพัฒนา Scrum ได้ทำโดย Schwaber และ Beedle หลักการของ Scrum เข้ากันได้กับคำแถลงการณ์อาไจล จัดตั้งทีมงานขนาดเล็กที่ “เกิดการสื่อสาร การแบ่งปันเทคนิค และข่าวสารที่ไม่เป็นทางการให้มากที่สุด ขณะที่ลดค่าใช้จ่ายส่วนเกินให้น้อยที่สุด” กระบวนการต้องสามารถปรับเข้ากับการเปลี่ยนแปลงทางธุรกิจและเทคนิคได้ เพื่อผลิตผลงานให้ดีที่สุด กระบวนการต้องผลิตรุ่นซอฟต์แวร์ออกมาบ่อยๆ เพื่อตรวจสอบ ปรับแต่ง ทดสอบ บันทึก และต่อยอดได้ งานพัฒนาและนักพัฒนาจะแบ่งออกเป็น แพ็กเก็ตหรือพาร์ติชั่นที่สะอาดและขึ้นแก่กันน้อยที่สุด มีการทดสอบและบันทึกเอกสารอย่างสม่ำเสมอขณะที่สร้างผลิตภัณฑ์ขึ้นมา กระบวนการ Scrum จะต้อง “สามารถแจ้งว่าพัฒนาผลิตภัณฑ์สำเร็จแล้ว”

4.3.4 สครัม (Scrum) Scrum สนับสนุนให้ใช้รูปแบบกระบวนการซอฟท์แวร์ (Software Process Pattern) ที่ได้รับการพิสูจน์แล้วว่าได้ผลดีสำหรับโครงการที่มีเวลาจำกัด มีการเปลี่ยนแปลงความต้องการ และมีความสำคัญยิ่งยวดต่อธุรกิจ

4.3.4 สครัม (Scrum) แบ็คล็อก (Backlog) รายการความต้องการหรือลักษณะที่ให้คุณค่าทางธุรกิจแก่ลูกค้าที่เรียงลำดับความสำคัญแล้ว สปริ้น (Sprints) ประกอบด้วยหน่วยของงานที่ต้องทำให้เสร็จตามความต้องการที่นิยามโดย Backlog

4.3.4 สครัม (Scrum) การพบปะของสครัม (Scrum meeting) การประชุมสั้นๆ ประมาณ 15 นาทีของทีมสครัมจะมีทุกวันเพื่อตอบคำถาม 3 ข้อคือ คุณได้ทำอะไรไปหลังจากการประชุมครั้งที่แล้ว มีอุปสรรคอะไรหรือไม่ และคุณวางแผนจะทำอะไรให้เสร็จก่อนการประชุมคราวหน้า สาธิต (Demos) ส่งมอบรุ่นของซอฟท์แวร์แก่ลูกค้าเพื่อสาธิตและประเมินหน้าที่การทำงานที่ได้ Implement

4.3.5 คริสตัล (Crystal) Alistair Cockburn และ Jim Highsmith ได้สร้างครอบครัวคริสตัลของอาไจล (Crystal Family of Agile Methods) เพื่อให้ได้มาซึ่งวิธีการพัฒนาซอฟต์แวร์ที่เน้น “ความสามารถในการนำร่อง” ที่ Cockburn บอกว่ามีลักษณะ “ทรัพยากรจำกัด เกมที่ต้องร่วมมือกันในการประดิษฐ์การสื่อสาร โดยมีเป้าหมายหลักคือ ส่งมอบซอฟต์แวร์ที่มีประโยชน์ทำงานได้ และเป้าหมายรองคือ จัดเตรียมความพร้อมสำหรับเกมถัดไป”

4.3.5 คริสตัล (Crystal) เพื่อให้บรรลุความสามารถในการนำร่อง Cockburn และ Highsmith ได้นิยามชุดของกรรมวิธี แต่ละกรรมวิธีมีชิ้นส่วนหลักๆ เหมือนๆ กัน และมีบทบาท กระบวนการผลิตผลงาน และวิธีปฏิบัติที่แตกต่างกันเฉพาะตัว ครอบครัวคริสตัลแท้จริงแล้วก็คือชุดกระบวนการอาไจลที่ได้พิสูจน์แล้วว่าได้ผลดีสำหรับโครงการชนิดต่างๆ ทีมอาไจลจะเลือกสมาชิกจากครอบครัวคริสตัลตัวที่เหมาะสมกับโครงการตนเองมากที่สุดไปใช้งาน

4.3.6 การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะของซอฟต์แวร์ Feature Driven Development (FDD)
การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะของซอฟต์แวร์ (FDD) เกิดขึ้นจากการคิดค้นของ Peter Coad และคณะ เพื่อใช้เป็นแบบจำลองกระบวนการเชิงปฏิบัติการของวิศวกรรมซอฟต์แวร์เชิงวัตถุ Stephen Palmer และ John Felsing ได้ขยายและเพิ่มเติมงานของ Coad อธิบายการปรับตัว กระบวนการอาไจลที่อาจประยุกต์กับโครงการขนาดกลางและขนาดใหญ่ขึ้น

4.3.6 การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะของซอฟต์แวร์ Feature Driven Development (FDD)
นิยามของคุณลักษณะให้ประโยชน์ เนื่องจากคุณลักษณะเป็นส่วนเล็กๆ ของซอฟต์แวร์ที่ทำงานได้ ผู้ใช้จึงสามารถอธิบายได้ง่าย เข้าใจความสัมพันธ์ระหว่างกันได้ง่ายกว่า และสามารถทบทวนได้ดีกว่าเมื่อมีความคลุมเครือ ข้อผิดพลาด หรือการหลงลืม คุณลักษณะอาจถูกจัดระเบียบเป็นกลุ่มลำดับชั้นที่มีความสัมพันธ์ทางธุรกิจได้ เนื่องจากลักษณะเป็นรุ่นๆ ของคุณลักษณะของซอฟต์แวร์ที่ต้องส่งมอบได้ในการพัฒนาแบบ FDD ทีมงานจะมุ่งพัฒนาซอฟต์แวร์ให้มีคุณลักษณะไม่ๆ ที่ทำงานได้ทุกๆ สองสัปดาห์ เนื่องจากคุณลักษณะมีขนาดเล็ก ตัวแบบและตัวโค้ดของคุณลักษณะจึงง่ายต่อการตรวจทานอย่างละเอียด การวางแผนโครงการ การจัดตารางงาน และการติดตามจะขับเคลื่อนด้วยคุณลักษณะตามลำดับขั้น ซึ่งดีกว่าการใช้ชุดงานย่อยที่เลือกมาแบบสุ่ม

Develop an Overall Model
4.3.6 การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะของซอฟต์แวร์ Feature Driven Development (FDD) Develop an Overall Model Build a Features List Plan by Feature Design by Feature Build by Feature More shape than content A list of features grouped into sets and subject areas A development plan class owners feature set owners A design package (sequences) Completed client-value function

4.3.7 การสร้างแบบจำลองอาไจล Agile Modeling (AM)
นักวิศวกรรมซอฟต์แวร์จะต้องสร้างระบบที่มีความสำคัญทางธุรกิจขนาดใหญ่ ขอบเขตและความซับซ้อนของระบบดังกล่าวจะต้องมีการสร้างแบบจำลอง เพื่อ เพื่อให้เข้าใจส่วนประกอบทั้งหมดว่ามีอะไรที่จำเป็นต้องทำ เพื่อแบ่งปัญหาออกเป็นส่วนๆ ให้เหมาะสมกับผู้ที่จะทำงานนี้ เพื่อให้สามารถประเมินคุณภาพได้ทุกๆ ขั้นตอนเมื่อระบบกำลังถูกประกอบขึ้นมา

สิ่งที่ทำให้การจำลองแบบอาไจลมีเอกลักษณ์ การสร้างแบบจำลองอย่างมีเป้าหมาย (Model with a purpose) ใช้แบบจำลองหลายๆ ตัว (Use multiple models) เดินทางอย่างเบาตัว (Travel light) เนื้อหาสำคัญกว่ารูปแบบ (Content is more important than representation) รู้จักแบบจำลองและเครื่องมือที่เลือกใช้ได้ดี (Know the models and the tools you use to create them) ปรับตัวตามสถานการณ์ (Adapt locally)

“การสร้างแบบจำลองอาไจล เป็นวิธีการเชิงปฏิบัติการสำหรับการสร้างแบบจำลอง และการบันทึกเอกสารของระบบซอฟต์แวร์ที่ได้ผล กล่าวอย่างง่าย การสร้างแบบจำลองอาไจลเป็นการรวบรวมคุณค่า หลักการ และหลักปฏิบัติสำหรับการสร้างแบบจำลองซอฟต์แวร์ที่สามารถประยุกต์กับโครงการพัฒนาซอฟต์แวร์อย่างได้ผล ในลักษณะที่มีน้ำหนักเบา แบบจำลองอาไจลได้ผลดีกว่าแบบจำลองแบบดั้งเดิม เพราะเพียงพอแก่การใช้งานโดยไม่จำเป็นต้องสมบูรณ์แบบ” Scott Ambler

4.4 สรุปท้ายบท ปรัชญาอาไจลสำหรับงานวิศวกรรมซอฟต์แวร์เน้น 4 เรื่อง หลัก คือ ความสำคัญของทีมจัดระเบียบตนเองที่ควบคุมงานที่ตนทำอยู่ การสื่อสารและความร่วมมือระหว่างสมาชิกในทีม ผู้ปฏิบัติงาน และลูกค้า การระลึกไว้ว่าการเปลี่ยนแปลงเป็นตัวแทนของโอกาสดีๆ การเน้นการส่งมอบซอฟต์แวร์ที่ทำให้ลูกค้าพอใจอย่างรวดเร็ว

4.4 สรุปท้ายบท การวางแผน การออกแบบ การเขียนโค้ด การทดสอบ
Extreme Programing (XP) เป็นกระบวนการอาไจลที่ใช้กันมากที่สุด ได้จัดระเบียบกิจกรรมไว้ 4 อย่างคือ การวางแผน การออกแบบ การเขียนโค้ด การทดสอบ

4.4 สรุปท้ายบท การพัฒนาซอฟต์แวร์ปรับตัว (ASD) เน้นความร่วมมือของมนุษย์และทีมจัดระเบียบตนเอง กำหนดกิจกรรมกรอบงาน 3 อย่างคือ การคาดเดา การร่วมมือ การเรียนรู้ ASD ใช้กระบวนการทำวนซ้ำที่รวมเอาการวางแผนวงจรการปรับตัว วิธีการรวบรวมความต้องการอย่างกระตือรือร้น และวงจรการพัฒนาแบบทำวนซ้ำที่มีการประชุมร่วมกับกลุ่มลูกค้าเป้าหมาย และใช้การตรวจทานด้านเทคนิคอย่างเป็นทางการ

4.4 สรุปท้ายบท การวนซ้ำการจำลองเชิงหน้าที่
วิธีการพัฒนาระบบไม่หยุดนิ่ง (DSDM) นิยามวงจรวนซ้ำที่แตกต่างกัน 3 อย่างคือ การวนซ้ำการจำลองเชิงหน้าที่ การวนซ้ำการออกแบบและการสร้าง การ Implement DSDM จัดตะรางงานโดยใช้กล่องเวลา และแนะนำให้ทำงานเพียงแค่พอเท่าที่จำเป็นสำหรับแต่ละรุ่นซอฟต์แวร์เพื่อความสะดวกไปสู่รุ่นถัดไป

4.4 สรุปท้ายบท สครัม เน้นการใช้ชุดรูปแบบกระบวนการซอฟต์แวร์ที่ได้ผลมาแล้ว สำหรับโครงการที่มีเวลาจำกัด มีการเปลี่ยนแปลงความต้องการ และมีความสำคัญยิ่งยวดทางธุรกิจ แต่ละรูปแบบกระบวนการนิยามของชุดงานย่อยในการพัฒนา และให้ทีมสครัมสร้างกระบวนการที่ปรับตัวตามความจำเป็นของโครงการ

4.4 สรุปท้ายบท คริสตัล เป็นกลุ่มครอบครัวแบบจำลองกระบวนการอาไจลที่สามารถปรับตัวเข้ากัน ลักษณะเฉพาะตัวของโครงการต่างๆ เช่นเดียวกับวิธีการอาไจลอื่นๆ คริสตัลใช้กลยุทธการวนซ้ำ แต่ปรับความเข้มข้นของกระบวนการ ให้รองรับโครงการที่มีขนาดและความซับซ้อนระดับต่างๆ กัน

4.4 สรุปท้ายบท การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะ (FDD) เป็นวิธีอาไจลที่ค่อนข้างที่จะเป็นทางการกว่าวิธีอาไจลอื่นๆ แต่ยังคงความคล่องตัว โดยการเน้นความสนใจของทีมพัฒนาไปที่คุณลักษระของซอฟต์แวร์ที่นิยามไว้เป็นหน้าที่การทำงานอันมีคุณค่าแก่ลูกค้า ที่สามารถอิมพลีเมนต์ให้เสร็จได้ภายในเวลาสองสัปดาห์หรือน้อยกว่า FDD ให้ความสำคัญแก่การบริหารโครงการมากกว่าวิธีอาไจลอื่นๆ

4.4 สรุปท้ายบท การสร้างแบบจำลองอาไจล แนะนำว่า แบบจำลองจำเป็นสำหรับทุกระบบ แต่ขนาด ประเภท และความซับซ้อนของแบบจำลอง ต้องปรับเข้ากับซอฟต์แวร์ที่จะสร้าง มีการนำเสนอชุดข้อแนะนำ และหลักการสร้างแบบจำลองเป็นชุดเสริมขึ้นมา เพื่อใช้ประโยชน์ระหว่างการวิเคราะห์และการออกแบบในทางปฏิบัติ

คำถามท้ายบท เลือกหลักการอาไจลหนึ่งข้อจากหัวข้อที่ 4.1 และเทียบดูกับแต่ละแบบจำลองในบทนี้ว่ามีการแสดงออกถึงหลักการนี้อย่างไร เหตุใดความต้องการจึงเปลี่ยนแปลงบ่อย ทำไมผู้ใช้ไม่ทราบความต้องการของตนเอง ทำไมกระบวนการทำวนซ้ำจึงง่ายต่อการจัดการความเปลี่ยนแปลง กระบวนการอาไจลทุกแบบเป็นการทำวนซ้ำหรือไม่ เป็นไปได้หรือไม่ที่จะทำโครงการให้เสร็จโดยไม่มีการทำวนซ้ำและยังเป็นอาไจลอยู่ อธิบายประกอบคำตอบของคุณ

คำถามท้ายบท กระบวนการอาไจลส่วนใหญ่แนะนำการสื่อสารด้วยการพูดคุยต่อหน้า แต่ในโลกปัจจุบันสมาชิกทีมซอฟต์แวร์อาจอยู่ห่างไกลกันคนละทวี คุณคิดว่าการอยู่ไกลกันของสมาชิกควรหลีกเลี่ยงหรือไม่ตามนัยยะของอาไจล คิดวิธีแก้ปัญหานี้มาหลายๆ วิธี ใช้แม่แบบคุณลักษณะ FDD ในหัวข้อที่ นิยามคุณลักษณะโปรแกรมท่องเว็บ (Web browser) และพัฒนาคุณลักษณะสำหรับชุดคุณลักษณะที่ว่ามา

บทที่ 4 กระบวนการอาไจล (An Agile View of Process)

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "บทที่ 4 กระบวนการอาไจล (An Agile View of Process)"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

บทที่ 4 กระบวนการอาไจล (An Agile View of Process)

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "บทที่ 4 กระบวนการอาไจล (An Agile View of Process)"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ