Một nhà phát triển (cơ sở) có nên cố gắng thúc đẩy các quy trình và thực tiễn tốt hơn trong nhóm phát triển / CNTT của họ không?

Tôi là một nhà phát triển cơ sở được cung cấp khả năng giúp định hình các quy trình của nhóm tôi nếu tôi có thể biện minh cho sự thay đổi và nếu điều đó giúp nhóm hoàn thành công việc. Điều này là mới đối với tôi vì các công ty trước đây của tôi ít nhiều có các quy trình được xác định cứng nhắc xuất phát từ quản lý.

Nhóm của tôi khá nhỏ và hơi mới (<3 tuổi). Họ thiếu:

• một khung phát triển phần mềm / quản lý công việc được xác định rõ (như scrum)
• quyền sở hữu sản phẩm mạnh mẽ
• vai trò được xác định rõ (ví dụ: nhân viên kinh doanh sẽ làm kiểm tra thủ công)
• cuộc họp thường xuyên
• một quy trình theo dõi vấn đề hợp nhất (chúng tôi có một công cụ, quy trình vẫn đang được phát triển)
• một đơn vị, hệ thống, hồi quy hoặc bộ kiểm tra thủ công hoặc danh sách
• tài liệu về logic và quy trình kinh doanh
• một cơ sở kiến ​​thức để ghi lại các mẹo đối mặt với nội bộ và khách hàng

Và danh sách được tiếp tục. Quản lý mở cửa cho việc thực hiện các cải tiến miễn là giá trị được chứng minh và nó giúp công việc quan trọng nhất (cụ thể là phát triển) được thực hiện. Tuy nhiên, giả định cơ bản là bạn phải có quyền sở hữu trong quá trình thực hiện, vì không ai sẽ làm điều đó cho bạn. Và không cần phải nói một số dự án trên là không tầm thường, không có nghi ngờ tốn thời gian, và rõ ràng không phải là công việc phát triển.

Có đáng để một nhà phát triển (đàn em) nỗ lực cố gắng và thúc đẩy những điều trên khi thời gian trôi qua không? Hoặc là tốt nhất để "ở trong làn của bạn" và tập trung vào sự phát triển, và để lại phần lớn định nghĩa quy trình và tối ưu hóa cho quản lý?

Câu trả lời tốt cho đến nay, nhưng chúng không bao gồm tất cả các cơ sở.

Theo kinh nghiệm của tôi, nhiều người mới ra trường có kiến ​​thức lý thuyết tuyệt vời - tốt hơn nhiều so với tôi hoặc nhiều người cao niên khác với hàng thập kỷ xây dựng phần mềm để kiếm sống.

NHƯNG, và đó là một NHƯNG lớn, kiến ​​thức đó không có cơ sở trong bất kỳ kịch bản thực tế nào. Trong thế giới thực, rất nhiều lý thuyết đã thất bại, hoặc ít nhất là phải được thực hiện với một hạt muối khổng lồ như trong thực tế để nó không hoạt động tốt trong kịch bản thế giới thực.

Tình huống cụ thể: Một ứng dụng tôi đã làm việc từ lâu được thiết kế bởi một nhà lý thuyết OO xuất sắc, được kiến ​​trúc để tuân theo các nguyên tắc và lý thuyết OO cho T, với rất nhiều mẫu được áp dụng ở mọi nơi.

Đó là một phần tuyệt vời của thiết kế phần mềm.

Đáng buồn thay, điều này dẫn đến cơn ác mộng sản xuất và bảo trì. Cơ sở mã rất lớn và phức tạp đến mức không thể thay đổi địa điểm; Không phải vì nó đặc biệt dễ vỡ mà vì nó quá phức tạp, không ai dám chạm vào nó vì sợ điều gì sẽ xảy ra (kiến trúc sư / nhà thiết kế ban đầu đã là một nhà thầu từ lâu đã rời đi).

Nó cũng thực hiện rất kém, chính xác là do cấu trúc nhiều lớp của các mẫu và các thư viện lớp được thiết kế theo yêu cầu. Ví dụ, nhấp vào nút trên màn hình để thực hiện một cuộc gọi đến cơ sở dữ liệu sẽ dẫn đến hàng trăm cuộc gọi đối tượng và cuộc gọi phương thức - tất cả đều có tên là đảm bảo khớp nối lỏng lẻo và những thứ tương tự.

Kiến trúc sư này đã từng là một giáo sư đại học với một vài cuốn sách về chủ đề này. Anh ấy chưa bao giờ làm việc một ngày với tư cách là một lập trình viên cho một dự án thương mại.

