เมื่อผมอยากทำซอฟต์แวร์ใช้เอง ตอนที่ 5: ยุค Agile รอบละ 2 สัปดาห์

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

ในตอนที่ 4 ต้นทำระบบห้องสมุดทีละรอบ

บรรณารักษ์ได้ลองของจริงตั้งแต่เดือนที่ 2 ดีกว่าการรอถึงเดือนที่ 14 ในตอนที่ 3 เยอะ

แต่แต่ละรอบก็ยังกินเวลาหลายเดือน

ตอนนี้ขยับมาปี 1999

ยุคที่ร้านค้าเริ่มเปิดหน้าร้านบนอินเทอร์เน็ต

แล้วหลายเดือนต่อรอบ มันช้าเกินไปแล้ว

วิธีที่ทีมยุคนี้หันมาใช้ เรียกว่า Agile (ทำเป็นรอบสั้นๆ ไม่กี่สัปดาห์ ทุกรอบต้องได้ของที่คนใช้ได้จริง และเปลี่ยนแผนได้ตลอด)

ตัวละครหลักรอบนี้เป็นคนใหม่ ชื่อ “ฝน”

ฝนเป็นตัวละครสมมติ ร้านค้าในเรื่องก็สมมติ แต่เครื่องมือและวิธีทำงานที่ฝนเจอ มีอยู่จริงในยุคนั้น

แผนภาพ: ปี 1999 ลูกค้าโทรสั่งจากแคตตาล็อกให้ร้านจดเอง ร้านอยากมีเว็บที่ลูกค้าเลือกของ ใส่ตะกร้า และสั่งซื้อได้เอง เพราะคู่แข่งเปิดเว็บไปแล้ว

ปี 1999 ร้านที่อยากขายบนเว็บ#

ฝนทำงานในทีมเล็กๆ 4 คน

ลูกค้ารายใหม่เป็นร้านขายอุปกรณ์เดินป่า ขายผ่านแคตตาล็อกกับโทรศัพท์มาหลายปี

เจ้าของร้านอยากมีร้านบนเว็บ ให้คนเลือกของ ใส่ตะกร้า แล้วสั่งได้เอง

แล้วก็รีบด้วย

เพราะร้านคู่แข่งอีกเจ้าเพิ่งเปิดเว็บไปแล้ว

ถ้าทีมฝนทำแบบตอนที่ 4 รอบละหลายเดือน กว่าร้านจะได้ขายจริง คู่แข่งก็แย่งลูกค้าไปหมดแล้ว

ตลาดยุคนี้ไม่รอใครครับ

Agile ต่างจากการทำทีละรอบแบบเดิมยังไง?#

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

ทีมฝนตกลงกันว่า รอบละสองสัปดาห์

ทุกรอบต้องใช้ได้จริง#

ไม่ใช่ภาพหน้าจอสวยๆ ไว้โชว์ ไม่ใช่ demo ที่กดได้แค่ปุ่มเดียว

รอบแรก ร้านมีหน้ารวมสินค้า กับหน้ารายละเอียดของแต่ละชิ้น คนเข้ามาดูของได้จริง

รอบที่สอง ค้นหาสินค้าได้

รอบที่สาม เพิ่มของลงตะกร้าได้

ของที่เสร็จแต่ละรอบ ต้องพร้อมให้ลูกค้าใช้ ถ้าเจ้าของร้านบอกว่าเอาขึ้นเลย

เจ้าของร้านเป็นคนเลือก#

ทีมฝนเขียนงานทั้งหมดที่อยากทำลงกระดาษโน้ต แผ่นละเรื่อง แปะเรียงบนกระดาน

ทุกต้นรอบ เจ้าของร้านมานั่งด้วย แล้วเลือกว่าสองสัปดาห์นี้ เรื่องไหนสำคัญที่สุด

ทีมบอกว่าทำได้กี่เรื่อง เจ้าของร้านเรียงว่าเรื่องไหนก่อน

