Trình quản lý tiếp tục thay đổi đặc tả yêu cầu sau mỗi bản demo [đóng]


21

Bối cảnh môi trường làm việc của tôi

Người quản lý của tôi không có nền tảng hoặc hiểu biết về máy tính hoặc phần mềm nào. Rất có khả năng anh ta đã không nhìn thấy mã dưới bất kỳ hình thức nào (thậm chí từ khoảng cách vật lý từ 10 feet trở xuống) trong cuộc sống của anh ta.

Không ai hiểu được sự phức tạp của những gì tôi được yêu cầu thực hiện. Đến mức nếu tôi bán mã cứng thì không ai biết.

Trong bài kiểm tra của Joel, chúng tôi cho điểm 0 không thể tin được.

Vấn đề

  • Người quản lý và đôi khi "cấp cao" khác tiếp tục thay đổi đặc điểm kỹ thuật yêu cầu. Những thay đổi, nếu kỹ thuật tốt được thực hiện và không phải là "sửa lỗi", yêu cầu thay đổi trong thiết kế cơ bản.
  • hoàn toàn không có một ai nhìn vào mã (có lẽ vì không ai biết làm thế nào để, hoặc thậm chí nếu nó nên được thực hiện) có nghĩa là không ai sẽ có thể:
    • Đánh giá cao sự phức tạp của vấn đề hoặc sự thanh lịch của giải pháp.
    • Đề xuất cải tiến cho cách tiếp cận.
    • Đánh giá cao chất lượng của mã.
    • Chỉ ra nơi mã có thể được cải thiện.
  • Rất nhiều biệt ngữ được sử dụng có ý nghĩa về mặt ngữ pháp nhưng không có ý nghĩa theo bất kỳ cách nào khác.
  • Không cảm thấy, hành xử hoặc làm việc như một công ty phần mềm.

Câu hỏi

Nên làm gì? Đặc biệt là không có ai chỉ ra những cải tiến trong mã của tôi.

Cập nhật

Để trả lời câu hỏi của HLGEM (và có thể là những người khác) về những gì tôi đã làm để thử và sửa nó. Tôi đề nghị thiết lập Redmine và giới thiệu kiểm soát nguồn cho mọi người. Tôi nói rằng tôi sẽ khuyên bạn nên phân phối (git hoặc đồng bóng) nhưng cũng sẽ nói về những người tập trung và để nhóm quyết định. Phản hồi là mọi thứ đang được thực hiện và sẽ được thực hiện trong vòng vài tuần. Tôi không thấy rằng tôi cũng không biết nếu các bộ phận khác của công ty sử dụng nó.


36
để trả lời câu trả lời rõ ràng: CHẠY !!
keppla

3
Trừ khi có một cái gì đó lớn mà bạn không nói với chúng tôi bắt đầu tìm kiếm một công việc mới.
Zachary K

11
"Người quản lý và đôi khi" cấp cao "khác tiếp tục thay đổi đặc điểm kỹ thuật yêu cầu." Chà, có một thông số sẽ cho bạn điểm 1 trong bài kiểm tra của Joel. : P
R. Martinho Fernandes

11
Không có tổ chức nào đạt ít hơn 2 điểm trong Bài kiểm tra Joel hoàn toàn vì các nhà quản lý phi kỹ thuật. Có một số điều bạn và các thành viên kỹ thuật khác của nhóm có thể làm mà không cần nhập từ các nhà quản lý phi kỹ thuật để tăng điểm của bạn. Bạn không có lý do gì để đổ lỗi rằng chỉ dựa vào người quản lý.
maple_shaft

6
Âm thanh như bạn có đội ngũ bán hàng là quản lý phần mềm quá, tôi thông cảm.
wildpeaks

Câu trả lời:


30

Phiên bản ngắn :

Chạy.


Phiên bản dài hơn một chút :

Nếu người quản lý không biết cách điều hành một dự án và nếu cấp cao đi cùng với nó, thì bạn sẽ không có cơ hội sửa chữa mọi thứ.

