บันทึกการเดินทาง#21 : The First Thailand Practical Software Engineering

ถึงกับต้องขอลางานไปงานนี้เลยทีเดียว อยากไปฟังมากงานนี้
พยายามเขียนสิ่งที่ Note ไว้และจำได้ละกันเนอะ



Managing Large Complex Projects: Dr.Firouz Naderi
The Case Study of the Mars Exploration Rover

Session นี้ถือว่าเป็น Highlight ของงานเลย แค่คนพูดนี่ก็น่าตื่นเต้นมากแล้ว Dr.Firouz Naderi ผู้อำนวยการโครงการสำรวจในระบบสุริยะทั้งหมดจาก NASA JPL โดยคราวนี้ยกตัวอย่างมาเล่าให้ฟังเกี่ยวกับโครงการสำรวจดาวอังคารที่กำลังทำอยู่ (เห็นว่าที่ฟังนี่เป็นแค่ฉบับย่อจาก 3 ชั่วโมงที่ท่านไปพูดที่ Standford และนักศึกษาที่นั่นลงทะเบียนกันเต็มเลยล่ะ) โดยเริ่มจากการเกริ่นจากไอเดียภาพรวมของการทำโครงการซักโครงการนึงว่า 
  1. เราเริ่มจากการมีความฝัน จากนั้นเราก็
  2. ขายฝันให้ได้กับใครสักคน จากนั้นในวันถัดมา 
  3. เราก็เริ่มจะคิดได้ว่า "มองโลกในแง่ดีเกินไปแล้วนะ" ซึ่งพอผ่านจุดนี้ก็จะ
  4. เริ่มทำงานหนักขึ้นที่ 60 ชั่วโมงต่อสัปดาห์และ 
  5. เราก็จะเริ่มเครียดขึ้นอีกเรื่อยๆ จากปัญหาต่างๆ ที่รุมเข้ามาไม่ว่าจะเป็นปัญหาทางเทคนิค, งบหรือแม้กระทั่งกำหนดส่ง ปัญหาเหล่านี้จะส่งผลให้
  6. เราทำงานหนักขึ้นอีกเป็น 70 ชั่วโมงต่อสัปดาห์ ซึ่งเมื่อถึงท้ายที่สุดแล้วไม่มีใครบอกได้ว่า 
  7. โครงการที่เราทำอยู่จะประสบความสำเร็จ ... หรือล้มเหลว
และยังบอกอีกว่า ในการเริ่มต้นทุกๆ โครงการมักจะง่ายเสมอโดยพูดว่า "Give me the money I give you a profit" แต่ปัญหาคือคนเรามักไม่เข้าปัญหาพื้นฐานของการทำโครงการอะไรสักอย่าง เช่นเรื่องการสร้างทีม โดย ดร. ได้บอกถึงหน้าที่ที่สำคัญของ Team Leader มี 3 ข้อประกอบด้วย
  1. เฟ้นหาคนที่ "ดีที่สุด" ให้มาร่วมทีมให้ได้ ซึ่งจะทำให้ไอเดียของเราประสบความสำเร็จมากกว่าคนที่ "ดีรองลงมา" และจงมั่นใจว่าคนที่หามาได้ จะต้องทำงานกับคนอื่นๆ ได้อย่างราบรื่น
  2. กระตุ้น (Motivate) ทีมให้มีความมุ่งมั่น และเป้าหมายเดียวกันตลอดเวลา โดยดร. ได้ยก Quote ของ Antonie de Saint-Exupery ใจความว่า If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea. 
  3. เป้าหมายและวิสัยทัศน์ต้องตรงกับทีมเสมอ และทำหน้าที่ Fair Leader ที่ดี นั่นคือเป็นคนแรกที่โดนด่า และได้รับคำชม
หลังจากนั้น ดร. ก็ได้พาเข้าเรื่อง Mars Exploration Rover โดยบอกว่าเป้าหมายของโครงการสำรวจดาวอังคารเพื่อคำถาม 3 ข้อนั่นคือ 
  1. ดาวอังคารสามารถอาศัยอยู่ได้หรือไม่ ?
  2. ถ้าได้ เคยมีสิ่งมีชีวิตอาศัยอยู่หรือไม่ ?
  3. และถ้ามี ตอนนี้สิ่งมีชีวิตเหล่านั้นยังอยู่ไหม ?
