ผ่านไปแล้วอีกหนึ่งกิจกรรมของกลุ่มเราครับ … C.M.3 — User Story for Agile Development ที่เราใช้เวลาส่วนใหญ่ไปในการทำ Workshop ฮ่าๆ ส่วนตัวแล้วการพบปะพูดคุยครั้งนี้ถือว่าประสบความสำเร็จนะครับ

1. ได้รู้จักเพื่อนใหม่เพิ่มขึ้น 4 คน … ที่เหลืออีก 7 คนก็ขาประจำ
2. ได้มีโอกาสได้ถ่ายทอดแนวคิดการทำงานแบบ Agile (อย่างย่อ) ภายในเวลา 15 นาทีให้เพื่อนๆได้ฟังกัน
3. ได้มีโอกาสลงในรายละเอียดของคำว่า User Story … และกระบวนการที่จะได้มาซึ่ง User Story ที่ดี … Workshop แรกของเราได้ผลดีเกินคาด ทั้งสองกลุ่มเขียน User Story ออกมาได้ชัดเจนและถูกต้องครับ ปรบมือให้ตัวเองดังๆ 10 แปะ
4. ได้มีโอกาสนำเสนอแนวทางการ Estimate แบบใหม่โดยใช้ Story Point … Workshop ที่สอง อันนี้ก็มันส์มาก ได้เล่น Planning Poker มีการถกเถียงกันเพื่อหา Point ที่เหมาะสมของแต่ละ User Story … ผลที่ได้มาก็ยอดเยี่ยมเลย
5. ได้มีโอกาสลองทำ Project Plan แบบ Agile และมีตัวอย่าง Burndown Chart รวมถึงหลักการอ่านและตีความหมายของกราฟให้ดูกันด้วย
6. ได้มีโอกาสถาม-ตอบและแลกเปลี่ยนความคิดเห็นกันระหว่างพวกเรา
7. สุดท้าย ได้กินกาแฟอร่อย แถมราคาย่อมเยาอีกต่างหาก … ขอบคุณเจ้าของสถานที่มากๆครับ

ตอนแรกเลยกังวลใจอยู่ว่าเนื้อหาและกิจกรรมครั้งนี้จะหนักไปสำหรับเวลาที่เรามีแค่ 3 ชั่วโมง ยิ่งถึงตอนที่เราคุยกันเรื่อง User Story คืออะไรผมยิ่งกังวลว่า … ผมจะพูดจาไม่รู้เรื่องทำให้เพื่อนๆงงกันเข้าไปใหญ่ แต่สุดท้ายแล้วหลังจากผ่าน Workshop แรกมา ความกังวลนั้นก็ลดน้อยลงครับ เพราะว่าเพื่อนๆเก่งมาก เขียน User Story ได้ถูกต้องเลยหละ (ปลื้ม)

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

ของฝากจากพวกเรา

อืม ต้องบอกว่ากิจกรรมรอบนี้ไม่มีอะไรเป็น Output ออกมาเลย ไม่มีอัดวิดีโอ ไม่มีข้อมูลที่ได้จากการทำ Workshop … ขนาดรูปถ่ายยังไม่มีเลย ฮ่าๆ มีอย่างเดียวที่ผมพอจะแบ่งปันให้ได้สำหรับเพื่อนๆที่พลาดกิจกรรมนี้ก็คงจะเป็นเอกสารที่พวกเราใช้ในการทำ Workshop นี่แหละครับ Download ได้เลยครับ … ถ้ามีอะไรสงสัยก็ถามมาหลังไมค์ก็ได้นะ

กิจกรรมหน้า

ยังคิดไม่ออกว่าจะคุยกันเรื่องอะไรดี ใครสนใจเรื่องไหนบอกได้นะ จะพยายามจัดให้ … ที่แน่ๆก็จะเป็นประมาณสัปดาห์ที่สามของเดือนกันยายน สถานที่ก็เหมือนเดิมครับ Art Element: School of Art

ลงทะเบียนครบ 15 คนเรียบร้อย … ขอบคุณมากที่ให้ความสนใจกันนะครับ รูปแบบการจัดกิจกรรมครั้งนี้ก็จะแตกต่างไปจากเดิมนิดหน่อยตรงนี้จะมี Workshop ให้ทำกันด้วย ลองดูรายละเอียดเลยครับ

รูปแบบกิจกรรม

ช่วงแรกผมจะเล่าให้ฟังอีกรอบว่า Agile Development คืออะไรเพื่อเป็นการเกริ่นนำถึงสิ่งที่เรากำลังจะทำ Workshop กันครับ หลังจากนั้นก็จะเริ่มโฟกัสที่เรื่องของ User Story กันเลย จบแล้วก็จะแบ่งเป็นสองกลุ่มเพื่อเริ่ม Workshop ที่ 1 โดยให้ลองสร้าง User Story ของเราเองครับ ผมจะกำหนด Case Study ให้ เสร็จแล้วก็จะขอตัวแทนกลุ่มออกมานำเสนอผลงานนิดนึงนะ

ต่อไปก็จะเป็นเรื่องของ Story Point ซึ่งเป็นการทำ Estimation ในรูปแบบ Agile Development ผมจะเล่าให้ฟังถึงหลักการและกระบวนการตรงนี้ก่อนที่เพื่อนๆจะได้ลองทำ Workshop ที่ 2 ซึ่งก็คือ Planning Poker เพื่อหา Point ของแต่ละ Story ที่เขียนมากันครับ … เสร็จแล้วก็ขอตัวแทนนำเสนอผลงานเหมือนเดิม