Những người có phần mềm xây dựng kinh nghiệm thực tế sẽ nhận ra điều quái dị mà thiết kế chắc chắn sẽ dẫn đến và thực hiện một cách tiếp cận thực tế hơn, dẫn đến một hệ thống dễ bảo trì và hoạt động tốt hơn.

Điều tương tự có thể áp dụng cho nhiều thứ khác mà bạn gặp phải khi mới tốt nghiệp, hoặc thực sự là một nhân viên mới trong bất kỳ công ty nào. Đừng cho rằng vì cơ sở lý thuyết của bạn cho bạn biết có gì đó không đúng hoặc không tối ưu nên không có lý do chính đáng nào để thực hiện theo cách đó.

Ngay cả bây giờ, với hơn 20 năm kinh nghiệm trong lĩnh vực này, tôi cảnh giác chỉ trích cách mọi thứ được thực hiện trong các công ty tôi làm việc cùng. Tôi sẽ đề cập đến rằng tôi nhận thấy mọi thứ khác với kinh nghiệm của tôi là tối ưu nhất, nhưng không phải là một cách hiếu chiến. Điều này thường dẫn đến các cuộc trò chuyện thú vị về lý do tại sao những điều đó là như vậy. Có thể thay đổi sẽ xảy ra và có thể không, tùy thuộc vào việc giá trị của việc thay đổi có nhỏ hơn chi phí hay không.

Đừng ngại đề xuất mọi thứ có thể được thực hiện tốt hơn, nhưng hãy luôn đảm bảo rằng bạn không bắt gặp như một đứa trẻ hợm hĩnh mà chỉ là một đồng nghiệp đang cố gắng và sẵn sàng không chỉ học mà còn giúp cải thiện các quy trình để cải thiện công ty, không chỉ là sự đúng đắn về mặt lý thuyết.

Có nhưng với rất nhiều sự quan tâm!

Hãy để tôi làm rõ điều đó.

Bạn nên cố gắng cải thiện khả năng cư trú của phần mềm. Nếu bạn nhìn vào mã / nhóm / doanh nghiệp / dự án / quản lý và phản ứng đầu tiên của bạn là đi tắm, thì đó là điều không thể ở được. Nếu phản hồi đầu tiên của bạn là hét lên yeah! ... Và sau đó phàn nàn khi bạn bị đuổi ra khỏi văn phòng, thì bạn cần phải làm cho ngôi nhà của bạn trở nên dễ sống hơn. Đó là một cảm giác, và bạn sẽ biết điều đó.

Điều đó đang được nói, bạn đang làm việc trong một phức tạp symathesis . Bất cứ điều gì bạn làm có khả năng đi sai, và có thể sẽ làm mọi thứ tồi tệ hơn ít nhất là trong ngắn hạn, bởi vì một thay đổi đơn giản có gợn sóng. Vì vậy, trước hết trở nên khiêm tốn, tôi không có nghĩa là trở thành người thúc đẩy hoặc chấp nhận rằng mọi thứ phải tồi tệ, ý tôi là phải đồng ý với thực tế rằng ý định tốt của bạn sẽ khiến bạn xấu xa.

Vấn đề

Với ý định tốt nhất bạn có thể cảm thấy rằng một sự thay đổi sâu rộng cần phải xảy ra và tôi không đồng ý rằng những tình huống này tồn tại, nhưng hãy dành một chút thời gian để suy nghĩ về nó. Hệ thống hiện tại đang hoạt động, bạn và nhóm của bạn đang sản xuất mã, có thể chậm, có thể đau, nhưng nó đang hoạt động và tất cả các bạn đều có kinh nghiệm về cách làm điều này. Bạn biết đại khái những gì mong đợi, trong ngắn hạn, bạn là những chuyên gia thực hành trong hệ thống này.

Sau khi thay đổi sâu rộng mặc dù không ai, ngoại trừ có lẽ người thực hiện, biết những gì mong đợi. Nói tóm lại, tất cả mọi người đã được thiết lập lại ở mức độ mới trong phần này của hệ thống. Điều đó không tốt. Neophytes phải học các quy tắc mới cần có thời gian. Trong thời gian đó, tân sinh viên đang mắc lỗi vì họ không thực hành. Những sai lầm đó trở thành một phần của hệ thống, mà bây giờ bạn phải sống cùng và không nơi nào gần như lấp lánh như bây giờ.

Một con đường phía trước