ยาน Curiosity เป็นวัตถุลำดับที่ 50 ที่ถูกส่งไปดาวอังคาร และเป็น 1 ใน 23 โครงการที่ลงจอดบนดาวอังคารได้สำเร็จ ดร. เปรียบเทียบว่าการส่งวัตถุไปยังดาวอังคารเหมือนการเตะฟุตบอลจากโตเกียวมาลงที่สนามราชมังคลากีฬาสถาน ซึ่งถ้านั่นคิดว่ายากแล้วให้นึกภาพต่อว่าสนามราชมังฯ หมุนด้วยความเร็ว 100, 000 กิโลเมตรต่อชั่วโมง แต่สื่งที่ยากที่สุดคือ 7 นาทีสุดท้ายก่อนที่ยานจะลงจอด


เพราะใน 7 นาทีสุดท้ายของการลงจอดนั้น ยานจะพุ่งไปด้วยความเร็ว 20,000 ไมล์ต่อชั่วโมง ซึ่งยานสำรวจไปยุคต่างๆ จะใช้เทคนิคต่างกันเช่นรุ่นแรกๆ จะใช้ Airbags นั่นคือปล่อยให้ยานลงจอด แล้วให้แอร์แบคทำงาน แล้วปล่อยให้กระเด้งๆ ไปจนหยุด แต่วิธีนี้เมื่อทำการทดสอบในห้องแลปแล้วไม่สามารถใช้กับยาน Curiosity ได้เนื่องจากตัวยานมีน้ำหนักมากเกินไป (พอๆ กับรถยนต์ 1 คันเลยทีเดียว) เลยต้องใช้เทคนิคพิเศษในการลงจอด


หลังจากทำให้ยาน Curiosity ลงจอดได้เป็นที่เรียบร้อยแล้วก็เข้าสู่คำถามที่ต้องการคำตอบนั่นคือ เมื่อ 1000 ปีที่แล้วเกิดอะไรขึ้นบ้างที่นี่ ซึ่งที่ที่จะหาคำตอบได้ก็คือ "หิน" ซึ่งแต่ละชั้นของหินก็เหมือนกับนิยายเล่มหนึ่งที่บอกเล่าเรื่องราวของดาวนั้นๆ แล้วใครจะเป็นคนอ่านมันล่ะ ? "นักธรณีวิทยา" ไงล่ะ แล้วทำไมถึงไม่ส่งคนขึ้นไปบนดาวอังคารล่ะ ดร. กล่าวถึงสาเหตุ 4 ข้อคือ
  1. Technical Problem เพราะยังไม่รู้ว่าจะขนของน้ำหนัก 40 ตันขึ้นไปบนดาวอังคารยังไง
  2. Psychological Problem เพราะยังไม่รู้ว่าร่างกายมนุษย์จะทนอยู่ใน Small Capsule นานกว่า 9 เดือนได้หรือไม่ ?
  3. Biological Problem เพราะยังไม่รู้ว่าการอยู่ในห้วงอวกาศนานขนาดนั้น จะส่งผลกระทบต่อร่างกายมนุษย์อย่างไรบ้าง 
  4. Financial Problem ประมาณการณ์สำหรับการส่งมนุษย์ไปเหยียบดาวอังคารคือ Half Trillion Dollar 