สุดท้ายเราจะมาลองทำ Iteration Planning ร่วมกันทั้งสองกลุ่มครับ ผมจะมีตัวอย่าง Project Plan แบบ Agile Development มาให้ลองดูลองเล่นกันฮะ … แล้วก็จบกิจกรรม

ข้อมูลเพิ่มเติม

สำหรับเพื่อนๆที่ยังไม่คุ้นเคยกับ Agile Development ผมแนะนำว่าถ้ามีเวลาก็ลองอ่านบทความข้างล่างดูครับ

Agile Manifesto: การ์ตูนเรื่องนี้ชี้ให้เห็นถึงปัญหาที่พวกเราเจอกันอยู่ประจำใน Software Development Project และเป็นแรงบันดาลใจของคำประกาศ 4 ข้อซึ่งเป็นพื้นฐานของ Agile Development

Waterfall, Iterative, or Agile: เป็นบทความที่เปรียบเทียบความเหมือนความต่างระหว่าง Software Development Life Cycle ที่ได้รับความนิยม 3 ประเภทครับ อ่านแล้วเพื่อนๆจะได้ข้อมูลมากขึ้นว่า Agile Development คืออะไร เหมาะกับงานแบบไหน

Extreme Programming (XP): บทความนี้จะเล่าให้ฟังว่าการทำงานด้วย Extreme Programming (XP) นั้นเป็นอย่างไร มีข้อดีอะไรบ้างกับตัวคนทำงานและองค์กร หลายคนอาจจะสงสัยว่า XP คืออะไร? … มันคือรูปแบบการทำ Software Development ที่ประยุกต์ใช้หลักการของ Agile Development เข้ามา

Agile Development – Videos: เป็น Screencast ที่ผมพูดถึงหลักการที่สำคัญของ Extreme Programming (XP) เอาไว้ครับ ดูวิดีโอแล้วเพื่อนๆจะเข้าใจมากขึ้นว่า User Story คืออะไร

การเดินทาง

สุดท้ายขอฝากวิธีเดินทางไปยังจุดนัดหมายที่ Art Element: School of Art อย่างละเอียดครับ

แบบประหยัดก็รถเมล์

1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
2. จากนั้นเดินตรงไปแยกคลองเตยแล้วเลี้ยวซ้ายจะเจอป้ายรถเมล์ให้ขึ้นรถเมล์
3. สาย 22 / 45 / 46 /115 / 116 / 149 / 507 ได้หลายสายครับ บอกเค้าลงตรงป้ายองค์การโทรศัพท์ (รถมันจะผ่านจุดสังเกตทางด้านซ้ายมือเรียงลำดับดังนี้ 1.โชว์รูม BMW 2.สี่แยกเกษมราษฎร์ 3.คาร์ฟูร์ พระรามสี่ ฝั่งขวาเป็นโลตัส 4 สถานีโทรทัศน์ช่องสาม ตึกมาลีนนท์)
4. พอถึงตึกมาลีนนท์ก็กดกริ่งลงได้เลยครับ
5. จากนั้นให้เดินข้ามถนนเข้ามาที่ซอยอุทัยฟาร์มซึ่งจะอยู่ระหว่างองค์การโทรศัพท์กับตึก Green Tower ถ้าข้ามสะพานลอยให้หน้าเข้าป้ายรถเมล์แล้วเลี้ยวมาทางขวามือแล้วเดินตรงมาจะเจอซอยแรกเลยครับ (ก่อนถึงตึก Green Tower)
6. เดินเข้ามาประมาณ 50 เมตรก็เจอแล้วครับ อยู่ทางซ้ายมือ

แบบด่วนก็มอเตอร์ไซค์

1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
2. จากนั้นเดินตรงไปแยกคลองเตย เจอวินมอเตอร์ไซค์ ขึ้นเลยบอกว่าไปซอยอุทัยฟาร์มตรงตึก Green Tower ครับ 30 บาท

แบบมาเป็นกลุ่มก็แท๊กซี่

1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
2. เรียก Taxi แล้วดูตามแผนที่ครับ บอกว่าไปตรงข้ามช่อง 3

แบบขับรถมาเอง

1. มาตามเส้นทางข้างบน
2. จอดรถที่ตึก Green Tower หน้าปากซอย ชั่วโมงละ 20 บาทครับ

เจอกันเสาร์นี้ครับ

ต่อเนื่องจากบทความเก่าที่ว่าด้วยเรื่องของ Change สาเหตุหนึ่งที่ผมกล่าวถึงในนั้นก็คือบางครั้งการทำ Requirement Analysis และ Software Design ที่ไม่ครอบคลุมจะมีผลทำให้เกิด Change ตามขึ้นมาได้ (มากบ้าง น้อยบ้าง) นี่คือที่มาของบทความนี้ครับ … มันคงดีถ้าเรามี Requirement Analysis และ Software Design ที่มีประสิทธิภาพมากกว่าเดิม

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