Có những lúc, chém, đốt và xây dựng lại là điều tốt nhất bạn có thể làm. Nó đặc biệt hấp dẫn nếu không có ai được thực hành trong hệ thống cũ, bởi vì điều duy nhất bị mất là kiến ​​thức được mã hóa. Nếu kiến ​​thức này hoàn toàn không thể hiểu được thì nó đã bị mất và bắt đầu lại là lựa chọn duy nhất. Ngược lại, nếu phương pháp mã hóa, hoặc cách sử dụng nó có vấn đề nhưng hoạt động, kiến ​​thức đó vẫn có thể truy cập được và có lẽ nó đáng để lưu giữ, có lẽ là không - Chỉ cần đừng xem nhẹ quyết định.

Lựa chọn khác là làm việc với hệ thống để mọi người đều có khung tham chiếu, nhưng thay đổi các phần nhỏ của hệ thống để mọi người trong nhóm nhận thức được hoặc nếu họ không biết về sự thay đổi, thì cả hai đều dễ dàng Thông báo và dễ học. Đây là cơ sở cho các thực hành được gọi là Kaizen . Một công thức định hướng dành cho nhà phát triển hơn được trình bày trong bài trình bày Cạo râu Golden Yak, tôi khuyên bạn nên xem và suy nghĩ kỹ.

Vì vậy, tìm một điều nhỏ có thể thay đổi sẽ cải thiện cuộc sống của bạn, và hy vọng những điều đó của một vài người khác. Khắc phục hoặc cải thiện tình hình. Điều này sẽ cung cấp cho bạn thực hành và kinh nghiệm về việc đưa các thay đổi vào thực tiễn. Hãy chắc chắn rằng bạn nhận được thông tin phản hồi: bạn có thể thảo luận về nó tốt hơn không, nó có thực sự hữu ích không, nó có làm đảo lộn một phần khác của hệ thống không. Phát triển cảm nhận của bạn về những gì có thể được thực hiện và làm thế nào để làm điều đó.

Bây giờ có ba điều đã xảy ra:

• bạn đã cải thiện hệ thống
• bạn đã có kinh nghiệm về cách thay đổi hệ thống
• nhóm đã thấy bạn thay đổi thành công hệ thống.

Bây giờ hãy chọn một thứ khác để cải thiện, khi kinh nghiệm của bạn tăng lên và khi bạn loại bỏ các vấn đề treo thấp, bạn sẽ bắt đầu đối mặt với các vấn đề khó khăn hơn trong hệ thống nhưng ít nhất là bây giờ khi bạn nói chúng ta phải thay đổi X:

• Bạn biết sự thay đổi sẽ ảnh hưởng đến hệ thống như thế nào
• Bạn biết những vấn đề gì nó sẽ tạo ra (những quy tắc cần phải học lại)
• Bạn biết một số cách khắc phục ngay lập tức hoặc cải thiện các sự cố mà thay đổi sẽ giới thiệu
• những người xung quanh bạn biết rằng bạn am hiểu hệ thống và có khả năng thay đổi thành công

Có bạn có thể. NHƯNG...

Bạn phải cẩn thận đấy.

Khi bắt đầu sự nghiệp của tôi (rất lâu trước đây), tôi đã may mắn / không may mắn khi tham gia vào một dự án vài tháng tuổi với tư cách là "Thiếu niên".

Như điều đầu tiên tôi nhận thấy, không có (OMG) không có kho lưu trữ mã! Tất cả các sự hợp nhất của mã được thực hiện thủ công bằng cách gửi các tệp zip cho nhau bằng thư.

Vì vậy, tôi đã đi đến người quản lý (cũng mới) của mình và đề nghị rằng chúng ta nên có một kho lưu trữ. Trả lời là: Ok, tổ chức nó ....

Vì vậy, tổ chức một kho lưu trữ mã, mà không cần trợ giúp, là công việc mới trong công ty, bây giờ đó là một kinh nghiệm khiêm tốn.

Khi tôi thiết lập tất cả, (sốc) không ai muốn sử dụng nó. Vì vậy, tôi đã cố gắng đẩy mọi thứ theo và may mắn là người quản lý của tôi hiểu tầm quan trọng của nó nên tôi đã hỗ trợ.

Nhưng điều này dẫn đến việc tôi không thích và thật không may có một biệt danh bắt nguồn từ hệ thống kiểm soát nguồn.

Vì vậy, tôi nghĩ về điều này là, trước tiên hãy cảm nhận các thành viên trong nhóm của bạn, những gì họ nghĩ là quan trọng để thiết lập tiếp theo.

Có lẽ họ cũng có một danh sách như của bạn. Có lẽ họ có tất cả mọi thứ thông qua và họ muốn làm "điều" đó trong danh sách. Có lẽ họ .... (sao cũng được) ....

Toàn đội phải được căn chỉnh.

