ติดตั้ง Robot Framework + AutoItLibrary สำหรับ Automated testing กับ Windows application

ภาพจาก http://www.odedgov.com/index.php?/projectsbezalel/automata/


ไม่รู้จะเริ่มยังไง เอาเป็นว่า บทความนี้เป็นการแนะนำการติดตั้งเครื่องมือสำหรับการทำ Automated test ที่มีชื่อว่า Robot framework นะครับ ส่วนใหญ่เขาทำกับ Web application คราวนี้มาลอง Windows application กันดูบ้าง โดยผ่าน library ที่มีชื่อว่า AutoItLibrary ครับ เป็น library ที่เขียนครอบ AutoIt อีกที ซึ่งเจ้า AutoIt มันก็คือเครื่องมือที่เอาไว้รัน Automate script บน Windows อยู่แล้ว อยากรู้มากกว่านี้ลองเข้าไปอ่านที่ http://www.autoitscript.com/site/autoit/
อ้อ ก่อนอื่นผมแนะนำให้ไป download Virtualbox มาแล้วทำการติดตั้ง Windows แล้วลองติดตั้งเล่นใน virtual machine ดูก่อนนะครับ เผื่อว่าทำอะไรผิดพลาดไปจะได้ลบทิ้งแล้วเริ่มใหม่ได้ง่ายๆ Windows รุ่นที่แนะนำคือ XP ครับ ISO ก็คงหากันเองได้ไม่ยากหรอก(มั้ง)  ใหม่กว่านี้จะติดพวก UAC ต้องไปหาทาง disable เอา ไหนจะเรื่อง 32/64 bit อีก วุ่นวายตามประสา Windows

เริ่มกันเลย 
1.ติดตั้ง Python โดยไป Download ได้จาก https://www.python.org/download/ โดย version ที่แนะนำให้ใช้คือ 2.7 ขึ้นไป (3 ยังไม่เคยลองครับ) และควรใช้แค่ 32 บิต ก็พอ
2.ไปเพิ่ม path

C:\Python27;C:\Python27\Lib\site-packages\;C:\Python27\Scripts\;

ที่ environment settings ของ Windows ตามนี้

ลองเปิด command prompt แล้วพิมพ์คำสั่ง python ดูครับ ควรจะได้หน้าตาประมาณนี้

3.ติดตั้ง pip โดยไปที่เพจนี้ https://pip.pypa.io/en/latest/installing.html ที่หัวข้อ Install pip จะเจอลิงค์ get-pip.py นะครับ คลิกขวาแล้ว save as มาไว้ในเครื่อง

เสร็จแล้วไปยังตำแหน่งที่เราเก็บไฟล์ get-pip.py เอาไว้(ผมเอาไว้ใน My documents\downloads) แล้วพิมพ์คำสั่ง
>python get-pip.py
รอสักพักจนมันติดตั้งเสร็จเรียบร้อย

แล้วลองพิมพ์คำสั่ง
>pip install
จะเจอ Error ประมาณนี้ แปลว่าคำสั่ง pip ใช้งานได้ครับ

4.ติดตั้ง Robot framework โดยพิมพ์
>pip install robotframework
เสร็จแล้วลองพิมพ์คำสั่ง
>pybot
จะเห็น Error อีกเช่นกัน แต่เป็นเพราะว่าเรายังไม่มีไฟล์ script ที่ใช้ในการเทส ไม่เป็นไร เดี๋ยวมีแน่

5.เสร็จแล้วไป Download AutoItLibrary มาครับ
แตก zip แล้วติดตั้งด้วย คำสั่ง
>python setup.py install
เราจะพบว่า ยังติดตั้งไม่ได้ ต้องลง pywin32 ก่อน

ก็ไปโหลดมาครับ ที่นี่ http://sourceforge.net/projects/pywin32/files/pywin32/ เลือกเอา build ล่าสุดสำหรับ Python 2.7 และ win32 นะครับ ดูดีๆ โหลดมา เป็นไฟล์ exe อยู่แล้วทำการติดตั้งได้เลยครับ

กลับไป install AutoItLibrary อีกที ผ่านแล้ว