1. ไม่มีเวลาพอที่จะทำ Analysis และ Design … ไม่แปลก เวลาเขียนโค๊ดก็แทบจะไม่มีอยู่แล้ว
2. คุยแล้วก็ไม่ค่อยละเอียดเท่าไร … ก็ไม่รู้ว่าต้องใส่ใจเรื่องอะไรบ้างนี้ บางทีตอนนั้นก็นึกไม่ออกด้วย
3. บางครั้งคิดได้แล้วนะ แต่ก็ลืม … ไม่มีเวลามานั่งทำ Design Document เล่มใหญ่ๆหรอก

แล้วก็มาถึงวิธีแก้ไขในความคิดผม จะผิดจะถูกก็แล้วแต่วิจารณญาณของเพื่อนๆครับ

เรื่องของเวลา

เราจะสร้างเวลาขึ้นมาได้อย่างไร? ยกตัวอย่างง่ายๆว่า ถ้าเรานั่งอยู่ในห้องประชุม 3 ชั่วโมงพร้อมกัน 10 คน คำนวณแล้วว่าเรามีเวลาทำงานกี่ชั่วโมง? ตอบ … 3 ชั่วโมงครับ เพราะคนทั้ง 10 คนต้องทำงานอย่างเดียวกันพร้อมกัน นั่นคือนั่งในห้องประชุม เปลี่ยนใหม่ ถ้าเรานั่งอยู่ในห้องประชุมที่หนึ่ง 3 ชั่วโมงกับคน 5 คน แล้วห้องประชุมที่สองอีก 3 ชั่วโมงกับคนอีก 5 คน คำนวณแล้วว่าเรามีเวลาทำงานกี่ชั่วโมง? ตอบ … 6 ชั่วโมงครับ เพราะว่าเราทำงานพร้อมกันไปได้สองกลุ่มนั่นเอง … นี่แหละครับ วิธีการสร้างเวลาหรือใช้เวลาให้มีประสิทธิภาพมากกว่าเดิม

ทำไมผมถึงแนะนำแบบนี้? จำกฎ 80/20 ได้มั้ยครับ? “มีคนแค่ 20 % ในห้องประชุมที่มีส่วนร่วมอย่างจริงจัง (ฟัง พูด อ่าน เขียน) … ที่เหลือ 80% เข้ามาทำไม?!!” การประชุมเป็นเรื่องที่กินเวลามากเลยถ้าบริหารจัดการไม่ดีซึ่งการทำ Requirement Analysis และ Software Design ก็เป็นรูปแบบหนึ่งของการประชุม (ไม่ว่าจะเป็นทางการหรือไม่เป็นทางการ) ดังนั้นแบ่งกลุ่มซะครับ เลือกเฉพาะคนที่จำเป็นต้องรู้ จำเป็นต้องทำ จำเป็นต้องตอบคำถามจริงๆในการคุยเรื่องนี้ ที่เหลือก็ปล่อยเค้าไปตั้งกลุ่มพูดคุย Requirement อื่นๆครับ การจะทำแบบนี้ได้ตั้งอยู่ด้วยพื้นฐานสองข้อที่ต้องยอมรับ

1. ทุกคนไม่จำเป็นต้องรู้ในรายละเอียดทุกเรื่อง และ
2. ต้องแบ่งงานให้เล็กลงในระดับที่เหมาะสม … ถ้าโอเคหละก็ลองใช้วิธีนี้ได้ครับ

เรื่องของมุมมอง

ส่วนตัวมองว่ามันหมดยุคที่แบ่งแยกงานระหว่าง Developer กับ Tester ขาดออกจากกันแล้วนะครับ ประเภทที่ว่าฉันมีหน้า Design + Code + Unit Test ไปเธอไม่ต้องมายุ่ง เจ้าตัว Tester ก็ไม่สนเรื่องอื่น นั่งรอรับของมาทำ System Test อย่างเดียวมันล้าสมัยไปแล้วอะครับ ทำไมหนะหรอ? ก็เพราะว่ามันพิสูจน์มาแล้วว่า Developer ไม่ใช่พระเจ้าที่จะ Design หรือ Code อะไรแล้วถูกต้องหมด เห็นออกจะบ่อยที่ Developer บอกกับ Tester หลังเจอบั๊กว่า “อ่าว เออ ต้องมีแบบนี้ด้วยหรอ ไม่ได้คิดไว้เลยอะ โทษทีๆ” … แล้วก็ต้องเสียเวลาแก้กันอีก ในมุมกลับกัน มีหลายครั้งที่ Tester ไม่ได้เทสบางส่วนแล้วมันก็กลายเป็นบั๊กที่หลุดไปถึงลูกค้า และ Tester ก็มาบอกเหมือนกันว่า “อ่าว เออ ต้องเทสแบบนี้ด้วยหรอ ไม่ได้คิดไว้เลยอะ โทษทีๆ” ฮ่าๆ

