TDE&W (3) :: Team Foundation Service

ตอนที่ 3 ออกก่อนตอนที่ 2 Git Basic เพราะในวันพฤหัสนี้ผมมี Session สอนเลยอาจได้ใส่อะไรเพิ่มเติมในหัวข้อดังกล่าวครับ

       ก็เป็นตอนที่ 3 แล้ว สิ่งที่ผมจะมาพูดถึงในวันนี้คือ หนึ่งในเรื่องที่ตัดสินใจยากที่สุดตั้งแต่ตอนเริ่มทำ Project I แล้วคือ การหา Project Management Tool ครับ ย้อนกลับไปในเดือนกรกฎาคมปี 2013 เป็นช่วงเวลาที่โปรเจ็คเริ่มตั้งไข่ หลังจากส่ง Proposal และได้รับการอนุมัติแล้ว ในช่วงเวลานั้นผมยังคงยอมรับว่าผมยังคงใหม่กับ Agile Practice มาก (จนถึงตอนนี้ก็ยังยอมรับว่ายังใหม่อยู่) และสิ่งที่มือใหม่ Agile มักจะทำกันจากที่ผมสังเกตมาหลายคนที่ศึกษาเอง คือหาเครื่องมือที่เหมาะสมกับตัวเองและทีม เพื่อที่จะใช้ Agile ได้อย่างสมบูรณ์แบบ (แต่ผมก็ไม่ได้บอกว่าวิธีการนี้เป็นวิธีการศึกษาที่ดีนะครับ จริงๆ พอมามองย้อนกลับไปผมน่าจะไปศึกษาแนวคิดให้มันแน่นกว่านี้ แต่อย่างว่ามือใหม่มักจะตื่นเต้นกับ Tools มากกว่าหลักการจริงๆ เสมอ)

Release Backlog แรกสุดที่ทำ มีแค่ Excel

       ผมเริ่มต้นการศึกษาหลักการนี้จากงาน Agile Thailand 2013 แล้วต่อยอดมาอ่าน Agile Samurai และ Scrum Primer ซึ่งสุดท้ายแล้วก็เลือกที่จะนำเอาแนวคิด Scrum มาใช้ในการทำ Project อย่างที่ท่านๆ ได้เคยเห็นไปแล้วในบล็อกตอนก่อนๆ เครื่องมือที่ใช้ในช่วงแรกๆ นั้นมีแค่ Excel, Post-It และ Whiteboard แค่นั้นในการทำ Backlog Grooming ครั้งแรกซึ่ง การคุยกันครั้งแรกสามารถแตก User Story บางเรื่องที่ไม่เคยคิดว่าจะใหญ่ออกเป็นก้อนเล็กๆ ได้ และสามารถคิด Feature เพิ่มขึ้นมาได้หลายอย่างด้วย พอเรียงลำดับความสำคัญกันเสร็จ ผมและทีมก็ประสบปัญหาทันทีคือ จะเอามันไปไว้ตรงไหนให้ดูได้ตลอด Story ในเวลานั้นก็เลยย้ายไปติด Product Backlog ไว้มุมห้องมุมหนึ่ง ซึ่งสรุปในเวลาต่อมาไม่นานว่า แทบไม่มีใครดูเลย เพราะมันติดกันอัดแน่นมาก ผมจึงเริ่มมองหาเครื่องมือใหม่อีกครั้ง

       โชคไม่ดีที่หลังจากนั้นไม่นานผมและทีมตัดสินใจที่จะเปลี่ยนหัวข้อการทำ Project ใหม่ สิ่งที่ส่งผลตามมาคือทุกอย่างที่เราเคยทำไว้ก่อนหน้านี้ถือว่า เซตซีโร่, ยกเข่ง ทำใหม่หมด ช่วงนั้นหนึ่งในเรื่องพื้นฐานที่สุดที่ต้องเปลี่ยนคือ เราต้องการ Tool ที่ทุกคนสามารถที่จะเข้าไปดูความคืบหน้าของแต่ละคนได้ และสามารถรองรับแนวคิด Scrum ที่เรากำลังยึดถือกันอยู่ได้ ความต้องการแค่นี้หลังจากนั้นเป็นการหาข้อมูล และผมค้นพบว่ามีการถกเถียงกันอย่างกว้างขวางในเรื่องของ Tools ในสังคม Agile หลายๆ ที่ไม่ว่าจะเป็นใน Stack overflow, ตามบล็อกอิสระทั่วไป หรือแม้กระทั่งในกลุ่ม Agile66 เอง แต่นอกจากแนวคิดที่ใช้แค่ Post-It กับกระดานบอร์ดนั้น Tools ที่ใช้มีหลักๆ ที่คนแนะนำอยู่ไม่กี่ตัวหนึ่งในนั้นคือ Trello

