Visit: https://codingugly.com/?p=157

ในช่วงที่ผ่านมา มีคนพูดถึงประเด็น เวลามีมูลค่าบ่อยมาก อาจเป็นเพราะ เร็วๆนี้ผู้ว่าชัชชาติได้พูดถึงกรณีมูลค่าของเวลาในการสร้างรถไฟความเร็วสูง ซึ่งก็ตรงกับการพัฒนาซอฟต์แวร์เช่นกัน

Sponsored by: https://codingugly.com, Tech Leadership Anti-Patterns

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

จากบทความเรื่อง “Software Development Waste” ที่ตีพิมพ์ในวารสารวิชาการ International Conference on Software Engineering (ICSE) , 2017 ที่ได้เฝ้าดูการพัฒนาซอฟต์แวร์ 8 โปรเจ็คในระยะเวลา 2 ปีครึ่ง แล้วแยกแยะ waste ต่างๆ ในกระบวนการทำซอฟต์แวร์ ออกเป็นกรณีๆ ผมจึงคิดว่า มันน่าจะมีประโยชน์ในแง่ของ Checklist หากทีมใดจะนำไปใช้ เพื่อลด waste และเพิ่มประสิทธิภาพในการทำงาน ผมขอเริ่มกันเลยครับ

Waste#1 Product ที่ไม่มีใครต้องการ

เป็น waste ที่เสียไปในการสร้างสิ่งที่ไม่ถูกต้อง ใช้งานไม่ได้ ไม่ตอบโจทย์ กล่าวคือ… อ่านต่อ...

Visit: https://codingugly.com/?p=147

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

ธรรมชาติของการพัฒนาซอฟต์แวร์ มักจะมี deadline ในการส่งมอบ working software ให้กับลูกค้า หรือ users เป็นรอบๆ และบางครั้งก็เร่งรีบจากสาเหตุหลายประการ ทำให้ทีมพยายาม focus ไปที่ features ที่จะส่งมอบ และเทส feature นั้นๆ รวมถึงสิ่งที่พอจะทำได้เช่น performance ในขณะที่มักจะลืมสิ่งที่ถูกมองข้ามได้ง่ายอย่างเช่น maintainability และ reusability

ถ้าโปรเจคส่งมอบได้ จะเข้าสู่โหมด maintenance ในช่วงนี้จะมีการแก้โค้ดและ enhancement ในลักษณะเพิ่มโค้ดเข้าไปเรื่อยๆ ตาม feedback ที่ได้มา หากยิ่งไม่มีการ refactor หรือ improve code quality แล้วนั้น มันก็จะค่อยๆกัดกร่อน quality กล่าวคือ ถ้าในโค้ดมี “code smells”… อ่านต่อ...

Visit: https://codingugly.com/?p=105

ทีมพัฒนาซอฟท์แวร์บ่อยครั้งมักจะมีการเปรียบเทียบกับทีมในการแข่งขันกีฬาที่ต้องใช้ทีมเวิร์คสูง หนึ่งในนั้นคือกีฬาเรือใบ

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

ยิ่งถ้าได้ดูการแข่งขันกีฬาอย่าง SailGP ใน Youtube แล้ว ยิ่งทำให้เห็นภาพมากขึ้น ว่าในการแข่งเรือใบ กรังปรี สมัยใหม่นี้จะต้องอาศัยเทคโนโลยีและเครื่องมือที่ทันสมัยมากๆ ผู้เข้าแข่งขันต้องร่วมกันทำงานเป็นทีมเวิร์คอย่างสูง และ Goal ในแต่ละ race ก็ชัดเจนคือต้องเข้าเส้นชัยเป็นที่หนึ่ง เปรียบได้กับทีมซอฟต์แวร์ที่แต่ละ sprint จะมี sprint goals เป็นจุดหมาย
SailGP จะมีผู้เล่นในทีมบนเรือ 5 คน ประกอบด้วย helm หรือคนคุมหางเสือ 1 คน wing trimmer 1 คน คอยปรับ aerodynamics ของเรือ และทำงานกับ flight controller 1 คน ที่คุมการควบคุมต่างที่เป็นเทคโนโลยีของเรือ และ grinder… อ่านต่อ...

