Làm thế nào để quản lý ra khỏi quá trình phát triển của chúng tôi


14

Tôi là một kỹ sư phần mềm trong một nhóm phát triển phần mềm. 3 năm qua chúng tôi đã làm việc cho một khách hàng nội bộ về một sản phẩm mới. Bây giờ sản phẩm này đã hoàn thành, chúng tôi sẽ làm việc trên các tính năng mới chính cho các sản phẩm hiện có. Đối với một tính năng cụ thể, quản lý sản phẩm đã đoán được phải mất 150 giờ để phát triển. Cùng với người quản lý dự án của chúng tôi, chúng tôi đã tạo ra một kế hoạch rất chi tiết và chúng tôi đã nỗ lực trong 300 giờ. Hôm qua chúng tôi đã thảo luận về điều này và họ nghĩ rằng chúng tôi đã đánh giá quá cao những thứ.

Trong kế hoạch của chúng tôi, chúng tôi ước tính hàng giờ để viết bài kiểm tra đơn vị, ý tưởng của họ là bỏ chúng để tiết kiệm thời gian. Quyết định chưa được đưa ra và tôi sẽ bảo vệ kế hoạch này và các bài kiểm tra đơn vị nếu cần. Nhưng điều tôi thực sự không thích ở đây là quản lý đang can thiệp vào quá trình phát triển của chúng tôi. Làm thế nào để tôi giữ chúng ra khỏi quá trình phát triển của chúng tôi? Và những đối số nào tôi có thể sử dụng để giữ cho thử nghiệm đơn vị tại chỗ (bên cạnh chất lượng và tiết kiệm thời gian dài hạn)?

Một lưu ý nữa là công ty chúng tôi có 3 nhóm kỹ thuật và nhóm tôi sẽ giao phần mềm của họ đúng hạn (cho hoặc nhận 10% lợi nhuận). Trong khi các đội khác luôn giao hàng trễ, chủ yếu là do đánh giá thấp trong kế hoạch. Họ chỉ lập kế hoạch mã hóa chứ không phải quản lý, kiểm tra và xử lý xung quanh nó.


1
Làm thế nào tốt quản lý hiểu quá trình phát triển?
JB King

5
Tại sao quản lý không được bao gồm trong "của chúng tôi"? Đó là trung tâm của vấn đề đó. Quản lý không phải là "Chúng tôi Vs. Chúng", lịch trình so với các tính năng. Tại sao họ không cảm thấy được bao gồm, như vậy họ cần phải tập cơ bắp muộn và cắt cơ?
Alex Feinman

Nhảy tàu. @Alex, không phải đội ngũ quản lý nào cũng quan tâm đến việc tham gia. Nếu họ muốn được bao gồm, họ sẽ được bao gồm; họ quản lý. Các công ty dẫn đầu về kỹ thuật là thiểu số.
Mark Canlas

1
@Mark, thường là trong khả năng của bạn để thu hút những người tạo nên đội ngũ quản lý. Quản lý trở lên là một kỹ năng sinh tồn / hạnh phúc hữu ích.
Alex Feinman

Câu trả lời:


5

Đầu tiên, hãy để tôi nói tôi hoàn toàn thông cảm với vị trí của bạn. Nó có thể gây bực bội khi bạn thiếu hiểu biết hoặc sự cố giao tiếp giữa các bộ phận khác nhau của doanh nghiệp. Có nói rằng, tôi không nghĩ bạn nên cố gắng tránh xa họ. Thay vào đó bạn nên cho họ thấy những con số về lý do tại sao đây là một ý tưởng tốt. Những sự thật nào bạn có mà biện minh cho việc kiểm tra đơn vị có xứng đáng với công sức bạn bỏ ra không? Nếu bạn không có bất kỳ thứ gì, thì bạn nên bắt đầu thu thập những số liệu đó hoặc hiển thị một số nghiên cứu để sao lưu các yêu cầu của mình.

Tôi đã phải tự mình giải quyết các tình huống tương tự và tôi đã trả lời câu hỏi này về một chủ đề tương tự . Tôi cũng viết blog về cách tôi xử lý nó ở đây:

http://prrealagility.com/show-them-the-numbers-its-results-that-matter/

Trong trường hợp bạn không cảm thấy muốn đuổi theo liên kết, tôi sẽ lặp lại tóm tắt của tôi từ câu hỏi liên quan:

Tóm lại, tôi đã so sánh số giờ ước tính của chúng tôi với số giờ thực tế cho dự án và sau đó so sánh tỷ lệ lỗi của chúng tôi với tỷ lệ lỗi của các đội khác. Trong trường hợp của chúng tôi, những con số này được so sánh thuận lợi và không còn mối quan tâm nào nữa.

Kết luận của tôi dựa trên kinh nghiệm này là:

... Cách tốt nhất để thuyết phục bất cứ ai rằng cách tiếp cận của bạn để làm một cái gì đó là thực tế và thực dụng, là làm nó và đo lường nó chống lại các phương pháp khác. Mọi người không quan tâm đến giáo điều, hoặc tại sao bạn nghĩ rằng một cái gì đó nên là cách tốt nhất. Chỉ bằng cách cho mọi người thấy các con số và đo lường hiệu quả của phương pháp của bạn, bạn mới có thể thực sự cho thấy rằng các hoạt động của bạn có hiệu quả.

Nếu nhóm quản lý của bạn không đồng ý đầu tư những gì họ thấy là thêm 150 giờ cho thử nghiệm đơn vị, có lẽ bạn có thể thuyết phục họ đầu tư vào một khu vực nhỏ của sản phẩm (hoặc thậm chí đồng ý tự mình cung cấp một số giờ để cung cấp một số dữ liệu ). Thực hiện kiểm tra đơn vị trong một khu vực của sản phẩm sau đó thu thập dữ liệu về tỷ lệ lỗi trong khu vực đó của sản phẩm và chi phí để tìm và sửa các lỗi đó so với tỷ lệ lỗi ở các khu vực khác của sản phẩm. Hy vọng bạn sẽ thu thập một số dữ liệu để sao lưu trường hợp của bạn và đây sẽ không phải là vấn đề cho dự án tiếp theo của bạn.


20

Quy tắc số một phải tuân theo, bất kể phương pháp bạn sử dụng là gì

  1. Các nhà phát triển nên có quyền ước tính công việc của chính họ.
  2. Các bên liên quan nên có quyền ưu tiên trong số các công việc đó.

Ước tính và ưu tiên là hai lực lượng phối hợp rất tốt với nhau một khi cả hai bên chấp nhận trách nhiệm của mình. Vì vậy, thay vì lãng phí thời gian để tranh luận, hãy đồng ý với điều này và tôn trọng rằng cả hai bên sẽ làm việc hết khả năng của mình.


Điều gì xảy ra nếu họ không ưu tiên kiểm tra?
JeffO

16
Thử nghiệm không phải là những gì họ có cơ hội để ưu tiên. Nó là một phần của quá trình phát triển tiêu chuẩn. Họ nên ưu tiên các tính năng không phải là quá trình.
HLGEM

12

Bạn có thể chỉ ra rằng các bài kiểm tra đơn vị tiết kiệm thời gian, vì vậy nếu bạn bỏ chúng, ước tính sẽ là 500 giờ.


3
Đó là lén lút.
JeffO

8
Và có lợi ích là sự thật.
HLGEM

2
Mặc dù nó đúng với các kỹ sư, tôi không biết làm thế nào bạn có thể truyền đạt một cách thực tế nghịch lý đó đến những người không phải là kỹ sư.
Mark Canlas

2
Bằng cách cung cấp cho họ ước tính mới, nơi bạn đã thêm nhiều giờ hơn vào phần gỡ lỗi của ước tính.
HLGEM

Thái độ sai đối với tôi. Điều đó sẽ không đi đến kết quả nhóm tổng thể tốt (bao gồm cả quản lý).
Marc

6

Nói với họ về nợ kỹ thuật và giá trị của thử nghiệm đơn vị

Nhìn vào bài đăng này từ một số ý tưởng tốt đẹp về nợ kỹ thuật. Theo dõi từ bài viết đó, bạn có thể nhận được bản pdf sau

Tôi thích bài đăng này về giá trị của thử nghiệm đơn vị (có thể có nhiều hơn để tìm)

Hy vọng không phải là đưa họ ra khỏi quá trình phát triển của bạn mà là để họ tham gia và cam kết đúng cách.