ทางทีดีเราควรเปิดโอกาสให้ทุกคนที่มีส่วนร่วมกับงานตรงนี้ได้มีสิทธิมีเสียงในการแสดงความคิดเห็นตั้งแต่ต้น นั่นก็คือให้โอกาสเค้าร่วมทำ Requirement Analysis และ Software Design ด้วยกันเลย การรวมกลุ่มตรงนี้จะประกอบไปด้วย Developer + Tester + Product Manager (หรือตัวแทนลูกค้าที่ตอบคำถามในเรื่อง Requirement ได้) + Domain Expert (ผู้เชี่ยวชาญด้านต่างๆ เช่น Database Expert, Security Expert หรือ Network Expert) ด้วยหลักการหนึ่งข้อคือ “ทุกคนในกลุ่มต้องมีหน้าที่ของตัวเอง” ต้องไม่มีใครที่เข้ามานั่งจ๊อง ฟังเฉยๆ ไม่พูด ไม่จด ไม่ออกความเห็น … แบบนี้ห้ามครับเพราะมันเสียเวลาเค้าเปล่าๆ ทำแบบนี้จะเป็นการเปิดมุมมองใหม่สำหรับ Requirement Analysis และ Software Design เมื่อประกอบกับการที่เรามีหลักการในการพูดคุย (แนะนำ Operational Concept) แล้วด้วย ผลที่ได้น่าจะดีขึ้นครับ

อีกหนึ่งแนวคิดที่ผมมีคือแทนที่เราที่เป็นผู้เชี่ยวชาญกับงานอยู่แล้วจะเป็นคนนำการ Analysis และ Design ทั้งหมด ลองเปลี่ยนเป็นแบบนี้ครับ … ปล่อยให้น้องๆเค้าไปทำงานกันเองแล้วค่อยนำกลับมาเสนอ ส่วนเราก็ทำหน้าที่เป็นผู้ให้ความคิดเห็นครับ ประโยชน์ที่ผมเห็นสองอย่างคือ

1. เด็กสมัยนี้เก่งนะ มุมมองกว้างกว่าเราด้วยในบางเรื่อง เช่น Technology การให้โอกาสเค้าจะเป็นการแก้ปัญหามุมมองที่ตีบตันของตัวเราเองได้ครับ
2. เป็นการพัฒนาทักษะและความสามารถให้น้องๆในทีมด้วย ทั้งเรื่องของ Technical Skill เรื่องของการทำงานเป็นทีม ฝึกการเป็นผู้นำ ฝึกการเป็นผู้ตาม และอีกมากมาย

เรื่องของเอกสาร

เรื่องนี้พูดเท่าไรก็ไม่จบเนอะ ฮ่าๆ … ปัญหาอยู่ที่ว่าความสมดุลอยู่ที่ไหน? ครั้นจะตะบี้ตะบันทำเอกสารเล่มหนาปึ้กก็เสียเวลาและไม่มีอะไรมารับประกันได้ว่าจะไม่มีอะไรเปลี่ยนแปลงภายหลัง ส่วนครั้นจะไม่ทำเลยก็จะมีปัญหาอีกว่า แล้วจะเอาอะไรเป็นตัวอ้างอิงเวลาทำงานกันหละ บางครั้งคนเราก็หลงๆลืมๆ พูดอย่างทำอีกอย่างก็บ่อยไปเนอะ ทางออกสำหรับเรื่องนี้มีอยู่ว่า …

ก่อนอื่นเราต้องบอกตัวเองว่า “เราจะทำเอกสารเท่าที่จำเป็นจริงๆ” แค่นั้นพอ มาดูกันว่าอะไรที่จำเป็นจริงๆบ้างหละ? เอกสารที่จำเป็นก็จะต่างกันไปสำหรับแต่ละ Project นะ  ยกตัวอย่างง่ายๆก็เช่น

1. Business View ซึ่งเป็นที่มาของ Workflow ที่คนทำงานควรจะต้องรู้ รวมถึงการเชื่อมโยงของงานส่วนนี้กับระบบโดยรวมทั้งหมด
2. ตัวแทนของ State Diagram ที่จะบอกเราได้ว่าทางเข้า-ทางออกของการทำงานตรงนี้คืออะไร เช่น ก่อนจะสร้าง User ได้ต้องมีเงื่อนไขอะไรบ้าง ถ้าสร้าง User สำเร็จขั้นตอนต่อไปคืออะไร แล้วถ้าสร้างไม่สำเร็จจะทำยังไง ประมาณนี้
3. ประเภทของ Input – Output ของแต่ละส่วน ซึ่งอาจจะเชื่อมโยงไปในเรื่องของการออกแบบ Database
4. หน้าจอ User Interface คร่าวๆว่าจะมีกี่ Textbox จะเป็น Dropdown list หรือ Radio Button ประมาณนี้
5. เรื่องอื่นๆ เช่น Security, Performance, และ Constraints ต่างๆที่ต้องคำนึงถึงด้วย
6. Acceptance Criteria ที่ควรจะต้องมีสำหรับงานส่วนนี้
7. อื่นๆ

แต่ต่อให้ทำแค่นี้ก็อาจจะเสียเวลาแปลงจากคำพูดและข้อตกลงในห้องประชุมมาเป็นเอกสารอยู่ดีแหละ ผมมีแนวคิดมาช่วยจัดการปัญหาตรงนี้นิดหน่อยครับ ด้วยความต้องการที่ว่า “มันน่าจะดีถ้าเราได้เอกสารออกมาทันทีหลังจากจบการประชุมเลยเนอะ” … ทำได้นะครับถ้าเรากำหนดไปเลยว่า Output ที่เราต้องการหลังจากจบการประชุมนอกเหนือจากข้อสรุปแล้วก็คือเอกสารตรงนี้แหละ โดยเรามอบหมายให้สมาชิกแต่ละคนที่เข้าประชุมรับผิดชอบเอกสารไปคนละแบบสองแบบ เช่น Developer 1 รับผิดชอบเขียน Workflow กับ UI รวมกับ Developer 2 เขียน State Diagram กับ Input/Output ส่วน Tester ก็รับ Acceptance Criteria ไป พยายามใช้บอร์ด กระดาษ ปากกา ดินสอ ขีดเขียนวาดรูปให้เยอะๆครับ เอาว่าให้อ่านแล้วเข้าใจกันได้ ถ่ายรูปแล้วเก็บไว้ … นี่ก็เป็น Design Document รูปแบบหนึ่งที่พอเพียงและใช้ได้จริง เราไม่ต้องไปเสียเวลาแปลงให้เป็น Word หรือ Visio ครับ

ยังไม่หมด ฮ่าๆ … ขั้นตอนสุดท้ายก็คือการบอกข้อมูลการ Design อย่างละเอียด (สุดๆ) ไว้ด้วยการ Comment Code ครับ ถ้าตรงนี้ทำได้ดีมันจะเป็น Design Document ที่มีประสิทธิภาพที่สุดเพราะว่าก็เห็นๆอยู่ว่า Code มันเขียนไว้แบบนี้แหละ อีกจุดหนึ่งที่สะท้อนให้เห็นถึง Design ก็คือ Acceptance Criteria หรือว่า Test Case ของเรานั่นเองครับ ถ้ามี Comment ไว้ด้วยก็จะดีมากเช่นกันครับ

เรื่องของ Change

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

หลังจากคิดอยู่นาน … สรุปว่า Chapterpiece.Meeting.3 จะพูดคุยกันเรื่อง User Story for Agile Development ครับ เหตุผลที่เลือกหัวข้อนี้ก็เพราะ:

• เป็นการต่อยอดความรู้จาก Chapterpiece.Meeting.1: Agile Development — First Chapter
• User Story เป็นเรื่องที่มีข้อสงสัยในความหมาย ประโยชน์และกระบวนการให้ได้มาซึ่งสิ่งนี้มากทีเดียว
• เป็นโอกาสอันดีที่เราจะได้ทำ Workshop กันครับ … เปลี่ยนบรรยากาศไปด้วย

สำหรับเพื่อนๆที่สนใจเข้าร่วมกิจกรรมครั้งนี้ ถ้าใครมีพื้นฐานเรื่อง Agile Development มาก่อนแล้วจะดีมากเลยครับ จะได้มาช่วยกันแชร์ประสบการณ์ ฮ่าๆ แต่ไม่ต้องกังวลไปสำหรับมือใหม่ (อยาก) หัดใช้ Agile … ผมจะเล่าที่มาที่ไปและหลักการของเจ้าวิธีการพัฒนาซอฟท์แวร์แบบใหม่นี้ให้ฟังกันก่อนครับ เอาแบบคร่าวๆนะ ใช้เวลาไม่เกิน 10 นาที

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

เรื่องสถานที่ ต้องขอบคุณ Art Element: School of Art ที่อำนวยความสะดวกให้เราได้ใช้สถานที่ฟรีเช่นเคย มีทั้งห้องแอร์ โปรเจกเตอร์ และมีร้านกาแฟข้างล่างด้วย … ไม่ต้องซื้อกาแฟจากข้างนอกเข้ามานะ

อ่านมาก็หลายครั้ง เห็นมาก็หลายหนกับคำแนะนำที่ว่า “เราควรใช้ข้อมูลและตัวเลขเก่าๆมาช่วยในการทำ Software Estimation” ก็ฟังดูดีนะครับแต่หลังจากได้ลองผิดลองถูกมากขึ้น ประสบการณ์บอกให้ผมรู้ว่าหลักการแบบนี้อันตรายทีเดียว … ทำไมถึงเป็นแบบนั้น? ก็กฎง่ายๆที่ว่า “Bad In – Bad Out” คุณภาพของข้อมูลห่วย ผลลัพธ์ก็ห่วยตามเป็นธรรมดา ขอขยายความแบบนี้ครับ

Requirement Characteristic กับ Software Estimation

การได้มาของข้อมูลเป็นเรื่องสำคัญมากครับ ลองถามตัวเองว่าเราทำ Software Estimation กันอย่างไร? ถ้าเป็นแบบนี้อาจมีปัญหาได้นะ

1. ได้ Requirement มาก็อาศัยความที่เป็นผู้อาวุโสรวบหัวรวบหางเริ่มต้นการ Estimate ทันที
2. อ่าน Requirement แล้วเริ่มวิเคราะห์ว่า เอ่อ มันต้องทำอะไรมั่งวะเนี่ยะ … Analyze ต่ออีกหน่อยพร้อมๆกับ Design อืม ต้องแก้ Code เยอะเหมือนกันนะเนี่ยะ ทั้ง Server แล้วก็ UI แต่ยังโชคดีที่ Test ไม่ยากเท่าไร
3. คิดได้ดังนั้นแล้วก็ … 15 วันคงเสร็จมั้ง