Visit: https://codingugly.com/?p=71

เคยบ้างไม๊ที่รู้สึกว่าโปรเจคที่เราดูแลอยู่มันไปไม่ถึงไหน เคยไม๊ที่โทษตัวเองว่าถึงแม้เราจะพยายามมากแค่ไหน ก็ไม่มี progress อะไรเกิดขึ้นเลย หรือว่าที่ตรงนี้ไม่ใช่ที่ของเรา และเรามาถึงจุดนี้ได้อย่างไร หรือเราเป็น imposter ในทีม ต้องยอมรับว่าความรู้สึกแบบนี้ เกิดขึ้นกับ developers, team leads หรือแม้กระทั่ง leaders ในทุกๆระดับ ที่ส่วนใหญ่จะต้องผ่านจุดนี้ จุดที่เรียกว่า Imposter Syndrome

ทำไมเราต้องตั้งคำถามกับความสามารถของเรา ต้องยอมรับก่อนว่า งานในสายพัฒนาซอฟต์แวร์ มักจะมีความซับซ้อนและไม่ตรงไปตรงมาเข้ามาเกี่ยวข้องเสมอ ทำให้บ่อยครั้งโปรเจคไม่ดำเนินไปข้างหน้าอย่างที่ควร feature ใหม่ๆ ไม่ผ่าน QA หรือแม้กระทั้งเรื่องเล็กๆอย่าง cycle time ของ pull request นานเกินไปกว่าจะได้ merge เข้า develop branch จนพาลทำให้เกิดคำถามในใจว่าเราไม่มีความสามารถหรือเปล่า หรือว่าเราเป็นของปลอม (imposter)

จริงๆแล้วเราต้องยอมรับก่อนว่า ความรู้สึกแบบนี้เป็นเรื่องปกติ ไม่ว่าจะอาชีพไหน ขอยกตัวอย่าง หากคุณเป็น engineering manager ที่เพิ่งถูก assign มาให้แก้ปัญหาโปรเจคที่ go live ไปแล้ว หากคุณเริ่มรู้สึกถึง imposter syndrome เมื่อไหร่… อ่านต่อ...

Visit: https://codingugly.com/?p=51

เมื่อเร็วๆนี้ ผมถูกถามว่าเราจะทำ product อะไรขายลูกค้าดี ที่จะแก้ปัญหา xyz ให้เค้า ตั้งแต่ทำงานสาย engineering มา ผมมักจะเจอคำถามทำนองนี้บ่อยๆ ที่แยก problem และ solution ออกจากกันกล่าวคือเป็นการแยกกันของ problem ที่ลูกค้ามี และ solutions ที่จะตอบโจทย์ลูกค้า

จริงๆ approach นี้ก็ค่อนข้างมีเหตุผล แต่บางครั้งก็ไม่สามารถใช้แก้ปัญหาที่ซับซ้อนได้ โดยเฉพาะในกรณีที่ต้องการ innovation ด้วย เพราะฝ่าย problem ก็จะพยายามทำความเข้าใจปัญหาให้ได้มากที่สุดเพื่อให้ฝ่าย solution ไปหาทางออกให้ จึงจำเป็นต้องทำลายกำแพง problem และ solution นี้ทิ้งซะก่อน

เฮนรี่ ฟอร์ด ผู้ก่อตั้งรถยนต์ยี่ห้อฟอร์ด เคยกล่าวไว้เมื่อ 100 กว่าปีที่แล้ว หากไปถามลูกค้าว่าอยากได้อะไร พวกเขาจะตอบว่า “faster horses” แต่ฟอร์ดก็เลือกที่จะสร้างรถยนต์ ในสายซอฟแวร์ในปัจจุบัน ยิ่งชัดว่าบ่อยครั้งที่ลูกค้าไม่ทราบว่าเขาอยากได้ solution อะไรมาแก้ปัญหาของเขา หลายโปรเจคทำมาเพื่อแก้ปัญหา แต่ก็ไม่ได้แก้ปัญหาที่แท้จริงเลย นั่นก็เพราะว่า product team ใช้เวลาส่วนใหญ่ในการค้นหาว่าปัญหาของลูกค้าคืออะไร และผลักงานที่เหลือมาให้ engineering team สร้าง… อ่านต่อ...

