關於 tdd scrum ，我們在網路上蒐集到這些相關的討論、資訊與評價

ถ้าพูดถึงการพัฒนาซอฟต์แวร์ จะว่าไปแล้วมันก็ดูเป็นสิ่งนึงที่ติดลูป วนไปวนมาในชีวิตชาวเดฟเหมือนกันนะ โดยเฉพาะอย่างยิ่งกับองค์กรที่ใช้ Agile และ Scrum ในการทำงาน ที่มีการแบ่งการทำงานเป็นรอบ ๆ (Sprints)
.
เพราะคุณจะต้องเก็บ Requirements ของลูกค้าหรือผู้ใช้งาน แล้วก็นำไป Design และ Process เป็นซอฟต์แวร์ขึ้นมา จากนั้นก็ไปเก็บ Feedback จากลูกค้าหรือผู้ใช้งาน เพื่อนำ Feedback ไปปรับปรุงและพัฒนาซอฟต์แวร์ต่อในรอบถัดไป 🤔
.
👉 ซึ่งในการพัฒนาซอฟต์แวร์จะมีคำอยู่คำนึงที่มักพูดถึงกันบ่อย ๆ นั่นก็คือคำว่า “Technical Debt” หรือแปลเป็นไทยตรง ๆ ว่า “หนี้ทางเทคนิค” นั่นเอง
.
.
🔥 Technical Debt คืออะไร?
.
คำว่า Technical Debt เกิดขึ้นครั้งแรกโดย Ward Cunningham ตอนกำลังทำ Software ด้านการเงินอยู่ (เขาคือ 1 ใน 17 คนที่ได้คิดคำว่า Agile ขึ้นมา) ซึ่งเขาอยากอธิบายปัญหาที่เจออยู่ให้นายจ้างที่ไม่รู้เรื่อง Technical จึงเลือกเปรียบเทียบปัญหาทางเทคนิคกับหนี้ทางการเงิน (Monetary Debt) 💸
.
👉 คำว่า Technical Debt จึงพูดถึงปัญหาต่าง ๆ ด้านเทคนิค 💻 ไม่ว่าจะมาจากการเขียนโค้ดที่ไม่ดี Design ที่ไม่มีคุณภาพหรือไม่ยืดหยุ่น การละเลยปัญหาบางอย่างระหว่างพัฒนา หรือสาเหตุใด ๆ ก็ตามที่สุดท้ายก็ต้องมาตามแก้ทีหลังอยู่ดี
.
.
🔥 Technical Debt เกิดจากอะไรได้บ้าง?
.
เป็นคำถามที่มีคำตอบได้ล้านแปดอย่าง เพราะการพัฒนาซอฟต์แวร์คงหลีกเลี่ยงปัญหาไม่ได้อยู่แล้ว ยิ่งเป็นซอฟต์แวร์ขนาดใหญ่แล้ว ยิ่งใช้เวลามากเท่าไหร่ หรือมีคนร่วมพัฒนาเยอะแค่ไหน ก็อาจทำให้มีปัญหาอีกมากมายที่รอให้เราไปตามแก้อยู่ 🤕
.
👉 และที่สำคัญ Technical Debt ไม่ได้มีแค่ “โค้ด” เท่านั้น ไม่ว่าจะปัญหาจากการออกแบบ การเทสต์ การทำเอกสาร เครื่องมือที่เลือกใช้ในการพัฒนา หรือผู้ร่วมพัฒนาเองก็เป็น Technical Debt ได้เหมือนกัน
.
.
🔥 ตัวอย่าง Technical Debt ที่คุณอาจจะได้เจอ
.
🔹 ใช้ Architecture หรือ Tools ต่าง ๆ ไม่เหมาะกับสิ่งที่พัฒนาอยู่
🔹 รู้ว่าซอฟต์แวร์มีปัญหาตรงไหน แต่ไว้ก่อนจนสุดท้ายไม่ได้แก้
🔹 เวลาที่ให้ไม่สอดคล้องกับจำนวนงานที่ต้องทำ
🔹 ไม่เข้าใจซอฟต์แวร์ที่กำลังทำอยู่
🔹 ลืมทำ Documents หรือทำแบบขอไปที ไม่มีคุณภาพ
🔹 เขียนโค้ดซับซ้อน อ่านทำความเข้าใจและ Maintain ได้ยาก
🔹 คนในทีมมีภาระหนักเกินไป เช่น ทำงานมากกว่า 1 งาน ในเวลาพร้อม ๆ กัน
.
.
🔥 ทำยังไงดี ถ้าไม่อยากมี Technical Debt
.
เอาเข้าจริง ๆ แล้วการพัฒนาซอฟต์แวร์ คงจะหลีกเลี่ยง Technical Debt ได้ยาก แถมพอมีแล้วก็ต้องตามแก้กันอีก ราวกับส่งดอกให้เจ้าหนี้ 😔 แต่ถึงจะเลี่ยงได้ยาก ก็ไม่ได้แปลว่าจะเลี่ยงไม่ได้เลย เรามาดูวิธีลด Technical Debt กันดีกว่า
.
👉 แน่นอนว่า สิ่งที่ช่วยลด Technical Debt ได้ดีที่สุด ก็คือการไม่สร้างมันขึ้นตั้งแต่แรกด้วยวิธีต่าง ๆ เช่น เขียนโค้ดให้ Clean, ใช้ Test-Driven Development (TDD) ในการพัฒนา, ทำ Unit Testing รวมถึงวางแผนการพัฒนาซอฟต์แวร์ให้ดีและเลือกใช้เทคโนโลยีที่เหมาะกับสิ่งที่ทำ
.
🤔 แต่ถ้ามันเกิดขึ้นมาแล้ว จะทำยังไงล่ะ? ข้อแรกเลยคือต้องรู้ก่อนว่า อะไรเป็น Technical Debt ของซอฟต์แวร์ แล้วจึงหาวิธีแก้ไขปรับปรุง โดยจัดลำดับความสำคัญของปัญหาที่เจอ แล้วแก้ไปเรื่อย ๆ เพื่อให้ Technical Debt ลดลง อย่าแค่รู้ว่ามีปัญหาอะไร แล้วก็ไว้ก่อน จนสุดท้ายก็ไม่ได้แก้
.
.
📌 สรุปแล้ว Technical Debt ก็ไม่ได้ต่างจากหนี้ทางการเงินเท่าไหร่ เพราะมีหนี้ก็ต้องมีจ่าย และไม่ได้จ่ายแค่เงินต้น เราต้องเสียดอกเบี้ย และจะเสียมากขึ้นไปอีก ถ้าปล่อยให้หนี้ก้อนนี้อยู่ไปนาน ๆ เหมือนกับ Dev ที่ต้องมาตามแก้ปัญหาต่าง ๆ แถมถ้าทิ้งไว้นานแล้ว หรือเป็นหนี้ก้อนใหญ่ ก็ต้องใช้ทั้งแรง ทั้งเวลา และทั้งเงินในการขจัดปัญหานั้นมากกว่าเดิม
.
เพราะฉะนั้น ถึงเวลาแล้วล่ะ 🙌 ที่จะบอกลา (หรือลด) คำพูดก่อหนี้อย่าง “เดี๋ยวค่อยทำ” หรือ “ทำ ๆ ให้เสร็จไปก่อน” หรือ “ไม่ต้องมี Test หรอก” เพื่อให้เกิดหนี้ทางเทคนิคอย่าง Technical Debt น้อยที่สุดนั่นเอง~
.
.
🔖 ขอบคุณข้อมูลจาก
https://siamchamnankit.co.th/ว่าด้วยเรื่อง-หนี้ทางเทคนิค-technical-debt-ทำไมต้องใส่ใจ-b7a0c296b590
.
borntoDev - 🦖 สร้างการเรียนรู้ที่ดีสำหรับสายไอทีในทุกวัน
#TechnicalDebt #BorntoDevวันละคำ #BorntoDev

Ron Jeffries 的提醒，大家在以 scrum 進行軟體產品開發時，要避免本末倒置、倒行逆施。

“When a team does not have the necessary and less than obvious technical skills to produce a shippable Scrum Increment week in and week out, the Scrum process almost inevitably goes dark.”

如果你是工程人員，更建議你先從 極限編程(extreme programming) 著手。

事實上我們看過這麼多的客戶，極少看到 agile/scrum 落實內化很好，但極限編程跟人員的工程技能低落的。

大部分順利的路，是從極限編程做得不錯，再引入 scrum 的。可以參考我自己的 scrum 序章：https://tdd.best/blog/my-beginning-of-scrum/

也有一種很特別的例子，是 agile/scrum + XP 併行推進的，這個比較考驗大家對目標的認同，對相同方向上的施力，而且一開始就認知自己組織內可能各方面能力都需要提升，才能在這持續改善的路上持續學習，知道這條路本來就充滿荊棘挫折，但只要我們能越來越好，就總比之前好上不少。

Ron Jeffries 是誰：https://en.wikipedia.org/wiki/Ron_Jeffries

極限編程 三大頭之一，敏捷宣言 17個簽署人之一，同時也是 Scrum Alliance 的 CST 培訓師。

在我們多天的 scrum 相關培訓中，通常就會有一半以上是實際的開發協作過程。

--
最近一年也讓我試著換另外一個角度來看，

「改善比較容易，還是加班比較容易？」
「學 scrum 比較容易，還是學單元測試、重構、TDD 比較容易？」

最直接的方式，做個調查，多少公司以 scrum 方式進行開發，而多少公司內有落實 unit test 與持續重構。這個比例拉出來，就不意外為什麼大部分看到的都是 Dark Scrum 了。

開發人員總是訕笑著 PM 永遠都給著不合理的時程，然而他們也總是以「沒有時間」當藉口來掩飾自己技能上的不足。

如果你是在開發軟體產品，那整體就是 領域(產品) x 協作(溝通) x 開發 (交付) ，而且真正做東西出來的核心，還是開發交付的部份。

這一塊夠扎實，即使是瀑布，也可以有一定的成績。

新加坡商鈦坦科技 高雄辦公室正式落腳高雄三民區囉，一些北漂到台北奮鬥的鈦坦PD們，現在要回鄉打拼，而且正在招兵買馬中。

如照片中所說，他們第一波回去高雄的先鋒部隊，都是參加過我所有公開課，而且在 coaching 時一直被我「盯」到大的一群支柱。

看到第一波回去高雄辦公室的名單，我整個就不擔心他們新的 team 會有什麼問題了，都是一時之選，非常適合團隊作戰，技術、產品、協作能力都很好的一群人。

這樣說好了，他們團隊基本款就是會寫單元測試、會重構，真的會在產品開發過程中 TDD 完成功能的。

會有 code review, pair programming 甚至 mob-programming 整組人一起開發一個 feature 的。

版控用 git，分支策略正往 trunk-based 走，且團隊有能力在設計上搭配 feature toggle/flags 來做到持續部署，當然就更別說 CI 做持續整合了。

架構能力基本的 DI/AOP, decorator, Adapter, proxy 的使用都是基本規範。

這些對很多 modern development 公司的基本功，這群人都有能力也都能這麼做。

順便講一下，他們先鋒 team 也是全員用極速開發的方式在使用 IDE+vim 做開發、測試跟重構的，新人進去多 pair 幾次，就會對這種正規作戰、扎實基本功的戰技趨之若鶩。

沒見過時，你都覺得是烏托邦、天方夜譚，真的在產品開發時，團隊成員每個都這樣搞，而且覺得這不是很自然、很正常的事嗎？

嗯，這群人都是從高雄帶到台北再一路帶大，現在再把這整套開發方式帶回高雄的先驅部隊。

如果你有興趣，不要錯過這機會啦，高雄能有這種扎實開發方式的公司，能把敏捷搞進骨子裡的公司，能真的全員背靠背互相支援的團隊，寥寥可數。

#該煩惱的應該是台北辦公室怎麼補回這些柱的戰力

所以尤其是上過我的課，而且無法在現在工作上發揮技能、一展身手，且你又覺得到/回高雄工作很不錯的，不要錯過一開始招兵買馬的機會啦，機會是不等人滴！

—
From @李境展 Tomas:

Scrum 是個照妖鏡，「沒有人能閃躲，問題全跑出來。」
　
「敏捷思維 (Agile Mindset)，必須建立在學習型組織 (Learning Organization)、持續進步 (Never stop improving)、不貼標籤減少預設立場 (No labelling)。敏捷在鈦坦的環境裡，並非只是一味求取快速，而是如同呼吸般的存在，既自然又無所不在。能夠做到此地步，究竟鈦坦做了什麼改變呢？」謝謝 ＃MOPCON 和 KM 曹凱閔的邀請採訪，讓更多朋友們認識敏捷管理與實踐。
　
同時也在這裡大聲分享「#鈦坦科技正式擴點高雄」（灑花）

🎉🎉🎉🎉🎉🎉🎉🎉🎉
在過去幾個月的準備，和許多 MOPCON 好友們的協助下，鈦坦科技高雄辦公室正式落腳在高雄三民區。接下來可以和高雄社群朋友有更多的交流和學習，先感謝一波。
　
更重要的是，現在開始，正式廣邀南臺灣的人才，也歡迎各界好友們推薦人才加入，共創鈦坦科技高雄辦公室！
🌳🌳🌳🌳🌳🌳🌳🌳🌳
🧲 Software Engineer／Programmer ＃軟體工程師(高雄)
🧲 Product Owner ＃產品負責人(高雄)
🧲 User Experience Researcher #使用者體驗研究員 (高雄)
🧲 UI Designer / ＃網頁設計師 (高雄)
🧲 HR&Admin Specialist ＃人資行政管理師 (高雄)
https://www.titansoft.com/tw/career/current-openings?country=taiwan

https://medium.com/mopcon-%E5%B7%A5%E4%BA%BA%E6%99%BA%E6%85%A7%E8%A8%98%E4%BA%8B%E6%9C%AC/2020mopcon-titansoft-bc49620248d5