เก็บตกจากเสวนา @tarad.com

ขอบคุณทุกท่านอีกครั้งครับที่ได้ให้โอกาสผมไปร่วมเสวนาในครั้งนี้ ไปครั้งนี้ได้ความรู้ใหม่ๆเยอะ เลยของขึ้นต้องมาขอระบายที่นี่ ไม่พูดมากเริ่มกันเลยดีกว่า

อไจล์ต้องการเฉพาะคนเก่งๆ มาร่วมทีม

เรื่องนี้ดูจะเป็นสิ่งที่หลายคนพอเริ่มศึกษาก็จะพลอยคิดไปอย่างนั้น เพราะสามัญสำนึก(common sense) ของเราคือคนเก่งควบคุมดูแล คนไม่เก่ง พอจะได้ดูแลกันเองก็แปลว่าต้องมีแต่คนเก่ง อันนี้ไม่จริงเลย อไจล์ไม่เคยต้องการคนเก่ง แต่ต้องการคนดีต่างหาก พอพูดว่าดีก็ฟังดูเลื่อนลอย เอาเป็นที่เข้าใจง่ายดีกว่า คือคนที่มีเป้าหมายร่วมกันกับทีมจึงจะเหมาะสม ตัวอย่างเช่น ถ้าคนที่ต้องการเป้นหัวหน้าแล้วไม่ต้องทำงานย่อมขัดกับเป้าหมายของทีมที่ทำงานให้มีคุณภาพเพื่อส่วนรวม มันก็ไปกันไม่ได้ แม้ว่าเค้าจะเก่งแค่ไหนก็ตาม หรือบางคนต้องการทำงานคนเดียวไม่สุงสิงกับใคร แต่เป้าหมายของทีมคือทำงานร่วมกันแบบมีปฏิสัมพันธ์ (interaction) เยอะๆ มัีนก็ไปกันไม่ได้ สรุปอไจล์ต้องการทีมเวิร์คมากกว่าแบบโชว์เดี่ยวโดยไม่สนใจว่าจะเก่งมากน้อย ตามภาษาฝรั่งว่า synergy คือหนึ่งบวกหนึ่งแล้วได้มากกว่าสอง ถ้าคนธรรมดาสองคนทำงานร่วมกันมันต้องชนะคนเก่งคนเดียวอยู่แล้่ว หรือถ้าไม่ลองสามสิน่าจะได้

การแบ่งงานทำได้ยาก

อันนี้จริงเสียยิ่งกว่าจริง เพราะเราคุ้นเคยกับการแบ่งงานแบบตามฟังค์ชันเพื่อแจกงานให้ functional team คือ อันนี้ dev ทำ QA ทำ หรือ DBA ทำ พอมาเป็น cross functional team มันต้องแบ่งตาม requirements มันเลยลำบากต้องกลับสมองคิด ต้องทำให้มันทำงานได้ แต่ต้องเล็กพอที่จะบรรจุในสปรินต์ แ่ต่ต้องฝึก อย่าง สมมติ แบ่ง อันที่ทำสำเร็จเป็นหนึ่งงาน แล้ว ก็แบ่ง error แต่ละ case เป็นงานๆ ไป ก็เป็นวิธีหนึ่ง หรือ ถ้าเป็น พวก performance อาจจะแบ่งเป็น 1 user, 2 users, 10 users, 1000, 100000,..etc. โดยไม่ต้องเริ่มมารองรับ 100000 คนเลย มันทำยากกว่ากัน แล้วก็แบ่งได้ โดย ยังได้ working software อยู่ สรุปคือ ยากจริง และต้องฝึกฝน แต่ไม่ใช่ทำไม่ได้เลย

การสร้างทีมนั้นต้องปรับเปลี่ยนตามสถานการณ์

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

สิ่งที่หายากที่สุดในการสร้างอไจล์ทีมคือ Product Owner ที่ดี

อันนี้เถียงไม่ได้เลย เพราะ owner ที่ดีต้องรู้ว่าที่ไว้ใจทีมได้อย่างไร รู้เรื่องธุรกิจอย่างดี และยังต้องสร้าง user story พร้อมทั้งเรียง priority อยู่ตลอดเวลา จึงไม่ง่ายเลยที่จะหาคนๆ นี้ในองค์กรได้ง่ายๆ นี่คือเหตุผลที่เราต้องมี Scrummaster เพื่อคอยเป็นพี่เลี้ยงให้ owner ได้เรียนรู้บทบาทของตัวเองใน scrum โปรเจ็ค

ถ้าย้อนเวลาได้จะยังคงเลือกอย่างที่ได้ทำมาแล้ว