Trello

       Trello เป็นหนึ่งในเครื่องมือที่ใช้ในการทำ Agile ได้ง่ายที่สุดและเร็วที่สุด เพราะแทบจะไม่มีอะไรเลยนอกจาก Kanban board  ซึ่งเอาเข้าจริงก็ตอบโจทย์ผมได้ในระดับนึงเลยทีเดียว ความสามารถในการปรับแต่งตัวโครงสร้างของบอร์ดให้รองรับกับรูปแบบของทีมถือว่าเป็น จุดเด่น อย่างหนึ่งที่ผมยอมรับเลยว่า Trello ทำออกมาได้ดีมาก (แต่ก็อย่าลืมว่าเครื่องมือส่วนใหญ่หลายๆ ตัวก็สามารถปรับแต่งในจุดนี้ได้) ผมยอมรับตามตรงว่าไม่ได้มีโอกาสสัมผัส Trello อย่างจริงจังมาก เพราะในตอนนั้นผมคิดแต่เพียงว่าในเมื่อมันเป็นแค่ Board และตัวอื่นๆ ก็สามารถทำได้หมดทำไมไม่หาเครื่องมือที่มันครบเครื่องกว่านี้หล่ะ (เป้าหมายจริงๆ คืออยากได้เครื่องมือที่วาด Burndown Chart ให้ได้ พอมาคิดดูตอนนี้ทำไมแนวคิดผมโคตรเด็กเลยแหะ)

Asana

       จริงๆ ผมมีเครื่องมือที่อยากพูดถึงอีกหลายตัวก่อนจะเข้า TFS ซักที ตัวสุดท้ายที่ผมอยากจะพูดถึงก่อนเราจะเข้าเรื่องหลักที่จะมาพูดกันในวันนี้คือ Asana ครับ Asana เป็น Project Management Tool ที่เพิ่งเปิดตัวได้ไม่นาน เป็นผลงานของ Dustin Moskovitz (Facebook Co-founder) และทีมงาน ซึ่งด้วยเหตุนี้ทำให้เครื่องมือตัวนี้ออกจะโด่งดังอยู่ซักหน่อย จุดเด่นจริงๆ ของ Tool ตัวนี้คือ Task Management โดยหลักการแล้ว แทบไม่แตกต่างจาก Basecamp หรือตัวอื่นๆ มากนัก แต่ที่ประทับใจที่สุดก็คงจะเป็น UX ที่วืดวาดๆ ได้ถูกใจวัยรุ่นเป็นอย่างมาก รวมถึงระบบส่ง email ในการแจ้งเตือน Task ที่ใกล้จะเสร็จก็พูดตามตรงว่าโคตรน่ารำคาญแต่ได้ผลมากระดับนึง อย่างไรก็ตามผมมองว่าสำหรับทีมผมการที่เราไม่เลือกใช้เครื่องมือตัวนี้มีเพียงเหตุผลเดียว "มันไม่มีบอร์ดงาน"

       Microsoft Team Foundation Service มาเตะตาผมตอนที่ผมคิดจะเริ่มไปใช้ Microsoft Project แต่ด้วยเหตุผลบางอย่างผมมองว่า Microsoft Project เป็นเครื่องมือที่โบราณและอุ้ยอ้ายเกินกว่าที่จะทำ Agile ได้ ผมเลยผ่านมาหา TFS อีกรอบ จริงๆ แล้วนี่ไม่ใช่ครั้งแรกที่ผมคิดจะใช้ TFS ตอนช่วงระหว่างฝึกงานภาคฤดูร้อน ผมเคยมีแนวคิดที่จะใช้ TFS ในการจัดการงานที่ทำในช่วงฝึกงานอยู่พักนึง (เนื่องจากตอนนั้น Scale งานเริ่มใหญ่ขึ้นเรื่อยๆ) แต่การที่ในช่วงฝึกงานยังมีความรู้ในแนวคิดของ Agile และ Scrum อยู่น้อยมากทำให้ความพยายามในการใช้งานครั้งแรกไม่ประสบความสำเร็จซักเท่าไร และผมก็ลืมมันไปจนกระทั่งอย่างที่บอกลอยมาเตะตาอีกครั้ง ต้องสารภาพไว้ก่อนว่าผมได้ใช้ TFS แค่ในส่วนของ Work Management แค่นั้นในส่วนของ Source code management และ Build/Test Server ผมไม่ได้แตะมันเลย (เนื่องจากโปรเจ็คของทีมผมเป็น PHP-Based) 

       เนื่องจากทีมของผมเป็นทีมที่โคตรมีขนาดเล็ก (มีกันอยู่ 3 คน) ทำให้สามารถใช้โปรโมชั่นฟรีของเครื่องมือหลายๆ ตัวได้ TFS เองก็เป็นหนึ่งในนั้นโดยมี Free Plan ไว้จำกัดที่ไม่เกิน 5 User ตัว TFS เองมาพร้อมกับ Process Template ทั้ง Agile และ CMMI โดย Template ที่ทีมผมเลือกใช้คือ Microsoft Visual Studio Scrum 3.0 ซึ่งตอบโจทย์ผมได้พอดีจากที่กล่าวไปในตอนต้นว่าผมใช้ Scrum เป็นแนวคิดหลักในการทำงานของทีม เครื่องมือที่ TFS มีมาให้พูดจริงๆ ก็เรียกได้ว่าครบครันพอเพียง ตรงตามความต้องการหลายๆ อย่างไม่ว่าจะเป็นตาราง Backlog ตั้งแต่ในระดับ Release จนถึงในระดับ Sprint, Cumulative Flow, เครื่องมือวัด Team Velocity และ Board ในการทำงานพร้อม Burndown Chart ที่ไว้คอยจับคนอู้ได้อย่างชัดเจน

Sprint Backlog ช่วงท้ายๆ Project I

       ในช่วงเดือนกันยายนปี 2013 ซึ่งเป็นช่วงที่เข้มข้นที่สุดของ Project I เลยก็ว่าได้ ผมยอมรับเลยว่า TFS มีส่วนช่วยมากกว่า 50% ในการจัดการงานให้ทีมของผมสามารถทำสำเร็จลุล่วงไปได้จนถึงการสอบ ปัญหาที่เจอในช่วง Sprint แรกคือ ทีมผมไม่สามารถประเมินเวลาการทำงานได้อย่างต่อเนื่อง อาจจะยังเป็นเพราะยังไม่ชินกับการทำงานในแบบนี้ (ลากจาก To-dos ->Done ทีเดียวตอนงานเสร็จ) ทำให้พอจบ Sprint 1 ต้องมาคุยกันอีกรอบว่าต้องขยันอัพเดทบอร์ดกันมากกว่านี้ และสิ่งที่เป็นปัญหาอีกอย่างคือการไม่ได้กำหนด Definition of Done ของหลายๆ งานที่สร้างกันไว้ ทำให้คำว่าเสร็จของแต่ละคนในทีม ความหมายไม่ตรงกันและสุดท้ายมันก็ไม่เสร็จ (ในความหมายของทุกคน (แต่อาจจะเสร็จในความหมายของบางคน)) ซึ่งนี่ก็เป็นอีกจุดหนึ่งที่ทีมผมพยายามปรับปรุงกันตลอด 4 Sprint 

       อย่างไรก็แล้วแต่ สิ่งสำคัญที่สุดสิ่งหนึ่งที่ได้เรียนรู้หลังจากการทำงานใน Project I ผ่านไปคือ ยิ่งทีมนั่งทำงานด้วยกันมากเท่าไร โอกาสที่ Flow การทำงานมันจะไหลไปได้เร็วโดยไม่ขลุกขลักก็มีสูงขึ้นมาก เนื่องจากในช่วงแรกๆ จนถึงกลางๆ ของการทำ Project I ผมเป็นคนเดียวในทีมที่แยกออกมานั่งทำงานจากคนละที่กับทีม ทำให้เจอปัญหาสำคัญคือ การสื่อสารไม่เข้าใจกันและทำให้เกิดความไม่เข้าใจกันในเรื่อง Definition of Done อย่างที่กล่าวไปแล้ว ขอกล่าวไว้ก่อนว่าผมไม่ได้บอกว่าการทำงานแบบ Remote เป็นสิ่งที่ไม่ดี แต่การจะทำงานแบบนั้นได้มีประสิทธิภาพให้ใกล้เคียงกับการทำงานด้วยกันในที่เดียวกัน คือ ต้องสื่อสารกับทีมให้เคลียร์และไม่ค้างคาตลอดเวลาของการทำ Project ไม่ใช่เพียงเฉพาะช่วงเริ่มต้น (แต่ช่วงเริ่มต้นอาจจะมากหน่อย) 

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

ปล.Project II ปัจจุบันผมเลิกใช้ TFS แล้วครับด้วยเหตุผลบางอย่าง...