สรุป
“ The Nature of
Software
Development
Process ”
โดย Alpaca Group
Alpaca Group Members
นางสาวชนาภา ชูวิเศษวณิชย 59130500015
นายชวนันท อัครประถมพงศ 59130500017
นายณัฐภัทร กิตติเกียรติกําจร 59130500027
นายฑัตพงศ อิศรัตน 59130500022
นายธนวัฒน กิตติศิริพันธ 59130500035
นายพงษพันธุ บุญลอม 59130500050
นายพรเลิศ หลอเจริญรัตน 59130500053
นางสาวภรณวรัตน สุวิชาชนันทร 59130500062
นายภูริภัทร อารยศิริกุล 59130500069
นางสาวสวรส ออกลกิจ 59130500099
Part 0: Introduction
“Software is lava”
การพัฒนาSoftwareเปนงานที่อันตราย
ยากและซับซอน(เปรียบกับลาวา) เราจึง
ตองการเสนทางที่จะทําใหเราสามารถขาม
ผานลาวาไดอยางปลอดภัย ซึ่งเราเรียก
เสนทางนั้นวา Natural Way
“Natural Way”
เสนทางในการพัฒนา Software ที่คํานึง
ถึงValueเปนสิ่งสําคัญ ซึ่งจะทําใหสามารถ
พัฒนา Software ที่ตรงกับความตองการของผู
ใชงานได โดยไมหลงทาง ซึ่งดีกับทุกฝาย
- ผูใชงาน: ไดรับงานที่มีคุณภาพอยาง
รวดเร็ว
- ธุรกิจ: ไดกําไรเร็ว เพราะมีการจัดลําดับ
ความสําคัญในการทํางาน
- การจัดการ: จัดการไดงาย
- ผูพัฒนา: รูลําดับงานและความตองการ
อยางชัดเจนกอนลงมือทํา
“Simple but Not Easy”
ตองคิดอยูเสมอวาอะไรคือสิ่งที่เรา
ตองการ เรียนรูในสิ่งที่จะทํา และทํามัน
อยางงาย โดยโฟกัสที่สงตอคุณคาที่
สามารถมองเห็นไดอยางสมํ่าเสมอ
Part I: The Circle of Value
วงกลมแหงคุณคา
“ความสําเร็จในการพัฒนาsoftwareเปน
เรื่องยาก และมันก็ยากเสมอที่จะทํา...”
Chapter 1
“ The Search for
Value ”
คนหาคุณคา
กระบวนการทํางาน
Guiding
ทุกคนในทีมตองรูและเขาใจตรงกันวาตองการอะไร มี
เวลาเทาไหรในการทํา
Organizing
แบงงานดวยfeature โดยดูจากความสามารถในการ
ทํางานตามแผน และจะตองจัดคนใหเหมาะกับงาน
Planning
จัดลําดับความสําคัญของfeature โดยดูวาอันไหน
สําคัญที่สุดใหยกขึ้นมาทํากอน
Value = สิ่งที่เราตองการ
ทุกอยางเกิดขึ้นไดเพราะValue ซึ่งValueอาจเปนเงิน
ความสุข หรือการใชชีวิตก็ได
กระบวนการทํางาน
Slicing
ลดขนาดงานใหเล็กลงเพื่อใหสามารถสงงานไดเร็วขึ้น
และพรอมสงงานตลอดเวลาเมื่อdeadlineมาถึง
Quality
ทํางานใหมีคุณภาพตลอดเวลา สงงานที่มีคุณภาพได
อยางตอเนื่อง
Building
การลงมือทํา โดยทํางานเปนชิ้นตามความสําคัญ จะ
ทําใหการสงคุณคาเร็วขึ้นและบอยขึ้น
Chapter 2
“ Value is What
We Want ”
Value คือ สิ่งที่เราตองการ
“เราตองการvalue และvalueคือสิ่งที่เราตองการ”
Valueสวนใหญเกี่ยวกับเงิน เวลา
และการใชชีวิต เมื่อทําเสร็จจะตองตรวจ
สอบวาเราไดสิ่งที่เราตองการหรือไม เพื่อ
เช็ควาvalueที่ไดมานั้นตรงกับความ
ตองการจริงๆ
Valueจะเกิดขึ้นเมื่อเราเริ่มสง
software ดังนั้นจึงตองหาวิธีเพื่อสง
softwareใหเร็ว
เราไมสามารถทําทุกอยางใหเสร็จตอนนี้
ถาเรามีfeatureมากจะยิ่งใชเวลามากในการ
พัฒนา
“คุณคาเกิดขึ้นไดในสิ่งที่เราเลือกจะทํา”
เลือกfeatureที่มีคุณคา ราคาถูกมา
ทําเปนอันดับแรก แตบางครั้งงานก็ออกมา
นาเบื่อ
เมื่อเราเริ่มทําจากfeatureที่มีคุณคา
สูงสุดเสร็จแลว เราสามารถสรางnew
productขึ้นมาตอยอดของเดิมได ซึ่งเปน
สิ่งที่นาสนใจมากกวา
“ คุณคาที่ดีที่สุดเกิดจากสิ่งเล็กๆ
คุณคาโฟกัสดวยfeatureและ
ความถี่ในการสงมอบ ”
Chapter 3
Guiding Goes
Better
“Feature by
Feature”
“สิ่งแรกที่เรารูเมื่อเริ่มทําโปรเจ็กตคือ Deadline”
Deadline: เสนสีนํ้าเงิน
Plan: ดาว
สิ่งที่สามารถทําไดเปนอยางนอย: เสนแดง
เราไมสามารถมีทุกอยางได แตเราตอง
จัดการวางแผนวาอยางนอยสิ่งที่ตองทําได
คืออะไร และไปใหถึงจุดนั้น กอนที่จะพัฒนา
ตอตามแผนที่เรากําหนดไวหากยังมีเวลา
เหลือ
“activity-based”
โปรเจ็กตสวนใหญใชกระบวนการเปนพื้นฐาน โดย
แบงเปน4ขั้นตอน คือ วิเคราะห ออกแบบ เขียนโคด
ทดสอบ
ซึ่งจะดีถาสามารถวิเคราะหไดตามแผน แตวามันไม
สามารถวิเคราะหวาทําแบบไหนถึงจะดี และไมสามารถ
บอกจุดเริ่มตนของกระบวนการตอไปไดวาจะเริ่มเมื่อไหร
ในหลายๆครั้งเรามักใชเวลามากกวาที่เราคิด
เปนการทํางานแบบmonolith ที่วางแผนทุกอยางไวแลว
คอยทําทีเดียว ซึ่งบางครั้งก็ไมตอบโจทยสิ่งที่ตองการ และ
เสียเวลาโดยเปลาประโยชน
“Deliver feature by feature”
สามารถทํานายชวงเวลาการทํางานไดวาขั้นตอไปจะเริ่มเมื่อไหร และใหคุณคา
กับลูกคาไดเร็วกวา รวมทั้งใหผลที่ดีกวา
Chapter 4
“Organizing by
Feature”
จัดการดวยfeature
“Team build features”
แบงทีมทํางาน โดยแตละทีมจะตองมีคน
ที่ถนัดในแตละดานอยูดวยกัน ไมควรจัดทีมที่
แบงความถนัดเปนเรื่องๆ เพราะจะไมสามารถ
ทําใหงานกาวหนาได
“Communities of Practice”
ในกรณีที่มีผูเชี่ยวชาญไมพอ ใหแบง
กลุมกันเรียนรูและเรียนรูไปดวยกัน โดยผูที่
จะนําสอนอาจจะเปนคนที่อยูในทีมเดียวกันที่
สามารถทําไดหรือมีความสามารถอยูแลว
มาสอนเพื่อนในทีม
“Scaling”
การแบงทีมทํางาน จะทําใหสามารถมอง
เห็นวาอะไรเปนสวนที่สําคัญและทําใหงาย
ขึ้นในการทํางาน รวมทั้งสามารถตัดงานที่ไม
จําเปนออกได
Chapter 5
“Planning Feature
by Feature”
วางแผนทีละfeature
“Planning”
การวางแผนเปนสิ่งสําคัญ เราจะวางแผนแคคราวๆแตจะไมลงรายละเอียดวาอะไรจะ
เกิดขึ้นและเกิดขึ้นเมื่อไหร เมื่อถึงเวลาคอยตัดสินใจวาจะทําอะไรตอ การที่ลงรายละเอียด
ตอนวางแผนเปนการเสียเวลาและกอใหเกิดความเครียด
“Getting Started”
เริ่มดวยไอเดีย คิดสักเล็กนอย จัดตั้งทีม เริ่มลงมือทํา สามารถบอกไดวาเราจะสรางอะไรที่
ใหคุณคา ใชเวลานานเทาไหร ซึ่งทําใหตัดสินใจไดวาจะลดคาใชจายหรือวางแผนอยางไร
ตอไปใหไดคุณคามากขึ้น
Idea Think Team Build
“Feature Splitting”
การวางแผนแคตอนตนไมใชสิ่งที่ดีเทาไหร
เพราะเราตองการคุณคา เราจึงตองวางแผน
ตลอดเวลา ซึ่งเราเรียกการทํางานแบบนี้วา
Iteration/Sprints ซึ่งใชเวลา2สัปดาห โดยเรา
ตองมีS◌ัtoryเปนตัวกําหนดการทํางาน ซึ่งถา
ใหญมากๆเราจะแบงเปนสวนยอยที่เรียกวา
Tasks ซึ่งคนทั่วไปอาจมองtasksไมคอยเขาใจ
ซึ่งบางครั้งทางเทคนิคอาจใชการแบงเปน
featyreยอยเพื่อใหคนทั่วไปสามารถเขาใจได
“Plan often, don’t overeat”
ทีมจะตองตัดสินใจวาจะทําอะไรบางใน1
รอบการทํางาน2สัปดาห และตัดสินใจวาจะทํา
อะไรตอไป ในบางครังก็ใชเวลาคุยมากเกินไป
ทําใหเหลือเวลานอยในตอนทาย ซึ่งจะทําใหเกิด
ความกดดัน และมีภาระงานที่ตองทําเยอะ ดังนั้น
จึงควรเลือกงานที่ใหคุณคาสูงมาทํากอน
Chapter 6
“Building the
Product,
Feature by Feature”
ลงมือทําทีละfeature
“ทํางานใหเสร็จในแตละรอบการทํางานยอย”
วางแผนและจัดการโปรเจ็กตในรอบการทํา
งานสั้นๆซึ่งจะไดงานที่เสร็จแลวในแตละรอบ
ในแตละรอบเราจะไดเรียนรูการทํางานที่
ชัดเจนซึ่งทําใหเราไดงานที่มีประสิทธิภาพออก
มา
“Identify real progress”
การทํางานแบบfeatureจะรวมการทํางาน
ทั้งระบบไวในแตละรอบการทํางาน ทั้งการ
เก็บความตองการ ออกแบบ เขียนโคด และ
ทดสอบ ซึ่งจะดีกับการทํางานของเรา เพราะมี
ประสิทธิภาพ ปลอดภัยและชวยฝกฝน
เมื่อเราดูงานที่เสร็จจริงจะทําใหเขาใจและรู
ถึงเงื่อนไขของโปรเจ็กตเรา ถาเราไมสามารถดู
featureไดหรือทําไมเสร็จเราก็จะไมรูวาอะไรจะ
เกิดขึ้นตอไป
“Eliminate the test and fix finish”
หลายโปรเจ็กตจบดวยการทดสอบ เราตอง
เรียนรูวิธีที่จะลดเวลาการทดสอบลง เพื่อความ
มั่นใจเราควรตรวจอบทุกอยางตลอดเวลา เพื่อให
งานที่สงออกไปมีคุณภาพและไมเกินกรอบเวลาที่
กําหนดไว
“Grow and refine design”
ถาเราออกแบบมากเกินไป เราจะมีfeature
ไมมาก แตถาเราออกแบบนอยไปfeatureจะยาก
ที่จะทําและทําใหงานชา
เราตองหาขนาดที่เหมาะสมกับงานที่จะทํา
โดยใชเทคนิคที่เรียนรูไดงาย และไมกดดันมาก
จนเกินไป
Chapter 7
“Build Features
and
Foundation in
Parallel”
ลงมือทําเปนลําดับ
“Solid Infrastructure”
ถาไมมีการออกแบบที่ดี การทํางานจะเปน
ไปไดยาก และทํางานไดชา featureจะตองรอง
รับโครงสรางพื้นฐานและโครงสรางพื้นฐาน
ตองการการออกแบบที่ดี ซึ่งเราไมสามารถสราง
featureไดโดยไมมีโครงสรางพื้นฐาน
“อุดมคติ...”
ทางอุดมคติมองวา เราสามารถสงfeature
ที่เสร็จแลวทุกfeatureในระยะเวลาที่กําหนด
เราตองตัดสินใจวาเราควรออกแบบอะไรกอน
หรือเราควรสรางทุกfeatureแบบเต็มรูปแบบ
ในเวลาเดียว
“การทํางาน”
ออกแบบกอน จะใชเวลามาก
ในการทํา ซึ่งทําใหfeatureที่
สามารถสงตอไดมีจํานวนนอยเมื่อ
ถึงกําหนดเวลา
เมื่อเราสรางfeatureที่
สมบูรณตอจากอีกfeatureจะ
ทําใหบางสวนที่สําคัญหายไป
เมื่อหมดเวลาการทํางาน
สรางฟงกชันที่งายๆกอน
ในตอนแรก เพื่อใหได
productที่ดีในขณะที่ยังมี
เวลาเหลือ
“Steer to best result”
แยกการทํางานเพื่อใหไดผลที่ดีที่สุด
โดยตัดสินใจในการสงงาน เพราะเราพรอม
ตลอดเวลา เราสามารถสงงานไดอยาง
รวดเร็ว
Chapter 8
“Bug-Free and
Well Designed”
ไมมีBug และมีการออกแบบที่ดี
ทํางานตามfeature ตามรอบ
เวลาที่กําหนดไว เปนวิธีที่ดีที่สุดที่จะ
ทําใหงานสําเร็จ
เมื่อเราวางแผนจัดการดวยfeature เราจะบอกวา
เสร็จเมื่อfeatureนั้นสามารถทํางานได ซึ่งเราไมสามารถ
บอกไดวาอะไรจะเกิดขึ้นระหวางการทํางานบาง
การทดสอบและแกบัคใชเวลานาน ถาเราตัดสินใจวาจะใชเวลาตอนทายในการจัดการ
จะทําใหแผนที่จะทํางานใหมถูกรบกวนและยังตองตัดสินใจอีกวาจะแกปญหานั้นอยางไร
“Test-Driven Development”
เขียนtestกอนลงมือทํา ทดสอบทุกรอบการ
ทํางานและทดสอบบอยๆเพื่อไมใหเสียเวลากับ
การแกบัคในตอนทาย เพราะเมื่อพบขอผิดพลาด
ก็สามารถแกไขไดทันที โดยมี2ระดับในการ
ทดสอบคือผูใชงานและผ◌ูพัฒนา
หลังจากทดสอบแลวบางครั้งอาจตองมีการ
ปรับเปลี่ยนโครงสรางเพื่อใหการทํางานดีขึ้นกวา
เดิม
Chapter 9
“Full Circle”
ไมมีBug และมีการออกแบบที่ดี
Building
ลงมือทําจากสิ่งเล็กๆ ซึ่งทํางานไดอยางถูกตองและมี
การออกแบบที่ดี
Development
สงfeatureที่ทํางานไดจริงที่ผานการทดสอบแลว มีการ
ออกแบบที่ดี
Managing
การจัดการโดยดูจากvalueจะดีกวาจัดการดวยวันที่ ที่
ไมสามารถสงมอบคุณคาได
Planning
การวางแผนดวยfeatures จะทําใหรูสิ่งที่ตองการ และ
วางแผนเพื่อทําใหงานที่เคยสงไปแลวดีขึ้น
Value
สิ่งที่ตองการ featureสงมอบคุณคา ยิ่งสงเร็วเทาไห
รยิ่งใหคุณคาหรือสิ่งที่ตองการไดเร็วเทานั้น
Part II: Notes and Essays
บันทึกและเรียงความ
“Good work is simple but, it is not easy...”
Chapter 10
“Value—
What Is It?”
คุณคา...คืออะไร?
ที่คุณบอกวา valueคือ
สิ่งที่เราตองการ แบบนี้
มันก็เปนแคเปลือกสิ แลว
แทที่จริงvalueคืออะไร
กันแน??
ใชแลว แตในกระบวนการพัฒนา
software เราตองตัดสินใจวาอะไร
คือสิ่งที่เราตองทําหรือไมทํา โดย
เอาvalueเปนพื้นฐาน โดยเราจะ
เลือกเอางานที่ใหvalueสูงมาทํา
กอน
จุดประสงคของผมคือชวยใหคุณ
เห็นvalueในความเปนจริง ซึ่งก็คือ
อะไรก็ตามที่คุณตองการ หรือเปน
สิ่งที่คุณใหความสนใจ...
Information
ขอมูลที่ผูใชตองการ ดังนั้นเรา
อาจทําPrototypeแลวเอาไป
เสนอใหผูใชที่เกี่ยวของ
Human life
จุดประสงคของผลิตภัณฑอาจ
เปนการชวยชีวิตคน เรา
ตัดสินใจในการทําfeatureตอ
ไปโดยอาศัยจํานวนของผู
รอดชีวิต
Product speed
พัฒนาใหมีความเร็วมากขึ้น
เพื่อใหสามารถแขงขันกับคูแขง
ไดและตอบโจทยความตองการ
ของผูใชงาน
People’s happiness
ทําใหผูใชงานมีความสุข
Rapid progress
กระบวนการอาจใชเวลานาน
กวาจะไดบางสิ่งออกมา เราจึง
ตัดสินใจเลือกบางfeatureออก
มาทํากอนซึงจะทําใหเห็นผลเร็ว
ขึ้น
05
01
02 03
04Value
Product owner คือ ผูที่ตัดสินใจลําดับในการทํางานวาอะไรสําคัญมาก-
นอยหรือทํากอน-หลัง ที่จะใหผลที่ดีที่สุดที่อาจเกิดขึ้นได
อะไรก็ตามที่ตองการ
Chapter 11
“Value—How Can
We Measure It?”
คุณคา...เราจะวัดมันไดอยางไร?
แตคุณบอกวาvalueคือ
สิ่งที่แตละคนตองการ
แลวแบบนี้เราจะวัดคา
ใหเปนตัวเลขที่แนนอน
ไดอยางไร?
เราจําเปนตองใชตัวเลขในการวัด
เพราะเราจําเปนตองคํานวณคาใช
จายที่จะใชเพื่อดูวาคุมคาหรือไม
ซึ่งเราไมสามารถบอกเปนตัวเลขได
วาจะมีผูใชงานเทาไหร ไมรูวาผล
ตอบรับจะเปนอยางไร รวมทั้งไมรู
วาผูใชจะซื้อproductของเรามั้ย
“เราจะวัดvalueไดอยางไร”
1. ถามตัวเองวาจะทําอะไรตอไปที่จะใหคุณคา
กับงานของเรา
2. ถามตัวเองวาทําไม แลวถามผูที่เกี่ยวของวา
เห็นดวยหรือไม
เมื่อสวนใหญเห็นดวยก็เดินหนาทําตอ แตถาไมก็
พยายามหาคนที่เห็นดวย ไมก็พยายามแกไขโดย
เพิ่มfeatureที่ตรงกับความตองการของผูใชงาน
ใหมากขึ้น จากนั้นก็ลงมือทํา สงใหตรงเวลา และ
ฟงความเห็นของผูใชอยางสมํ่าเสมอ
Chapter 12
“Of Course
It’s Hard!”
แนนอน...วามันยาก!
ที่คุณบอกมันดูเขาใจ
งาย ใหเราสนใจและทํา
ทุกอยางโดยยึดvalue
เปนหลัก ซึ่งมันดีมาก
แตมันยากเหลือเกิน ยาก
มากๆ
แนนอนวามันยาก เรามีขั้นตอนการ
ทํางานดังนี้
- สนใจในvalueเราจะไดผลที่
ดีที่สุด
- สรางsoftwareจริง จะรูวา
อะไรคือสงที่เราตองการ
- ลงมือทําที่ละขั้นเล็กๆ จะเห็น
วาเราควรทําอยางไร
- เรียนรูการวางแผน จัดการ
และทักษะเฉพาะ ซึ่งทําให
เราสรางproductที่ดีและมี
คุณภาพ
“ยังไงก็ยังยากอยูดี”
แนนอนวามันยาก แตเราไมตองการขั้นตอน
การทํางานที่ซับซอน ไมมีการจํากัดวาวิธีไหนดี
ที่สุด เราตองทําใหมันงายแตมีคุณภาพ
ซึ่งการทํางานแบบนี้เราตองตัดสินใจตลอด
เวลา ซึ่งเปนเรื่องยาก แตจะทําใหทีมมีพลังมาก
ขึ้นและทําใหการทํางานเร็วขึ้น
Chapter 13
“Not That Simple”
ไมใชเรื่องงาย
มันไมใชเรื่องงาย คุณ
คิดวาฉันโงมั้ย?
แนนอนวามันไมงาย เราตอง
พยายามทําใหมันใกลเคียงกับ
ความงายมากที่สุด
เรากําลังพยายามทําตาม
แนวคิดงายๆ โดยเนนที่valueเปน
หลัก เพื่อดูวามีอะไรกําลังจะเกิดขึ้น
เราตองตัดสินใจวาเรา
ตองการอะไร สิ่งที่เราตองการจริงๆ
โดยการสรางสิ่งตางๆและมอง
วิธีการทํางานใหออก
Chapter 14
“Creating Teams
That Thrive”
สรางทีมที่เจริญเติบโต
“เปาหมายมาจากBusiness”
Product Ownerเปนคนที่ชวยนําทางวาจะทํา
อะไรตอไป โดยบอกรายละเอียดที่ตองการมาให รวม
ทั้งบอกปญหาที่ตองการแกไข
ซึ่งทีมจะเปนคนลงมือทําตามที่Product Owner
ตองการ แตตองมั่นใจวาทุกคนเขาใจตรงกันวาตองทํา
อะไรเพื่ออะไร และจะแกไขปญหาอยางไร
ในขั้นแรกมักยากเสมอ แตเมื่อทํางานไปในแตละ
รอบจะทําใหเห็นวาเราทําอะไรไบางและจะทําใหดีขึ้น
ไดอยางไร
Chapter 15
The “Five-Card
Method”
for Initial
Forecasting
Prepared
“Five-Card Method”
ทํานายการทํางานขนาดใหญได ไมไดใหรายละเอียดมากนักแตก็ทําใหทีมรูวาตองทํา
อะไรและจะทําอยางไรใน1สัปดาห
- หาสิ่งที่สําคัญ3-5อยาง ซึ่ง1การดจะมี1ประโยคเทานั้น
- แบงละชิ้นใหญใหเปนสวนยอย3-5ชิ้น อาจแบงเปนfeatureแตไมใชเปนความคิดดาน
เทคนิค
- ทําจนกวาทุกfeatureมีขนาดเทาๆกัน หรือเล็กพอที่จะทําได โดยเลือกทําfetureที่มีvalue
สูงกอน ตองจําไววาการจัดการตองมีความรอบคอบ ตัดสินใจไดวาจะทําอะไรกอน-หลัง
Chapter 16
“Managing Natural
Software
Development”
การจัดการกระบวนการพัฒนา
software
“อะไรคือการจัดการ?”
ในปกติการทํางานของเรา Product Champion จะตองการระบุทิศทางและการทํางาน
กับผูมีสวนรวมและสมาชิกในทีม เพื่อกําหนดลําดับความสําคัญ ทีมจะแสดงซอฟตแวรของเรา
ในทุก ๆ2สัปดาห นั่นเพื่อใหเราบอกทุก ๆคนไดวาเรากําลังจะทําอะไร เพื่อชวยใหทีมตัดสินใจ
ไดวาตองการความชวยเหลืออะไรไหม
ทีมของเรามีทักษะและความสามารถในการสงมอบซอฟตแวรแตละชิ้นที่เพิ่มขึ้น เราเขา
ใกลเปาหมายที่เราวางไวมากขึ้น การประสานงานที่เราตองการนั้นก็นอยลง ทีมที่มีการจัดการ
องคกรของตนเองที่ดี สมาชิกในทีมจะตัดสินใจไดวาจะจัดชุดการทํางานออกมาไดอยางไร
ใหมันออกมาเสร็จสมบูรณ
การจัดการงานใหเสร็จยังคงเปนเรื่องจําเปน
แนนอนวาการคัดเลือกพนักงานจะตองมาจากทีมงานระดับสูงกวา อยางไรก็ตาม การ
ตัดสินใจเกี่ยวกับพนักงานไมวาจะจางหรือเลิกจางนั้น จะตองมาจากผูบริหาร ทีมอาจเสนอ
งบประมาณใหกับ Product Champion การตัดสินใจดานงบประมาณภายในโครงการ
นั่นแหละคือการจัดการ
ผูจัดการบางครั้งสงสัยวาพวกเขาจะลงไปทํางานดวยตัวเองหรือไม ในการจัดการนี้เรียก
วา “การมอบสิทธิ์” ถาผูจัดการสรางทีมที่มีประสิทธิภาพสรางผลิตภัณฑที่มีคุณคา มีวิสัยทัศนที่
ดีผูจัดการคนนั้นจะไดผลลัพธมากกวาที่ลงมือทําซะอีก
ผูบริหารตัดสินใจเรื่องธุรกิจในองคกร
บางที่ผูบริหารจะตัดสินใจเรื่องธุรกิจในองคกรวาจะเปน
ยังไง คืออะไร พวกเขาจะตัดสินใจเรื่องขอกําหนดวาจะทําอะไร
ใหเสร็จ และใครจะทํามันบาง นี่คือจุดเริ่มตนของการวางแผน
เลือกทางแกไขปญหาและมองหาโอกาสที่จะเกิดขึ้น กําหนด
ขนาดของแตละการทํางาใหเหมาะกับเวลา พนักงานและ
งบประมาณ
จากมุมมองโดยธรรมชาตินั้น การวางแผนระยะยาวสามารถ
ทําไดหลายวิธี ผูคนจากหลายสาขาควรมีสวนรวมในกิจกรรม
การวางแผนนี้ : บุคคลฝายการจัดการ,บุคคลฝายการเงิน,บุคคล
ฝายผลิต,บุคคลฝายเทคนิค
การลงทุนลงแรงในระยะยาว
การลงทุนลงแรงในระยะเริ่มตนหรือระยะยาวนั้นขึ้นอยูกับ
เปาหมาย โดยตามธรรมชาตินั้น เราจะสรางฟเจอรที่มีมูลคาสูง
หรือสําคัญไวแรกๆ และผูจัดการสามารถคอยติดตามดูไดโดยไม
ตองลงรายละเอียด ในฐานะนักวางแผนระดับสูงและผูจัดการ
ตองใหชัดเจนในความสามารถทั่วไปที่จําเปนในโครงการขนาด
ใหญของเราและขอถาม Product Champions ของเราถึง “
show us the software” เพื่อใหจัดการครอบคลุมประเด็นสําคัญ
ทั้งหมดของสิ่งที่เราทําเสียกอน จากนั้นคอยใหความสําคัญกับ
สวนที่มีความสําคัญนอยกวาเชนเวลาและเงิน
การวางแผนในระยะสั้น
โดยธรรมชาติแลว การวางแผนในระยะสั้นนั้น
จะมีผลตอเนื่องถึงระดับของการพัฒนา และพวกเขาจะ
ทําตามลําดับโดยทําจากลําดับที่สําคัญมากสุดเปน
ลําดับแรก แผนคือแกไขทุกสองสามสัปดาหและเราทุก
คนสามารถเห็นสิ่งตางๆที่เราจะทําไดชัดเจนยิ่งขึ้น
เราทําแบบนี้ไดงายๆ ทุกสองสามสัปดาห เราจะ
สังเกตสิ่งที่ได และเราวางแผนในอีกสองสัปดาหตอไป
โดยเราจะคํานึงถึงวิสัยทัศนและจุดมุงหมายของการทํา
งานของเรา
ไมไดยึดติดกับแผน
ในความเปนจริงนั้นงานของคุณไมไดยึดติดกับ
แผน คุณตองเลือกผลลัพธที่ดีที่สุดของคุณ โดยไม
จําเปนตองระบุเปาหมายตายตัว
เมื่อสงมอบงานใหลูกคาบอยๆ เราจะพบวาเรา
เราไดทําทุกอยางตามที่ลูกคาของเราตองการเรียบรอย
แลว เรามักจะพบวาแทนที่เราจะจินตนาการถึงสิ่งที่งาน
ของเราควรจะเปน เราควรคิดถึงแนวคิดใหมๆที่
นอกเหนือจากการทํางานตามปกติ
เราตองคอยติดตามถึงการวางแผนในแตละ
ระดับอยางสมํ่าเสมอ วางลูทางแผนงานในการทําวาจะ
ทําอยางไร ถาม Product Champion เพื่อแสดงใหเห็น
ถึงสิ่งที่เราทํา และถามถึงความสัมพวาอะไรคือคุณคา
ของสิ่งที่เราทํา
ผูบริหารระดับสูงยังมีหนาที่รับผิดชอบในองคกร
ทั่วไป พวกเขาจัดสรรเงินและคนใหกับงาน
โดยทั่วไปจะกําหนดงบประมาณ จัดการเลือก
Product Champion และบุคลากร บอยครั้งที่ Product
Champion เลือกสมาชิกทีมหลัก และทีมรวมจะเลือก
สวนที่เหลือ the Product Champion and team
self-organize จะทํางานจนสําเร็จ พยายามที่จะผลัก
ดันการตัดสินใจขององคกร ลงรายละเอียดใหไปได
ไกลใหมากที่สด ใชงบประมาณเพื่อควบคุมขนาดของ
งาน มุงเนนผลลัพธใหมากที่สุดเทาที่คุณจะทําได และ
ชวยใหทุกคนเกิดความใกลชิดกับการทํางานมากขึ้น
ในการตัดสินใจและการจัดระเบียบของสิ่งที่ทํา
เปนไปไดมากวาการกระทําอะไรของบุคลากรจะ
ตองเริ่มตนหรืออยางนอยตองไดรับการอนุมัติจากผู
บริหารกอน แตอยางไรก็ตาม ทางเลือกและคําแนะนํา
ตาง ๆ จะถูกมอบใหกับทีม ปลอยใหทีมของคุณ
พิจารณาวาพวกเขาตองการคนเพิ่มหรือไม
เปนการชวยใหทีมเขาใจปญหาของนโยบาย
โดยรวมจากการจางงาน แนวทาง และยุทธศาสตร และ
ที่สําคัญที่สุดคือคุณคาของการสรางคนที่คุณมีอยูแลว
ของคุณใหดีขึ้น ใหทีมเขาใจไดดีขึ้นถึงภาพใหญๆที่ดี
กวาจะไปหาใหม
การจัดการจะตัดสินใจวา product อะไรที่จะ
ลงทุน พวกเขาเลือก Product Champion ซึ่งจะ
รับผิดชอบตอผลลัพธจัดการดูแตละงานที่ออกมา และ
คอยแนะนํา the Product Champion ใหมั่นใจและ
สนับสนุนวัตถุประสงคของงาน โดยใชเวลาและทิศทาง
ไมกี่รูปแบบ
บางครั้งสิ่งที่เปลี่ยนแปลงในสิ่งแวดลอมหรือตาม
การจัดลําดับความสําคัญของบริษัท การเปลี่ยนแปลง
เหลานี้ถูกสงผานไปในแงของการปรับวิสัยทัศน
ผลิตภัณฑ งบประมาณและอื่น ๆ
บางครั้งสิ่งตางๆอาจไมดีเทาที่ควร การทํางาน
ตามที่เราแนะนําในหนังสือเลมนี้ผูบริหารจะเห็นการ
เบี่ยงเบนที่รวดเร็วและสามารถตอบสนองไดดวยการ
ชวยเหลือ Product Champion และทีมใหดีขึ้น นา
ประหลาดใจมากเมื่อมันเปนสิ่งที่เกือบเปนไปไมได เมื่อ
คุณสามารถมองเห็นผลิตภัณฑไดในทุกสองสัปดาห
สรุป
โดยธรรมชาติของการพัฒนาซอฟตแวรนั้น คือ
การมีอิสระในการมอบอํานาจใหกับคนทํางาน ไมมี
อะไรใหมเกี่ยวกับเรื่องนี้ มันเปนวิธีการจัดการที่ทําได
เสมอ ผูจัดการบางคนลังเลที่จะมอบหมายงานอยาง
เต็มที่ โชคดีที่รูปแบบของการพัฒนาซอฟตแวรนี้มี
มากมายจากการมองเห็นถึงสิ่งที่เกิดขึ้น ทําใหการ
มอบหมายเปนไปอยางรอบคอบ
Chapter 17
“Whip the
Ponies Harder”
ไปไดชากวาที่คิดไว
“Whip the Ponies Harder”
เมื่องานที่ตองทําเริ่มไปชากวาที่คาดหวังไว project manager หลายๆคนจะกระตุนดวย
การบอกใหทํามากขึ้นซึ่งจะทําใหเกิดแรงกดดันขึ้นภายในกลุมพัฒนาซึ่งจะสงผลใหละเลย
การทําเทสและกอใหเกิดขอผิดพลาดตามมา บางขอผิดพลาดที่หลุดไปถึงมือ customer ก็จะ
ทําใหเสีย Value ไป เพราะฉะนั้นในการจัดการปญหานี้ ควรทําตามคําพูดนี้ “Work smarter,
not harder” คือการเริ่มตนจากการหาสาเหตุกอนวางานลาชา เพราะอะไร แลวจึงจัดการกับ
ตนตอเหลานั้นและเราทํางานเพื่อใหได Value ไมใช Cost เพราะฉะนั้นเพื่อที่จะไดเวลางาน
ตองเสร็จ แตตองเสร็จโดยที่ไมเสียหรือลด Value นั้นลงไปเพราะฉะนั้น Don’t “whip the
ponies.” Help them improve. (สิ่งที่จะชวยทําใหทีมสามารถผลิตงานที่มีคุณภาพคือการที่
พวกเขามีสกิลในการทําสูงซึ่งจะไดจากการที่เราลงทุนสงพวกเขาไปเรียนรูในดานนั้นๆ)
Chapter 18
“To Speed Up,
Build with Skill”
เพิ่มความเร็วได โดยใชทักษะ
“To Speed Up, Build with Skill”
สิ่งที่มีคุณคาที่สุดในการพัฒนา Software คือการพัฒนาสกิลของทีมไปดวย ผลลัพธจาก
การลงทุนนี้จะคอยๆแสดงผลลัพธใหเห็นในเวลาไมชา แตจะสูญเสียเวลาไปบางจากการแกไข
ขอบกพรองตางๆของโปรแกรม แตจะทําใหการพัฒนา Software ผานไปไดดวยดีนุมนวล
ไมคอยเจอปญหามาก เพราะทีมที่ทํางานไดเร็วนั้นจะเปนทีมที่ทํางานไดอยางตอเนื่องและทํา
งานไปไดอยางนุมนวลไมติดขัด
Chapter 19
“Refactoring”
เปลี่ยนแปลงโครงสราง
“เราตองการการดําเนินงานที่มั่นคง”
การดําเนินการตามแผนที่มั่นคงทําใหเรารูตัววาเราอยูจุดไหนแลว อะไรที่จะทําเปน
ลําดับตอไปหรืออะไรที่ควรจะถูกเลื่อนออกไปกอน
บอยครั้งที่การดําเนินงานของเรานั้นไมมั่นคง ถึงแมวาองคประกอบตางๆของงานเราจะดู
มีความยากพอๆกัน งานของเราอาจจะเอาแนเอานอนไมได หลังจากนั้นงานของเราก็จะคอยๆ
คืบหนาไดชาลงๆ
นอกจากนี้มันยังทําใหการยากแผนยากขึ้น เราจะเห็นวาปญหาจะเริ่มเกิดขึ้นจนแยที่สุด
คือทําใหเราสงงานไมทันเดดไลน
ทางคดเคี้ยว
การสราง feature ขึ้นมาไดนั้นมาจากความยาก
ของฟเจอรนั้นและความยากในการเอาฟเจอรใหมๆ
ใสเขาไปรวมกับ code เดิมที่มีอยูได
ถาเราละเลยเรื่องนี้ตอนเอา feature ใหมใส
เขาไปอาจจะงาย แตจะทําใหงานยุงเหยิงไปดวยสิ่งที่
เรียกวา bad code งานตอๆไปก็จะเริ่มใชงานนานขึ้น
เราตองหลีกเลี่ยงการสรางทางคดเคี้ยวเพื่อจะ
ทําใหงานเราดําเนินไดอยางมั่นคง และหากเราเผลอ
สราง เราตองดึงออกไมใหขด
Refactor ใหทางเดินของเราเปนเสนตรง
คําวา refactor แปลงายๆก็คือทําให code ของเราสะอาด สามารถเกิดขึ้นไดงายๆ หาก
เรากดดันทีมของเราใหทํา feature เพิ่มจนไมนาทันตามความเปนจริง พวกเราจะลืมทุกอยาง
เชนการทํา test หรือการเขียนโคดที่มีระเบียบ ผลที่ไดคืองานของเรามีขอบกพรองมากมาย
งานที่ไมมีคุณภาพนั้นสังเกตไดยากหากมองแตภายนอก ในฐานะ businesspeople เรา
คาดหวังใหทีมของเราเขียนโคดใหมีระเบียบ และเมื่อไรที่เราพบทางคดเคี้ยวอีก เราก็ตอง
จัดการใหเรียบรอยซะ
ทําอยางไรหากทางเดินเรายุงเหยิงไปหมด
คงไมใชทางออกที่ดีหากเราจะเริ่มทํางานชิ้น
ใหญๆใหมหมด ทุกครั้งที่เราจะเริ่ม feature เราจะ
clean งานในสวนที่เราจะลงมือทํากอน clean ให
เพียงใหพอทํางานไดกอน และเมื่อ feature เราใชได
แลว เราจึงคอย clean code เพิ่มเติม
งานสวนที่เราไมคอยไดยุงก็ไมคอยทําใหงาน
เราชาลงมากเทาไรนัก สวนงานที่ สําคัญเราจะใสใจ
มากในการ clean
สวนใหญ developer จะเริ่มเขียนใหมทั้งหมด
ซึ่งไมใชเรื่องที่ดีนัก ดังนั้นฝกฝนเรื่อง refactor ให
ชํานาญซะ
Chapter 20
“Agile Methods”
การทํางานแบบAgile
ฉันโชคดีที่ไดเปนนักเขียนคนหนึ่งของ Agile
Manifesto
“The Natural Way” คือการกลั่นสิ่งที่ฉันไดเรียนรูในชวงครึ่งศตวรรษของการพัฒนา
ซอฟตแวรและเกือบ 20 ปในการทํา “Agile” ฉันไมไดพยายามสรางAgile อื่นที่นี่ ใน Nature
ฉันอธิบายวาฉันคิดอยางไร ควรจะสรางซอฟตแวรตามสิ่งที่ฉันไดเรียนรูกอนระหวางและหลัง
“Agile”
ถาคุณตองการทราบขอมูลเพิ่มเติมเกี่ยวกับการพัฒนาซอฟตแวร มีวิธีการหรือ Agile
framework จํานวนมาก เปนที่นิยมมากที่สุดคือ Scrum โดย Jeff Sutherland และ Ken
Schwaber โดยการไมมุงเนนเพียงการออกแบบเพียงอยางเดียว ดังนั้น Scrum จึงไมไดรวมถึง
การปฏิบัติทางเทคนิคอยางชัดเจน เชนการทดสอบที่ยอมรับการทดสอบการพัฒนาการ
ทดสอบที่ขับเคลื่อนดวยการพัฒนา refactoring และอื่น ๆ
XP หรือ Extreme Programming ที่สรางโดย 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) และอื่น ๆ อีกมากมาย
อีกครั้งที่ The Nature of Software Development ไมไดอธิบายถึงอีกAgile
Framework แตขอคุณใหคิดถึงสิ่งที่ตองทําใน software project โดยเฉพาะ“Agile”
software project เพื่อที่คุณจะสามารถทํางานใน frameworks ที่คุณเลือกได
คําแนะนําเกี่ยวกับ frameworks
● โครงรางสําหรับ project ของคุณตองการใหพอดี ทุกคนการตองการพื้นที่อิสระ เพื่อ
โตตอบในรูปแบบที่ไมไดพิจารณาโดยกรอบใด ๆ และที่ไมสามารถออกคําสั่งไดตามกฎ
● ถาคุณมีโครงการขนาดใหญที่มีจํานวนคนมาก คุณจะตองมีกระบวนการมากกวา แต
อยางไรก็ตาม ใช retrospectives เพื่อตัดสินใจวาควรจะเพิ่มอะไร เพิ่มองคประกอบของ
กระบวนการเปนแบบทดสอบใหชัดเจนวาคุณคาดหวังอะไรจากการเปลี่ยนแปลงและ
ตรวจสอบดูวาคุณไดรับหรือไม ถาคุณทําไมไดหรือคุณไดรับผลกระทบที่ไมพึงประสงค
บางอยางใหเปลี่ยนแปลงครั้งตอไป
คําแนะนําเกี่ยวกับ frameworks (ตอ)
● ควบคุม framework หามให framework ควบคุมคุณ สราง framework ใน project
ของคุณใหมีประสิทธิภาพ อยางไรก็ตามอยางเปลี่ยน framework เพราะจะทําใหเกิด
ปญหา
● ปรับปรุงกระบวนการในการทํางานใหเหมาะสมกับทีม ไมมีใครไดเปรียบกวาใคร คุณ
ควรจัดการ project ของคุณโดยการสังเกตคนในทีม ไมควรเจาะจงใครเปนพิเศษแตให
มองในภาพรวม
คําแนะนําเกี่ยวกับ frameworks (ตอ)
● ใหการเรียนรูเปนสิ่งสําคัญ อยางที่เราเห็นในหนังสือเลมนี้ทักษะเปนสิ่งสําคัญ จําเปนตอง
มีทุกทักษะในการสรางโปรเจคหนึ่งๆขึ้นมา และตองจัดวางคนใหเหมาะสม บางทีอาจจะ
ตองมีการอบรมเพื่อเสริมทักษะที่มีอยูใหมากขึ้น เพื่อใหการทํางานมีประสิทธิภาพมากขึ้น
ตาม
● การทํางานใหไดดีนั้นไมไดใชแคการคาดการณและควบคุมเพียงเทานั้น แตตองมีการ
สังเกตอยูเสมอเพื่อใหสามารถตอบสนองตอเหตุการณตางๆไดทันทวงที อาจจะมีการวาง
แผนงานสํารองเอาไวหากเกิดขอผิดพลาดขึ้นมากะทันหัน ความสําเร็จของงานจะขึ้นอยู
กับทีม
Chapter 21
“Scaling Agile”
ปรับขนาดAgile
Scaling Agile
ปจจุบันมีความสนใจใน “scaling”บริษัทขนาด
ใหญเคยไดยินคําพูด Buzzzword Agile และความคิด
ที่ดีในอดีตเชน Six Sigma และ TQM ตอนนี้พวกเขา
ตองการที่จะกาวไปขางหนา Agile มันเปนสิ่งที่ตองทํา
แตพวกเขาเปน บริษัท ขนาดใหญ ดังนั้นพวกเขาคิดวา
พวกเขาจําเปนตองปรับ แตปรากฎวาในหลายกรณี
พวกเขาผิด พวกเขาไมจําเปนตองปรับ พวกเขา
ตองการพัฒนาซอฟตแวรดวย Agile อยางเรียบงาย
Scaling Agile กลายเปนธุรกิจที่ดีที่จะเขามา
เพราะคนอื่น ๆ คิดวาจําเปนตองใช มีตลาดที่เหมาะสม
สําหรับ Scaling Agile อยูเสมอ ดังนั้นจึงมีแนวทางที่จะ
ดําเนินการอยูเสมอ ขณะนี้ตลาดสําหรับ Agile เติบโต
ขึ้นเรื่อยๆ
คุณไมสามารถไดสิ่งที่ตองการเสมอไปหรอก...
แตนาเสียดายที่ในกรณีนี้มีการฝกอบรมที่มีราคา
แพงเพื่อใหตัวเองเปน Scaling Agile แตสุดทายพวก
เขาจะไดรับผลประโยชนบางอยางแนนอน ความสนใจ
ที่จะปรับปรุงมักจะดีกวาการไมมีความสนใจเลย
Agile นั้นเรียบงาย..แตมันแคไมงาย
Agile คอนขางงาย Agile เปนที่ไดรับความนิยม
มากที่สุด Scrum มีบทบาทเพียงสามอยาง คือกิจกรรมที่
หยิบยื่น และสิ่งประดิษฐที่สําคัญๆอยางหนึ่งที่เรียก
วาการทดสอบซอฟตแวร
มันไมไดหมายความวา Agile เปนเรื่องงาย ยังคง
เปนเรื่องยากที่จะตัดสินใจวาจะให product ใดเปนที่
พึงพอใจและยังคงยากที่จะเขียนซอฟตแวร
Agile ตองเรียบงาย ไมเชนนั้นก็ไมใช agile
Chet Hendrickson ชี้ใหเห็นวา Agile ใชงาน
ไดงาย Agile ที่ปรับเปนแบบเรียบงาย มิฉะนั้นจะไมมี
Agile อีกตอไป เราควรมองวา “Scaled Agile” ซึ่งมีค
วามซับซอน
ในขณะเดียวกัน Arlo Belshee แสดงใหเห็นวา
หากทีมพัฒนาของคุณมีความชํานาญในการพัฒนา
ซอฟตแวร Agile การปรับไมใชปญหา ถาทีมงาน
ทั้งหมดของคุณสามารถตัดเรื่องราวเล็ก ๆ และนําเสนอ
ซอฟตแวรที่ปราศจากขอบกพรอง จากนั้น “scaling”
ไดงาย Diana Larsen และ Jim Shore ผูคิดคนใน
บริบทนี้ทําใหประเด็นคลายกัน
ถาทีมของคุณเปน Agile จริงๆ...
ทีม Agile ทํางานทุกวันกับเพื่อนรวมธุรกิจ (Agile
Manifesto Principle 4) พวกเขาสงซอฟตแวรทํางาน
บอยๆทุกๆสองสัปดาห (หลักการที่ 3) (หลักการที่ 7) ทํา
งานอยางยั่งยืน (หลักการ 8) และใหความสําคัญกับ
ความเปนเลิศดานเทคนิคและการออกแบบที่ดี
(หลักการที่ 9) และอื่น ๆ
หมายถึงเปน Agile จริงๆนะ...
ทีม Agile ที่ชํานาญหลังจากเจอขอผิดพลาด เมื่อ
เริ่มตนใชงานทําใหเกิด features ที่สอดคลองกันและ
ทําใหขอบกพรองอยูในระดับที่ตํ่ากวาทีมเดียวกัน
ทีม Agile ที่ชํานาญอยางเห็นไดชัด พวกเขาได
รับสิ่งที่ทําอยางแทจริงในจังหวะที่สอดคลองและ
สามารถคาดเดาได หากทีมงานของคุณทําตามนั้น
… คุณอาจจะทําเสร็จไปแลว
จริงๆ หากทุกสิ่งทุกอยางที่คุณทําถูกสรางขึ้น
โดยทีมเล็ก ๆเดียวกัน Scaling Agile จะลดลงเพื่อให
แตละทีมเรียนรูที่จะสราง Agile จากนั้นจึงขอใหพวก
เขารวมงานกับผูที่เปนนักธุรกิจเพื่อเปนแนวทางกับสิ่งที่
พวกเขาจะสรางขึ้น
Agile Scaled ไมมีอะไรพิเศษนอกเหนือจาก
พื้นฐานที่ยากพอสมควร เราไดสํารวจในหนังสืออื่นๆ
แตคุณไมจําเปนตองดําเนินการเปลี่ยนแปลง Agile
ขนาดใหญที่คุณตองทํา
จะทําอยางไรหากตองการใหมีทีมมากกวาหนึ่ง
ทีม Agile ที่สามารถทําสิ่งนี้ไดอยางแทจริงจะ
ทําใหเกิดหลาย features ในทุกๆสองสัปดาห ไมใช
เรื่องงายเลยที่จะทําใหทีมมีความสามารถเชนนี้: คุณ
ตองมี product จํานวนมากที่จะทํา แตบางทีคุณอาจมี
product ขนาดใหญ เชนโปรแกรมประมวลผลหรือ
โปรแกรมกราฟกสําหรับการแกไขภาพ คุณรูสึกวามี
งานมากพอที่จะทําใหทีมตางๆไมวาง
เมื่อทีมที่ทํางานเกี่ยวกับ product ของคุณทําให
Agile มีคุณภาพแลว จากนั้นใหดูที่อัตราที่สงมอบ ดูวา
คุณตองการคุณสมบัติเพิ่มเติมมากกวานี้หรือไม
Feature teams
หากยอนกลับไปในศตวรรษที่ผานมา แนวคิด
ของ feature team ที่ไดรับการวางแผน คุณลักษณะ
เล็กๆของทีมคือ มีหนาที่ในการนําคุณลักษณะตางๆมา
สูผลิตภัณฑ เพื่อใหไดคุณสมบัติมากขึ้นคุณจะสามารถ
เพิ่มทีมงานที่มี features ครบถวนและซอฟตแวรที่นํา
เสนอทั้งหมดลงในผลิตภัณฑเครื่องเดียว หรือตองการ
เพิ่ม features อื่นๆ
มีไมมากที่เกี่ยวของในการปรับ ถาทุกทีมรู
วิธีการทํา Agile ก็จะรูวิธีดําเนินการเพิ่ม feature team
และผลิตภัณฑแลวจะสามารถทํางานไดเร็วเทาที่คุณ
ตองการได
Agile teams coordinate using tests.
โปรดจําไววาทีม Agile ทําเปน features ขนาด
เล็กจํานวนมากทุกๆสองสัปดาห ทีมเดียวสามารถทํา
features ดังกลาวได 15 หรือ 20 features ในการทํา
ซํ้าสองสัปดาห พวกเขาจัดการไดอยางไรเพื่อไมให
กาวกายกัน?
มันกลายเปนเรื่องงาย ทีม Agile ที่คลองแคลวใช
test-driven development ในการตรวจสอบ ชวยให
ทีมรูวาเมื่อใดที่มีคุณลักษณะครบถวน
Agile teams coordinate using tests (ตอ)
ถาเรากําลังใชหลาย feature teams ใหทํางานในลักษณะเดียวกัน ทุกครั้งที่สราง
feature ใหม ๆ หรือเพิ่ม feature ดวยการตรวจสอบโดยอัตโนมัติ แคทุกทีมทําใหเปรียบ
เสมือนเปนทีมเดียวกัน
อาจมีความขัดแยงระหวางสิ่งที่ทํากันในทีม? อาจจะเกิดขึ้นไดและทีมงานจะประสานกัน
เพื่อดูวาเกิดอะไรขึ้น
ทีม Agile ทําแบบนี้แนนอน พวกเขาเรียนรูที่จะคอยๆทําเปนชิ้นเล็ก เมื่อพวกเขาทํางานที
ละนิด พวกเขาก็จะยิ่งทํางานไดละเอียดมากขึ้น เมื่อพวกเขาแบงงานเปนชิ้นเล็ก มันจะทําให
งายในการคนหา
แลว infrastructure ละ?
หากผลิตภัณฑของคุณมีขนาดใหญพอที่จะใช
หลายๆ Feature teams พวกเขาจะอาศัยโครงสราง
พื้นฐานทั่วไปบางอยาง หากเปลี่ยนเปนสิ่งนี้ละ?
ทีม Agile เปลี่ยนโครงสรางพื้นฐานตามที่
ตองการ พวกเขาทํางานอยางอิสระทุกสองสัปดาหโดย
การสนับสนุนการเปลี่ยนแปลงของตนเอง
Feature teams สามารถทําสิ่งเดียวกันกับแตละ
ทีม โดยแตละทีมสามารถเปลี่ยนแปลงไดตามความ
ตองการและมีการตรวจสอบ code บอยๆ
อยาลืมวาคุณไมจําเปนตองมี feature teams เลยหากแตละทีมของคุณสามารถทํา Agile ได แตถาคุณทําเชนนี้
คุณจะไมจําเปนตองมีโครงสรางพื้นฐานพิเศษเพื่อใหมีทีมที่มีคุณลักษณะเฉพาะ คุณจําเปนตองมีทีมที่มีอํานาจหลายคน
ที่สามารถและจะประสานงานกันเองตามความจําเปน
So far, so good
บริษัทที่ทํางานไดโดยทีมเดียวไม
จําเปนตองมีอะไรที่พิเศษ
ในองคกรสวนใหญที่ฉันเคยเห็น สวนใหญ
จะทําโดยทีมงานเดียวกันแลวในไมกี่ปที่
ผานมาฉันไดเห็นผลิตภัณฑที่มีการ
ผสมผสานเขาดวยกันและมีขนาดใหญ
เพียงพอที่จะใช feature teams ได
Giant efforts
ความพยายามที่มีขนาดใหญโดย
เฉพาะอยางยิ่งกับนักพัฒนาซอฟตแวร
หลายรอยคนบางทีอาจจะเปนพัน ๆ คนการ
ทํางานในสิ่งหนึ่งสิ่งใด หากคุณไมไดอยู
ใน บริษัท เชนนั้นบางทีสิ่งที่คุณตองทําคือ
การทําใหแตละทีมของคุณสามารถทํางาน
ไดอยางคลองตัว
อยางแรก คอยๆสราง giant
หากคุณกําลังเริ่มตน giant effort วิธี
มาตรฐาน Agile ก็ทํางานไดดี เริ่มตนดวย
ทีมเดียว สรางมันใหใหญขึ้น สรางและ
ขยายโครงสรางพื้นฐานในขณะที่คุณไป
เพิ่ม feature teams ตามที่คุณตองการ
สุดทายแลว แบง giant ออกมาซะ
แมใน giant efforts เกือบทุกอยางที่ทําจะถูกทํา
โดยทีมเดียว เรารูอยูแลววาจะทําอยางไร
แมใน giant efforts การเพิ่มทีมทํางานเขาไปก็
สามารถชวยไดเหมือน feature team
สวนใหญแลวฉันไมคิดวาจะมี giant effort ที่ไม
สามารถถูกลดลงไดหรอกนะ ถาจะมี ก็เพราะไมมีใครรู
วาจะทําอยางไร
ถาเราทราบวิธีแบงงานแลวเกือบตลอดเวลางาน
สวนใหญสามารถทําไดโดยใช Agile
Bottom line
หากทีมงานแตละทีมของคุณไม
สามารถทํางานในแบบ Agile ไดอยาง
ชัดเจน คุณยังไมพรอมที่จะ “เปลี่ยน” ขั้น
แรกใหเริ่มสรางทีมที่มีความสามารถใน
การทํา Agile จากนั้นใหความสําคัญกับ
งานที่มีคาที่สุดเพื่อใหองคกรของคุณ
สามารถเกิดขึ้นได และสรางทีม Agile โดย
จัดระเบียบตาม features ที่เปนไปได คุณ
อาจพบวาคุณไมจําเปนตองใช Scale
Agile
Chapter 22
“Conclusion”
สรุป
ลองจินตนาการวาคุณกําลังปนภูเขาที่ชื่อ การพัฒนา
Software
ซึ่งคุณอาจเปนนักปนเขาหลายระดับทั้งมือใหมที่รออยูที่ตีน
เขา หรือมีประสบการณอยูแลวที่มีอุปกรณและความรู
ครบครัน หนังสือเลมนี้จะชวยใหเห็นเสนทางบนภูเขาและ
สามารถบอกไดวาเสนทางไหน
ที่ปลอดภัยและเสนทางไหนอันตราย สิ่งเหลานี้ทําใหคุณ
สามารถเพิ่มการเดินทางของคุณเอง บางครั้งรางวัลเปน
เพียงการปนเขาที่ทําใหคุณมีทักษะมากขึ้นและมากขึ้น
สําหรับผมผมคิดอยางนี้นะ แลวคุณละ คิดอยางไร?
ขอบคุณที่อาน
Reference
Ron Jeffries, 2015, The Nature of Software Development Process
The nature of software development process

The nature of software development process