Nhưng nếu họ không, thì bạn vẫn có thể làm việc chuyên nghiệp. Và tìm những người có đầu óc và làm việc cùng nhau như thế nào bạn nghĩ nó nên được thực hiện. Nếu điều này mang lại kết quả tốt, nhiều người sẽ làm việc với Bạn, cuối cùng nó sẽ trở thành quá trình "the".

Cũng giống như với mã, tương tự cho các quy trình phát triển: cần cải tiến liên tục.

Vì vậy, Có, bạn nên luôn luôn cố gắng cải thiện, đó là điều có thể cải thiện.

Nhưng cũng nên nhớ nhiều người Bạn đang làm việc cùng, có thể đã là chuyên gia và họ biết điều gì sai và điều gì là cần thiết.

Có đáng để một nhà phát triển (đàn em) nỗ lực cố gắng và thúc đẩy những điều trên khi thời gian trôi qua không?

Vâng, nó luôn luôn xứng đáng với nỗ lực của bạn để cố gắng và làm cho mọi thứ tốt hơn. Bạn biết rõ nhất những vấn đề bạn phải đối mặt sau tất cả.

Nhưng như bạn đã đề cập, có rất nhiều vấn đề cần giải quyết và nhiều vấn đề đó không có giá trị khủng khiếp. Và tại rất nhiều nơi, sẽ có những rào cản không thể vượt qua đối với thành công của bạn hoặc những người khác có vị trí tốt hơn rất nhiều để chiến thắng họ. Vì vậy, bạn nên luôn luôn cố gắng làm cho mọi việc tốt hơn, thậm chí nếu điều đó có nghĩa là hái mà điều bạn dành nhiều thời gian của bạn cố gắng để làm tốt hơn.

Bởi vì cuối cùng, nếu bạn không phải là một phần của giải pháp thì bạn là một phần của vấn đề.

Đúng. Nhưng thay đổi tổ chức là khó ngay cả đối với một cấp cao vì vậy nếu bạn thực sự muốn tạo sự khác biệt hãy làm điều đó theo cách đúng đắn:

• Không phải trong những tuần đầu tiên: Sử dụng thời gian này để:

  • Tạo ra một sự khởi đầu tốt. Cho thấy bạn phù hợp với đội.
  • Hiểu rõ văn hóa và chính trị hoặc công ty của bạn. Có an toàn để thúc đẩy thay đổi?
  • Xây dựng mối quan hệ tốt với đồng nghiệp
  • Tìm hiểu về quy trình, quy tắc và nhu cầu của nhóm của bạn
  • Tìm hiểu công việc của bạn và làm điều đó tốt nhất bạn có thể. Bạn chắc chắn sẽ bận rộn đủ.

• Chọn các trận đánh của bạn. Nhận một số chiến thắng sớm : Bạn có thể đến với năng lượng để thay đổi mọi thứ nhưng điều này là không thực tế. Tập trung vào một số trái cây treo thấp và cho thấy ý tưởng của bạn hoạt động. Bạn muốn họ dễ tiếp thu những cải tiến phức tạp hơn. Và hãy nhớ rằng mọi thứ dễ dàng hơn trong sách.

• Hãy xem xét hàm ý cho người khác : Tôi làm các nhà tái cấu trúc ảnh hưởng đến rất nhiều tệp. Ngay cả khi họ cải thiện mã, tôi phải rất cẩn thận để tránh biến sự hợp nhất thành một nỗi đau ở mông. Cũng cố gắng để nắm bắt những lý do tại sao họ tiếp tục làm việc như vậy. Có thể họ không thể sử dụng Scrum vì họ thiếu các bài kiểm tra và, một cách dễ hiểu, sợ phải đẩy mã chưa được kiểm tra vào sản xuất thường xuyên. Viết một bài kiểm tra khả thi không phải là một nhiệm vụ dễ dàng. Mã hiện tại có thể rất khó kiểm tra. Hơn nữa, nhóm không được sử dụng để viết các bài kiểm tra hoặc mã kiểm tra. Cơ sở mã hiện tại có thể đặc biệt khó kiểm tra và cần được cấu trúc lại. Nó có thể cần nhiều năm để thay đổi vấn đề này nhưng ít nhất bạn có thể tập trung vào nguyên nhân gốc rễ.

• Đừng phán xét. Đừng đòi hỏi. Yêu cầu và lắng nghe cẩn thận: Đây là thời điểm mà giao tiếp là quan trọng và chúng tôi, các lập trình viên, thường không giỏi lắm về các sắc thái tinh tế. Có kỹ thuật để giúp đỡ . Thật dễ dàng để tiếp tục thúc đẩy ý tưởng của chúng tôi thay vì tập trung vào câu trả lời. Trước tiên hãy chắc chắn rằng họ cảm thấy rằng bạn đã có điểm của họ. Hiểu rằng cảm xúc là quan trọng. Sự thay đổi này làm cho họ cảm thấy gì? nỗi sợ? thiếu năng lực? Sự phẫn nộ? thất vọng? mong? Lười biếng? Ngốc nghếch? (Không bao giờ làm cho mọi người cảm thấy ngu ngốc). Tất nhiên bạn sẽ hỏi rất nhiều câu hỏi trước đây và điều này sẽ ngăn chặn rất nhiều bước sai.

