คำตอบที่คุณต้องคิดก่อนเปลี่ยนเป็น Agile

สืบเนื่องมาจากคำถามที่ผมทิ้งไว้ให้คิดกัน(ดูจากลิ้งค์ด้านล่าง) มีเพื่อนๆ หลายคนช่วยกันตอบผม อาจจะเป็นที่ผมอินไปหน่อย เลยฟังดูเหมือนผมกำลังต่อต้าน agile จริงๆ แล้วเป็นบทบาทการแสดงแบบ devil advocates เพื่อให้เห็นว่า ในสถานการณ์จริงจะโดนอะไรบ้าง

คราวก่อนอย่างที่ผมพยายามบอกไปตอนต้น ว่าเป็นเรื่องสมมติว่าคุณจะต้องคุยกับผู้บริหาร เพราะการจะเปลี่ยนเป็น agile ได้นั้นมันต้องได้รับการสนับสนุนจากระดับสูง ความจริงการเปลี่ยนแปลงทุกชนิดนั้นแหละ คนเราพอจะต้องเปลี่ยนแปลงก็จะมีส่วนหนึ่งกระตือรือร้นที่จะเปลี่ยน อีกส่วนยังไงก็ได้ อีกส่วนขอดูทางลมก่อน และสุดท้ายต่อต้านการเปลี่ยนแปลง (เก็บเรื่องไว้เขียนแยกเป็นอีกตอนดีกว่า) การจะจัดการคนทุกกลุ่มให้อยู่หมัดได้ก็ต้องอาศัยบารมีของผู้ใหญ่ มาช่วยหนุนเราจึงจะสำเร็จได้ เพราะฉะนั้นจังหวะของการล้อบบี้ึจึงสำคัญที่สุด ปัญหาก็คือ ประสบการณ์ของผู้บริหารกับเรานั้นไ่ม่เหมือนกัน ส่วนใหญ่ถ้าหากว่ามีแบกกราวน์จากสายโปรแกรมมิ่งแล้วท่านผู้ใหญ่ของเราก็คงหนีไม่พ้นคนจากโลกยุคสามเป็นแน่(อ่านจากวันก่อนเรื่อง TDD != Unit Testing) คำถามที่ผมลองถามไปให้คิดจึงเป็นการบ้านที่เราต้องทำก่อน เดินไปหาท่านผู้บริหาร

ก่อนอื่นผมขออ้างถึงคำพูดที่ผมมักจะพูดบ่อยๆ

Due date is the root of all evil

เหตุผลที่ผมกล่าวไว้อย่างนั้นเพราะ มันคือจุดอ่อนที่สำคัญที่สุดของ agile พูดใหม่ก็ได้ เพราะมันคือจุดแข็งที่สุดของ agile อ๊ะ! งงมะ? ต้องกลับไปอ่านเรื่อง Extreme Programming ท่านศาสนา Kent Beck ของกระผมพูดไว้ตั้งแต่ต้นว่า การพัฒนาซอฟแวร์ก็เหมือนกับมีปุ่มปรับอยู่สี่ปุ่มคือ Scope, Resources, Time, Quality

ทีนี้ Scope น่ะมันตามลูกค้าอยู่แล้ว เพิ่มได้ลดไม่ได้ Resources หรือจำนวนคนนี่เพิ่มเข้ามาก็สร้างปัญหามากกว่า เพราะต้องมา train กันวุ่นวาย มากกคนก็มากความ ก็เหลือเวลา กับ คุณภาพ การกำหนด due-date ก็คือการจำกัดเวลา ทำให้ developer เหลือทางเลือกเดียวคือการลดคุณภาพซอฟแวร์เพื่อให้ทักำหนดส่งงาน วิธีการบริหารแบบดั้งเดิมจึงมักได้งานตามกำหนดแต่คุณภาพไม่ดีสุดท้าย ลูกค้าก็รับไ่ม่ได้ งานก็บานปลาย

agile จึงเสนอทางออก ด้วยการ กำหนดคุณภาพแล้วปล่อย เวลาให้เป็นอิสระ นี่คือเหตุผลว่าทำไม agile จึงบอกว่า good enough ก็พอไม่ต้องสุดยอด เพราะ มันจะทำให้ของไม่มีวันเสร็จอย่างไรล่ะ ซึ่งตรงนี้จะตรงข้ามกับของเดิมคือ เอาคุณภาพให้ดีที่สุดเท่าที่เวลาที่มีอยู่

1. การทำล่วงเวลา และการทำงานวันหยุด
เพราะกำหนดเสร็จมันไม่มีแล้ว จะต้องไปทำดีกๆ ดื่นๆ ให้แก้สองบั๊ก แต่ใส่เข้าไปใหม่อีกสามบั๊กไปทำไม การพูดอย่างนี้ได้ต้องมีหลักฐาน คือต้องวัดผลกันที่ defect rate หลังจากส่งมอบ คือ defect จาก UAT จริงว่าให้ผลที่ดีกว่า คือ bug จาก UAT ต้องเป็นศูนย์ – ทำไมจะทำไม่ได้ ถ้า user มาร่วมทดสอบกับเราตั้งแต่ต้น UAT มันก็ไม่มีตั้งแต่แรกแล้ว แล้วมันจะมี bug ไปได้อย่างไร