IMHO bạn cần viết kế hoạch ban đầu của bạn xuống, thêm chương 1 và 2 (không phải trong phụ lục) trong đó bạn giải thích nợ kỹ thuật và giá trị của thử nghiệm đơn vị. Cung cấp cho họ lựa chọn thay thế:

  • ít giờ hơn (không phải toàn bộ 150, nghe có vẻ vô lý) trong đó trung bình mọi thay đổi (trong giai đoạn phát triển và trong quá trình bảo trì) sẽ diễn ra:
    • nhỏ 4 giờ
    • trung bình 16 giờ
    • lớn 40 giờ
  • số giờ ước tính của bạn trong đó trung bình mọi thay đổi (giai đoạn phát triển và trong quá trình bảo trì) sẽ diễn ra:
    • nhỏ 2 giờ
    • trung bình 8 giờ
    • lớn 20 giờ

(Giờ chỉ mang tính biểu thị. Bạn được trang bị tốt hơn để đưa ra ước tính phù hợp.)

Đừng quên bao gồm hồ sơ theo dõi của bạn để giao hàng đúng thời gian trên ngân sách.

Viết nó xuống và thảo luận với họ. Họ có thể có một số điểm có giá trị trong các tính năng mà hiện tại không thực sự cần hoặc một số khoản nợ kỹ thuật mà họ sẵn sàng thực hiện để giao hàng đúng hạn. Chỉ cần chắc chắn rằng đây là những lựa chọn có ý thức.

Hy vọng điều này sẽ giúp và may mắn.


3

Trước hết, đừng tách ra "viết bài kiểm tra đơn vị" thành một nhiệm vụ riêng biệt được ước tính, lên lịch và có khả năng, được cắt giảm. Ước tính của bạn phải ở cấp tính năng "Triển khai XYZ - 18 giờ". 18 giờ đó nên bao gồm mọi nội dung trong quy trình của bạn để đưa tính năng đó vào "XONG", bao gồm cả "kiểm tra đơn vị ghi".

Đó là một cách tốt để đưa sự phát triển phi kỹ thuật "ra khỏi quá trình phát triển của bạn". Đừng bao gồm quá trình phát triển của bạn trong danh sách nhiệm vụ hoặc lịch trình dự án mà bạn cung cấp cho họ!

Thứ hai, có vẻ như nhóm của bạn đã cung cấp sản phẩm tốt cho họ và đúng hạn, nhưng các đội khác thì không. Có lẽ nhóm quản lý này đã quen với việc quản lý các nhóm đó. Phát huy sở trường của bạn - đề nghị hiển thị cho họ các bản cập nhật hàng tuần hoặc hai tuần một lần với các tính năng hoạt động và chúng sẽ giúp bạn quay lại với "quá trình phát triển".


2

Tôi đã từng ở trong một tình huống mà tôi đang làm việc với một cơ sở mã ở trạng thái rất tốt; một tính năng mới đầy thách thức là cần thiết trong một khung thời gian rất ngắn và tôi đã xoay sở để cung cấp tính năng này trong một thời gian rất ngắn. Tại thời điểm đó, cơ sở mã đã ở trong tình trạng tồi tệ hơn nhiều. Vì vậy, tính năng đã được phân phối, nhưng công việc của tôi đã không được thực hiện: tôi phải đưa mọi thứ trở lại trạng thái tốt như nhau.

Tôi đã giải thích với người quản lý hai cấp độ như thế này: Nó giống như làm một công việc sơn trong nhà của bạn. Nếu tất cả các công cụ đều ở đó nơi chúng thuộc về và ở trạng thái tốt, tất cả các cọ vẽ được làm sạch, v.v., bạn có thể thực hiện công việc sơn rất nhanh. Nhưng sau đó bạn phải dành thời gian để đưa tất cả các công cụ của bạn trở lại theo thứ tự. Nếu bạn không làm điều đó, thì công việc sơn tiếp theo của bạn sẽ mất nhiều thời gian hơn. Trên thực tế, bạn sẽ không nhớ công cụ của mình ở đâu, cọ vẽ của bạn không thể cứu vãn được nữa và nó sẽ khiến bạn tốn thêm thời gian và tiền bạc như thể bạn đã hoàn thành công việc dọn dẹp ngay lập tức.

Và tương tự trong công việc lập trình của tôi: Bằng cách dọn dẹp, tôi đưa codebase vào trạng thái mà tôi có thể cung cấp một cái gì đó rất nhanh một lần nữa vào lần tiếp theo. Nếu không, lần sau sẽ mất nhiều thời gian hơn.


1

Bạn không thể ngăn họ hoàn toàn khỏi quy trình của bạn, sau tất cả họ trả tiền lương cho bạn và họ sẽ sử dụng sản phẩm của bạn (nếu không trực tiếp, có lẽ ai đó trong công ty bạn là người dùng cuối).