• Dẫn dắt bằng ví dụ : phàn nàn là dễ dàng, tạo ra sự thay đổi là khó khăn. Hiển thị kết quả và mọi người sẽ tin bạn. Nếu họ không sử dụng kiểm tra, bạn có thể viết bài kiểm tra đơn vị của bạn. Nếu mọi người không làm tài liệu, bạn có thể chia sẻ một số tài liệu google với nhóm. Hiểu rằng "Ok, làm điều đó" là một trong những tình huống tốt nhất có thể và sau đó bạn cần cung cấp. Trong trường hợp này, bạn cần phải nghĩ những tài nguyên bạn sẽ cần . Ví dụ: cho tôi một ví dụ Amazon nhỏ và hai giờ từ quản trị viên cho máy chủ Jenkins

• Giữ cho nó nhỏ và đơn giản (và giá rẻ): Bạn không muốn chờ phê duyệt ngân sách chính thức hoặc ông chủ của bạn nghĩ rằng bạn đang mất thời gian quý báu từ các lập trình viên đắt tiền. Sẽ thật tuyệt khi có mã này xem xét phần mềm hoặc đánh giá một số công cụ nguồn mở nhưng chúng tôi sẽ chỉ sử dụng repo vào lúc này.

• Nhận khối lượng quan trọng: Tập hợp nhóm người tập trung vào nâng cao chất lượng. Bạn thậm chí có thể đi với họ đến các hội nghị và yêu cầu giúp đỡ hoặc cố vấn. Peopleware mô tả "đánh thức hiện tượng khổng lồ" bằng cơ sở của đội theo nghĩa đen là nổi dậy chống lại một số thực hành ngu ngốc làm chậm năng suất. Điều này cá nhân sẽ rất nguy hiểm và tôi sẽ không đề nghị. Nhưng nếu tất cả các nhóm đồng ý thay đổi sẽ dễ dàng hơn.

• Cho nó một chút thời gian. Sau đó bỏ phiếu với feets của bạn: Bạn có thể muốn thử nó trong một vài tháng cho đến hai năm. Nhưng một số công ty không có giải pháp dễ dàng. Một số đội không muốn thay đổi và không có ưu đãi. Và một số cơ sở mã là kinh dị thuần túy. Nếu bạn cảm thấy rằng đó là bạn chống lại thế giới hãy nhớ rằng có rất nhiều lời mời trong nhóm công việc. Bạn muốn học hỏi những thực hành tốt và về lâu dài, bạn sẽ trở nên tốt hơn trong một tổ chức hòa bình với mức lương ít hơn nhưng việc có được kinh nghiệm sẽ giúp bạn có giá trị hơn.

Tiền thưởng: Nếu bạn thành công hãy viết nó ra cho CV / Phỏng vấn của bạn. Là một Junior bạn thường có rất ít điều để nói và tạo ra một sự thay đổi để tốt hơn luôn là một dấu hiệu tuyệt vời. Bạn muốn có một cái nhìn rất rõ ràng và thực tế về những gì cá nhân bạn đã làm và những gì là công việc từ người khác. Hãy tưởng tượng câu hỏi phỏng vấn sau đây.

• Nói cho tôi biết về một thời gian mà bạn đã tạo ra sự khác biệt trong đội.
• Chà, tôi đã ở một nơi là họ có những tập tục rất cũ. Rất nhiều người không hài lòng với nó và năng suất có một căn phòng lớn để cải thiện. Vì vậy, tôi đã đề xuất thực hiện một thử nghiệm nhanh với các hồi cứu, chúng tôi đã thực hiện X và Y và kết quả là chúng tôi đã có kết quả có thể đo lường tuyệt vời này ".

Đúng. Nhưng không phải những điều bạn đề nghị.

Trong danh sách của bạn Các bài kiểm tra Đơn vị / Tích hợp là mục duy nhất bạn có thể tiến bộ.

Bạn có thể bắt đầu thêm những thứ này một mình với đầu tư thời gian tối thiểu và hiển thị giá trị ngay lập tức. Đây là một vấn đề kỹ thuật với các lợi ích được chấp nhận rộng rãi và sẽ không ảnh hưởng đến các hoạt động làm việc khác. Trong khi cũng đạt được cho bạn kiến ​​thức về cơ sở mã ngay cả khi kết quả không được chấp nhận. Một bán dễ dàng.

Những người khác nói chung là các quy trình kinh doanh liên quan đến toàn bộ nhóm hoặc thậm chí các nhóm khác. Bạn có thể đề xuất cải tiến, nhưng họ sẽ khó thay đổi nhân viên cấp dưới và quá trình thay đổi chúng thường không mang tính công nghệ và có thể không liên quan đến công việc bình thường của bạn.

Tôi cũng sẽ đề xuất những thứ như, thiết lập đường ống CI, triển khai tự động, tạo phiên bản, thư viện đóng gói là công cụ tốt để tấn công

Nó phụ thuộc vào:

• bạn mong đợi nhận được bao nhiêu từ thực tiễn tốt hơn
• bạn sẽ phải bỏ ra bao nhiêu công sức để đến đó
• cơ hội thành công và rủi ro là gì - từ thất bại áp dụng đơn giản đến thực tiễn mới thực sự khủng khiếp, suy giảm chất lượng mã, những người chủ chốt rời đi, mọi người ghét bạn và bạn phải tìm một công việc khác ở một thành phố khác, nơi không ai biết tên bạn

Về cơ bản: bạn nên dành thời gian hợp lý để ủng hộ những gì bạn cho là tốt nhất - nhưng quyết định nên là một nhóm hoặc trách nhiệm quản lý. Hãy nhớ rằng xa lánh mọi người hiếm khi có giá trị, ngay cả khi bạn kết thúc với các thực hành tốt hơn.

Đừng bắt đầu với những thứ phức tạp nhất như Scrum. Bắt đầu với các bước dễ nhất có thể.

Bạn đã không đề cập đến quản lý mã nguồn. Bạn có kho lưu trữ mã nguồn nào không (git, svn, cvs, ...)? Một chiến lược để gắn thẻ và phân nhánh? Đó là những bước đơn giản mà một người mới bắt đầu có thể làm. Đọc những vấn đề mà các bước này (cố gắng) giải quyết và cách điều đó giúp công ty của bạn giảm chi phí (đó là điều mà ban quản lý quan tâm).

Bước tiếp theo có thể là các bản dựng tự động, hàng đêm hoặc trực tiếp sau mỗi lần đăng ký, ví dụ như với Jenkins. Bạn cũng có thể chạy thử nghiệm tự động. Và thêm một số công cụ để đo lường chất lượng mã (ồ đúng: xác định một số tiêu chuẩn mã hóa cũng là một bước tốt).

Đối với scrum, đọc tốt hơn về "Lập trình cực đoan" (XP). Scrum dựa trên nhiều ý tưởng của XP và thêm một quy trình chính thức xung quanh chúng - các khái niệm về XP vẫn có thể được sử dụng mà không cần quá trình đó.

Gợi ý mọi thứ, cung cấp thông tin cơ bản, cố gắng thuyết phục người khác dùng thử, phân tích kết quả, ... nhưng đừng mong đợi sự hợp tác nhiều từ người khác: hầu hết mọi người thích gắn bó với thói quen xấu cũ của họ. Nhưng khi bạn không thử điều đó, sẽ không có gì cải thiện.

Bạn nói rằng nhóm khá mới (3 tuổi), vì vậy nếu bây giờ bạn không thể đưa ra một số nguyên tắc tốt, thì sẽ khó hơn 10 năm sau đó. Một số điều bạn đã đề cập như hệ thống thử nghiệm và phiên bản là một trong những điều bạn có thể đề xuất, nhưng đừng ném đề xuất như thế mà không nhấn mạnh vào lợi ích rõ ràng của chúng và chọn công cụ mà ngăn xếp phát triển của bạn yêu cầu.

Ban đầu, đặt câu hỏi

Đọc danh sách của bạn, tôi sẽ đề xuất các câu hỏi sau (tham khảo lại danh sách của bạn để xem chúng phù hợp như thế nào):

• Làm thế nào để tôi thấy những gì công việc mà các chủ doanh nghiệp đang yêu cầu?
• Bạn đã thử [Scrum] chưa?
• Ai là chủ sở hữu sản phẩm cho việc này?
• Có những vai trò gì?
• [Vai trò này] làm gì?
• Vai trò nào chịu trách nhiệm cho [hoạt động này]?
• Bạn đã thử một standup hàng ngày?
• Làm thế nào để tôi truyền đạt những trở ngại của tôi với phần còn lại của đội?
• Làm thế nào để tôi tìm ra những gì các thành viên khác trong nhóm đang làm việc?
• Chúng ta có nên đặt [cái này] trong công cụ theo dõi vấn đề không?
• Làm thế nào chúng ta nên viết [này] trong công cụ theo dõi vấn đề?
• Khi [điều này] xảy ra, chúng ta có nên đặt nó trong công cụ theo dõi vấn đề là [điều đó] không?
• Làm thế nào để chúng tôi kiểm tra?
• Làm thế nào để chúng tôi ghi lại các bài kiểm tra của chúng tôi để người khác sử dụng lại?
• Bạn đã thử [JUnit] chưa?
• Tài liệu này được ghi ở đâu?
• Bạn đã thử [MediaWiki] chưa?