6.ลองทดสอบดู โดยไปที่ C:\RobotFramework\Extensions\AutoItLibrary\tests เขาจะมีตัวอย่างไว้ให้แล้ว ลองทดสอบดูโดยการ run ไฟล์ที่ชื่อ Runtests.bat

โปรแกรม Calculator จะถูกเปิดขึ้นมา แล้วก็กดปุ่มต่างๆเองตาม script ในตัวอย่าง พร้อมแสดงผลของ Test case แต่ละอัน

รันจบแล้ว แต่มันยังไม่จบครับ จะโดนเตือนอีกว่า ยังไม่ได้ลง PIL(Python image library)  นะ ถ้าอยากจะให้ capture ภาพเอาไว้ช่วยลงให้ด้วย

โอเค เราก็ไปโหลดมา http://www.pythonware.com/products/pil/ (ไปโหลดมาเลยครับ อย่าไปหวังพึ่งพาอะไรกับ pip ใน Windows อิอิ) ติดตั้งเสร็จแล้วก็ ลองรัน test ดูใหม่ มันจะไม่เตือนเราแล้ว ทีนี้เข้าไปดูในโฟลเดอร์ results นะครับ เราจะเห็นภาพที่มัน capture เอาไว้ให้เรา

ตอนหน้ามาลองเขียน Test ง่ายๆเพื่อทำความรู้จักกับเจ้า AutoItLibrary กันครับ

Review Corona SDK part.2 Language from the moon.

มาพูดถึงตัวภาษาที่ใช้ใน Corona SDK กันบ้าง ก็คือภาษา Lua (ใน Official ให้อ่านออกเสียงว่า ลู-อะ แต่ไม่มีใครอ่านแบบนั้นสักคน จะฝรั่งหรือไทยก็อ่าน "ลัว" กันหมด)

ประวัติของมันก็ไปอ่านกันได้ที่ http://www.lua.org/

ตัวภาษามันก็เป็นภาษา script อารมณ์เดียวกับ Javascript, python, ruby, php ฯลฯ เทือกๆนี้แหละครับ ส่วนตัวแล้วผมว่ามันคล้ายๆ Javascript แต่มันก็มีอะไรที่เป้นของมันเองเยอะเหมือนกันนะ

วิธีการเขียนก็ง่ายๆสไตล์ภาษาScript อย่างเช่นอยากจะ Hello world ก็แค่

 print("Hello world")  

แล้ว save เป็นไฟล์ สมมติว่าชื่อ hello.lua แล้วรันด้วย command (ต้องติดตั้ง lua เองต่างหากนะครับ Corona SDK ไม่มีมาให้ เด๊่ยวจะมาแนะนำวันหลัง)

>lua hello.lua

แค่นี้ก็ทำงานได้แล้วครับ

แต่ว่าแค่นี้มันจะไปพิเศษยังไงกันล่ะ มีภาษาอื่นๆทำได้ตั้งเยอะแยะ เดี๋ยวลองดูไปเรื่อยๆละกันครับ

ไม่ต้องประกาศ Type 
เป็นมาตรฐานของภาษายุคนี้ไปแล้วกระมัง คือเราไม่จำเป็นต้องประกาศ Type ของตัวแปร เอาอะไรมารับก็ได้หมด เช่น

 somchai = "My father"  
 somchai = 65355  
 somchai = {}  

ตัวแปรทุกตัวเป็น Global 
ถ้าเราเขียนแบบนี้

 function createSomchai()  
   somchai = "My father"  
 end  
 function greetSomchai()  
   print("Hello"..somchai)  
 end  

พวกที่อยู่ข้างนอก ก็จะรู้จัก somchai ไปด้วย

createSomchai()
print(somchai)
greetingSomchai()

ถ้าไม่อยากให้เป็น Global ต้องใส่ local ไว้ข้างหน้า

 functon createSomchai()  
   local somchai = "My father"  
 end  

นอก function ก็จะไม่รู้จักตัวแปร somchai อีกต่อไป

Table เทพ
ใน Lua ไม่มี Array ไม่มี Class ไม่มี Struct ฯลฯ มีให้แต่ Table ซึ่งมันสามารถแปลงร่างเป็นสิ่งที่เราอยากให้มันเป็นได้
เป็น Array

 somchaiChildrens = {"Perseus", "Herculis", "Kratos"}  

