เมื่อวานเห็น @hybridknight ทำ task board แปะกลาง office จริงๆ แถมให้ทีมอื่นเข้าร่วมด้วยให้เห็น process เกือบทั้งหมดเลยอยากจะจดไว้ซักหน่อย เพราะกว่ามันจะออกมาเป็น task board แบบนี้นับจากวันแรกที่เริ่มคิดว่าจะแก้อะไรบางอย่าง ก็ผ่านไปครึ่งปีพอดี วันแรกที่เริ่มทำจำได้ว่าการทำงานทั้งหลายมันต่างจากที่เป็นอยู่ปัจจุบันพอสมควร ยังคิดได้ไม่หมดด้วยและแทบจะไม่ฟังคนอื่นเลย ตอนนั้นคิดอย่างเดียวว่าต้องเปลี่ยนให้ได้ และจะไม่เอา Trac เข้ามายุ่งเกี่ยวเด็ดขาด (พูดง่ายๆ จะกำจัด Tools ทิ้งทั้งหมด ใครทำอะไรให้มาเล่า และ Information วิ่งหาคนแทนเข้าหาเครื่องมือ) หลังๆ พอมันวิ่งไปได้เดือนสองเดือนก็ค่อยๆ คิดถึงการปรับแก้จากของเดิมเอาเข้ามา ที่สำคัญคือช่วงน้ำท่วม เวลาว่างเยอะเลยได้อ่านหนังสือเกี่ยวกับ process พวกนี้เยอะขึ้นด้วย (Kanban, Element of Scrum, …) ก็เลยได้ปรับแก้จนเป็นรูปร่างเหมือนปัจจุบัน สิ่งที่ยังขาดต่อจากนี้ก็คงจะเป็นการคุยกันของสิ่งที่อยู่บนกระดานนี้ จากแต่ก่อน คุยกันเฉพาะภายในทีมเล็กๆ และไม่เป็นเวลาเท่าไหร่ (มาครบทีมปกติก็จะเป็นคนไปไล่ถามเอง ว่าใครทำอะไรบ้างเฉพาะทีมที่ดูแลอยู่ ตอนเย็นทำถึงไหนก็ไล่ถามอีกที) มาถึงตอนนี้อาจจะต้องจัดให้เป็นเวลามากขึ้น และไม่ได้เป็นคนที่ไล่ถามอีกต่อไป การไล่ถามเพื่อจัดการนี่จะยากกว่า Task board [...]
Kanban
ตอนแรกที่ซื้อเล่มนี้มาคิดว่ามันถูกดี อยากหาอะไรอ่านเล่นไม่คิดอ่านจริงจังเท่าไหร่ อีกอย่างไม่คิดว่ามันจะเกี่ยวกับงานที่ทำด้วย จนช่วงน้ำท่วมซื้อ Kindle มาอ่านหนังสือแก้เซ็ง เลยหยิบเล่มนี้มาอ่านหลังจากกับน้ำท่วม กลายเป็นว่าเล่มนี้เขียนถึงสิ่งที่เคยคิดไว้เกือบทั้งหมดเลย และด้วยราคา version Kindle เพียง 9 usd ก็รู้สึกคุ้มสุดๆจนอ่านจบเกือบอยากจะซื้อฉบับกระดาษมาเลยทีเดียว ติดเพียงอย่างเดียว version กระดาษโคตรแพง หนังสือเล่มนี้พูดถึงวิธีจัดการ Software Project วิธีหนึ่งที่ชื่อว่า Kanban (เห็นหลายที่บอกว่าอ่านว่าคัมบัง) เล่าตั้งแต่ปัญหาของการทำ Software ต่างๆ ในทีมจนมาเป็นวิธีนี้ขึ้นมา และมีวิธีการอย่างไรบ้างเช่น การกำหนดจำนวนงานที่จะรับมาทำ การทำให้ทุกคนรู้ถึงขั้นตอนต่างๆชัดเจนโดยสร้างกระดานขั้นตอนขึ้นมา การเอาไปใช้ในระบบปัจจุบันและตัวอย่างการเอาไปใช้ในที่ต่างๆ ในเล่มก็ยังมีพูดถึง Lean ในระบบสายการผลิตของ Toyota และ Scrum ด้วยก็ได้ยินมานานหละแต่ยังไม่ได้หามาอ่านเสียที หลังอ่านเล่มอื่นๆ ใน Kindle จนหมดว่าจะหาซื้อมาอ่านเพิ่มแล้วเขียนอีกที
Less behavior, more case
คำเตือน blog นี้เขียนเพื่อบ่นการทำงานโดยเฉพาะ! ช่วงนี้ประชุมเยอะ เลยคิดอะไรได้นิดหน่อยเนื่องจากพยายามจะจำกัดให้ Project ไม่โตเกินไปแต่รู้สึกจะห้ามไม่ได้เท่าไหร่ เคย Tweet ลอยๆว่าจริงๆ ควรทำระบบในรูปแบบกลับด้านจากเผื่อเหลือ ให้เป็นระบบที่ยังขาดบางอย่างอยู่ซะ แต่ก็ไม่ได้คิดต่อว่าเพราะอะไรจนช่วงนี้แหละที่ประชุมรวบรวมว่าระบบต้องทำอะไรบ้างถึงเขียนยาวๆ ได้ เนื่องจากระบบที่ทำอยู่ เป็นระบบที่ใหญ่มากประกอบด้วยการทำงานจากชั้นย่อยๆ หลายๆส่วน มีพฤติกรรมล้านแปดจาก Marketing เมื่อจะเริ่มทำเจ้าของระบบก็เอา Requirement ทั้งหมดมาแปลงเป็น Design ขนาดใหญ่เพื่อให้ระบบทำตาม Requirement/Bahavior ได้ทั้งหมดตั้งแต่เริ่มต้น!!! ซึ่ง Requirement ก็เปลี่ยนแปลงไปมาเพิ่มนู่นนี่จนปัจจุบันก็ยังไม่ได้ Finale design ที่สมบูรณ์พร้อมที่จะให้ Programmer ตาดำๆ ไปเขียนหรือแบ่งส่วนให้ชัดเจนเสียที เพราะรายละเอียดจุกจิกทั้งหลายมักจะโผล่มาจากคนนู้นทีคนนี้ทีจนมันไม่เสร็จ ก็เลยคิดได้ว่า จริงๆแล้วถึงแม้ระบบมันจะใหญ่ขนาดไหนก็ตาม มันควรจะตัด Behavior พื้นฐานแล้วค่อยๆทำก่อน ไม่จำเป็นต้องออกแบบหรือคิดถึง Behavior ทั้งหมด เมื่อได้ชั้นต่างๆ ที่มีหน้าที่ชัดเจน มี test(case) ครอบคลุมแล้วเราถึงค่อยทำ Behavior เพิ่ม การออกแบบก็ไม่ใช่ออกแบบทั้งหมดตั้งแต่ต้น แต่ต้องทำเพื่อให้มันค่อยๆ เพิ่มได้เพราะงั้นสิ่งที่ควรทำจริงๆ คือ [...]
ล้างไพ่
อาบน้ำอยู่ก็คิดถึงวิธีนี้ขึ้นมา คิดว่าไม่ได้ใหม่อะไรแต่มันไม่มีอยู่ในขั้นตอนการทำงานปัจจุบัน แต่น่าจะทำให้ QA กะ Dev ทำงานมีความสุขขึ้นอีกเล็กน้อยเพราะไม่เห็นอะไรยาวเป็นหางว่าวเหมือนปัจจุบัน เริ่มจาก Milstone1 เป็นช่วงที่ปั้นโครงของระบบทั้งหมดว่าหน้าตาจะเป็นอย่างไร Feature หลักเป็นอย่างไรบ้าง เป็นตัวกำหนดว่าสิ่งที่ทำคืออะไร Milestone2 หลังจาก Milestone1 ถูกโยนให้ QA และได้ Feedback มาแล้ว Milestone นี้จะเลือก Feedback บางอย่างมาทำ จากนั้นโยน Feedback ที่เหลือทิ้งทั้งหมด ไม่มีการเอามาจัดคิวใดๆ ทั้งสิ้น Milestone3 ทำเหมือน Milestone2 คือหลังจากได้รับ Feedback จาก QA ก็เลือกแล้วโยนทิ้ง ทำแบบนี้ไปเรื่อยๆ จน Release ไม่มีการเก็บ Feedback ที่ไม่ได้ทำเอาไว้ Feedback ที่ว่าอาจเป็น Bug, Requirement ที่ลิมทำ หรืออะไรก็แล้วแต่ที่ Dev ลืม ที่ทำแบบนี้เพราะว่า Feedback ทั้งหลายที่เก็บไว้เมื่อมันไม่ถูกเลือก [...]
Software Development Team
หลังจากทำงานมาสี่ปี เจอปัญหามามากมาย ได้แก่ Component ต่างๆ ไม่มีใครสามารถเล่าได้ หรือรันให้ดูเป็นส่วนว่ามันทำงานอย่างไร ต้องเข้าไปอ่าน Code แล้วลองรันดูเอง ถึงจะรู้ จะรันโค้ดส่วนต่างๆ ได้ต้อง setup นู่นนี่นั่น ขึ้นมาก่อนถึงจะรัน test ได้ รันแล้วยังคงไม่รู้อยู่ดีว่ามันทำงานยังไง เพราะตอนรันไม่มีคนมาอธิบาย ตอนอธิบายก็คือเป็นการสอนกลุ่มใหญ่ ดูสไลด์เอา บางครั้งถึงกับรันไม่ได้เลย จนเหนื่อยใจเลิกรัน test กันไป เมื่อมีการแก้ไข Component ไม่สามารถรู้ได้ว่าสิ่งที่เพิ่มไป ทำให้ของเก่าพังหรือป่าว ต้องถึงมือ QA ก่อนถึงจะรู้! เมื่อถึงมือ QA แล้วกลับมาแก้ก็ไม่รู้ไปพังส่วนไหนอีก ตอนทำงานพร้อมกันหลายๆ ส่วนแล้วเอามารวมกัน ไม่สามารถรู้ได้ว่าทำให้โค้ดคนอื่นพังป่าว เวลา Merge version ใหญ่ๆ ไม่สามารถบอกได้เลยว่าทุกอย่างยังทำงานถูกต้อง Code แต่ละคนแม้ส่วนใหญ่จะใช้รูปแบบเหมือนกัน แต่เวลามีน้องใหม่เข้ามาทำงาน ไม่มีการบอกกล่าวก็เจอรูปแบบประหลาดไปเต็มๆ เนื่องจาก แก้แล้วแก้อีก เพราะแก้เสร็จก็ทำให้เกิดปัญหาอีกอย่าง ทำให้งานไม่เสร็จซักที ช่วงสองสามเดือนที่ผ่านมา อาการพวกนี้เริ่มเข้าขั้นวิกฤต สามารถแก้แบบปะผุไปล่วงหน้าได้บ้าง [...]
Subscribe / Connect
Subscribe to our e-mail newsletter to receive updates.