แผนภาพ: รายการงานห้าเรื่อง เจ้าของร้านย้าย "ใส่ตะกร้า" จากกลุ่มล่างขึ้นบนสุด เหลือรอยเดิมเป็นกรอบจาง รอบสองสัปดาห์นี้ทีมทำสองเรื่องบน อีกสามเรื่องรอรอบหน้า

เปลี่ยนแผนไม่ใช่ความผิดใคร#

รอบที่สอง เจ้าของร้านเห็นของจริงแล้วพูดว่า

“ลูกค้าโทรมาถามเรื่องไซส์รองเท้าทุกวันเลย ขอตารางไซส์ก่อนระบบสมาชิกได้มั้ย”

ถ้าเป็นยุคตอนที่ 3 ประโยคนี้แปลว่าต้องแก้แฟ้ม spec เซ็นใหม่ แล้วหาว่าใครผิด

ยุคนี้แค่ย้ายกระดาษโน้ตแผ่นนั้นขึ้นไปบนสุด

จบ 555+

แผนเปลี่ยนเพราะเจ้าของร้านรู้มากขึ้น ไม่ใช่เพราะใครทำพลาด

ปี 1999 ทีมเขียนโค้ดด้วยกันยังไง?#

ทุกคนแก้โค้ดชุดเดียวกันพร้อมกันได้ผ่าน CVS เห็นรายการปัญหาเดียวกันใน Bugzilla และมี test ที่รันเองให้ทุกครั้งที่แก้

ตรงนี้คือสิ่งที่ทำให้รอบละสองสัปดาห์เป็นไปได้จริง

แผนภาพเทียบ: RCS ล็อกไฟล์ให้แก้ได้ทีละคน คนอื่นต้องรอคิว ส่วน CVS ให้ทุกคนแก้พร้อมกันจากที่เก็บโค้ดกลางแล้วรวมให้

CVS ให้หลายคนแก้งานเดียวกันได้#

ในตอนที่ 4 ทีมต้นใช้ RCS ใครจะแก้ไฟล์ไหน ต้องยืมออกมา คนอื่นแก้ไฟล์นั้นไม่ได้

ทีมฝนใช้ CVS ที่ Dick Grune เริ่มเขียนและปล่อยออกมาในปี 1986 ต่อมา Brian Berliner เขียนต่อจนเป็นตัวที่คนใช้กันแพร่หลาย

ทุกคนดึงโค้ดทั้งชุดมาไว้ที่เครื่องตัวเอง แก้ไปพร้อมๆ กันได้ แล้วส่งกลับเข้าที่เก็บกลาง

ถ้าสองคนแก้ไฟล์เดียวกัน CVS จะรวมให้เอง ติดตรงไหนค่อยให้คนมาดู

ไม่ต้องรอคิวยืมไฟล์อีกแล้ว

CVS นี่แหละ คือรุ่นพี่ของเครื่องมืออย่าง git ที่มาทีหลัง

Bugzilla รายการปัญหาที่ทุกคนเห็น#

เมื่อก่อน ปัญหาอยู่ในสมุดจดของใครของมัน หรือในอีเมลที่ส่งต่อกันไปมา

ทีมฝนใช้ Bugzilla ที่ Netscape ปล่อยเป็น open source ในปี 1998

ทุกปัญหาเป็นหน้าเว็บหนึ่งหน้า เขียนว่าเจออะไร ใครรับไปแก้ แก้ถึงไหนแล้ว

ใครในทีมเปิดดูก็เห็นตรงกัน

เครื่องมือแบบนี้ต่อมาโตเป็น Jira (ปี 2002) และ GitHub Issues (ปี 2009) ที่หลายทีมใช้กันทุกวันนี้

test ที่รันเอง#

ร้านใหญ่ขึ้นทุกรอบ ทุกครั้งที่แก้อะไร ก็กลัวว่าจะไปทำของเดิมพัง