2. TDD vs Unit Testing
เพราะท่านผู้บริหารเกิดเร็วไป ความเข้าไปในหัวของท่าน ไม่เหมือนเรา ท่านงงว่าจะต้องไปเสียเวลาทำ Unit Tests กันมากมายไปทำไม อย่าพยายามคุยเสียให้ยาก ท่านไม่เข้าใจหรอก จงเลี่ยงไปใช้คำอื่นซะ เช่น Code Review หรือ Design Review แต่ความจริงคือ session การตรวจว่า มี unit tests ครบตามที่ควรจะเป็นหรือไม่ ขั้นแรกของการก้าวสู่ agile นั้น TDD ไม่จำเป็นเท่าไหร่หรอก จะบอกให้ เอาไว้ ทำ defects เป็นศูนย์ได้แล้วค่อยคิดก็ยังทัน (แต่ต้องแอบเตรียมไว้ก่อนนะ ไม่งั้นเกิดปัญหาเขียน test ให้ match โค้ดไม่ได้แน่)

3. โหวตเกินจริง และอู้งาน
“Perception is King” ประโยคเทพนี้ต้องงัดเอามาใช้กันตอนนี้แหละ มันเป็นหน้าที่ของคุณที่เป็น agile master ต้องทำให้ผู้บริหารรู้สึกว่า ทำงานกันหนัก ไม่มีพัก

“ทำงานมันต้องไม่สนุก ถ้าสนุกแปลว่าไม่ได้ทำงาน”

ไม่ใช่ดันไปใช้

“(ทำงานคนเดียวเหนื่อยแทบตาย) ทำงานหลายคนสนุกเหมือนเล่น”

มันใช้ไม่ได้ ผู้บริหารเค้าเป็นรุ่นเก่า จะมาเข้าใจเรื่องแบบนี้ได้ยังไง หัดใช้ท่าไม่ตาย “ทำเป็นยุ่ง” กันเป็นมั้ย?

4. เสร็จเมื่อไหร่?
คนยุคเก่าเขา precise ไปตอบเป็นช่วงก็เสร็จกันพอดี ลองคิดว่า ถ้าภรรยา(หรือตัวคุณเอง)ตั้งท้อง ไปหาคุณหมอ ถามคุณหมอว่า กำหนดคลอดเมื่อไหร่ คุณหมอตอบว่า “ประมาณเก้าเดือน” ก็เปลี่ยนหมอเท่านั้นเอง บ้า! ตอบแบบนี้ใครก็ตอบได้ มันต้องเป๊ะๆ พอถึงเวลา มันคลาดเคลื่อนไป เขาก็ไม่ว่าหรอก เข้าใจกันได้ ยิ่งเวลาผ่านไปเราจะมีข้อมูลมากขึ้น อย่าคอยให้ถาม proactive ไปบอกเขาก่อนว่า ที่บอกไว้ วันที่ 24 นี่ไม่ได้แล้วนะ เพราะ … หาเหตุผลดีๆ แล้วกัน มี requirement เพิ่ม 1 2 3 4.. ฝ่าย IS ทำเครื่องมีปัญหา test ไม่ได้ไปสามวัน พอได้กลับมาต้องเริ่ม test ใหม่ สิ่งสำคัญคือหลักฐานหรือเหตุผลที่เราเอามา backup ว่าน่าเชื่อถือแค่ไหน สุดท้ายถ้าไม่ได้ จริงๆ ให้ทิ้งไว้ เป็น known issues หรือ residual defects แล้วไปตาม fix ตอนไป production ข้อนี้ต้องใช้วิทยายุทธเยอะเพราะจะไปบอกเขาตรงๆ ได้หรือว่า agile ไม่มี due-date ครับ/ค่ะ ได้กลับบ้านไปเลี้ยงลูก/หลาน/หมา/แมว กันพอดี

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

สุดท้ายถ้าคุณรู้สึกว่า ปัญหาพวกนี้ฉันไม่เคยเจอ คุณเป็นคนโชคดีเพราะองค์กรของคุณเป็น agile ก่อนที่คุณจะเข้ามาแล้ว เอาใหม่ดีกว่า คุณเป็นคนโชคร้ายเพราะ ไม่มีโอกาสที่จะรู้ว่าเหนือ agile ขึ้นไปเป็นอย่างไร

บอกแล้วว่า อย่ายึดติด..

Links
http://www.agile66.com/blogs/2010/08/12/คำถามที่คุณต้องเตรียมตัวตอบก่อนเปลี่ยนเป็น_Agile/
http://www.agile66.com/blogs/2010/08/14/tdd-unit-testing/
http://www.agile66.com/blogs/2010/08/15/tdd-unit-testing-2/
https://korn4d.wordpress.com/2010/07/15/why-due-date-is-the-root-of-all-evil/
https://korn4d.wordpress.com/2010/07/01/perception-is-king/

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s