Quản lý phần mềm làm cho các nhà phát triển làm Quản lý dự án

Tôi là một nhà phát triển phần mềm làm việc trong một công ty hệ thống nhúng. Chúng tôi có Giám đốc dự án, người đảm nhiệm lịch trình tổng thể của dự án (bao gồm cả điện, chất lượng, phần mềm và sản xuất) do đó lịch trình phần mềm của anh ấy rất ngắn gọn.

Chúng tôi cũng có Giám đốc phần mềm, ông chủ của tôi. Anh ấy bắt tôi viết và duy trì lịch trình phần mềm, tài liệu thiết kế (thiết kế cấp cao và cấp thấp), SRS, quản lý thay đổi, kế hoạch xác minh và báo cáo, quản lý phát hành, đánh giá và tất nhiên là phần mềm.

Chúng tôi chỉ có một Kỹ sư kiểm tra cho toàn bộ nhóm phần mềm (10 thành viên) và tại bất kỳ thời điểm nào, có một vài dự án đang diễn ra.

Tôi đang dành 80% thời gian để làm những tài liệu này. Sếp của tôi đến từ nền tảng Quy trình và tin rằng những gì chúng tôi cần là tài liệu tốt hơn để cải thiện phần mềm:

1. Ông coi thiết kế là tối quan trọng, mã hóa là "chỉ viết thiết kế xuống", nó không mất quá nhiều thời gian và "tất cả mã phải được viết trước khi phần cứng sẵn sàng".
2. Không hiểu sự khác biệt giữa điều khiển Phiên bản Trung tâm & Phân tán, ngay cả sau khi chúng tôi nói với anh ta rằng việc cộng tác với một mô hình phân tán dễ dàng hơn.
3. Không hiểu mã và muốn hiểu mọi lỗi và giải pháp đề xuất của nó.
4. Việc xác minh tin tưởng nên được thực hiện bởi nhà phát triển và xác thực bởi Người kiểm tra. Mặc dù vậy, việc xác minh của chúng tôi chỉ kiểm tra xem việc triển khai có đúng không (chúng tôi không viết bài kiểm tra đơn vị, nó không bao giờ được xem xét trong lịch trình) và xác thực là kiểm tra hộp đen, vì vậy các bài kiểm tra đơn vị bị thiếu.

Tôi thực sự bối rối.

1. Tôi có trách nhiệm duy trì tất cả các tài liệu này không? Về bản chất, nó làm tôi cảm thấy như mình đang làm Quản lý dự án phần mềm. Tôi ổn với tài liệu kỹ thuật, nhưng tôi tin rằng việc lập kế hoạch / lập kế hoạch không nên được thực hiện bởi nhà phát triển.
2. Tôi thực sự không thích tạo tài liệu, tôi muốn giải quyết vấn đề và viết mã. Theo kinh nghiệm của tôi, việc tạo tài liệu thiết kế chỉ giúp ở một mức độ nào đó, nó không bao giờ là giải pháp để mã tốt hơn hoặc nhanh hơn.
3. Tôi cảm thấy ông chủ không thực sự quan tâm đến việc tạo ra những sản phẩm tốt hơn, mà chỉ là về việc trở thành một người quản lý tốt trong mắt ban lãnh đạo.

Tôi có thể làm gì? Cả năm nay tôi đã thực hiện 3 tháng mã hóa thực tế, phần còn lại chỉ dành cho việc tạo tài liệu và chờ báo cáo lỗi từ khách hàng.

Bạn có vẻ như là một kỹ sư phần mềm.

Người quản lý dự án tập trung nhiều hơn vào trạng thái của toàn bộ dự án và phân bổ các nguồn lực một cách hiệu quả để đảm bảo rằng các mốc quan trọng được đáp ứng và trong thời gian thích hợp. Họ cũng loại bỏ các rào cản và giúp các tài nguyên dự án tập trung vào các chức năng công việc cụ thể của họ.

Viết và duy trì thiết kế và tài liệu kỹ thuật là một phần quan trọng của việc trở thành một kỹ sư phần mềm và phù hợp với vai trò của bạn. Quá nhiều điều tốt có thể là xấu mặc dù (Xem Phân tích Paraylsis ).

Ông coi thiết kế là tối quan trọng, mã hóa là "chỉ viết thiết kế xuống"

Nếu người quản lý dự án coi các tài liệu thiết kế là tối quan trọng thì anh ta hy vọng các tài liệu đó có thể giao được trong quy trình. Đó không phải là một sự lãng phí thời gian từ phía bạn nếu anh ấy cảm thấy họ đủ quan trọng để phân bổ 80% thời gian của bạn cho nó.

không nên mất quá nhiều thời gian và "tất cả mã phải được viết trước khi phần cứng sẵn sàng".