จากสาเหตุของปัญหาที่กล่าวมา NASA จึงได้พยายามที่จะส่ง "หุ่นยนต์นักธรณีวิทยา" ขึ้นไปแทน
หลังจากเราได้เรียนรู้เรื่องโครงการกันพอสมควรแล้ว ดร. ก็กลับมาเรื่องโครงการต่อ ดร. เล่าถึงเรื่องปัญหางบประมาณไม่พอ โดยเริ่มต้นเพียง 100 ล้านเหรียญสหรัฐ แต่พอทีมทำสำเร็จทำให้ได้เพิ่มงบเป็น 250 ล้านเหรียญ ซึ่งทำให้ดร. สามารถทำโครงการสำรวจได้มากถึง 2 โครงการ และ 2 โครงการที่ว่านั้นก็ล้มเหลวอย่างไม่เป็นท่า โดย ดร. ได้กล่าวถึงข้อคิดเกี่ยวกับความล้มเหลวไว้ว่า
อย่ากลัวและสิ้นหวังกับความล้มเหลวที่เกิดขึ้น ถ้าเราได้เรียนรู้ความผิดพลาดจากความล้มเหลวนั้นแล้ว ความล้มเหลวนั้นก็ไม่ใช่ความล้มเหลวทั้งหมดซะทีเดียว
ดร. ในฐานะ Program Manager ของโครงการแนะนำให้ยอมที่จะเสี่ยงกับโครงการที่แม้จะมีความเสี่ยงสูง แต่ถ้ามีความเสี่ยงสูง สิ่งที่ได้กลับมาก็สูงเช่นกัน ดังนั้น ดร. มักจะมองหาโครงการที่ยากที่สุดเสมอ และทำตาม 3 ข้อที่ได้กล่าวในตอนต้น ซึ่งจะทำให้โอกาสสำเร็จมีมากขึ้น

ดร. เล่าว่าในการทำงานที่ NASA ทุกครั้งที่มีการนำเสนอโครงการจะมี Program Manager ของโครงการเก่าๆ อยู่ด้วยเสมอ ซึ่งกล่าวถึงโครงการ Mars Exploration Rover ว่า 1 ปีก่อนที่จะส่งจรวดขึ้นไปนั้น ทีมยังไม่สามารถสร้าง Airbags ได้เลยพร้อมทั้งเจอข้อจำกัดมากมาย การที่จะสามารถส่งวัตถุขึ้นไปบนดาวอังคารได้ภายในทุกๆ 26 เดือนนั้นและโอกาสที่จะปล่อยมีเพียง 21 วันเท่านั้น (ช่วงเวลาที่โลกและดาวอังคารโคจรรอบดวงอาทิตย์เข้าไกล้กันมากที่สุด) ไม่ง่ายเลย สุดท้ายแล้วแม้โครงการนี้จะสำเร็จแต่ดร. ก็ใช้งบประมาณเกินไปกว่า 100 ล้านเหรียญจากตอนที่ขอครั้งแรก ดร. ได้กล่าวถึงปัญหาหนึ่งของการส่งจรวดขึ้นไปคือช่วงที่เกิดพายุทราบบนดาวอังคาร โดยได้ฝากข้อคิดสุดท้ายไว้ว่า
ในโครงการที่มีความซับซ้อนมากๆ นั้น บางครั้งข้อมูลสำหรับการตัดสินใจก็ไม่ครบถ้วนเสมอไป และบ่อยครั้งที่เราจะต้องตัดสินใจจากข้อมูลที่ไม่สมบูรณ์แบบ

Robot Framework by Twin Panichsombat 


การทำ Acceptance TDD นั่นคือ หยิบการ Test มาไว้ก่อนหน้าการ Develop แบบเดียวกับที่เราทำ TDD นั้นแหละ มีทั้งหมด 3 ขั้นตอน 
  1. ทั้ง Tester และ Developer จะต้องคุยกันว่า Test Scenario ต่างๆ มีอะไรบ้าง จะได้รู้ขอบเขตการทำงานที่ชัดเจน และ Test Scenario ที่เขียนขึ้นถ้ามีการยกตัวอย่างต้องชัดเจนมากๆ เช่น ใส่อะไรช่องใน เกิดผลลัพธ์อะไร ไม่ควรยกมาลอยๆ
  2. Develop งานตาม Test Scenario ที่ได้มา
  3. จากนั้น Deliver ของที่ควรจะเป็นให้ Product Owner ดู
