Thailand Agile Coach Meetup 2015

Thailand Agile Coach Meetup 2015

สวัสดีครับทุกๆท่าน วันนี้วันที่ 11 เดือนพฤศจิกายน 2558 เป็นวันที่คนสนใจ Agile หรือเคยเอา Agile ไปใช้มารวมตัวกันเพื่อพูดคุย รับฟัง ปัญหา ข้อซักถาม ข้อเสนอแนะ กันในวัน Thailand Agile Coach Meetup ประจำปี 2015 และเราก็จะจัดกันทุกๆไตรมาสกันต่อไป

บรรยากาศก่อนเริ่มงาน วางเก้าอี้ ล้อมวง ตามจำนวนคนที่ register กันไว้

แนะนำตัว ประสบการณ์และเรื่องที่อยากพูดคุยกันในวันนี้

ได้ประเด็นออกมา

จัดกลุ่มกันหน่อยว่าประเด็นต่างๆ นี้แบ่งเป็นอะไรออกมาได้บ้าง ที่ออกมาได้นั้นเช่น กลุ่มองค์กร กลุ่มทีม กลุ่ม Scrum Master เป็นต้น

ตกลงกันว่าเราจะพูดทีละเรื่อง โดยเรื่องๆนึงจะพูดคุยกัน 50 นาที อีก 10 นาทีพัก แล้วมาต่อเรื่องต่อไป

ขอนิยามสั้นๆหน่อยว่า Agile คืออะไร

เริ่มเลยช่วยกันเลือกว่าเราจะยกเรื่องอะไรมาพูดคุยกันเรื่องแรกดี ตกลงกันได้เราจะเอาเรื่องว่า

องค์กรจะไป Agile

- ทำไม

- อย่างไร

ให้ยั่งยืน

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

อย่างไรละที่เอามาใช้กัน ทดลองซะโปรเจคบ้าง หรือศึกษาเพิ่มเติม ไปอบรม ไปเรียนกัน เรื่อยๆกันทุกๆคน ทุกๆระดับขององค์กร

พูดคุยกันใน session นี้ก็ครบ 50 นาทีละ ไปเบรคกันก่อน กลับมาก็ถามทุกคนว่าจะต่อเรื่องนี้ไหม หรีอไปเรื่องอื่นกันเลย ทุกคนตกลงกันว่าต่อเรื่องนี้

แล้วยั่งยืนด้วย ความยั่งยืนนี้ยังคงถกเถียงกันอยู่ เนื่องจากความเป็นไปได้นั้นมีตัวแปรเยอะมาก ที่สนใจพิเศษเห็นจะเป็นเรื่อง mindset ที่ต้องให้ทุกคนในองค์กรเห็นไปในทางเดียวกัน รู้จัก เข้าใจ Agile เหมือนกัน

มีแตกประเด็นว่า แล้วที่ไม่ยั่งยืนคืออะไร?

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

พักเที่ยงกันเถอะ

บ่ายชั่วโมงแรกต่อกันเลยของตัวเองเลยเรื่อง จะเอา Engineering Practice ใส่ลงทีมในจังหวะไหน

ประเด็นปัญหาอยู่ที่เรารู้ถึง Risk และ Issue ที่จะเกิดขึ้นในอนาคตของทีม แต่ทีมยังไม่รู้ตัว หรืออาจจะคิดว่าค่อยทำก็ได้ แชร์ความคิดกันก็ได้ออกมาว่าลองสร้างภาพสิ ลองให้เขา pair programming ลอง review บ่อยๆ ถ้าทำ CI CD ด้วยก็ลองใช้กราฟที่เป็น report ของพวกนี้มาให้ทีมดู แล้วลองดูว่าทีมเห็นอะไรไหม ก็ค่อยแนะนำไป หรือจะปล่อยให้เขาเจอถึง Issue ไปเลยก็ได้ถ้าเรารับผลลัพธ์ของงานได้แล้วทีมได้เรียนรู้ แต่การพูดนี้ก็ต้องใช้คำถามที่เป็น Powerful Question หน่อยละถึงจะได้ผล