จบกระบวนการทำ Estimation อย่างรวดเร็ว ปัญหาที่จะตามมาจากกระบวนการนี้มีเยอะแยะ เช่น 1. คิดคนเดียวแน่ใจหรอว่าถูก 2. นี่คุณเป็น Developer นะ ไปคิดแทน QA เค้าได้ยังไงว่ามันจะ Test ง่าย 3. เออ คุณเก่งแล้วนี่ทำงานมานาน ถ้าให้น้องใหม่ที่เพิ่งเข้ามาทำงานได้ 2 เดือนมันจะทำได้เร็วแบบคุณมั้ยเนี่ยะ? และอื่นๆ อีกมาก

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

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

ปัจจัย	คำอธิบาย
Requirement Stability	ความแน่นอนของ Requirement นี้มีมากน้อยแค่ไหน ถ้าน้อยเราคงต้องเผื่อเวลาไว้สำหรับ Change บ้าง
Data Migration	Requirement ตัวนี้ต้องมีการทำ Data Migration ด้วยมั้ย ถ้ามีเราก็ต้องเผื่อเวลาเพิ่มเข้าไปอีก
Application Experience	คนที่จะมาทำ Requirement นี้มีประสบการณ์ในงานมากน้อยแค่ไหน ถ้าน้อยเราก็ต้องเผื่อเวลาเข้าไปอีก
Technology Experience	คนที่จะมาทำ Requirement นี้มีประสบการณ์ใน Technology ที่จะใช้มากน้อยแค่ไหน ถ้าน้อยเราก็ต้องเผื่อเวลาเข้าไปอีก
Maturity of Technology	Technology ที่เราเลือกใช้มันเป็นที่ยอมรับและได้รับการพิสูจน์ว่าดีจริงมาแล้วรึยัง ถ้ายังเราต้องเผื่อเวลาไว้สำหรับปัญหาที่จะเกิดขึ้นด้วย
Reusable Components	เราสามารถจะเอาของที่มีอยู่แล้วมาใช้กับ Requirement นี้บ้างได้มั้ย เช่น Code หรือ Test Case ถ้ามีอยู่แล้วก็ดี เราจะได้ไม่ต้องเสียเวลาทำทุกอย่างใหม่หมด

สิ่งที่ผมพยายามจะสื่อให้เห็นคือ ถ้าเราอยากหวังจะพึ่งพิงตัวเลขเก่าๆมาช่วยในการทำ Software Estimation แล้วหละก็ นอกจากตัวเลขที่บอกว่างานนี้ใช้เวลาทำกี่วันแล้ว เราควรจะต้องเก็บ Requirement Characteristic นั่นก็คือสมมติฐานที่เราใช้เพื่อให้ได้มาซึ่งตัวเลขนี้ด้วยครับ งานยักษ์เลยหละ แล้วสุดท้ายก็จะลงเอยที่ไม่มีใครยอมทำและไม่มีเวลาทำ … ตัวเลขที่ได้มาจากการนั่งเทียนเลยเป็นตัวเลขที่อันตรายตามไปด้วย

Estimate กับ Actual มันคนละเรื่องกัน

ความสับสนในเรื่องตัวเลขและความหมายของมันมีส่วนสำคัญมากนะครับ เราต้องทำความเข้าใจก่อนว่าไม่ใช่แค่ Estimate แล้วจะจบเรื่องกันไป ความจริงแล้วตัวเลขที่ Estimate ออกมานั้นไร้ประโยชน์เลยด้วยซ้ำ เช่น ถ้าเรา Estimate ว่า Requirement นี้ต้องใช้เวลา Coding 10 วัน … แต่เอาเข้าจริงใช้เวลาไป 15 วัน เพื่อนๆคิดว่าตัวเลขไหนที่ควรจะเอามาพิจารณาตอนทำ Estimation ครั้งหน้าครับ? … มันก็ต้อง 15 วันเซ่ ก็ของจริงหรือ Actual มันใช้เท่านั้นนี่ เห็นมั้ยครับว่าเลข 10 ที่ได้จากการทำ Estimation มันไม่มีประโยชน์อะไรเลย แต่ปัญหาที่ตามมามันอยู่ตรงนี้แหละว่าเราจะเก็บค่า Actual ได้ให้กับทุกงานใน Project ได้อย่างครบถ้วนหรือไม่?

นี่เป็นหลักฐานแสดงให้เห็นถึงความเข้มแข็งของการทำ Project Tracking และความอุตสาหะอย่างยิ่งของ Project Manager กันเลยทีเดียวครับ ฮ่าๆ ก็เพราะมันไม่ใช่เรื่องง่ายนะที่ต้องเก็บข้อมูลทั้งหมดนี้ ยิ่งกับ Project ใหญ่ๆที่มี Task เยอะๆ … สำหรับใครที่ใช้ Microsoft Project เป็นตัวช่วยก็อาจจะง่ายหน่อย เราทำ Baseline Plan ไว้แล้วก็มากรอกข้อมูล Actual เข้าไปตอนทำ Tracking มันก็จะเห็นได้ว่า Estimate ไว้กี่วัน Actual กี่วัน (แล้วจะตกใจกับความแตกต่าง ฮ่าๆ) สำรหรับคนที่ใช้ Microsoft Excel ก็อาจจะยากหน่อยเพราะต้องเตรียม Template เองเป็นต้น