Thay thế mọi thứ trong [ngoặc] khi thích hợp để làm cho các câu hỏi có ý nghĩa hoặc phù hợp với các ưu tiên của bạn. Xem xét viết lại nếu từ ngữ của tôi không phù hợp với phong cách của bạn.

Bạn có thể đã bắt đầu làm điều đó. Yêu thích các cuộc trò chuyện một đối một trên các cuộc hội thoại nhóm. Bởi vì từng người một, bạn có thể hiểu rõ hơn về những gì người kia nghĩ. Có phải người đó cho sự thay đổi này? Chống lại nó? Yếu? Bệnh dại?

Khi bạn mới, việc đặt câu hỏi thực tế là miễn phí. Mọi người nên mong đợi bạn đặt câu hỏi. Ngay cả khi câu hỏi của bạn ngầm ủng hộ một vị trí mà họ phản đối, họ cũng không nên tức giận. Họ nên giải thích tại sao họ phản đối vị trí đó. Tôi khuyên bạn không nên tranh cãi với họ. Tranh luận có xu hướng làm cứng các vị trí nhiều hơn nó thuyết phục. Lưu ý ai có vị trí và di chuyển trên.

Sau đó, thực hiện các bước

Tìm kiếm những cách mà bạn và có thể những người khác (tức là những người bạn đã lưu ý đồng ý với bạn trước đây) có thể bắt đầu những thay đổi bạn muốn. Không phải ai cũng muốn có một standup? Tại sao không? Có lẽ những người bạn muốn một người có thể có standup của riêng bạn. Không hiệu quả như với toàn đội, nhưng nhiều hơn bạn có bây giờ.

Khi bạn gặp trở ngại (và giả sử bạn không thể chia sẻ trong tình huống chờ), hãy gửi email cho nhóm để được giúp đỡ.

Xác định vai trò nên là gì, có thể với sự hỗ trợ của những người khác đồng ý với bạn. Bắt đầu liên tục đến với mọi người khi công việc liên quan đến vai trò mà bạn (có thể là một nhóm bạn) nghĩ rằng họ nên có. Nếu họ đẩy lùi, yêu cầu họ xác định ai nên sở hữu vai trò đó.

Yêu cầu chủ sở hữu sản phẩm (mà bạn đã xác định) viết lên các mô tả về cách họ nghĩ rằng sản phẩm của họ sẽ hoạt động ngay bây giờ và trong tương lai.

Cài đặt một khung kiểm tra (nếu những người khác ủng hộ điều này, đưa ra quyết định chung về khung nào) và sử dụng nó cho các dự án của bạn. Khi bạn đang sửa lỗi, hãy viết bài kiểm tra. Tài liệu này trong báo cáo lỗi về trình theo dõi sự cố (đã viết kiểm tra lỗi chứng minh, được lưu trữ tại [vị trí]). Khuyến khích người khác chạy thử nghiệm khi họ thực hiện thay đổi. Nếu họ không, hãy tự chạy các bài kiểm tra và gửi các vấn đề cho người theo dõi khi cần thiết.

Nếu bạn có thể nhận được hỗ trợ quản lý, hãy cài đặt phần mềm wiki hoặc tương tự và bắt đầu ghi lại tài liệu của bạn. Nếu mọi người hỏi bạn những câu hỏi cho thấy họ không đọc tài liệu, hãy chỉ chúng vào các trang có liên quan. Khuyến khích họ đặt thêm câu hỏi nếu họ không hiểu tài liệu. Nếu họ tiếp tục đặt câu hỏi trong tài liệu, hãy trích dẫn từ tài liệu khi trả lời. Cân nhắc khuyến khích họ cập nhật wiki nếu bạn nghĩ rằng vấn đề là do cấu trúc chứ không phải họ không đọc.