Visit: https://codingugly.com/?p=46

ถึงแม้เราจะมองการทำซอฟต์แวร์เป็นงานที่ไม่เหมือนไลน์การผลิตในโรงงาน เพราะเป็นงานที่ต้องใช้ทักษะ ความคล่องตัว และความคิดสร้างสรรค์อย่างมาก แต่ในทางกลับกันเครื่องมือและกระบวนการกลับสวนทางอย่างชัดเจน

Tool ที่ป็อปปูล่ามากๆในสายนี้คือ JIRA ซึ่งเป็นบอร์ดที่ทีมงานต้องดูทุกวัน กล่าวคือทีมจะพยายามทำงาน และ move งานไปทางด้านขวาไปหา “done” ให้ได้มากที่สุด แต่ปัญหาคืองานบนบอร์ดไม่สามารถแสดงถึงความสัมพันธ์ของแต่ละงานได้อย่างถูกต้องนัก งานบางอย่างมีความต่อเนื่องกับงานก่อนหน้าและงานถัดๆไปในลักษณะ feedback loop ก่อนที่แต่ละงานจะย้ายเข้าไปอยู่ในช่อง “done“ ได้อย่างแท้จริง

ถึงแม้มันจะช่วยเรา visualize งานที่กำลังทำอยู่ว่าเสร็จไปถึงไหนแล้ว หรือแม้กระทั่งดูว่างานตอนนี้เยอะไปหรือเปล่าก็ตาม แต่ก็ไม่สามารถจะ visualize ความสัมพันธ์ที่ว่าได้ ยกตัวอย่างเช่นงานที่ต้องทำการทดลอง เช่นทดลอง feature ใหม่ๆที่จะเป็นอนาคต ของบริษัท เหมือนอย่างที่ startup ทั่วไปทำ MVP (minimum viable product) คือมันยากมากที่จะเอางานมาวางเรียงกันบน JIRA board แล้วลงมือทำ และสิ่งที่อยู่ในบอร์ดก็ช่วยเราได้แค่แสดงว่างานเสร็จไปถึงไหนแล้วแค่นั้น หากเกิดกรณีนี้ สิ่งที่ต้องทำควบคู่กันไปคือการเน้นการใช้ story หรือใบงาน (ticket) บน JIRA ให้เป็นเหมือนการเล่าเรื่อง (narrative) และสร้างความสัมพันธ์ของแต่ละงานด้วยการ linked แต่ละ tickets เข้าหากัน ดังนั้นสิ่งที่ต้องทำ คือการส่งเสริมให้ทีมงานมีการพูดคุยแบบ… อ่านต่อ...

Visit: https://codingugly.com/?p=40

Product manager จำนวนมากมองทีม development เหมือนกับบล็อก Tretis โดยไม่รู้ตัว เป็นอย่างไร มาลองดูกันครับ

การพัฒนา product อย่างที่ทราบกันดี คือต้องเป็นไปอย่างต่อเนื่องเป็น iterations ทำให้การบริหาร resource ต้องต่อเนื่องด้วยเช่นกัน การใส่ product backlogs เข้าไป ทำให้การันตีว่ามีงานเข้ามาอย่างต่อเนื่อง และ เมื่อจัดเป็น sprint backlog แล้วยิ่งต้อง flow อย่างต่อเนืองยิ่งกว่า

คำถามประมาณว่า “ตอนนี้ทำไรอยู่?” “ให้คนนั้นมาช่วยทำดีไม๊?” “ถ้า dev คนนั้นทำ ticket นี้เสร็จ ผมจะให้เค้ามาทำอีก ticket นะ” หรือ “quarter นี้ถ้าพอมีเวลาเรา deliver feature xxx เข้าไปด้วยใน sprint นี้เลยจะทันไม๊ บางทีเราอาจต่อรองเอา epic นี้ออกไปก่อน”