ความยากมันยังไม่หมดไปเพราะว่าเราต้องใช้ความพยายามสูงเลยหละที่จะไปตามเก็บข้อมูลพวกนี้มาใส่ Project Plan ของเราครับ ถ้ายิ่งมีงานเยอะมีสมาชิกเยอะก็ลำบากเข้าไปอีก บางครั้งงานบางงานต้องทำโดยคนที่อยู่ต่างประเทศก็ไปกันใหญ่ ถ้าไม่มั่นใจว่าเราได้ค่า Actual มา ผมว่าการเอา Historical Data ที่เป็นค่า Estimation มาใช้นั้นผิดอย่างมากเลยหละ

Actual Effort ที่ได้มาถูกต้องแล้วหรอ?

ถ้าเรามีเวลาและความพยายามตามเก็บค่า Actual Effort ของทุกงานที่อยู่ใน Project ได้ก็ยังมีปัญหาให้ปวดหัวต่อไปอีกว่า แล้วตัวเลขที่ได้มาเนี่ยะมันถูกต้องและเชื่อถือได้มากน้อยแค่ไหน? เรื่องนี้พูดยากมากเลย … เริ่มยังไงดี? …  มันเป็นเรื่อง Effort – Duration – Calendar Day ซึ่งเป็นตัวเลขสามตัวที่เกี่ยวข้องกันในมุมมอง Project Management ครับ ประเด็นคือการที่เราจะบอกว่างานนี้ใช้เวลาทำ 1 วันหมายความว่ายังไงครับ?

• ก็ต้องมาดูว่าวันนึงเราทำงานกี่ชั่วโมง ดังนั้นเราจะพูดได้เต็มปากว่างานนี้จะใช้เวลาทำหนึ่งวันนั้นคือเราทำงานนั้นต่อเนื่องเป็นเวลา 8 ชั่วโมง นี่คือ Effort ที่ต้องใช้
• แล้วถ้าเราทำงานนี้วันละ 4 ชั่วโมง 2 วันหละ แปลว่างานนี้ต้องใช้ 2 วันรึเปล่า? … ไม่ใช่ครับ Effort ที่เกิดขึ้นก็ยังเป็น 8 ชั่วโมงซึ่งแปลงกลับมาได้เป็นแค่ 1 วันทำงานอยู่ดี

ปัญหามันอยู่ตรงนี้แหละ เพราะว่าใน Project Plan ของเราจะมีวันเริ่ม-วันจบของงานอยู่ซึ่งวันจบงานนี้บอกเราไม่ได้ว่า Effort ที่เกิดขึ้นจริงเป็นเท่าไร เช่น ผมขี้เกียจอะ ทำงานนี้วันละ 1 ชั่วโมง กว่าจะเสร็จก็ 8 วัน … แปลว่างานนี้ต้องทำ 8 วันรึเปล่า? ไม่ใช่หรอกแต่ใน Project Plan จะบอกว่าเริ่มงานวันที่ 1 แล้วเสร็จวันที่ 8 อะครับ นี่แหละปัญหาที่ว่าการเก็บค่า Actual Effort มันไม่ง่าย

และต่อให้เราทุ่มเทมากขึ้นกว่าเดิมด้วยการมีระบบ Time Tracking ที่ขอความร่วมมือ (แกมบังคับ) ให้สมาชิกในทีมเข้ามากรอกข้อมูลว่าแต่ละวันทำงานอะไรไปบ้าง อย่างละกี่ชั่วโมง ตัวเลขที่ได้จะละเอียดขึ้นครับว่า Requirement นี้ใครมีส่วนร่วมทำบ้าง แล้วทำคนละกี่ชั่วโมงต่อวัน อะไรประมาณนี้ แต่ปัญหา (อีกแล้ว) คือรู้ได้ยังไงว่าตัวเลขที่สมาชิกในทีมกรอกมามันตรงกับความจริง … นั่งเทียนกันมาทั้งนั้นแหละครับ ใครจะมานั่งจำว่าวันๆนึงทำงานอะไรไปเท่าไรกันบ้าง เนอะ ฮ่าๆๆ

Lesson Learned in Software Estimation

เป้าหมายของบทความนี้คือห้ามไม่ให้เพื่อนเอาตัวเลขเก่าๆมาใช้ในการทำ Software Estimation เลยหรอ? ไม่ขนาดนั้นหรอก ผมแค่ต้องการจะชี้ให้เห็นถึงปัญหาที่เป็นอยู่กับการเอาตัวเลขที่อาจจะไม่มีความถูกต้องมากนักมาใช้เป็นหลักยึดในการทำ Software Estimation ครับ แต่ถ้าใครที่มองแล้วว่า Project ตัวเองมีการทำ Software Estimation ที่ถูกต้อง มีการเก็บข้อมูลที่ดีและครบถ้วน บวกกับไม่ลืมเรื่องการทำ Project Tracking เพื่อเก็บ Actual Effort แล้วหละก็ … ยินดีด้วยครับ (อิจฉาด้วยแหละ) ที่ตัวเลขที่เพื่อนๆมีในมือนั้นถือว่าเป็นขุมทรัพย์เลยหละ

