Fear Driven Development

จะเกิดอะไรขึ้นถ้า Developer ต้องทำงานอยู่ภายใต้สิ่งแวดล้อมที่มีความกลัวครอบงำ…

ทีมที่ทำงานด้วย Fear Driven Development (FDD) นั้นจะทำให้ Developer นั้นรู้สึกว่า

  • กลัวที่จะทำผิด
  • ไม่กล้าแก้ Code
  • ไม่กล้า Refactor
  • ไม่กล้า Commit หรือ Push Code
  • ไม่กล้าเปลี่ยน Design
  • ไม่กล้าท้าทาย UI/UX หรือ Product เพราะกลัวได้งานเพิ่ม
  • ไม่กล้ารับปาก เพราะกลัวทำไม่ได้
  • ไม่กล้าออกความเห็น เพราะกลัวต้องรับผิดชอบกับ Idea ตัวเอง
  • ไม่กล้าเปลี่ยน Tools หรือ Framework
  • กลัวว่า Software นั้นจะมี BUG ซึ่งเห็นเหตุผลให้เกิด Process ต่างๆมากมาย
  • และสุดท้ายทำให้ Developer ใช้เวลาไปกับงาน Admin/Process มากกว่าการเขียน Code….

ความกลัวและไม่กล้าต่างๆเหล่านี้ทำให้ Project ไปได้ช้าลงแน่นอน รวมถึงทำให้เกิด Over-Engineer (การ Design Software เกิด Use case ที่จะเกิดขึ้นจริง) และกลัวการ Estimate ซึ่งเป็นการบอกเวลาว่า Project นี้จะเสร็จตอนไหนกับเหล่าท่านๆผู้บริหารระดับสูงทั้งหลาย จึงทำให้การ Estimate (ประเมิณ) กลายมาเป็นการลงรายละเอียดซึ่งใช้เวลาเยอะมากจนกว่าจะได้ตัวเลขออกมาก

วัฒนธรรมกลัวตกงาน

เป็นลักษณะหนึ่งของ FDD ซึ่งเกิดจากทีมใช้งาน Developer อย่างหนักและมีการกดดันกันว่าถ้ามีปัญหากับโปรเจคอาจจะโดนไล่ออกได้ ซึ่งการทำแบบนี้ไม่อาจจะทำให้ทีมนั้นมี Productivity ที่ดีได้ รวมทั้งยังขาด Innovation ด้วยรวมถึงทำให้เกิดความกดดันต่างๆและทำให้อัตรา Turn-Over สูงขึ้น ซึ่งในทีมที่มีวัฒนธรรมแบบนี้ส่วนใหญ่ก็จะมีการยกย่องคนที่เรียกว่า Hero(Hero Driven Development) ซึ่งเป็นคนที่ทำให้แต่ละ Release นั้นผ่านไปได้จะได้รับการยกย่องและสุดท้ายก็จะกลายเป็นว่าทีมนั้นต้องการ Hero ตลอดเวลานี่แหละคือปัญหา!

รวมถึงวัฒนธรรมการ Blame เช่นเมื่อเวลามีปัญหาเกิดขึ้นก็หาคนทำผิดแทนที่จะช่วยกันแก้ปัญหาให้ User…

วัฒนธรรมกลัวการแก้ Code

อีกสิ่งที่น่ากลัวของการพัฒนา Software ซึ่งก็คือ Developer ไม่กล้าแก้ไข Code ซึ่งอาจจะเป็นเพราะว่า Code นั้นเก่ามากๆซึ่งปกติน่าจะเกิดจากการที่ไม่เข้าใจ Code ชุดนั้นมากกว่า ลักษณะของ Code ประเภทนี้คือมันก็ work ดีเกือบทุก case แต่ถ้าจะต้องแก้ Developer ก็จะกลัวจะเกิดผลที่คาดไม่ถึง รวมทั้งเกิด Bug ต่างๆ และที่เลวร้ายไปกว่านั้นคือไม่กล้าแก้ Code ของตัวเอง!

สุดท้าย

ส่วนตัวผม คิดว่าสิ่งที่อาจจะน่ากลัวกว่าก็คือการกลัวการเปลี่ยนแปลงโดยเฉพาะ Developer เพราะอย่างที่รู้กันอยู่แล้วว่า Software Development นั้นเทคโนโลยีหรือ Tools ต่างๆมาเร็วไปไว ซึ่งการที่เราไม่ยอมรับการเปลี่ยนแปลงตรงนี้ก็จะคงอยู่แต่โลกเดิมๆ โดยไม่ได้มองหาสิ่งที่จะมาเพิ่ม Productivity ความรู้ใหม่ๆ เพื่อช่วยให้เราเก่งขึ้นและทำงานได้ดีขึ้น 🙂

ถ้า Developer ไม่กล้าแก้ Code แล้วใครจะกล้าแก้ล่ะ???

เรียบเรียงจาก:

http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx

 

Advertisements

Hero Driven Development

วันนี้ผมจะเล่านิทานให้ฟัง….

กาลครั้งหนึ่งนานมาแล้ว ณ หมู่บ้านที่สงบสุขท่ามกลางชีวิตที่เรียบง่ายของชาวบ้านที่ใช้ชีวิตอย่างมีความสุข

Screen Shot 2559-06-26 at 6.33.21 PM.png

สิ่งที่ไม่คาดคิดก็เกิดขึ้น ได้มีมังกรวายร้ายปรากฏตัวขึ้นมาเพื่อทำลายหมู่บ้าน

Screen Shot 2559-06-26 at 6.33.52 PM

ชาวบ้านได้ตื่นตระหนกและทำการสวดอ้อนวอน

Screen Shot 2559-06-26 at 6.35.36 PM.png

ทันใดนั้นเองก็ได้มี คนๆนึงที่ใครๆก็เรียกเค้าว่า ฮีโร่ ปรากฏกายขึ้นมา พร้อมประกายแห่งความหวัง

Screen Shot 2559-06-26 at 6.37.02 PM.png

แน่นอนว่าด้วยความเก๋าของฮีโร่ + กำลังใจอย่างเต็มเปี่ยมของชาวบ้าน
เค้าก็จัดการมังกรร้ายได้อย่างง่ายดาย…

Screen Shot 2559-06-26 at 6.37.34 PM.png

ในที่สุดชาวบ้านก็กลับมาใช้ชีวิตอย่างมีความสุขเช่นเดิม

Screen Shot 2559-06-26 at 6.33.21 PM.png

HAPPY ENDING

(?)

นิทานที่ผมเล่าไปนั้นสามารถตีความให้เกี่ยวกับการพัฒนา Software แบบ Hero Driven Development ได้

ซึ่งนั่นก็คือ..ในทุกครั้งที่มีแหตุการณ์ไม่ปกติ เช่น ปัญหาร้ายแรง/critical bugs/server ล่ม  ทีมงานทุกคนในทีมก็จะเฝ้ารอให้มีคนใดคนนึงที่พวกเค้าเชื่อว่าเก่งที่สุดดังเช่นฮีโร่ จะออกมาแก้ปัญหานี้ให้พวกเค้า และพวกเค้าจะทำหน้าที่นั่งเชียร์ คอยหาขนม และให้กำลังใจอยู่ห่างๆ อย่างห่วงๆ(?)
และเมื่อปัญหานี้ได้ถูกแก้ไป ทีมงานก็กลับไปทำงานตามปกติจนกระทั่งจะเกิดเหตุการณ์นี้ขึ้นอีกในอนาคต….

ปัญหาจริงๆก็คือทีมงานไม่เกิดการเรียนรู้และการแก้ปัญหาด้วยตัวของพวกเค้าเอง ซึ่งถ้าเกิดปัญหาอีกเค้าก็จะเฝ้ารอคนมาแก้ไขให้

ปัญหาเหล่านี้ไม่ใช่ปัญหาของฮีโร่แต่เป็นปัญหาของทีม!

การแก้ปัญหาพวกนี้ต้อง
– ให้โอกาสทีมได้เรียนรู้ ลองผิดลองถูก
– มีการโค๊ชที่ดีจากเหล่าฮีโร่
– นำปัญหาเรื้อรังออกวางไว้บนหน้ากระดาน ไม่ใช่เก็บไว้ที่ใครคนใดคนหนึ่ง และหาทางแก้ไขด้วยกันทั้งทีม
– และที่สำคัญ ฮีโร่ ต้องการเวทีไว้สำหรับพัฒนาฝีมือ การสู้กับมังกรแบบเดิมๆจะไม่ทำให้ฮีโร่เก่งขึ้น ฉะนั้นฮีโร่ควรมีสนามแข่งที่ทำให้พวกเค้าเก่งขึ้นไปอีก

และสุดท้ายหวังว่า เราจะสร้างหมู่บ้าน Super HERO ไปได้ด้วยกัน

เรียบเรียงจาก
http://carlokruger.com/?p=35
http://highlevelbits.com/2014/08/hero-driven-development.html

