Mặc dù các kỹ năng thực tế và kiến thức về các ngôn ngữ, công cụ và công nghệ lập trình cụ thể là chìa khóa để có được công việc toàn thời gian với tư cách là nhà phát triển phần mềm, nhưng có một chỉ số giá trị khác có thể được coi là tiền giả định để thành công trong nghề này theo nhiều cách: năng suất. Đo lường năng suất là điều mà tất cả các nhà phát triển phần mềm chuyên nghiệp cần phải hiểu và tính đến vì các số liệu hiệu suất vốn đã rất quan trọng đối với bất kỳ nhóm phát triển phần mềm nào trong môi trường kinh doanh ngày nay.
Tại sao năng suất của bạn với tư cách là một nhà phát triển lại quan trọng?
Trong thời đại phát triển Agile, DevOps và thu hẹp chu kỳ phát hành phần mềm, khi các nhà phát triển cần gửi các phiên bản sản phẩm mới càng nhanh càng tốt, các công ty sử dụng nhiều chỉ số năng suất khác nhau để đánh giá hiệu suất của từng lập trình viên và toàn bộ nhóm. Xem xét điều này từ quan điểm của nhà phát triển, đo lường hiệu suất có thể phục vụ một số mục đích có giá trị, giúp bạn theo dõi tiến trình kỹ năng lập trình của mình, điều này sẽ cho phép bạn đạt được sự phát triển nghề nghiệp nhất quán. Các lập trình viên có năng suất cao là những người cuối cùng nhận được mức lương cao ngất ngưởng và được làm việc trong các dự án thú vị nhất. Nhưng ngay cả khi bạn không hẳn là người đạt thành tích cao và chỉ muốn có bất kỳ công việc nào trong lĩnh vực phát triển phần mềm và thành công ở mức vừa phải trong đó, bạn vẫn cần có ít nhất một sự hiểu biết cơ bản về các chỉ số hiệu suất và cách chúng được sử dụng để đo lường năng suất đầu vào của bạn tại nơi làm việc. Đó là những gì chúng ta sẽ nói về ngày hôm nay.
Chỉ số đo lường năng suất phát triển phần mềm
Số liệu năng suất phát triển phần mềm là gì?
Số liệu phát triển phần mềm là các lĩnh vực của công việc lập trình nơi các phép đo định lượng có thể được áp dụng để theo dõi hiệu suất, chất lượng công việc và năng suất của nhà phát triển. Mọi thước đo năng suất đều dựa trên việc lấy dữ liệu từ quá trình phát triển và sử dụng dữ liệu đó để đo lường năng suất. Vì hầu như không có gì liên quan đến phát triển phần mềm là dễ dàng và đơn giản, bạn có thể nói rằng việc đo lường năng suất lập trình cũng khá không nhất quán và bị phân mảnh trong toàn ngành. Hay nói một cách đơn giản, các nhóm và công ty khác nhau có thể sử dụng các chỉ số hiệu suất hoàn toàn khác nhau và tiếp cận vấn đề này từ nhiều góc độ. Vì vậy, bạn không cần bận tâm đến việc tìm hiểu từng số liệu có thể được sử dụng bởi các nhóm phát triển phần mềm.
Có những loại thước đo năng suất phát triển phần mềm nào?
Đương nhiên, có nhiều chỉ số năng suất khác nhau tiếp cận việc đo lường hiệu suất ở các cấp độ và góc độ khác nhau. Dưới đây là các loại phổ biến nhất của số liệu năng suất như vậy:
Số liệu tập trung vào kích thước chính thức.
Các số liệu này tập trung vào việc đo lường quy mô kết quả công việc của lập trình viên, chẳng hạn như dòng mã (LOC), độ dài hướng dẫn mã, độ phức tạp của mã, v.v. Những số liệu này ngày càng được coi là lỗi thời trong ngành phát triển phần mềm ngày nay.
Số liệu năng suất tập trung vào thời gian và chức năng.
Có một lựa chọn các số liệu năng suất truyền thống được sử dụng trong phát triển phần mềm thác nước, chẳng hạn như ngày hoạt động, phạm vi chức năng được vận chuyển trong một khoảng thời gian nhất định, tỷ lệ rời mã, số lượng nhiệm vụ được giao, v.v.
Số liệu quy trình phát triển linh hoạt.
Các số liệu quy trình phát triển nhanh, chẳng hạn như báo cáo phân tích nước rút, vận tốc, thời gian hoàn thành, thời gian chu kỳ và các số liệu khác, có lẽ là số liệu được sử dụng phổ biến nhất trong các nhóm phát triển phần mềm hiện nay. Chúng ta sẽ nói chi tiết hơn về số liệu Agile ở phần sau của bài viết.
Chỉ số phân tích hoạt động.
Bộ số liệu này tập trung vào việc đo lường hiệu suất phần mềm trong môi trường sản xuất hiện tại của nó. Thời gian trung bình giữa các lần lỗi (MTBF), thời gian trung bình để khôi phục (MTTR) và tỷ lệ sự cố ứng dụng là các số liệu được sử dụng nhiều nhất tại đây.
Các chỉ số thử nghiệm.
Kiểm thử phần mềm có bộ số liệu riêng để đo lường chất lượng của kiểm thử hệ thống, chẳng hạn như tỷ lệ phần trăm kiểm thử tự động, phạm vi mã, v.v.
Chỉ số hài lòng của khách hàng.
Cuối cùng, thước đo cuối cùng cho bất kỳ phần mềm nào là trải nghiệm của khách hàng cuối và cũng có một tập hợp các thước đo cho điều đó, chẳng hạn như điểm nỗ lực của khách hàng (CES), điểm hài lòng của khách hàng (CSAT), điểm quảng bá ròng (NPS) và những người khác.
Chỉ số phát triển phần mềm linh hoạt
Như bạn có thể thấy, rất dễ bị lạc trong tất cả những điều phức tạp của các thước đo năng suất phần mềm. Tuy nhiên, thứ duy nhất mà một nhà phát triển phần mềm thông thường nên quen thuộc là các số liệu Agile, thường được các nhóm phát triển phần mềm sử dụng ngày nay làm tiêu chuẩn đo lường năng suất của nhóm trong các phần khác nhau của vòng đời phát triển phần mềm. Hãy liệt kê các số liệu Agile chính và được sử dụng phổ biến nhất.
1. Đốt cháy nước rút.
Báo cáo Sprint Burndown là một trong những số liệu chính cho các nhóm phát triển scrum nhanh nhẹn. Vì trong Agile, quy trình phát triển được tổ chức thông qua các lần chạy nước rút có giới hạn thời gian, Sprint Burndown được sử dụng như một cách để theo dõi việc hoàn thành các nhiệm vụ trong một lần chạy nước rút. Giờ hoặc điểm câu chuyện được sử dụng làm đơn vị đo lường. Mục tiêu là đạt được tiến độ nhất quán và phân phối công việc phù hợp với các dự đoán ban đầu. Sprint Burndown giúp các nhóm đo lường tiến độ công việc và điều chỉnh nó khi cần thiết.
2. Vận tốc nhóm.
Vận tốc là một chỉ số quan trọng khác, cũng dựa trên số giờ hoặc điểm câu chuyện làm đơn vị đo lường. Nó đo lường khối lượng công việc trung bình mà một nhóm hoàn thành trong một lần chạy nước rút và được sử dụng để ước tính và lập kế hoạch trong toàn bộ dự án. Theo dõi tốc độ là rất quan trọng để đảm bảo nhóm mang lại hiệu suất nhất quán.
3. Điểm câu chuyện.
Ở cấp độ của một thành viên nhóm phát triển cá nhân, điểm câu chuyện là một thước đo có giá trị, vì kích thước của câu chuyện mà một lập trình viên cung cấp trong mỗi lần phát hành là một chỉ báo về năng suất của người lập trình này.
4. Biểu đồ kiểm soát chu kỳ.
Đo tổng thời gian từ khi công việc trên một nhiệm vụ hoặc một hạng mục tồn đọng khác bắt đầu cho đến khi hoàn thành. Cho phép theo dõi và kiểm soát thời gian chu kỳ mang lại kết quả dễ đoán hơn.
5. Thông lượng và giá trị được cung cấp.
Người quản lý dự án phân tích các nhiệm vụ được giao cho các nhà phát triển và gán giá trị cho họ. Số liệu này sau đó được sử dụng để đo lường thông lượng của nhóm hay nói cách khác là lượng công việc giá trị gia tăng được thực hiện.
6. Mã khuấy.
Code churn là một số liệu khác đáng được đề cập vì nó được sử dụng để đo lường cả năng suất của một nhóm nói chung và để theo dõi hiệu suất của từng lập trình viên. Churn mã đo lường tần suất nhà phát triển xóa hoặc thực hiện thay đổi trong các dòng mã đã thêm trước đó và tỷ lệ phần trăm mã đã viết trước đó bị thay đổi hoặc loại bỏ.
ý kiến chuyên gia
Cuối cùng, để bổ sung thêm một số góc nhìn, một vài trích dẫn về vấn đề này của các chuyên gia có kinh nghiệm trong ngành phát triển phần mềm. “Tôi thực sự hy vọng bạn không muốn "so sánh" các số liệu của mình với một số loại tiêu chuẩn hoặc thậm chí với hiệu suất của một nhóm khác trong công ty khác. Ở mọi nơi tôi đã làm việc đều có những khác biệt độc đáo trong định nghĩa của họ về điểm câu chuyện, tốc độ, ước tính hàng giờ, nhiệm vụ, v.v. điều đó thực sự khiến cho việc so sánh trực tiếp hiệu suất của một nhóm từ công ty này với hiệu suất của nhóm khác ở công ty khác gần như không thể công ty,” Cliff Gilley, cựu Giám đốc Sản phẩm Kỹ thuật và Huấn luyện viên Agile, lưu ý. “Tôi hơi thận trọng với các số liệu khi nói đến việc hướng dẫn hiệu suất của nhóm. Khi bạn chỉ chú ý đến một hoặc hai biến số, bạn sẽ rất dễ rơi vào tình trạng (cố ý hay không) đánh lừa số liệu và đánh lừa bản thân rằng bạn đang cải thiện - trong khi tất cả những gì bạn đang làm là cải thiện số liệu. Ví dụ: các số liệu dựa trên tốc độ có thể "cải thiện" bằng cách nhóm chuyển sang các câu chuyện nhỏ hơn (ít công việc hơn trên mỗi câu chuyện - do đó, nhiều câu chuyện đã hoàn thành hơn - do đó tốc độ tăng lên). Đó có thể là một điều tốt nếu các câu chuyện là những câu chuyện hữu ích của người dùng mang lại giá trị kinh doanh gia tăng nhỏ hơn. Đó có thể là một điều tồi tệ nếu các câu chuyện trở nên nhỏ hơn và nhiều nhiệm vụ "kỹ thuật" hơn mà bản thân chúng không mang lại giá trị thực sự,” Adrian Howard, một chuyên gia khác trong ngành, cho biết. “Khi làm việc trong một hệ thống dựa trên kéo, tôi coi trọng thông lượng và thời gian quay vòng. Đầu tiên cung cấp cho tôi thông tin chung về năng lực của nhóm chúng tôi và theo thời gian có thể trở thành một biện pháp dự đoán rất hiệu quả. Thứ hai là hữu ích như một thước đo chung về hiệu quả của các đường ống dẫn của chúng tôi. Nếu thời gian chu kỳ cao, đã đến lúc bắt đầu xem xét quy trình, bởi vì có một hạn chế mà chúng ta có thể làm việc để nới lỏng/khai thác. Nhưng số liệu chỉ là công cụ. Đừng để bị lạc trong chúng, và chắc chắn đừng bắt đầu lập kế hoạch hướng tới một số liệu cụ thể. Hãy suy nghĩ về những gì bạn đang làm với tư cách là một nhóm và cách bạn làm việc một cách tự nhiên, sau đó xây dựng hệ thống xung quanh mọi người. Các số liệu sẽ giúp bạn biết hệ thống của bạn đang hỗ trợ công việc của mọi người như thế nào. Hoặc không,” Dave Cerra, một nhà sản xuất phát triển trò chơi điện tử, kết luận .
GO TO FULL VERSION