A Paradigm Shift
วันก่อน @RallySoftware เค้า tweet มาให้ tweet definition ของคำว่า #AgileSuccess ไปครับ ผมก็ลองส่งไปเล่นๆว่า
#AgileSuccess is reaching hyper-productivity by developing software as if playing a game.
(การประสบความสำเร็จด้าน agile คือการเข้าถึงจุด hyper-productivity โดยพัฒนาซอฟต์แวร์เหมือนกับกำลังเล่นเกม)
ไม่น่าเชื่อ ติด 1 ใน 5 ด้วย >> How do you define Agile success?
ดีใจมากครับ ตอนเห็นว่าเค้าเอาไปลง ตาลุกว่าว หน้าร้อนผ่าว สติแตกไปเลย 
แผนที่การคลอบคลุมสัญญาณโทรศํพท์มือถือปัจจุบันของบริษัท AT&T ยังมีพื้นที่อีกมากที่ยังไม่มี coverage
การใช้ TDD ขับเคลื่อนการเขียนโค้ดโดยเริ่มจากการเขียนเทสต์ก่อน (บางสำนักจะเรียกเจาะจงว่าเป็น TFD – Test First Design) นอกจากจะช่วยทำให้เราสามารถออกแบบโค้ดให้สอดคล้องกับสเปกที่เขียนจากเทสต์แล้ว ยังทำให้โค้ดที่เขียนมี test coverage ในตัวไปด้วย เป็นวิธีที่ดีกว่าเขียนโค้ดให้เสร็จแล้วมาเขียนเทสต์ cover ภายหลัง ซึ่งค่อนข้างจะน่าเบื่อและอาจหลุดการเทสต์หลายๆกรณีได้
คราวนี้คำถามอยู่ที่ว่าเราควรจะเขียน code coverage ขนาดไหนถึงจะพอ อย่าลืมว่าเทสต์ก็เป็นส่วนหนึ่งของโค้ดเบสที่ต้อง maintain การมีโค้ดหรือเทสต์ที่ไม่จำเป็นก็กลายเป็นขยะโดยไม่รู้ตัว
สังเกตดูหลายๆบทความมีการพูดถึงการเขียนเทสต์ที่มุ่งเป้าที่จะ cover code ให้ครบ 100% ทำให้สงสัยว่าจำเป็นหรือไม่ ลองดูตัวอย่างข้างล่างนี้แล้วนึกตามว่าหัวข้อไหนจำเป็น/ไม่จำเป็นที่จะต้องเขียนเทสต์
สวัสดีครับ post นี้เป็นตอนที่ 5 ใน Series ของผม นับจาก post ที่แล้วนี่กี่เดือนแล้วเนี่ย ไม่ได้เขียนมาพักใหญ่ๆ ก็ไม่มีข้อแก้ตัวครับ ช่วงนี้งานที่ออฟฟิสยุ่งอย่างแรง (นี่กำลังแก้ตัวใช่มั้ยเนี่ย -_-’) ช่วงนี้เป็นช่วงที่กำลังจะปิด Project ให้ได้ แต่การปิดโปรเจคนี่ไม่ใช่เรื่องง่ายๆเลยทีเดียวล่ะ มีบางคนบอกว่า งานอีก 10% ที่เหลือ มักจะใช้เวลาเท่ากับ 90% ของทั้งหมด ซึ่งอันนี้ผมว่าค่อนข้างจริงครับ มีใครเห็นด้วยมั้ย
เล่าถึงสถานการณ์ Agile project ของทีมผมหน่อย ตอนนี้ก็กำลังจะเข้า Iteration ที่สามครับ หลังจากผ่านสอง Iteration แรกมา ก็ถือว่าเป็นการทดลองงานที่ได้ประสบการณ์ที่คุ้มค่าเลยทีเดียว ของแบบนี้ถ้าไม่ได้ลองก็ไม่รู้ เพราะว่าไม่มี Process ไหนที่เข้ากันได้ 100% กับทีมของเรา อ่านหนังสือ Agile ยังไงก็ไม่มีทางเข้าใจลึกซึ้งไปกว่าการได้ลงมือทำจริงๆ เพราะว่าทำแล้วก็จะต้องมีการปรับแก้จากสิ่งที่อ่านมาให้เข้ากับสถานการณ์และปัญหาที่เกิดขึ้นจริงของทีม น้องๆในทีมหลังจากที่ได้ลองทำ Test Code, ทำ Refactoring, Daily Meeting, etc.. ที่ขลุกขลักกันช่วงแรกๆ ตอนนี้ก็เริ่มทำงานได้คล่องขึ้น คิดว่า ประมาณอีกสองสาม Iteration คงจะลงตัวกว่านี้
กลับมาว่ากันต่อเรื่องการ Adopt Agile ครับ ตอนก่อนหน้านี้ผมพูดถึงเรื่องการรื้อระบบใหม่เพื่อจะปรับให้สามารถทำ Test Driven ได้ หลังจากที่ทุกอย่างเสร็จเรียบร้อย ตอนแรกว่าจะขยายความเรื่อง MVP ในตอนที่ห้านี้ แต่พอลองวางๆโครงเรื่องแล้วรู้สึกว่าค่อนข้างจะ Technical เลยทีเดียว อาจจะไม่ค่อยเหมาะกับ Style ของ Agile66 เท่าไหร่ เลยขอจบเรื่อง MVP ไว้ในตอนที่สี่ละกันครับ…
Post นี้จะเล่าถึงปัญหาที่เจอที่ฝั่ง Dev ในการทำงานร่วมกับ QA และ PM และเป็นปัญหาที่ผมมองว่าหลักการของ Agile สามารถช่วยแก้ปัญหานี้ได้ ก่อนอื่น ผมขอเล่าย้อนไปถึงสมัยก่อนที่จะมีการศึกษา Agile เพื่อที่จะเอาเข้ามาใช้ การทำงานในโปรเจคของผมจะมี Cycle การทำงานประมาณนี้ครับ
พอดีมีแรงบันดาลใจให้อยากแปล blog อันหนึ่งซึ่งเคยมีเพื่อนที่บริษัทส่งมาให้เมื่อนานมาแล้ว เนื้อหามันก็มีว่า
บริษัทเหล่านี้ทำโปรเจคเป็นร้อยๆโปรเจคพร้อมๆักัน บ้างก็เป็น Agile จริงแต่ก็มีหลายทีมที่ไม่ใช่
สิ่งที่ตามมาคือความจริงที่เจ็บปวดของทีมที่ทำ Agile ต้องเผชิญ เมื่ออยู่ในองค์กรณ์ซึ่งยังใหม่กับ Agile หรือทำ Agile ไปเพียงแค่เพราะเหตุผลทางการตลาดเท่านั้น
เรื่องมันก็มีอยู่ว่า …
คุณรู้สึกดีมากๆ คุณได้พบปะผู้คุยกับผู้คนหลายหลากในแวดวงซอฟต์แวร์ที่รู้จัก Agile แบบผิวเผิน และคุณรู้สึกดีที่ได้บอกเขาเหล่านั้นว่าคุณกำลังทำ Agile ในโปรเจคของคุณอย่างไร คุณบอกเขาถึงความมหัศจรรย์ของการที่ Agile สามารถทำให้คุณส่งมอบมูลค่าทางธุรกิจให้กับลูกค้าได้จริงๆ บอกเขาถึงความสุขที่คุณได้กลับมาจากการมีสมดุลย์ของงานและชีวิตครอบครัวเมื่อคุณปฏิบัตตามแนวทางของ Agile อย่างเคร่งครัด บอกเขาว่าคุณรู้สึกผูกพันธ์และทุ่มเทให้กับโปรเจค บอกเขาว่าคุณมีทีมที่ยอดเยี่ยมและป็นมืออาชีพ
ก็ดูจะโอนะ
จุดสุดยอดของเรื่องมาเกิดขึ้นตอนบ่ายวันศุกร์วันหนึ่ง เมื่อพวกที่บริษัทตราหน้าว่าไม่ทุ่มเทให้กับการทำงาน ได้รับซองขาวเชิญให้ออก และแน่นอนว่าทีมคุณก็เป็นหนึ่งในนั้น
Latest Posts