원점회귀(Shift Left Zero)
현재의 DevOps 철학은 가능한 일찍 피드백하고, 가능한 일찍 테스트하고, 보안과 프로덕션 환경을 가능한 초기부터 고려한다.
소프트웨어가 조금씩 조금씩 올바른 방향으로 나아가게 한다. == TDD
가장 간단한 테스트 케이스부터 작성한다. 가장 간단한 개발을 한다. 테스트 한다. 리펙토링을 한다. x 반복
--> 조금씩 조금씩 올바른 방향으로 소프트웨어가 완성되어 간다.
눈이 많아야 버그가 줄어든다. 눈이 많아야 옳은 방향으로 나아간다.
숨기지 말자
코드를 숨기지 말자
내가 할 수 없는 일을 숨기지 말자
실수나 실패를 숨기지 말자
상호작용의 세 기둥
겸손 - 존중 - 신뢰
겸손 : 당신의 코드는 우주의 중심이 아니며, 완벽하지도 않다. 겸손한 사람은 배움에 열려 있다.
존중 : 함께 일하는 동료를 진심으로 대하고, 그들의 능력과 성취에 감사해야 한다.
신뢰 : 동료들이 유능하고, 올바른 일을 하리라 믿는다.
'사회적 관계의 힘을 과소평가하지 말라.' 사람을 속이거나, 조정하거나, 과소평가하거나, 비난하기 보다는 일이 진행되도록 관계를 형성하라. 관계는 언제나 프로젝트보다 오래 지속되며, 동료와의 관계는 필요할 때 자신들의 수고를 기꺼이 마다하지 않도록 만들어 준다.
실패는 선택이다
실패하지 않으면 혁신을 시도하지 않는 것이며, 위험을 감수하지 않는 것이다.
실패하지 않는 가장 완벽한 방법은 시도와 도전을 하지 않는 것이다.
(단, 같은 일에서 반복해서 실패 또는 문제가 발생한다면 그것은 실패한 것이 아니라 무능한 것이다.)
포스트모템(Post mortem)
일이 끝난 이후에 검토하는 것. 포스트모템 문서는 사죄, 변명, 지적으로 채워지면 안된다. 무엇을 배웠는지와 무엇을 바꿀지가 담겨야 한다.
그런 다음 포스트모템에서 제안한 변화를 팀이 실천했는지를 확인해야 한다.
- 사건의 개요
- 사건을 인지하고 해결에 이르기까지의 타임라인
- 사건의 근본 원인
- 영향과 피해 평가
- 문제를 즉시 해결하기 위한 조치 항목(소유자 명시)
- 재발 방지를 위한 조치 항목(소유자와 기한 명시)
- 해당 경험에서 얻은 교훈
지식 공유
=배움을 가로 막는 장애물=
전부 아니면 전무 전문성(all or nothing expertise) :
모든 것을 아는 사람과 아무것도 모르는 사람으로 나뉘는 문제
자식과 책임은 계속 이미 전문가가 된 사람에게 집중되고, 새로운 팀원이나 초심자들은 그들만의 울타리에 갇혀 느리게 성장하게 됨
앵무새처럼 흉내내기(parroting)
이해하지 못한 상태로 흉내만 내는 것. 이 중상에 빠진 사람은 목적이나 내면을 이해하지 못하고 기존 패턴이나 코드를 따라 함
유령의 묘지(haunted graveyard)
무언가 잘못될 게 두려워서 아무도 손대지 않는 영역(주로 코드)
두려움과 의심 때문에 손대기를 기피하는 영역
=철학=
팀내 전문가의 일대일 조언은 매우 효과적이지만, 확장성이 부족하여 팀이 커지면 그리 유용하지 못하다.
문서화된 지식은 팀을 넘어 조직 전체로 퍼뜨릴 수 있으며, 팀 위키(WIKI)같은 도구를 활용하면 많은 사람이 참여하여 자신들의 전문성을 더 큰 그룹과 공유할 수 있다.
정리된 문서가 일대일 조언보다 확장성은 좋지만, 개별적인 상황에서는 다소 적합하지 않을 수 있으며, 정보를 문서에 반영해야 하는 유지보수 비용이 든다.
기록된 지식은 확장성이 좋고, 일대일 현장 지식은 기록으로 커버하지 못하는 영역을 보완해 준다.
가장 적합한 지식 공유 방법은 조직의 규모 등에 따라 변화되어야 한다.
중요한 점은 조직 스스로가 교육하고, 배우고 성장하는 데 집중하고, 충분한 수의 전문가를 양성해야 한다.
엔지니어링 전문성이 너무 높아서 문제되는 경우는 없다.
'Wise saying' 카테고리의 다른 글
| 소프트웨어의 지속 가능성 (0) | 2022.09.22 |
|---|