ข้อควรระวังคือ … อย่าทำ ATDD Upfront มันเป็นไปไม่ได้อยู่แล้วที่จะเขียน Test Scenario ทั้ง xxxx Features เมื่ออิงตามหลักการทำงานแบบ Agile นั้นเราจะเลือกงานที่คิดว่าจะทำเสร็จใน 1 ช่วงเวลาที่กำหนดไว้ (1, 2 อาทิตย์) โดยงานที่เลือกมาต้องเป็นงานที่ Prioritize โดยลูกค้า (หรือ Product Owner) 

Robot Framework เขียนด้วยภาษา Python (ดังนั้น Syntax ที่เขียนบน Robot จะต้องอิงตามหลักภาษา Python เช่นเรื่อง Indentation) ที่ Wrap-up Selenium Framework เป็น Web Application UI Automation Test 

Practical UX by @apirak

หลายคนมักคิดว่าการทำ UX ในกระบวนการทำ Software นั้นจะทำในขั้นตอนการ Design แบบนี้
แต่จริงแล้วจะเป็นแบบนี้

ผลลัพธ์ของทำกระบวนการต่างๆ ของ UX (User Experience) แล้วจะได้ Requirement และ Wireframe ของ App คร่าวๆ จากนั้นก็จะสามารถที่จะแบ่งงานออกเป็น Product Backlog Item ย่อยๆ ซึ่ง Item เหล่านั้นจะตรงตามความต้องการผู้ใช้ จากนั้นก็นำ Items เหล่านั้นเข้าสู่กระบวนการ Agile (ซึ่งจะส่งมอบงานบ่อยๆ เพื่อเพิ่มความตรงความต้องการของผู้ใช้ขึ้นไปอีก)


Ten Pitfalls to avoid in the Agile Journey: Umar Akhter

  1. Overloaded Release Cycles ห้ามให้มีของที่จะต้องทำเยอะเกินความสามารถของทีม ต้องคุยกันให้ดี และประเมินให้ดีว่าอะไรสำคัญกว่าจริงๆ และดึงมาทำในจำนวนที่เหมาะสม
  2. Certifications is all you need to change the game อย่าให้ Certification (ในที่นี้คงหมายถึงพวก Scrum Master) ทำให้คุณคิดว่าจะมีอำนาจเปลี่ยนอะไรได้ สิ่งสำคัญคือประสบการณ์และการฝึกฝนในการทำหลายๆ Project ต้องเจ็บและต้องเรียนรู้
  3. Engineering Practices are not for me ทุกการกระทำมีเหตุผลของตัวมันเอง ไม่ใช่แค่ทำไปเท่ๆ ไม่ว่าจะเป็นอะไรก็ตาม เช่นเล่น Planning Poker 
  4. Anything can change anytime เนื่องจากข้อ 4 ของ Agile Manifesto ทำให้คนที่ไม่เข้าใจคิดว่า มันเปลี่ยนได้ตลอด สิ่งที่ถูกต้องคือ เราแค่ทำให้มันพร้อมเปลี่ยน แต่ทุกการเปลี่ยนต้องมี Cost เสมอ ทุกการเปลี่ยนจะต้องกระทบกับงานที่ทำอยู่ และงานที่กำลังรอให้ไปทำ
  5. Agile means no documentation คงไม่ต้องอธิบายเยอะ คนเข้าใจผิดเรื่องนี้กันมาก ไม่ใช่เราไม่ทำ แต่เราทำในเวลาที่ควรทำ
  6. Empowered Team means indiscipline อำนาจที่ยิ่งใหญ่ มาพร้อมกับความรับผิดชอบอันใหญ่ยิ่ง (ใช่ปล่าวนะ 555) ก็นั่นแหละ ตามนั้น
  7. Never know when it will be over การทำ Agile คนมักเข้าใจคำว่า "Software ไม่มีวันเสร็จ มีแต่ Improve ขึ้นเรื่อยๆ" แปลว่างานมันไม่เสร็จสักที จริงแล้ว Agile คือ Adaptive Planing เรามีเวลาที่ชัดเจน แต่เราจะใช้เวลานั้นทำให้สิ่งที่เราทำมีประสิทธิภาพมากที่สุดได้อย่างไร
  8. You do Scrum so you're Agile เราต้องเข้าใจว่า Scrum เป็นแค่ Framework หนึ่งของ Agile เท่านั้น ไม่ใช่ว่าเราทำตามหลักการและกิจกรรมของ Scrum แล้วบอกว่าเราเป็น Agile แล้วอย่างแรกคือเราต้องเข้าใจในทุกการกระทำที่เกิดขึ้นว่า "ทำไปเพื่ออะไร ?" และอย่างที่สองคือ "Agile ยังมี Framework อีกหลายตัว จงเลือกให้เหมาะกับที่ทำงานคุณ อย่าฝืนใช้อะไรที่ไม่เหมาะ"
  9. Agile means micromanagement 
  10. Always starched on projects