Để quản lý các dự án phần mềm, người quản lý cần phải hiểu điều gì đó về phần mềm. Nếu người quản lý không, họ cần học trước. Cơ hội nào bạn có thể thuyết phục được quản lý của mình và (các) cấp cao của bạn rằng họ đã hiểu sai? Cơ hội bạn sẽ dạy họ điều gì?

Tôi đã từng ở trong một tình huống tương tự (chỉ không có tiền bối). Tôi bỏ cuộc sau một năm khủng khiếp, và không bao giờ nhìn lại (trừ sự ghê tởm).


3
+1 cho trích dẫn này: "Nếu người quản lý không biết cách chạy chương trình và nếu cấp cao đi cùng với nó, thì bạn sẽ không có cơ hội sửa chữa mọi thứ."
maple_shaft

17

... tiếp tục thay đổi các đặc điểm kỹ thuật yêu cầu. Những thay đổi, nếu kỹ thuật tốt được thực hiện và không phải là "sửa lỗi", yêu cầu thay đổi trong thiết kế cơ bản.

Âm thanh như thế giới thực. Điều này xảy ra mọi lúc, mọi nơi. Vâng, nó rất tệ, nhưng nó có thể chịu được với một thái độ nhanh nhẹn nào đó. Bên cạnh đó, một thước đo về tính tốt của phần mềm là tính linh hoạt của nó. Hãy coi đó là một thử thách.

Rất nhiều biệt ngữ được sử dụng có ý nghĩa về mặt ngữ pháp nhưng không có ý nghĩa theo bất kỳ cách nào khác.

Một lần nữa, nghe có vẻ không quen thuộc lắm ;-)

Không có ai hiểu được sự phức tạp của những gì tôi được yêu cầu thực hiện.

Thậm chí không phải bạn? Nếu bạn hiểu điều đó, thì có một người trong gương là người hiểu điều đó. Vì vậy, trách nhiệm của bạn đối với sức khỏe của công ty bạn có lẽ nặng hơn so với tiêu đề chính thức của bạn cho thấy. Nếu bạn hiểu vấn đề và người quản lý của bạn thì không, bạn có trách nhiệm làm cho mọi thứ rõ ràng với ban quản lý để họ có thể điều hành công ty đúng cách. Có thể hợp lý khi cho rằng những người quản lý gần nhất của bạn phải có năng lực về mặt kỹ thuật (không nhất thiết phải có năng lực như bạn - trong khi họ là quản lý, bạn là chuyên gia - nhưng ít nhất là có năng lực một chút), nhưng nếu họ rõ ràng không và bạn có thể giúp họ, tại sao bạn không?

Một giải pháp thoát hiểm đơn giản là chuyển đổi công ty. Nhưng như một lựa chọn khác, hãy xem xét triển khai các mục của Joel test. Mặc dù các mục từ 5 trở lên yêu cầu hợp tác nhiều hơn với ban quản lý, các mục 1-4 là như vậy bạn chỉ có thể thiết lập chúng mà không cần hỏi ai.

Điều đó nói rằng, không ai ở đây tại SE có thể biết chính xác tình hình của bạn. Có thể bạn đang ở trong một công ty đông đúc bởi những kẻ bất tài, và làm cho một cái gì đó tốt từ một mớ hỗn độn như vậy có thể là quá nhiều đối với bất cứ ai. Bạn phải tự đánh giá tình hình.


Điều gì về một người chỉ ra những sai trái của tôi? Giúp tôi cải thiện và học hỏi.
Thợ săn rừng

4
@Jungle Hunter: Tất nhiên sẽ dễ dàng hơn khi ở trong một công ty nơi mọi thứ đã được thiết lập sẵn, mọi người đều tuân theo mọi thực hành tốt nhất có thể tưởng tượng, v.v. để bạn có thể chỉ là người học việc và bắt chước người khác. Nhưng bạn cũng có thể cải thiện và học hỏi được nhiều thứ bằng cách chịu trách nhiệm và tự mình chủ động trong việc cải thiện công ty. Cải thiện và học tập cuối cùng là trong tay của chính bạn. Những người khác có thể giúp đỡ, nhưng ông chủ của bạn không phải là một trong số họ.
Joonas Pulakka

