2017년 3월 20일 월요일
2016년 7월 27일 수요일
2016년 6월 10일 금요일
DevOps는 무엇인가
DevOps
서비스나 제품의 릴리즈를 위해서 개발/운영/QA 활동 등이 서로 협업하여 장애없이 서비스나 어플리케이션을 빠르게 릴리즈 하는 방법
Agile, DevOps 뭐가 다른거야
2016년 6월 9일 목요일
SW 유지보수 적용사례 – 적용 효과
• 개발 업무 진행상황의 가시성 향상
– 적용 전에는 개발자들이 무슨 일에 보틀넥이 걸려있으며 어떤 애로사항이 있는지 알기 어려워 팀장 입장에서 업무 진행 현황을 일일이 물어보아야 파악 할 수 있었는 데 지금은 타스크 보드와 데일리 미팅을 통하여 일일이 물어보 지 않아도 팀원들이 어떤 문제에 애로사항이 있으며 어떤 업무에 버틀넥이 있는지 쉽게 알개 되었고 당면한 문제 점들을 바로 바로 해결할 수 있게 되었다.
• 통합테스트 단계에서 발생하는 결함 감소
– 평균적으로 QA팀에서 개발팀으로 매달 8~9여건 정도의 크고 작은 재 작업 요청이 있었으나 애자일을 적용하고
나서부터는 1~2건 정도로 줄어든 상태이며 그나마도 마이너한 작업이 되어 품질이 많이 향상되었다. (70% 이상 감소)
• 개발과정의 효율성이 높아지고 생산성 향상
– 상호간의 협업 증대로 월별 처리건수 향상 (50% 이상 향상)
– 적용 전에는 개발자들이 무슨 일에 보틀넥이 걸려있으며 어떤 애로사항이 있는지 알기 어려워 팀장 입장에서 업무 진행 현황을 일일이 물어보아야 파악 할 수 있었는 데 지금은 타스크 보드와 데일리 미팅을 통하여 일일이 물어보 지 않아도 팀원들이 어떤 문제에 애로사항이 있으며 어떤 업무에 버틀넥이 있는지 쉽게 알개 되었고 당면한 문제 점들을 바로 바로 해결할 수 있게 되었다.
• 통합테스트 단계에서 발생하는 결함 감소
– 평균적으로 QA팀에서 개발팀으로 매달 8~9여건 정도의 크고 작은 재 작업 요청이 있었으나 애자일을 적용하고
나서부터는 1~2건 정도로 줄어든 상태이며 그나마도 마이너한 작업이 되어 품질이 많이 향상되었다. (70% 이상 감소)
• 개발과정의 효율성이 높아지고 생산성 향상
– 상호간의 협업 증대로 월별 처리건수 향상 (50% 이상 향상)
SW 개발에서 나타나는 전형적인 이슈와 문제점
1. 프로젝트 일정 및 태스크 공수 추정의 신뢰성 부족
• 전형적인 일정 및 공수 추정 형태
– 소수의 개발리더(전문가)를 중심으로 단독 추정
– 경영진및고객이제시한일정에WBS를끼워맞추는형태로일정개발
• 전형적인 일정 및 공수 추정 형태
– 소수의 개발리더(전문가)를 중심으로 단독 추정
– 경영진및고객이제시한일정에WBS를끼워맞추는형태로일정개발
-
문제점
-
– 리더가 본인이나 잘하는 사람을 기준으로 공수를 추정하다 보니 항상 프로
젝트 공수가 부족
-
– 개인의 편차가 심하며 공수 추정의 신뢰성이 떨어짐
-
– 알려지지 않은(Unknown) 리스크를 고려한 일정 버퍼가 부족
-
– 리더가 본인이나 잘하는 사람을 기준으로 공수를 추정하다 보니 항상 프로
-
애자일 해법
-
– 전문가 집단 추정(Planning Poker ) 기법을 활용하여 평균 공수를 추정함으
로써 추정의 신뢰성을 향상
-
– 평균 공수 추정에 따른 일정 산정과 알려지지 않은(Unknown) 리스크를 고
려한 일정 버퍼 삽입
-
– 전문가 집단 추정(Planning Poker ) 기법을 활용하여 평균 공수를 추정함으
2. 업무 성과 및 품질 불량으로 관리자와 팀원 간의 갈등 발생
-
전형적인 갈등 상황
-
– 팀원은리더의일방적지시에따라업무를진행하다보니해당업무에대한완
료 기준이 서로 상이함
-
– 태스크초기일정미준수에따른비난이나질책이발생
-
– 팀원이수행한태스크점검시결함이자주발생하는것에실망
-
– 팀원은리더의일방적지시에따라업무를진행하다보니해당업무에대한완
료 기준이 서로 상이함
-
애자일 해법
-
– 스프린트계획시고객및리더,팀원이함께토론하여해당업무혹은요구사
항에 대한 완료기준을 명확하게 설정함(Test Driven)
-
– 리더는 태스크 일정 수행의 불확실성을 인식하고 태스크 장애요소 해결에 집중
-
– 업무 수행에 대한 책임을 개인 책임보다는 팀 책임으로 설정하고
-
– 완료조건에크로스및QA테스트검증포함
-
– 스프린트계획시고객및리더,팀원이함께토론하여해당업무혹은요구사
3. 수동적인 팀원들의 자세 및 낮은 사기
-
전형적인 상황
-
– 업무계획시팀원의참여부족
-
– 업무수행의타당성및명확한목표가부재
-
– 대부분의 업무할당이 리더의 일방적 지시로 이루어짐
-
– 리더의 업무 관여로 업무수행의 자율성이 부족
-
– 유지보수 조직은 잘해야 본전
-
– 업무계획시팀원의참여부족
-
애자일 해법
-
– 릴리즈 및 스프린트 계획 시 팀원들이 주도적으로 업무를 계획하게 유도
-
– 스프린트 계획 시 사용자와 개발자가 업무수행의 타당성과 대안을 토론함
-
– 팀원들이 본인들이 잘할 수 있는 업무태스크를 스스로 선택하고 업무를 진행(Self-organizing)
-
– 팀원에게 업무수행의 자율성을 보장하고 리더는 문제해결에만 집중함
-
– 팀원과 함께 스프린트 목표(정성적/정량적)를 설정하고 리더는 이에 대한 피드백을 주기적으로 제공
-
– 주기적인 1:1 팀원 코칭
-
– 릴리즈 및 스프린트 계획 시 팀원들이 주도적으로 업무를 계획하게 유도
4. 프로젝트 및 팀 구성원들간의 소통 및 협력 부족
-
전형적인 상황
-
– 리더와 팀원, 리더와 리더간의 업무소통은 활발하게 이루어지나 팀원과 팀원, 타 팀원간의 소통과 협력은 부족
-
– 팀간에 발생하는 이슈 및 문제들이 리더들 미팅을 통해서만 해결됨
-
– 리더와 팀원, 리더와 리더간의 업무소통은 활발하게 이루어지나 팀원과 팀원, 타 팀원간의 소통과 협력은 부족
-
애자일 해법
-
– 데일리 스탠드업 미팅, 스프린트 리뷰, 회고, 오픈 스페이스 미팅 등을 활용하여 팀원들간의 소통과 협력을 제고
-
– 개인책임이아닌팀책임업무수행
-
– 동료평가 및 절대평가를 통한 팀원간의 협력 증진
-
– 데일리 스탠드업 미팅, 스프린트 리뷰, 회고, 오픈 스페이스 미팅 등을 활용하여 팀원들간의 소통과 협력을 제고
5. 요구사항의 불확실성과 잦은 변경
-
전형적인 상황
-
– 고객 요구사항이 초기에 개략적으로 도출되며 제품 구현 후에 자주 변경됨
-
– 요구사항의 불확실성으로 인하여 범위 베이스라인 설정과 변경통제가 어려움
-
– 고객 요구사항이 초기에 개략적으로 도출되며 제품 구현 후에 자주 변경됨
-
애자일 해법
-
– 주어진 일정과 비용 내에서 우선순위가 높은 기능 중심으로 개발
-
– 사용자스토리중심의릴리즈계획과상세태스크중심의스프린트계획으로구분하여전체범위및일정관리
-
– 요구사항에 대한 우선순위 관리와 스프린트 단위로 요구 변경을 통제함
-
– 주어진 일정과 비용 내에서 우선순위가 높은 기능 중심으로 개발
6. 개발 산출물 및 업무 회의 과다
-
전형적인 상황
-
– 고객사혹은내부표준프로세스준수에따른개발산출물과다발생
-
– 고객이나 개발팀에게 의미 없는 산출물이 대량 발생
-
– 수시로발생하는각종업무회의로인하여실제일은저녁에나가능
-
– 고객사혹은내부표준프로세스준수에따른개발산출물과다발생
-
애자일 해법
-
– 고객 및 개발팀에게 실질적으로 가치가 있는 산출물을 정의(유지보수에 필요한 산출물 중심)
-
– 스프린트 회고를 통하여 불필요한 산출물과 회의를 지속적으로 제거
(표준 프로세스는 준수해야 할 프로세스라기보다는 개선해야 할 프로세스로 인식)
-
– 아침회의는 데일리 스탠드업 미팅 시 혹은 이후에 바로 수행함으로써 업무시간과 회의시간을 구분
-
– 회의 방식을 Push 방식에서 Pull 방식으로 전환
-
– 고객 및 개발팀에게 실질적으로 가치가 있는 산출물을 정의(유지보수에 필요한 산출물 중심)
7. 고객 및 사용자의 참여 부족
-
전형적인 상황
-
– 현업이 바쁜 관계로 프로젝트 참여가 제한적이며 보통 분석 및 테스트단계에 주로 참여
-
– 많은 경우 요구사항을 명확히 제시하지 못하며 개발자를 과신하는 경향이 있음
-
– 현업이 바쁜 관계로 프로젝트 참여가 제한적이며 보통 분석 및 테스트단계에 주로 참여
-
애자일 해법
-
– 프로젝트 초기에 제품책임자들을 선정하고 이들로 하여금 사용자 의견을 수렴
-
– 스프린트 단위로 사용자들의 피드백을 참조하여 개발
-
– 제품책임자들은 스프린트 계획과 리뷰에 참여하여 개발자들과 개발기간 동안 밀접하게 소통해야 함
-
– 고객과개발팀이활발하게소통할수있는프로젝트관리및커뮤니케이션도구제공
-
– 프로젝트 초기에 제품책임자들을 선정하고 이들로 하여금 사용자 의견을 수렴
8. 진척상황의 불투명성
• 전형적인 상황
– 주간단위로 팀원들의 업무 진행상황을 점검하고 있으나 팀원들이 현재 어떤 업무에 어려움이 있고 도움이 필요한지 실시간으로 파악하기는 어려움
• 애자일 해법
– 주간단위로 팀원들의 업무 진행상황을 점검하고 있으나 팀원들이 현재 어떤 업무에 어려움이 있고 도움이 필요한지 실시간으로 파악하기는 어려움
• 애자일 해법
-
– Visual Task Board를 활용하여 업무진행상황 및 이슈를 실시간으로 파악
-
– 데일리 스탠드업 미팅을 통하여 업무 진행현황과 장애요소, 이슈를 자연스럽게 파악하고 해결
2016년 4월 14일 목요일
제63회 SW공학 Technical 세미나 안내(4/28(목))
안녕하세요. 소프트웨어공학센터 입니다.
SW Quality
Insights 제 63회 소프트웨어 공학
Technicl 세미나 소식을 알려드립니다.
본 세미나는 국내외 SW전문가를 초빙하여 SW개발 관련 최신 기술 동향을
파악하고
개발과정에서의 경험을 공유하는 등 SW개발자와 관리자의 역량강화를 위하여
매월 지속적으로 개최하고 있습니다.
4월의 주제는 "AI 핵심기술 개발현황 및 기술 별 주요 내용과 주요 과제" 입니다.
무료로 진행되는 세미나이며, 소프트웨어공학센터의 홈페이지를 통하여
선착순으로 접수받고 있으니 여러분의 많은 관심과 참여를 바랍니다.
세미나 신청하기 →
2016년 3월 18일 금요일
제62회 SW공학 Technical 세미나 안내(3/31, 목요일)
안녕하세요. 소프트웨어공학센터입니다.
SW Quality Insights 제 62회 소프트웨어 공학 Technicl 세미나 소식을 알려드립니다.
본 세미나는 국내외 SW전문가를 초빙하여 SW개발 관련 최신 기술 동양을 파악하고
개발과정에서의 경험을 공유하는 등 SW개발자와 관리자의 역량강화를 위하여
매월 지속적으로 개최하고 있습니다.
이 달의 주제는 "IoT 보안방안에 대한 고찰과
Apache Spark를 활용한 실시간 데이터 처리 및 분석" 입니다.
무료로 진행되는 세미나이며, 소프트웨어공학센터의 홈페이지를 통해
선착순으로 접수받고 있으니 여러분의 많은 관심과 참여를 바랍니다.
2016년 2월 15일 월요일
제61회 SW공학 Technical 세미나 안내(2/25, 목요일)
SW Quality Insights 제 61회 소프트웨어 공학 Technicl 세미나에 여러분을 모십니다.
본 세미나는 국내외 SW전문가를 초빙하여 SW개발 관련 최신 기술 동양을 파악하고 개발과정에서의 경험을 공유하는 등 SW개발자와 관리자의 역량강화를 위해 매월 지속적으로 개최하고 있습니다.
2016년 1월 16일 토요일
제60회 SW공학 Technical 세미나 안내(1/28(목)
SW Quality Insights 제 60회 소프트웨어 공학 Technicl 세미나에 여러분을 모십니다.
본 세미나는 국내외 SW전문가를 초빙하여 SW개발 관련 최신 기술 동양을 파악하고 개발과정에서의 경험을 공유하는 등 SW개발자와 관리자의 역량강화를 위해 매월 지속적으로 개최하고 있습니다.
본 세미나는 국내외 SW전문가를 초빙하여 SW개발 관련 최신 기술 동양을 파악하고 개발과정에서의 경험을 공유하는 등 SW개발자와 관리자의 역량강화를 위해 매월 지속적으로 개최하고 있습니다.

2015년 12월 23일 수요일
2015년 12월 22일 화요일
Dev & ops cooperation at Flickr: "10 deploys per day"
Flickr의 John Allspaw(Ops head)와 Paul Hammond(Dev head)가
Velocity 2009년에서 발표한 영상
왜 DevOps를 해야 할까요?
DevOps는 소프트웨어 개발자와 정보 기술 전문가 간의 소통, 협업
및
통합을 강조하는 개발 방법론.
데브옵스는 소프트웨어 개발 조직과 운영 조직간의 상호 의존적 대응
이며 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을
목적으로 한다.
그럼, Amazon, Google, Netflix, Facebook, Twitter는 얼마나 자주 배포할까요?
그럼, Amazon, Google, Netflix, Facebook, Twitter는 얼마나 자주 배포할까요?
2015년 12월 21일 월요일
DevOps 소프트웨어 딜리버리 하기
DevOps Process
Endless Possibilities: DevOps can create an infinite loop of release and feedback for all your code and deployment targets.
FaceBook, Flickr, Netflix, Etsy은 어떻게 DevOps를 할까요?
배포 주기
- 매일 마이너 업데이트
- 메이저 업데이트 (매주 화요일 오후)
DeploymentAPipeline
출처: http://ieeexplore.ieee.org/xpl/article Details.js p?arnumbe r=644 9236
소스 버젼 관리
- 모든 FB 개발자는 Single stable branch에서 작업
- 따라서, long-lived branche들을 머징하는 데 시간 소비 하지 않도록 함
Tools
- 코드 리뷰: Phabricator (http://phabricator.org/)
- 테스트 자동화: Watir (http://watir.com/)
- 테스트 자동화: Selenium (https://github.com/seleniumhq/selenium)
- 성능 테스트: Perflab
커뮤니케이션
- 자체 IRC서버로 배포할 때 관련자들 다같이 IRC로 커뮤니케이션 (평균 700명)
- 개발자가 몇 분 내로 답변하지 않을 때는 해당 개발자 개발한 건 빼고 배포
서비스 모니터링
- 배포 이후에 트래픽의 변화, 자원 사용량, 프로덕션 환경의 각각 세그먼트들 등
- 심지어 Facebook에 대한 트윗들까지 모니터링함
2015년 12월 17일 목요일
2015년 12월 15일 화요일
업무 시스템에 기존 소스로 프로세스를 탑재하고 시스템을 매핑하여 관리하기
- 기 구축된 시스템 분석을 통한 설계 정보 생성과 분석 모델과의 연계를 통해 시스템 운영 기반 구축
- 시스템과 관련된 모든 정보는 통합 저장소에 탑재되어 관리
피드 구독하기:
글
(
Atom
)