Members Left Because of Technical Debt

Tình hình:
Thành viên dự án xin nghỉ và lý do là "em thấy mã nguồn bẩn quá" và "làm mãi ở dự án, gần một năm mà không học được gì"

Phân tích lý do:
Khi nhận được thông tin member xin nghỉ, quản lý/SM giả định nhiều lý do: Lương, thưởng thấp, mâu thuẫn với đồng nghiệp, lý do cá nhân, bạn bè lôi kéo.
Member xin nghỉ vì họ có lý do nào đó, mỗi tình huống xin nghỉ đều có lý do khác nhau, và trong trường hợp này "mã bẩn", "không học được gì" là hai lý do chính

Mã nguồn bẩn:
Đây là một dạng technical debt. Dự án đã phát triển trong trạng thái không kiểm soát về mã nguồn, kiến trúc. Một số biểu hiển về sự bẩn của mã nguồn:

  • Nghiệp vụ lung tung
  • Đọc code spaghetti không hiểu được, học khó hiểu
  • Với yêu cầu từ khách hàng, developer phải đi "mò" những yêu cầu ẩn
  • Dự án có nghiệp vụ phức tạp nhưng không có tài liệu về nghiệp vụ, quy trình, thiết kế
  • Dự án sử dụng CodeIgnitor như mô hình MVC và kiến trúc không được tuân thủ tốt
  • Coding convention không được tuân thủ
  • Không có tài liệu thiết kế database. DB không có annotation
  • Luôn xảy ra nhu cầu cần sửa đổi cấu trúc DB, tên trường trong DB do thay đổi nghiệp vụ
  • git pull request không được review (dù có cơ chế approve) tốt
  • (HMLT) Data table đơn giản, ít chức năng, cần phải code nhiều khi có yêu cầu thay đổi từ khách hàng (như: sorting, hide/unhide trường, dữ liệu, điều chỉnh độ rộng cột, hàng, inline edit cell (giống Excel)

Không học được gì:

  • Dự án không thực sự có một người mạnh về kỹ thuật ở mức "technical lead", dẫn dắt team về định hướng kỹ thuật
  • Kỹ thuật sử dụng trong dự án không có gì nổi trội
  • Không được hướng dẫn
  • Không được hỗ trợ gì nhiều từ những người có kinh nghiệm hơn (họ bận việc khác)
  • Phản biện: Liệu member này thiếu sự tự giác, tự chủ, cầu tiến hay không?
  • Các framework kỹ thuật dùng trong dự án cũ kỹ
  • Dự án/sản phẩm thiếu một vision dài hạn và mục tiêu ngắn hạn (member lo lắng cho tương lai của dự án/của bản thân mình)

​Giải pháp:

  1. Trả nợ technical debt càng sớm càng tốt
  2. Viết tài liệu cho hệ thống
  3. Viết thiết kế cho hệ thống
  4. Tổng hợp know-how, kiến thức cho hệ thống, từ developers, members trong team
  5. Tổ chức test festival để thu thập kiến thức, tìm ra một cái nhìn chung về cách hệ thống chạy, requirement, tìm lỗi hệ thống
  6. Tổ chức code review festival để chia sẻ hiểu biết về code, tìm ra bất cập về mã nguồn
  7. Tổ chức retrospective thường xuyên để tìm ra những điểm bất cập, những điểm cần/có thể improve

Advertisements

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Đăng xuất / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Đăng xuất / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Đăng xuất / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Đăng xuất / Thay đổi )

Connecting to %s