Vâng, bạn đúng. Tôi đang cố gắng cải thiện nhưng những nỗ lực của tôi tôi nghĩ đang bị phàn nàn nhiều hơn là cố gắng cải thiện. Thành thật mà nói, những nỗ lực của tôi là cả hai, nhưng hãy xem liệu tôi có thể khiến họ thấy được nửa sau - nỗ lực cải thiện.
Thợ săn rừng

@Jungle Hunter: Tôi thấy, ranh giới giữa phàn nàn và cải thiện có thể mờ nhạt . Nhưng nó không bao giờ đau đớn để nghiêng về phía xây dựng.
Joonas Pulakka

4
@Joonas: Tôi đã ở các công ty nơi tôi đã giới thiệu VCS, đánh giá mã, đã tổ chức các hội thảo về C ++ và không có gì để cải thiện chất lượng mã. Và tôi đã ở trong một công ty khá nhiều như OP mô tả. Nếu đó là một trường hợp vô vọng, bạn phải thừa nhận thất bại và tìm kiếm một công việc mà sự đấu tranh của bạn được đền đáp bằng cách cho phép bạn thành công.
sbi

16

Bạn nói trong một trong những ý kiến ​​rằng đây là công việc đầu tiên của bạn. Các nhà quản lý thường không có kỹ thuật ở bất cứ đâu ngoại trừ một cửa hàng phần mềm chuyên dụng theo kinh nghiệm của tôi. Đây là một phần của cuộc sống, chỉ cần làm quen với điều đó.

Bạn khóc và than vãn vì không có ai đánh giá cao sự thanh lịch trong các giải pháp của bạn. Vấn đề thực sự ở đây không phải là không có ai đánh giá cao sự thanh lịch của các giải pháp của bạn, mà là không có ai dạy bạn rằng các giải pháp của bạn không tốt như bạn nghĩ. Hầu như tất cả các lập trình viên mới đều đánh giá quá cao các kỹ năng thực tế của họ. Không có người cố vấn, không có ai giúp bạn thực hành tốt hơn. Nếu không có ai ở đó để tư vấn cho bạn, thì hãy tham gia các nhóm người dùng địa phương, tích cực tham gia và nhờ ai đó ở đó tư vấn cho bạn. Thậm chí tốt hơn, điều đó sẽ giúp bạn tìm được một công việc tốt hơn cuối cùng.

Bạn đạt điểm 0 trong bài kiểm tra Joel? Nếu bạn là lập trình viên duy nhất (và nó phát ra từ những gì bạn đã viết) thì tại sao bạn không sử dụng kiểm soát nguồn? Điều gì đang ngăn cản bạn? Nếu bạn không phải là lập trình viên duy nhất, tại sao không có ai có thể thực hiện đánh giá mã? Tất cả các nhà phát triển của chúng tôi đều xem xét mã, đó không phải là chức năng quản lý, đặc biệt khi người quản lý không có kỹ thuật.

Yêu cầu thay đổi ở khá nhiều nơi. Nhu cầu kinh doanh thay đổi liên tục và những người không phải là lập trình viên thường không thể hình dung được chương trình sẽ làm gì cho đến khi họ thấy điều gì đó. Sau đó, họ nhận ra đó không phải là thứ họ cần. Đó là lý do tại sao Agile ra đời thực sự bởi vì các phương thức cũ không xử lý tốt sự thay đổi đó.