ทีมฝนเลยเขียน test อัตโนมัติ เก็บไว้ (โค้ดอีกชุดที่คอยลองใช้โปรแกรม แล้วเช็กว่าผลออกมาถูกมั้ย)

เช่น ใส่รองเท้า 2 คู่ลงตะกร้า ยอดรวมต้องถูก ลบออก 1 คู่ ยอดต้องลดลง

แก้โค้ดเสร็จ สั่งรันทีเดียว test ร้อยกว่าข้อเช็กให้หมดในไม่กี่นาที

ยุคนั้นมีเครื่องมือช่วยเขียน test แบบนี้แล้ว อย่าง JUnit ที่ Kent Beck กับ Erich Gamma เขียนขึ้นในปี 1997 สำหรับภาษา Java

ทำงานด้วยกันผ่านอินเทอร์เน็ต#

วันไหนฝนทำงานจากบ้าน ก็ต่อเน็ตเข้ามาดึงโค้ดจาก CVS เปิด Bugzilla ดูงาน แล้วคุยกับทีมทางอีเมล

ตัวอย่างที่ใหญ่ที่สุดของการทำ software ด้วยกันผ่านเน็ตในยุคนั้น คือ Linux

ปี 1991 Linus Torvalds นักศึกษาฟินแลนด์อายุ 21 ประกาศในกลุ่มสนทนาบนเน็ตว่ากำลังเขียนระบบปฏิบัติการเล่นๆ

ไม่กี่ปีต่อมา มีคนจากทั่วโลกช่วยกันเขียนเกินร้อยคน ส่วนใหญ่ไม่เคยเจอหน้ากันเลย

Agile เพิ่งเกิดปี 2001 หรือเปล่า?#

ไม่ใช่ วิธีแบบนี้มีทีมใช้กันมาก่อนหลายปีแล้ว ปี 2001 เป็นปีที่มีคนตั้งชื่อรวมให้มันว่า Agile

กลางยุค 1990 เริ่มมีคนเขียนวิธีพวกนี้ออกมาเป็นระบบ

Scrum Ken Schwaber กับ Jeff Sutherland นำเสนอที่งานประชุม OOPSLA ปี 1995 ทำงานเป็นรอบสั้นๆ ที่เรียกว่า sprint

XP (Extreme Programming) Kent Beck เริ่มใช้ในโครงการระบบเงินเดือนของ Chrysler ตั้งแต่ปี 1996 เน้นรอบสั้น test อัตโนมัติ และคุยกับลูกค้าบ่อยๆ

แล้วเดือนกุมภาพันธ์ปี 2001 คน 17 คนจากหลายสำนักไปเจอกันที่รีสอร์ตสกี Snowbird ในรัฐ Utah 3 วัน

ทั้งเล่นสกี ทั้งเถียงกัน 555+

ผลคือเอกสารสั้นๆ ชื่อ Agile Manifesto ที่ทุกคนเซ็นชื่อร่วมกัน

ไม่ได้คิดวิธีใหม่ขึ้นมา แต่ตั้งชื่อให้สิ่งที่หลายทีมทำกันอยู่แล้ว

ในเรื่องของเรา ทีมฝนก็ไม่รู้หรอกว่าตัวเองกำลังทำ Agile

รู้แค่ว่าเจ้าของร้านพอใจ ก็พอแล้ว

เส้นเวลา: Scrum 1995, XP 1996, JUnit 1997, ทีมฝนในเรื่องทำแบบนี้อยู่แล้วปี 1999, แล้วปี 2001 คน 17 คนตั้งชื่อรวมว่า Agile Manifesto

เสร็จแล้ว แต่ยังไม่เสร็จ#

รอบที่หก ทีมฝนทำ ตะกร้าสินค้าใหม่

เลือกของ ใส่ตะกร้า แก้จำนวน คิดค่าส่ง จ่ายเงิน ครบในหน้าเดียว

บ่ายวันศุกร์ ทีมเรียกเจ้าของร้านมาดู

เธอลองกดเองทุกปุ่ม แล้วยิ้มกว้าง