ถ้าพูดว่า ทำยาก แสดงว่า ทำได้

อยากได้ไอเดีย การวัดว่าทั้งปีทีมทำงาน success แค่ไหน

การวัดว่าทั้งปีทีมทำงานสำเร็จแค่ไหน?

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

การเปลี่ยนตำแหน่ง สิ่งที่ทำเดิม มาเป็น ผู้นำทางจิตวิญญาณ

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

Outside-In และ Inside-Out

ปิดท้ายด้วยเล่า SAFe และ LeSS

ขอขอบคุณทุกคนที่มาร่วมงานและเสนอแนะแสดงความคิดเห็นกันน่ะครับ ได้ความรู้มากกว่าเดิมเยอะเลย

บอกเลยงานนี้ได้สาระความรู้ความบันเทิงของ Agile มากมาย บางเรื่องที่พูดไม่ได้ในบล๊อก แต่ฟังได้น่ะที่งานนี้

เจอกันใหม่เดือนกุมภาพันธ์ 2559

ร่วมทำ Product Discovery กับทีม PO; Part II

สวัสดีครับ วันที่ 10 พ.ย. 2558

ร่วมทำ Product Discovery กับทีม PO; Part II

       วันนี้เป็นวันที่สองของการทำ Product Discovery บรรยากาศเหงาลงไปเนื่องจากคนมาน้อยลง ซึ่งไม่ดีน่ะครับแบบนี้ เพราะอยู่กันไม่ครบองค์ แต่ก็ยังทำไปได้อยู่ในส่วนที่เหมือนกันครับ

       ช่วงเช้าเริ่มโดยการมาเล่ารูปแบบการทำงานแบบเดิมเป็นอย่างไรบ้าง มีใครสัมพันธ์กับใคร ยังไง ข้อมูลไหลไปแบบไหนบ้าง ให้น้องๆทีมพัฒนาเห็นกัน เพื่อให้เห็นสภาพปัจจุบัน และมองเห็นสิ่งที่เขาจะทำต่อไปว่าจะมาช่วยแก้ไขปัญหาเก่านี้ได้อย่างไรด้วย (เมื่อทีมพัฒนาทำสำเร็จจะทำให้เขาภูมิใจที่ได้ช่วยแก้ไขปัญหาได้ อย่าลืมที่จะชมเชยน่ะ)

       ทีมพัฒนาเอา tool ที่จะมาช่วยพัฒนาให้ทีม PO เห็นกันว่า น้องๆทีมพัฒนาเขาต้องเจออะไรบ้างกับ flow แต่ละหน้า

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

       ก็เริ่มงานกันเลย เอา Flow แรกของเมื่อวานหยิบมาทำกัน โดยการทำนี้คือการ design หน้าจอออกมาเลยครับ แต่บนกระดาษน่ะ ไม่ใช่ในจอคอม เพื่อให้ง่ายต่อการแก้ไข โยกย้ายได้ง่าย 

       แบ่งออกเป็น 2 กลุ่ม กลุ่ม 1 ทีม PO และกลุ่ม 2 ทีมพัฒนา เมื่อแยกกันทำแล้ว ผลที่ออกมา ว่า Programmer ออกแบบก็หน้าจอจะแข็งๆ ดูยาก เล่นยาก ตาม logic เขา ส่วนฝั่ง PO ก็ลงรายละเอียดเยอะกว่าเลยละ 

       ตรงนี้จะสลับกันวิจารณ์กันน่ะครับ โดยให้เขียนลง Post-it ไว้ ว่าชอบ ไม่ชอบ เสนอแนะอะไร แล้วรับฟังกัน ต่างคนต่างคิดวิเคราะห์ไว้ แล้วรวมกันสิว่าตรงไหนดีหยิบมา รวมร่างกัน ก็จะได้ออกมาระดับนึงละ

       พักเที่ยงกันก่อน แล้วกลับมาใหม่

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

       ต่อมาก็หยิบ flow ที่เกี่ยวข้องกันมาทำกัน โดยแบ่งกลุ่ม 2 กลุ่ม แต่ให้คละคนเข้ากัน เพื่อให้เกิดการ discuss กันและเห็นร่วมกันได้ทั้ง Dev และ PO แล้วก็ design เหมือนเดิมออกมาเลยครับ

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

       วันนี้ก็จบด้วย Flow ใหญ่ 1 ตัวที่ประกอบไปด้วยหลายๆ Flow ย่อย และ Estimate คร่าวๆ

       การทำ Product Discovery นี้ทำให้ทุกๆฝ่าย USER,PO,DEV มองเห็น เข้าใจ ปัญหาร่วมกัน เห็นอกเห็นใจซึ่งกันและกัน มองเห็นความเป็นไปได้ร่วมกัน จนทำให้งานที่ออกมานี้จะเกิดการแก้ไข(BUG, Rework) ออกมาน้อยที่สุด 

       เสียเวลากับ Product Discovery มากๆ ดีกว่าการแก้ไขโปรแกรมแบบไม่รู้จบ

       การคุยกัน ทำงานกันแบบนี้นั้น เรื่องงาน การ discuss งานนั้นไม่ใช่ปัญหาของการทำเท่าไรนัก แต่จะไปอยู่ที่คำพูดคำจาที่คุยกันนั้น เข้าใจซึ่งกันและกันแค่ไหน เคารพในการพูดของเขาไหม คือตั้งใจฟังที่เขาพูด ไม่ใช่ตั้งใจฟังที่เราคิด รับฟังความคิดเห็นแค่ไหน มองเป้าหมายขององค์รวมหรือตัวเอง 

       การควบคุมให้ Focus กับงานที่ทำ ไม่ออกนอกเรื่องไปมาก เพราะยิ่งนอกเรื่องยิ่งเสียเวลา