Đây là suy nghĩ mơ ước và một quan điểm kiểu Thác nước cổ xưa về cách phát triển phần mềm hoạt động. Nó luôn luôn không bao giờ sạch sẽ cho dù bạn có dành bao nhiêu thiết kế và chuẩn bị. Tuy nhiên, trên lưu ý đó, bạn nên có thông số kỹ thuật phần cứng rõ ràng và môi trường kiểm tra phù hợp và mô phỏng phần cứng giả định để mã của bạn tương tác nhưng một lần nữa, thế giới thực lại lộn xộn.

Quản lý dự án là vô cùng dễ dàng trong một thế giới hoàn hảo. Thế giới không hoàn hảo tuy nhiên dù bạn mong muốn đến mức nào thì việc quản lý dự án thực sự trở nên vô cùng khó khăn. Đây là lý do tại sao họ được trả nhiều tiền

(2) Không hiểu sự khác biệt giữa điều khiển Phiên bản trung tâm & phân tán.

Tại sao anh ta phải quan tâm? Nó ảnh hưởng đến các cột mốc như thế nào? Nó không.

3) Không hiểu mã và muốn hiểu mọi lỗi và giải pháp đề xuất của nó

Mục tiêu của anh ấy là cho phần mềm làm việc và bạn cũng vậy. Anh ta không cần phải hiểu mã nhưng anh ta cần phải hiểu các vấn đề ngăn cản phần mềm làm việc. Một khi hai bạn nhìn thấy nhau ở cấp độ cơ bản này thì mục tiêu chung của bạn sẽ giúp bạn làm việc cùng nhau hiệu quả hơn.

(4) Xác minh tin tưởng nên được thực hiện bởi nhà phát triển và xác thực bởi Người kiểm tra.

Điều gì là sai với tình cảm này? Người kiểm tra trong vai trò đảm bảo chất lượng nên được quan tâm với việc xác nhận các tính năng và yêu cầu. Các nhà phát triển nên thực hiện mọi nỗ lực để xác minh và kiểm tra công việc của họ trước khi đi kiểm tra.

Tôi thực sự không thích tạo tài liệu, tôi muốn giải quyết vấn đề và viết mã.

Nếu bạn muốn trở thành một lập trình viên đơn giản thì có lẽ bạn nên nói chuyện với sếp của bạn về điều này và xem liệu có vai trò nào tốt hơn cho bạn trong dự án hay không. Ai đó cần viết và duy trì tài liệu kỹ thuật, vì vậy có lẽ một trong những nhà phát triển khác có thể giúp bạn thực hiện một số nhiệm vụ này để bạn không mất 80% thời gian để viết tài liệu.

Theo kinh nghiệm của tôi, việc tạo tài liệu thiết kế chỉ giúp ở một mức độ nào đó, nó không bao giờ là giải pháp để mã tốt hơn hoặc nhanh hơn.

Điều này chủ yếu là đúng ... nhưng chỉ khi tất cả mười nhà phát triển dành 80% thời gian của họ để viết tài liệu kỹ thuật mà không ai sẽ đọc. Đây là một mô hình chống quản lý khổng lồ mà tôi đã sống trước đây. Nếu bạn thấy rằng bạn đang làm hầu hết các tài liệu cho nhóm thì có vẻ như công bằng rằng bạn bị từ chối quyền thực hiện nhiều công việc mã hóa hơn.

Thực tế của vấn đề là tài liệu kỹ thuật tốt nhất là chính mã.

Tôi cảm thấy ông chủ không thực sự quan tâm đến việc tạo ra những sản phẩm tốt hơn, mà chỉ là về việc trở thành một người quản lý tốt trong mắt ban lãnh đạo

Tôi cảm thấy rằng ông không chăm sóc bởi vì sản phẩm là phường của mình và nếu các dự án và các tính năng không được điền đầy đủ và khách hàng không hài lòng sau đó quản lý cấp trên sẽ không chăm sóc cho anh ấy rất nhiều. Vấn đề là quan điểm của bạn về các cải tiến chất lượng cần thiết không phù hợp với quản lý cấp trên và quản lý cấp trên và nhận thức của khách hàng về những gì họ cảm thấy là quan trọng.

Cố gắng hiểu điều gì thực sự quan trọng đối với sản phẩm, bởi vì trong khi bạn có thể tăng hiệu quả của quy trình gấp 3 lần, nếu bạn dành cả tuần để làm điều này thì đó là chi phí của một tính năng quan trọng khác mà khách hàng đang yêu cầu.

Tất cả chúng ta đều muốn nhìn tốt vào mắt cấp trên của mình. Không có gì sai với điều đó, đó là bản chất của con người là tự phục vụ. Đây là một thực tế của cuộc sống.

Ở một số độ, tôi đồng ý với người quản lý dự án của bạn. Phát triển phần mềm vượt xa các tính năng mã hóa. :-)

Với tình huống của bạn, tôi sẽ đến gặp anh ấy và giải thích rằng các yêu cầu của anh ấy chiếm 80% thời gian của bạn và tìm cách hiểu tại sao điều quan trọng đối với anh ấy là bạn dành thời gian này để duy trì tài liệu thay vì phát triển (vượt xa mã hóa).