จริงๆ product manager ก็ไม่ได้ทำอะไรผิด เพราะมันเป็นหน้าที่ของเขาที่ต้อง ทำให้ได้ output ให้ได้มากที่สุด ไม่เฉพาะ… อ่านต่อ...

Visit: https://codingugly.com/?p=35

ใครๆก็อยากใช้ซอฟต์แวร์ที่ใช้งานง่ายทั้งนั้น แต่ทำไมเราจึงเห็นซอฟต์แวร์ที่ใช้งานยากและซับซ้อนอยู่ทั่วไป ในยุค digital disruption เราจะพยายามหลีกเลี่ยง UI ที่ใช้งานยาก แต่สุดท้ายความซับซ้อน ก็เกิดขึ้นมาตามธรรมชาติโดยไม่ได้ตั้งใจ ดังนั้น software developers ต้องทำความเข้าใจถึงสาเหตุว่าทำไมความซับซ้อนของซอฟต์แวร์จึงบังเกิด

ทุกอย่างเกิดขึ้นจากความต้องการของ user เมื่อมี feature request เข้ามา การใส่ feature เข้าไปแบบง่ายที่สุด และเป็นธรรมชาติที่สุดคือการเพิ่มเข้าไปแบบดื้อๆ โดยไม่ไปแตะส่วนอื่นๆเลย แล้ว insert component ใหม่นี้เข้าไป ไม่ว่าจะเป็นการเพิ่มปุ่มใหม่ หรือ parameter ที่เพิ่มเข้ามาใน function เมื่อเกิดบ่อยๆซ้ำๆ ความเรียบง่ายของระบบจะหายไป และจะถูกแทนที่ด้วยความซับซ้อน pattern แบบนี้จะพบเห็นได้ทั่วไปใน enterprise software ที่บางครั้ง feature ใหม่ถูกเขียนขึ้นเพื่อ support user กลุ่มหนึ่งโดยเฉพาะ แต่อาจไปเพิ่มภาระให้กับ user อีกกลุ่มที่เหลือ

ทุก feature request จะมี user ที่สนับสนุนอยู่แล้ว user อยากได้และอยากให้มันเกิด แต่ถ้ามองในทางกลับกันความเรียบง่ายของระบบ เหมือนจะไม่มีผู้สนับสนุนเลย เป็น non functional… อ่านต่อ...

Visit: https://codingugly.com/?p=30

สมมติว่าบางอย่างเกิดขึ้นแล้วกันครับ ทำให้ feature นึงไม่พร้อมใช้งาน แต่มันได้เข้าไปอยู่ใน develop branch เรียบร้อยแล้ว (สมมติว่าใช้ git flow) คุณในฐานะที่เป็นเป็นผู้รับผิดชอบ product การเอา feature เข้าออกอาจเป็นเรื่องปกติ แต่มาเจอแบบ last minute แบบนี้ ก็สามารถทำให้ปวดหัวได้เช่นกัน เหตุการณ์แบบนี้เกิดขึ้นได้ ไม่เป็นไรครับ ลองมาดูว่าจะแก้ปัญหานี้ได้อย่างไร โดยขอใช้เป็น git command line ในการอธิบายสิ่งที่เกิดขึ้น ทำให้เห็นภาพง่ายกว่า GUI tool

กรณี #1
แบบไม่ค่อยเต็มใจจะเอา feature ออกเท่าไหร่ แก้บางไฟล์ใน last commit ก็พอ เราใช้ git checkout เพื่อ เอาไฟล์ออกมา เพราะการ checkout คือการเอาไฟล์จาก index หรือ statging area มาไว้ที่ working tree (directory) ซึ่งจริงๆแล้วการ checkout สามารถดึงไฟล์จาก commit ไหนก็ได้ ไม่ใช่เฉพาะจาก commit… อ่านต่อ...

Visit: https://codingugly.com/?p=24