Thiết lập theo dõi lỗi ngay cả khi quản lý không muốn tự nhập dữ liệu. Chịu trách nhiệm nhập lỗi / tính năng mới khi có ai đó đề cập đến chúng cho bạn. Nó thực sự giúp tôi có thể nói với người quản lý khi anh ấy muốn thay đổi rằng bạn đã được chỉ định 27 điều khác và đây là danh sách, bạn muốn tôi chuyển xuống danh sách ưu tiên để thay thế cho thay đổi mới này. Nó sẽ giúp ích trong thời gian xem xét vì bạn sẽ có thể đếm số lần sửa lỗi và các tính năng bạn đã triển khai. Nếu mọi người không sử dụng nó, thì ít nhất bạn có thể cho công việc của riêng bạn. Nếu họ không cho phép bạn cài đặt bất kỳ phần mềm nào thì hãy sử dụng bảng tính Excel. Hãy chủ động. Một khi bạn có thể hiển thị kết quả, những người khác sẽ quan tâm hơn. Nếu bạn nghĩ rằng có quá nhiều công việc cho một người, trình theo dõi lỗi sẽ giúp bạn chứng minh điều đó.

Đừng chứng minh những bản demo trông bóng bẩy! Các bản demo sẽ trông như thể chúng được viết nguệch ngoạc bằng bút trên một tờ giấy. Giao diện càng bóng bẩy thì người phi kỹ thuật càng nghĩ nó đã hoàn thành.

Mặc dù không ai biết nếu bạn không tuân theo các thực tiễn tốt nhất và mã semi_hard chẳng hạn, bạn sẽ biết và bạn sẽ mắc phải những thói quen xấu, cẩu thả. Điều đó sẽ không phục vụ bạn tốt trong công việc tiếp theo của bạn. Vì vậy, làm những điều gần với đúng cách mà bạn có thể trong hoàn cảnh. Đảm bảo viết các bài kiểm tra (chỉ coi đây là một phần của thời gian phát triển và dành thời gian để thực hiện nó trong bất kỳ ước tính nào bạn đưa ra quản lý ngay cả khi bạn không nói cụ thể đó là một phần của ước tính) và sử dụng các bài kiểm tra đó để đảm bảo những thay đổi sau này không phá vỡ một cái gì đó khác.

Bạn cần xem đây là một cơ hội vô giá để phát triển và cải thiện. Bạn có nhiều tự do hơn trong mã hóa thực tế hơn nhiều người có ở giai đoạn đó của sự nghiệp. Vì vậy, coi đây là một cơ hội để tạo ra một danh mục các dự án được thực hiện thành công. Khi bạn đi tìm công việc tiếp theo, việc có thể chỉ ra những thành tựu như kiểm soát nguồn được lập ra, theo dõi lỗi, tạo ra X số lần thực hiện dự án thành công, v.v., sẽ khiến bạn nổi bật so với phần còn lại.

Bạn cũng có một cơ hội tuyệt vời ở đây để học cách quản lý kỳ vọng trở lên. Đây là Askill sẽ có ích trong phần còn lại của sự nghiệp của bạn. Bạn không có gì để mất khi cố gắng làm điều này ở đây, mọi thứ đã không tốt. Nhưng bạn có thể học các kỹ năng chính trị sẽ giúp bạn ở những nơi tốt hơn sau này. Tìm hiểu để làm một phân tích lợi ích chi phí. Tìm hiểu cách nhấn mạnh lĩnh vực kinh doanh để bạn có thể bị thuyết phục khi bạn nói chuyện với họ. Học cách nói chuyện về các trang phục cho công ty và lợi nhuận. Thực hiện ước tính cho mọi nhiệm vụ bạn được giao và ngay cả khi chúng không phù hợp với quản lý waht đang cung cấp cho bạn, hãy lưu hồ sơ về những gì bạn ước tính và những gì thực sự cần để cải thiện khả năng ước tính công việc của bạn. Khi bạn có thể chỉ ra rằng các ước tính của bạn trong lịch sử đã chính xác hơn so với quản lý, họ sẽ có nhiều khả năng lắng nghe khi bạn nói với họ ước tính quá thấp. Nhưng bạn phải xây dựng một hồ sơ theo dõi trước tiên về cả hai ước tính chính xác hơn và quan trọng nhất là khả năng cung cấp các dự án và làm cho chúng hoạt động. Một lần nữa đây là một kỹ năng tốt để có khi bạn tiến lên trong sự nghiệp của mình.