Continuous Deployment ของ Netflix

หลังจากที่ได้พูดถึงการทำ Continuous Deployment (CD) ของ Instragram ไปใน บทความที่ผ่านมา (link)

มาคราวนี้ทาง Netflix ซึ่งเป็น บริษัทที่ให้บริการด้านดูหนังและซีรีย์ออนไลน์ที่มีสมาชิกกว่า 75 ล้านคน

ทาง Engineer ของ Netflix ก็ได้มาแชร์ข้อมูลเกี่ยวกับการ Build http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html

เราลองมาดูกันครับ

Netflix นั้นมีหรือ Workflow ตามรูปนี้

pasted image 0.png

ซึ่งกล่องสีขาวคือ Process ของการทำงานจากซ้ายมือไปขวามือ ส่วนสีฟ้าคือ Tools ที่ใช้

ก่อนที่จะลงรายละเอียดแต่ละขั้นตอนทาง Netflix ได้เน้นย้ำไว้ว่าสิ่งที่สำคัญที่ทำให้ Solution นี้เกิดขึ้นมาได้นั้นมาจาก

  1. วัฒนธรรมของบริษัท : ซึ่งก็คือ ความอิสระและความรับผิดชอบ เพื่อที่จะเน้นย้ำให้ทุกคนนั้นได้คิดถึง Solution หรือ Tool ที่ดีที่สุดในการแก้ปัญหาต่างๆได้อย่างเหมาะสม ซึ่ง Tool ที่ดีนั้นควรจะต้อง Add Value และช่วยลดขั้นตอนการทำงานด้วย ซึ่งทาง Engineers นั้นสามารถคิดหา Solution ได้เสมอและต้องคำนึงถึงการดูแลระบบด้วย
  2. Cloud : ทาง Netflix นั้นได้ทำการย้ายระบบจาก Data Center based ไปใช้ Amazon Webservice แทน
  3. Microservices : Netflix ได้เปลี่ยน architecture จากการทำงานด้วยระบบขนาดใหญ่ (monolithic) ไปเป็น Microservices แทน ซึ่ง Microservices นั้นคือการออกแบบให้ Services หรือ API นั้น เล็ก ไม่ซับซ้อน และเป็นอิสระต่อกัน เพื่อที่จะได้แก้ไขแต่ละ Service ได้ง่ายขึ้น

เริ่มจาก

  • Code ทำการ build และ test บนเครื่องของ Developer โดยใช้ Nebula (Tools ของ Netflix เอง)
  • Code Check-in : การ Commit Code เข้า Master branch โดยใช้ Git
  • Continuous Integration : ใช้ Jenkins ในการสั่งให้ Nebular ทำงาน ซึ่งสิ่งที่เกิดขึ้นในขั้นตอนนี้จะประกอบด้วย การ build, test, และการทำ package ที่ไว้ใช้สำหรับการ deploy
  • Bake : ในการ deploy ของทาง Netflix นั้นจะเริ่มจากการ สร้าง Image ของเครื่องใหม่บน Amazon  โดย Image นั้นได้มีการติดตั้งระบบพื้นฐานไว้แล้วเช่น Linux, มี Tools หรือ services ต่างๆพร้อมที่จะใช้สำหรับการติดตั้ง package ใหม่
  • Deployment (Deploy จนถึง Live) : ทาง Netflix ใช้ Spinnaker ช่วยในการทำ pipeline ในการ deploy ต่างๆเช่น เครื่อง Test การจัดการเกี่ยวกับการ deploy หลายๆทวีปพร้อมกัน การทำ canary release เพื่อให้ users ทดลองใช้

สุดท้ายนี้ Netflix ยังได้พูดถึงความท้าทายที่ทางทีมกำลังแก้ไขด้วย เช่น

  1. ปัญหาด้าน dependnecies ของ Java ซึ่งทางทีมก็ได้ปรับปรุงให้ดีขั้นแล้ว
  2. ขั้นตอนของ Bake ให้เวลาเยอะไป ซึ่งปัจจุบันขั้นตอนหลังจาก Code Check-in จน Deploy เสร็จนั้นใช้เวลา 16 นาที แต่เวลา 7 นาทีนั้นใช้ในขั้นตอน Bake ซึ่งเป็น 44% ของเวลาทั้งหมด

มาดู Continuous Deployment ของ Instagram กัน

เมื่อต้นเดือนเมษายน ทาง Engineer ของ Instagram ได้เขียนบนความของการทำ Continuous Deployment ภายในระบบของเค้า http://engineering.instagram.com/posts/1125308487520335/continuous-deployment-at-instagram