ร่วมทำ Product Discovery กับทีม PO; Part I

สวัสดีครับ วันที่ 9 พ.ย. 2558

ร่วมทำ Product Discovery กับทีม PO; Part I

       วันนี้เป็นวันแรกของการทำ Product Discovery ครับ ซึ่งคนที่เข้าร่วมนั้นก็มีดังนี้ Product Owner (PO), Stockholder หรือ User, Development Team(Developer, Tester, SA), Scrum Master

      โดยปกติคนที่จะพาทำกิจกรรมต่างๆของการทำ Product Discovery นั้นต้องเป็น PO ครับ แต่ถ้า PO ยังใหม่กับการทำแบบนี้ Scrum Master ก็เข้ามามีบทบาทได้ เพื่อช่วย PO ทำงาน

      เริ่มกันเลย SM แนะนำให้ทุกคนรู้จักการทำ Product Discovery ก่อนว่าคืออะไร มีไว้เพื่ออะไร เพื่อความเข้าใจให้ตรงกันว่า วันนี้เราจะมาทำอะไรกัน เพื่อเป้าหมายอะไรกัน จะได้ไปในทิศทางเดียวกัน

      SM บอก Rule การทำงานวันนี้ว่ามีอะไรบ้าง ซึ่งทุกคนต้องทำตาม เพื่อให้ได้เกิดประโยชน์สูงสุด แต่ Rule นี้ก็เป็นที่ยอมรับของทุกคนเหมือนกันครับ เช่น ห้ามใช้ notebook เพื่อให้ตั้งใจทำงานตรงนี้

      SM ถามถึง Business Requirement คืออะไรบ้าง และ Software Requirement คืออะไรบ้าง ให้ทุกคนช่วยเสนอออกมา ถ้าคนเยอะให้แบ่งเป็นกลุ่มๆ เพื่อลดการโต้เถียงที่ยาวนาน เมื่อทุกกลุ่มได้ออกมาแล้วก็พูดออกมาว่ามีอะไรบ้าง ถ้ากลุ่มไหนมีเหมือนกันก็เสริมกันได้เลย แต่ถ้าแตกต่างก็ discuss ได้แต่อย่านานเกินไป เนื่องจากพอได้ตรงนี้มาแล้ว เราจะหันมาถาม Development Team ว่า Business Requirement เพียงพอที่จะเอาไป develop ได้หรือไม่ เมื่อไม่พอต้องเพิ่มอะไรมาบ้างตรงนี้ละที่สำคัญเลย

      Business Requirement เช่น