Trên hết, đừng thụ động và mong đợi sự cải thiện đến từ phía trên.


1
Câu trả lời này có những phần rất hữu ích. Và một số điều tôi cảm thấy không chính xác về việc hiểu tình hình của tôi. Giống như, tôi đề cập đến cả hai trường hợp, không ai đánh giá cao khi nó tốt. Không ai chỉ ra khi tôi hiểu sai. Tôi sử dụng kiểm soát nguồn, nhưng trong một nhóm 2-3 người khác thì không. Mã, khi được chia sẻ được chia sẻ bằng cách sử dụng ổ đĩa và sử dụng Airdrop. Nếu bạn đang đọc bình luận, tôi nghĩ rằng tôi cũng đã đề cập đến việc tôi đã thiết lập Redmine trên máy tính xách tay của mình và cuối cùng chỉ được tôi sử dụng. Và tương tự với git. Đã cố gắng để thực hiện những điều này cho tất cả mọi người. Trình độ của tôi, mới ra trường. Cao cấp được cho là mã nhưng không.
Thợ săn rừng

Tôi sẽ nhận lời khuyên về việc xây dựng một hồ sơ theo dõi. Tôi sẽ nhớ rằng tôi có nhiều tự do hơn ở giai đoạn của mình hơn là nói chung. Tôi có thể học cách quản lý kỳ vọng và các kỹ năng chính trị và mềm mại khác.
Thợ săn rừng

3
Ngừng cung cấp mã cho họ trên Pendrive. Nếu họ muốn mã của bạn, hãy nói với họ đó là kiểm soát nguồn và chỉ cho họ cách sử dụng mã đó.
Hugo

1
@JungleHunter Khi họ yêu cầu mã của bạn, hãy nói với họ rằng nửa chừng của bạn sẽ thay đổi, nhưng họ có thể có phiên bản ổn định cuối cùng từ kiểm soát nguồn.
Kirk Broadhurst

1
@HLGEM "Bạn khóc và rên rỉ"? Quá nhiều khắc nghiệt, hạ thấp cho một mình.
Ben H

6

Nếu tôi là bạn, tôi sẽ cố gắng tìm một công việc khác. Tại sao? Tôi nghĩ rằng bạn biết rằng, thật không may, người quản lý của bạn, "không tốt". Bạn nên cố gắng làm việc một số thứ với người quản lý của bạn mặc dù.

Nếu bạn không muốn rời đi, và / hoặc bạn sẽ không nói chuyện với bất cứ ai, thì bạn sẽ phải tự mình tìm thứ gì đó. Nếu không ai trong công ty biết về mã của bạn, làm thế nào người quản lý của bạn phải biết bạn đáp ứng các yêu cầu? Chỉ cần nói.


Anh ta chỉ nhìn vào một bản demo. Nói rằng, hãy thay đổi điều này theo cách này và cách khác. Và sau đó là một lũ thuật ngữ.
Thợ săn rừng

2
@Jungle, tôi sẽ không đặt bất kỳ tác phẩm nào vào các bản demo sau đó vì chúng nhất định sẽ thay đổi một cách điên cuồng một khi anh ấy nhìn thấy chúng. Anh ta có vẻ như một người trực quan đầu tiên và quan trọng nhất. Bạn đã thử vẽ lên ảnh chụp màn hình của các trường hợp sử dụng khác nhau cho anh ta? Điều này có thể dễ dàng hơn nhiều để kết hợp với nhau hơn các nguyên mẫu chức năng.
maple_shaft

@maple_shaft: Tôi nghĩ đó là một ý tưởng tuyệt vời.
Thợ săn rừng

