ศุกร์ที่ผ่านมามี Meetup เกี่ยวกับ Software Development ที่นี่ซึ่งก็มีเป็นกลุ่มเลย คล้ายๆกับ Opendream ในไทยที่มีจัด Meetup เล่าเรื่องเทคนิคต่างๆในการทำระบบอะไรซักอย่างขึ้นมา เมื่อวานเป็นครั้งที่สองที่ไป Meetup ของที่นี่ แต่ก็ยังไม่คุ้นเคยอยู่ดี (พูดง่ายๆ คือฟังยังไม่ค่อยออก ฮะๆ) แต่ก็พยายามจะสรุปประเด็นที่พอฟังได้มาจดไว้ก่อน Meetup คราวนี้จัดที่บริษัท Odd-e ตอนแรกก็คิดว่าคล้ายๆ Opendream ก็คล้ายจริงๆ นั่นแหละเพียงแต่ว่าพื้นที่น้อยกว่ากันเยอะ และคนที่มาก็มากกว่ากันพอสมควร เรียกว่าแทบจะเข้ามาฟังกันไม่ได้เลยหละ เนื้อหาที่พูดมีให้โหวตกันก่อนหน้านั้นสุดท้ายแล้วมีสองเรื่องคือ Maintainability, Extensibility, Testability กับ ATDD and BDD เรื่องแรก Maintainability, Extensibility, Testability พูดถึงวิธีที่คนพูดใช้ในการทำเรื่องพวกนี้ต่างๆ ส่วนใหญ่จะเน้นไปที่ Aspect-J ว่าเอามาใช้แยก logic การทำงานให้ชัดเจนอย่างไร ทดสอบง่ายอย่างไร และเอา function เข้าและออกง่ายอย่างไร และการแยกแบบนี้มีข้อดีอย่างไร เมื่อแยกส่วนแล้วจะทดสอบยังไร สำหรับคนที่สนใจ Aspect-J ก็คงเหมาะกับ [...]
Process ที่ผ่านไปครึ่งปี
เมื่อวานเห็น @hybridknight ทำ task board แปะกลาง office จริงๆ แถมให้ทีมอื่นเข้าร่วมด้วยให้เห็น process เกือบทั้งหมดเลยอยากจะจดไว้ซักหน่อย เพราะกว่ามันจะออกมาเป็น task board แบบนี้นับจากวันแรกที่เริ่มคิดว่าจะแก้อะไรบางอย่าง ก็ผ่านไปครึ่งปีพอดี วันแรกที่เริ่มทำจำได้ว่าการทำงานทั้งหลายมันต่างจากที่เป็นอยู่ปัจจุบันพอสมควร ยังคิดได้ไม่หมดด้วยและแทบจะไม่ฟังคนอื่นเลย ตอนนั้นคิดอย่างเดียวว่าต้องเปลี่ยนให้ได้ และจะไม่เอา Trac เข้ามายุ่งเกี่ยวเด็ดขาด (พูดง่ายๆ จะกำจัด Tools ทิ้งทั้งหมด ใครทำอะไรให้มาเล่า และ Information วิ่งหาคนแทนเข้าหาเครื่องมือ) หลังๆ พอมันวิ่งไปได้เดือนสองเดือนก็ค่อยๆ คิดถึงการปรับแก้จากของเดิมเอาเข้ามา ที่สำคัญคือช่วงน้ำท่วม เวลาว่างเยอะเลยได้อ่านหนังสือเกี่ยวกับ process พวกนี้เยอะขึ้นด้วย (Kanban, Element of Scrum, …) ก็เลยได้ปรับแก้จนเป็นรูปร่างเหมือนปัจจุบัน สิ่งที่ยังขาดต่อจากนี้ก็คงจะเป็นการคุยกันของสิ่งที่อยู่บนกระดานนี้ จากแต่ก่อน คุยกันเฉพาะภายในทีมเล็กๆ และไม่เป็นเวลาเท่าไหร่ (มาครบทีมปกติก็จะเป็นคนไปไล่ถามเอง ว่าใครทำอะไรบ้างเฉพาะทีมที่ดูแลอยู่ ตอนเย็นทำถึงไหนก็ไล่ถามอีกที) มาถึงตอนนี้อาจจะต้องจัดให้เป็นเวลามากขึ้น และไม่ได้เป็นคนที่ไล่ถามอีกต่อไป การไล่ถามเพื่อจัดการนี่จะยากกว่า Task board [...]
My process goal
ขอจดไว้ก่อนกันตัวเองลืม และก็เพื่อให้ @hybridknight ที่จะรับช่วงต่อด้วย ช่วงสามสี่เดือนที่ผ่านมาได้ทดลอง process การทำงานใหม่บางอย่างที่ก็ขัดกับคนอื่นบ้างแต่ตอนนี้ก็เริ่มลงตัว ตอนเริ่มทำเป้าหมายก็ยังไม่ชัดเท่านี้ด้วย คิดแค่ว่าต้องการให้สิ่งที่ทำสามารถการันตีได้ว่ามันจะไม่พังเมื่อเวลาผ่านไปและมีปัญหาเหมือนระบบเดิมที่เคยทำมา แต่เมื่อสองวันก่อนคุยกับ @visibletrap จนได้ข้อสรุปสามข้อที่มันชัดจนคิดว่านี่แหละคือเป้าหมายที่ตัวเองดันมา ทั้งสามข้อก็ไม่มีอะไรมากแค่ process นี้ต้องทำให้ตรวจสอบความผิดพลาดต่างๆ ได้ง่ายๆ ข้อแรกนี้แก้ด้วยการหาทางให้เขียน test ได้ง่ายๆ รันง่ายๆ process นี้ต้องลด Interrupt ที่แต่ละคนจะเจอขณะทำงานให้มากที่สุด แน่นอนบางอย่างมันต้อง Interrupt เข้ามาได้ (เช่น production server down หรือสอบถามอะไรบางอย่าง) แต่บางอย่างก็ไม่ควรจะเข้ามา Interrupt เช่น QA ไม่ผ่าน หรือการเพิ่ม Feature อะไรบางอย่าง พวกนี้ควรจะจัดเวลาหรือที่ซักที่ให้ไปแปะไว้ แล้วนัดเวลามาดูร่วมกัน อันนี้พยายามดันโดยการให้ทุกคนใช้ task board และกำหนดเวลาตายตัวว่าจะคุยกันช่วงไหน process นี้ต้องทำให้ทุกคนรู้ว่าใครทำอะไรอยู่บ้าง ว่างไม่ว่าง และติดอะไรอยู่ ข้อนี้มีเหตุผลคือ คนจัดงาน รู้ว่าไม่มีใครว่างงาน และไม่จัดงานหนักๆ เพิ่มเข้าไป [...]
Visual or Physical task board
ตอนเริ่มเข้ามาแก้ไข Dev process ใหม่ๆ วิธีที่อยู่ในหัวและได้ยินชื่อมาพอสมควรคือ Scrum ซึ่งมีเครื่องมืออย่างนึงที่เรียกว่า Task board แม้ตอนนี้จะปลื้มและใช้ Kanban มากกว่าแต่ก็มีเครื่องมือเดียวกันคือ Task board ทั้งสองวิธีพูดอย่างนึงตรงกันคือ มันควรจะมีกระดานจริงๆ ที่ให้ทุกคนมาเขียนแปะ ส่วนตัวแล้วไม่ชอบที่จะต้องสร้างกระดานจริงขึ้นมาเท่าไหร่ในที่ทำงานปัจจุบันด้วยเหตุผลว่า คนในทีมแต่ละคน แม้จะอยู่ใน Office เดียวกัน แต่นั่งกันกระจัดกระจายมาก เหมือนอยู่คนละทีม คือไม่สามารถสร้างกระดานที่ทุกคนมองเห็นได้ หรือมาแก้ไขได้สะดวกๆ นั่นเอง เดือนที่แล้วที่น้ำท่วมหนักๆ ทุกคนแยกย้ายกลับต่างจังหวัดกันหมด ถ้าทำกระดานจริงขึ้นมามันคงไร้ประโยชน์มากหรือไม่คนที่คุมก็เหนื่อยมาเพราะต้องคอยถามและแก้ไขตลอด จากเหตุผลสองข้อด้านบนทำให้ไม่ได้สร้างกระดานจริงขึ้นมาใช้งาน แต่ไปสร้าง กระดานเสมือน ขึ้นมาแทนเพื่อให้ทุกคนเข้ามาเห็นได้ง่ายๆ แน่นอนสิ่งที่ขาดไปจากการใช้กระดานแบบนี้คือการสื่อสารที่ลำบากขึ้นเมื่อมีการเปลี่ยนแปลงสถานะของงานที่กระดานจริงจะทำได้ (ทำกระดานจริงคงเอามาไว้ใกล้ตัว แก้ไขทีแต่ละคนคงได้มาคุยตัวต่อตัวก่อนที่จะเปลี่ยนแปลง) เพราะงั้นจะใช้กระดานจริง หรือโปรแกรมที่แสดงงานต่างๆ หรือจะใช้คู่ไปเลยก็ได้ ส่วนตัวแล้วคิดว่ามันขึ้นอยู่กับสภาพแวดล้อมรวมมากกว่า ว่ามันเอื้อแบบไหน และลองแก้ไขตามสิ่งที่อยากได้ดู จะมีกระดานจริงหรือไม่มีก็ได้ ขอแค่ทุกคนต้องคุยกันถึงเหตุการณ์ต่างๆ ที่เกิดขึ้นใน Project แล้วทำให้มันเสร็จได้เร็วที่สุด (จะตามกำหนดหรือไม่นั่นก็อีกเรื่องนึง) จะว่าไปแล้วของจริงที่ทำๆ อยู่จะบอกว่าเป็น Scrum มั้ยก็ไม่เหมือนเป๊ะซักทีเดียว มี Kanban [...]
Kanban
ตอนแรกที่ซื้อเล่มนี้มาคิดว่ามันถูกดี อยากหาอะไรอ่านเล่นไม่คิดอ่านจริงจังเท่าไหร่ อีกอย่างไม่คิดว่ามันจะเกี่ยวกับงานที่ทำด้วย จนช่วงน้ำท่วมซื้อ Kindle มาอ่านหนังสือแก้เซ็ง เลยหยิบเล่มนี้มาอ่านหลังจากกับน้ำท่วม กลายเป็นว่าเล่มนี้เขียนถึงสิ่งที่เคยคิดไว้เกือบทั้งหมดเลย และด้วยราคา version Kindle เพียง 9 usd ก็รู้สึกคุ้มสุดๆจนอ่านจบเกือบอยากจะซื้อฉบับกระดาษมาเลยทีเดียว ติดเพียงอย่างเดียว version กระดาษโคตรแพง หนังสือเล่มนี้พูดถึงวิธีจัดการ Software Project วิธีหนึ่งที่ชื่อว่า Kanban (เห็นหลายที่บอกว่าอ่านว่าคัมบัง) เล่าตั้งแต่ปัญหาของการทำ Software ต่างๆ ในทีมจนมาเป็นวิธีนี้ขึ้นมา และมีวิธีการอย่างไรบ้างเช่น การกำหนดจำนวนงานที่จะรับมาทำ การทำให้ทุกคนรู้ถึงขั้นตอนต่างๆชัดเจนโดยสร้างกระดานขั้นตอนขึ้นมา การเอาไปใช้ในระบบปัจจุบันและตัวอย่างการเอาไปใช้ในที่ต่างๆ ในเล่มก็ยังมีพูดถึง Lean ในระบบสายการผลิตของ Toyota และ Scrum ด้วยก็ได้ยินมานานหละแต่ยังไม่ได้หามาอ่านเสียที หลังอ่านเล่มอื่นๆ ใน Kindle จนหมดว่าจะหาซื้อมาอ่านเพิ่มแล้วเขียนอีกที
Subscribe / Connect
Subscribe to our e-mail newsletter to receive updates.