“อันนี้แหละที่อยากได้”

test ผ่านครบ เจ้าของร้านชอบ ทีมก็คิดว่าเสร็จแล้ว

แต่ลูกค้าของร้านยังใช้ไม่ได้

เพราะกว่าโค้ดจะขึ้นเว็บจริงได้ ต้องผ่านอีกหลายด่าน

แผนภาพ: โค้ดผ่าน test และเจ้าของร้านชอบแล้ว แต่ต้องผ่านสี่ด่าน ส่งต่ออีกทีม เครื่องทดสอบไม่เหมือนเครื่องจริง รออนุมัติเดือนละครั้ง ติดตั้งด้วยมือ ลูกค้าจึงยังใช้ไม่ได้

ด่านที่ 1 ส่งต่อให้อีกทีม#

ทีมฝนเขียนโค้ด แต่ไม่ได้ดูแลเครื่องที่รันเว็บจริง

เครื่องพวกนั้นเป็นของทีม operations อีกทีมหนึ่ง

ฝนต้องเขียนเอกสารส่งงาน แล้วต่อคิว เพราะทีมนั้นมีงานของคนอื่นรออยู่ก่อนแล้วหลายงาน

ด่านที่ 2 เครื่องทดสอบไม่เหมือนเครื่องจริง#

ทีม operations เอาโค้ดไปลงเครื่องทดสอบก่อน

ปรากฏว่าพัง

บนเครื่องของฝน ตะกร้าทำงานดี แต่เครื่องทดสอบตั้งค่าไม่เหมือนกัน รุ่นของโปรแกรมที่ลงไว้ก็ไม่ตรงกัน

อ้าว 555+

โค้ดเลยถูกส่งกลับมาให้ทีมฝนแก้ แล้วต่อคิวใหม่

ด่านที่ 3 รออนุมัติ#

แก้ผ่านแล้ว ก็ยังขึ้นไม่ได้

ร้านนี้ปล่อยของใหม่ขึ้นเว็บเดือนละครั้ง ตอนดึกๆ ที่คนเข้าเว็บน้อย

และต้องมีคนเซ็นอนุมัติก่อน

แก้เสร็จไม่ทันรอบปล่อยของของเดือนนี้ ก็ต้องรอเดือนหน้า

ด่านที่ 4 ติดตั้งด้วยมือ#

คืนวันปล่อยของ คนในทีม operations นั่งทำตามคู่มือติดตั้งหลายสิบหน้า

ก๊อปไฟล์ แก้ค่า restart โปรแกรม ทีละขั้น ด้วยมือทั้งหมด

ข้ามขั้นตอนไปขั้นเดียว เว็บล่มทั้งคืน

แผนภาพเวลา: เขียนตะกร้าสองสัปดาห์ แต่รอผ่านด่านอีกหกสัปดาห์ ด่านสุดท้ายคือติดตั้งด้วยมือกลางดึกตามคู่มือหลายสิบหน้า ข้ามไปขั้นเดียวเว็บล่มทั้งคืน

สองสัปดาห์ กับหกสัปดาห์#

นับดูแล้ว ทีมฝนเขียนตะกร้าใหม่เสร็จในสองสัปดาห์

ลูกค้าของร้านได้ใช้จริง อีกหกสัปดาห์ต่อมา

เวลาเกือบทั้งหมดหายไปกับด่านพวกนี้ ไม่ใช่กับการเขียนโค้ด

สิ่งที่ผมได้จากยุคนี้#

ลองทำเอง

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

แผนเปลี่ยนได้ เพราะคนที่รู้ว่าอะไรสำคัญที่สุด คือคนที่ใช้งานจริง

ส่วนเครื่องมืออย่าง CVS, Bugzilla และ test อัตโนมัติ ก็ทำให้คน 4 คนแก้งานชุดเดียวกันได้โดยไม่ทับกัน

เก็บศัพท์

