문화는 종종 무시되고 오해되지만 기업의 성과를 좌우하는 핵심 요소입니다. 문화를 관리하지 않으면 결국 잘못된 관행을하게되어 궁극적으로 비즈니스 목표에 영향을 미치게됩니다.
조직의 현재 문화 이해
문화는 그룹 또는 회사 내의 가치와 규범에 대해 알려줍니다. 중요한 것은 무엇이며 사람들이 서로 접근하고 협력하는 방식을 식별합니다.
문화 = '성공을 위해 어떻게 일을 현명하게 할 수 있는가'
고객 지원 팀의 예를 들어 보겠습니다. 해당 팀의 문화는 고객 만족도의 97-98 %를 달성 할 수 있어야합니다.
고객의 기쁨을 생각하면서 무엇보다도 정중해야합니다. 어려운 상황에서도 요구 사항에 따라 작업의 우선 순위를 정해야하는 혼란을 피하기 위해 좋은 경청자가되어야합니다.
잠시 멈추고 스스로에게 몇 가지 질문을하겠습니다.
- 현재 우리 회사의 문화는 무엇입니까?
- 이 문화가 내 비즈니스 목표 또는 KRA와 얼마나 잘 일치합니까?
- 정렬 불량으로 인해 어떤 문제가 발생할 수 있습니까?
모든 조직에서 4C는 중요한 역할을합니다.
이제 소프트웨어 개발 조직의 문화를 살펴 보겠습니다. 단일 소프트웨어 유닛을 구축하고 유지하기 위해 많은 팀이 참여합니다. 이 모든 팀에는 별도의 목표와 별도의 문화가 있습니다.
이 프로세스는 고객이 요구 사항을 확인한 후에 시작됩니다.
개발자는 조직에서 정의한 코딩 지침을 따르고 컴파일러, 인터프리터, 디버거 등과 같은 프로그래밍 도구를 사용하여 코드를 생성합니다. 코딩에는 C, C ++, Pascal, Java 및 PHP와 같은 다양한 고급 프로그래밍 언어가 사용됩니다.
그들은 완전한 패키지를 작은 폴더로 나누고 그에 따라 작은 코드를 개발합니다.
스테이지 1 :이 작은 코드 단위는 큰 단위를 형성하기 위해 클럽 화됩니다. 더 작은 칩을 통합하는 동안 통합 테스트라고하는 프로젝트 수준 테스트를 수행해야합니다.
2 단계 : 성공적인 통합 후 더미 시스템에 배포됩니다. 이 더미 시스템은이 프로젝트를 최종적으로 배포해야하는 클라이언트 컴퓨터 또는 컴퓨터와 유사한 구성을 가지고 있습니다.
3 단계 : 마지막으로 더미 시스템의 모든 기능을 테스트 한 후 프로젝트가 프로덕션 서버 또는 클라이언트 컴퓨터에 배포됩니다.
이 과정은 말로는 매우 부드럽고 쉬운 것처럼 보이지만 기술적으로는 달성하기가 매우 어렵습니다.
어떤 문제에 직면 할 수 있는지 살펴 보겠습니다.
스테이지 1 :
지금 서비스 티켓팅 시스템 교육
고객은 항상 제품의 품질을 개선하기 위해 변경 사항을 찾고 있습니다. 첫 번째 반복이 수행되는 대부분의 경우 클라이언트는 몇 가지 변경 사항을 제안합니다. 개발자가 변경 사항을 받으면 통합에 영향을주는 통합을 시작하여 빌드가 손상됩니다.
2 단계 :
대부분의 경우 테스터 또는 다른 운영 담당자는 새로운 변경 사항을 인식하지 못합니다. 개발자로부터 코드를받는 즉시 테스트를 시작합니다. 백엔드에서 개발자는 여전히 변경을하고 있습니다.
새로운 변경 사항을 구현할 시간이 충분하지 않아 결국 다른 네트워크 및 데이터베이스 문제에 직면하여 비효율적 인 코드가 개발되어 전달 시간이 다시 지연됩니다.
마침내 운영 팀에 코드를 전달하면 새로운 테스트 케이스를 생성하고 구현하는 데 최소한의 시간이 남습니다. 그래서 그들은 나중에 그들이 우선 순위가 높다는 것을 깨닫는 많은 테스트 케이스를 건너 뜁니다.
3 단계 :
사실상 빌드가 생산 준비가 된 것처럼 보이지만 결과는 완전히 예상치 못한 것입니다. 빌드가 실패하고 여러 버그가 발생합니다.
그런 다음 버그가 발생했을 때마다 발생 원인, 발생 위치,이를 극복하기 위해 수행해야하는 변경 사항, 이전 코드와 호환되도록 다른 코드에 변경이 있는지 추적해야합니다. 마지막으로 이러한 모든 버그에 대해 버그 보고서를 생성해야합니다.
실패는 데이터베이스 개발자의 코드 효율성에 대한 무지, 테스터의 테스트 사례 수에 대한 무지 등으로 인한 시스템 오류 때문입니다.
클라이언트는 항상 마감일을 빡빡하게 유지하기 때문에이를 달성하는 데 관여하는 직원은 전체 품질을 타협해야하는 경우에도 최종 릴리스에만 집중합니다.
업무 조정에 문제가되는 것 같지만 이것은 실제로 채택 된 문화의 실패입니다.
이것은 수동 프로세스에 대한 큰 의존성 때문에 발생합니다. 서로 다른 분야에 대한 지식 부족 또는 관심 부족으로 같은 팀에서 이리저리 달리는 것은 우리 자신의 부담과 고통을 증가시킵니다.
다재다능해야 할 때입니다. 시스템에 관련된 모든 프로세스를 마스터하는 것은 어려울 수 있지만 우리는 모두의 잭이되어 그중 하나를 마스터 할 수 있습니다. 그래야만 시스템을 자동화하거나 롤백보다는 복구 할 수있을만큼 지능적으로 만들 수 있습니다.
자, 왜 그런지 생각하고 계십니까?
왜냐하면 당신이 마스터하는 사람이 다른 사람에게 크게 의존하기 때문입니다. 따라서 종속성 지점을 알기 위해서는 전체 시스템을 이해해야합니다.
그러니 문화를 바꾸는 과정을 생각해 봅시다. 그 전에 아래 질문에 대한 답이 있습니까?
- 현재의 문화는 어디에서 실패합니까?
- 프로세스를 변경하려는 이유는 무엇입니까?
- 필요한 모든 변경 사항을 명확하게 확인 했습니까?
- 영향을받는 모든 이해 관계자로부터 피드백과 동의를 얻었습니까?
- 변경을 위해 프로세스 규칙, 데이터 및 측정 시스템을 재 검증 했습니까?
이제 우리가 모든 것에 대한 답을 얻었을 때 우리는 우리 시스템에 대한 혁명을 생각합니다. 이 혁명은 어떻게 일어날까요? 그것은 우리가 지금있는 것을 죽일 때만 성취 될 수 있습니다. 팀 간의 코드 마이그레이션에 많은 시간이 낭비됩니다. 지속적인 통합과 지속적인 배포를 수행 할 수있는 프로세스를 가져와야합니다.
이러한 지속적인 통합 및 배포 프로세스는 더 민첩하게 만듭니다. 이러한 민첩성을 가져 오는 것은 DevOps 문화로 간주됩니다.
DevOps는 설계부터 개발 프로세스, 생산 지원에 이르기까지 전체 서비스 라이프 사이클에 함께 참여하는 운영 및 개발 엔지니어의 관행입니다.
시간이 지남에 따라 작업 시스템을 변경하는 것은 쉽지 않습니다. 성공적인 전환은 시스템을 재 구축하는 것이 아니라 개조하는 것입니다.
def __init __ (self) python
이제이를 어떻게 달성 할 수 있는지 살펴 보겠습니다. 접근하는 방법은 두 가지가 있습니다.
1) 위에서 아래로
2) 상향식
이러한 기술에 대해 자세히 살펴보면 조직에 가장 적합한 기술을 알게 될 것입니다.
하향식 접근 방식에서는 상위 관리자에게 가서 모든 팀에 걸쳐 변경을 요청할 수 있습니다. 경영진이 확신하면 작업을 시작할 수 있습니다.
그러나“아니오”라고 대답 할 확률은 상당히 높습니다. 시스템을 변경하면 조직이 불안정해질 수 있기 때문입니다.
그들은 조직의 구조, 수익, 고객의 관심 수준 등을 조사해야합니다.하지만 이전 시스템에서 빠져 나가는 데있어 가장 중요한 요인은 무엇을 달성 할 수 있는지, 그리고 새로운 것을 통해 얼마나 원활하게 달성 할 수 있는지에 대한 큰 그림.
이 경우이 큰 그림을 얻기위한 두 번째 접근 방식을 찾을 수 있습니다.
상향식 접근 방식에는 자원 봉사자가 필요합니다. 여기서 우리는 소규모 팀과 소규모 작업을 데브 옵스 모델에서 실행해야합니다.
이 모델의 기술적 측면을 살펴보면 작업을보다 효율적이고 빠르게 수행 할 수있는 다양한 정교한 도구 세트가 있습니다. 그러나 도구만으로는 DevOps라고하는 협업 환경을 만들 수 없습니다.
이러한 환경을 만들려면 상자에서 벗어나 생각해야합니다. 사람들이 팀, 비즈니스 및 고객에 대해 어떻게 생각하는지 평가하고 재정렬합니다.
Java 용 Eclipse 설정 방법
새로운 도구 세트를 조합하는 것은 조직 문화를 바꾸는 것보다 간단합니다. 반사회적 마스터 개발자를 홍보하고, 비효율적 인 코드를 통합하고, 제대로 테스트되지 않은 코드를 배포하고, 서로를 비난하며, 운영 팀이 어리 석다고 생각하는 것은 비즈니스를 활성화하기 위해 따르는 모범 사례가 아닙니다. 고객을위한 가치를 창출합니다.
프로세스를 복잡하게 만드는 것은 도구가 아니라 사용하는 사람들입니다. 아이디어와 행동을 모으기보다 추상적 인 수준에서 말하는 것은 그들에게 열린 마음으로 우리를 밝은 길로 인도합니다.
6 명으로 구성된 팀과 3 점 이야기부터 시작하겠습니다. 첫째, 우리는 개발자, 운영, 테스터 등으로 부르는 팀을 깨야합니다. 우리는 모두를 하나로 간주합니다. 'DevOps'라고 말합니다. 요구 사항을 받으면 위험 영역을 분석해야합니다. 바다 & 헬립의 더 깊은 부분을 염두에두고 .. 우리는 항해를 시작합니다.
이제 '실패 가능성을 줄이는 이러한 지속적인 통합 및 지속적인 배포의 x- 팩터는 무엇입니까'라고 생각해야합니다.
개선 된 비전과 프로세스를 통해 프로세스가 얼마나 순조 로웠는지, 실패 위험이 어떻게 감소했는지, 타임 라인 이전에 작업이 어떻게 완료되었는지 등과 같은 결과를 명확하게 파악하여 경영진에 접근 할 수 있습니다.
이제 우리는 각 반복 후 회고를 통해 전체 프로세스가 기술 및 문화적 측면에서 어떻게 최적화되었는지 명확하게 시각화 할 수 있습니다.
Edureka는 특별히 큐레이팅했습니다. Puppet, Jenkins, Ansible, SaltStack, Chef에 대한 개념을 마스터하는 데 도움이됩니다.
질문이 있으십니까? 댓글 섹션에 언급하시면 다시 연락 드리겠습니다.
관련 게시물: