มีโอกาสได้ไปเรียนคอร์ส CSD กับทาง Odd-e Thailand มาครับ เลยมาบันทึกอะไรเก็บไว้หน่อย
CSD ย่อมาจาก Certified Scrum Developer เป็นคอร์สที่มีทั้งนั่งฟัง Lectucre และ Workshop รวมอยู่ด้วยกัน ใช้เวลาทั้งหมด 6 วัน เนื้อหาก็ตามชื่อครับ เกี๋ยวกับ Agile และ Scrum แต่จะเน้นทางด้าน Developer และการทำานร่วมกันเสียมาก (ผมไม่เคยเรียนคอร์สเกี่ยวกับ Scrum master หรือ Product owner นะ แต่เนื้อหามันคงจะต่างกันเยอะอยู่ เอาไว้มีโอกาสคงได้สัมผัส ตอนนี้ต้องหาตังมาจ่ายค่าเรียนก่อนครับ ฮ่ะๆๆ)
สำหรับเนื้อหาในชั้นเรียนไม่ได้มีอะไร surprise เท่าไหร่ (สำหรับผมนะ แต่ถ้าใหม่ๆมาเลยมันจะเหมือนเอาตัวเองเข้าไปอยู่ท่ามกลางพายุดีๆนี่ล่ะครับ ซึ่งคงไม่มีหรอก...มั้ง) ตัวผมก็เคยผ่านค่าย Spartan กับชั้นเรียนมหาสนุกอย่าง Geek academy มาแล้ว แต่พอลองเอามาใช้กับงานจริงๆมันก็ไม่ได้เป็นอย่างที่ฝันไว้เท่าไหร่ กิจกรรมหรือpracticeบางอย่างก็ทำบางอย่างก็ไม่ หลายตัวที่ไปเรียนมาแล้วก็ขายไม่ออก ผมจึงอยากรู้ว่าที่เขาทำกันจริงๆน่ะ มันเป็นยังไง
เนื้อหาคร่าวๆในชั้นเรียน
- Hyper productivity
- Introduction to Agile & Scrum
- Unit test
- Collective ownership
- Code smell
- Mocking
- Robot framework
- ฯลฯ
ส่วนใหญ่จะได้เรียนไปแล้วใน Geek academy และค่าย Spartan นะครับ ถ้าไม่เคยเรียนก็ไปเรียนกันนะ
ระหว่างเรียนเราก็จะต้องทำ Product สุดเมพขึ้นมา 1 ตัว กับทีมที่ไม่เคยทำงานร่วมกันมาก่อน ภายในเวลา 5 วัน ระหว่างทางเราก็พบกับปัญหาเต็มไปหมด ทั้งปัญหาจริงๆ ทั้งวางกับดักกันเอง กระทั่งผู้สอนวางให้ แต่ก็ส่งงานได้ในวันสุดท้ายนะครับ :)
ในชั้นเรียนนี้เราจะมีครบ ทั้ง ทีม, Product owner, Scrum master และ Technical coach (บางทีก็มาช่วย บางที่ก็มาวางยา 555) อะไรที่ทำไม่ได้หรือไม่ได้ทำในที่ทำงาน ลองมาที่นี่ครับ ได้ทำทุกกิจกรรมจริงๆ
ทำให้ผมเข้าใจเลยว่า Scrum master กับ Product owner มันมีความจำเป็นจริงๆ ไม่ใช่ว่านึกจะอุปโลกน์ใครขึ้นมาเป็น หรือ ไม่มีเลยได้
การมี Scrum master ทำให้เรามีกิจกรรมที่ไม่ได้ทำที่ทำงานอย่างเช่น การกำหนด Working agreement การเปลี่ยนคู่ Pair ทุกชั่วโมง อ้อ รวมไปถึงการทำ Pair programming ด้วยนะครับ ยากมากเลยนะเวลาจะเอาไปใช้ในที่ทำงาน แรงต้านเยอะมาก แต่ในชั้นเรียนนี้เราจะแพร์มันทุกๆอย่าง กระทั่งการติดตั้งweb server หรือJenkins เขียนATDDด้วย Robot framework แต่จนจบคอร์สผมก้ยังแพร์ได้ไม่ครบทุกคนอยู่ดี น่าเสียดายนัก
พูดถึงเรื่อง Pair หน่อย ปกติแล้ว เวลาเราทำงานอะไรอยู่ เราก็จะปล่อยให้ตัวเองจมดิ่งลงไปในตัวงานนั้น ถ้ามีใครมาบอกให้หยุดหรือขัดจังหวะเราก็หงุดหงิด ก็อยากจะทำงานของเราต่อไป ผมคิดว่านี่เป็นสาเหตุที่หลายๆทีมล้มเหลวนะ เพราะเราก็ไม่ค่อยอยากจะขัดใจเพื่อนพอนานๆไป เราก็เลิกไปเองโดยปริยาย Scrum master ต้องมีไว้เพื่อเหตุนี้แหละครับ คอยบอกกับทีมว่า เฮ้ย พวกแกทำข้อตกลงอะไรกันไว้ ลืมแล้วป่าว ช่วงแรกก็ฝืนๆหน่อย ที่จะต้องทิ้งงานที่ทำอยู่ไป แต่ช่วงกลางถึงท้ายของคอร์ส เราก็ชินกับมันแล้วก็เปลี่ยนคู่กันเองได้เลยครับ เวลาติดปัญหาหรือresearchได้หรือไม่ได้ก็ให้ทีมมาร่วมรับรู้(มีกระดิ่งวิเศษหนึ่งอัน พอดังแล้วทุกคนต้องหยุดงานแล้วมาดู มีอยู่ใน Working agreement ด้วย)
ยังมีเรื่องที่ประทับใจอีกครับ อย่างเช่นการได้solutionจากเพื่อนร่วมทีมที่เราไม่รู้หรือไม่เคยคิดถึงมันมาก่อน การเอาปัญหามาแชร์กับทีมมันไม่ได้เป็นเรื่องเสียเวลาเลยครับ ถ้าเรานั่งอมมันเอาไว้ อาจจะเสีย feature ที่เราจะ release ใน sprint นั้นไปเลยก็ได้
แล้วก็การได้pairกับระดับปรมาจารย์อย่างSteven Mak(ผู้สอนท่านหนึ่ง เป็นคนฮ่องกง)นี่มันช่วยเปิดหูเปิดตาเราได้มากจริงๆ อย่างเช่นการมีอยู่ของ Getter,Setter ถ้ามันไม่มี test ที่เรียกใช้มันก็ลบทิ้งไปซะ เป็นต้น รู้สึกว่าเรานี่ยังห่างไกลกับเค้าอีกหลายล้านปีแสงเลย แต่ไม่ได้ทำให้หมดกำลังใจนะครับ กลับกันเลย เหมือนทางที่ต้องเดินต่อไปข้างหน้ามองเห็นได้ชัดขึ้นมากกว่า
แล้วก็การทำ Code review ที่แท้จริง ผมเรียกอย่างนี้ก็แล้วกันนะ เพราะที่เคยทำมามันไม่ได้เป้นแบบในชั้นเรียนเลย บรรยากาศมันผิดกัดลิบลับ ตรงนี้จะนำไปปรับใช้ในทีมแน่นอน
เรื่องเพื่อนร่วมชั้นนี่ก็เกรียนกันดีมากครับ ผมอยากจะทำ Product กับทีมนี้ต่อไปเลย แถมยังได้เป็นเพื่อนร่วมชั้นกับพี่หนุ่ม อันนี้ผมรู้สึกเป็นเกียรติมาก ปกติแล้วเคยเป็นแต่นักเรียนของพี่เขาน่ะ 555
เรื่องที่ไม่่ค่อยพอใจก็มีอยู่บ้าง เช่นการพยายามจะไม่เป็น Hero แต่ก็อดไม่ได้ อันนี้ไม่ได้อวยตัวเองนะครับ แต่ผมหมายถึงอาการแบบเห็นคนอื่นทำไม่ได้ ก็เลยเข้าไปทำเองอะไรเงี้ย บางทีก็ทำไม่ได้ ก็ติดเหมือนกันอย่างเช่นวันแรกๆที่ต้องทำ Jenkins ก็นังทำไปทั้งวัน มาวันสุดท้าย เมล์ยังส่งไม่ได้เหรอ มาผมลุยเอง แอบ Hardcode อีกตะหาก ดีนะวันสุดท้ายไม่มี code review แบบนี้น่ะครับ บางทีแอบนั่งว่างก็มี :(
แล้วก็ระหว่างทางไม่ได้เอางานให้ PO ดูเลยซักกะนิด (ไม่ค่อยจะอยู่ด้วยแหละ อันนี้ถือว่าแบ่งๆกันไปนะครับ ฮ่าๆ)
อ้อ แล้วก็การทีทีมตกลงใช้ Netbeans ด้วยครับ ที่ทีมเราตกลงใช้ Netbeans ในตอนแรกเนี่ย เพราะเชื่อว่ามันจะมี Web server อย่าง tomcat มาให้ครับ ซึ่งปรากฏว่าไม่มี สุดท้ายก็ต้องมาลงกันเองอยู่ดี เจอปัญเรื่อง Maven เรื่อ Java path/version อีกตะหาก แต่ก็ผ่านมาได้นะ ทีมเราเทพ อิอิ
มีเรื่องที่ข้ามไปอีกนะครับ เช่นเรื่องที่เรากินกันตลอดเวลา, มุขแป๊กของคุณแอร์ หรือ commit น้อยไปมั้ย ฯลฯ แต่หมดแรงแล้ว เอาเป็นว่าถ้ามีโอกาสก็ลองมาเรียนดูครับ แค่ได้มาลองทำ Practice ทั้งหลายที่อาจจะทำไม่ได้ในที่ทำงานเราก็คุ้มแล้วครับ
สวัสดีครับ -/\-
Tuesday, April 15, 2014
Saturday, March 29, 2014
Review: Kanban 101 by Kamon&Kulawat (4)
Part สุดท้ายของชั้นเรียนนี้คือเกมที่เรียกว่า Kanbanopoly
ก่อนอื่นให้จับกลุ่มตามนี้
Customer(ลูกค้าผู้น่ารัก) 4 คน
PO 1 คน
DEV 4 คน ทำงานเป็น Pair
QA 2 คน
Ops 2 คน
พอเริ่มก็ให้ ลูกค้าทุกคนช่วยกันเขียน feature ขึ้นมา 10 ชิ้นลงบน Post-it ( เราจะทำ Selfie app กัน)
จากนั้น มีการกำหนดให้ลูกค้าทุกคนมีเงินอยู่ในมือคนละสองล้าน(หรือสามล้าน จำไม่ได้) ให้เลือกว่าจะลงทุนกับ feature ไหนมากที่สุด
แล้วก็เรียกทุกคนมาประเมินขนาดของแต่ละ feature (เจอการ์ดนึงประมาณคลิกเดียวทำให้เสร็จทุกอย่าง Epic มาก แล้วลูกค้าอยากให้ทำมากที่สุดด้วย แต่ละท่านสวมบทบาทเป็นลูกค้าได้แนบเนียนมาก อินเนอร์สุดๆอ่ะ)
เสร็จมามากำหนด WIP ของแต่ละทีม แล้วก็เขียนลงในบอร์ด หน้าตาประมาณนี้...มั้ง
วันแรก PO เอาของเข้า จบวันแรก
วันที่ 2 Dev เอางานไปทำ ที่เอาเข้าได้แค่ 2 ชิ้นเพราะกำหนดให้ทำงานเป็น pair ซึ่งทีม Dev มี 4 คนก็ได้2คู่ คนอื่นงานยังไม่ถึง เลยไม่ต้องทำอะไร จบไปอีกวัน
วันที่ 3 เริ่มมีการเอางานไปทำแล้ว PO จึงเอางานเข้าไปเพิ่ม Dev จะเริ่มทำงาน
การทำงานก็คือการทอยลูกเต๋า หน้าที่ออกคือสิ่งที่ทำได้ในแต่ละวัน
ก็จะมีเหตุการณ์ต่างๆเช่น
- 1 แต้ม = วันนี้ Productive ดีมาก งานเสร็จหมด ก็เลื่อนงานได้
- 2 แต้ม = แฟนบอกเลิก เขียนโค้ดไม่ออกซักกะตัว ก็ยังเลื่อนงานไม่ได้
ประมาณเนี้ยอ่ะครับ ผมจำของจริงไม่ได้หรอก แหะๆ
กลับมาต่อที่เกม สมมติว่าฟลุคมากทอยได้ 1 แต้มทั้งสองคู่เลย Dev ก็สามารถเลื่อนงานของตัวเองไปไว้ที่ช่องทางขวาได้ เพื่อแสดงว่า "เสร็จแล้วนะ" ให้ทีม QA สามารถรับงานไปทำได้ในวันถัดไป
วันที่ 4 เริ่มมีช่องว่างแล้ว PO จึงเอางานใส่เข้าไปได้อีก Dev ก็เอางานใหม่มาทำต่อได้ และ QA ก็รับงานไปทำได้
วันที่ 5 ทีม Dev และทีมQAผ่านฉลุยเหมือนกันงานก็จะไปรอให้ Ops เอาไป deploy ( QA ก็ทำงานโดยการทอยลูกเต๋าเหมือนกัน )
พอจะเข้าใจแล้วใช่มั้ยฮะ ถ้างานมันผ่านง่ายๆ เราคงไม่ต้องมาคิดหาวิธีแก้ปัญหากันหรอกเนอะ
เราเล่นกันต่อแล้วพบว่าปัญหามันเริ่มจะเกิด เมื่อทำงานไม่เสร็จ (ทอยเต๋าได้ผลลัพธ์ที่แย่ ซึ่งเกมนี้ออกแบบให้ผลลัพธ์ที่แย่มีโอกาสออกมากกว่าผลลัพธ์ที่ดี ชีวิตจริงสุดๆ)
เกมเปิดโอกาสให้เราได้แก้ปัญหานี้โดยที่แต่ละทีมสามารถเข้าไปช่วยเหลือคนที่ติดปัญหาอยู่ได้ เพื่อเพิ่มโอกาสในการทำงานเสร็จให้มีมากขึ้น (เลือกทำรอบละ 1 อย่างนะครับ เอางานเข้า, ทำงานของตัวเอง หรือ ไปช่วยคนอื่น) เกมก็เริ่มสนุกมากขึ้น รอบหลังๆ PO กับลูกค้า เค้าคงเห็นว่างานมันไม่ไปไหนซักที (น่าจะเป็นผลจากการ Visualize) ก็เลยเข้ามาช่วยด้วย สนุกสนานมาก กว่าจะทำงานให้เสร็จได้หมด เล่นกันอยู่เป็นชั่วโมง
ในการทำงานจริง เราอาจจะไม่มีความรู้ที่จะเข้าไปช่วย ให้เลือกเอาว่าจะนั่งว่าง (งานเต็ม wip อยู่) หรือไปซื้อกาแฟ หรือเข้าไปมุง เข้าไปแพร์ ฯลฯ ให้ไปลองหาคำตอบของเราเองครับ
ผมอาจจะบรรยายถึงความยอดเยี่ยมได้ไม่ดีนัก แต่นี่คือไม้เด็ดของชั้นเรียนนี้ครับ
เพิ่มอีกหน่อย card ไม่สามารถดึงถอยหลังได้นะครับ อย่างเช่น ถ้า test ไม่ผ่าน ก็ต้องไปตามโปรแกรมเมอร์มาทำให้มันผ่าน ไม่ใช่ส่งกลับไปอยู่ในเลน develop
ก่อนอื่นให้จับกลุ่มตามนี้
Customer(ลูกค้าผู้น่ารัก) 4 คน
PO 1 คน
DEV 4 คน ทำงานเป็น Pair
QA 2 คน
Ops 2 คน
พอเริ่มก็ให้ ลูกค้าทุกคนช่วยกันเขียน feature ขึ้นมา 10 ชิ้นลงบน Post-it ( เราจะทำ Selfie app กัน)
จากนั้น มีการกำหนดให้ลูกค้าทุกคนมีเงินอยู่ในมือคนละสองล้าน(หรือสามล้าน จำไม่ได้) ให้เลือกว่าจะลงทุนกับ feature ไหนมากที่สุด
แล้วก็เรียกทุกคนมาประเมินขนาดของแต่ละ feature (เจอการ์ดนึงประมาณคลิกเดียวทำให้เสร็จทุกอย่าง Epic มาก แล้วลูกค้าอยากให้ทำมากที่สุดด้วย แต่ละท่านสวมบทบาทเป็นลูกค้าได้แนบเนียนมาก อินเนอร์สุดๆอ่ะ)
เสร็จมามากำหนด WIP ของแต่ละทีม แล้วก็เขียนลงในบอร์ด หน้าตาประมาณนี้...มั้ง
วันแรก PO เอาของเข้า จบวันแรก
วันที่ 2 Dev เอางานไปทำ ที่เอาเข้าได้แค่ 2 ชิ้นเพราะกำหนดให้ทำงานเป็น pair ซึ่งทีม Dev มี 4 คนก็ได้2คู่ คนอื่นงานยังไม่ถึง เลยไม่ต้องทำอะไร จบไปอีกวัน
วันที่ 3 เริ่มมีการเอางานไปทำแล้ว PO จึงเอางานเข้าไปเพิ่ม Dev จะเริ่มทำงาน
การทำงานก็คือการทอยลูกเต๋า หน้าที่ออกคือสิ่งที่ทำได้ในแต่ละวัน
ก็จะมีเหตุการณ์ต่างๆเช่น
- 1 แต้ม = วันนี้ Productive ดีมาก งานเสร็จหมด ก็เลื่อนงานได้
- 2 แต้ม = แฟนบอกเลิก เขียนโค้ดไม่ออกซักกะตัว ก็ยังเลื่อนงานไม่ได้
ประมาณเนี้ยอ่ะครับ ผมจำของจริงไม่ได้หรอก แหะๆ
กลับมาต่อที่เกม สมมติว่าฟลุคมากทอยได้ 1 แต้มทั้งสองคู่เลย Dev ก็สามารถเลื่อนงานของตัวเองไปไว้ที่ช่องทางขวาได้ เพื่อแสดงว่า "เสร็จแล้วนะ" ให้ทีม QA สามารถรับงานไปทำได้ในวันถัดไป
วันที่ 5 ทีม Dev และทีมQAผ่านฉลุยเหมือนกันงานก็จะไปรอให้ Ops เอาไป deploy ( QA ก็ทำงานโดยการทอยลูกเต๋าเหมือนกัน )
เราเล่นกันต่อแล้วพบว่าปัญหามันเริ่มจะเกิด เมื่อทำงานไม่เสร็จ (ทอยเต๋าได้ผลลัพธ์ที่แย่ ซึ่งเกมนี้ออกแบบให้ผลลัพธ์ที่แย่มีโอกาสออกมากกว่าผลลัพธ์ที่ดี ชีวิตจริงสุดๆ)
เกมเปิดโอกาสให้เราได้แก้ปัญหานี้โดยที่แต่ละทีมสามารถเข้าไปช่วยเหลือคนที่ติดปัญหาอยู่ได้ เพื่อเพิ่มโอกาสในการทำงานเสร็จให้มีมากขึ้น (เลือกทำรอบละ 1 อย่างนะครับ เอางานเข้า, ทำงานของตัวเอง หรือ ไปช่วยคนอื่น) เกมก็เริ่มสนุกมากขึ้น รอบหลังๆ PO กับลูกค้า เค้าคงเห็นว่างานมันไม่ไปไหนซักที (น่าจะเป็นผลจากการ Visualize) ก็เลยเข้ามาช่วยด้วย สนุกสนานมาก กว่าจะทำงานให้เสร็จได้หมด เล่นกันอยู่เป็นชั่วโมง
ในการทำงานจริง เราอาจจะไม่มีความรู้ที่จะเข้าไปช่วย ให้เลือกเอาว่าจะนั่งว่าง (งานเต็ม wip อยู่) หรือไปซื้อกาแฟ หรือเข้าไปมุง เข้าไปแพร์ ฯลฯ ให้ไปลองหาคำตอบของเราเองครับ
ผมอาจจะบรรยายถึงความยอดเยี่ยมได้ไม่ดีนัก แต่นี่คือไม้เด็ดของชั้นเรียนนี้ครับ
เพิ่มอีกหน่อย card ไม่สามารถดึงถอยหลังได้นะครับ อย่างเช่น ถ้า test ไม่ผ่าน ก็ต้องไปตามโปรแกรมเมอร์มาทำให้มันผ่าน ไม่ใช่ส่งกลับไปอยู่ในเลน develop
Friday, March 21, 2014
Review Kanban 101 by Kamon&Kulawat (3)
พอกินข้าวเที่ยงเสร็จเราก็กลับมาเรียนกันต่อ แต่ก่อนที่จะเริ่มเรียนนั้น ยังมีเกมให้เราเล่นอีกเกมหนึ่งครับ
ชื่อว่า Kiss game
ก็แบ่งคนออกเป็นสองทีม และให้แต่ละทีมส่งตัวแทนออกมาเล่นเกมทีมละ 1 คน
เกมนี้จะมี ช็อกโกแลตยี่ห้อ Kiss เป็นรางวัล (มันเลยชื่อ Kiss game)
ก่อนเริ่มให้ตัวแทนของแต่ละทีมเอามือมาประสานกัน
กติกามีอยู่สามข้อ
- ทำให้หลังมือฝ่ายตรงข้ามแตะพื้น ได้รับ Kiss 1 อัน
- จำไม่ได้
- More kiss win
ผมคิดว่าหลายๆคนก็คงเดาจุดประสงค์ของเกมนี้ได้อยู่แล้วล่ะนะ แต่ก็จะขอลองไฝว้สักหน่อยอยู่ดี อย่างกับในหนังสือการ์ตูนแน่ะ ต้องขอแสดงพลังหน่อยนึง แล้วค่อยคุยกัน
เกมนี้ก็คืออยากจะบอกเราว่า พวกแกจะบ้าพลังงัดข้อกันไปทำไม ผลัดกันเอามือแตะพื้นโต๊ะไม่ดีกว่ารึ ได้กิน kiss กันทุก เปรียบเทียบกับการทำงาน ทำไมเราต้องไปคอยงัดข้อกับคนโน้นคนนี้ แทนที่จะร่วมมือกันทำงานให้มันเสร็จ
แต่มันแป๊กไปหน่อยนะฮะ ช็อกโกแล็ตผมก้ไม่ค่อยอยากแย่งชิงเท่าไหร่ ถ้าเป็นบ้านพร้อมที่ดินอาจจะโอเค :)
ทีนี้เข้าสู้เนื้อหา TPS ( Toyota product system )
คือเรารู้อยู่แล้วล่ะว่า Kanban มันมีที่มาจากกระบวนการของ Toyota แต่มันเป็นยังไงอ่ะ เราก็ยังไม่รู้ คุณกรก็เลยพาเราไปรู้จักกับมัน เนื้อหาค่อนข้าง Abstract และเอามาใช้กับ Software ได้ยาก ก็มีการถามคำถามเพื่อ map กลับไปยังการพัฒนา software อยู่เรื่อยๆ
ผมจดอันที่น่าสนใจไว้บ้าง เช่น
- เชื่อถือคนที่อยู่หน้างาน มากกว่า
- continuous improvment
- นำเสนอไอเดียกลับไปยังฝ่ายผู้บริหารได้
- Challenge ทำเร็ว ผิดเร็ว เชิดชูคนที่กล้าทำผิด
- ใครๆก็สามารถหยุดไลน์การผลิตได้ (ภารโรง แม่บ้าน ก็กดปุ่มหยุดได้นะ แล้วก็เรียกผู้เชียวชาญมาดู)
- ความสูญเปล่า 7 ประการ ไม่ใช่เป้าหมาย
- พูดถึง TPS มันจะขาดรูปนี้ไปไม่ได้
-Just in time คือการผลิตสิ่งที่ลูกค้าต้องการตามเวลาและมีของเหลือในคลังน้อยที่สุด ข้างในมันจะมีเรื่ิ่งเกี่ยวกับ Pull system, Takt time ย่อยลงไปอีก ต้องไปหาอ่านละเอียดๆอีกทีนะ
- Jidohka เป็นการควบคุมคุณภาพรูปแบบหนึ่ง มีคำหนึ่งที่น่าสนใจคือ Autonomation หมายถึงกระบวนการที่ใช้เครื่องจักร์ทำงานและมีคนเข้ามาร่วมด้วยในบางอย่าง ที่มาของมันคือ เครื่องทอผ้า ซึ่งมันก็ทำหน้าที่ของมันได้ดี แต่เวลาด้ายขาด มันต่อเองไม่ได้ ต้องให้คนไปต่อให้ ถ้าเป็น Software ก็หมายถึงการทดสอบบางอย่างก็ยัง Automate ไม่ได้ ต้องเอาคนมาทดสอบ
- Kaizen หมายถึงการเปลี่ยนแปลง (ให้ดีขึ้น)
- plan > do > check > act
ตรงนี้รู้สึกว่าไม่ค่อยได้อะไรเป็นชิ้นเป็นอันเลยแฮะ เนื้อหาส่วนนี้มันค่อนข้างจะ Abstract นะครับเลยหลุดๆไป
ข้ามมาเรื่อง 5ส เลยดีกว่า อันที่จริงก็รู้จักอยู่แล้ว ได้ยินมาจนเอียน (แต่ทำมั้ย ไม่ 555) แต่คุณกรบอกว่าบ้านเรารับเข้ามา แต่ดันเอามาทำให้มันแย่ พวกเราจึงได้รู้จักกับ 5ส ที่แท้จริง
เกม 5ส
เกมนี้ไม่ต้องแบ่งทีม ได้เล่นกับทุกคน โดยให้เรารับบทเป็นบริษัทจัดหาตัวเลข งานของเราคือการหาตัวเลขในกระดาษ ตั้งแต่ 1-49 ตามลำดับ
ซึ่งทุกคนจะได้รับกระดาษคนละแผ่น ก็คือให้เราขีดตัวเลขตั้งแต่ 1-49 ไปตามลำดับในแผ่นนี้แหละ โดยข้อมูลในกระดาษจะเป็นแบบนี้
ผมหาได้แค่ 1-11 เท่านั้น บางคนก็หาได้เยอะนะ เสร็จรอบแรก ให้ลองนึกหาสาเหตุดุว่าทำไมได้น้อย วิธีการทำงานเราผิดพลาดหรือเปล่า ก่อนจะเริ่มรอบต่อไป โดยคราวนี้มีการทำ 5ส ข้อแรก นั่นคือการสะสาง
เราก็ได้รับกระดาษแผ่นใหม่ที่ด้รับการ"สะสาง(seiri)"เรียบร้อยแล้ว โดยการนำตัวเลขที่ไม่ใช่เป้าหมายของเราออกไปซะ
บร๊ะเจ้า! ทำงานง่ายขึ้นเลยมั้ย แต่มันก็ยังดูมั่วๆอยู่ดีป่ะ งั้นมาดูข้อต่อไปกัน ข้อที่ 2 คือ "สะดวก(seiton)" โดยการตีกรอบเข้าไปแบบนี้
เริ่มจะมองเห็นเป็น Pattern แล้วครับ ข้อสุดท้ายเราข้ามไปที่ ส ตัวสุดท้ายกันเลยคือ Standardize (ภาษาไทยแปลว่า สุขลักษณะ ซึ่งไม่ใช่ละ) โดยการเอาตัวเลขมาเรียงกันใหม่ให้มันดูง่ายๆแบบนี้
สุดท้ายคือ sustain คือการทำให้เป็นนิสัย ทำทีละนิด แต่ทำบ่อยๆ
(ทำไมผมนึกถึง Clean code ก็ไม่รู้แฮะ หรือผมคิดไปเอง?)
คราวหน้าเป็นหมัดเด็ดของชั้นเรียนนี้เลยก็ว่าได้ครับ กับเกม Kanbanopoly
ชื่อว่า Kiss game
ก็แบ่งคนออกเป็นสองทีม และให้แต่ละทีมส่งตัวแทนออกมาเล่นเกมทีมละ 1 คน
เกมนี้จะมี ช็อกโกแลตยี่ห้อ Kiss เป็นรางวัล (มันเลยชื่อ Kiss game)
ก่อนเริ่มให้ตัวแทนของแต่ละทีมเอามือมาประสานกัน
กติกามีอยู่สามข้อ
- ทำให้หลังมือฝ่ายตรงข้ามแตะพื้น ได้รับ Kiss 1 อัน
- จำไม่ได้
- More kiss win
ผมคิดว่าหลายๆคนก็คงเดาจุดประสงค์ของเกมนี้ได้อยู่แล้วล่ะนะ แต่ก็จะขอลองไฝว้สักหน่อยอยู่ดี อย่างกับในหนังสือการ์ตูนแน่ะ ต้องขอแสดงพลังหน่อยนึง แล้วค่อยคุยกัน
เกมนี้ก็คืออยากจะบอกเราว่า พวกแกจะบ้าพลังงัดข้อกันไปทำไม ผลัดกันเอามือแตะพื้นโต๊ะไม่ดีกว่ารึ ได้กิน kiss กันทุก เปรียบเทียบกับการทำงาน ทำไมเราต้องไปคอยงัดข้อกับคนโน้นคนนี้ แทนที่จะร่วมมือกันทำงานให้มันเสร็จ
แต่มันแป๊กไปหน่อยนะฮะ ช็อกโกแล็ตผมก้ไม่ค่อยอยากแย่งชิงเท่าไหร่ ถ้าเป็นบ้านพร้อมที่ดินอาจจะโอเค :)
ทีนี้เข้าสู้เนื้อหา TPS ( Toyota product system )
คือเรารู้อยู่แล้วล่ะว่า Kanban มันมีที่มาจากกระบวนการของ Toyota แต่มันเป็นยังไงอ่ะ เราก็ยังไม่รู้ คุณกรก็เลยพาเราไปรู้จักกับมัน เนื้อหาค่อนข้าง Abstract และเอามาใช้กับ Software ได้ยาก ก็มีการถามคำถามเพื่อ map กลับไปยังการพัฒนา software อยู่เรื่อยๆ
ผมจดอันที่น่าสนใจไว้บ้าง เช่น
- เชื่อถือคนที่อยู่หน้างาน มากกว่า
- continuous improvment
- นำเสนอไอเดียกลับไปยังฝ่ายผู้บริหารได้
- Challenge ทำเร็ว ผิดเร็ว เชิดชูคนที่กล้าทำผิด
- ใครๆก็สามารถหยุดไลน์การผลิตได้ (ภารโรง แม่บ้าน ก็กดปุ่มหยุดได้นะ แล้วก็เรียกผู้เชียวชาญมาดู)
- ความสูญเปล่า 7 ประการ ไม่ใช่เป้าหมาย
- พูดถึง TPS มันจะขาดรูปนี้ไปไม่ได้
- Jidohka เป็นการควบคุมคุณภาพรูปแบบหนึ่ง มีคำหนึ่งที่น่าสนใจคือ Autonomation หมายถึงกระบวนการที่ใช้เครื่องจักร์ทำงานและมีคนเข้ามาร่วมด้วยในบางอย่าง ที่มาของมันคือ เครื่องทอผ้า ซึ่งมันก็ทำหน้าที่ของมันได้ดี แต่เวลาด้ายขาด มันต่อเองไม่ได้ ต้องให้คนไปต่อให้ ถ้าเป็น Software ก็หมายถึงการทดสอบบางอย่างก็ยัง Automate ไม่ได้ ต้องเอาคนมาทดสอบ
- Kaizen หมายถึงการเปลี่ยนแปลง (ให้ดีขึ้น)
- plan > do > check > act
ตรงนี้รู้สึกว่าไม่ค่อยได้อะไรเป็นชิ้นเป็นอันเลยแฮะ เนื้อหาส่วนนี้มันค่อนข้างจะ Abstract นะครับเลยหลุดๆไป
ข้ามมาเรื่อง 5ส เลยดีกว่า อันที่จริงก็รู้จักอยู่แล้ว ได้ยินมาจนเอียน (แต่ทำมั้ย ไม่ 555) แต่คุณกรบอกว่าบ้านเรารับเข้ามา แต่ดันเอามาทำให้มันแย่ พวกเราจึงได้รู้จักกับ 5ส ที่แท้จริง
เกม 5ส
เกมนี้ไม่ต้องแบ่งทีม ได้เล่นกับทุกคน โดยให้เรารับบทเป็นบริษัทจัดหาตัวเลข งานของเราคือการหาตัวเลขในกระดาษ ตั้งแต่ 1-49 ตามลำดับ
ซึ่งทุกคนจะได้รับกระดาษคนละแผ่น ก็คือให้เราขีดตัวเลขตั้งแต่ 1-49 ไปตามลำดับในแผ่นนี้แหละ โดยข้อมูลในกระดาษจะเป็นแบบนี้
ผมหาได้แค่ 1-11 เท่านั้น บางคนก็หาได้เยอะนะ เสร็จรอบแรก ให้ลองนึกหาสาเหตุดุว่าทำไมได้น้อย วิธีการทำงานเราผิดพลาดหรือเปล่า ก่อนจะเริ่มรอบต่อไป โดยคราวนี้มีการทำ 5ส ข้อแรก นั่นคือการสะสาง
เราก็ได้รับกระดาษแผ่นใหม่ที่ด้รับการ"สะสาง(seiri)"เรียบร้อยแล้ว โดยการนำตัวเลขที่ไม่ใช่เป้าหมายของเราออกไปซะ
บร๊ะเจ้า! ทำงานง่ายขึ้นเลยมั้ย แต่มันก็ยังดูมั่วๆอยู่ดีป่ะ งั้นมาดูข้อต่อไปกัน ข้อที่ 2 คือ "สะดวก(seiton)" โดยการตีกรอบเข้าไปแบบนี้
เริ่มจะมองเห็นเป็น Pattern แล้วครับ ข้อสุดท้ายเราข้ามไปที่ ส ตัวสุดท้ายกันเลยคือ Standardize (ภาษาไทยแปลว่า สุขลักษณะ ซึ่งไม่ใช่ละ) โดยการเอาตัวเลขมาเรียงกันใหม่ให้มันดูง่ายๆแบบนี้
สุดท้ายคือ sustain คือการทำให้เป็นนิสัย ทำทีละนิด แต่ทำบ่อยๆ
(ทำไมผมนึกถึง Clean code ก็ไม่รู้แฮะ หรือผมคิดไปเอง?)
คราวหน้าเป็นหมัดเด็ดของชั้นเรียนนี้เลยก็ว่าได้ครับ กับเกม Kanbanopoly
Wednesday, March 19, 2014
Review: Kanban 101 by Kamon&Kulawat (2)
มาต่อกันในส่วนของการบรรยายเกี๋ยวกับ Kanban
เริ่มกันตั้งแต่จุดกำเนิดของมัน ให้กำเนิดโดย David Anderson ชือเดิมคือ Lean software development แต่ชื่อ Kanban ขายดีกว่า โดยสาเหตุแกต้องคิด Kanban ออกมาก็คือ เขาเอา Agile ไปใช้กับทีมหนึ่งแล้วมันได้ผล แต่พอเอาไปใช้กับทีมอื่นแล้วมันไม่ได้ผล
สาเหตุสำคัญอย่างหนึ่งคือมันมี "แรงต้าน"
ก็เลยไปคิดวิธีทำ Agile ยังไงให้มันไม่เกิดแรงต้าน มองไปมองมาก็ไปเจอกับวิธีการของ Toyota แล้วก็เกิดไอเดียว่า มันน่าจะเอามาใช้กับการทำ software ได้นะ
แล้วก็เริ่มจากการคุยกัน Community เล็กๆ จนกระทั่งเปิดตัวออกมาเป็น Kanban ในที่สุด
เพิ่งจะมีหนังสือออกมาในปี 2010 นี่เองครับไปดูได้ ที่นี่
มี Principle 4 ข้อ
มาเริ่มที่ข้อแรก Visualize the workflow ก็คือการเอางานที่เราทำๆกันอยู่เนี่ยให้มามองเห็นเป็นภาพ วิธีที่ง่ายที่สุดก้คือทำเป็น Board แต่เค้าไม่ได้บังคับว่าต้องทำBoardนะ ถ้ามีวิธีการอื่นในการVisualizeได้ก็ทำครับ
ใน slide มีการนำ Board จากหลายๆที่มาให้เราดูเป็นตัวอย่าง แต่ส่วนใหญ่จะหน้าตาคล้ายๆกันเป็น Kanban board แบบนี้(รูปหากิน ฮิฮิ) ซึ่งบางทีมันจะมีขนาดใหญ่มาก จนเรียกว่า card wall เลยก็ได้
บางที่ก็มี spare ไว้สำหรับ support หรืองานด่วนที่มีโอกาสวิ่งเข้ามา (บางท่านเรียกมันว่า "งานฟ้าประทาน")
หรือ Board ใหญ่สำหรับองค์กรที่มี Product หลายๆตัว ( มี board แบบด้านบน ของแต่ละทีมอีกที)
พอดียังไม่ได้ Slide จากทางผู้สอน เลยต้องวาดขึ้นใหม่ มันอาจจะดูมั่วๆ ต้องขออภัยครับ ถ้าได้มาแล้วจะเอามาอัพเดท
เสร็จแล้วก็ลองกำหนดจำนวน WIP ที่รับได้ในแต่ละ Roles ซึ่งถ้าไม่ได้เล่นเกมไม้ขีดมาคงไม่เข้าใจว่ากำหนดแล้วมันดียังไง อันนี้เสริมหน่อย ผมเคยไปฟังคุณกรพูดเกี่ยวกับ Kanban ในงาน TPSE มาแล้วครั้งหนึ่ง ซึ่งบอกตรงๆว่าไม่เข้าใจเลยสักนิดตรง WIP เนี่ยล่ะ จะมีไปทำไม ฟังอย่างเดียวไม่เห็นภาพจริงๆครับ
อีกเรื่องที่น่าสนใจก็คือการกำหนดรอบการทำงาน ซึ่งไม่ได้กำหนดอะไรเลย ขึ้นอยู่กับทีมจริงๆ
จะใช้ Sprint แบบ Scrum ก็ได้ (Kanban ล้อมเอาไว้หมดแล้ว)
หรือจะทำแบบ On demand คือ ทีมอยากจะ planning, restrospective, review, release กันตอนไหนก็ได้ ทำทุกวันก็ได้ ไม่ผิดกติกา
สุดท้ายแล้ว (เพราะนึกอะไรไม่ออกแล้ว) ก็คือการหา Right WIP limit ครับ ค่อยๆปรับกันไป
เสร็จแล้วก็ถึงเวลาพักเที่ยงครับ มือเที่ยงก็เป็นข้างกล่องทั่วไป ไม่ได้อลังการอะไร รสชาติใช้ได้
ครึ่งทางแล้วครับ จบมันดื้อๆอย่างนี้แหละ :)
เริ่มกันตั้งแต่จุดกำเนิดของมัน ให้กำเนิดโดย David Anderson ชือเดิมคือ Lean software development แต่ชื่อ Kanban ขายดีกว่า โดยสาเหตุแกต้องคิด Kanban ออกมาก็คือ เขาเอา Agile ไปใช้กับทีมหนึ่งแล้วมันได้ผล แต่พอเอาไปใช้กับทีมอื่นแล้วมันไม่ได้ผล
สาเหตุสำคัญอย่างหนึ่งคือมันมี "แรงต้าน"
ก็เลยไปคิดวิธีทำ Agile ยังไงให้มันไม่เกิดแรงต้าน มองไปมองมาก็ไปเจอกับวิธีการของ Toyota แล้วก็เกิดไอเดียว่า มันน่าจะเอามาใช้กับการทำ software ได้นะ
แล้วก็เริ่มจากการคุยกัน Community เล็กๆ จนกระทั่งเปิดตัวออกมาเป็น Kanban ในที่สุด
เพิ่งจะมีหนังสือออกมาในปี 2010 นี่เองครับไปดูได้ ที่นี่
มี Principle 4 ข้อ
1.start with what you do know อะไรที่ทำกันอยู่ก็ทำต่อไปเหมือนเดิม
2.agree to pursue incremental evolutionary change ตกลงกันว่าเราจะค่อยๆปรับวิธีการทำงาน
3.initially, respect current roles, responsibilities & job titles เคารพในตำแหน่ง หน้าที่ และ ความรับผิดชอบ ของทุกๆคน
4.encourage acts of leadership at all levels in your organization ทำให้เกิดภาวะผู้นำในทุกระดับ
2.agree to pursue incremental evolutionary change ตกลงกันว่าเราจะค่อยๆปรับวิธีการทำงาน
3.initially, respect current roles, responsibilities & job titles เคารพในตำแหน่ง หน้าที่ และ ความรับผิดชอบ ของทุกๆคน
4.encourage acts of leadership at all levels in your organization ทำให้เกิดภาวะผู้นำในทุกระดับ
และ Pracitce อีก6ข้อ
1. Visualize the workflow
2. Limit WIP
3. Manage Flow
4. Make Process Policies Explicit
6. Implement Feedback loops
5. Improve Collaboratively (using models & the scientific method)
2. Limit WIP
3. Manage Flow
4. Make Process Policies Explicit
6. Implement Feedback loops
5. Improve Collaboratively (using models & the scientific method)
คุณปอมเขียนเรื่องนี้ไว้แล้วครับ ไปอ่านกันได้ ที่นี่
ใน slide มีการนำ Board จากหลายๆที่มาให้เราดูเป็นตัวอย่าง แต่ส่วนใหญ่จะหน้าตาคล้ายๆกันเป็น Kanban board แบบนี้(รูปหากิน ฮิฮิ) ซึ่งบางทีมันจะมีขนาดใหญ่มาก จนเรียกว่า card wall เลยก็ได้
บางที่ก็มี spare ไว้สำหรับ support หรืองานด่วนที่มีโอกาสวิ่งเข้ามา (บางท่านเรียกมันว่า "งานฟ้าประทาน")
หรือ Board ใหญ่สำหรับองค์กรที่มี Product หลายๆตัว ( มี board แบบด้านบน ของแต่ละทีมอีกที)
พอดียังไม่ได้ Slide จากทางผู้สอน เลยต้องวาดขึ้นใหม่ มันอาจจะดูมั่วๆ ต้องขออภัยครับ ถ้าได้มาแล้วจะเอามาอัพเดท
เสร็จแล้วก็ลองกำหนดจำนวน WIP ที่รับได้ในแต่ละ Roles ซึ่งถ้าไม่ได้เล่นเกมไม้ขีดมาคงไม่เข้าใจว่ากำหนดแล้วมันดียังไง อันนี้เสริมหน่อย ผมเคยไปฟังคุณกรพูดเกี่ยวกับ Kanban ในงาน TPSE มาแล้วครั้งหนึ่ง ซึ่งบอกตรงๆว่าไม่เข้าใจเลยสักนิดตรง WIP เนี่ยล่ะ จะมีไปทำไม ฟังอย่างเดียวไม่เห็นภาพจริงๆครับ
อีกเรื่องที่น่าสนใจก็คือการกำหนดรอบการทำงาน ซึ่งไม่ได้กำหนดอะไรเลย ขึ้นอยู่กับทีมจริงๆ
จะใช้ Sprint แบบ Scrum ก็ได้ (Kanban ล้อมเอาไว้หมดแล้ว)
หรือจะทำแบบ On demand คือ ทีมอยากจะ planning, restrospective, review, release กันตอนไหนก็ได้ ทำทุกวันก็ได้ ไม่ผิดกติกา
สุดท้ายแล้ว (เพราะนึกอะไรไม่ออกแล้ว) ก็คือการหา Right WIP limit ครับ ค่อยๆปรับกันไป
เสร็จแล้วก็ถึงเวลาพักเที่ยงครับ มือเที่ยงก็เป็นข้างกล่องทั่วไป ไม่ได้อลังการอะไร รสชาติใช้ได้
ครึ่งทางแล้วครับ จบมันดื้อๆอย่างนี้แหละ :)
Sunday, March 16, 2014
Review: Kanban 101 by Kamon&Kulawat (1)
รูปนี้ผมขโมยมาจากบล็อกคุณปอม ต้นทางอยู่ที่ http://kulawat.tumblr.com/post/75491518534/kanban-101-by-kamon-kulawat
- Agile intro
- Flow game
- Da Kanban
- Kiss game
- TPS
- 5s game
- Kanbanopoly game
(ตกอันไหนไปป่าวนะ ถ้านึกได้ค่อยเพิ่มเข้าไปละกัน)
และช่วงสุดท้ายคือการนั่งคุย ถามตอบปัญหา
นอกจากนี้ยังมีการให้เขียนคำถามที่เราอยากรู้ไปแปะไว้บนกระดาน ระหว่างเรียนผู้สอนจะคอยหหยิบมาตอบเป็นระยะๆ ก็อย่างที่เห็นแหละฮะ เป็นเกมไปเกินครึ่ง
พูดถึงกระดาน มันไม่ใช่กระดานธรรมดานะครับ มันเป็นโต๊ะที่จับมาตั้ง ซึ่งมันใช้ได้ดีอย่างไม่น่าเชื่อ อันนี้คุณกรบอกว่าเห็นมาจากอีกที่หนึ่งเขาทำกัน เลยเอามาทำบ้าง ผมเองก็คิดว่าเดี๋ยวจะไปใช้โต๊ะตัวเองทำแบบนี้บ้าง อาจจะต้องตบตีกับแม่บ้านบ้างก็ไม่เป็นไร
เริ่มที่ส่วนแรก คือ Agile intro ตัวผมก็ได้ฟังมาหลายครั้งแล้ว ผมคิดว่าคนในชั้นเรียนหลายๆคนก็คงผ่านมาแล้วเช่นกัน แต่พอฟังจากคุณกรครั้งนี้ก็รู็สึกว่าเป็นรสชาติที่แปลกใหม่ดีนะ (ผมไม่เคยฟังคุณกรบรรยายแนวๆ Agile intro มาก่อน) Agile manifesto 4 ข้อ และ Principle ทั้ง 12 ข้อ รวมไปถึงเหล่าผู็ให้กำเนิดทั้งหลายนั้นนั้นยังพูดถึงอยู่ แต่ผ่านไปอย่างรวดเร็ว คุณกรพาเราลงไปลึกกว่านั้น นั้นคือย้อนกลับไปมองถึงสภาพสังคม และปัญหาในยุคนั้น (ช่วงปี 2000) เทคโนโลยี ฯลฯ สรุปว่าเป็น Agile intro แบบคุณกรจริงๆอ่ะ
พอจบแล้วก็มีเกมมาให้เล่นครับ เกมนี้ชื่อว่า Flow เกม
เกมนี้ทุกคนตั้งชื่อเล่นให้กับมันว่า"เกมไม้ขีด" เพราะอุปกรณ์หลักของมันคือ ไม้ขีดใช้แทนงานที่มันจะถาโถมเข้ามาหาทีมเราประหนึ่งฝูงซอมบี้ และลูกเต่๋า ใช้ทอยเพื่อดูว่าในแต่ละวันเราทำงานได้กี่ชิ้น กระดาษ Post-it รุ่น Super sticky เอาไว้แปะตรงหน้าสมาชิกแต่ละทีมเพื่อบอกว่าตำแหน่ง และกระดาษให้ PM เอาไว้จดว่าผ่านมากี่วันแล้ว
ผมไม่ได้ถ่ายรูปเอาไว้ เอาเป็นว่าผมวาดให้ดูก็แล้วกันนะ
วิธีเล่นก็คือให้ทุกตำแหน่ง (ยกเว้น PM หน้าที่ของ PM คือคอยจดกับบอกว่าผ่านไปกี่วันแล้ว) ทอยลูกเต๋าของตัวเองถ้าทอยได้แต้มสูง ก็เอาไม้ขีดผ่านตัวเองไปได้มาก ไม้ขีดนี้ก็จะไปกองอยู่ตรงหน้าคนถัดไป ก็คือเป็นการจำลองการทำงานของทีมทำ Software นั่นแหละครับ กว่างานจะผ่านมือ DEV ก็อาจจะเป็นวันที่ 3 กว่าจะส่งมอบงานชิ้นแรกได้ก็เป็นวันที่ 5
ดูจากในรูป คือไม้ขีดอันทีผมถมดำไว้มาถึงตำแหน่ง Done ได้ถือว่าจบรอบ ก็ให้เริ่มรอบต่อไป โดยที่รอบนี้แต่ละคนเริ่มจะมีไม้ขีดค้างอยู่ตรงหหน้ากันบ้างแล้ว รอบนี้ปรากฏว่าใช้เวลามากขึ้นเป็น 7-8 วัน
รอบต่อมาก็เพิ่มความมันส์ด้วยการบอกว่า Test ต้องทำทุก Platform ก็คือ จำนวนแต้มที่ทอยได้ให้หารสอง Oh shit งานก็มากองที่ Test น่ะสิ(ชีวิตจริงชัดๆ) รอบนี้กว่าจะจบก็กินเวลาไปสิบกว่าวัน นี่ขนาดผมทอยได้ 6 แต้มหลายๆครังแล้วนะ ;_;
เราเล่นกันทั้งหมด 4 รอบ ปรากฏว่ายิ่งทำงานไป จำนวนวันก็ยิ่งเพิ่ม (ผมไม่ได้จดจำนวนตัวเลขที่แน่นอนเอาไว้) ที่นีคุณกรก็ให้เรามา dicusss กันว่าปัญหามันอยู่ตรงไหน ก็ว่ากันไป จะเพิ่มคนบ้าง เอาคนออกบ้าง(ผมเสนอไปว่าเอา Test ออกสิ ฮิฮิ) ให้ PM มาช่วยงานบ้าง ฯลฯ
ต่อมาเรากก็ได้เริ่มเล่นเกมใหม่ คราวนี้ มีการกำหนด จำนวน WIP(Work In Progress) ของแต่ละคนเข้าไปด้วย เราตกลงกันที่ 3 ตัวเลขมาจากไหน ก็มาจากการที่ Tester ทำงานได้มากที่สุดแค่วันละ 3 ไงครับ T-T
ตกลงกันได้แล้วก็เรื่มเล่นใหม่ โดยแต่ละคนจะทำงานได้ไม่เกินวันละ 3
ปราฏว่าจำนวนวันที่ใช้ในแต่ละรอบคือ 5-6 วัน แค่ใส่ WIP !?
เริ่มจะเก็ทละ คุณกรมาอธิบายต่ออีกว่า WIP มันเป็นเรื่องของแต่ละคน(หรือแต่ละทีม/ตำแหน่ง) ต้องไปกำหนดกันเอาเอง และมันปรับเปลี่ยนได้เสมอตามที่เห็นว่าสมควร ถ้าตั้งไว้น้อยไป ก็จะมีคนว่างเยอะ ถ้ามากไป ก็จะมีงานค้างและมีโอกาสจะกองอยู่ที่คนใดคนหนึ่งเยอะ (อย่างเช่นในตัวอย่างก็คือ Tester)
ผมว่าถ้าจะไปเล่าต่อก็ไม่ต้องพูดกันมากครับ ให้เล่นเจ้า Flow game นี่แหละครับเห็นภาพแน่นอน
มีคำถามว่า แล้วคนว่างจะทำยังไง
คุณกรบอกว่าทำได้สองอย่างคือ ปล่อยให้ว่างต่อไป หรือ เข้าไปช่วยเหลือคนอื่นๆ (มีเสริมในตอนท้ายว่า เราชอบถนนที่ว่างๆ หรือ ถนนที่รถแน่น มากกว่ากัน)
ต่อมาก็เป็นการบรรยายของตัว Kanban แต่ผมว่าผมเขียนยาวไปละ เท่านี้ก่อนดีกว่าเนอะ
Friday, February 28, 2014
Review: Corona SDK part.1
หลังจากใช้มาเกือบสองเดือน ก็เลยลองมาเขียนreviewขำๆดูหน่อยละกัน
Official site: http://coronalabs.com/
Corona SDK เป็นเครื่องมือทำทำให้เราสามารถสร้าง Mobile application ได้ง่าย แบบ ง่ายมากๆ
สามารถ Build ไปลงได้ทั้ง iOS และ Android และคุณไม่ต้องปวดหัวกับภาษาต่างดาวอย่าง Objective-C หรือ Java อีกต่อไป คุณแค่ต้องเปลี่ยนมาปวดหัวกับภาษา Lua แทน :D
เอาล่ะครับ เดียวกลับมาว่ากันเรื่องภาษานะ
มาดูกันว่ามันมีอะไรให้คุณบ้างนะ เจ้า Corona นี่ เอาที่ผมได้ใช้แล้วจริงๆนะ
1.อย่างแรกก็คือ มันวาดรูปได้!!
แหงอยู่แล้วป่ะ Tool สร้างเกม ดันวาดรูปไม่ได้ แล้วมันจะทำมาหากินได้ยังไง
เอาเป็นว่า คุณสามารถวาดรูปทรงพื้นฐานลงไปบนหน้าจอได้ครับ วงกลม สี่เหลี่ยม หลายเหลี่ยม รวมไปถึงกำหนดตำแหน่ง, สี, ฯลฯ อันนี้ไปดูใน API docs กันต่อนะครับ
2.โหลดรูปได้!!
พื้นสุดๆอ่ะ มันคือการเอาไฟล์รูป ประเภทต่างมาแปะบนหน้าจอได้ครับ Support ฟอร์แมตที่นิยมใช้ันอยู่ในสากลโลก ถ้าใช้ png ก็จะทำTransparentได้
3.ทำ Sprite ได้
เราทำ Animation เป็น sprite sheet มา แล้วก็โหลดเข้ามาในโปรแกรมแล้วก็ทำให้มันเล่นเป็น sequence ได้นะครับ Version ล่าสุดที่ผมใช้นี่เป็น native support แล้วด้วย เป็นของที่คนทำเกมขาดไม่ได้เลยล่ะ
4.การกำหนดตำแหน่ง เรากำหนด origin ได้
เมื่อวาดรูปขึ้นมาแล้ว มันสารถกำหนด anchorX, anchorY ให้กับ Object ได้ ปกติมันจะมีค่าเป็น 0 ทั้งคู่ ซึ่งหมายถึงจุดที่อ้างอิงตรงกลางของ object มีผลเวลาที่กำหนดตำแหน่ง x,y มันจะอยู่ตรงกลาง ...งงมั้ยครับ คือปกติ แล้ว เรามักจะคิดว่า 0,0 จะต้องเริ่มจากมุมซ้ายบนเสมอใช่มั้ยครับ แต่ Corona มันสามารถกำหนเได้ว่า 0,0 นั้น จะให้เริ่มที่ตรงไหน เช่น จากตรงกลาง หรือ มุมขวา ซึ่งช่วยอำนวยความสะดวกให้เราได้มากทีเดียวครับ
5.มี Transition
รู้จัก Tween กันใช่มั้ยครับ ถ้าไม่ก็มันคือการเคลื่อนที่ Object จากที่หนึ่งไปอีกที่หนึ่งแหละครับ แต่ถ้าเราไปแก้ค่า x,y โดยตรงเลย มันก็จะวาปไปอยู่ที่ตรงนั้นเลย แต่เราอยากให้มันเคลื่อนที่ไปแบบเนี่ยนๆ เราก็ใช้ Transition เข้ามาช่วยครับ กำหนดตำแหน่งปลายทาง แล้วก็ช่วงเวลาที่ต้องการ แล้วมันก็จะบินไปเองฮะ ง่ายป่ะล่ะ
6.Event driven
ก็เหมือนๆกับ GUI ทั่วไปนะครับ ที่ใส่ listener ให้กับ Object ทีเราต้องการได้ เช่น tap, touch นอกจากนี้ก็มีพวก Event เกียวกับ sprite ที่เพิ่มเติมเข้ามา เช่น Sprite animate เล่นจบแล้ว หรือเริ่มเล่นเป็นต้น แล้วก็พวก Event เกียวกับ Physics ครับ ที่นิยมใช้กันมากๆ ก็อย่างเช่นการตรวจจับ Colliison
7.Physics
ความเจ๋งอีกอย่างของมันคือมี 2D Physics มาให้เลยครับ แค่เราสั่งเปิดใช้เท่านั้น เกมของเราก็จะมีระบบฟิสิกส์ทันที แต่ต้องไปเพิ่มโค้ดอีกนิดหน่อย หาอ่านได้ใน Tutorial ครับ
มันยังมีอีกเยอะนะครับ เช่นมี Simulator ที่ดี, มี Features เกี่ยวกับการใส่ Ads ฯลฯ แต่เท่าที่เขียนมานี่ก็พอจะทำเกมง่ายๆแปะโฆษณาได้แล้วล่ะ
ลองมาดูข้อเสียกันบ้าง
- เวลา Build ต้องส่งโค้ดของเราไปที่ server ของเค้า วันไหนเน็ตไม่ดีหรือล่ม ก็ลืมมันไปซะ (อยาก Build เองเหรอ จ่ายตังสิ)
- ไม่มี Auto update นะ ติดตามกันเอาเอง
- ไม่มีใน Linux
- ง่ายเกินไป อันนี้ก็แล้วแต่คน แต่ถ้าติดกับความง่ายของ Corona แล้ว จะขยับไปหา Tool ตัวอื่นหรือเข้าถึง Native ลำบากนะ
- External tool หรือ 3rd party lib ส่วนใหญ่ไม่ฟรี ในโลกของ Corona มันมีฝูงหมาป่ารอขย้ำคุณอยู่นะ ถ้าเป็นไปได้ก็พยายามพึ่งตัวเองให้ได้มากที่สุดครับ (ผมไม่ได้ห้ามซื้อนะ แต่อยากให้ดูดีๆก่อน ถ้าสักแต่ว่าซื้อๆ ก็อาจจะได้ของที่ไร้ประโยชน์มา เสียเงินเปล่า)
- ไม่มี Styling อยากทำ Font สวยๆ เดิ้นๆ มี Shadow มี outlined เหรอ เจ้าจงไปหาวิธีทำกันเอาเอง (หรือไม่ก็เสียตังซื้อ tool )
สรุปว่ามันเป็นเครื่องมือที่ดีตัวหนึ่งเลยนะครับสำหรับการทำเกม แค่เวอชั่นฟรีก็เพียงพอที่จะทำเกมได้ทั้งเกมแล้ว ใช้เวลาศึกษาไม่มาก(สำหรับมือใหม่จริงๆเลย) tutorial เพียบ community ค่อนข้างใหญ่ แต่ผมว่ายังไงก็คงต้องจ่ายเงินให้เขาสักวันล่ะนะ อิอิ
ไว้มาต่อ Part 2 เกียวกับตัวภาษา Lua
*ภาพประกอบไม่เกียวข้องกับเนื้อหาแต่อย่างใด
Official site: http://coronalabs.com/
Corona SDK เป็นเครื่องมือทำทำให้เราสามารถสร้าง Mobile application ได้ง่าย แบบ ง่ายมากๆ
สามารถ Build ไปลงได้ทั้ง iOS และ Android และคุณไม่ต้องปวดหัวกับภาษาต่างดาวอย่าง Objective-C หรือ Java อีกต่อไป คุณแค่ต้องเปลี่ยนมาปวดหัวกับภาษา Lua แทน :D
เอาล่ะครับ เดียวกลับมาว่ากันเรื่องภาษานะ
มาดูกันว่ามันมีอะไรให้คุณบ้างนะ เจ้า Corona นี่ เอาที่ผมได้ใช้แล้วจริงๆนะ
1.อย่างแรกก็คือ มันวาดรูปได้!!
แหงอยู่แล้วป่ะ Tool สร้างเกม ดันวาดรูปไม่ได้ แล้วมันจะทำมาหากินได้ยังไง
เอาเป็นว่า คุณสามารถวาดรูปทรงพื้นฐานลงไปบนหน้าจอได้ครับ วงกลม สี่เหลี่ยม หลายเหลี่ยม รวมไปถึงกำหนดตำแหน่ง, สี, ฯลฯ อันนี้ไปดูใน API docs กันต่อนะครับ
2.โหลดรูปได้!!
พื้นสุดๆอ่ะ มันคือการเอาไฟล์รูป ประเภทต่างมาแปะบนหน้าจอได้ครับ Support ฟอร์แมตที่นิยมใช้ันอยู่ในสากลโลก ถ้าใช้ png ก็จะทำTransparentได้
3.ทำ Sprite ได้
เราทำ Animation เป็น sprite sheet มา แล้วก็โหลดเข้ามาในโปรแกรมแล้วก็ทำให้มันเล่นเป็น sequence ได้นะครับ Version ล่าสุดที่ผมใช้นี่เป็น native support แล้วด้วย เป็นของที่คนทำเกมขาดไม่ได้เลยล่ะ
4.การกำหนดตำแหน่ง เรากำหนด origin ได้
เมื่อวาดรูปขึ้นมาแล้ว มันสารถกำหนด anchorX, anchorY ให้กับ Object ได้ ปกติมันจะมีค่าเป็น 0 ทั้งคู่ ซึ่งหมายถึงจุดที่อ้างอิงตรงกลางของ object มีผลเวลาที่กำหนดตำแหน่ง x,y มันจะอยู่ตรงกลาง ...งงมั้ยครับ คือปกติ แล้ว เรามักจะคิดว่า 0,0 จะต้องเริ่มจากมุมซ้ายบนเสมอใช่มั้ยครับ แต่ Corona มันสามารถกำหนเได้ว่า 0,0 นั้น จะให้เริ่มที่ตรงไหน เช่น จากตรงกลาง หรือ มุมขวา ซึ่งช่วยอำนวยความสะดวกให้เราได้มากทีเดียวครับ
5.มี Transition
รู้จัก Tween กันใช่มั้ยครับ ถ้าไม่ก็มันคือการเคลื่อนที่ Object จากที่หนึ่งไปอีกที่หนึ่งแหละครับ แต่ถ้าเราไปแก้ค่า x,y โดยตรงเลย มันก็จะวาปไปอยู่ที่ตรงนั้นเลย แต่เราอยากให้มันเคลื่อนที่ไปแบบเนี่ยนๆ เราก็ใช้ Transition เข้ามาช่วยครับ กำหนดตำแหน่งปลายทาง แล้วก็ช่วงเวลาที่ต้องการ แล้วมันก็จะบินไปเองฮะ ง่ายป่ะล่ะ
6.Event driven
ก็เหมือนๆกับ GUI ทั่วไปนะครับ ที่ใส่ listener ให้กับ Object ทีเราต้องการได้ เช่น tap, touch นอกจากนี้ก็มีพวก Event เกียวกับ sprite ที่เพิ่มเติมเข้ามา เช่น Sprite animate เล่นจบแล้ว หรือเริ่มเล่นเป็นต้น แล้วก็พวก Event เกียวกับ Physics ครับ ที่นิยมใช้กันมากๆ ก็อย่างเช่นการตรวจจับ Colliison
7.Physics
ความเจ๋งอีกอย่างของมันคือมี 2D Physics มาให้เลยครับ แค่เราสั่งเปิดใช้เท่านั้น เกมของเราก็จะมีระบบฟิสิกส์ทันที แต่ต้องไปเพิ่มโค้ดอีกนิดหน่อย หาอ่านได้ใน Tutorial ครับ
มันยังมีอีกเยอะนะครับ เช่นมี Simulator ที่ดี, มี Features เกี่ยวกับการใส่ Ads ฯลฯ แต่เท่าที่เขียนมานี่ก็พอจะทำเกมง่ายๆแปะโฆษณาได้แล้วล่ะ
ลองมาดูข้อเสียกันบ้าง
- เวลา Build ต้องส่งโค้ดของเราไปที่ server ของเค้า วันไหนเน็ตไม่ดีหรือล่ม ก็ลืมมันไปซะ (อยาก Build เองเหรอ จ่ายตังสิ)
- ไม่มี Auto update นะ ติดตามกันเอาเอง
- ไม่มีใน Linux
- ง่ายเกินไป อันนี้ก็แล้วแต่คน แต่ถ้าติดกับความง่ายของ Corona แล้ว จะขยับไปหา Tool ตัวอื่นหรือเข้าถึง Native ลำบากนะ
- External tool หรือ 3rd party lib ส่วนใหญ่ไม่ฟรี ในโลกของ Corona มันมีฝูงหมาป่ารอขย้ำคุณอยู่นะ ถ้าเป็นไปได้ก็พยายามพึ่งตัวเองให้ได้มากที่สุดครับ (ผมไม่ได้ห้ามซื้อนะ แต่อยากให้ดูดีๆก่อน ถ้าสักแต่ว่าซื้อๆ ก็อาจจะได้ของที่ไร้ประโยชน์มา เสียเงินเปล่า)
- ไม่มี Styling อยากทำ Font สวยๆ เดิ้นๆ มี Shadow มี outlined เหรอ เจ้าจงไปหาวิธีทำกันเอาเอง (หรือไม่ก็เสียตังซื้อ tool )
สรุปว่ามันเป็นเครื่องมือที่ดีตัวหนึ่งเลยนะครับสำหรับการทำเกม แค่เวอชั่นฟรีก็เพียงพอที่จะทำเกมได้ทั้งเกมแล้ว ใช้เวลาศึกษาไม่มาก(สำหรับมือใหม่จริงๆเลย) tutorial เพียบ community ค่อนข้างใหญ่ แต่ผมว่ายังไงก็คงต้องจ่ายเงินให้เขาสักวันล่ะนะ อิอิ
ไว้มาต่อ Part 2 เกียวกับตัวภาษา Lua
Tuesday, February 25, 2014
Lean coffee
พอดีมีโอกาสได้ไปเข้าร่วม Lean coffee กับคุณนนท์ ก็เลยมาบล็อกเก็บเอาไว้สักหน่อย
มันก็เป็นการ meeting รูปแบบหนึ่งแหละครับ ใน Official site บอกว่า มันคือ structured, but agenda-less meeting
เริ่มจากการให้ผู้ที่เข้าร่วมทุกคนเขียนหัวข้อขึ้นมา ใส่ card แล้วก็เอามาแปะๆไว้ แล้วก็ใช้เวลาอีกเล็กน้อยให้ทุกคนอธิบายหัวข้อของตัวเองว่ามันคืออะไรแน่
เสร็จแล้วก็ทำ dot vote โดยที่แต่ละคนโหวตได้ 2 ครั้ง จะโหวตเรื่องของตัวเองหรือโหวตของคนอื่นก็ได้
พอโหวตเสร็จแล้ว ก็เอามาจัด priority ตามหัวข้อที่มีคะแนนโหวตมากที่สุด แล้วก็เริ่มคุยกัน
เมื่อเราเริ่มคุยกัน เราจะมีเวลา 5 นาที ในการคุยหัวข้อนั้น (มี facilitator คอยจับเวลา) ก็คุยกันไปครับ (ยอมรับเลยว่าเลเวลผมมันน้อยมากจริงๆ หาช่องพูดไม่ค่อยได้เลย เศร้า T-T) ถ้าหมดเวลาแล้วแต่ยังพูดไม่จบ ก็พูดต่อให้จบได้
พอหมดเวลาก็ให้สมาชิกมาโหวตอีกว่าจะคุยเรื่องนี้กันต่อมั้ย
โดยมีทางเลือก สามอย่าง คือ
Y = คุยต่อ
N = ไม่เอาละ
O = ยังไงก็ได้ (No vote) อันนี้โดนติงมาว่าอย่า no vote มาก ทำตัวไม่ถูก ก็น่าคิดนะฮะ ถ้า No vote กันหมดแล้วจะเอาไงต่อ ประเทศชาติจะเดินต่อไปยังไง ต้องปฏิรูปก่อนมั้ย ... เอิ่ม พอดีกว่า
เอาเป็นว่า ถ้า Y เยอะ ก็คุยเรื่องเดิมต่ออีก 5 นาที ถ้า N เยอะ ก็ เอาเรื่องต่อไปมาคุย
ทำอย่างนี้ไปจนหมดเวลา ซึ่งกำหนดไว้ที่ครึ่งชั่วโมง
ในตอนท้าย คุณนนท์ยังบอกอีกว่า ที่เราทำกันไปเป็น Lean coffee แบบมาตรฐาน สามารถนำไปปรับให้เข้ากับองค์กรณ์หรือทีมของตัวเองได้
เสร็จแล้วก็มาทำ Retrospect กันหน่อย อันนี้ส่วนตัวของผมนะ มีเพิ่มเติมนิดหน่อยครับ ตอนนั้นคิดไ่ม่ทัน แหะๆ
Good
- มีเรื่องที่จะคุยชัดเจน มีเตรียมหัวข้อมาก่อน
- Dead air น้อยมาก อาจจะเป็นเพราะสมาชิกแต่ละท่านเลเวลสูงๆกันทั้งนั้นเลย
ฺBad
- มีหัวข้อที่ไม่ได้คุยเยอะ คนที่หัวข้อไม่ได้รับการโหวตอาจจะน้อยใจได้ :)
- อุปกรณ์กับเน็ตผมกากมาก ทั้งหลุดทั้งส่งเสียงรบกวน
- ผมพูดน้อยมาก
Try ตอนนั้นคิดไม่ทัน เลยบอกไปว่าไม่มี
- ได้คุยกับพี่มุ้ยต่อหลังจากนั้น น่าจะเอาหัวข้อที่น่าสนใจ มาคุยต่อในกรุ๊ป
- ใจกล้า หน้าด้าน หาช่องในการพูดบ้าง
หมดละครับ ขอบคุณคุณนนท์กับเพื่อนๆที่มาช่วยกันแชร์ครับ ผมนี่ไม่ค่อยได้แชร์อะไรเลย เฮ้อ
Official site http://leancoffee.org/
มันก็เป็นการ meeting รูปแบบหนึ่งแหละครับ ใน Official site บอกว่า มันคือ structured, but agenda-less meeting
เริ่มจากการให้ผู้ที่เข้าร่วมทุกคนเขียนหัวข้อขึ้นมา ใส่ card แล้วก็เอามาแปะๆไว้ แล้วก็ใช้เวลาอีกเล็กน้อยให้ทุกคนอธิบายหัวข้อของตัวเองว่ามันคืออะไรแน่
เสร็จแล้วก็ทำ dot vote โดยที่แต่ละคนโหวตได้ 2 ครั้ง จะโหวตเรื่องของตัวเองหรือโหวตของคนอื่นก็ได้
พอโหวตเสร็จแล้ว ก็เอามาจัด priority ตามหัวข้อที่มีคะแนนโหวตมากที่สุด แล้วก็เริ่มคุยกัน
เมื่อเราเริ่มคุยกัน เราจะมีเวลา 5 นาที ในการคุยหัวข้อนั้น (มี facilitator คอยจับเวลา) ก็คุยกันไปครับ (ยอมรับเลยว่าเลเวลผมมันน้อยมากจริงๆ หาช่องพูดไม่ค่อยได้เลย เศร้า T-T) ถ้าหมดเวลาแล้วแต่ยังพูดไม่จบ ก็พูดต่อให้จบได้
พอหมดเวลาก็ให้สมาชิกมาโหวตอีกว่าจะคุยเรื่องนี้กันต่อมั้ย
โดยมีทางเลือก สามอย่าง คือ
Y = คุยต่อ
N = ไม่เอาละ
O = ยังไงก็ได้ (No vote) อันนี้โดนติงมาว่าอย่า no vote มาก ทำตัวไม่ถูก ก็น่าคิดนะฮะ ถ้า No vote กันหมดแล้วจะเอาไงต่อ ประเทศชาติจะเดินต่อไปยังไง ต้องปฏิรูปก่อนมั้ย ... เอิ่ม พอดีกว่า
เอาเป็นว่า ถ้า Y เยอะ ก็คุยเรื่องเดิมต่ออีก 5 นาที ถ้า N เยอะ ก็ เอาเรื่องต่อไปมาคุย
ทำอย่างนี้ไปจนหมดเวลา ซึ่งกำหนดไว้ที่ครึ่งชั่วโมง
ในตอนท้าย คุณนนท์ยังบอกอีกว่า ที่เราทำกันไปเป็น Lean coffee แบบมาตรฐาน สามารถนำไปปรับให้เข้ากับองค์กรณ์หรือทีมของตัวเองได้
เสร็จแล้วก็มาทำ Retrospect กันหน่อย อันนี้ส่วนตัวของผมนะ มีเพิ่มเติมนิดหน่อยครับ ตอนนั้นคิดไ่ม่ทัน แหะๆ
Good
- มีเรื่องที่จะคุยชัดเจน มีเตรียมหัวข้อมาก่อน
- Dead air น้อยมาก อาจจะเป็นเพราะสมาชิกแต่ละท่านเลเวลสูงๆกันทั้งนั้นเลย
ฺBad
- มีหัวข้อที่ไม่ได้คุยเยอะ คนที่หัวข้อไม่ได้รับการโหวตอาจจะน้อยใจได้ :)
- อุปกรณ์กับเน็ตผมกากมาก ทั้งหลุดทั้งส่งเสียงรบกวน
- ผมพูดน้อยมาก
Try ตอนนั้นคิดไม่ทัน เลยบอกไปว่าไม่มี
- ได้คุยกับพี่มุ้ยต่อหลังจากนั้น น่าจะเอาหัวข้อที่น่าสนใจ มาคุยต่อในกรุ๊ป
- ใจกล้า หน้าด้าน หาช่องในการพูดบ้าง
หมดละครับ ขอบคุณคุณนนท์กับเพื่อนๆที่มาช่วยกันแชร์ครับ ผมนี่ไม่ค่อยได้แชร์อะไรเลย เฮ้อ
Official site http://leancoffee.org/
Subscribe to:
Posts (Atom)




