• Flow Business
• Condition
• User
• User Interface
• Test Case + Data Test

      Software Requirement เช่น

• Performance
• Response Time
• Non-Functional

      SM เริ่มโดยการถามทุกคนว่า

• PROBLEM ปัญหาที่ทำให้เกิด Product นี้คืออะไร
• GOAL เป้าหมายเพื่อให้ Product นี้สำเร็จได้คืออะไร อันนี้ควรจะตอบโจทย์ปัญหาน่ะ และควรเป็น GOAL ที่ชัดเจน และเรียง PRIORITY ด้วย
• MAXIMIZE OUTCOME ผลที่อยากให้เกิดขึ้นเมื่อ PRODUCT นี้ได้เอาไปใช้แล้ว เช่นมีคนใช้งานมากขึ้นเรื่อย, ลดขั้นตอนการทำงานจาก PRODUCT เก่า เป็นต้น

      หลังจากได้ PROBLEM, GOAL, OUTCOME มาแล้ว เราก็เริ่มแก้ปัญหาทีละเรื่อง (Flow Business)

      โดยให้ช่วยกันเขียนว่าเรามี Flow Business อะไรบ้างออกมาให้หมด

• PO มาเรียง PRIORITY ว่าต้องการ flow ไหนก่อนหลัง
• ถ้า Fix Time ให้ PO บอกว่า Flow ต้องได้อย่างน้อยเท่าไร
• Dev Team บอก PO ว่าจะทำได้อย่างที่ PO ขอหรือไม่ ถ้าไม่ ได้แค่ไหน พร้อมเหตุผล

      ใส่ People และ Step workflow ที่เกี่ยวข้องกับ Flow Business นี้ลงไปแต่ละ Flow เลยว่า ใครทำอะไร มี step การทำงานอย่างไรลงไป ตรงนี้ถ้าเกิด flow ใหม่มาก็เพิ่มได้เลย (แต่จะเน้นให้ทำเฉพาะส่วนที่ Dev Team บอกว่าทำได้ก่อน)

• PO มาเรียง PRIORITY ว่าต้องการ flow ไหนก่อนหลัง
• ถ้า Fix Time ให้ PO บอกว่า Flow ต้องได้อย่างน้อยเท่าไร
• Dev Team บอก PO ว่าจะทำได้อย่างที่ PO ขอหรือไม่ ถ้าไม่ ได้แค่ไหน พร้อมเหตุผล

     เราจะเห็นว่ามีการปรับ PRIORITY ได้ตลอดเวลา และการ Estimate ว่าทำได้แค่ไหนนั้น คือการเดาล้วนๆเลยครับ แต่ถ้าเรา ลงรายละเอียดของแต่ละ Flow Business ได้มากแค่ไหนก็ยิ่งง่ายต่อการพัฒนา ครับ

     การทำกิจกรรมของวันแรกนี้คือ

• ทุกคนเห็นปัญหาเดียวกัน
• ทุกคนมีเป้าหมายเดียวกัน
• ตอบโจทย์ผู้ใช้งานและผู้ที่เกี่ยวข้องมากที่สุด
• พาทุกคนให้เสนอแนะ แสดงความคิดเห็น พูดออกมาให้มากที่สุด (การถาม ตั้งคำถาม พูดให้ฉุกคิด)
• ควบคุมให้ทุกคนอยู่ในเป้าหมายตลอดเวลา ไม่ให้ออกนอกเรื่อง (ถามถึงเรื่องที่เรากำลังทำ)
• วาง Agenda ของแต่ละช่วงเพื่อให้งานต่อเนื่องไปยังเป้าหมายได้อย่างถูกต้องมากที่สุด
• ควบคุม ป้องกันไม่ให้เกิดปัญหาระหว่างคน (การยับยั้งการพูดจาที่อาจจะสุ่มเสี่ยง)

     จบวันแรกละ เนื่องจากใช้เวลากับการลงรายละเอียดแต่ละ flow เยอะ และการอธิบายเนื้อของแต่ละ Flow พรุ่งนี้มาต่อน่ะครับ