Tôi sẽ đề nghị chỉ tập trung vào một nhiệm vụ tại một thời điểm. Và chắc chắn chỉ đẩy một lúc. Đừng đẩy mạnh. Xem ví dụ này về việc đẩy mạnh hơn nhóm muốn. Tập trung nhiều hơn vào việc thay đổi hành vi của bạn hơn họ. Nếu cách của bạn là đúng cách, điều đó là hiển nhiên đối với những người quan sát bạn. Hành động mạnh hơn lời nói. Cố gắng không lặp lại chính mình với cùng một người khi bạn làm nũng. Một khi bạn đã dẫn con ngựa xuống nước, hãy để lựa chọn khi nào hoặc có nên uống cho người khác.

Cuối cùng, bạn sẽ là người cao cấp

Theo thời gian, nhóm của bạn sẽ thuê người mới. Bạn sẽ ngừng là người thuê mới và có thể ủng hộ vị trí của bạn với những người mới. Làm việc với họ để thực hiện thay đổi. Và bạn có thể thấy rằng bạn cũng đang tiến bộ với các đồng đội hiện tại của bạn. Hoặc nếu điều đó không hiệu quả, hãy tìm một công việc mới nơi họ có các hoạt động tốt hơn. Không có vội vàng thực sự. Bạn có một công việc. Bạn có thể chờ đợi một thời gian để có một công việc tốt hơn, bằng cách cải thiện công việc đó hoặc tìm một công việc tốt hơn.

Câu trả lời ngắn : Không, vì tất cả các lý do được nêu trong các câu trả lời khác. Ngay cả khi là một nhà phát triển trung cấp hoặc cao cấp, tốt hơn hết là tìm kiếm trước tiên để hiểu khi gia nhập một nhóm mới.

Một giải pháp được đề xuất :

1) bất cứ khi nào bạn thấy một cái gì đó bạn cảm thấy cần được cải thiện, hãy lưu ý về nó! (trong một cuốn sổ tay, trong một ghi chú kỹ thuật số ...)

2) Sau 6 tháng, quay lại ghi chú của bạn và kiểm tra chúng. Có bao nhiêu ý tưởng bây giờ cảm thấy vô nghĩa và không đầy đủ? Rất có thể là rất nhiều, bạn đã tiết kiệm cho mình một số bối rối. Nếu một số ý tưởng vẫn còn, bây giờ sẽ là thời điểm tốt để giới thiệu chúng, nếu có thể bằng cách tự kiểm tra chúng trước.

Trả lời muộn, và đồng ý rất nhiều nội dung tốt trong các câu trả lời khác.

Tôi nghĩ rằng cần phải gọi ra rằng một vấn đề quan trọng ở đây không phải là các thực tiễn cụ thể, mà là văn hóa nhóm tổng thể.

• Tạo ra sự thay đổi văn hóa là khó khăn .
• Hơn nữa nếu bạn xem là "đàn em"

Mọi thứ khác có thể làm theo nếu có một phương tiện để đạt được sự cải tiến liên tục .

Cách tiếp cận của tôi để đạt được điều đó là:

• Tài liệu quy trình và thủ tục
• Hồi tưởng với nhóm có hành động thay đổi tài liệu quy trình.

Tôi đoán nếu bạn không chạy nước rút, bạn chưa có bản retros thường xuyên. Tất cả những gì bạn cần là một cuộc trò chuyện với nhóm, và sau đó hành động.

Bạn có thể dễ dàng bắt đầu các quy trình tài liệu. "Tôi là người mới, tôi đã hiểu đúng chưa? Hãy để tôi viết nó xuống." Điều quan trọng là sau đó thực sự tuân theo quy trình, hoặc cố gắng và gọi cho chúng tôi nơi nó phá vỡ.

Có thể bạn bắt đầu với những cuộc trò chuyện như vậy là đặc biệt và sau đó đề xuất các nghi thức thường xuyên.

Thực hiện phương pháp này cho phép một cách tiếp cận gia tăng, nhẹ nhàng nhẹ nhàng. Bạn có thể tránh xuất hiện như một đàn em, những người họ biết tất cả và thay vào đó cố gắng trở thành người hỗ trợ cho nhóm thực hiện thay đổi.

Một số cân nhắc:

• Một số đội có một quá trình nghèo nàn nhưng thực sự đã biết điều đó. Họ muốn thay đổi và chỉ cần một cái gì đó để xúc tác điều đó. Các đội khác thực sự bị mắc kẹt theo cách của họ và khó khăn hơn nhiều để thay đổi.
• Các cá nhân cũng vậy.
• Bạn cần phải nhạy cảm với điều đó và tìm ra ai trong nhóm mở cửa để thay đổi và ai không. Hiểu tại sao.
• Tìm chiến thắng dễ dàng.
• Thực hiện các thay đổi chào mừng đến với nhóm: Tìm điểm đau riêng của họ và cố gắng giúp khắc phục chúng.