วันนี้มาคุยกันเรื่อง Mindsets ของ Product vs Project ว่ามันแตกต่างกันอย่างไร และทำให้เราส่งมอบ product ที่ใช่ ถูกใจตลาดได้อย่างไรกันครับ ขอเริ่มจาก project mindset ก่อน

สมัยก่อนคำว่า project ไม่ได้เป็นคำที่ใช้กันมากนัก แต่ในยุคไม่กี่ทศวรรตหลังนี่เอง ความก้าวหน้าของเทคโนโลยี กระบวนการและเครื่องมือใหม่ๆ ทำให้ Project กลายเป็นเรื่องปกติธรรมดา เมื่อสิบกว่าปีก่อน ผมได้มีโอกาสไปทำงานในประเทศสหรัฐอเมริกา ได้ไปเห็นการทำงานแบบ result oriented และมีส่วนร่วมในการทำ software แบบ large scale ที่บริษัท Cisco Systems, Inc ทำให้เห็นภาพ project ใหญ่ๆเค้าทำกันยังไง project ส่วนใหญ่จะมีส่วนของ planning และส่วนของ executing และบทบาทของ Project Manager มีส่วนสำคัญมาก Project Manager มีหน้าที่รับผิดชอบในการวางแผน ค้นหาว่าจะทำอย่างไร ต้องทำอะไร ทำนานแค่ไหน และจะต้องใช้ budget เท่าใด และนี่คือสามเหลี่ยม Project Management นั่นคือ Scope, Time… อ่านต่อ...

Visit: https://codingugly.com/?p=16

เกริ่นนำ

ในการพัฒนาซอฟท์แวร์ด้วย Agile Development เรามักจะได้ยินบ่อยๆว่า deliver the right app, on time และ on budget แต่มีคำอยู่คำหนึ่งที่ dev ทุกคนเคยผ่านตามาบ้างคือ technical debt (อ่านว่า เด็ท ตัวบีไม่ออกเสียงนะครับ) และมันอาจเป็นสาเหตุที่ทำให้ product deliverables เกิดอาการเป๋ไปได้ หากไม่ได้ถูกจัดการอย่างเป็นระบบและสม่ำเสมอ

เช่นเมื่อกลางปีที่แล้ว ผมมีโปรเจคนึงไม่สามารถ upgrade ไป version ใหม่ได้ เพราะไม่ได้ upgrade software stacks ตามระยะ สุดท้ายต้องรื้อโค้ด ปัญหานี้เกิดบ่อยกับ startup ที่ต้องปล่อย app สู่ตลาดอย่างรวดเร็ว ออก features ใหม่ๆตามรอบ iterations อยู่ตลอดเวลา การหาเวลา upgrade จึงทำได้ยาก

ดังนั้นมาดูกันว่า technical debt มันทำงาน และจะจัดการกับมันอย่างไร

Technical debt ในสายตาของ product… อ่านต่อ...

Visit: https://codingugly.com/?p=8

Software หรือ app delivery เป็น event ที่สำคัญของทีมพัฒนา software และเป็นความรับผิดชอบโดยตรงของ product manager งานที่เขาต้องทำมีอยู่ 3 อย่างคือ discovering, planning และ executing เพื่อทำให้ส่งมอบ product ที่ใช่ ตรงเวลา และอยู่ใน budget หากมองถึงความซับซ้อนของงานที่ต้องทำ จะขึ้นกับขนาดของทีม, ขึ้นกับ stage ของ product ว่าอยู่ในช่วงไหน เป็นช่วง beta test หรือ go-live แล้ว, ประเภทของ product เป็นแบบไหน เป็น e-commerge, B2B, B2C, vendor หรือ in-house product และที่สำคัญคือ culture ของบริษัทเป็นแบบไหน ถ้าทีมเล็กๆ บางที product manager สามารถ handle คนเดียวได้สบาย ถ้าซับซ้อนและมีหลาย development ทีม อาจต้องมีทีมงานช่วยอีกแรง

ค้น
ใน… อ่านต่อ...