Rally Day (21/10/2015)

สวัสดีครับ เนื่องจากมีโอกาสได้ไปร่วมกิจกรรมของงาน Rally Day (SAFe Big Room Planing) มาเมื่อวันที่ 21 ตุลาคม 2015 ที่ โรงแรมปทุมวันปริ้นเซส

หัวข้อที่จะมาทำกิจกรรมนั้นก็คือ Big Room Planning โดยเราจะใช้ Lego มาสร้างเมืองกัน

ก่อนอื่นเลยทาง Rally แนะนำให้เราฟังก่อนว่าเจ้า Big Room Planning นี้คืออะไรกัน

Big Room Planning คือการประชุมเพื่อเตรียมแผนการทำงานของผลิต Product ตัวนึง เป็นการวางแผนภาพใหญ่ ซึ่งเป็นการประชุมที่ทุกๆคนต้องเข้ามา คนที่เข้ามาก็มี
Executive เพื่อเข้ามาให้ Vision กับทุกคน ทุกคนจะได้เห็นภาพ เข้าใจเป้าหมายที่เหมือนกัน
Release Train Engineer (RTE) คนที่คอยดูภาพใหญ่ทั้งหมด เพื่อให้เป็นไปตามแผนงาน
UX/Architect คนที่ดูเรื่องการวางโครงสร้างของการทำงาน
Product Manager คนที่เป็นเจ้าของ Product และดูแล Product ภาพใหญ่(Roadmap)
Product Owners คนที่เป็นทีมเดียวกับ Product Manager เพื่อช่วยแบ่งงาน module ไปทำงาน
Scrum Masters คนที่ดูแลทีม
Develop Team ทีมงานพัฒนา

จบทฤษฎีก็มา workshop กันดีกว่า

มีการแบ่งทีม 5 ทีม
ทีม 1 - 4 เป็นทีมที่สร้าง บ้าน คอนโด โรงเรียน ลานกีฬา อื่นๆ
ทีม 5 สร้างผังเมือง ถนน (มีทีมนี้ตั้งแต่ภาพใหญ่มาจะทำให้เกิดคุณภาพถึง 25%)

Product Owner ของแต่ละทีมไปรับงานจาก Product Manager มาให้ โดยมี Scrum Master เป็นคนกำกับการทำงาน แล้วมาวางแผนของทีมกัน ซึ่งต้องมีเรื่อง Objective, Story, Risk จะเหมือนกันกับการที่เราทำ Sprint Part I ซึ่งตรงนี้เราจะได้บอร์ดภาพใหญ่ออกมา

ส่วนที่มีการ Dependency กัน
การวางแผนของทีม ก็จะมีส่วนที่ทีมต้องไปคุยกันกับทีม 5 ที่จะมีหน้าที่สร้างผังเมือง
เรื่องของขนาดโครงสร้างอาคารที่กำหนดไว้ว่าต้องใหญ่กว่าบ้าน 3 เท่า จึงทำให้ต้องมีการคุยกันกับ
ทีมที่รับผิดชอบในการสร้างบ้าน ซึ่งตรงนี้จะมีเส้นที่ลากผูกสัมพันธ์กันที่บอร์ดใหญ่

เมื่อทุกๆคนเริ่ม Clear ภาพของการทำงานทั้งของตัวเองและที่ Dependency กันแล้วก็ Commit งานกัน
แยกย้ายกันไปทำงาน ซึ่งทุกทีมจะมีบอร์ดการทำงานของตัวเอง และสัมพันธ์กับบอร์ดใหญ่ด้วย

รอบการทำงานของทุกๆทีมจะเหมือนกัน เมื่อถึงรอบการ Integrate กัน ก็จะมาวางพร้อมกัน
แต่เมื่อไรที่ติด และสัมพันธกันกับทีมอื่นก็จะต้องวางแผนเพื่อขยับไปด้วยกัน