Agile in Enterprise: The Missing Pieces (P' Non)

ในบริษัทใหญ่ๆ ทำงานกันแบบ .... เอ่อม น้ำตกแหละ การที่เราจะไปเปลี่ยน Mindset การทำงานให้เป็นแบบ Agile ด้วยวิธีการถล่มน้ำตกให้พังในครั้งเดียวนั้นไม่ใช่เรื่องง่ายเลย วิธีหนึ่งที่น่าสนใจคือ เริ่มจากทีมเล็กๆ ทำ Agile และสร้างความสำเร็จด้วยทีมเล็กๆ นั้นให้คนเริ่มเห็น เมื่อสร้างทีมเล็กๆ นั้นได้แล้วก็จะเกิดสิ่งที่จะต้องทำต่อไป 3 ข้อนั่นคือ 
  1. Survive หรือทำยังไงให้เราอยู่รอดท่ามกลางน้ำตกอันใหญ่โตได้ เช่นถ้าพวก Business ไม่เข้าใจการทำงานของเรา เขาจะไม่อิน เราก็ต้องพยายามอธิบายให้เข้าใจ แต่อย่าให้คำว่า Agile เช่น ถ้ามี Requirement มาสักชุดก็คงจะต้องถามว่า อยากได้อะไรก่อน อยากเห็นอะไรก่อน ค่อยๆ ทำแล้วมาดูกันอีกที ว่าสิ่งที่คุณต้องการมันมาถูกทางไหม อย่างไร ? 
  2. Spread เราต้องเริ่มทำให้ทีมอื่น มาทำงานแบบเราให้ได้ เช่นทีมเรา Release ทุกๆ 2 อาทิตย์ แต่ทีมข้างๆ Release ทุกๆ 3 เดือน จะเห็นได้ว่าถ้ามีงานที่ต้องทำร่วมกันก็จะลำบาก (มีนะ พวกที่ Release Cycle เป็นเดือนๆ แล้วเวลาเหลือเยอะ บอกว่า Release ไม่ได้ เพราะยังไม่ถึงรอบ) ในแบบนี้จะเห็นว่าเราทำงานได้เยอะ และเห็นภาพชัดเจนกว่ามาก เราก็อาจจะแย๊บๆ เบื้องบนได้บ้างว่าทีมเราทำงานเร็วและมีประสิทธิภาพกว่าเพื่อ Force อีกทีมในทางใดทางหนึ่งให้มาทำงานแบบเดียวกัน
  3. Conquer เมื่อเราสามารถ Spread Agile Mindset ไปสู่วงกว้างในบริษัทได้แล้ว สิ่งที่ (อาจจะ)เกิดขึ้นคือทุกคนจะคิดว่าทีมตัวเองสามารถทำได้ทุกอย่าง และเมื่องานของแต่ละทีมมี Dependency กันก็อาจจะทำให้เกิดเหตุการณ์ที่ไปยุ่งกับงานคนอื่นก่อน Release Cycle จะมาถึง 
อีกเรื่องที่พี่นน หยิบมาแชร์คือเรื่องราวเกี่ยว Enterprise คือ
  • Organization Transformation เมื่อ PO (Product Owner) ถาม Team ว่าเร่งได้ไหม แนวคิดคือ ถ้าตอบได้จะดูแปลก หมายความว่า Team ไม่ได้ทำงานเต็มประสิทธิภาพตั้งแต่ต้น อีกเรื่องคือเป้าหมายของทุกคนในบริษัทต้องชันเจนเสมอ ยกตัวอย่างเช่น "เราจะต้องให้ลูกค้าได้เห็นเว็บไซต์ให้เร็วที่สุด" หรืออย่างของพี่นนคือ "Release Cycle ของทุกทีมในบริษัทคือทุกอาทิตย์" เป็นต้น
  • Legacy Culture พี่นนยกตัวอย่างเรื่องเล่า "การทดสอบจิตวิทยาหมู่ของลิง" ลองสังเกตุว่าสิ่งที่คุณเห็นและทำอยู่ทุกวันนี้ มีเหตุผลมารองรับดีพอหรือไม่ ? ไม่ใช่แค่ทำตามๆ กันไปโดยที่ไม่เคยตั้งคำถามใดๆ เลย
  • Remote Team ความไกลในที่นี่ไม่ใช่แค่เรื่องระยะทาง แต่เป็นเรื่องเวลาเราจะ Manage อย่างไร ถ้าเวลาไม่ตรงกัน ดังนั้นการทำงานที่มี Protocol ตรงกัน ถ้าทำได้จะดีมากเนื่องจากอีกคนหลับ อีกคนก็ยังทำงานต่อได้
สุดท้ายพี่นน ได้ทิ้งข้อความเท่ๆ ไว้ว่า
วิธีการเขียนโปรแกรมที่ดีคือ เขียนให้เรียบง่ายที่สุดจนไม่เกิดข้อผิดพลาด หรือเขียนให้ซับซ้อนที่สุดจนมองไม่เห็นข้อผิดพลาด 

Code Quality Inspection with Sonar by @nuboat

ถ้าเรากล่าวถึง Code ที่มีคุณภาพ เราจะดูทั้งหมด 7 ข้อด้วยกันประกอบด้วย
  1. Coding Rules แต่ละภาษาที่รูปแบบการเขียนของตัวเอง และเป็นสิ่งที่เราควรเรียนรู้เป็นอย่างแรกเมื่อไปเขียนภาษานั้นๆ เช่นเรื่องการตั้งชื่อ การวรรคตอน
  2. Architecture Design 
  3. Unit Tests Coverage เพื่อความถูกต้องของ Function ที่เราเขียนไป ดังนั้นก็ต้อง Test เสมอ ซึ่งจะคำนวณออกมาเป็น % จากโค้ดทั้งหมด
  4. Duplicated Code โค้ดที่ซ้ำ แยกออกมาเป็น Function หรือใช้หลักการต่างๆ เช่น Polymorphism มาช่วยก็ได้ (ในบางกรณีที่สมควร) อย่าให้เกิดขึ้นเยอะ
  5. Potential Bugs หลายครั้งกับ Bugs ที่อาจจะเกิดขึ้นได้โดยความไม่ตั้งใจของ Programmer
  6. Complexity ความซับซ้อนของ Algorithm ที่ใช้ โดยมากคือการที่เขียนโดยไม่คำนึงถึง BigO และซ้อนเงื่อนไขกันมากเกินไป 
  7. Comment บางอย่างจำเป็น บางอย่างก็ไม่จำเป็น Comment บางชนิดไม่ควรมี สิ่งที่ควรทำคือ Self-Documented Code 
โดย Sonar จะช่วย Inspect ให้เราเกือบทุกอย่างที่กล่าวมายกเว้น Architecture Design โดย Sonar จะทำหน้าที่วิเคราะห์และแสดงข้อมูลต่างๆ เพื่อให้เราแก้ไข Code ของตัวเองเพื่อเพิ่มคุณภาพให้มากขึ้น

Popular posts from this blog

12 วิธี การบริการและดูแลลูกค้าในร้าน Starbucks

[Android Dev] การติดตั้ง Eclipse+AndroidSDK เพื่อพัฒนาโปรแกรมบน Android

5 TED Talk ที่จะช่วยให้คุณทำงานดีขึ้น