1
@maple_shaft: Hoặc có thể thay vì giao hàng trước thời hạn, giao hàng chỉ về cuối. ;)
Thợ săn rừng

1
Lời khuyên về công việc từ một học sinh cấp hai ...

4

Nói chuyện với người quản lý của bạn và với người cao niên về điều này. Giải thích vấn đề của bạn và đề xuất giải pháp. Chuẩn bị bài nói chuyện một chút để bạn biết thông điệp chung mà bạn muốn truyền tải.

Sau khi nói chuyện, hãy cho nó một chút thời gian . Xem mọi thứ có thay đổi hay không. Nếu họ không, hãy cố gắng tự thực hiện các thay đổi và hiển thị cho người quản lý và người cao niên về kết quả tích cực của các thay đổi của bạn .

Nếu cuộc nói chuyện không có ích và những thay đổi của bạn bị loại bỏ, bạn phải tự đánh giá xem bạn thích làm việc ở nơi đó như thế nào. Vâng, công việc có thể là xấu, nhưng có thể tiền lương là tốt và bạn chỉ có 5 phút đi lại? Các khía cạnh tích cực của công việc của bạn vượt xa tiêu cực? Tôi không, tôi bắt đầu tìm kiếm một công việc mới.


1
Tôi đã nói chuyện. Tôi đề nghị thiết lập một hệ thống bán vé, kiểm soát phiên bản giới thiệu nhưng anh ta không quan tâm. Hoặc hiểu. Hoặc cả hai. Tôi đã hỏi nói chuyện với anh ta về việc có một thông số đáng tin cậy và anh ta đồng ý. Thay đổi nó dù sao. Anh ấy không điều khiển dữ liệu. (Ồ và loại bỏ sự nhấn mạnh vào văn bản khỏi câu hỏi của tôi.)
Jungle Hunter

2
@Jungle: Sau đó chạy càng sớm càng tốt.
sbi

1
Tôi đồng ý với sbi, nếu bạn chưa yêu cầu bị bắn hạ, bạn có thể tự mình đi ra ngoài và tự mình làm điều này. Bạn đã mất phòng và nếu tôi ở trong hoàn cảnh của bạn, tôi sẽ bắt đầu tìm kiếm.
maple_shaft

3

Vấn đề của bạn là hệ thống bán vé và kiểm soát phiên bản là vấn đề KỸ THUẬT và bạn nên thực hiện việc này bất kể đầu vào của người quản lý phi kỹ thuật. Điều này nên được coi là một cách thực hành tốt nhất về mặt kỹ thuật và nếu họ không thiết lập điều này thì bạn nên tự mình thực hiện nó để thực hiện điều này.

Bạn không thể mong đợi một người quản lý phi kỹ thuật hiểu được lợi ích của việc theo dõi lỗi, kiểm soát nguồn và tích hợp liên tục. Đây là lý do tại sao họ không có kỹ thuật, họ không cần phải biết hoặc quan tâm đến điều đó, họ là chuyên gia về kiến ​​thức kinh doanh và tên miền. Điều duy nhất họ nên cung cấp là định hướng và yêu cầu cấp cao.

Tôi cũng có một người quản lý phi kỹ thuật và có thể tăng điểm Joel Test từ 4 lên 8 chỉ vì tôi đã đi và làm chúng và không xin phép.

Nhóm của bạn cần một người lãnh đạo kỹ thuật mạnh mẽ và không ai bước lên đĩa.

Hãy xem http://community.parentdev.com/ họ có phiên bản cộng đồng thực hiện công việc tuyệt vời về quản lý dự án Agile và theo dõi Khiếm khuyết. Điều đó một mình sẽ làm tăng điểm Joel của bạn và bạn sẽ không tốn không gian máy chủ hoặc thời gian để thiết lập.


Vâng! Đó là tôi nghĩ vấn đề chính. Chúng tôi không có một nhà lãnh đạo kỹ thuật mạnh mẽ.
Thợ săn rừng

2