ข้อดีจากการทำ BRP นี้ทำให้ทกุๆคนได้เห็นแผนที่ชัดเจน เห็นปัญหาได้ชัดเจนมากขึ้น

Rally มี Software ที่ทำให้เราเห็นภาพบอร์ด และอัพเดทได้ทันที ทำให้ทุกคนเห็นภาพใหญ่ได้ดีขึ้น
https://www.rallydev.com/blog/product/got-big-room-planning

ผู้จัดงาน
Rally https://www.rallydev.com/
CA http://www.ca.com/
V-Link http://www.vlink.co.th
Lean In Consulting http://lean-in.co/

ข้อมูลที่ต้องศึกษาเพิ่มเติม
http://scaledagileframework.com/

DevOps

DevOps

Development and Operations ที่จะทำให้กระบวนพัฒนา Software ทำงานได้รวดเร็ว คล่องตัวขึ้น

ทำไมถึงรวดเร็วได้ละ ทำไมถึงคล่องตัวละ แล้ว DevOps นี้คืออะไรกันหน่อ

DevOps คือการมีเครื่องมือต่างๆ ที่จะเข้ามาช่วยให้การทำงานที่ต้องทำซ้ำซ้อนลดลงไป เช่น

Case 1

การที่เราต้องการ server ตัวนึงเพื่อที่จะทดสอบ software ตัวนึงที่เรากำลังพัฒนามาได้นั้น

มีหลายขั้นตอนมากมาย เช่น ต้องทำเอกสารแจ้งไปยังทีม ITO เพื่อขอ server ตาม spec ที่เราบอก

เมื่อ ITO ได้ข้อมูล spec ไปก็ต้องตรวจสอบว่า มี resource พอหรือไม่ ถ้าพอก็ต้องไปขอ IP จากทีม

Network เมื่อได้ IP มาแล้วก็ deploy server มาให้เราได้

Case 2

การที่เราต้องการให้ config Middleware บน production ได้นั้นเราต้องทำเอกสารส่งไปให้ ITO ทำ

ITO ก็ต้องมานั่ง config ตามเอกสารอีกที มีโอกาส Human Error สูง

อย่างที่เราเห็นนี้ ขั้นตอนมากมาย ข้อมูลส่งต่อหลายต่อ ปัญหา Human Error นั้นก็มีโอกาส 

จะดีกว่าไหมที่เราสร้าง script ต่างๆเหล่านี้ให้อยู่บน tools ที่จะช่วยให้เราแค่กรอกข้อมูลไป

แล้ว ITO ก็ดู monitor ว่ามีพอหรือไม่พอ ถ้าพอก็กด approve ไป ทุกอย่างก็จะ auto install config ให้

เราอย่างที่เราต้องการได้เลย ถ้าผิดก็ผิดที่เรากรอกข้อมูลลงใน tools เองแล้วละ

เราจะพอได้เห็นว่า การจะได้ Server Middleware นั้นจะง่ายขึ้นละ

Software ที่เราพัฒนาละ ถ้าเราพัฒนา feature ออกมาได้บ่อยๆ ทุกๆสัปดาห์ ทุกๆเดือน

แล้วเราต้อง deploy ลง Develop Environment => QC Environment => UAT Environment => Production Environment ตามลำดับแบบนี้บ่อยๆ จะยุ่งยากขนาดได้ ต้องใช้คนเท่าไรกัน

คนทำงานที่ต้องมาทำอะไรที่ซ้ำๆ มันน่าเบื่อไหม จะได้ไปพัฒนาตนเองได้เรื่องอื่นๆไหม

แล้ว Test ที่ต้องมา Regression Test ละ เยอะขนาดไหนกันเชี่ยว

DevOps แก้เรื่องเหล่านี้ได้น่ะ แต่ๆๆๆ คนที่จะมาทำให้เกิดนั้น ต้องเข้าใจ flow การทำงานในแต่ละ
ขั้นตอนโดยละเอียด รู้ว่าจุดไหนของการทำงานต้องการให้นำมาช่วยได้บ้างนี้ก่อนน่ะ