ศัพท์	ความหมายแบบภาษาคน
Agile	ทำเป็นรอบสั้นๆ ไม่กี่สัปดาห์ ทุกรอบได้ของใช้ได้จริง เปลี่ยนแผนได้
Scrum	วิธีแบบ Agile ที่ทำงานเป็นรอบสั้นเรียกว่า sprint
XP (Extreme Programming)	วิธีแบบ Agile ของ Kent Beck เน้นรอบสั้นและ test อัตโนมัติ
CVS	เครื่องมือเก็บประวัติโค้ดที่หลายคนแก้พร้อมกันได้ รุ่นก่อน git
Bugzilla	เว็บรายการปัญหาที่ทั้งทีมเห็นร่วมกัน
test อัตโนมัติ	โค้ดที่คอยลองใช้โปรแกรมแล้วเช็กผลให้เอง
JUnit	เครื่องมือเขียน test อัตโนมัติสำหรับภาษา Java ปี 1997
operations	ทีมที่ดูแลเครื่องที่รันระบบจริง

จดบันทึก

ถ้าเพิ่งเข้ามาอ่านตอนนี้ ย้อนไปเริ่มที่ตอนที่ 1 ได้ครับ

ตอนที่ 2 สอนว่ายิ่งรู้ว่าผิดช้า ยิ่งเจ็บ

ตอนที่ 3 สอนว่ารอยต่อระหว่างคนคือที่ที่ความผิดซ่อนอยู่

ตอนที่ 4 สอนว่าให้คนใช้ดูเร็ว และทำเรื่องที่น่ากลัวที่สุดก่อน

ตอนนี้รอบสั้นเหลือสองสัปดาห์ และคนใช้เป็นคนกำหนดทิศทาง

แต่รอยต่อระหว่างคนจากตอนที่ 3 ก็กลับมาอีก คราวนี้อยู่ระหว่างทีมที่เขียนโค้ด กับทีมที่เอาโค้ดขึ้นเว็บ

คำถามที่พบบ่อย#

Agile คืออะไร?

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

Agile ต่างจาก Iterative ยังไง?

ทั้งคู่ทำเป็นรอบ แต่ Iterative แบบในตอนที่ 4 รอบหนึ่งยาวเป็นเดือนๆ และคนใช้แค่ได้ลอง ส่วน Agile รอบสั้นเหลือไม่กี่สัปดาห์ ทุกรอบต้องพร้อมใช้จริง และให้คนใช้เป็นคนกำหนดว่าทำอะไรก่อน

Agile Manifesto เขียนขึ้นเมื่อไหร่?

วันที่ 11 ถึง 13 กุมภาพันธ์ 2001 ที่รีสอร์ตสกี Snowbird รัฐ Utah คน 17 คนจากหลายวิธี เช่น Scrum และ XP ร่วมกันเขียนและเซ็นชื่อ

Scrum กับ XP ต่างกันยังไง?

Scrum เน้นวิธีจัดงานของทีมเป็นรอบที่เรียกว่า sprint ส่วน XP เน้นวิธีเขียนโค้ดด้วย เช่น เขียน test อัตโนมัติ และปล่อยของบ่อยๆ หลายทีมใช้สองอย่างนี้ร่วมกัน

ทำไมทำ Agile แล้ว ของยังขึ้นเว็บช้า?

เพราะ Agile เร่งการเขียนโค้ด แต่ขั้นตอนเอาโค้ดขึ้นระบบจริงยังเหมือนเดิม ทั้งส่งต่อทีม เครื่องทดสอบไม่ตรงกับเครื่องจริง รออนุมัติ และติดตั้งด้วยมือ

Next → ตอนที่ 6: ยุค DevOps ปล่อยของทุกวัน ตอนหน้าเป็นยุค DevOps ถ้าทีมเขียนโค้ดกับทีมดูแลเครื่องมาทำงานด้วยกัน แล้วให้เครื่องเป็นคนติดตั้งแทนคน หกสัปดาห์นั้นจะเหลือเท่าไหร่ ผมจะลองดูครับ