Download as PDF, PPTX
Uploaded bySawaros Okolkij
The nature of software development process
INT202 Software Development Process@KMUTT Group work This is a summarized version of "The Nature of Software Development Process" by Ron Jeffries for education in Thai language.
![[Agile Thailand 2012] Release planning & estimation the agile way](https://cdn.slidesharecdn.com/ss_thumbnails/releaseplanningestimationtheagileway-120701015228-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![Organization oriented creativity and innovation 20140616 [innovation journey]](https://cdn.slidesharecdn.com/ss_thumbnails/organizationorientedcreativityandinnovation20140616ij-140616212715-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
The nature of software development process
- 1. สรุป “ The Natureof Software Development Process ” โดย Alpaca Group
- 2. Alpaca Group Members นางสาวชนาภาชูวิเศษวณิชย 59130500015 นายชวนันท อัครประถมพงศ 59130500017 นายณัฐภัทร กิตติเกียรติกําจร 59130500027 นายฑัตพงศ อิศรัตน 59130500022 นายธนวัฒน กิตติศิริพันธ 59130500035 นายพงษพันธุ บุญลอม 59130500050 นายพรเลิศ หลอเจริญรัตน 59130500053 นางสาวภรณวรัตน สุวิชาชนันทร 59130500062 นายภูริภัทร อารยศิริกุล 59130500069 นางสาวสวรส ออกลกิจ 59130500099
- 3.
- 4. “Software is lava” การพัฒนาSoftwareเปนงานที่อันตราย ยากและซับซอน(เปรียบกับลาวา)เราจึง ตองการเสนทางที่จะทําใหเราสามารถขาม ผานลาวาไดอยางปลอดภัย ซึ่งเราเรียก เสนทางนั้นวา Natural Way
- 5. “Natural Way” เสนทางในการพัฒนา Softwareที่คํานึง ถึงValueเปนสิ่งสําคัญ ซึ่งจะทําใหสามารถ พัฒนา Software ที่ตรงกับความตองการของผู ใชงานได โดยไมหลงทาง ซึ่งดีกับทุกฝาย - ผูใชงาน: ไดรับงานที่มีคุณภาพอยาง รวดเร็ว - ธุรกิจ: ไดกําไรเร็ว เพราะมีการจัดลําดับ ความสําคัญในการทํางาน - การจัดการ: จัดการไดงาย - ผูพัฒนา: รูลําดับงานและความตองการ อยางชัดเจนกอนลงมือทํา
- 6. “Simple but NotEasy” ตองคิดอยูเสมอวาอะไรคือสิ่งที่เรา ตองการ เรียนรูในสิ่งที่จะทํา และทํามัน อยางงาย โดยโฟกัสที่สงตอคุณคาที่ สามารถมองเห็นไดอยางสมํ่าเสมอ
- 7. Part I: TheCircle of Value วงกลมแหงคุณคา
- 8.
- 9. Chapter 1 “ TheSearch for Value ” คนหาคุณคา
- 10. กระบวนการทํางาน Guiding ทุกคนในทีมตองรูและเขาใจตรงกันวาตองการอะไร มี เวลาเทาไหรในการทํา Organizing แบงงานดวยfeature โดยดูจากความสามารถในการ ทํางานตามแผนและจะตองจัดคนใหเหมาะกับงาน Planning จัดลําดับความสําคัญของfeature โดยดูวาอันไหน สําคัญที่สุดใหยกขึ้นมาทํากอน Value = สิ่งที่เราตองการ ทุกอยางเกิดขึ้นไดเพราะValue ซึ่งValueอาจเปนเงิน ความสุข หรือการใชชีวิตก็ได
- 11.
- 12. Chapter 2 “ Valueis What We Want ” Value คือ สิ่งที่เราตองการ
- 13. “เราตองการvalue และvalueคือสิ่งที่เราตองการ” Valueสวนใหญเกี่ยวกับเงิน เวลา และการใชชีวิตเมื่อทําเสร็จจะตองตรวจ สอบวาเราไดสิ่งที่เราตองการหรือไม เพื่อ เช็ควาvalueที่ไดมานั้นตรงกับความ ตองการจริงๆ Valueจะเกิดขึ้นเมื่อเราเริ่มสง software ดังนั้นจึงตองหาวิธีเพื่อสง softwareใหเร็ว เราไมสามารถทําทุกอยางใหเสร็จตอนนี้ ถาเรามีfeatureมากจะยิ่งใชเวลามากในการ พัฒนา
- 14. “คุณคาเกิดขึ้นไดในสิ่งที่เราเลือกจะทํา” เลือกfeatureที่มีคุณคา ราคาถูกมา ทําเปนอันดับแรก แตบางครั้งงานก็ออกมา นาเบื่อ เมื่อเราเริ่มทําจากfeatureที่มีคุณคา สูงสุดเสร็จแลวเราสามารถสรางnew productขึ้นมาตอยอดของเดิมได ซึ่งเปน สิ่งที่นาสนใจมากกวา
- 15.
- 16. Chapter 3 Guiding Goes Better “Featureby Feature”
- 17. “สิ่งแรกที่เรารูเมื่อเริ่มทําโปรเจ็กตคือ Deadline” Deadline: เสนสีนํ้าเงิน Plan:ดาว สิ่งที่สามารถทําไดเปนอยางนอย: เสนแดง เราไมสามารถมีทุกอยางได แตเราตอง จัดการวางแผนวาอยางนอยสิ่งที่ตองทําได คืออะไร และไปใหถึงจุดนั้น กอนที่จะพัฒนา ตอตามแผนที่เรากําหนดไวหากยังมีเวลา เหลือ
- 18. “activity-based” โปรเจ็กตสวนใหญใชกระบวนการเปนพื้นฐาน โดย แบงเปน4ขั้นตอน คือวิเคราะห ออกแบบ เขียนโคด ทดสอบ ซึ่งจะดีถาสามารถวิเคราะหไดตามแผน แตวามันไม สามารถวิเคราะหวาทําแบบไหนถึงจะดี และไมสามารถ บอกจุดเริ่มตนของกระบวนการตอไปไดวาจะเริ่มเมื่อไหร ในหลายๆครั้งเรามักใชเวลามากกวาที่เราคิด เปนการทํางานแบบmonolith ที่วางแผนทุกอยางไวแลว คอยทําทีเดียว ซึ่งบางครั้งก็ไมตอบโจทยสิ่งที่ตองการ และ เสียเวลาโดยเปลาประโยชน
- 19. “Deliver feature byfeature” สามารถทํานายชวงเวลาการทํางานไดวาขั้นตอไปจะเริ่มเมื่อไหร และใหคุณคา กับลูกคาไดเร็วกวา รวมทั้งใหผลที่ดีกวา
- 20.
- 21. “Team build features” แบงทีมทํางานโดยแตละทีมจะตองมีคน ที่ถนัดในแตละดานอยูดวยกัน ไมควรจัดทีมที่ แบงความถนัดเปนเรื่องๆ เพราะจะไมสามารถ ทําใหงานกาวหนาได
- 22. “Communities of Practice” ในกรณีที่มีผูเชี่ยวชาญไมพอใหแบง กลุมกันเรียนรูและเรียนรูไปดวยกัน โดยผูที่ จะนําสอนอาจจะเปนคนที่อยูในทีมเดียวกันที่ สามารถทําไดหรือมีความสามารถอยูแลว มาสอนเพื่อนในทีม
- 23.
- 24. Chapter 5 “Planning Feature byFeature” วางแผนทีละfeature
- 25. “Planning” การวางแผนเปนสิ่งสําคัญ เราจะวางแผนแคคราวๆแตจะไมลงรายละเอียดวาอะไรจะ เกิดขึ้นและเกิดขึ้นเมื่อไหร เมื่อถึงเวลาคอยตัดสินใจวาจะทําอะไรตอการที่ลงรายละเอียด ตอนวางแผนเปนการเสียเวลาและกอใหเกิดความเครียด
- 26. “Getting Started” เริ่มดวยไอเดีย คิดสักเล็กนอยจัดตั้งทีม เริ่มลงมือทํา สามารถบอกไดวาเราจะสรางอะไรที่ ใหคุณคา ใชเวลานานเทาไหร ซึ่งทําใหตัดสินใจไดวาจะลดคาใชจายหรือวางแผนอยางไร ตอไปใหไดคุณคามากขึ้น Idea Think Team Build
- 27. “Feature Splitting” การวางแผนแคตอนตนไมใชสิ่งที่ดีเทาไหร เพราะเราตองการคุณคา เราจึงตองวางแผน ตลอดเวลาซึ่งเราเรียกการทํางานแบบนี้วา Iteration/Sprints ซึ่งใชเวลา2สัปดาห โดยเรา ตองมีS◌ัtoryเปนตัวกําหนดการทํางาน ซึ่งถา ใหญมากๆเราจะแบงเปนสวนยอยที่เรียกวา Tasks ซึ่งคนทั่วไปอาจมองtasksไมคอยเขาใจ ซึ่งบางครั้งทางเทคนิคอาจใชการแบงเปน featyreยอยเพื่อใหคนทั่วไปสามารถเขาใจได
- 28. “Plan often, don’tovereat” ทีมจะตองตัดสินใจวาจะทําอะไรบางใน1 รอบการทํางาน2สัปดาห และตัดสินใจวาจะทํา อะไรตอไป ในบางครังก็ใชเวลาคุยมากเกินไป ทําใหเหลือเวลานอยในตอนทาย ซึ่งจะทําใหเกิด ความกดดัน และมีภาระงานที่ตองทําเยอะ ดังนั้น จึงควรเลือกงานที่ใหคุณคาสูงมาทํากอน
- 29. Chapter 6 “Building the Product, Featureby Feature” ลงมือทําทีละfeature
- 30.
- 31. “Identify real progress” การทํางานแบบfeatureจะรวมการทํางาน ทั้งระบบไวในแตละรอบการทํางานทั้งการ เก็บความตองการ ออกแบบ เขียนโคด และ ทดสอบ ซึ่งจะดีกับการทํางานของเรา เพราะมี ประสิทธิภาพ ปลอดภัยและชวยฝกฝน เมื่อเราดูงานที่เสร็จจริงจะทําใหเขาใจและรู ถึงเงื่อนไขของโปรเจ็กตเรา ถาเราไมสามารถดู featureไดหรือทําไมเสร็จเราก็จะไมรูวาอะไรจะ เกิดขึ้นตอไป
- 32. “Eliminate the testand fix finish” หลายโปรเจ็กตจบดวยการทดสอบ เราตอง เรียนรูวิธีที่จะลดเวลาการทดสอบลง เพื่อความ มั่นใจเราควรตรวจอบทุกอยางตลอดเวลา เพื่อให งานที่สงออกไปมีคุณภาพและไมเกินกรอบเวลาที่ กําหนดไว
- 33. “Grow and refinedesign” ถาเราออกแบบมากเกินไป เราจะมีfeature ไมมาก แตถาเราออกแบบนอยไปfeatureจะยาก ที่จะทําและทําใหงานชา เราตองหาขนาดที่เหมาะสมกับงานที่จะทํา โดยใชเทคนิคที่เรียนรูไดงาย และไมกดดันมาก จนเกินไป
- 34. Chapter 7 “Build Features and Foundationin Parallel” ลงมือทําเปนลําดับ
- 35. “Solid Infrastructure” ถาไมมีการออกแบบที่ดี การทํางานจะเปน ไปไดยากและทํางานไดชา featureจะตองรอง รับโครงสรางพื้นฐานและโครงสรางพื้นฐาน ตองการการออกแบบที่ดี ซึ่งเราไมสามารถสราง featureไดโดยไมมีโครงสรางพื้นฐาน
- 36.
- 37.
- 38. “Steer to bestresult” แยกการทํางานเพื่อใหไดผลที่ดีที่สุด โดยตัดสินใจในการสงงาน เพราะเราพรอม ตลอดเวลา เราสามารถสงงานไดอยาง รวดเร็ว
- 39. Chapter 8 “Bug-Free and WellDesigned” ไมมีBug และมีการออกแบบที่ดี
- 40. ทํางานตามfeature ตามรอบ เวลาที่กําหนดไว เปนวิธีที่ดีที่สุดที่จะ ทําใหงานสําเร็จ เมื่อเราวางแผนจัดการดวยfeatureเราจะบอกวา เสร็จเมื่อfeatureนั้นสามารถทํางานได ซึ่งเราไมสามารถ บอกไดวาอะไรจะเกิดขึ้นระหวางการทํางานบาง
- 41.
- 42. “Test-Driven Development” เขียนtestกอนลงมือทํา ทดสอบทุกรอบการ ทํางานและทดสอบบอยๆเพื่อไมใหเสียเวลากับ การแกบัคในตอนทายเพราะเมื่อพบขอผิดพลาด ก็สามารถแกไขไดทันที โดยมี2ระดับในการ ทดสอบคือผูใชงานและผ◌ูพัฒนา หลังจากทดสอบแลวบางครั้งอาจตองมีการ ปรับเปลี่ยนโครงสรางเพื่อใหการทํางานดีขึ้นกวา เดิม
- 43. Chapter 9 “Full Circle” ไมมีBugและมีการออกแบบที่ดี
- 44. Building ลงมือทําจากสิ่งเล็กๆ ซึ่งทํางานไดอยางถูกตองและมี การออกแบบที่ดี Development สงfeatureที่ทํางานไดจริงที่ผานการทดสอบแลว มีการ ออกแบบที่ดี Managing การจัดการโดยดูจากvalueจะดีกวาจัดการดวยวันที่ที่ ไมสามารถสงมอบคุณคาได Planning การวางแผนดวยfeatures จะทําใหรูสิ่งที่ตองการ และ วางแผนเพื่อทําใหงานที่เคยสงไปแลวดีขึ้น Value สิ่งที่ตองการ featureสงมอบคุณคา ยิ่งสงเร็วเทาไห รยิ่งใหคุณคาหรือสิ่งที่ตองการไดเร็วเทานั้น
- 45. Part II: Notesand Essays บันทึกและเรียงความ
- 46. “Good work issimple but, it is not easy...”
- 47. Chapter 10 “Value— What IsIt?” คุณคา...คืออะไร?
- 48. ที่คุณบอกวา valueคือ สิ่งที่เราตองการ แบบนี้ มันก็เปนแคเปลือกสิแลว แทที่จริงvalueคืออะไร กันแน?? ใชแลว แตในกระบวนการพัฒนา software เราตองตัดสินใจวาอะไร คือสิ่งที่เราตองทําหรือไมทํา โดย เอาvalueเปนพื้นฐาน โดยเราจะ เลือกเอางานที่ใหvalueสูงมาทํา กอน จุดประสงคของผมคือชวยใหคุณ เห็นvalueในความเปนจริง ซึ่งก็คือ อะไรก็ตามที่คุณตองการ หรือเปน สิ่งที่คุณใหความสนใจ...
- 49. Information ขอมูลที่ผูใชตองการ ดังนั้นเรา อาจทําPrototypeแลวเอาไป เสนอใหผูใชที่เกี่ยวของ Human life จุดประสงคของผลิตภัณฑอาจ เปนการชวยชีวิตคนเรา ตัดสินใจในการทําfeatureตอ ไปโดยอาศัยจํานวนของผู รอดชีวิต Product speed พัฒนาใหมีความเร็วมากขึ้น เพื่อใหสามารถแขงขันกับคูแขง ไดและตอบโจทยความตองการ ของผูใชงาน People’s happiness ทําใหผูใชงานมีความสุข Rapid progress กระบวนการอาจใชเวลานาน กวาจะไดบางสิ่งออกมา เราจึง ตัดสินใจเลือกบางfeatureออก มาทํากอนซึงจะทําใหเห็นผลเร็ว ขึ้น 05 01 02 03 04Value Product owner คือ ผูที่ตัดสินใจลําดับในการทํางานวาอะไรสําคัญมาก- นอยหรือทํากอน-หลัง ที่จะใหผลที่ดีที่สุดที่อาจเกิดขึ้นได อะไรก็ตามที่ตองการ
- 50. Chapter 11 “Value—How Can WeMeasure It?” คุณคา...เราจะวัดมันไดอยางไร?
- 51.
- 52. “เราจะวัดvalueไดอยางไร” 1. ถามตัวเองวาจะทําอะไรตอไปที่จะใหคุณคา กับงานของเรา 2. ถามตัวเองวาทําไมแลวถามผูที่เกี่ยวของวา เห็นดวยหรือไม เมื่อสวนใหญเห็นดวยก็เดินหนาทําตอ แตถาไมก็ พยายามหาคนที่เห็นดวย ไมก็พยายามแกไขโดย เพิ่มfeatureที่ตรงกับความตองการของผูใชงาน ใหมากขึ้น จากนั้นก็ลงมือทํา สงใหตรงเวลา และ ฟงความเห็นของผูใชอยางสมํ่าเสมอ
- 53. Chapter 12 “Of Course It’sHard!” แนนอน...วามันยาก!
- 54. ที่คุณบอกมันดูเขาใจ งาย ใหเราสนใจและทํา ทุกอยางโดยยึดvalue เปนหลัก ซึ่งมันดีมาก แตมันยากเหลือเกินยาก มากๆ แนนอนวามันยาก เรามีขั้นตอนการ ทํางานดังนี้ - สนใจในvalueเราจะไดผลที่ ดีที่สุด - สรางsoftwareจริง จะรูวา อะไรคือสงที่เราตองการ - ลงมือทําที่ละขั้นเล็กๆ จะเห็น วาเราควรทําอยางไร - เรียนรูการวางแผน จัดการ และทักษะเฉพาะ ซึ่งทําให เราสรางproductที่ดีและมี คุณภาพ
- 55. “ยังไงก็ยังยากอยูดี” แนนอนวามันยาก แตเราไมตองการขั้นตอน การทํางานที่ซับซอน ไมมีการจํากัดวาวิธีไหนดี ที่สุดเราตองทําใหมันงายแตมีคุณภาพ ซึ่งการทํางานแบบนี้เราตองตัดสินใจตลอด เวลา ซึ่งเปนเรื่องยาก แตจะทําใหทีมมีพลังมาก ขึ้นและทําใหการทํางานเร็วขึ้น
- 56. Chapter 13 “Not ThatSimple” ไมใชเรื่องงาย
- 57. มันไมใชเรื่องงาย คุณ คิดวาฉันโงมั้ย? แนนอนวามันไมงาย เราตอง พยายามทําใหมันใกลเคียงกับ ความงายมากที่สุด เรากําลังพยายามทําตาม แนวคิดงายๆโดยเนนที่valueเปน หลัก เพื่อดูวามีอะไรกําลังจะเกิดขึ้น เราตองตัดสินใจวาเรา ตองการอะไร สิ่งที่เราตองการจริงๆ โดยการสรางสิ่งตางๆและมอง วิธีการทํางานใหออก
- 58. Chapter 14 “Creating Teams ThatThrive” สรางทีมที่เจริญเติบโต
- 59. “เปาหมายมาจากBusiness” Product Ownerเปนคนที่ชวยนําทางวาจะทํา อะไรตอไป โดยบอกรายละเอียดที่ตองการมาใหรวม ทั้งบอกปญหาที่ตองการแกไข ซึ่งทีมจะเปนคนลงมือทําตามที่Product Owner ตองการ แตตองมั่นใจวาทุกคนเขาใจตรงกันวาตองทํา อะไรเพื่ออะไร และจะแกไขปญหาอยางไร ในขั้นแรกมักยากเสมอ แตเมื่อทํางานไปในแตละ รอบจะทําใหเห็นวาเราทําอะไรไบางและจะทําใหดีขึ้น ไดอยางไร
- 60. Chapter 15 The “Five-Card Method” forInitial Forecasting Prepared
- 61. “Five-Card Method” ทํานายการทํางานขนาดใหญได ไมไดใหรายละเอียดมากนักแตก็ทําใหทีมรูวาตองทํา อะไรและจะทําอยางไรใน1สัปดาห -หาสิ่งที่สําคัญ3-5อยาง ซึ่ง1การดจะมี1ประโยคเทานั้น - แบงละชิ้นใหญใหเปนสวนยอย3-5ชิ้น อาจแบงเปนfeatureแตไมใชเปนความคิดดาน เทคนิค - ทําจนกวาทุกfeatureมีขนาดเทาๆกัน หรือเล็กพอที่จะทําได โดยเลือกทําfetureที่มีvalue สูงกอน ตองจําไววาการจัดการตองมีความรอบคอบ ตัดสินใจไดวาจะทําอะไรกอน-หลัง
- 62.
- 63. “อะไรคือการจัดการ?” ในปกติการทํางานของเรา Product Championจะตองการระบุทิศทางและการทํางาน กับผูมีสวนรวมและสมาชิกในทีม เพื่อกําหนดลําดับความสําคัญ ทีมจะแสดงซอฟตแวรของเรา ในทุก ๆ2สัปดาห นั่นเพื่อใหเราบอกทุก ๆคนไดวาเรากําลังจะทําอะไร เพื่อชวยใหทีมตัดสินใจ ไดวาตองการความชวยเหลืออะไรไหม ทีมของเรามีทักษะและความสามารถในการสงมอบซอฟตแวรแตละชิ้นที่เพิ่มขึ้น เราเขา ใกลเปาหมายที่เราวางไวมากขึ้น การประสานงานที่เราตองการนั้นก็นอยลง ทีมที่มีการจัดการ องคกรของตนเองที่ดี สมาชิกในทีมจะตัดสินใจไดวาจะจัดชุดการทํางานออกมาไดอยางไร ใหมันออกมาเสร็จสมบูรณ
- 64. การจัดการงานใหเสร็จยังคงเปนเรื่องจําเปน แนนอนวาการคัดเลือกพนักงานจะตองมาจากทีมงานระดับสูงกวา อยางไรก็ตาม การ ตัดสินใจเกี่ยวกับพนักงานไมวาจะจางหรือเลิกจางนั้นจะตองมาจากผูบริหาร ทีมอาจเสนอ งบประมาณใหกับ Product Champion การตัดสินใจดานงบประมาณภายในโครงการ นั่นแหละคือการจัดการ ผูจัดการบางครั้งสงสัยวาพวกเขาจะลงไปทํางานดวยตัวเองหรือไม ในการจัดการนี้เรียก วา “การมอบสิทธิ์” ถาผูจัดการสรางทีมที่มีประสิทธิภาพสรางผลิตภัณฑที่มีคุณคา มีวิสัยทัศนที่ ดีผูจัดการคนนั้นจะไดผลลัพธมากกวาที่ลงมือทําซะอีก
- 65. ผูบริหารตัดสินใจเรื่องธุรกิจในองคกร บางที่ผูบริหารจะตัดสินใจเรื่องธุรกิจในองคกรวาจะเปน ยังไง คืออะไร พวกเขาจะตัดสินใจเรื่องขอกําหนดวาจะทําอะไร ใหเสร็จและใครจะทํามันบาง นี่คือจุดเริ่มตนของการวางแผน เลือกทางแกไขปญหาและมองหาโอกาสที่จะเกิดขึ้น กําหนด ขนาดของแตละการทํางาใหเหมาะกับเวลา พนักงานและ งบประมาณ จากมุมมองโดยธรรมชาตินั้น การวางแผนระยะยาวสามารถ ทําไดหลายวิธี ผูคนจากหลายสาขาควรมีสวนรวมในกิจกรรม การวางแผนนี้ : บุคคลฝายการจัดการ,บุคคลฝายการเงิน,บุคคล ฝายผลิต,บุคคลฝายเทคนิค
- 66. การลงทุนลงแรงในระยะยาว การลงทุนลงแรงในระยะเริ่มตนหรือระยะยาวนั้นขึ้นอยูกับ เปาหมาย โดยตามธรรมชาตินั้น เราจะสรางฟเจอรที่มีมูลคาสูง หรือสําคัญไวแรกๆและผูจัดการสามารถคอยติดตามดูไดโดยไม ตองลงรายละเอียด ในฐานะนักวางแผนระดับสูงและผูจัดการ ตองใหชัดเจนในความสามารถทั่วไปที่จําเปนในโครงการขนาด ใหญของเราและขอถาม Product Champions ของเราถึง “ show us the software” เพื่อใหจัดการครอบคลุมประเด็นสําคัญ ทั้งหมดของสิ่งที่เราทําเสียกอน จากนั้นคอยใหความสําคัญกับ สวนที่มีความสําคัญนอยกวาเชนเวลาและเงิน
- 67. การวางแผนในระยะสั้น โดยธรรมชาติแลว การวางแผนในระยะสั้นนั้น จะมีผลตอเนื่องถึงระดับของการพัฒนา และพวกเขาจะ ทําตามลําดับโดยทําจากลําดับที่สําคัญมากสุดเปน ลําดับแรกแผนคือแกไขทุกสองสามสัปดาหและเราทุก คนสามารถเห็นสิ่งตางๆที่เราจะทําไดชัดเจนยิ่งขึ้น เราทําแบบนี้ไดงายๆ ทุกสองสามสัปดาห เราจะ สังเกตสิ่งที่ได และเราวางแผนในอีกสองสัปดาหตอไป โดยเราจะคํานึงถึงวิสัยทัศนและจุดมุงหมายของการทํา งานของเรา
- 68. ไมไดยึดติดกับแผน ในความเปนจริงนั้นงานของคุณไมไดยึดติดกับ แผน คุณตองเลือกผลลัพธที่ดีที่สุดของคุณ โดยไม จําเปนตองระบุเปาหมายตายตัว เมื่อสงมอบงานใหลูกคาบอยๆเราจะพบวาเรา เราไดทําทุกอยางตามที่ลูกคาของเราตองการเรียบรอย แลว เรามักจะพบวาแทนที่เราจะจินตนาการถึงสิ่งที่งาน ของเราควรจะเปน เราควรคิดถึงแนวคิดใหมๆที่ นอกเหนือจากการทํางานตามปกติ เราตองคอยติดตามถึงการวางแผนในแตละ ระดับอยางสมํ่าเสมอ วางลูทางแผนงานในการทําวาจะ ทําอยางไร ถาม Product Champion เพื่อแสดงใหเห็น ถึงสิ่งที่เราทํา และถามถึงความสัมพวาอะไรคือคุณคา ของสิ่งที่เราทํา
- 69. ผูบริหารระดับสูงยังมีหนาที่รับผิดชอบในองคกร ทั่วไป พวกเขาจัดสรรเงินและคนใหกับงาน โดยทั่วไปจะกําหนดงบประมาณ จัดการเลือก ProductChampion และบุคลากร บอยครั้งที่ Product Champion เลือกสมาชิกทีมหลัก และทีมรวมจะเลือก สวนที่เหลือ the Product Champion and team self-organize จะทํางานจนสําเร็จ พยายามที่จะผลัก ดันการตัดสินใจขององคกร ลงรายละเอียดใหไปได ไกลใหมากที่สด ใชงบประมาณเพื่อควบคุมขนาดของ งาน มุงเนนผลลัพธใหมากที่สุดเทาที่คุณจะทําได และ ชวยใหทุกคนเกิดความใกลชิดกับการทํางานมากขึ้น ในการตัดสินใจและการจัดระเบียบของสิ่งที่ทํา
- 70. เปนไปไดมากวาการกระทําอะไรของบุคลากรจะ ตองเริ่มตนหรืออยางนอยตองไดรับการอนุมัติจากผู บริหารกอน แตอยางไรก็ตาม ทางเลือกและคําแนะนํา ตางๆ จะถูกมอบใหกับทีม ปลอยใหทีมของคุณ พิจารณาวาพวกเขาตองการคนเพิ่มหรือไม เปนการชวยใหทีมเขาใจปญหาของนโยบาย โดยรวมจากการจางงาน แนวทาง และยุทธศาสตร และ ที่สําคัญที่สุดคือคุณคาของการสรางคนที่คุณมีอยูแลว ของคุณใหดีขึ้น ใหทีมเขาใจไดดีขึ้นถึงภาพใหญๆที่ดี กวาจะไปหาใหม
- 71. การจัดการจะตัดสินใจวา product อะไรที่จะ ลงทุนพวกเขาเลือก Product Champion ซึ่งจะ รับผิดชอบตอผลลัพธจัดการดูแตละงานที่ออกมา และ คอยแนะนํา the Product Champion ใหมั่นใจและ สนับสนุนวัตถุประสงคของงาน โดยใชเวลาและทิศทาง ไมกี่รูปแบบ บางครั้งสิ่งที่เปลี่ยนแปลงในสิ่งแวดลอมหรือตาม การจัดลําดับความสําคัญของบริษัท การเปลี่ยนแปลง เหลานี้ถูกสงผานไปในแงของการปรับวิสัยทัศน ผลิตภัณฑ งบประมาณและอื่น ๆ บางครั้งสิ่งตางๆอาจไมดีเทาที่ควร การทํางาน ตามที่เราแนะนําในหนังสือเลมนี้ผูบริหารจะเห็นการ เบี่ยงเบนที่รวดเร็วและสามารถตอบสนองไดดวยการ ชวยเหลือ Product Champion และทีมใหดีขึ้น นา ประหลาดใจมากเมื่อมันเปนสิ่งที่เกือบเปนไปไมได เมื่อ คุณสามารถมองเห็นผลิตภัณฑไดในทุกสองสัปดาห
- 72. สรุป โดยธรรมชาติของการพัฒนาซอฟตแวรนั้น คือ การมีอิสระในการมอบอํานาจใหกับคนทํางาน ไมมี อะไรใหมเกี่ยวกับเรื่องนี้มันเปนวิธีการจัดการที่ทําได เสมอ ผูจัดการบางคนลังเลที่จะมอบหมายงานอยาง เต็มที่ โชคดีที่รูปแบบของการพัฒนาซอฟตแวรนี้มี มากมายจากการมองเห็นถึงสิ่งที่เกิดขึ้น ทําใหการ มอบหมายเปนไปอยางรอบคอบ
- 73. Chapter 17 “Whip the PoniesHarder” ไปไดชากวาที่คิดไว
- 74. “Whip the PoniesHarder” เมื่องานที่ตองทําเริ่มไปชากวาที่คาดหวังไว project manager หลายๆคนจะกระตุนดวย การบอกใหทํามากขึ้นซึ่งจะทําใหเกิดแรงกดดันขึ้นภายในกลุมพัฒนาซึ่งจะสงผลใหละเลย การทําเทสและกอใหเกิดขอผิดพลาดตามมา บางขอผิดพลาดที่หลุดไปถึงมือ customer ก็จะ ทําใหเสีย Value ไป เพราะฉะนั้นในการจัดการปญหานี้ ควรทําตามคําพูดนี้ “Work smarter, not harder” คือการเริ่มตนจากการหาสาเหตุกอนวางานลาชา เพราะอะไร แลวจึงจัดการกับ ตนตอเหลานั้นและเราทํางานเพื่อใหได Value ไมใช Cost เพราะฉะนั้นเพื่อที่จะไดเวลางาน ตองเสร็จ แตตองเสร็จโดยที่ไมเสียหรือลด Value นั้นลงไปเพราะฉะนั้น Don’t “whip the ponies.” Help them improve. (สิ่งที่จะชวยทําใหทีมสามารถผลิตงานที่มีคุณภาพคือการที่ พวกเขามีสกิลในการทําสูงซึ่งจะไดจากการที่เราลงทุนสงพวกเขาไปเรียนรูในดานนั้นๆ)
- 75. Chapter 18 “To SpeedUp, Build with Skill” เพิ่มความเร็วได โดยใชทักษะ
- 76. “To Speed Up,Build with Skill” สิ่งที่มีคุณคาที่สุดในการพัฒนา Software คือการพัฒนาสกิลของทีมไปดวย ผลลัพธจาก การลงทุนนี้จะคอยๆแสดงผลลัพธใหเห็นในเวลาไมชา แตจะสูญเสียเวลาไปบางจากการแกไข ขอบกพรองตางๆของโปรแกรม แตจะทําใหการพัฒนา Software ผานไปไดดวยดีนุมนวล ไมคอยเจอปญหามาก เพราะทีมที่ทํางานไดเร็วนั้นจะเปนทีมที่ทํางานไดอยางตอเนื่องและทํา งานไปไดอยางนุมนวลไมติดขัด
- 77.
- 78. “เราตองการการดําเนินงานที่มั่นคง” การดําเนินการตามแผนที่มั่นคงทําใหเรารูตัววาเราอยูจุดไหนแลว อะไรที่จะทําเปน ลําดับตอไปหรืออะไรที่ควรจะถูกเลื่อนออกไปกอน บอยครั้งที่การดําเนินงานของเรานั้นไมมั่นคง ถึงแมวาองคประกอบตางๆของงานเราจะดู มีความยากพอๆกันงานของเราอาจจะเอาแนเอานอนไมได หลังจากนั้นงานของเราก็จะคอยๆ คืบหนาไดชาลงๆ นอกจากนี้มันยังทําใหการยากแผนยากขึ้น เราจะเห็นวาปญหาจะเริ่มเกิดขึ้นจนแยที่สุด คือทําใหเราสงงานไมทันเดดไลน
- 79. ทางคดเคี้ยว การสราง feature ขึ้นมาไดนั้นมาจากความยาก ของฟเจอรนั้นและความยากในการเอาฟเจอรใหมๆ ใสเขาไปรวมกับcode เดิมที่มีอยูได ถาเราละเลยเรื่องนี้ตอนเอา feature ใหมใส เขาไปอาจจะงาย แตจะทําใหงานยุงเหยิงไปดวยสิ่งที่ เรียกวา bad code งานตอๆไปก็จะเริ่มใชงานนานขึ้น เราตองหลีกเลี่ยงการสรางทางคดเคี้ยวเพื่อจะ ทําใหงานเราดําเนินไดอยางมั่นคง และหากเราเผลอ สราง เราตองดึงออกไมใหขด
- 80. Refactor ใหทางเดินของเราเปนเสนตรง คําวา refactorแปลงายๆก็คือทําให code ของเราสะอาด สามารถเกิดขึ้นไดงายๆ หาก เรากดดันทีมของเราใหทํา feature เพิ่มจนไมนาทันตามความเปนจริง พวกเราจะลืมทุกอยาง เชนการทํา test หรือการเขียนโคดที่มีระเบียบ ผลที่ไดคืองานของเรามีขอบกพรองมากมาย งานที่ไมมีคุณภาพนั้นสังเกตไดยากหากมองแตภายนอก ในฐานะ businesspeople เรา คาดหวังใหทีมของเราเขียนโคดใหมีระเบียบ และเมื่อไรที่เราพบทางคดเคี้ยวอีก เราก็ตอง จัดการใหเรียบรอยซะ
- 81. ทําอยางไรหากทางเดินเรายุงเหยิงไปหมด คงไมใชทางออกที่ดีหากเราจะเริ่มทํางานชิ้น ใหญๆใหมหมด ทุกครั้งที่เราจะเริ่ม featureเราจะ clean งานในสวนที่เราจะลงมือทํากอน clean ให เพียงใหพอทํางานไดกอน และเมื่อ feature เราใชได แลว เราจึงคอย clean code เพิ่มเติม งานสวนที่เราไมคอยไดยุงก็ไมคอยทําใหงาน เราชาลงมากเทาไรนัก สวนงานที่ สําคัญเราจะใสใจ มากในการ clean สวนใหญ developer จะเริ่มเขียนใหมทั้งหมด ซึ่งไมใชเรื่องที่ดีนัก ดังนั้นฝกฝนเรื่อง refactor ให ชํานาญซะ
- 82.
- 83. ฉันโชคดีที่ไดเปนนักเขียนคนหนึ่งของ Agile Manifesto “The NaturalWay” คือการกลั่นสิ่งที่ฉันไดเรียนรูในชวงครึ่งศตวรรษของการพัฒนา ซอฟตแวรและเกือบ 20 ปในการทํา “Agile” ฉันไมไดพยายามสรางAgile อื่นที่นี่ ใน Nature ฉันอธิบายวาฉันคิดอยางไร ควรจะสรางซอฟตแวรตามสิ่งที่ฉันไดเรียนรูกอนระหวางและหลัง “Agile” ถาคุณตองการทราบขอมูลเพิ่มเติมเกี่ยวกับการพัฒนาซอฟตแวร มีวิธีการหรือ Agile framework จํานวนมาก เปนที่นิยมมากที่สุดคือ Scrum โดย Jeff Sutherland และ Ken Schwaber โดยการไมมุงเนนเพียงการออกแบบเพียงอยางเดียว ดังนั้น Scrum จึงไมไดรวมถึง การปฏิบัติทางเทคนิคอยางชัดเจน เชนการทดสอบที่ยอมรับการทดสอบการพัฒนาการ ทดสอบที่ขับเคลื่อนดวยการพัฒนา refactoring และอื่น ๆ
- 84. XP หรือ ExtremeProgramming ที่สรางโดย Kent Beck เปนกรอบที่ไมรวมถึงการ ปฏิบัติทางเทคนิคอยางชัดเจน มิฉะนั้น XP ก็เหมือนกับ Scrum XP ไมรวม Scrum Master แต มักจะแนะนําโคชที่เปนความคิดที่คลายคลึงกัน สําหรับฉันการตอสูและการปฏิบัติทางเทคนิค กับ XP บางคนคงไมเห็นดวยกับฉันในเรื่องนี้ Alistair Cockburn’s Crystal Clear เปน Agile framework ที่งายกวา Scrum นอกจาก นี้ยังมีโครงสรางที่ซับซอนขนาดใหญที่ซับซอนเชน Dynamic System Development Method (DSDM), Larman/Vodde’s Large Scale Scrum (LeSS), Scott Ambler’s Disciplined Agile Development (DAD) หรือ Dean Leffingwell’s Scaled Agile Framework (SAFe) และอื่น ๆ อีกมากมาย
- 85. อีกครั้งที่ The Natureof Software Development ไมไดอธิบายถึงอีกAgile Framework แตขอคุณใหคิดถึงสิ่งที่ตองทําใน software project โดยเฉพาะ“Agile” software project เพื่อที่คุณจะสามารถทํางานใน frameworks ที่คุณเลือกได
- 86. คําแนะนําเกี่ยวกับ frameworks ● โครงรางสําหรับproject ของคุณตองการใหพอดี ทุกคนการตองการพื้นที่อิสระ เพื่อ โตตอบในรูปแบบที่ไมไดพิจารณาโดยกรอบใด ๆ และที่ไมสามารถออกคําสั่งไดตามกฎ ● ถาคุณมีโครงการขนาดใหญที่มีจํานวนคนมาก คุณจะตองมีกระบวนการมากกวา แต อยางไรก็ตาม ใช retrospectives เพื่อตัดสินใจวาควรจะเพิ่มอะไร เพิ่มองคประกอบของ กระบวนการเปนแบบทดสอบใหชัดเจนวาคุณคาดหวังอะไรจากการเปลี่ยนแปลงและ ตรวจสอบดูวาคุณไดรับหรือไม ถาคุณทําไมไดหรือคุณไดรับผลกระทบที่ไมพึงประสงค บางอยางใหเปลี่ยนแปลงครั้งตอไป
- 87. คําแนะนําเกี่ยวกับ frameworks (ตอ) ●ควบคุม framework หามให framework ควบคุมคุณ สราง framework ใน project ของคุณใหมีประสิทธิภาพ อยางไรก็ตามอยางเปลี่ยน framework เพราะจะทําใหเกิด ปญหา ● ปรับปรุงกระบวนการในการทํางานใหเหมาะสมกับทีม ไมมีใครไดเปรียบกวาใคร คุณ ควรจัดการ project ของคุณโดยการสังเกตคนในทีม ไมควรเจาะจงใครเปนพิเศษแตให มองในภาพรวม
- 88. คําแนะนําเกี่ยวกับ frameworks (ตอ) ●ใหการเรียนรูเปนสิ่งสําคัญ อยางที่เราเห็นในหนังสือเลมนี้ทักษะเปนสิ่งสําคัญ จําเปนตอง มีทุกทักษะในการสรางโปรเจคหนึ่งๆขึ้นมา และตองจัดวางคนใหเหมาะสม บางทีอาจจะ ตองมีการอบรมเพื่อเสริมทักษะที่มีอยูใหมากขึ้น เพื่อใหการทํางานมีประสิทธิภาพมากขึ้น ตาม ● การทํางานใหไดดีนั้นไมไดใชแคการคาดการณและควบคุมเพียงเทานั้น แตตองมีการ สังเกตอยูเสมอเพื่อใหสามารถตอบสนองตอเหตุการณตางๆไดทันทวงที อาจจะมีการวาง แผนงานสํารองเอาไวหากเกิดขอผิดพลาดขึ้นมากะทันหัน ความสําเร็จของงานจะขึ้นอยู กับทีม
- 89.
- 90. Scaling Agile ปจจุบันมีความสนใจใน “scaling”บริษัทขนาด ใหญเคยไดยินคําพูดBuzzzword Agile และความคิด ที่ดีในอดีตเชน Six Sigma และ TQM ตอนนี้พวกเขา ตองการที่จะกาวไปขางหนา Agile มันเปนสิ่งที่ตองทํา แตพวกเขาเปน บริษัท ขนาดใหญ ดังนั้นพวกเขาคิดวา พวกเขาจําเปนตองปรับ แตปรากฎวาในหลายกรณี พวกเขาผิด พวกเขาไมจําเปนตองปรับ พวกเขา ตองการพัฒนาซอฟตแวรดวย Agile อยางเรียบงาย Scaling Agile กลายเปนธุรกิจที่ดีที่จะเขามา เพราะคนอื่น ๆ คิดวาจําเปนตองใช มีตลาดที่เหมาะสม สําหรับ Scaling Agile อยูเสมอ ดังนั้นจึงมีแนวทางที่จะ ดําเนินการอยูเสมอ ขณะนี้ตลาดสําหรับ Agile เติบโต ขึ้นเรื่อยๆ
- 91. คุณไมสามารถไดสิ่งที่ตองการเสมอไปหรอก... แตนาเสียดายที่ในกรณีนี้มีการฝกอบรมที่มีราคา แพงเพื่อใหตัวเองเปน Scaling Agileแตสุดทายพวก เขาจะไดรับผลประโยชนบางอยางแนนอน ความสนใจ ที่จะปรับปรุงมักจะดีกวาการไมมีความสนใจเลย
- 92. Agile นั้นเรียบงาย..แตมันแคไมงาย Agile คอนขางงายAgile เปนที่ไดรับความนิยม มากที่สุด Scrum มีบทบาทเพียงสามอยาง คือกิจกรรมที่ หยิบยื่น และสิ่งประดิษฐที่สําคัญๆอยางหนึ่งที่เรียก วาการทดสอบซอฟตแวร มันไมไดหมายความวา Agile เปนเรื่องงาย ยังคง เปนเรื่องยากที่จะตัดสินใจวาจะให product ใดเปนที่ พึงพอใจและยังคงยากที่จะเขียนซอฟตแวร
- 93. Agile ตองเรียบงาย ไมเชนนั้นก็ไมใชagile Chet Hendrickson ชี้ใหเห็นวา Agile ใชงาน ไดงาย Agile ที่ปรับเปนแบบเรียบงาย มิฉะนั้นจะไมมี Agile อีกตอไป เราควรมองวา “Scaled Agile” ซึ่งมีค วามซับซอน ในขณะเดียวกัน Arlo Belshee แสดงใหเห็นวา หากทีมพัฒนาของคุณมีความชํานาญในการพัฒนา ซอฟตแวร Agile การปรับไมใชปญหา ถาทีมงาน ทั้งหมดของคุณสามารถตัดเรื่องราวเล็ก ๆ และนําเสนอ ซอฟตแวรที่ปราศจากขอบกพรอง จากนั้น “scaling” ไดงาย Diana Larsen และ Jim Shore ผูคิดคนใน บริบทนี้ทําใหประเด็นคลายกัน
- 94. ถาทีมของคุณเปน Agile จริงๆ... ทีมAgile ทํางานทุกวันกับเพื่อนรวมธุรกิจ (Agile Manifesto Principle 4) พวกเขาสงซอฟตแวรทํางาน บอยๆทุกๆสองสัปดาห (หลักการที่ 3) (หลักการที่ 7) ทํา งานอยางยั่งยืน (หลักการ 8) และใหความสําคัญกับ ความเปนเลิศดานเทคนิคและการออกแบบที่ดี (หลักการที่ 9) และอื่น ๆ
- 95. หมายถึงเปน Agile จริงๆนะ... ทีมAgile ที่ชํานาญหลังจากเจอขอผิดพลาด เมื่อ เริ่มตนใชงานทําใหเกิด features ที่สอดคลองกันและ ทําใหขอบกพรองอยูในระดับที่ตํ่ากวาทีมเดียวกัน ทีม Agile ที่ชํานาญอยางเห็นไดชัด พวกเขาได รับสิ่งที่ทําอยางแทจริงในจังหวะที่สอดคลองและ สามารถคาดเดาได หากทีมงานของคุณทําตามนั้น … คุณอาจจะทําเสร็จไปแลว
- 96. จริงๆ หากทุกสิ่งทุกอยางที่คุณทําถูกสรางขึ้น โดยทีมเล็ก ๆเดียวกันScaling Agile จะลดลงเพื่อให แตละทีมเรียนรูที่จะสราง Agile จากนั้นจึงขอใหพวก เขารวมงานกับผูที่เปนนักธุรกิจเพื่อเปนแนวทางกับสิ่งที่ พวกเขาจะสรางขึ้น Agile Scaled ไมมีอะไรพิเศษนอกเหนือจาก พื้นฐานที่ยากพอสมควร เราไดสํารวจในหนังสืออื่นๆ แตคุณไมจําเปนตองดําเนินการเปลี่ยนแปลง Agile ขนาดใหญที่คุณตองทํา
- 97. จะทําอยางไรหากตองการใหมีทีมมากกวาหนึ่ง ทีม Agile ที่สามารถทําสิ่งนี้ไดอยางแทจริงจะ ทําใหเกิดหลายfeatures ในทุกๆสองสัปดาห ไมใช เรื่องงายเลยที่จะทําใหทีมมีความสามารถเชนนี้: คุณ ตองมี product จํานวนมากที่จะทํา แตบางทีคุณอาจมี product ขนาดใหญ เชนโปรแกรมประมวลผลหรือ โปรแกรมกราฟกสําหรับการแกไขภาพ คุณรูสึกวามี งานมากพอที่จะทําใหทีมตางๆไมวาง เมื่อทีมที่ทํางานเกี่ยวกับ product ของคุณทําให Agile มีคุณภาพแลว จากนั้นใหดูที่อัตราที่สงมอบ ดูวา คุณตองการคุณสมบัติเพิ่มเติมมากกวานี้หรือไม
- 98. Feature teams หากยอนกลับไปในศตวรรษที่ผานมา แนวคิด ของfeature team ที่ไดรับการวางแผน คุณลักษณะ เล็กๆของทีมคือ มีหนาที่ในการนําคุณลักษณะตางๆมา สูผลิตภัณฑ เพื่อใหไดคุณสมบัติมากขึ้นคุณจะสามารถ เพิ่มทีมงานที่มี features ครบถวนและซอฟตแวรที่นํา เสนอทั้งหมดลงในผลิตภัณฑเครื่องเดียว หรือตองการ เพิ่ม features อื่นๆ มีไมมากที่เกี่ยวของในการปรับ ถาทุกทีมรู วิธีการทํา Agile ก็จะรูวิธีดําเนินการเพิ่ม feature team และผลิตภัณฑแลวจะสามารถทํางานไดเร็วเทาที่คุณ ตองการได
- 99. Agile teams coordinateusing tests. โปรดจําไววาทีม Agile ทําเปน features ขนาด เล็กจํานวนมากทุกๆสองสัปดาห ทีมเดียวสามารถทํา features ดังกลาวได 15 หรือ 20 features ในการทํา ซํ้าสองสัปดาห พวกเขาจัดการไดอยางไรเพื่อไมให กาวกายกัน? มันกลายเปนเรื่องงาย ทีม Agile ที่คลองแคลวใช test-driven development ในการตรวจสอบ ชวยให ทีมรูวาเมื่อใดที่มีคุณลักษณะครบถวน
- 100. Agile teams coordinateusing tests (ตอ) ถาเรากําลังใชหลาย feature teams ใหทํางานในลักษณะเดียวกัน ทุกครั้งที่สราง feature ใหม ๆ หรือเพิ่ม feature ดวยการตรวจสอบโดยอัตโนมัติ แคทุกทีมทําใหเปรียบ เสมือนเปนทีมเดียวกัน อาจมีความขัดแยงระหวางสิ่งที่ทํากันในทีม? อาจจะเกิดขึ้นไดและทีมงานจะประสานกัน เพื่อดูวาเกิดอะไรขึ้น ทีม Agile ทําแบบนี้แนนอน พวกเขาเรียนรูที่จะคอยๆทําเปนชิ้นเล็ก เมื่อพวกเขาทํางานที ละนิด พวกเขาก็จะยิ่งทํางานไดละเอียดมากขึ้น เมื่อพวกเขาแบงงานเปนชิ้นเล็ก มันจะทําให งายในการคนหา
- 101. แลว infrastructure ละ? หากผลิตภัณฑของคุณมีขนาดใหญพอที่จะใช หลายๆFeature teams พวกเขาจะอาศัยโครงสราง พื้นฐานทั่วไปบางอยาง หากเปลี่ยนเปนสิ่งนี้ละ? ทีม Agile เปลี่ยนโครงสรางพื้นฐานตามที่ ตองการ พวกเขาทํางานอยางอิสระทุกสองสัปดาหโดย การสนับสนุนการเปลี่ยนแปลงของตนเอง Feature teams สามารถทําสิ่งเดียวกันกับแตละ ทีม โดยแตละทีมสามารถเปลี่ยนแปลงไดตามความ ตองการและมีการตรวจสอบ code บอยๆ อยาลืมวาคุณไมจําเปนตองมี feature teams เลยหากแตละทีมของคุณสามารถทํา Agile ได แตถาคุณทําเชนนี้ คุณจะไมจําเปนตองมีโครงสรางพื้นฐานพิเศษเพื่อใหมีทีมที่มีคุณลักษณะเฉพาะ คุณจําเปนตองมีทีมที่มีอํานาจหลายคน ที่สามารถและจะประสานงานกันเองตามความจําเปน
- 102. So far, sogood บริษัทที่ทํางานไดโดยทีมเดียวไม จําเปนตองมีอะไรที่พิเศษ ในองคกรสวนใหญที่ฉันเคยเห็น สวนใหญ จะทําโดยทีมงานเดียวกันแลวในไมกี่ปที่ ผานมาฉันไดเห็นผลิตภัณฑที่มีการ ผสมผสานเขาดวยกันและมีขนาดใหญ เพียงพอที่จะใช feature teams ได
- 103. Giant efforts ความพยายามที่มีขนาดใหญโดย เฉพาะอยางยิ่งกับนักพัฒนาซอฟตแวร หลายรอยคนบางทีอาจจะเปนพัน ๆคนการ ทํางานในสิ่งหนึ่งสิ่งใด หากคุณไมไดอยู ใน บริษัท เชนนั้นบางทีสิ่งที่คุณตองทําคือ การทําใหแตละทีมของคุณสามารถทํางาน ไดอยางคลองตัว
- 104. อยางแรก คอยๆสราง giant หากคุณกําลังเริ่มตนgiant effort วิธี มาตรฐาน Agile ก็ทํางานไดดี เริ่มตนดวย ทีมเดียว สรางมันใหใหญขึ้น สรางและ ขยายโครงสรางพื้นฐานในขณะที่คุณไป เพิ่ม feature teams ตามที่คุณตองการ
- 105. สุดทายแลว แบง giantออกมาซะ แมใน giant efforts เกือบทุกอยางที่ทําจะถูกทํา โดยทีมเดียว เรารูอยูแลววาจะทําอยางไร แมใน giant efforts การเพิ่มทีมทํางานเขาไปก็ สามารถชวยไดเหมือน feature team สวนใหญแลวฉันไมคิดวาจะมี giant effort ที่ไม สามารถถูกลดลงไดหรอกนะ ถาจะมี ก็เพราะไมมีใครรู วาจะทําอยางไร ถาเราทราบวิธีแบงงานแลวเกือบตลอดเวลางาน สวนใหญสามารถทําไดโดยใช Agile
- 106. Bottom line หากทีมงานแตละทีมของคุณไม สามารถทํางานในแบบ Agileไดอยาง ชัดเจน คุณยังไมพรอมที่จะ “เปลี่ยน” ขั้น แรกใหเริ่มสรางทีมที่มีความสามารถใน การทํา Agile จากนั้นใหความสําคัญกับ งานที่มีคาที่สุดเพื่อใหองคกรของคุณ สามารถเกิดขึ้นได และสรางทีม Agile โดย จัดระเบียบตาม features ที่เปนไปได คุณ อาจพบวาคุณไมจําเปนตองใช Scale Agile
- 107.
- 108. ลองจินตนาการวาคุณกําลังปนภูเขาที่ชื่อ การพัฒนา Software ซึ่งคุณอาจเปนนักปนเขาหลายระดับทั้งมือใหมที่รออยูที่ตีน เขา หรือมีประสบการณอยูแลวที่มีอุปกรณและความรู ครบครันหนังสือเลมนี้จะชวยใหเห็นเสนทางบนภูเขาและ สามารถบอกไดวาเสนทางไหน ที่ปลอดภัยและเสนทางไหนอันตราย สิ่งเหลานี้ทําใหคุณ สามารถเพิ่มการเดินทางของคุณเอง บางครั้งรางวัลเปน เพียงการปนเขาที่ทําใหคุณมีทักษะมากขึ้นและมากขึ้น สําหรับผมผมคิดอยางนี้นะ แลวคุณละ คิดอยางไร? ขอบคุณที่อาน
- 109. Reference Ron Jeffries, 2015,The Nature of Software Development Process