ผมเคยคุยกับคุณ Kluak110 เมื่อหลายปีก่อนเกี่ยวกับเรื่องว่า Agile และหลักเศรษฐกิจพอเพียงนั้นเป็นเรื่องเดียวกัน เมื่อวานนี้คุณ Kluak110 ขอ encore ผ่านทาง agile66 forum เข้ามา คิดว่าคงจะยังติดใจเรื่องนี้อยู่
ถ้าฟังจากสื่อต่างๆ คงจะงงว่า แล้วฉันไม่ได้ไปทำนา ฉันเป็นโปรแกรมเมอร์ เป็น developer แล้วเศรษฐกิจพอเพียงมาเกี่ยวอะไรด้วย หรือเขียนโปรแกรมมันไม่พอกิน ต้องให้ฉันไปทำนาด้วย ลองฟังพระราชดำรัชนี้ดูดีกว่า
เศรษฐกิจพอเพียง แปลว่า Sufficiency Economy … คำว่า Sufficiency Economy นี้ไม่มีในตำราเศรษฐกิจ จะมีได้อย่างไร เพราะว่าเป็นทฤษฎีใหม่ … Sufficiency Economy นั้น ไม่มีในตำรา เพราะหมายความว่าเรามีความคิดใหม่ … และโดยที่ท่านผู้เชี่ยวชาญสนใจ ก็หมายความว่า เราก็สามารถที่จะไปปรับปรุง หรือไปใช้หลักการ เพื่อที่จะให้เศรษฐกิจของประเทศและของโลกพัฒนาดีขึ้น
พระราชดำรัสเนื่องในโอกาสวันเฉลิมพระชนมพรรษา 23 ธันวาคม 2542
ไม่มีตรงไหนเลยที่บอกว่าเศรษฐกิจพอเพียงเป็นเรื่องการเกษตร มีแต่บอกว่าเกี่ยวกับเศรษฐกิจ เพราะฉะนั้น “อะไรที่เกี่ยวข้องกับเศษฐกิจใช้เศรษฐกิจพอเพียงได้หมด” ซึ่งการพัฒนาซอฟแวร์ก็เป็นส่วนหนึ่งของเศรษฐกิจเพราะฉะนั้นน่าจะใช้ได้ เศรษฐกิจพอเพียงนั้นมีหลักการง่ายๆ ว่า “สามห่วงสองเงื่อนไข (ตามรูป)
ผมจะอธิบายหลัก “สามห่วงสองเงื่อนไข” ในเทอมของ Agile ไปด้วยกันเลย เพื่อให้เห็นภาพการซ้อนทับกันของแนวคิด ความจริงถ้าไม่มี Agile เข้ามาจับ เราก็น่าจะสร้างวิธีพัฒนาซอฟแวร์ตามเศรษฐกิจพอเพียงได้ แต่ในเมื่อมี Agile อยู่แล้วเราจะไป “reinvent the wheel” ทำไม
สามห่วง คือ คุณลักษณะ 3 ประการที่จำเป็นต้องมี
1. ความพอประมาณ หมายถึง ความพอดีที่ไม่น้อยเกินไปและไม่มากเกินไป โดยไม่เบียดเบียนตนเองและผู้อื่น
Just in time & Just enough ผมแปลเรื่องนี้เป็นไทย ว่า หลัก “3 จำเป็น” คือ ทำเฉพาะ สิ่งที่จำเป็น ในเวลาที่จำเป็น เท่าที่จำเป็น เหตุผลเพราะ ถ้าเราไม่ทำสิ่งที่จำเป็น(ตาม requirement) software ของเราก็ไม่สามารถตอบสนองความต้องการของลูกค้าได้ เหตุผลที่เราต้องทำสิ่งจำเป็นเหล่านั้นให้เสร็จทันเวลาที่จะใช้พอดี เพราะการทำเสร็จมาวางคอยไว้เป็นความสูญเปล่า(ดู 7 wastes) และทำให้กำลังใจ(morale) ของทีมลดลง สุดท้ายต้องทำเท่าที่จำเป็น เพราะถ้าทำเผื่อหรือทำเกิน จะเป็นภาระให้เราต้องตามดูแล(maintenance) มันตลอดไป สุดท้ายเราจะเรียกมันว่า legacy code และเรียกร้องที่จะเขียนใหม่ทั้งหมด และเริ่มต้นวงจรอุบาทก์(vicious circle) อีกครั้งหนึ่ง
Muda (7 wastes) การทำอะไรที่ไม่พอดีเป็นการสูญเปล่า แต่การที่ไม่มี buffer เลย และพอเกิดปัญหา ระบบงานก็หยุดชะงัก ก็เป็นความสูญเปล่าอีกเช่นกัน เพราะฉะนั้นเราจะต้องมี buffer สำรองให้น้อยที่สุดเท่าที่จะยังรักษาความต่อเนื่อง(flow)ของระบบงานได้ ตัวอย่างเช่นการสร้าง user story ถ้าเราพยายามสร้าง story ของทั้งโปรเจ็คให้เสร็จในคราวเดียวนับเป็นความสูญเปล่า เพราะ requirements อาจจะเปลี่ยนเมื่อไหร่ก็ได้ แต่ถ้าเราสร้าง story เท่าที่จะทำใน sprint ก็เป็นความสูญเปล่าอีกนั่นแหละ เพราะ story ทั้งหมดใน sprint อาจเสร็จก่อนเวลา แล้ว developer ก็จำเป็นต้องนั่งว่างเพราะไม่มีอะไรทำ เพราะฉะนั้น การสร้าง story ควรจะสร้างเตรียมไว้ ให้มากกว่าที่จะทำได้ใน 1 sprint แต่ไม่เกิน 2 sprint จึงจะนับได้ว่าพอดี เป็นต้น
2. ความมีเหตุผล หมายถึง การตัดสินใจเกี่ยวกับระดับของความพอเพียงนั้นจะต้องเป็นไปอย่างมีเหตุผล โดยพิจารณาจากเหตุปัจจัยที่เกี่ยวข้องตลอดจนคำนึงถึงผลที่คาดว่าจะเกิดขึ้นจากการกระทำนั้น ๆ อย่างรอบคอบ
User story การใช้ user story ในการกำหนด requirement นั้นประกอบด้วย who what และ why เพื่อให้เราได้รู้รายละเอียดและต้นตอของ requirement นั้นอย่างแจ่มชัด
5 Whys การพิจารณาหาต้นตอของปัญหา(จริงๆ ทุกเรื่องน่ะแหละ) ด้วยการถามคำถามที่ขึ้นต้นว่าทำไม อย่างน้อย 5 ครั้งเพื่อนำเราไปยังต้นตอที่แท้จริงของปัญหา และสามารถแก้มันได้อย่างถาวรและยั่งยืน
3. การมีภูมิคุ้มกันที่ดีในตัว หมายถึง การเตรียมตัวให้พร้อมรับผลกระทบ และการเปลี่ยนแปลงด้านต่าง ๆ ที่จะเกิดขึ้นโดยคำนึงถึงความเป็นไปได้ของสถานการณ์ต่าง ๆ ที่คาดว่าจะเกิดขึ้นในอนาคตทั้งใกล้และไกล
Embrace change พร้อมรับการเปลี่ยนแปลงอยู่เสมอ(Responding to change over following a plan) การที่เราจะรับความเปลี่ยนแปลงต่างๆ ได้ ไม่ใช่แค่ใช้ใจเท่านั้น เรายังต้องมีการเตรียมพร้อมที่ดีด้วย 2 ข้อแรก(ความพอประมาณและมีเหตุผล)นั้น เป็นการเตรียมตัวเพื่อข้อนี้โดยเฉพาะ เพราะ ถ้าเราทำอะไรไม่พอประมาณเช่นออกแบบระบบให้ใหญ่และซับซ้อนเกินไป(เผื่อ) พอเวลาเกิดการเปลี่ยน requirement โค้ดที่เราจะต้องแก้ก็มากขึ้น ที่จะต้องเทสท์ ก็มากขึ้นตามไปด้วย
TDD (Test Driven Development) เป็นเครื่องมือสำคัญที่ใช้ในการสร้างภูมิคุ้มกันต่อความเปลี่ยนแปลง เพราะเมื่อเราเปลี่ยน โค้ด Test จะเป็นตัวบอกเราทันทีว่าโค้ดที่เราทำยังถูกต้องตาม requirements อยู่หรือไม่ (Jidoka/Autonomation)
สองเงื่อนไข คือในการตัดสินใจวางแผนและดำเนินงานนั้นให้เป็นไปตามเงีอนไขดังนี้
1. เงื่อนไขความรู้ ประกอบด้วย ความรอบรู้เกี่ยวกับวิชาการต่าง ที่เกี่ยวข้องอย่างรอบด้าน ความรอบคอบที่จะนำความรู้เหล่านั้นมาพิจารณาให้เชื่อมโยงกัน เพื่อประกอบการวางแผนและความระมัดระวังในขั้นปฏิบัติ
Planning Poker หลายคนพอได้ยินคำว่า”รอบรู้” ก็จะพยายามคิดว่า อ่ะ ข้าต้องรู้ทุกเรื่อง ความจริงแล้วความในที่นี้คือการรวมและกระจายความรู้อย่าง dynamics เพราะมันเป็นไปไม่ได้ที่ใครคนใดคนหนึ่งจะรู้ทุกเรื่อง การรวมคนเข้ามาช่วยกันคิดจึงเป็น การเพิ่มความรอบรู้ โดยเอาความรู้ของทั้งทีมมาบวกกัน เทคนิคนี้เรียกว่า Cloud thinking หรือที่ไทยเรียกว่า สอง(หลาย)หัวดีกว่าหัวเดียว นอกจากทำให้รอบรู้ขึ้น การมีหลายคนช่วยกันคิดวางแผนยังทำให้เกิดความรอบคอบด้วย เพราะมีหลายตาช่วยกันมองตรวจสอบ
Pair Programming เมื่อถึงขั้นตอนปฏิบัติ(ลงมือโค้ด) การใช้สองคนช่วยกันทำ ทำให้เกิด ความระมัดระวัง เพราะคนหนึ่งมองจาก user requirement perspective อีกคนมองจาก technical perspective และ การทำ pair ยังเป็นการการกระจายความรู้ อีกทางหนึ่ง ทีมจึงมีความรู้รอบ และรอบรู้ไปพร้อมๆ กัน
2. เงื่อนไขคุณธรรม ที่จะต้องเสริมสร้างประกอบด้วย มีความตระหนักในคุณธรรม มีความชื่อสัตย์สุจริต และมีความอดทน มีความพากเพียร ใช้สติปัญญาในการดำเนินชีวิต
Agile Discipline การใช้งาน agile นั้นต้องอาศัยความมีวินัยอย่างถึงที่สุด มีหลายคนสับสน Agile กับ Cowboy style ผมบอกได้ว่า มันต่างถึงขนาดพระกวาดลานวัด กับหมาปัดที่นอน เลยที่เดียว (ถ้าเคยเลี้ยงหมาลองสังเกตมันจะวนที่ๆ มันจะนอนสองสามรอบก่อนนอนลงไปจริงๆ)
Individuals and interactions over processes and tools ผมพูดเรื่องนี้หลายรอบแล้ว แต่ก็ยังคงย้ำอยู่ว่า คนเป็นคนไม่ใช่เครื่องจักร ผมมีความเห็นแย้งกับแนวความคิดที่ว่าคนเป็น resources เอามากๆ โดยส่วนตัวผมคิดว่า คนในทีมคือเจ้าของ product มากกว่าจะเป็น resources ที่ใช้ในการผลิต
Customer collaboration over contract negotiation นอกจากทีมจะเป็นเจ้าของ product แล้ว ลูกค้ายังเป็นเจ้าของ product ด้วย เพราะเขาจะเป็นคนที่ต้องใช้ชีวิตอยู่กับ product นี้ไปอีกหลายปี เขาควรจะมีชีวิตที่ดีขึ้น จากการเป็นเจ้าของมัน ไม่ใช่ทำให้ชีวิตลำบาก(miserable)
บังเอิญว่าผมไม่ได้ติดโน้ตที่ผมเคยจดเรื่องนี้เอาไว้มาด้วย ทั้งหมดบีบออกมาจากหัว(ยังกะสิว) ถ้าตกหล่นตรงไหนไปผมจะเอามาเพิ่มทีหลังให้นะครับ
Links
http://th.wikipedia.org/wiki/เศรษฐกิจพอเพียง
http://en.wikipedia.org/wiki/Muda_%28Japanese_term%29
http://en.wikipedia.org/wiki/5_Whys
http://en.wikipedia.org/wiki/Autonomation
http://www.drdobbs.com/architecture-and-design/201804241
คิดเหมือนกันเลย ผมก็เคยคุยกับใครหลายคนไปในแนวนี้ และจำได้ว่าในงาน NJUG (Narisa Java User Group) เมื่อสัก 2-3 ปีก่อนผมไปพูดด้วยนิดหน่อย ก็เล่าให้ฟังว่า Agile กับเศรษฐกิจพอเพียงไปกันได้และเข้ากันมากเลย แต่หลายคนไม่เข้าใจ ว่ามันเกี่ยวกันอย่างไร คนส่วนมากที่หันมาสนใจ Agile มักมีมุมมองและทัศนคติในเชิงเทคนิคัลมากไปนะผมว่า
เนื่องจาก Agile มาจาก Lean ส่วน Lean มาประยุกต์แนวคิดจากเซนและพุทธมิใช่น้อย
ผมเห็นว่าพวกกูรูด้าน Agile ต่างชาติ (อเมริกา) ที่คนไทยมักเสพสาระจากแหล่งเหล่านี้มิใช่น้อย พวกเขาหลายคนก็ออกแนวเทคนิคัลจ๋ากันมากมาย พูดคุย/นำเสนอ/อธิบายออกมาในแนวเทคนิคัลเกินไป หลายรายออกไปในแนวไม่เน้นการจัดการเลย เน้นแต่มุ่งเน้น executable code เน้นแต่ระบบที่จะออกมา โดยขาดการมองและดำเนินการอย่างบูรณาการ ทำให้คนไทยที่ศึกษา Agile เข้าใจไปแนวนี้กันทั้งนั้น เพราะผมเห็นว่าส่วนใหญ่เติบโตมาจากแนว developer
ผมเคยเขียนบทความเกี่ยวกับงานซอฟต์แวร์และแนวคิดเศรษฐกิจพอเพียงไว้เหมือนกัน แต่เขียนในบริบทด้านอุตสาหกรรมและธุรกิจ ไว้จะเอามาแชร์มั่งนะครับ
ส่วนปกติผมมักใช้แนวคิดเศรษฐกิจพอเพียงกับงานด้าน architecture คือ ต้องออกแบบโดยเลือกใช้สิ่งต่าง ๆ อย่างพอเพียง ไม่ใหม่เกิน ไม่เก่าไป ไม่… ฯลฯ ซึ่งต้องมีเหตุผลในการออกแบบ (rationale + assumption) สามารถอธิบายที่มาที่ไปและอธิบายความคิดได้ว่ามี influence และ แรงบันดาลใจจากอะไร ส่วนภูมิคุ้มกันผมมักพูดถึงหลักด้าน symptom analysis และ trouble shooting management โดยในแง่สถาปัตยกรรมก็มักเน้นด้าน testability
ผมว่าเจ้าภูมิคุ้มกันนี่สำคัญมากนะครับ (พอประมาณและมีเหตุผลก็สำคัญเหมือนกัน) โดยเฉพาะปัญหาในประเทศเราตอนนี้ เพราะมีองค์กรมากมายที่ประสบภาวะภูมิคุ้มกันด้านไอทีบกพร่อง มีปัญหาแล้วไม่สามารถพึ่งพาตนเองได้เท่าที่ควร เสียดุลกับเม็ดเงินมากมายให้บริษัทซอฟต์แวร์ที่ทำงานไม่เก่งและเวนเดอร์ต่างชาติที่โหดร้าย ผมทำด้าน enterprise architecture อยู่ด้วย ผมมักใช้เจ้าภูมิคุ้มกันนี่เป็นตัวชี้วัดวุฒิภาวะด้านไอทีขององค์กรตัวหนึ่งเลย
เอ๊ย ชักออกนอกเรื่อง เท่านี้ก่อนละกันครับ ยินดีที่บ้านเรามีคนที่เข้าใจอะไรถึงแก่นแบบนี้นะครับ หวังว่าคงได้แลกเปลี่ยนกันอีก ผมเข้าไปอ่าน blog หลายบทความดี ๆ ทั้งนั้น ไว้จะติดตามนะครับ
ดีใจครับ ที่มีคนสนใจคล้ายๆ กัน เดี๋ยวกลับไปแล้วผมว่าจะหาทางจัดเป็นสัมมนาแบบกระทัดรัด คิดว่าคงมีโอกาสได้เจอกันนะครับ แต่ออกตัวไว้ก่อนว่าผมก็ไม่ได้เข้าใจอะไรลึกซึ้งขนาดนั้นหรอกนะ เรียกว่า กำลังศึกษาและเป็นเพื่อนร่วมทางกันจะดีกว่าครับ
เข้าใจและอธิบายเชื่อมโยง(บูรณาการ)กันได้ขนาดนี้ก็ถือว่าลึกซึ้งแล้วล่ะครับ
อ้าว… แล้วตอนนี้อยู่ต่างประเทศหรือครับ? ผมไม่ค่อยได้แวะมาบ้านนี้เท่าไหร่ อาจไม่ค่อยรู้จักใครนัก
ไว้คงได้มีโอกาสเจอกันคุยกันมั่งครับ เป็นเพื่อนร่วมแนวทางกันไปก็ดีครับ ดีใจที่ได้เจอนักไอที ‘ประเภท’ นี้เพิ่มขึ้นอีกคนนะครับ หาไม่ง่ายนะครับในบ้านเรา ยกเว้นว่าต้องอายุเยอะ ๆ สักเกิน 40 ขึ้นไปเลยถึงจะได้เจอบ่อยหน่อย แต่ถ้าต่ำกว่า 40 นี่หายากนะผมว่า เพราะเห็นมีแต่นักเทคนิคัลนักเทคโนโลยีเต็มบ้านเต็มเมือง การที่จะมามองเห็นแก่นแล้วบูรณาการเชื่อมโยงกันได้ขนาดนี้หาได้ยากครับ
เอ… หรือว่าคุณ Korn4D เกิน 40 แล้ว? ล้อเล่นนะครับ
ฟังแล้วเหมือนตัวเองเป็นสัตว์ป่าสงวนเลยแฮะ ผมมาเทรนกลับเดือนกันยาครับ อาจจะได้เจอกันใน barcamp ครั้งหน้าครับ และ ผมยังไม่แก่ขนาดนั้นหรอกน่า
จำได้ว่า ตอนที่คุยกับ Korn4D ตอนนั้น ซักเกือบสองปีมาแล้ว มีการบ้านว่าอยากจะหา Value ให้ทีม dev Korn4D ก็เลยยกเรื่องหลักเศรษฐกิจพอเพียงมาจับ แต่ก็น่าเสียดายที่ได้คุยกันในหมู่คนไม่กี่คน (หรือมีแค่สองคนก็ไม่แน่ใจ) และก็ไม่ได้สานต่อเลย ตอนนั้นประทับใจว่า เออมันเก่งที่เอามาผูกกันได้ จริงจะสารภาพว่าก่อนหน้านั้นยังคิดว่าเศรษฐกิจพอเพียงคือการประหยัดอยู่เลย เพราะว่ารู้จักแต่ชื่อ ไม่ได้รู้เรื่องห่วงเรื่องเงื่อนไขอะไรนี่เลย คุยกับ Korn4D ก็ทำให้ได้เปิดหูเปิดตาขึ้น
วันนี้เห็น Korn4D กำลังบ้าพลัง เลยขอซะหน่อย ดีใจที่คนอื่นจะได้รับรู้ด้วย ขอบคุณครับ
ไม่ได้บ้าพลังนา ผมรู้สึกว่า ถ้าพระทำวัตรทุกวันได้ ผมก็เขียน blog ทุกวันได้ ก็เท่านั้นเอง กำลังคิดว่า คิดเรื่องนี้ต่อด้วยการแทนที่จะโปรโมต “อไจล์” เปลี่ยนเป็น “อจน”(แปลว่า ไม่จน) methodology ดีมั้ย?