เราจะมาดูกันว่ามีอะไรน่าสนใจบ้าง [ผมแปลแบบสรุปไปด้วยนะครับ ดังนั้นอาจจะไม่ใช่การแปลแบบแป๊ะๆ]

ทำไปทำไม?

Continuous Deployment นั้นมีข้อดีมากมายๆนะครับ ใครไม่รู้จักคำนี้และทำงาน Software Development ที่มีระบบขนาดกลาง/ใหญ่ (ที่มี Developers มากกว่า 10 ละกัน) ควรจะลองศึกษาดู

  1. ทำให้ Developers/Engineers ทำงานได้เร็วขึ้น สามารถที่จะแก้ไขอะไรได้รวดเร็วมากขึ้น
  2. ทำให้ช่วยในการหาข้อผิดพลาดที่เกิดจากการแก้ไขตัวระบบได้เร็วขึ้น จากที่จะต้องมาดูสิ่งที่แก้ไขที่มีเยอะแยะ ก็มาดูแค่รายครั้งที่มีการ Deploy ในแค่ละครั้ง
  3. สิ่งที่ Commit แล้วมีปัญหาก็จะเจอได้รวดเร็วและยังแก้ได้เร็วด้วย

การนำไปใช้

ทาง Instagram นั้นใช้วิธี iterative approach ก็คือไม่ใช้ว่าทำระบบที่เดียวเสร็จแล้วใช้งานทันที แต่จะใช้การค่อยๆพัฒนาทีละจุดไปเรื่อยๆจนกระทั่งเสร็จสมบูรณ์

ก่อนหน้านี้เป็นยังไง

ก่อนที่ทาง Instagram จะมี Continuous Deployment นั้น Engineer จะใช้การ Deploy ตามใจและเวลาที่จะมีการแก้ไข รวมถึงต้องรู้การเช็ค Log และเริ่มการ Deploy ที่ละเครื่องเพื่อทำการทดสอบก่อนที่จะ Deploy ไปที่เครื่อง Servers ที่เหลือ

การทดสอบ/เทส

เริ่มจากการเพิ่มการเทสซึ่งเป็น Script ง่ายๆที่ทาง Engineer ต้องทำจากที่ต้องทำบนเครื่องที่ตั้งใจจะลงบน Production ก็เปลี่ยนมาเป็นทำการ Deploy ที่เครื่อง Canary Machine(เครื่องสำหรับให้ users ทดลองใช้)

จากนั้นมีการสร้างเครื่องที่ทำการทดสอบจาก Git – Master โดยใช้ Jenkins เมื่อเทสของ version ไหนผ่านก็จะมีการแนะนำว่าควรใช้ version นั้นแทนที่จะเป็น version ล่าสุด

การทำงานอัตโนมัติ

เนื่องจากระบบข้างบนแล้ว สิ่งที่ยังเหลือว่าจะต้องให้คนตัดสินใจก็คือ

  1. จะเอา version ไหนไปใช้ในการ Deploy – ซึ่งทาง Instagram ก็เลือกใช้ version ที่ผ่านการทดสอบและมีการเปลี่ยนแปลงไม่เกิน 3 commits
  2. การ Deploy สำเร็จหรือไม่ – หลักการก็คือถ้าไม่สามารถ Deploy ไปที่ servers ได้ด้วยอัตรา 1% จะถึงว่าไม่สำเร็จ

ปัญหา

หลังจากที่ทาง Instagram ได้ทำมาก็พบว่ามีปัญหาใหญ่ๆคือ

เทสไม่ผ่าน

หลายๆครั้งที่ทาง Engineer ได้พบว่ามีการแก้ไข software ที่ทำให้การเทสไม่ผ่าน ซึ่งทำให้ไม่สามารถ Deploy ได้ ซึ่งการแก้ไขนั้นต้องทำการ revert แบบ Manual รวมถึงการเทสที่ใช้เวลานานและไม่ค่อยเสถียร ซึ่งทาง Engineer ก็ได้ทำการแก้ไขให้เทสได้เร็วขึ้นเป็น 5 นาทีจาก 15 นาที

สิ่งที่จะ Deploy

ทาง Instagram พบว่าสิ่งที่จะต้อง Deploy มีมากในคิว เนื่องจากว่าระบบ Canary สามารถดักจับปัญหาได้(ทั้งปัญหาจริง และบั๊ก) ซึ่งทำให้การ Deploy หยุด และต้องมีการแก้ไขด้วย Engineer เพื่อให้ระบบ Automation ทำงานต่อได้ ซึ่งทำให้เกิดการล่าช้าของการ Deploy สิ่งใหม่ๆ ซึ่งทาง Engineerได้แก้ไขปัญหานี้ด้วยการปรับปรุงเงื่อนไขในการทำ Automation deploy ให้ทำงานได้ดีมากขึ้น

