ไม่ค่อยได้เขียนเรื่อง Software Development สักเท่าไหร่ (ทั้งที่จริงๆ เป็นเรื่องที่เดินสายพูด เดินสายบรรยาย สอน และถนัดที่สุดแล้วในบรรดาเรื่องทั้งหมด) แต่เมื่อคืนน้องในทีมพัฒนา Sticgo (http://www.sticgo.com) Startup ที่ผมเป็น Mentor อยู่ในโครงการ True Incube (http://incube.truecorp.co.th) ดันเอา Chart อะไรบางอย่างขึ้นใน Facebook แล้วพี่ Roofimon (www.roofimon.com) เข้ามาบอกเลย “บาป” แล้วก็งงว่ามันคือ Chart อะไร ผมก็เลยสัญญากับพี่รูฟไปว่าจะเขียนเรื่อง Chart ตัวนี้ใน Blog ด้วยความเป็นลูกผู้ชาย ก็เลยต้องรักษาสัญญาซะหน่อย
เป็นที่รู้และเข้าใจกันดี ว่าการพัฒนาซอฟต์แวร์ตัวหนึ่งมันไม่ใช่เรื่องเล็กๆ มันมีเครื่องไม้เครื่องมือมีกระบวนการมี Mindset อะไรหลายต่อหลายอย่างเอาไว้ให้เราใช้ในการช่วยพัฒนาซอฟต์แวร์
Mindset โบราณที่ลอก Metaphor มาจากการก่อสร้าง หรือที่เรียกว่ากระบวนการแบบ Waterfall ก็มีเครื่องมือหลากหลาย และตัวหนึ่งที่เราต้องเจอกันมาตลอดก็คือ “Gantt Chart” ซึ่งไอ้เจ้า Gantt Chart ตัวนี้เป็นเครื่องมือนำ “แผนการทำงาน” มาวางต่อเนื่องบน Timeline เพื่อดูว่าเราวางแผนการทำงานอย่างไร อะไรต้องทำก่อนทำหลังอะไร แล้วเวลาที่จะใช้คือประมาณเท่าไหร่ ฯลฯ
สิ่งที่ Gantt Chart ตอบได้อย่างชัดเจนก็คือ การให้เห็นแผนการทำงาน ระยะเวลาของงาน และปริมาณงานที่เสร็จไปแล้ว ซึ่งนี่คือสิ่งที่จำเป็นมากในการทำงานอะไรก็ตามในโลกความเป็นจริงที่เราต้องอยู่กับชาวบ้าน ทำงานกับคนอื่น (ลูกค้า เจ้านาย ฯลฯ) เพราะว่ามันจะมีความถามเราตลอดเวลากับคำถามต่อไปนี้ “แล้วจากนี้จะทำอะไร ต่อจากนั้นทำอะไร ใช้เวลาประมาณเท่าไหร่ เหลืองานอีกเยอะมั้ย เสร็จไปแล้วเท่าไหร่” ฯลฯ (ซึ่งพวกนี้จะเกี่ยวข้องกับค่าจ้างเราด้วยนะ)
แน่นอนว่า ในโลกบางใบ คนหลายคนต้องการที่จะเห็นรายละเอียดทั้งหมดเหล่านี้ Up-Front ซึ่งหมายความว่าเห็นรายละเอียดของแผนการดำเนินการ ระยะเวลา และงบประมาณทั้งหมดก่อนที่จะเริ่มดำเนินการ ซึ่งในขณะที่แนวคิดแบบนี้ใช้ได้กับงานบางประเภท มันกลับไม่เหมาะเอาซะเลยกับการพัฒนาซอฟต์แวร์ โดยเฉพาะอย่างยิ่งการพัฒนาซอฟต์แวร์ที่ “เป็นของใหม่ ไม่มีใครทำมาก่อน” ซึ่งมันมี Unknown เยอะ (ถ้าเป็นโปรแกรมประเภท Data Entry ธรรมดาๆ นี่อีกเรื่อง อันนี้พอจะประมาณได้จากประสบการณ์ แต่ต้องมีประสบการณ์เยอะพอที่จะทำได้นะ — บอกตรงๆ ว่าโดยทั่วไป ต่อให้เป็นผมหรือเก่งกว่าผมก็มองเห็นทุกอย่าง Up-Front ขนาดนั้นไม่ได้หรอก)
ในแนวทางพัฒนาซอฟต์แวร์สมัยใหม่ ก็เลยไม่ค่อยที่จะสนใจ Gantt Chart กันสักเท่าไหร่ ยิ่งพวกที่ทำตามปรัชญา Agile ด้วยแล้วยิ่งไปกันใหญ่ (ย้ำตรงนี้: “Agile” มันเป็น “ปรัชญา” ไม่ใช่ “วิธีการ” … เพียงแต่มันมีคนสร้างวิธีการต่างๆ มากมายขึ้นมาจากแก่นปรัชญานี้ ไว้วันหลังผมจะเขียนเรื่องนี้ละเอียดๆ อีกที ตอนนี้แปะโป้งไว้ก่อน)
แต่ว่ามันต้องมีเครื่องมืออะไรสักอย่างสิ …. ไม่งั้นเค้าจะใช้อะไรกัน
มาขนอิฐกันดีกว่า!
จริงๆ แล้วมันก็มีเครื่องมืออยู่หลายตัว ซึ่งเป็นเครื่องมือเชิงกระบวนการ ที่เอาไว้จัดการกระบวนการทำงานภายในของทีมให้เห็น Dynamic ของงานและการเคลื่อนไหวของ Task ต่างๆ ซึ่งผมจะไม่พูดถึงตรงนี้ ตรงนี้ผมจะพูดถึงแค่เครื่องมือง่ายๆ ที่เรียกว่า “Burn Chart” ครับ
หลักการทำงานของ Burn Chart นั้นๆ ง่ายๆ ไม่มีอะไรมากมาย และมันเกี่ยวข้องกับคำว่า “Work Done” และ “Work Left” (Work Not Done) โดยตรง ทั้งนี้ตอนนี้ให้คิดก่อนว่า “งานหนึ่งงาน คือ อิฐหนึ่งก้อน” ที่อิฐแต่ละก้อนมีขนาดต่างๆ กัน แล้วเราจะนำหินพวกนี้มาวางไว้ หรือหยิบออกไปจากกอง ขึ้นอยู่กับว่า “กองอิฐ” ที่ว่านี้คืออะไร
ก่อนอื่นมันเริ่มจากตอนที่เราคิดถึงงานว่าจะต้องทำอะไรบ้าง มีฟีเจอร์อะไรบ้าง มีระบบอะไรบ้าง มีหน้าจอกี่หน้าจอ ฯลฯ ให้เราคิดมันออกมาเท่าที่เราคิดออก (ไม่ต้องทั้งหมด และไม่ต้องห่วงว่าจะต้องคิดทั้งหมดหรือคิดละเอียดมากมาย คิดเท่าที่คิดออกก็พอ)
จากนั้นใช้ความรู้สึก ใช้ประสบการณ์ ใช้เพื่อนร่วมงาน ใช้ทีม ใช้อะไรก็ได้ ในการ “กะขนาด” ของงาน ซึ่งก็คือขนาดของก้อนอิฐนั่นแหละ โดยไม่ต้องกะละเอียดมากมาย แค่ “เล็ก กลาง ใหญ่” ก็พอแล้ว เช่น ถ้าเรากำลังทำโปรแกรมบนมือถือแนะนำที่พัก เราอาจจะบอกว่า “ผู้ใช้ค้นหารายชื่อที่พักจากจังหวัดได้” เป็นงานขนาดเล็ก “ผู้ใช้จะเห็นรายชื่อที่พักที่อยู่ห่างจากตำแหน่งที่เขาอยู่ไม่เกิน 5 กิโลเมตร” เป็นงานขนาดกลาง เป็นต้น ส่วนถ้าต้องการจะแตกงานให้ละเอียดว่าจะต้องทำอะไรก่อนหรือเปล่า เช่น “งั้นก็ต้องมี Server Application ที่เก็บข้อมูลก่อน” เป็นงานขนาดเล็ก “มีฐานข้อมูลง่ายๆ แค่เก็บที่พักก็พอแล้ว” เป็นงานขนาดเล็ก “เปิด API สำหรับให้โปรแกรมบนมือถือดึงข้อมูลดได้” เป็นงานขนาดกลาง ฯลฯ การแตกงานนี้ประสบการณ์ช่วยได้ว่าจะต้องทำแค่ไหน
สำหรับผมแล้ว ผมทำมันในโปรแกรม Spreadsheet ง่ายๆ นี่แหละครับ ใช้ขนาด 1, 3, 5 Cell สำหรับงานเล็ก กลาง ใหญ่ ตามลำดับ เพราะในความรู้สึกผมแล้ว งานเล็กๆ 3 งาน มันจะพอๆ กับงานกลางๆ 1 งาน และงานกลางๆ 2 งาน มันใหญ่กว่างานใหญ่ 1 งานนิดหน่อย …. ถ้างานใหญ่มันใหญ่มากกว่านั้น แปลว่าเรายังแตกงานไม่มากพอ อะไรประมาณนั้น
Burn Down Chart
Chart ตัวแรกก็คือ Burn Down Chart ซึ่งเป็น Burn Chart ที่คิดว่าน่าจะแพร่หลายที่สุดล่ะ หลักการของ Burn Down Chart ก็คือ “งานที่เหลืออยู่” นั่นคือ ก่อนอื่นเลยเราจะเอางานทั้งหมดมาวางซ้อนกันเป็นแท่งตรง จากนั้นเมื่อตัวไหนเสร็จก็หยิบมันออกไปเรื่อยๆ ถ้ามีงานใหม่เข้ามา เช่นคิดฟีเจอร์ใหม่ออก หรือเจอบั๊กต้องแก้ ก็ไม่มีปัญหาแต่อย่างใด ก็แค่ประมาณขนาดของมัน แล้วก็วางซ้อนมันลงไป ดังนั้นสิ่งที่จะเห็นตลอดเวลาก็คือ “งานที่เหลืออยู่” นั่นเอง ซึ่งสำหรับ Burn Down Chart นี้ งานจะเสร็จเมื่อทุกอย่างกลายเป็นความว่างเปล่า
จากตัวอย่างในรูป จะเห็นว่าขนาดของแท่งงานจะลดลงไปเรื่อยๆ ตามงานที่เสร็จไปแล้วจริง เช่นถ้างานชิ้นเล็กๆ เสร็จ ก็จะลดลงนิดหน่อย ถ้างานไม่คืบหน้าเพราะอะไรก็แล้วแต่ ขนาดของแท่งงานก็จะเท่าเดิม ถ้าวันหนึ่งเกิดบ้าพลังทำงานได้เยอะ งานก็จะหายไปเยอะ และเมื่อเอางานให้ลูกค้า ให้ Owner หรือให้คนอื่นดู แล้วเจอ Feature Request หรือแก้ Bug หรือ ฯลฯ ที่เรียกว่า “งานงอก” งานก็จะงอกงามขึ้นมาใหม่ ถ้าเจอ Framework ตัวช่วยเจ๋งๆ งานเสร็จเร็ว ก็จะหายเยอะหน่อย เป็นต้น
อันนี้ผมจะยังไม่พูดถึงเรื่อง Team Velocity อะไรพวกนี้นะ ถึงมันจะเกี่ยวๆ กันก็เถอะ เพราะเดี๋ยวจะได้นอกเรื่องยาว อันนี้เอาแค่นี้ก่อน
Burn Up Chart
เมื่อมันมี Burn Down มันก็ต้องมี Burn Up ซึ่งอันนี้คิดตรงกันข้าม ก็คือเริ่มต้นจากความว่างเปล่า ให้หยิบงานที่เสร็จแล้วมากองเพิ่มขึ้นไปเรื่อยๆ
ถ้าถามว่าผมชอบตัวไหนมากกว่ากันระหว่างสองตัวนี้ ผมจะชอบ Burn Down มากกว่า (และหลายคนก็คงรู้สึกคล้ายๆ กับผม) เพราะเราจะเห็น Goal Line หรือคำว่า “Done” อย่างชัดเจนมาก ว่าตอนนี้เรายังห่างจากมันคือไหน
แต่มันก็ยังมีอะไรบางอย่าง ที่ Burn Chart ทั้งสองตัวตอบเราไม่ได้ … ลองย้อนกลับไปที่สิ่งที่ “ลูกค้า” เรา (หรือคนที่คุ้นเคยกับโลกที่ใช้ Metaphor จากงานก่อสร้าง หรืองานที่คุมทุกอย่างได้เป๊ะ) ต้องการทราบสิครับ:
“แล้วจากนี้จะทำอะไร ต่อจากนั้นทำอะไร ใช้เวลาประมาณเท่าไหร่ เหลืองานอีกเยอะมั้ย เสร็จไปแล้วเท่าไหร่”
จะเห็นว่าทั้งสองตัวนี้ตอบคำถามเหล่านี้ไม่ได้ ในขณะที่ Gantt Chart ตอบได้ไม่ยาก (เพราะโดยธรรมชาติ Gantt Chart มันอยู่บน Timeline และมี Progress ให้เห็นชัดเจน)
เราต้องทำอะไรบางอย่างกับสิ่งนี้ครับ… และโล่งอก ที่มันไม่ยากเท่าไหร่
Mixed Burn – The Project Completion Chart
เพื่อตอบคำถามเหล่านั้น (สนอง Need ตัวเองและลูกค้า) ผมก็เลยสร้าง Chart ใหม่ซะเลย โดยสิ่งที่ผมทำก็คือ เอา Burn Down, Burn Up มารวมกันเป็น Chart เดียว (Mixed Burn) ทั้งนี้ผมไม่คิดว่าผมเป็นคนแรกของโลกที่ทำมันล่ะนะครับ ก็คงจะมีอีกหลายคนที่ทำแบบนี้ ผมก็ไม่ได้ตั้งชื่ออะไรให้มันเท่ๆ นะ ก็เรียกมัน Mixed Burn เนี่ยแหละ แต่จริงๆ แล้วมันคือ Chart ที่แสดง Project Completion และตอบคำถามเหล่านั้นได้โดยไม่เสียแก่นของ Burn Chart
หน้าตามันเป็นแบบนี้ครับ:
ก่อนอื่นเลย ตอนนี้ขนาดของแท่งใน Chart เป็นขนาดของ “งานทั้งหมด” เท่าที่เราประเมินได้ในขณะนั้นๆ (เช่นวันแรก อาจจะไม่เห็นงานเยอะเท่าไหร่ เลยประเมินมาแท่งเล็ก หรือยังไม่ได้ประเมินอีกหลายระบบ หรืองานยังไม่งอก ฯลฯ ก็เป็นได้ทั้งนั้น)
จากนั้น เมื่องานเสร็จ เราใช้หลักการของทั้งสอง Burn ใน Chart เดียว ก็คือ “หยิบจากงานไม่เสร็จ เป็นไปงานเสร็จ” พูดง่ายๆ ก็คือเปลี่ยนสีน่ะแหละ ทีนี้ถ้าเราดูสีส้ม เราจะได้ Burn Down Chart ที่กลับหัว (เพราะแท่งมันเล็กลงเรื่อยๆ เข้าหาความว่างเปล่า) แต่ถ้าเราดูสีน้ำเงิน เราจะได้ Burn Up Chart (งานที่เสร็จเพิ่มขึ้นเรื่อยๆ)
ถ้าเราคิดงานได้เพิ่ม (งานงอก) เราก็จะเพิ่มมันลงไปในแท่ง เป็นงานที่ยังไม่เสร็จ ดังนั้นแท่งนี้ก็จะโตขึ้นเรื่อยๆ ตามปริมาณงานจริง
ถ้าเราไม่ชอบที่ดูแล้วได้อารมณ์ Burn Up มากกว่า Burn Down อยากได้สลับกัน ก็ไม่ใช่ปัญหาอะไร แค่เอางานที่เสร็จแล้วไว้ด้านล่าง แล้วกองงานที่ยังไม่เสร็จไว้ด้านบน ก็ยังเป็น Chart เดิมน่ะแหละ แต่ดูแล้วจะเห็นเป็น Burn Down มากกว่า Burn Up
Chart นี้จะช่วยตอบคำถามพื้นฐานที่ผมยกมาเมื่อกี้ได้ง่ายมาก เพราะเราจะเห็นปริมาณงานที่เสร็จแล้วต่องานทั้งหมดตลอดเวลา การที่จะบอกว่างานเสร็จไปแล้วกี่เปอร์เซ็นต์สามารถทำได้ไม่ยาก
ที่เจ๋งคือ สมมติว่าเราบอกว่างานเสร็จไปแล้ว 80% แต่เมื่อนำไปให้ลูกค้าหรือคนที่อยากได้งาน (เช่น CEO) ดู แล้วได้งานงอกกลับมา คือ “ต้องเพิ่มระบบนี้ ต้องเพิ่มหน้าจอนั้น ต้องเอาหน้าจอนี้ออกไปใส่ในหน้าจอนั้นแทน ฯลฯ” หรือแม้กระทั่งงานเล็กๆ น้อยๆ (ที่วุ่นวาย) แบบ “เปลี่ยนสีตรงนี้หน่อย มันเข้มไป” อะไรแบบนี้ ปริมาณงานที่ยังไม่เสร็จ ยังไม่ทำ มันก็งอกขึ้นมา ดังนั้นเราก็จะบอกได้ทันทีเลยว่า “งั้นเมื่อกี้ที่บอกว่าเสร็จไปแล้ว 80% นี่ตอนนี้เหลือแค่ 50% แล้วนะครับ” อะไรแบบนี้ (เพราะแท่งสีส้มมันถมทับเพิ่มขึ้นมา)
พูดง่ายๆ ก็คือ แท่งแต่ละแท่ง จะทำหน้าที่เป็น Progress Bar ของงานในขณะนั้นๆ (ลองจับตะแคงดูสิ จะเห็นชัด) ซึ่งพอเป็นแบบนี้หลายคนจะชอบล่ะ เพราะมันบอกสิ่งที่เขาอยากได้ (เช่นนักศึกษามหาวิทยาลัย จะสอบความคืบหน้าของโปรเจ็คได้จะต้องเสร็จไม่ต่ำกว่า 60% หรือการส่งมอบงานที่ชอบวัดเป็นเปอร์เซ็นต์ ซึ่งมันก็มีอยู่เยอะพอควร อะไรแบบนี้เป็นต้น)
แบบนี้เราจะมีเครื่องมือในการคุยงานกับลูกค้า กับหัวหน้า กับอะไรง่ายๆ ในโลกที่เขาคุ้นเคยและรู้จักครับ ประเมินด้วยกันก็ยังได้ว่างานไหนงานใหญ่งานเล็ก ขนาดของอิฐอาจจะใช้อะไรเป็นตัววัดก็ได้ เช่น Impact, Priority อะไรก็แล้วแต่ แล้วตกลงกันง่ายๆ เลยก็ได้ว่า ขนาดอิฐมันก้อนละเท่าไหร่ (ฮ่าๆ) ถ้าจะเพิ่มงานเข้ามา แน่ใจนะว่าจะเพิ่ม เขาจะเห็นง่ายๆ เลยว่ามันกระทบกับโปรเจ็คแค่ไหนบ้าง
แถม: การนำไปประยุกต์กับ Agile Methodology อื่นๆ
เครื่องมือทุกอย่างมันทำงานด้วยกันได้ครับ ถ้าใครใช้พวก Scrum หรือ Kanban อะไรพวกนี้ก็ไม่ยาก ก็แค่เอางานทั้งหมดที่มีตอนนั้นมาแยกเป็น “Done” และ “Everything Else” (ไม่สนว่าจะเป็นอะไร) แล้วเอา Stack Up กัน ก็ได้แล้ว
Scrum Board ที่ Code App
(งานนี้จะกองไว้ที่ Done เกือบหมดแล้ว โปรเจ็คใกล้เสร็จแล้ว ฮ่าๆ)
และเครื่องมือพวกนี้มันก็คือเครื่องมือครับ ปรับเปลี่ยนได้ตามสะดวก อย่ายึดติดกับมัน … ผมยังเอา Chart ชาวบ้านเค้ามาปรับเป็นแบบที่เหมาะกับสิ่งทีผมต้องเจอเลย อย่ายึดติดกับอะไรทั้งสิ้น
ขอหน่อยละกัน…. ผมชอบเทียบเรื่องพวกนี้กับศาสนาพุทธครับ มันมีคนที่ “ปฏิบัติตามปรัชญาศาสนาในการใช้ชีวิต” และมันมีคนที่ “หากินกับศาสนา” … ปรัชญาของสอนให้ไม่ยึดติด ละตัวตน ฯลฯ อะไรก็แล้วแต่ แต่ “คนที่หากินกับศาสนา จะสอนให้คนยึดติดศาสนา” ไม่ว่าจะเป็นการที่จะต้องทำโน่นทำนี่ทำอะไรมากมาย ต้องซื้อวัตถุมงคล ต้องทำบุญด้วยเงินเท่าไหร่ต่อเท่าไหร่ เอาความโลภ (ในบุญ ในชาติภพหน้า อะไรก็แล้วแต่) มาเป็นตัวล่อด้วยซ้ำไป
ก็คงไม่ต่างกันหรอกครับ กับเรื่องการยึดติดวิธีการต่างๆ ของการพัฒนาซอฟต์แวร์ ที่มันก็มีคนเข้าถึงแก่น ปฏิบัติ และสอนให้คนเข้าถึงแก่นเหล่านี้ด้วยกัน แล้วมันก็มีคนที่หากินกับเปลือก ให้คนยึดติดที่เปลือก … ก็ต้องเลือกมองหาสำนักที่เข้าถึงจริงจังขายการปฏิบัติให้เป็นผลจริงจัง มากกว่ามอมเมาวิชาล่ะครับ
ส่งท้าย
สารภาพว่า จริงๆ ผมเขียนหนังสือเรื่องพวกนี้อยู่ล่ะครับ แต่ยังเขียนไม่เสร็จสักที ก็เลยคิดว่าจะเริ่มเอาเรื่องที่เขียนๆ ไว้บางส่วนมาลงใน Blog ไปเรื่อยๆ แก้ขัดไปก่อน (ฮ่าๆ) … เพราะว่า “Project Completion Chart ของหนังสือเล่มนี้มันงอกไปเรื่อยๆ” และ “ผมเปลี่ยนสีส้มเป็นสีน้ำเงินไม่ทัน คิดอะไรออกก็ใส่มันลง Chart ไปก่อน” (ฮ่าๆ — เขียนหนังสือยังใช้อันนี้) แล้วจะแจ้งอีกทีถ้ามีความคืบหน้าอะไรนะครับ
You must be logged in to post a comment.