อันนี้มาจากทาง โปรเตอุส ว่านี่คือ indicator ที่สุดยอดที่สุดว่าเราทำงานได้ดีแค่ไหน ถ้า จบงานแล้ว ถามลูกค้าว่าถ้าย้อนเวลาได้อยากเปลี่ยนอะไรแล้วเค้าบอกว่า ไม่ต้องการเปลี่ยนอะไรเลย น่าเอาไปลองถามแฟนพวกเราดูนะ :)

Project Manager เป็นยาเสพติดอย่างนึง

อันนี้เป็นความรู้สึกผมเอง จากที่ฟังๆ หลายคนพูด รู้สึกว่าเราไปหมกมุ่นกับการ manage แล้วก็ตำแหน่ง manager มากเกินไป ตำแหน่งนี้มันเกิดจากในสมัยโบราณ-ยุคปฏิวัติอุตสาหกรรมที่คนงานทั้งหมดเป็นคนไร้การศึกษา จึงต้องหาคนที่มีการศึกษามาควบคุมดูแล เืพื่อให้งานเป็นไปอย่างราบรี่น ดูงานพัฒนาซอฟแวร์ทุกวันนี้เราใช้คนขาดการศึกษาทำเขียนโค้ดรึเปล่า ถ้าเปล่า จะมีตำแหน่งนี้ไปทำไม ตำแน่งนี้เป็นคนขัดขวางงานให้ช้าลงหรือทำให้งานเร็วขึ้นกันแน่ ใน training Scrummaster มี exercise นึงให้ทุกคนจับคู่แบ่งเป็นคนสั่งกับคนทำ โดยคนทำห้ามคิดเอง คนสั่งต้องสั่งเท่านั้นจึงจะทำได้ โดยเป้าหมายคือ ให้เดินให้ได้ 60 ก้าวใน 2 นาที ปรากฏว่าเละ ชนไปชนมา ทำผิดทำถูก แต่พอ เปลี่ยนใหม่ ได้ทุกคนเป็นคนทำ โดยไม่มีคนสั่ง ปรากฏว่าทำได้ง่ายๆ โดยไม่ชนกันเลย นี่คงบอกได้ชัดว่า มี manager กับ manage กันเองอะไรเร็วกว่า

นอกจากมี cross functional team แล้ว ต้องมี Cross functional stakeholders ด้วย

คือ เวลาจบแต่ละสปรินต์ต้องมีการ review กับ stakeholders จะต้องได้มาครบทุกสายงาน ไม่ใช่ คุยแต่กับฝ่ายขาย พอจบโปรเจ็ค ฝ่ายบัญชีบอกไม่ได้อย่างนี้ปิดงบไม่ได้ จบเลย การดิวงานต้องทำให้ได้ครบทุกฝ่าย ถ้าทีมตามไมไ่ด้ ก็ได้เวลาใช้งาน scrummaster หรือ ที่มีคนบอกในเสวนว่า คือตำแหน่ง เบ๊ ของทีม

Waterfall ไม่ได้เลวร้ายอย่างที่คิด

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

Don’t call us, we will call you

ถ้าใครใช้ Spring framwork คงคุ้นกำสโลแกนนี้ อยากบอกว่า มันใช้กับคนได้ด้วยนะ ถ้าคุณทำงานแล้วรู้สึกว่าทำไมเค้าไม่บอกคุณ หรือไม่สื่อสารมา ก็ถามตัวเองว่า เราเอ่ยปากถามเค้าหรือไม่ ให้วางไว้ในใจเลยว่า เป็นหน้าที่เราที่ต้องถาม ไม่ใช่หน้าที่อีกฝ่ายที่ต้องบอกก่อน ถ้าทุกคนทำแบบนี้ information มันจะ flow เป็นพายุเลยทีเดียว ไม่มีคำว่า เื่รื่องเดินช้า หรือกั๊กข้อมูลกันอีกต่อไป ใครล่ะจะไม่อยากให้งานตัวเองเดินเร็วๆ

จะพันจะหมื่น test ก็แค่ไม่กี่วินาที

นี่คือสุดยอด TDD (Test Driven Development) เลย อะไรที่ทำง่ายได้ผลเร็ว เราก็จะทำมันบ่อยๆ อะไรที่ช้าน่าเบื่อเราก็ไม่อยากทำมัน ถ้า unit tests ทำงานช้าอย่าหวังเลยว่า จะได้ผลงานที่ดี ได้ยินอย่างนี้จาก developer แล้ว happy จริงๆ ครับ ส่วนรายละเีอียดต้องไปว่ากันในเรื่องการทำ mock และ TDD เทคนิค ยาวครับ เรื่องนี้

โน้ตผมหมดแค่นี้ไว้โอกาสหน้าผมมารับใช้ใหม่ครับ

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s