แล้วถึงจะต้องมาทำ script หรือมี tools ที่จะช่วยให้เขียน script น้อยลง ซึ่ง script นี้ก็จะประกอบ

ไปด้วยเรื่องของการใช้ tools มาทำ unit test, automate test flow งานตาม business , deploy ลง

แต่ละ environment เมื่อผ่าน environment นึงละต้องการให้ไปต่อก็ทำให้เกิดแค่ปุ่มกด approve

เพื่อยืนยันว่า software ผ่าน environment นี้ละต้องไป step ต่อไปได้ละ รวดเร็วไหมละ แค่ปุ่มเดียว

DevOps ต้องใช้ทักษะหลายๆอย่าง เพื่อที่จะต้องเขียน script ให้ support ทุกกระบวนการทำงาน

ถึงแม้ว่า เราจะหา Tools DevOps มาก็ตามที ก็มักจะมีจุดที่เราต้องมาทำ script เองอยู่ดีครับ

Script นี้มีภาษา เช่น shell command สำหรับ OS, Middleware, Database เป็นต้น ขึ้นอยู่กับว่าเราจะ

ช่วยให้ขั้นตอนไหน auto ได้  หรือต้องมา manual ได้ง่ายที่สุด

Tools ขอไม่ระบุว่าเป็นอะไรบ้างในที่นี้ก่อนน่ะครับ เพราะมีหลายตัวให้เลือกใช้

สุดท้ายแล้ว script นี้ก็ทำแค่ครั้งแรกครั้งเดียว และก็เอาไปใช้ต่อได้ใน software ถัดๆไป 

เว้นแต่ว่ามีอะไรที่แตกต่างเพิ่มมา

Refactoring - Composing Methods

 จากหนังสือ Refactoring Improving Design Existing Code

บทที่ 6 Composing Methods

Extract Method

การแยก code ส่วนนึงออก โดยพิจารณาจาก

• มี code ส่วนนี้เป็นเนื้อหาย่อยของชื่อ method หรือไม่
• มี comment ที่บอกว่า code ส่วนนี้เป็นอีกเรื่องนึงที่ทำงาน

เราก็ลอง extract method ออกไป แต่ให่เราคำนึงถึงชื่อที่ตั้งให้ method ด้วยน่ะว่า

• ชื่อต้องสื่อถึงการทำงานของ code ที่ extract ออกไป

Example

Example: No Local Variables

Example: Using Local Variables

Example: Reassigning a Local Variable

แล้ว rename outstanding => result เพื่อให้เข้าใจง่ายของการทำงานใน method นี้

Next Example

Inline Method

การยุบ Method ที่ไม่จำเป็นต้องมี อาจจะพิจารณาได้จาก

• เรียกจากที่เดียว
• method ทำงานแค่ 1 บรรทัด

Example

Inline Temp

การยุบ Object Temp ที่เรียกใช้งานเพียงครั้งเดียว

Example

Replace Temp with Query

การยุบ Object ที่เป็นการคิด หรือทำอะไรเพียงเล็กน้อย แล้ว Extract Method ออกไป

Example

Example

ใส่ final ไว้เพื่อให้มั่นใจว่าจะได้รับการ assign value เพียงครั้งเดียว

Introduce Explaining Variable

ค่าที่มีที่มาเพียงอย่างเดียวหรือเงื่อนไขชัดเจนสามารถแยกออกไปได้

Example

Example

Example with Extract Method

Split Temporary Variable

ค่าของ temp เป็นคนละเรื่องกัน ก็ควรแยกชื่อกัน เพื่อความเข้าใจที่ง่ายกว่า

Example

การใช้ object มาเป็น temp กับ loop ก็อาจจะมีปัญหาได้

Example

Remove Assignments to Parameters

ไม่ใช้ Object ที่ส่งมาโดยตรง

Example

Replace Method with Method Object

Example

 

Substitute Algorithm

Example