Nếu đây là một cửa hàng nhỏ, nơi bạn và người kia "cao cấp" về cơ bản những người duy nhất mã hóa, sau đó nó thực sự có thể của bạn chịu trách nhiệm để chỉ ra cho người quản lý những gì cần phải được thực hiện để đáp ứng các "Joel Test".

Những thay đổi trong yêu cầu sẽ luôn ở đó và công việc của bạn là nắm lấy chúng, đó là một trong những nguyên tắcbản của sự phát triển nhanh :

Chào mừng các yêu cầu thay đổi, thậm chí muộn trong phát triển. Agile quy trình khai thác thay đổi cho lợi thế cạnh tranh của khách hàng.

Nhưng thích ứng với các yêu cầu thay đổi có nghĩa là cũng tuân theo các nguyên tắc nhanh nhẹn khác. Ở cấp độ quản lý, điều này có nghĩa là người quản lý phải có thể trình bày một cách minh bạch cho khách hàng rằng tất cả các thay đổi đó đều đi kèm với chi phí: hoặc phạm vi của dự án phải được thay đổi để đáp ứng thời hạn, hoặc thời hạn phải được thay đổi (không được khuyến nghị).

Nếu đây là một loại dự án mà người quản lý của bạn là người đưa ra tất cả các yêu cầu, thì bạn nên hành động như anh ấy / cô ấy là khách hàng nhanh nhẹn của bạn và giải thích điều tương tự với họ (phạm vi <-> thỏa hiệp thời hạn ).

Nhưng ở cấp độ của nhà phát triển trong một công ty nhỏ, tôi sẽ nói rằng trách nhiệm của bạn là đảm bảo rằng phần mã hóa phù hợp với các khuyến nghị nhanh.

Đây là một số bước bạn thực sự cần phải làm và có lẽ bạn sẽ cần phải tự làm chúng:

  • bạn phải có một hệ thống kiểm soát phiên bản (mất một ngày để thiết lập nó cho một nhóm nhỏ)
  • bạn phải có các tập lệnh xây dựng để đảm bảo rằng bạn có thể tạo các bản phát hành thường xuyên (cũng khá nhanh để thiết lập)
  • bạn phải sử dụng các thử nghiệm đơn vị tự động (đây là một cách mã hóa và nó quyết định toàn bộ thiết kế của bạn một cách triệt để, do đó có thể khó thêm chúng vào giữa một dự án được liên kết chặt chẽ)
  • bạn cũng có thể thiết lập một hệ thống tích hợp liên tục để đảm bảo các bản dựng và kiểm tra tự động, cũng như các bài kiểm tra chức năng và GUI (khó viết hơn một chút)

Hãy nhớ rằng bạn có thể có một kho lưu trữ SVN cục bộ trên máy của riêng bạn. Một danh sách TODO đơn giản có thể đóng vai trò là hệ thống theo dõi lỗi của người nghèo (hơi cực, nhưng hey). Và không có lý do gì để không có các tập lệnh xây dựng.

Ngoài ra, trước khi đưa ra bất kỳ tuyên bố nào về thỏa hiệp phạm vi / thời hạn, ai đó cũng cần đưa ra dự đoán về việc một tính năng nhất định sẽ mất bao nhiêu thời gian. Điều này thường được thực hiện trong "ngày lý tưởng" trong thế giới nhanh, có nghĩa là bạn nên cố gắng hết sức để dự đoán nỗ lực tương đối của từng tính năng, sau đó sử dụng tốc độ mã hóa thực tế của bạn để xem bạn dự đoán tốt như thế nào (và chia tỷ lệ "đường cong" phù hợp ).


Đối với "lợi thế cạnh tranh của khách hàng" là chìa khóa. Sau hôm nay tôi hỏi anh ta về lý do tại sao anh ta làm điều này, nói, để gây ấn tượng với khách hàng. : |
Thợ săn rừng