ส่วนตัวผมเองก็ต้องบอกตามตรงว่าทำไม่ได้ขนาดนั้นหรอก ตัวเลขที่ได้มาแต่ละครั้งก็นั่งเทียนบ้างอะไรบ้าง การเก็บ Actual Effort ก็ขาดไปเยอะ ดังนั้นสิ่งที่ผมใช้แทนตัวเลขเหล่านี้ตอนทำ Estimation ก็คือ Lesson Learned ครับ บทเรียนที่ว่าคือ ถ้าทำอะไรดีเราก็ทำต่อ ถ้าอะไรทำแล้วไม่เข้าท่าเราก็พยายามปรับปรุงหรือไม่ก็เลิกใช้ไป … Lesson Learned สำหรับ Software Estimation ที่ผมมีก็ …

1. การใช้เวลาในการ Estimate มากไม่ได้เป็นการการันตีว่าจะได้ผลที่ถูกต้องมากขึ้น
2. ใช้ PERT ในการทำ Estimation แล้วถือว่าโอเคนะแต่ใช้เวลาพอสมควร
3. ใช้ Delphi ในการทำ Estimation ก็ดีเหมือนกันเพราะได้ความคิดเห็นจากคนมากกว่าหนึ่งคน มีการเปิดช่องให้พูดคุยเพื่อทำความเข้าใจในงานระหว่างกันด้วย แต่เสียเวลามากเลย
4. เคยเอาคนทั้งทีมมาช่วยกันทำ Estimation นะ นั่งรวมกันในห้องประชุมแล้วก็ Estimate ร่วมกัน เสียเวลา เสียแรง ผลที่ได้ก็ใช่จะตรงเป๊ะ ไม่คุ้มเท่าไร
   
5. ตอนหลังเลยเปลี่ยนเป็นจับคู่กัน Estimate ส่วนใหญ่จะเป็น Senior + Junior คู่กันช่วยกัน Estimate เฉพาะงานที่ได้รับมอบหมายให้ทำ ประหยัดเวลาได้มากขึ้น ผลลัพธ์ที่ได้ก็โอเค ถือว่าคุ้มค่าที่จะทำต่อ
   
6. สำคัญมากว่าควรจะให้คนทำได้มีสิทธิมีเสียงในการ Estimate ด้วย ไม่ใช่ว่าใครก็ไม่รู้จับงานมายัดใส่มือพร้อมกับเวลาที่น้อยเกินไป
7. หลังๆเริ่มมีการรวมกลุ่มระหว่าง Developer และ QA เข้ามาช่วยกัน Estimate เพื่อเปิดมุมมองของอีกฝั่งหนึ่ง ประโยชน์ที่ได้รับก็คือการทำ Requirement Analysis และ Design ไปในตัวเลย
8. เคยทำ Planning Game ของ Agile Development แล้วด้วย สนุกมาก เสียเวลามาก และด้วยความที่เป็น Project แรก ตัวเลขที่ได้ออกมาก็มั่วมากด้วย ฮ่าๆๆ
9. Story Point ที่ได้ออกมามันไม่ค่อยตรง และด้วยความคุ้นเคยทุกคนจะถามคำถามเดียวกันว่า “5 แต้มนี่มันใช้เวลาทำกี่วัน แล้วต้องเสร็จเมื่อไร?” สุดท้ายเลยต้องเปลี่ยนจาก Point มาเป็น Ideal Day แทน ทั้งที่พอรู้มาบ้างว่าเราไม่ควรไปยึดติดกับแนวคิดเดิมที่มองอะไรเป็นวัน แต่ต้านกระแสมหาชนไม่อยู่จริงๆ
   
10. ได้ด้วเลขมาแล้วก็อย่าลืมคิดเรื่องวันหยุดราชการ วันลาพักร้อนและวันลาป่วยเผื่อๆไว้ด้วย
11. ได้ตัวเลขมาแล้วก็อย่าลืมบวก Buffer ไปด้วยนะ ไม่งั้นเดี๋ยวมี Change เข้ามาแล้วจะยุ่ง
12. อย่ามองว่า Software Estimation คือกระบวนการที่ทำครั้งเดียวเสร็จ หมั่นตรวจสอบผลการ Estimate อยู่เรื่อยๆเพราะบ่อยครั้งตัวเลขที่ได้มามันไม่ตรงหรอก ถ้า Requirement แรกก็คลาดเคลื่อนไปมากกว่า 30% แล้วเราควรจะมานั่งพิจารณาหน่อยว่า เฮ้ย แล้วไอ้ Requirement ที่เหลือมันจะตรงมั้ยวะเนี่ยะ ฮ่าๆๆ กระบวนการนี้เรียกว่า Re-Estimation
    
13. ถ้า Requirement ไม่ค่อยชัดเจนหรือคาดการณ์แล้วว่าต้องมีการเปลี่ยนแปลงเกิดขึ้นเรื่อยๆ แนะนำให้ใช้ Iterative จะดีกว่า การทำ Estimation จะยืดหยุ่นมากขึ้นด้วย
14. ถ้าเป็นไปได้ก็พยายามแบ่ง Requirement ออกมาเป็นส่วนย่อยๆแล้วค่อย Estimate จากงานที่เล็กๆ ตัวเลขที่ได้จะแม่นยำกว่าเดิม
15. ถ้าไม่แน่ใจว่างานนี้ยากง่ายแค่ไหน ลองปรึกษาผู้เชี่ยวชาญดูก่อน จะทีมเดียวกันหรือต่างทีมก็ได้นะ

สรุปง่ายๆว่า Software Estimation เป็นเรื่องยากมากสำหรับผมนะ เพื่อนๆคิดว่าไงกันมั่งครับ?