Các nhà quản lý cáo buộc các nhà phát triển về thời gian ước tính quá mức là một kịch bản rất phổ biến trong kinh nghiệm của tôi, và nếu không được giải quyết, nó có thể dẫn đến một cuộc chạy đua vũ trang khá ngu ngốc, nơi bạn ước tính tiếp theo sẽ tăng gấp đôi vì bạn biết các ông chủ sẽ giảm một nửa, họ biết điều này họ quý họ, vì vậy bạn tăng gấp bốn lần họ, v.v. Bạn cần tránh vòng luẩn quẩn này nếu có thể.

Giả sử không có lý do "thả chết" cho thời hạn thì tôi sẽ đề xuất 2 điều.

  1. Đưa ra một kế hoạch chi tiết về những gì bạn nghĩ bạn có thể làm trong 150 giờ, tuân theo cách tiếp cận hiện tại của bạn về công việc chất lượng cao. Liệt kê chính xác những gì có thể được cung cấp trong khung thời gian này. Câu trả lời từ KeesDijk có một số liên kết rất tốt về lập kế hoạch ở cấp độ hạt mịn.
  2. Thực hiện theo cùng một phong cách lập kế hoạch chi tiết để bao quát tất cả các tính năng và cho thấy sẽ mất 300 giờ (hoặc bất cứ điều gì con số đưa ra tại).

Sau đó đi làm và báo cáo lại thường xuyên về tiến độ, và nếu có thể có một số giao hàng đều đặn. Điều này sẽ cung cấp cho sự tự tin của quản lý về kỹ năng ước tính và khả năng cung cấp của bạn.


1

Yêu cầu họ cho các cơ sở ước tính của họ. Nó chỉ là công bằng để thảo luận về sự khác biệt. Kiểm tra đơn vị bán phá giá là một nền kinh tế sai lầm, những gì bạn không dành để viết các bài kiểm tra đơn vị bạn sẽ chi tiêu cho trình gỡ lỗi sau này (và lâu hơn). Về cơ bản, bạn đã ghi lại thực tế bạn dự định thử nghiệm công việc bạn hoàn thành. Họ đang nói với bạn không nên kiểm tra gì cả . Cho dù bạn kiểm tra bằng cách sử dụng kiểm tra đơn vị hoặc kiểm tra đột xuất khi bạn phát triển dự án, bạn vẫn cần tính đến thời gian đó. Xóa thời gian bạn đã phân bổ cho kiểm tra đơn vị cũng xóa thời gian được phân bổ cho kiểm tra đột xuất.

Điểm mấu chốt: dính vào súng của bạn với ước tính của bạn. Hồ sơ theo dõi của bạn cho thấy bạn biết những gì bạn đang nói và có thể đưa ra câu trả lời hợp lý dựa trên ước tính của bạn (giả định, kỳ vọng, hiệu suất trong quá khứ, v.v.). Có vẻ như quản lý cấp trên của bạn không có khả năng hiển thị mà họ cần để tạo ước tính hợp lý. Có phải họ giả định 8 ngày không có gián đoạn cho các cuộc họp? Họ có ngân sách để thử nghiệm hệ thống trong ước tính của họ? Làm thế nào mà họ đưa ra con số là một nửa của bạn, xem xét hồ sơ theo dõi của bạn?


-1

Tôi sẽ ước tính sẽ mất 300 giờ và nếu ngân sách 150 của họ cung cấp cho họ tùy chọn thì đó sẽ là công việc vội vàng hoặc trễ để được giao. Khi dự án hoàn thành và đúng như bạn dự đoán thì bạn chỉ có thể nói với họ đó là những gì bạn yêu cầu.


Điều đó có thể được chấp nhận hoàn toàn trong một số tình huống, nhưng tôi muốn làm rõ hơn. Như một động lực bổ sung để làm sáng tỏ nó là kế hoạch của chúng tôi được tính đến trong các đánh giá hàng năm của chúng tôi.
thiệu

4
Cung cấp chất lượng thấp hơn là một ý tưởng tồi, đội ngũ này dường như có một danh tiếng tốt, có thể bị mất mãi mãi hoặc trong một thời gian dài, nếu họ làm công việc chất lượng kém.
Steve

1
Đừng. Bạn có thể đề nghị loại bỏ các tính năng hoặc làm cho một số tính năng có mức độ ưu tiên thấp (điều tương tự). Nhưng làm cho phần mềm lỗi trên mục đích đơn giản là không chuyên nghiệp.
nikie

