Agile, DevOps, ALM

Agile

형식보다 실용
빠르고 민첩하게 고객의 요구사항에 신속하게 대응하고 개발
빠르게 전달 고객만족 실현

• <-> 폭포수방법론
• 문서 x 작동하는 소프트웨어 o
• 고객과 협력
• 변화에 대응

도입이 어려운 이유

• 기존의 방식 고수
• 수평적이지만 한국은 수직적
• 직원들과의 긴밀한 협의 끝에 정착
• 기존방식의 문제점을 인식해야함
• 기존의 인식할만한 비효율적인 프로세스를 하나하나 서서히 변형해야함

DevOps

개발자는 계속해서 새로운것을 도입하고 싶어하지만, Ops들은 안정성을 최우선으로 여긴다. 그래서 등장한것이 DevOps

• 개발자들과 Ops들을 서로 잘 융합시키고 의사소통이 원할하게 하기 위한 개발 방법론이다.
• 보통은 개발과 운영을 나워서 관리해서 의사소통에 문제가 있고 비효율적

Cross Functional Team

• 각 프로세스의(개발 ~ 배포 및 테스트까지) 담당자들을 하나의 팀으로 모으라는 뜻

Widely Shared Metrics

• 서비스를 개발만 하는게 아니라 서비스가 운영에서 잘 돌아가고 있는지, 사용자의 반응은 어떤지를 측정할 수 있는 기준이 필요하다는것

Automating repetitive tasks

• 반복적인 일들은 자동화
• ex) CI/CD
  • 새 버전의 소프트웨어를 제공하기 위해 수행해야 할 일련의 단계
• 고도화된 서비스를 만들 여유와 시간을 벌 수 있을것

Post Mortems

• 장애나 이슈가 있을때 그걸 혼자만 알지 말고 팀원들과 공유를 해야한다

Regular Release

• 짧은 주기의 정기 배포를 통해서 빠르게 서비스의 기능을 개선하고 고객들의 VoC를 반영해 나가야한다

ALM

• 요구 사항 관리, 개발, 유지보수에 이르기까지 소프트웨어의 전 생명주기를 면밀히 관리하는 것
• 소프트웨어 개발 팀뿐만 아니라 관련된 다른 팀과의 원활한 공동작업을 위한 표준화된 환경을 제공하며 프로세스의 상황과 실적을 가시화하고 추적

필요성을 인지하지 못하고 단지 좋다는 소리만 듣고 방법론을 도입하는 것은 한계가 있다
기존 방법론의 문제점을 인식하고 한단계 한단계 천천히 적용시키는 것이 중요하다

ex) DevOps: 개발을 시작하는 단계부터 운영이 안정화되는 단계까지 매일 개발팀과 운영팀이 함께 간단한 회의를 하고 업무시작
            긍정적인 결과가 나왔다면 천천히 개발과 운영을 하나의 팀이 되고록 서서히 변경