เป็น Data object

 somchaiProfile = {  
   name="Somchai",  
   age=42,  
   isMarries=true  
 }  

เป็น Module

 somchai = {  
   function sleep() end  
   function wake() end  
   function wwork() end  
 }  

นอกจากนี้ก็มีพวก Data structure แบบอื่นๆอีกเช่น Set, Queue, Tree ซึ่งจะเอามาแนะนำในโอกาสต่อไปครับ รวมถึงเรื่องการ iteration ด้วย

Function ก็เป็น Type
หมายถึงว่าเราสามารถ pass function เข้าไปใน function อื่นๆได้ หรือจะเอาไว้ใน table ก็ได้เช่นเดียวกัน แล้วก็ evaluate function นั้นได้แบบเดียวกับ Javacript

 function evaluateFunction(anyFunction)  
   anyFunction()  
 end  

ไม่มี Try Catch
เพราะตัวภาษามันสร้างมาจาก C มันไม่มี Exception handling (= =')  ต้องใช้ฟังก์ชั่น pcall แทนครับ แบบนี้

 local result, message = pcall(greetSomchai())  

result จะเป็นตัวแปร boolean ถ้าเป็น true หมายถึง ไม่มี error ถ้าเป็น false หมายถึงมี error เกิดขึ้น
message ขึ้นอยู่กับ result ถ้าเป็น true ก็จะเป็นผลลัพธ์ที่ return มาจาก function (ถ้าไม่มีก็เป็น nil) แต่ถ้าเป็น false มันก็จะเป็น Message ของ error ที่เกิดขึ้น
ตัวอย่างวิธีการใช้ error ครับ

 function greetSomchai()  
  if somchai then  
  print("Hello "..somchai)  
  else  
  error("Who the hell is Somchai?")  
 end  

Silent fail
ถ้าไม่ร้ายแรงจริงๆ มันจะไม่ throw error ออกมาครับ อย่างเช่นหา Module ไม่เจอ, เรียกใช้ตัวแปรที่ยังไม่ถูกประกาศหรือเป็น nil อันนี้มันจะมี error ออกมา
แต่ถ้าเป็นพวกการเปิดไฟล์ ถ้าไม่มีไฟล์หรือใส่ path ผิดมันไม่ error นะครับมันจะ error ตอนที่เราจะเอามาใช้ ให้เราเดาสาเหตุกันเล่นๆ สนุกๆ  ^ ^ หรือ
สรุปว่าต้องเขียนดีๆ นะ เวลามีแมลงจะได้ไล้จับถูก

OOP ก็มีให้ใช้นะ
แต่วิธีการมันจะประหลาดหน่อย  อย่างกับทำอะไรฝืนธรรมชาติอยู่ ก็มันทำงานอยู่บนภาษา C นี่นะ ถ้าใช้แค่ใน Corona ก็ไม่จำเป็นเลยครับ

ยังมีที่อยากจะบ่นอีกแต่พอเท่านี้ก่อนละกัน สรุปแล้ว ถ้าถามว่าง่ายมั้ย ก็ง่ายจริง แต่สำหรับผู้ที่ผ่านภาษาอื่นๆมาแล้วมากกมายอย่าง Java, Python, PHP ... พอเริ่มจับไอ้ตัวนี้เราจะไปไม่เป็น ทำไม่ถูก พยายามเอาความรู้จากภาษาอื่นๆมาใช้กับ Lua ผลคือเละ ต้องปรับตัวหน่อยครับ ลืมๆ ไอ้ที่เคยทำมาไปซะ เราทำงานกับภาษา Lua ก็ต้องเขียนโปรแกรมสไตล์ Lua ครับ ตัวผมเองใช้เวลาอยู่หลายเดือน ถึงจะเริ่มเข้าที่ แต่จนถึงก็ยังไม่ได้ดีเด่อะไรหรอกนะ ยังขาดอะไรอีกเยอะ

ไปเรียน CSD มาแหละ

มีโอกาสได้ไปเรียนคอร์ส 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 ทั้งหลายที่อาจจะทำไม่ได้ในที่ทำงานเราก็คุ้มแล้วครับ

สวัสดีครับ -/\-

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