The Nature of Software Development เขียนโดย Ron Jeffries เป็นหนังสือที่พยายามอธิบายการทำซอฟต์แวร์ให้ง่าย และนำเสนอการทำงานเป็นรอบๆ (Iterative) ได้น่าสนใจมาก เน้นให้ผู้อ่านปรับทัศนะคติการทำซอฟต์แวร์ใหม่ ในแบบที่เขาเรียกว่า “The Natural Way” เพราะเขาเชื่อว่ามันเป็นหนทางที่เข้าใจง่าย เน้นการส่งมอบคุณค่าให้ได้ไว และบ่อยๆ
หนังสือเล่มนี้ใช้ภาษาอ่านไม่ยาก คนทั่วไปอ่านได้ เหมือนกำลังฟังลุง Ron บ่นๆ ไปเรื่อยๆ เพื่อปูพื้นฐานและปรับทัศนคติ ใครอ่านที่ผมสรุปไว้และสนใจอยากลองหาฉบับเต็มมาอ่าน ลองดูได้จากลิงค์นี้ครับ The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece
การทำซอฟต์แวร์ขึ้นมาตัวหนึ่ง จะมีหลายกระบวนการ เช่น วางแผน พัฒนา จัดการคนทำงาน เพื่อให้งานมันเสร็จ และผู้ว่าจ้าง หรือลูกค้าเรา สามารถใช้งานซอฟต์แวร์นั้นได้ ซึ่งสิ่งที่เราส่งมอบให้ มันคือสิ่งที่มีคุณค่า เพราะถ้าซอฟต์แวร์ยังเป็นแค่โค้ด หรือยังเล่นไม่ได้ ต่อให้เขียนโค้ดดีแค่ไหน มันก็ยังไร้ค่าใช่หรือเปล่า?
แล้วคำถามต่อไปคือ เมื่อซอฟต์แวร์ มันใช้เวลาผลิตนาน จะให้มันเสร็จไวๆ มอบของ(คุณค่า)ให้ลูกค้าได้เห็นบ่อยๆ จะทำอย่างไรล่ะ?
ค้นหาคุณค่าซอฟต์แวร์ของคุณให้เจอ
เจ้ายอดพีระมิดในรูปนั่นหละ คือสิ่งที่เราต้องค้นหามันให้เจอ ว่าคุณค่าของซอฟต์แวร์เราคืออะไร ซึ่งคุณค่า (Value) ที่ว่า คือ สิ่งที่เราต้องการในงานชิ้นนี้ (What you want) ซึ่งเป็นได้หลายกรณี ตั้งแต่แบบจับต้องได้คือ เงิน ไปจนถึงจับต้องไม่ได้ อย่าง เสียงหัวเราะ ความสุข ความสะดวกสบาย
การทำให้เกิดคุณค่า จะเริ่มจากส่วนล่างสุดของพีระมิด ไล่เรียงขึ้นมา โดยเริ่มจาก…
- Guiding – ทีมทำงานต้องเข้าใจว่าอะไรคือสิ่งที่พวกเขาจะต้องทำ เราต้องการอะไร คุณค่าของงานคืออะไร เรามีทรัพยากร เช่น เครื่องมือ เวลา ฯลฯ อย่างไร
- Organizing – ใช้ความสามารถของทีมให้มีประสิทธิภาพ และสร้าง Team มีการพัฒนาความชำนาญขึ้นไปเรื่อยๆ
- Planning – วางแผน ตัดงานเป็นชิ้นตามคุณสมบัติ (Feature) ลำดับความสำคัญตามสิ่งที่ต้องการ เพื่อให้ได้สาระสำคัญของงานนั้นออกมาก่อน
- Building – สร้างงานเป็นชิ้นๆ ตามคุณสมบัติ (Feature) เพื่อส่งมอบงานให้ได้บ่อยๆ สามารถเห็นความคืบหน้าได้เรื่อยๆ
- Slicing – ตัดคุณสมบัติออกเป็นงานให้เล็กที่สุด ที่จะทำให้ส่องมอบงานได้ไว และส่งงานได้ตลอดเวลา
- Quality – นำวิธีการต่างๆมาประยุกต์ใช้เพื่อสร้างงานให้มีคุณภาพอยู่ตลอดเวลา
คุณค่าที่คุณคู่ควร (Value)
คุณค่า (Value) คือ สิ่งที่เราทุกคนต้องการ (What you want) และในมุมมองของซอฟต์แวร์นั้น เราจะไดรับคุณค่าของมันก็ต่อเมื่อมีการส่งมอบคุณสมบัติ (Features) ของซอฟต์แวร์นั้นออกมา ไม่ว่าจะแบบจับต้องได้ อย่างการทำให้ประหยัดเงิน ประหยัดเวลา หรือจับต้องไม่ได้อย่างการช่วยสร้างความสะดวกสบายในชีวิต หรือทำให้ผู้ใช้ยิ้มได้ ดังนั้น ผู้เขียนจึงให้คำนิยามคำว่า Value คือ “What we want”
ตามที่กล่าวไปข้างต้น คุณค่าของซอฟต์แวร์เริ่มมีหลังจากที่เราส่งมอบซอฟต์แวร์ไปแล้ว ดังนั้น การส่งมอบได้บ่อยๆ ก็เหมือนการส่งมอบคุณค่าให้ลูกค้าได้รับได้เห็นบ่อยๆ และสามารถพิจารณากันได้ทันทีว่า คุณค่าที่ส่งออกมา มันมีคุณค่าจริงๆไหม และที่กำลังจะทำต่อไป มันมาถูกทางแล้วหรือไม่ ซึ่งในภาษา Startup ใช้คำว่าทำ MVP (Minimum Viable Product) ขึ้นมาก่อน โดยจะมีหัวใจของซอฟต์แวร์ หรือฟีเจอร์ที่ที่เอาไปขายได้ ออกมาทดลองในตลาดก่อน
และวิธีการส่งมอบซอฟต์แวร์ได้บ่อยๆ จะทำได้ด้วยการชำแหละมันออกมาเป็นชิ้นเล็กๆ แต่ต้องเป็นชิ้นเล็กๆ ที่ทำงานได้ด้วยนะครับ อุปมาเหมือนลูกค้าสั่งให้สร้างรถยนต์ โดยเราจะส่งมอบครั้งแรกอาจมีแค่โครงรถประกอบล้อที่พอเข็นได้ ยังไม่มีเครื่องยนต์ ซึ่งจะไม่ใช่การส่งเครื่องยนต์ พวงมาลัย ล้อ ไปให้ลูกค้าสามชิ้น
ดังนั้น การแยกชิ้นงานเป็นชิ้นเล็กๆ คือ การแยกตามคุณสมบัติ (Features) เช่น คุณสมบัติต้องกันฝนกันลมได้ สิ่งที่ส่องมอบคือ โครงสร้างภายนอกของรถ, หรือคุณสมบัติรถสามารถเคลื่อนที่ได้ สิ่งส่งมอบคือ โครงสร้างภายนอกที่ปรอกับใส่ล้อและสามารถเคลื่อนที่ได้ เป็นต้น
คุณค่าของการส่งมอบงานในแต่ละครั้ง จะมีคุณค่ามากจะน้อย อยู่ที่การเรียงลำดับงานที่จะทำ ซึ่งถ้าเอางานที่มีคุณค่าน้อยมาทำก่อน เสร็จไว ได้ส่งมอบก่อน (อาจด้วยเหตุผล มันทำง่ายกว่า) ก็จะไม่มีความน่าสนใจ กลับกันถ้าเอางานที่มีคุณค่ามากกว่ามาทำและส่งมอบก่อน งานจะได้รับความสนใจ และทำให้เห็นคุณค่าของงานได้ชัดเจนขึ้น เช่น ระบบสั่งอาหาร ที่ฟีเจอร์ใช้สั่งอาหาร ลูกค้าจะสามารถทำเงินได้ทันที เห็นคุณค่าทันที มากกว่าการที่เราส่งฟีเจอร์สมัครสมาชิกและล็อกอินไปให้กับลูกค้า
ยิ่งลำดับงานตามคุณสมบัติที่มีคุณค่าขึ้นมาทำก่อน และซอยชิ้นงานให้ย่อยเล็กลง จะสามารถส่งมอบงานให้เห็นได้เรื่อยๆ ไวขึ้น คุณค่าของงานจะค่อยๆมากขึ้นไปเรื่อยๆ นั่นเอง
มุ่งสู่สิ่งที่ดีกว่า ด้วยแนวคิดการทำทีละฟีเจอร์ (Guiding)
แบบที่เรารู้ๆกัน โครงการ (Project) ทุกชิ้นจะต้องมีกำหนดเวลาเสร็จชัดเจนเสมอ (Deadline) และต้องการได้ของครบทุกอย่างตามที่สั่งด้วย แต่พอนำไปปฎิบัติจริง ก็มักไม่ได้ตามนั้น, เพราะอะไร?
เพราะ การวางแผนที่ใช้ในโครงการส่วนใหญ่มัก จะทำเป็นก้อนใหญ่ และตัดเฟสโดยแบ่งตามประเภทกิจกรรม (Activity-based phase) เช่น เริ่มจากการวิเคราะห์ (Analysis) เสร็จแล้วนำไปออกแบบต่อ (Design) และก็ไปเขียนโค้ด (Coding) บลาๆๆ ซึ่งถ้าทำแบบนี้กว่าจะไปถึงเฟสหลังๆ จะรู้ได้อย่างไรว่า จะไม่เกิดบั๊กในภายหลัง หรือมีการเปลี่ยนแปลงความต้องการช่วงกลางทาง ซึ่งถ้าเกิดเรื่องเหล่านี้ขึ้นมา ก็แปลว่าเราจะไม่สามารถส่งมอบงานที่สมบูรณ์ทั้งหมดได้ใช่หรือไม่? … คำตอบคือ ก็ใช่..
และถ้าเปลี่ยนเป็นทีมส่งมอบงานออกไปได้บ่อยๆ เริ่มตั้งแต่การวางแผนเป็นชิ้นงานเล็กๆ แบบทีละฟีเจอร์ (Feature by Feature) จากนั้นค่อยนำเข้ากระบวนการ ออกแบบ เขียนโค้ด ทดสอบ เสร็จงานก็ปล่อยฟีเจอร์นั้นออกไปขาย และค่อยเริ่มทำฟีเจอร์ชิ้นต่อไป แบบนี้จะดีกว่าไหมครับ?
การทำทีละฟีเจอร์ นอกจากส่งมอบงานได้บ่อยๆ ทำให้ลูกค้าเห็นความเคลื่อนไหวของงานแบบที่จับต้องได้อยู่ตลอดเวลา ลูกค้าเอาไปใช้งานได้ทันที ส่วนตัวทีมพัฒนาเองก็ดูแลโครงการทั้งหมดง่ายขึ้นด้วย เพราะดูแลเป็นฟีเจอร์เล็กๆ ให้เสร็จไปทีละส่วน ก็จะ Win-Win กว่าไหม?
อ่านถึงตรงนี้ลองนึกย้อนกลับไปเทียบกับสิ่งที่ตัวเองกำลังทำ หรือกำลังสั่งให้ทีมพัฒนาทำอยู่ ว่ามันดีกว่าหรือแย่กว่ากัน?..
วิธีจัดการงานทีละฟีเจอร์ให้มีประสิทธิภาพ (Organizing)
บางครั้งงานชิ้นหนึ่งจำเป็นต้องใช้ความสามารถหลากหลายเพื่อมาทำ เช่น Dev/UX/UI ซึ่งการจัดทีมแบบ Skill-set หรือจับคนที่มีความสามารถแบบเดียวกันไปอยู่ด้วยกัน แม้จะง่ายกับการบริหาร แต่ก็อาจไม่เหมาะสมกับงาน และทำให้งานเดินได้ช้าลง เพราะพวกเขาต้องสลับหมุนเวียน ละจากงานหนึ่งไปงานหนึ่ง ออกไปขอคำปรึกษาจากผู้รู้ภายนอกทีม เช่น ฝ่ายกราฟฟิก ต้องไปถามฝ่ายทำ UX และไปถามฝ่ายพัฒนาถึงความเป็นไปได้ จากนั้นค่อยกลับมาทำงานของตนเอง นั่นจะหมายถึงเวลาที่สูญเสียแบบเปล่าประโยชน์ (แม้จะดูเล็กน้อยก็ตาม)
ดังนั้น วิธีการแก้ปัญหาคือ สร้างทีมทีมีผู้รู้ในแต่ละเรื่องที่จำเป็นสำหรับฟีเจอร์นั้นๆ มารวมกัน หรือเรียกว่า Feature Team
แต่การทำ Feature Team ไม่ได้ง่าย ยิ่งถ้าฟีเจอร์นั้น ต้องทำงานด้วยทีมหลายทีมผสมกัน เช่น ทำจากทีมหนึ่งเสร็จ ส่งไปให้ทีมสอง แล้วอาจต้องส่งกลับไปให้ทีมหนึ่งแก้อีกครั้ง ถ้าเป็นแบบนี้ ให้ดูผลงานและการทำงานของทีมก่อน ว่ายังไปกันได้ไหม ส่งมอบงานได้เร็วขึ้นและงานมีคุณภาพไหม ก็ให้ทำต่อไป แต่หากส่งมอบช้าลง งานแย่ลง ก็สามารถปรับเปลี่ยน Feature Team ใหม่ เพื่อให้สอดคล้องกับตัวงาน (ลุง Ron แกตอบง่ายดีเนอะ)
ในกรณีที่เรามีผู้เชี่ยวชาญในแต่ละด้านไม่เพียงพอเพื่อจับไปลงทีม เราควรหาผู้ที่มีความรู้ (อาจไม่จำเป็นต้องถึงขั้นผู้เชี่ยวชาญก็ได้) และสร้างกลุ่ม Community of Practice ขึ้นมา โดยให้ผู้รู้คนนั้นสอนคนอื่นๆ ในส่วนที่มีความจำเป็นต้องใช้ทำงาน เช่น Database Community of Practice หรือ UX Community of Practice
คนที่เป็นพนักงานระดับหัวหน้าหรือมีความอาวุโส ไม่ใช่ทำหน้าที่แค่เป็นหัวหน้าคนในทุ่มเท่านั้น แต่คุณต้องพาคนในทีมที่มีประสบการณ์น้อย ให้เรียนรู้ได้เท่าคนอื่นๆในทีมด้วย เพื่อความเข้ากันได้ของทีม และหัวหน้าทีมจะต้องดูแลช่วยเหลือคนเหล่านี้เพื่อให้เขามีความรับผิดชอบในงาน เรียนรู้ว่าต้องใช้ความรู้หรือเครื่องมืออะไรในการทำงาน และทำอย่างไร เพื่อให้งานสำเร็จ และนั่นจะทำให้เขากลายเป็นผู้เชี่ยวชาญอีกคนหนึ่ง
ลุง Ron ทิ้งท้ายไว้อย่างสะกิดต่อมเซเลบลัมในสมองว่า “ผู้เชี่ยวชาญที่เราจ้างมาด้วยราคาสูง ไม่ใช่จ้างมาเพราะเขาเป็นผู้เชี่ยวชาญเท่านั้น แต่ควรจ้างเขาเพื่อสร้างให้คนอื่นเป็นผู้เชี่ยวชาญได้เช่นกัน” (A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.)
การวางแผนทำทีละฟีเจอร์ (Planning)
วิธีส่งมอบงานให้ได้เร็ว จะเริ่มจากการมองภาพใหญ่ของงาน ว่าหัวใจหลักของมันคืออะไรบ้าง จากนั้นค่อยย่อยออกเป็นฟีเจอร์เล็กๆ เพื่อให้ชัดเจนขึ้น (ทำ Work Breakdown) แต่ยังไม่ต้องลงรายละเอียดมากนัก จะเสียเวลาและสร้างความสับสน ให้เพียงแยกเป็นฟีเจอร์หลัก และลำดับความสำคัญที่สร้างคุณค่าให้กับซอฟต์แวร์ก็เพียงพอ
แม้จะต้องใช้เวลาในการคิดและตัดสินใจเพื่อวางแผน แต่มันก็เป็นสิ่งที่ควรทำ และในขณะเดียวกัน ก็ต้องพร้อมที่จะเปลี่ยนแผนได้เสมอ เมื่อรู้ว่าคุณค่ามันเปลี่ยนแปลงไปแล้ว ณ เวลานั้น ซึ่งเรื่องแบบนี้เอง คนส่วนใหญ่จะกลัวการประมาณการ เช่น เรื่องของเวลาและงบประมาณ เพราะทำจริงๆ มักพบว่าไม่เป็นไปตามแผนที่คิดไว้ตอนแรก (และนี่เอง เป็นสิ่งที่ลุง Ron แนะนำว่า ยังไม่ต้องลงรายละเอียดกับมันในเวลานี้)
ลุง Ron บอกให้ลองปรับวิธีคิดใหม่ โดยประเมินเวลาและงบประมาณแบบเดิมนั่นแหละ แต่ให้วางแผนตัดชิ้นส่วนงานเป็นชิ้นย่อยๆ เพื่อพัฒนาแบบทีละฟีเจอร์ โดยไล่จากที่มีคุณค่ามากที่สุดออกมาก่อน จากนั้นส่งมอบงานออกมาเรื่อยๆ เพราะถ้ามันถึงที่สุดแล้ว เวลาหมด งบประมาณร่อยหรอ ไม่สามารถส่งมอบงานทั้งหมด แต่อย่างน้อยซอฟต์แวร์ก็ยังสามารถใช้งานฟีเจอร์หลักได้
ในบางครั้ง องค์กรอาจไม่แน่ใจที่จะยอมเสียเวลาและเงินเพื่อลงทุนทำโครงการ เพราะไม่รู้ว่าจะดีหรือไม่ เราอาจเสนอวิธีการแบบที่ลุงแนะนำ โดยการตั้งทีมพัฒนาและใช้วิธีค่อยๆส่งมอบงานทีละฟีเจอร์ ไล่ลำดับจากสำคัญๆ เพื่อให้ผู้บริหารและองค์กรได้เห็นภาพที่ชัดเจนขึ้น ว่าควรทำต่อไปหรือหยุดไว้เท่านี้
(อ่านมาถึงตรงนี้ จู่ๆผมก็นึกถึงบริษัทที่ผมเคยทำงานด้วย, สมัยก่อนผมขึ้นต้นด้วยการอธิบายวิธีการเลย ผู้ใหญ่ไม่ต้องรู้หรอกว่ามันดีอย่างไร แต่มันดีนะ ให้ผมทำไปเถอะ เชื่อผม…. และแล้ว เขาก็ไม่ได้เห็นด้วยกับวิธี และไม่อนุมัติให้ทำ.. เพราะเราไม่ได้ตัดแบ่ง ทำ Pilot Team, Pilot Project ทดลองให้เขาดูก่อน)
การส่งมอบงานออกมาเรื่อยๆ แบบนี้ จะเรียกรอบส่งงานนี้ว่า Iterations หรือ Sprints, โดยฟีเจอร์ (Feature) ที่ส่งมอบ จะเรียกว่า Story ซึ่งการทำงานแบบนี้ จะต้องวางแผนอยู่ตลอดเวลา เพราะมีการปรับเปลี่ยนเรื่อยๆ ไม่สามารถวางแผนในครั้งแรกครั้งเดียวแล้วใช้ได้เลย (ย้อนกลับไปย่อหน้าบนๆ อีกเช่นกัน ว่าทำไมไม่ต้องลงรายละเอียดกับมัรเยอะ และทำไมเรามักมีปัญหาเมื่อแผนเปลี่ยน)
ลุง Ron บอกว่า ไม่แนะนำให้ทำเป็น Story ใหญ่ๆ, ไม่แนะนำให้แตกงานย่อยๆ ออกมาเป็น Task ที่มีแต่ด้านเทคนิค (Technical) เพราะฝั่งที่ไม่มีความรู้ด้านเทคนิคจะอ่านไม่เข้าใจเลย และอีกประเด็นคือ การแปลง Story ออกมาเป็นฟีเจอร์เล็กๆ จะใช้เวลาทำและเข้าใจง่ายกว่าเป็น Technical Task
เมื่อวางแผนเสร็จแล้ว จะต้องประเมินเรื่องของเวลาที่ทำ ซึ่งตรงนี้ จะต้องให้ทีมทำงานเป็นผู้ที่กำหนดและตัดสินใจเวลาการทำงานเอง เพราะพวกเขารู้ดีที่สุดว่าความสามารถตนเองจะใช้เวลาเท่าไร และประสบการณ์ที่ผ่านมาจะบอกพวกเขาอีกเช่นกันว่าเป็นไปได้ไหม เราจะต้องไม่ไปเปรียบเทียบ และ/หรือ ต่อต้านในสิ่งที่ทีมได้ประเมินมา เรามีหน้าที่เพียงแค่เลือกงานที่จะต้องทำก่อน และ/หรือ เลื่อนออกไปก่อน เพราะเราควรให้ความสำคัญกับเรื่องขอบเขตของงาน มากกว่าการปรับปรุงการประเมิน ที่เราเองก็ไม่รู้เรื่อง และสุดท้ายแล้วก็ไม่สามารถบอกความจริงอะไรกับเรา
ลุง Ron เตือนไว้ว่า ในขณะที่วางแผน อย่าไปใส่ความท้าทายให้เป้าหมาย (stretch goals) เช่น “ลองใส่เพิ่มไปอีก 1 ฟีเจอร์ซิ๊” การทำแบบนี้มันจะทำให้ทีมพยายามทำมันให้เสร็จ โดยที่พวกเขาต้องเร่งทำงานอื่นให้เร็วขึ้น ทดสอบน้อยลง โค้ดลดคุณภาพลง เพียงเพราะต้องหาเวลาเพื่อรับความท้าทายขึ้นอีกแค่ 1 ฟีเจอร์ และท้ายที่สุดเราอาจจะได้งานช้าลงเพราะทีมต้องกลับมาปรับปรุงโค้ดหรือแก้ Defect ที่เกิดขึ้นในภายหลัง
“ความกดดันเป็นสิ่งที่อันตราย พยายามลีกเลี่ยงมัน”
และเมื่อเราเริ่มย่อยชิ้นงานแต่ละฟีเจอร์เป็น มีประสบการณ์ และต้องไปพบเจองานลักษณะเดิมอีก การประเมินต่างๆก็จะง่ายขึ้น เพราะความรู้สึกเราจะบอกได้เอง ว่าอะไรต้องทำก่อน ทำหลัง ทำนานแค่ไหน จุดนี้จะสามารถลดทอนเวลาในการประเมินลงไปได้อีก
สร้างมันขึ้นมาทีละฟีเจอร์ (Building)
ประโยชน์ของการย่อยงานทำทีละฟีเจอร์ (Feature by Feature) ทีมและองค์กรจะได้เรียนรู้ และเห็นผลของงานได้เร็ว สามารถเปลี่ยนแปลง ปรับปรุง การทำงานและตัวงานได้ตลอดเวลา (หรือเรียกกันว่า False Fast, Learn Fast)
ลักษณะการทำงานแบบนี้ มันเหมือนเราต้องทำซอฟต์แวร์ตัวเล็กๆหลายตัว เพื่อมาโปะกันไปเรื่อยๆจนได้สมบูรณ์ตามซอฟต์แวร์ภาพใหญ่ที่ต้องการ ดังนั้น การทำฟีเจอร์ตัวหนึ่ง จะยังคงต้องมีกระบวนการ Development Cycle ครบด้วย ตั้งแต่การวางแผน วิเคราะห์ ออกแบบ เขียนโค้ด ทดสอบ และเราจะเรียกกระบวนการที่ว่านี้เป็น 1 รอบการทำงาน (Iteration) ดังนั้นงานที่ได้ออกมาในแต่ละรอบจะเป็นงานที่ใช้ฟีเจอร์นั้นได้จริงๆ เอาไปโชว์ ไปขาย ไปใช้ได้ทันที
การทำ Feature by Feature และปล่อยงานให้เห็นบ่อยๆ จะช่วยให้ฝ่าย Business ได้พิจารณาสิ่งที่ตนเองได้เคยคิดเคยวางแผนไว้แต่แรก ว่ามาถูกทางไหม คุ้มค่าที่จะไปต่อไหม ต้องปรับปรุงแผน ลำดับงานใหม่ หรือเพิ่มประสิทธิภาพของทีมอะไรบ้าง เพือให้งานสำเร็จ
ในการทำงานแบบเดิม เราต้องรอจนถึงเฟส Test ถึงจะพบว่ามี Defect อะไรบ้าง ซึ่งมันอาจมีมากหรือน้อยจนทำให้ใช้เวลาเกินที่วางแผนไว้ แต่หากทำเป็นรอบและทุกรอบมีการ Test อยู่แล้ว เมื่องานทั้งหมดใกล้เสร็จ เราก็ไม่ต้องกังวลกับ Defect ก้อนโตในตอนท้าย (ผู้เขียนใช้คำว่า “nearly free of defects” คืองานเกือบจะไม่มีข้อผิดพลาดเกิดขึ้น)
นอกจากสร้างงานไม่ให้เกิดข้อผิดพลาดในแต่ละรอบการทำงานแล้ว สิ่งที่ต้องตระหนักอีกอย่าง คือ การออกแบบซอฟต์แวร์, ถ้าออกแบบไว้แต่ต้น เผื่อเยอะ มีความซับซ้อนโดยไม่จำเป็น ยากต่อการเรียนรู้ การทำงานในรอบต่อๆไปก็อาจจะยากขึ้นเรื่อยๆ
แนวคิดแบบแนวตั้ง และสร้างเท่าที่จำเป็น (Build Feature and Foundation in Parallel)
ฟีเจอร์ของซอฟต์แวร์ต้องมีโครงสร้าง (Foundation) ของซอฟต์แวร์ที่ดี, แต่สิ่งที่เราต้องคิดคือ จะทำอย่างไรให้ทั้งสองอย่างสมดุลและเสร็จไปพร้อมกันได้ ในเวลาที่จำกัด และเท่าที่จำเป็น
หากเรามัวแต่ไปทำโครงสร้างพื้นฐานของซอฟต์แวร์ เช่น ออกแบบ Framework สุดหรู, สร้าง Library ที่พร้อมใช้ทุกอย่าง แต่แล้วฟีเจอร์ต่างๆ ที่เป็นคุณค่าของซอฟต์แวร์ ไม่เสร็จ หรือเสร็จไม่ครบ แบบนี้ซอฟต์แวร์ของเราจะไปมีค่าอะไร เพราะมันใช้งานไม่ได้ตามที่ลูกค้าต้องการ
ดังนั้น การทำงานแบบ Iteration เพื่อส่งมอบงานให้ลูกค้า เราจะทำงานเป็นแนวตั้ง หมายความว่า เราจะสร้างสิ่งพื้นฐานที่จำเป็นสำหรับฟีเจอร์นั้น จากนั้นเราจะทำฟีเจอร์ของรอบนั้นให้ใช้งานได้ เพื่อส่งมอบ เท่านั้นพอ, เราจะไม่ทำงานแบบเดิม ที่อุทิศรอบการทำงานเพื่อทำโครงสร้างพื้นฐานให้สมบูรณ์ จากนั้นรอบงานถัดไปค่อยทำฟีเจอร์ทีละตัวไปใส่ แบบนี้ลูกค้าจะไม่ได้เห็นงานในรอบแรกๆ และเราเองก็มีโอกาสส่งมอบของให้ลูกค้าได้ไม่ครบด้วย เพราะมัวแต่ทำโครงสร้างสุดหรูในช่วงแรก(และก็อาจไม่มีโอกาสได้ใช้มัน)
พัฒนาฟีเจอร์ออกมาเพื่อให้ใช้งานได้ก่อน โดยทำขึ้นมาอย่างง่ายๆ หรือที่เรียกว่า MVP – “Minimum Viable Product” จากนั้นค่อยกลับมาเก็บรายละเอียดให้ดีอีกครั้ง
ซึ่งสิ่งเหล่านี้ ทีมพัฒนาต้องมีความรู้เป็นอย่างดีสำหรับการวางแผนทำงานเป็นแนวตั้ง เพราะต้องออกแบบโครงสร้าง (Foundation) ที่เรียบง่ายแต่ใช้งานได้จริงในตอนต้น และโครงสร้างนั้นเองก็ต้องพร้อมรองรับการขยายได้ในรอบถัดๆไป ดังนั้นหัวหน้าทีม หรือฝ่ายบริหารจะต้องจัดหาและช่วยเหลือในสิ่งที่เติมความรู้เหล่านี้ให้กับทีมได้
การออกแบบที่ดี และไร้ข้อผิดพลาด (Bug-Free and Well Designed)
ซอฟต์แวร์ของเราจะถูกทำเพิ่มเข้าไปเรื่อยๆตามรอบของงาน ซึ่งทุกรอบที่ส่งมอบมา งานใหม่ต้องใช้ได้ และงานเก่าก็ยังต้องใช้ได้อยู่เช่นเดิม
การมีข้อผิดพลาด (Defect) เกิดขึ้นตอนพัฒนา ซอฟต์แวร์มันทำให้เราประเมินได้ไม่ชัดเจนว่า ตอนนี้งานที่เหลือมีอะไร เพราะอาจสับสนว่าอะไรคืองานที่ต้องทำ อะไรคือ Defect ที่ต้องแก้ แล้วแบบนี้จะเรียกมันว่าเสร็จเพื่อส่งมอบได้ไหมเนี่ย เพราะข้อผิดพลาด (Defect) ทำให้เราประเมินเวลาไม่ได้ ไม่สามารถรู้ได้เลยว่าจะต้องใช้เวลาเท่าไรเพื่อหามัน ต้องแก้มัน และถ้าเราปล่อยไว้ มันก็จะกวนใจเราเรื่อยๆในรอบการทำงานถัดๆไป
ดังนั้น สิ่งที่ควรทำในการทำซอฟต์แวร์ คือ ต้องป้องกัน (Prevent) ไม่ให้เกิดข้อผิดพลาด มากกว่าการมาตามแก้ไขข้อผิดพลาดในภายหลัง (Fix)
สิ่งที่เราจะเริ่มทำคือ ทดสอบระบบด้วยการทดสอบระดับ Business ว่าสามารถใช้งานได้ตามที่ต้องการไหม หรือที่เราเรียกว่า Acceptance Test-Driven Development (ATDD) และค่อยต่อด้วยทดสอบระดับ Technical ด้วยวิธีการต่างๆ
ซอฟต์แวร์ของเราจะใหญ่ขึ้นเรื่อยๆ ตามจำนวนฟีเจอร์ที่เพิ่มและโค้ดที่เขียน ดังนั้นจะใช้เวลาและยากมากที่ต้องทดสอบทั้งหมดทุกครั้งหลังจบรอบการทำงาน (System Test, Integration Test) ดังนั้น ทีมพัฒนาควรทำ Automate Tests ให้ครอบคลุมทั้งระบบงาน หรือออกแบบทำไว้ตั้งแต่ก่อนพัฒนาระบบ หรือที่เรียกกันว่า Test-Driven Development (TDD)
ย้อนกลับไปบทที่แล้ว เราจะส่งมอบงาน “ที่ใช้งานได้” ให้ลูกค้าเห็นได้บ่อยๆ เราจะต้องออกแบบระบบให้ดีตั้งแต่แรก และเท่าที่จำเป็น ไม่เวิ่นเว้อเกินไป
และการที่พยายามออกแบบระบบสุดหรูเว่อวังไว้แต่แรก (ซึ่งอาจจะดีหรือไม่ดีก็ตาม) ระบบยิ่งใหญ่ก็ยิ่งซับซ้อนขึ้น ดังนั้นรอบการทำงานถัดไป ถ้าต้องปรับปรุง แก้ไข เพื่อให้ดีขึ้น ก็ต้องใช้ทีมที่มีความรู้ความสามารถมากขึ้นเช่นกัน
ดังนั้น ในทุกรอบการทำงาน เพื่อให้ระบบเราสอดคล้องกับฟีเจอร์ใหม่ในรอบนั้นๆ ควรให้ความสำคัญถึงการทำ Refactoring Code ด้วย เพื่อไม่ให้เกิดความยุ่งยากซับซ้อนในรอบทำงานต่อๆไป
Test และ Refactor ทั้งสองอย่างนี้เป็นเรื่องสำคัญของการพัฒนาระบบแบบ Feature-by-Feature เพราะจะทำให้งานเรามีคุณภาพได้ตลอดเวลา เพื่อพร้อมส่งมอบงานให้ลูกค้าได้เสมอ
ส่งท้าย
จากที่สรุปมาให้อ่านทั้งหมด ผมสังเกตได้ว่า ลุง Ron Jeffrie มีคำที่พยายามย้ำอยู่เรื่อยๆไม่กี่คำ คือ คุณค่า (Value), ทีม (Team), การพัฒนาทักษะ (Learn), การทำงานเป็นรอบ (Iteration) และ การทำทีละฟีเจอร์ (Feature-by-Feature), การส่งมอบ (Shipable)
ดังนั้น หัวใจหลักของการพัฒนาแบบ “The Nature Way” ที่ลุง Ron เอามาเสนอ เราต้องให้ความใส่ใจกับคำ 6 คำนี้แหละครับ ส่วนใครอ่านไปแล้วจะคิดต่อหรือหาความรู้เพิ่มเติม จากนั้นเอาไป Adapt & Implement กันอย่างไร ก็คงขึ้นอยู่กับแต่ละวัฒนธรรมองค์กร
ขอให้สนุกครับ
—
ที่มาของเนื้อหาและรูปภาพ จากหนังสือ The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece