TDE&W (3) :: TEAM FOUNDATION SERVICE
ก็เป็นตอนที่ 3 แล้วสิ่งที่ผมจะมาพูดถึงในวันนี้คือหนึ่งในเรื่องที่ตัดสินใจยากที่สุดตั้งแต่ตอนเริ่มทำ Project I แล้วคือการหา Project Management Tool ครับย้อนกลับไปในเดือนกรกฎาคมปี 2013 เป็นช่วงเวลาที่โปรเจ็คเริ่มตั้งไข่หลังจากส่ง Proposal และได้รับการอนุมัติแล้วในช่วงเวลานั้นผมยังคงยอมรับว่าผมยังคงใหม่กับ Agile Practice มาก (จนถึงตอนนี้ก็ยังยอมรับว่ายังใหม่อยู่) และสิ่งที่มือใหม่ Agile มักจะทำกันจากที่ผมสังเกตมาหลายคนที่ศึกษาเองคือหาเครื่องมือที่เหมาะสมกับตัวเองและทีมเพื่อที่จะใช้ Agile ได้อย่างสมบูรณ์แบบ (แต่ผมก็ไม่ได้บอกว่าวิธีการนี้เป็นวิธีการศึกษาที่ดีนะครับจริงๆพอมามองย้อนกลับไปผมน่าจะไปศึกษาแนวคิดให้มันแน่นกว่านี้แต่อย่างว่ามือใหม่มักจะตื่นเต้นกับ Tools มากกว่าหลักการจริงๆเสมอ)
ผมเริ่มต้นการศึกษาหลักการนี้จากงาน 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เป็นหนึ่งในเครื่องมือที่ใช้ในการทำ Agile ได้ง่ายที่สุดและเร็วที่สุดเพราะแทบจะไม่มีอะไรเลยนอกจาก Kanban board ซึ่งเอาเข้าจริงก็ตอบโจทย์ผมได้ในระดับนึงเลยทีเดียวความสามารถในการปรับแต่งตัวโครงสร้างของบอร์ดให้รองรับกับรูปแบบของทีมถือว่าเป็นจุดเด่นอย่างหนึ่งที่ผมยอมรับเลยว่า Trello ทำออกมาได้ดีมาก (แต่ก็อย่าลืมว่าเครื่องมือส่วนใหญ่หลายๆตัวก็สามารถปรับแต่งในจุดนี้ได้) ผมยอมรับตามตรงว่าไม่ได้มีโอกาสสัมผัส Trello อย่างจริงจังมากเพราะในตอนนั้นผมคิดแต่เพียงว่าในเมื่อมันเป็นแค่ Board และตัวอื่นๆก็สามารถทำได้หมดทำไมไม่หาเครื่องมือที่มันครบเครื่องกว่านี้หล่ะ (เป้าหมายจริงๆคืออยากได้เครื่องมือที่วาด Burndown Chart ให้ได้พอมาคิดดูตอนนี้ทำไมแนวคิดผมโคตรเด็กเลยแหะ)
จริงๆผมมีเครื่องมือที่อยากพูดถึงอีกหลายตัวก่อนจะเข้า 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 ที่ไว้คอยจับคนอู้ได้อย่างชัดเจน
ในช่วงเดือนกันยายนปี 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 แล้วครับด้วยเหตุผลบางอย่าง...
Original post at: https://yothinix.blogspot.com/2013/11/tde-3-team-foundation-service.html