Tôi có git / đồng bóng tại chỗ cho chính mình. Nhưng tôi làm thử nghiệm bằng tay ngay bây giờ. Tôi nên xem xét các bài kiểm tra đơn vị tự động.
Thợ săn rừng

1

Tôi nghĩ rằng thiếu các lớp trách nhiệm trong nhóm của bạn. Cần có một người quản lý dự án, nhà phân tích hệ thống, nhà phân tích kinh doanh và nhà phát triển. Vai trò Quản lý dự án chịu trách nhiệm xác định và thực thi chiến lược truyền thông dự án của khách hàng (trong số các nhiệm vụ khác).

Người quản lý không bắt buộc phải hiểu mã hoặc sự phức tạp. Sự cần thiết phải hiểu, tài nguyên, chi phí và rủi ro.

Các phiên bản mã nguồn, chất lượng mã, độ phức tạp, v.v ... là trách nhiệm của PM hoặc của Nhà phát triển cao cấp.

Giải pháp là:

1-Xác định cấu trúc nhóm dự án và trách nhiệm của họ

2-Giáo dục người quản lý trong các trường hợp lỗi phần mềm gây ra cho quản lý tồi - Tránh xa các chi tiết kỹ thuật. Bạn có thể tìm thấy một số ví dụ bằng cách googling.


"Tránh xa các chi tiết kỹ thuật." Tôi sẽ cố gắng chống cự. ;) Cảm ơn đã chỉ ra rằng.
Thợ săn rừng

0

Đặc biệt là không có ai chỉ ra những cải tiến trong mã của tôi.

Bạn không thể thử thiết lập đánh giá mã để có người nhìn vào mã? Có quy ước và tiêu chuẩn nào có thể giúp cung cấp cho mã một số cấu trúc không? Điều này được cho là bạn không phải là nhà phát triển duy nhất ở đó.

Trong khi bạn có khả năng ở một nơi ít hơn tuyệt vời, cuối cùng có vẻ như nó đang hoạt động? Các dự án đang được thực hiện và mọi thứ đang tiến lên? Có phải mọi thứ đang được thực hiện? Lập trình viên băng keo sẽ là bài viết Joel mà bạn có thể muốn đọc.


Tôi đã nghĩ đến việc nhóm của tôi đổi thành một nhóm có những người có thể xem mã của tôi. Hoặc cố gắng liên lạc với những người ở đó để xem lại mã của tôi. Như tôi đã nói trong các câu hỏi, ngay bây giờ không có ai có thể làm điều đó.
Thợ săn rừng

0

Tùy chọn 1 - nói với họ 'với tất cả những thay đổi bạn đang thực hiện cho dự án này, vào thời điểm chúng tôi triển khai nó, hệ thống sẽ chạy rất chậm' hoặc 'khách hàng sẽ không thể tìm ra nó'. Người quản lý của bạn không quan tâm đến mã spaghetti nhưng họ quan tâm đến khách hàng. Đặt vấn đề cho họ về những gì họ hiểu, không phải về mặt viết mã.

Tùy chọn 2 - cung cấp cho họ những gì họ muốn. Khi họ phàn nàn về điều bạn nói 'nhưng đó là những gì bạn yêu cầu'


Trước khi tôi "chạy" tôi sẽ làm chính xác điều đó. Nếu họ muốn thay đổi, tôi sẽ cho họ biết rằng đó không phải là một thay đổi nhỏ ở đây và ở đó nên sẽ mất nhiều thời gian hơn. Khi khách hàng không vui vẻ gì, họ sẽ không có gì để phàn nàn vì tôi đã cho họ những gì họ muốn.
Jungle Hunter

@jungle hunter - Không phải ai cũng có lựa chọn bỏ việc, đôi khi bạn phải vượt lên hoàn cảnh. Tôi đã tìm ra cách tốt nhất để xử lý sự điên rồ là quay lưng lại với những kẻ điên. Chỉ có những kẻ rất điên mới có thể tranh luận chống lại sự điên rồ của chính họ. chúc may mắn.
jqa
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.