หลักการที่แนะนำ

ทาง Instagram ยังได้แนะนำว่าถ้าอยากได้ระบบแบบของเค้า ให้ลองตามนี้

  1. การเทส

    ระบบเทสต้องเร็วและครอบคลุม แต่ไม่จำเป็นต้องสมบูรณ์ และต้องถูกใช้งานบ่อยๆ ทั้งตอน Code Review, ก่อนการ Deploy และหลังจาก Deploy

  2. Canary

    ต้องมีการทำ automated canary เพื่อที่จะป้องกันไม่ให้มีการ commit ที่ไม่ดีเข้าไปอยู่ในสิ่งที่จะ Deploy ลงบน Server ทุกเครื่อง

  3. Automated Test สำหรับการทำงานปกติ

    ไม่จำเป็นต้องมี automate ทั้งหมด แต่เฉพาะสิ่งที่สำคัญจริงๆและเป็นสิ่งที่เกิดขึ้นในเหตุการณ์ปกติ

  4. ทำให้คนรู้สึกมั่นใจ

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

  5. คิดไว้เลยว่าต้องเจอการ Deploy ไม่สำเร็จ

    อาจจะมีโอกาสที่จะมี version ที่ไม่ดีหลุดออกไปบน Production ซึ่งเป็นเรื่องที่ยอมรับได้ แต่ระบบจะต้องตรวจเจอได้เร็วและสามารถแก้ไข้แต่เร็วด้วย

ขั้นต่อไป

  1. ทำให้เร็วยิ่งขึ้น
  2. เพิ่ม Canary
  3. เพิ่มข้อมูล
  4. ปรับปรุงการดักจับข้อผิดพลาด

ว่าด้วยเรื่องการเพิ่ม Productivity ของ Developers

หลายๆคนอาจจะเคยได้ยินคำว่า Productivity ถ้าแปลตรงตัวเป็นภาษาไทยก็แปลว่า “ความสามารถในการผลิต”
แล้วการเพิ่ม Productivity คืออะไรในแง่ของการพัฒนา software

ผมคิดว่าหน้าที่ของ Software Engineer, Software Developer, Programmer(เรียกรวมๆว่า Developer ละกัน) ก็คือการทำให้ software ที่เป็นไอเดีย สามารถออกมาเป็น Program หรือ App ที่มันทำงานได้จริงอย่างมีประสิทธิภาพ

การที่เหล่า Developer นั้นต้องมานั่งหน้าคอมแล้วทำงานที่ไม่เกี่ยวกับการพัฒนา software สิ่งเหล่านั้นเราควรจะคิดว่ามันเป็นสิ่ง developer ไม่ควรจะเสียเวลาด้วยหรือควรจะเสียเวลาให้น้อยที่สุด ยกตัวอย่างเช่น การประชุมโดยที่ developer ไม่มีส่วนร่วม, การทำงานเดิมๆซ้ำๆ หรือแม้กระทั่งการ copy files ทุกวัน วันละ 2-3 รอบแล้วต้องนั่งรอ

ยกตัวอย่างเช่นถ้างานทุกวันของ Developer คือการ compile source code ที่ให้เวลา 10 นาทีต่อการ compile 1 ครั้ง
วันนึง Developer ต้อง compile ประมาณ 10 รอบ หมายความว่าในแต่ละวัน Developer จะเสียเวลา compile ไป 100 นาที = 1.5 ชม กว่าๆ

ถ้า Developer มีเงินเดือน 30,000 บาท หรือประมาณ 1,500 บาทต่อวัน ( นับ 20 วันทำงาน ) หมายความว่าเราอาจจะเสียเวลาของ Developer ใช้ในการ compile code ประมาณ 300 บาทต่อวัน หรือ 6,000 บาทต่อเดือน

ถ้าเราเอาเงินจำนวนนี้มาอัพเกรดเครื่อง Computer ให้ Developer เพื่อที่จะลดเวลาจาก 10 นาทีเป็น 5 นาที หมายความว่าเราจะมีเวลาให้ developer ใช้ในการทำงาน(เขียนโปรแกรม หรือ ออกแบบระบบให้ดีขึ้น) ซึ่งจะมีประโยชน์มากกว่าการรอ compile….