Tôi không đề xuất tạo ra phần mềm lỗi trên mục đích. Tôi đề nghị nói với họ trước rằng việc cắt trích dẫn nhưng không yêu cầu sẽ dẫn đến phần mềm bị lỗi. Đó là sự lựa chọn của họ.
Craig

-1

Wally sẽ làm gì?

Có nhiều cách để diễn giải những gì quản lý yêu cầu bạn, một là họ không muốn bạn giao hàng đúng hẹn.

Có vẻ vô lý? Có, nhưng làm thế nào khác họ có thể biết rằng bạn không đánh giá quá cao? Đừng đáp ứng thời hạn của bạn (chùng xuống nếu cần thiết), nếu bạn trượt và vô tình giao thứ gì đó đúng giờ, hãy chắc chắn trông rất mệt mỏi vì không tạo ấn tượng rằng đó là một cuộc đi dạo trong công viên.


@Downvoter Bạn nghĩ rằng con đường "tốt" của việc cố gắng dạy quản lý cách quản lý là thực sự hiệu quả? Gợi ý: "Xin chào, bạn đang làm sai công việc của mình, bạn nên làm như thế này, theo cách đó sẽ tốt hơn cho mọi người.". Phản ứng thế giới tối ưu: "Bắt tốt, chúng tôi có thể đã tạo ra một số mớ hỗn độn thực sự, kể từ bây giờ, chúng tôi sẽ làm mọi thứ theo cách bạn vừa nói với chúng tôi. Đây là một sự tăng lương." Phản ứng của thế giới thực: "STFU và đi làm những gì bạn được trả tiền để làm.".
aaaaaaaaaaaa

-1

Bạn đang ở trong một dưa chua. Nếu bạn dính súng và muốn làm bài kiểm tra đơn vị, và muốn yêu cầu 300 giờ, bạn sẽ tạo ra kẻ thù.

Nếu bạn giảm xuống 150 giờ và kiểm tra đơn vị chuck, bạn có thể cung cấp một sản phẩm buggier nhanh hơn, nhưng nó sẽ gây đau buồn xuống đường, với chi phí bảo trì cao hơn.

Dù bằng cách nào, bạn sẽ thua.

Hoặc có vẻ như vậy.

Bạn thấy đấy, bạn không điều hành một phòng thí nghiệm khoa học tại một trường đại học. Bạn đang cung cấp dịch vụ kinh doanh cho một đơn vị kinh doanh trong một công ty cung cấp dịch vụ cho khách hàng trong hệ sinh thái của các công ty. Công ty của bạn có thể cần sản phẩm của bạn để bắt đầu cung cấp dịch vụ nhanh hơn và tốt hơn cho khách hàng của mình và do đó tăng doanh thu cần thiết.

Bạn thấy đấy, cái bạn cần là phân tích ROI và bạn không có tất cả dữ liệu để thực hiện phân tích đó. Bạn chỉ có một số phần chi phí (bạn không biết số bảng lương của mọi người) và bạn chắc chắn không có phần doanh thu, đặc biệt không phải là dự báo doanh thu.

Quản lý của bạn, tin hay không, rất giỏi trong việc đưa ra các dự báo ROI (đó là những gì họ dạy trong trường kinh doanh) và có thể đã thực hiện nhiều dự đoán ROI và đưa ra "nếu chúng ta hành động ngay bây giờ, chúng ta sẽ kiếm được nhiều tiền hơn với việc trả gấp ba cho việc bảo trì phần mềm, các bozos trong CNTT phàn nàn. "

Vì vậy, nếu bạn muốn điều hành công ty, hãy bắt đầu công ty của riêng bạn. Bạn sẽ thấy, nó không dễ dàng như vậy.

Nói cách khác: làm những gì bạn nói. Nếu quản lý biết những gì nó đang làm, bạn sẽ đi ra phía trước. Nếu không, bạn đã nghỉ việc, kiểm tra đơn vị hay không.

ROI bạn hỏi là gì? Hoàn lại vốn đầu tư. Đó là một tên xấu mặc dù. Nó cần phải được hoàn vốn đầu tư kịp thời (ROTI), bởi vì thời gian là tất cả mọi thứ trong đầu tư.


Gì, không như lời khuyên của tôi? Rất tiếc. Vì vậy, từ các chiến hào mặc dù.
Christopher Mahan
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.