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

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

Review: Kanban 101 by Kamon&Kulawat (2)

มาต่อกันในส่วนของการบรรยายเกี๋ยวกับ Kanban

เริ่มกันตั้งแต่จุดกำเนิดของมัน ให้กำเนิดโดย 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 ทำให้เกิดภาวะผู้นำในทุกระดับ

และ 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)

คุณปอมเขียนเรื่องนี้ไว้แล้วครับ ไปอ่านกันได้ ที่นี่

มาเริ่มที่ข้อแรก 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 ครับ ค่อยๆปรับกันไป

เสร็จแล้วก็ถึงเวลาพักเที่ยงครับ มือเที่ยงก็เป็นข้างกล่องทั่วไป ไม่ได้อลังการอะไร รสชาติใช้ได้

ครึ่งทางแล้วครับ จบมันดื้อๆอย่างนี้แหละ :)

Review: Kanban 101 by Kamon&Kulawat (1)

รูปนี้ผมขโมยมาจากบล็อกคุณปอม ต้นทางอยู่ที่ http://kulawat.tumblr.com/post/75491518534/kanban-101-by-kamon-kulawat

พอดีผมได้เข้าร่วมชั้นเรียน Kanban 101 ของคุณกร Kamon กับ คุณ ปอม Kulawat ในวันที่ 15 มีนาคม 2557 ที่ผ่านมา มาดูว่าชั้นเรียนนี้เขาสอนอะไรบ้าง

- 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 แต่ผมว่าผมเขียนยาวไปละ เท่านี้ก่อนดีกว่าเนอะ

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

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/

Review: di-lite.js Dependencies injection ใน javascript แบบเบาๆ

ใน Javascript มีคนทำ Dependencies injection อยู่หลายเจ้า อาทิเช่น
wire.js
inverted
di-lite.js
หรือใน angular.js ก็ได้ข่าวว่ามีให้ใช้เหมือนกัน แต่เนื่องจากงานในปัจจุบันมันเกาะติดกับ Backbone อย่างแนบแน่นจนแงะไม่ออกไปเสียแล้ว เป็นอันว่าตัดทิ้งไป

ลองคุ้ยเขี่ยอยู่นาน ก็ตัดสินใจเอาเจ้าตัว di-lite นี่ล่ะมาใช้ เพราะตัวอื่นมันมากับ dependency พ่วงมาอีกประมาณหนึ่ง แถมต้องเขียนโมดูลแบบ AMD ซึ่งผมก็เพิ่งจะรู้เนี่ยแหละว่าเดี๋ยวนี้เขานิยมเขียนแบบนี้กัน

ด้วยเหตุนี้ ก็เลยเหลือตัวเลือกเพียงหนึ่งเดียว แต่ไม่ใช่ว่าจะตัดใจจากตัวอื่นๆแล้วหรอกนะครับ แต่ขอเอาไว้โอกาสหน้าก็แล้วกัน

เริ่มจากข้อดีก่อน
ข้อดีก็คือ มันใช้ง่ายมากๆ คือเขียนยังไงก็ได้ ขอแค่เวลาที่จะ Register มันรู้จัก Class นั้นก็พอ ทำให้แทบจะไม่กระทบอะไรกับงานที่เคยทำมาแล้วเลยครับ สามารถทยอยถอดส่วนที่ยุ่งเหยิงออกมาได้สบายๆ รวมถึงงานที่กำลังจะทำต่อไปในอนาคตด้วย
ในส่วนที่จำเป็นก็มีมาให้เกือบครบ (อะไรที่ขาดไป เดี๋ยวว่ากันอีกที่ในส่วนของข้อเสีย) อย่างเช่น

• Constructor arguments
• กำหนด Strategy ได้ (Singleton, Prototype) 
• ทำ Circular reference ก็ได้
• เรียก function อัตโนมัติหลังจากที่ initialize เสร็จแล้วได้

ซึ่งเท่านี้ก็เพียงพอสำหรับความต้องการ(ในตอนนี้นะ)

ที่นี้มาดูข้อเสียกันบ้าง

ข้อเสียที่เด่นๆเลยก็คือ วิธีประกาศ Dependencies มันแนวไปหน่อย ลองไปดูก็ได้ครับ ถ้าเราตัดสินใจจะใช้เจ้าตัวนี้ มันก็มีตราบาป (this.dependencies) ติดอยู่กับ Class ของเราไปตลอดกาล
แถมยังมีผลข้างเคียง ถ้ามีเพื่อนร่วมทีมมาดูโค้ดก็จะงง ว่า ไอ้ property ตัวนี้มันมาจากไหน (ซึ่งปกติ Javascript ก็ดูโค้ดยากด้วยตัวมันเองอยู่แล้ว ในระดับหนึ่ง)

ต่อมาคือเขียน Configuration แยกออกมาต่างหากไม่ได้ ต้อง Register เอาเองล้วนๆ ต่อไปถ้ามีของเยอะๆ อาจจะต้องเขียน Module สำหรับเอาไว้ Register โดยเฉพาะเลยก็เป็นได้

ยังทำ reference ไม่ได้ อย่างเช่นจะเอา module ที่ register ไปแล้วมาเป็น Constructor argument แบบนี้ยังทำไม่ได้ (แต่ set หลังจาก initialize แล้วได้นะ ต้องซิกแซกเอาหน่อย)

ซึ่งไปแอบส่อง Milestone เขามานิดหน่อยแล้วล่ะ คิดว่าคงได้รับการปรับปรุงไปเรื่อยๆ สู้ต่อไปนะ ทาเคชิ

สรุปว่าก็นำมาใช้งานได้ในระดับหนึ่ง อย่างน้อยมันก็ดีกว่ามานั่ง new แล้ว assign ให้เอาเองล่ะนะ แล้วก็ทำให้เขียน Class กับ Test ได้ง่ายขึ้นด้วย ตัวอื่นๆอาจจะเจ๋งกว่านี้ แต่มันต้องเปลี่ยนเยอะ เหนื่อย เอาไว้มีโอกาสทำอะไรเล่นอาจจะเอาตัวอื่นๆมาลองอีกครับ