FYI, Atlassion , một công ty phần mềm, có tỷ lệ 13 nhà phát triển cho một người QA và hầu hết các thử nghiệm (lập kế hoạch và thực hiện) được thực hiện bởi các nhà phát triển. Tôi đã học được điều này trong một trong những bài thuyết trình của họ tại Agile 2012 và các đội của chúng tôi hiện đang cố gắng thi đua thực hành này.

Tuy nhiên, tôi cũng sẽ thảo luận với người quản lý dự án của bạn nếu anh ta sẽ cởi mở để thử Scrum như một phương pháp để giúp thúc đẩy toàn bộ nhóm tiến lên. Đưa ra mô tả của bạn, tôi không nghĩ bạn đang sử dụng Scrum.

Giống như bạn, tôi đã vô cùng thất vọng khi duy trì các kế hoạch liên tục thay đổi và cách tiếp cận nhẹ nhàng của Scrum đã giúp tôi vượt qua sự thất vọng này.

Các đội có hiệu suất cao nhất theo kinh nghiệm của tôi là những đội phải đối mặt với ít quy trình cần thiết nhất để thực hiện công việc của họ. Tại một số điểm, quá trình bổ sung bắt đầu lấy đi chất lượng từ sản phẩm. Nếu QA bắt đầu bỏ lỡ lỗi vì họ quan tâm nhiều hơn đến việc giải quyết vấn đề giấy tờ và DEV không mã hóa các tính năng hoặc sửa lỗi vì họ đang viết tài liệu thì bạn có vấn đề. Tuy nhiên, việc tìm ra nếu đây thực sự là trường hợp trong công ty của bạn là một câu hỏi được địa phương hóa cao mà chỉ những người trong nhóm của bạn mới có thể trả lời (không phải chúng tôi).

Có một điều mà sếp của bạn rất sai, và đó là thực tế là bạn có quá ít QA và không có bài kiểm tra đơn vị. Một lỗi được tạo bởi nhà phát triển là theo định nghĩa của một giám sát. Mong các nhà phát triển luôn kiểm tra các tính năng của riêng họ và có ít thử nghiệm ngoài đó là một vấn đề về quy trình. QA có thể được thay thế bằng kiểm tra tự động tùy thuộc vào tên miền của bạn ở một mức độ nào đó, nhưng nếu bạn không có thì có lẽ bạn sẽ để lỗi xảy ra (và điều đó thường kết thúc với chi phí cao hơn so với việc tìm ra chúng sớm).

Ngoài ra, từ góc độ kinh doanh nghiêm ngặt, việc thuê QA rẻ hơn so với thuê các nhà phát triển. Bạn sẽ có thể trang trải nhiều tiền hơn cho số tiền đã chi nếu các đội có tỷ lệ QA / DEV tốt.

Các triển khai CMMI mà tôi đã thấy hoặc nghe trực tiếp về tất cả đều là quá trình và tài liệu nặng nề; ông chủ của bạn tin rằng tài liệu này phải đủ chi tiết để khiến việc thực hiện trở nên tầm thường ngụ ý mạnh mẽ rằng kỳ vọng của anh ta là tương tự.

Nếu bạn đang nhận được một phần không tương xứng của việc viết / bảo trì tài liệu, yêu cầu nó được phân phối đều hơn là hợp lý. Nếu các nhà phát triển khác có tài liệu tương tự như tỷ lệ mã hóa và bạn muốn dành phần lớn thời gian để viết mã; có lẽ đã đến lúc cân nhắc tìm một chủ nhân mới.

Bạn đang nói về các hệ thống y tế ... vì vậy an toàn là tối quan trọng - và do đó, tài liệu (cụ thể là truy xuất nguồn gốc) là rất cần thiết.

Một người kiểm tra có vẻ hơi nhẹ, nhưng ngoài điều đó, có - bạn có trách nhiệm đảm bảo tài liệu được đưa ra.

Kinh nghiệm của tôi trong thế giới y tế còn hạn chế, nhưng trong thế giới hàng không vũ trụ, chúng ta có Do-178B (nay là C) quy định một mô hình vòng đời quy định tài liệu và mức độ thử nghiệm cần thiết (tùy thuộc vào mức độ quan trọng an toàn [cụ thể hơn, mức độ đảm bảo thiết kế] của phần mềm) và trong thế giới ô tô, chúng ta có ISO26262, tương tự như vậy.

Nếu tài liệu không đúng chỗ, sản phẩm sẽ không được chứng nhận.

Nhưng điều quan trọng là làm việc với tài liệu được yêu cầu để làm cho sản phẩm của bạn tốt hơn ... đừng thử và thiết kế ngược lại tài liệu như một suy nghĩ sau bởi vì sau đó nó không phục vụ mục đích trong thế giới thực.