Văn hóa thường bị bỏ qua và hiểu sai, nhưng nó lại là yếu tố chính dẫn đến hiệu quả hoạt động của công ty. Nếu chúng ta không quản lý văn hóa của mình, chúng ta sẽ thực hiện các phương pháp sai lầm mà cuối cùng sẽ ảnh hưởng đến mục tiêu kinh doanh của chúng ta.
Hiểu văn hóa hiện tại của một tổ chức
Văn hóa cho chúng ta biết về các giá trị và chuẩn mực trong một nhóm hoặc công ty. Nó xác định điều gì là quan trọng cũng như cách mọi người tiếp cận và làm việc với nhau.
CULTURE = “Cách mọi thứ có thể được thực hiện một cách thông minh để thành công”
Hãy lấy ví dụ về nhóm hỗ trợ khách hàng. Văn hóa của đội đó phải sao cho họ đạt được 97-98% sự hài lòng của khách hàng.
Để làm hài lòng khách hàng, trước hết họ cần lịch sự, ngay cả trong những tình huống khó khăn họ cần phải là người lắng nghe tốt để tránh nhầm lẫn họ cần ưu tiên công việc theo yêu cầu.
Hãy dừng lại một chút và đặt một vài câu hỏi cho bản thân:
- Văn hóa của công ty tôi bây giờ là gì?
- Văn hóa này phù hợp với mục tiêu kinh doanh hoặc KRA của tôi như thế nào?
- Tôi có thể gặp những vấn đề gì do lệch trục?
Đối với mọi tổ chức, 4C đóng một vai trò quan trọng
Bây giờ, hãy cùng tìm hiểu văn hóa của một tổ chức phát triển phần mềm. Có nhiều nhóm tham gia để xây dựng và duy trì một đơn vị phần mềm duy nhất. Tất cả những đội này đều có mục tiêu riêng và văn hóa riêng biệt.
Quá trình này bắt đầu sau khi các yêu cầu đã được xác nhận bởi khách hàng.
Các nhà phát triển tuân theo các nguyên tắc mã hóa do tổ chức của họ xác định và các công cụ lập trình như trình biên dịch, trình thông dịch, trình gỡ lỗi, v.v. được sử dụng để tạo mã. Các ngôn ngữ lập trình cấp cao khác nhau như C, C ++, Pascal, Java và PHP được sử dụng để viết mã.
Họ chia gói hoàn chỉnh thành các thư mục nhỏ và sau đó phát triển các mã nhỏ cho phù hợp.
Giai đoạn 1 : Các đơn vị mã nhỏ này sau đó được ghép lại để tạo thành một đơn vị lớn. Trong khi tích hợp các chip nhỏ hơn, một thử nghiệm cấp độ dự án phải được thực hiện được gọi là thử nghiệm tích hợp.
Giai đoạn 2 : Sau khi tích hợp thành công, nó được triển khai thành một hệ thống giả. Hệ thống giả này có cấu hình tương tự như cấu hình của máy khách hoặc máy mà dự án này sẽ được triển khai cuối cùng.
Giai đoạn 3 : Cuối cùng, sau khi thử nghiệm tất cả các tính năng trong một hệ thống giả, dự án được triển khai vào máy chủ sản xuất hoặc máy khách.
Mặc dù quá trình này có vẻ rất suôn sẻ và dễ dàng, nhưng về mặt kỹ thuật thì nó rất khó đạt được.
Hãy xem những vấn đề chúng ta có thể gặp phải:
java vectơ là gì
Giai đoạn 1 :
Khách hàng luôn tìm kiếm những thay đổi để nâng cao chất lượng của sản phẩm. Hầu hết thời gian khi lần lặp đầu tiên được thực hiện, khách hàng sẽ đề xuất một vài thay đổi. Khi các nhà phát triển nhận được các thay đổi, họ bắt đầu kết hợp chúng, điều này ảnh hưởng đến việc tích hợp dẫn đến các bản dựng bị hỏng.
Giai đoạn 2:
Hầu hết thời gian, những người kiểm tra hoặc những người vận hành khác sẽ không nhận thức được những thay đổi mới sẽ được thực hiện. Ngay sau khi họ nhận được mã từ các nhà phát triển, họ bắt đầu thử nghiệm chúng. Trong khi ở mặt sau, các nhà phát triển vẫn đang thực hiện các thay đổi.
Vì họ không có đủ thời gian để thực hiện các thay đổi mới, họ sẽ phát triển các mã kém hiệu quả, họ phải đối mặt với các vấn đề về mạng và cơ sở dữ liệu khác, điều này lại làm trì hoãn thời gian giao hàng của họ.
Cuối cùng, khi họ cung cấp mã cho nhóm vận hành, họ chỉ còn lại rất ít thời gian để tạo và triển khai các trường hợp thử nghiệm mới. Vì vậy, họ bỏ qua nhiều trường hợp thử nghiệm mà sau đó họ nhận ra rằng những trường hợp đó được ưu tiên cao.
Giai đoạn 3:
Mặc dù hầu như bản dựng dường như đã sẵn sàng để đi vào sản xuất, nhưng kết quả hoàn toàn bất ngờ. Quá trình xây dựng không thành công và một số lỗi xảy ra.
Sau đó, đối với mỗi lỗi xảy ra, họ phải theo dõi lý do tại sao nó xảy ra, nó xảy ra ở đâu, những thay đổi nào cần phải thực hiện để khắc phục nó, liệu mã của người khác có thay đổi để làm cho nó tương thích với những cái trước đó không. Cuối cùng, đối với tất cả các lỗi này, một báo cáo lỗi phải được tạo.
Sự cố này là do lỗi hệ thống do sự thiếu hiểu biết của nhà phát triển cơ sở dữ liệu về hiệu quả của mã, sự thiếu hiểu biết của người kiểm tra về số lượng trường hợp thử nghiệm, v.v.
Vì khách hàng luôn giữ chặt thời hạn, các nhân viên liên quan đến việc đạt được chúng chỉ tập trung vào bản phát hành cuối cùng ngay cả khi họ phải làm giảm chất lượng tổng thể.
Mặc dù đây có vẻ là một vấn đề trong phối hợp công việc, đây thực sự là sự thất bại của nền văn hóa được áp dụng.
Điều này xảy ra do sự phụ thuộc lớn vào các quy trình thủ công. Việc chạy đi chạy lại trong cùng một nhóm vì thiếu kiến thức về các lĩnh vực khác nhau, thiếu khả năng tiếp cận hoặc có thể thiếu sự quan tâm sẽ làm tăng gánh nặng và nỗi đau của chính chúng ta.
Đã đến lúc chúng ta cần phải linh hoạt. Có thể rất khó để nắm vững tất cả các quy trình liên quan đến một hệ thống, nhưng chúng ta có thể là đầu tàu của tất cả, thành thạo một trong số chúng. Sau đó, chỉ chúng ta mới có thể tự động hóa hệ thống của mình hoặc làm cho nó đủ thông minh để khôi phục thay vì khôi phục.
Bây giờ, bạn có thể đang nghĩ tại sao?
Đó là bởi vì cái bạn đang làm chủ phụ thuộc nhiều vào người khác. Vì vậy, để biết về điểm phụ thuộc, chúng ta cần hiểu toàn bộ hệ thống.
Vì vậy, hãy nghĩ về một quá trình để thay đổi văn hóa. Trước đó bạn đã có câu trả lời cho những câu hỏi dưới đây chưa?
- Văn hóa hiện tại của bạn thất bại ở đâu?
- Tại sao bạn muốn thay đổi quy trình?
- Bạn đã xác định rõ ràng tất cả các thay đổi cần thiết chưa?
- Bạn đã nhận được phản hồi và mua từ tất cả những người nắm giữ cổ phần bị ảnh hưởng chưa?
- Bạn đã đánh giá lại kỷ luật quy trình, dữ liệu và hệ thống đo lường cho sự thay đổi chưa?
Vì vậy, bây giờ khi chúng tôi có câu trả lời cho tất cả, chúng tôi nghĩ đến một cuộc cách mạng trong hệ thống của chúng tôi. Cuộc cách mạng này sẽ diễn ra như thế nào? Nó chỉ có thể đạt được khi chúng ta giết chết những gì chúng ta đang có. Rất nhiều thời gian bị lãng phí trong việc di chuyển mã giữa các đội. Chúng tôi phải mang lại quá trình mà chúng tôi có thể tích hợp liên tục và triển khai liên tục.
Quá trình tích hợp và triển khai liên tục này làm cho nó nhanh nhẹn hơn. Mang lại sự nhanh nhẹn này được coi là văn hóa DevOps.
DevOps là hoạt động thực hành của các kỹ sư phát triển và vận hành tham gia cùng nhau trong toàn bộ vòng đời dịch vụ, từ thiết kế thông qua quá trình phát triển đến hỗ trợ sản xuất.
.trim làm được gì trong java
Không dễ thay đổi hệ thống làm việc theo thời gian. Thực hiện chuyển đổi thành công là cải tạo hệ thống, thay vì xây dựng lại.
Bây giờ, hãy xem cách chúng ta có thể đạt được điều này. Có thể có hai cách để tiếp cận.
1) Từ trên xuống
hợp nhất sắp xếp thực hiện c ++
2) Từ dưới lên
Đi sâu hơn vào các kỹ thuật này, chúng tôi sẽ nhận ra kỹ thuật nào phù hợp nhất cho tổ chức của chúng tôi.
Theo cách tiếp cận từ trên xuống, chúng ta có thể gặp cấp quản lý cao hơn và yêu cầu họ thực hiện các thay đổi trên tất cả các nhóm. Nếu ban lãnh đạo được thuyết phục thì chúng tôi có thể bắt tay vào thực hiện.
Nhưng xác suất nhận được câu trả lời là “KHÔNG” là khá cao. Đó là bởi vì việc thay đổi hệ thống có thể khiến tổ chức mất ổn định.
Họ phải xem xét cơ cấu tổ chức, doanh thu, mức độ quan tâm của khách hàng, v.v. Nhưng yếu tố quan trọng nhất kéo họ trở lại khỏi hệ thống cũ là họ không thể nhìn thấy bức tranh lớn về những gì có thể đạt được và cách thức đạt được nó một cách suôn sẻ với cái mới hơn.
Trong trường hợp này, chúng ta có thể tìm kiếm cách tiếp cận thứ hai để có được bức tranh lớn này.
Phương pháp tiếp cận từ dưới lên kêu gọi tình nguyện viên. Ở đây chúng tôi phải nhận một nhóm nhỏ và một nhiệm vụ nhỏ và thực hiện nó trong Mô hình DevOps.
Nhìn vào khía cạnh kỹ thuật của mô hình này, chúng tôi có nhiều bộ công cụ phức tạp khác nhau giúp công việc hiệu quả và nhanh chóng hơn. Tuy nhiên, một mình các công cụ không đủ khả năng để tạo ra một môi trường cộng tác được gọi là DevOps.
Tạo một môi trường như vậy đòi hỏi bạn phải suy nghĩ thấu đáo, ví dụ: đánh giá và sắp xếp lại cách mọi người nghĩ về nhóm của họ, doanh nghiệp và khách hàng.
Việc kết hợp một bộ công cụ mới đơn giản hơn thay đổi văn hóa tổ chức. Bằng cách thúc đẩy các nhà phát triển chống đối xã hội chủ nghĩa, cho phép tích hợp mã kém hiệu quả, triển khai mã không được kiểm tra đúng cách, đổ lỗi cho nhau, coi nhóm vận hành là ngu ngốc không phải là những phương pháp hay nhất mà chúng tôi đang làm để hỗ trợ hoạt động kinh doanh và tạo ra giá trị cho khách hàng của chúng tôi.
Không phải các công cụ, chính những người sử dụng chúng mới làm cho quá trình trở nên phức tạp. Nói ở mức độ trừu tượng hơn là thu thập các ý tưởng và hành vi, cởi mở với chúng sẽ đưa chúng ta đến một con đường tươi sáng.
Hãy bắt đầu với một nhóm gồm 6 thành viên và một câu chuyện 3 điểm. Đầu tiên, chúng tôi phải chia nhỏ nhóm mà chúng tôi gọi là nhà phát triển, vận hành, người kiểm tra, v.v. Chúng tôi coi tất cả họ là một, chẳng hạn như “DevOps”. Khi nhận được yêu cầu, chúng tôi cần phân tích các vùng rủi ro. Hãy ghi nhớ những đoạn sâu hơn của biển & hellip .. Chúng tôi bắt đầu chèo thuyền.
Bây giờ, bạn phải đang nghĩ “hệ số x của việc tích hợp liên tục và triển khai liên tục làm giảm xác suất thất bại là gì”.
Với tầm nhìn và quy trình được cải thiện, chúng tôi có thể tiếp cận ban lãnh đạo với bức tranh rõ ràng về kết quả như quy trình diễn ra suôn sẻ như thế nào, giảm nguy cơ thất bại như thế nào, nhiệm vụ được hoàn thành trước mốc thời gian như thế nào, v.v.
Bây giờ, chúng ta có thể hình dung rõ ràng toàn bộ quy trình đã được tối ưu hóa trên cơ sở kỹ thuật và văn hóa như thế nào bằng cách xem xét lại sau mỗi lần lặp lại.
Edureka đã giám tuyển đặc biệt điều đó giúp bạn nắm vững các khái niệm về Puppet, Jenkins, Ansible, SaltStack, Chef và những người khác.
Có một câu hỏi cho chúng tôi? Đề cập đến họ trong phần bình luận và chúng tôi sẽ liên hệ lại với bạn.
Bài viết liên quan: