Offcanvas

���������

‘짝퉁 애자일 기업’이 자신을 속이는 말 7가지

애자일 접근법을 취하고 있다고 생각하는가? 다시 한번 생각해보자. 단지 애자일 기법을 도입했다고 해서 소프트웨어 개발이 저절로 나아지지 않는다. 진짜 애자일 기업인 척하기 위해 자신을 속이고 있지 않은지 확인할 필요가 있다.   서당 개 3년이면 넘으면 풍월을 읊는다는 말이 요즘 시대에도 유효할까? 적어도 애자일 접근법은 그렇지 않다. 애자일 기법으로 만든 듯한 애플리케이션을 내놓고, 자신을 애자일 기업이라고 생각하더라도 진짜 애자일이 뭔지 아직 모를 수도 있다. 애자일은 하나의 개발 기법으로 알려져 있지만 문화나 철학에 가깝다. 따라서 애자일 기업을 만들거나 기존 기업에 애자일을 도입하는 것은 변혁을 요구한다. 하지만 다들 알다시피, 현실에서 기업은 변혁은커녕 조그마한 변화조차 이뤄내기 힘들다. 애자일을 하고 있다고 스스로를 속이고 있는, 아니 스스로를 속인지도 모르는 기업이 많을 수밖에 없는 이유다. 가짜 애자일 기업에게 흔히 나타나는 자기 기만의 목소리 7가지를 소개한다.   1.  '잘 모르지만 일단 하고 보자'  제일 먼저 CIO가 애자일에 대해 잘 모른다면 애자일이 제대로 되고 있을 리 만무하다. 애자일의 첫 번째 대중 서적이라고 할 수 있는 책 ‘린 스타트업’이 나온 지 10년이 지났음에도 기본 원칙, 요건 그리고 이점을 명확히 파악하지 못한 CIO가 있다. 스타트업 업계에서 시작한 애자일 기법은 모든 IT 기업이 도입해야 하는 새로운 개발 방식이라는 인식이 퍼졌다. 그러나 성과 관리 솔루션 업체 짓므허브(Gtmhub)에서 에반젤리즘 수석 부사장 제니 헤럴드는 많은 기업의 문화는 애자일과 맞지 않으며, 만약 진정한 애자일 기업이 되고 싶다면 기업 문화를 통째로 바꾸는 것을 각오해야 한다고 말했다. 즉, 진정한 애자일 기업이 되고자 한다면 기업의 리더부터 애자일을 제대로 이해 해야 한다. 헤럴드는 “애자일을 도입하고자 하는 기업의 CIO는 기본적인 가치와 목적부터 확실히 파악하길 바란다”라고 당부했...

애자일 개발 방법 애자일 기법 애자일 방법론 애자일 접근방식 스크럼 마스터 스크럼

2022.09.15

애자일 접근법을 취하고 있다고 생각하는가? 다시 한번 생각해보자. 단지 애자일 기법을 도입했다고 해서 소프트웨어 개발이 저절로 나아지지 않는다. 진짜 애자일 기업인 척하기 위해 자신을 속이고 있지 않은지 확인할 필요가 있다.   서당 개 3년이면 넘으면 풍월을 읊는다는 말이 요즘 시대에도 유효할까? 적어도 애자일 접근법은 그렇지 않다. 애자일 기법으로 만든 듯한 애플리케이션을 내놓고, 자신을 애자일 기업이라고 생각하더라도 진짜 애자일이 뭔지 아직 모를 수도 있다. 애자일은 하나의 개발 기법으로 알려져 있지만 문화나 철학에 가깝다. 따라서 애자일 기업을 만들거나 기존 기업에 애자일을 도입하는 것은 변혁을 요구한다. 하지만 다들 알다시피, 현실에서 기업은 변혁은커녕 조그마한 변화조차 이뤄내기 힘들다. 애자일을 하고 있다고 스스로를 속이고 있는, 아니 스스로를 속인지도 모르는 기업이 많을 수밖에 없는 이유다. 가짜 애자일 기업에게 흔히 나타나는 자기 기만의 목소리 7가지를 소개한다.   1.  '잘 모르지만 일단 하고 보자'  제일 먼저 CIO가 애자일에 대해 잘 모른다면 애자일이 제대로 되고 있을 리 만무하다. 애자일의 첫 번째 대중 서적이라고 할 수 있는 책 ‘린 스타트업’이 나온 지 10년이 지났음에도 기본 원칙, 요건 그리고 이점을 명확히 파악하지 못한 CIO가 있다. 스타트업 업계에서 시작한 애자일 기법은 모든 IT 기업이 도입해야 하는 새로운 개발 방식이라는 인식이 퍼졌다. 그러나 성과 관리 솔루션 업체 짓므허브(Gtmhub)에서 에반젤리즘 수석 부사장 제니 헤럴드는 많은 기업의 문화는 애자일과 맞지 않으며, 만약 진정한 애자일 기업이 되고 싶다면 기업 문화를 통째로 바꾸는 것을 각오해야 한다고 말했다. 즉, 진정한 애자일 기업이 되고자 한다면 기업의 리더부터 애자일을 제대로 이해 해야 한다. 헤럴드는 “애자일을 도입하고자 하는 기업의 CIO는 기본적인 가치와 목적부터 확실히 파악하길 바란다”라고 당부했...

2022.09.15

스크럼에 ‘디자인 사고’ 접목하기 A to Z

애자일 개발 팀에는 여러 개발자, QA 자동화 엔지니어, 사이트 신뢰성 엔지니어가 참여하기 마련이다. 이들에게 업무를 전달하는 출발점은 사용자 스토리를 정의하고, 사용자 스토리가 스프린트 내에서 완수되도록 하는 것이다.  때때로 사용자 스토리는 데이터 통합 구성, 마이크로서비스 API 코딩, 기술 부채 해결, 애플리케이션 성능 개선 같은 ‘백엔드’ 측면의 구현을 요구한다. 그러나 이는 여전히 사용자 스토리이다. 구현이 비즈니스 가치를 제공하기 때문이다. 단 제품 소유자는 기술적인 기준으로 타깃 사용자의 경험을 규정할 수 있다. 기능이나 사용자 스토리가 디자인이 필요한 ‘프론트엔드’ 구현을 요구하는 경우가 있다. 이 때 애자일 팀은 디자인 사고, 와이어프레이밍, 사용자 경험, 디자인 스펙을 요건에 반영할 시기와 방법을 결정해야 한다. 애자일 팀이 사용자 경험과 디자인 스펙을 규정하는 방법, 시기에 대한 ‘답’은 하나가 아니다. 이를 감안하는 것이 애플리케이션과 워크플로우, 모바일 앱의 성공에 아주 중요하다. 궁극적으로 고객 만족과 이용 편의성을 보장하는 것이 비즈니스 결과에 큰 영향을 주기 때문이다.   문제 진술(problem statement)을 정의하는 애자일 사용자 스토리 디자인 사고와 애자일 방법론이 어떻게 교차하는지 알아보기 위해, 먼저 제품 소유자가 애자일 팀의 백로그에서 요구사항을 포착하는 방법을 살펴보면 다음과 같다. 대체적으로 제품 소유자는 목표를 서사(epic)와 기능, 사용자 스토리로 구성된 계층으로 세분화한다. 사용자 스토리는 다음과 같은 질문에 답하는 데 도움을 준다. • 고객, 또는 최종 사용자는? • 다뤄야 할 문제나 기회는? • 구현을 통해 달성하려 하는 혜택이나 이점은? • 고객에게 중요한 이유는? • 이 사용자 스토리에 대해 ‘완료’를 규정하는 허용 기준은? 여기에서 사용자 스토리가 고객 관점의 문제에 대한 진술과 기회를 정의하는 것을 알 수 있다. 개발 팀에게 사용자 스토리에서 정의된 수용 기준...

스크럼 애자일 디자인 씽킹 디자인 사고

2021.05.11

애자일 개발 팀에는 여러 개발자, QA 자동화 엔지니어, 사이트 신뢰성 엔지니어가 참여하기 마련이다. 이들에게 업무를 전달하는 출발점은 사용자 스토리를 정의하고, 사용자 스토리가 스프린트 내에서 완수되도록 하는 것이다.  때때로 사용자 스토리는 데이터 통합 구성, 마이크로서비스 API 코딩, 기술 부채 해결, 애플리케이션 성능 개선 같은 ‘백엔드’ 측면의 구현을 요구한다. 그러나 이는 여전히 사용자 스토리이다. 구현이 비즈니스 가치를 제공하기 때문이다. 단 제품 소유자는 기술적인 기준으로 타깃 사용자의 경험을 규정할 수 있다. 기능이나 사용자 스토리가 디자인이 필요한 ‘프론트엔드’ 구현을 요구하는 경우가 있다. 이 때 애자일 팀은 디자인 사고, 와이어프레이밍, 사용자 경험, 디자인 스펙을 요건에 반영할 시기와 방법을 결정해야 한다. 애자일 팀이 사용자 경험과 디자인 스펙을 규정하는 방법, 시기에 대한 ‘답’은 하나가 아니다. 이를 감안하는 것이 애플리케이션과 워크플로우, 모바일 앱의 성공에 아주 중요하다. 궁극적으로 고객 만족과 이용 편의성을 보장하는 것이 비즈니스 결과에 큰 영향을 주기 때문이다.   문제 진술(problem statement)을 정의하는 애자일 사용자 스토리 디자인 사고와 애자일 방법론이 어떻게 교차하는지 알아보기 위해, 먼저 제품 소유자가 애자일 팀의 백로그에서 요구사항을 포착하는 방법을 살펴보면 다음과 같다. 대체적으로 제품 소유자는 목표를 서사(epic)와 기능, 사용자 스토리로 구성된 계층으로 세분화한다. 사용자 스토리는 다음과 같은 질문에 답하는 데 도움을 준다. • 고객, 또는 최종 사용자는? • 다뤄야 할 문제나 기회는? • 구현을 통해 달성하려 하는 혜택이나 이점은? • 고객에게 중요한 이유는? • 이 사용자 스토리에 대해 ‘완료’를 규정하는 허용 기준은? 여기에서 사용자 스토리가 고객 관점의 문제에 대한 진술과 기회를 정의하는 것을 알 수 있다. 개발 팀에게 사용자 스토리에서 정의된 수용 기준...

2021.05.11

‘교묘히 방해하기’··· 애자일화에 저항하는 7가지 책략

애자일을 향해 진군하라는 북소리가 커지고 있다. 그러나 애자일로의 변화가 싫거나 불편할 수 있다. 여기 애자일로의 변화가 실패로 귀결되도록 만드는 기똥찬 방법들이 있다. 애자일(Agile)이 본격화되기 시작한지 10년도 넘었다. <애자일 선언>이 나타난 시기가 거의 20년 전이다. 애자일 선언으로 공식화되기 오래 전에도 애자일스러운 기법이 사용되기도 했었다. 그러나, 여전히 애자일을 저지하고자 하는 저항 세력이 있다. 혹시 여러분이 그런 세력에 속해 있는가? ‘애자일화’의 압력을 받는 가운데 소행성의 충돌을 기다리는 공룡같은 기분을 느끼고 있는가? 여기 방법이 있다. 다음의 검증된 7가지 방법으로 공세를 취한다면 소속 회사의 발전과 변화를 방해한다는 비판을 듣지 않고도 IT조직에 애자일이 실행되는 것을 확실히 방지할 수 있을 것이다.   1. 애자일이라 부를 것. 무계획적으로 만들 것 다음 번에 프로젝트를 시작할 때는 프로젝트 관리자가 ‘애자일 방식’으로 실행해야 한다고 주장하라. 팀원 전원이 매일 아침 프로젝트를 나름대로 전진시키기 위해 그 날 할 일을 알아내는 식이다. 테스트는 어떻게 하느냐고? 팀이 어떤 기능을 테스트할 준비가 되면, 그 기능을 업무 담당 직원이 내일 써야 한다고 제품 소유자에게 오늘 알려라. 내일 기능이 준비되지 않아도 괜찮다. 다음 번 스프린트로 미루면 되니까. 프로젝트의 일정이 지켜지지 않는다고 제품 소유자가 불만을 제기할 경우에는 ‘애자일 프로젝트’에는 일정이 없다고 해명하면 멋지게 해결된다. 어차피 애자일은 ‘무계획’이라는 뜻 아닌가? 2. 아키텍처를 무시할 것 프로젝트 초반에 애플리케이션 아키텍처를 정의하느라고 시간을 낭비하지 마라. 애자일이 요건의 지속적인 진화를 의미한다면 애플리케이션 아키텍처 역시 지속적으로 진화해야 하지 않겠는가? 그러니, 추상적인 원칙을 지킬 것을 고집하면서 개발자의 창의성을 제한하지 않도록 하자. 그 대신 개발자에게 힘을 실어주어야 한다. 개발자 본인이 원하는 방식으로...

애자일 워터폴 변화 관리 스크럼 SAFe 저항

2021.01.26

애자일을 향해 진군하라는 북소리가 커지고 있다. 그러나 애자일로의 변화가 싫거나 불편할 수 있다. 여기 애자일로의 변화가 실패로 귀결되도록 만드는 기똥찬 방법들이 있다. 애자일(Agile)이 본격화되기 시작한지 10년도 넘었다. <애자일 선언>이 나타난 시기가 거의 20년 전이다. 애자일 선언으로 공식화되기 오래 전에도 애자일스러운 기법이 사용되기도 했었다. 그러나, 여전히 애자일을 저지하고자 하는 저항 세력이 있다. 혹시 여러분이 그런 세력에 속해 있는가? ‘애자일화’의 압력을 받는 가운데 소행성의 충돌을 기다리는 공룡같은 기분을 느끼고 있는가? 여기 방법이 있다. 다음의 검증된 7가지 방법으로 공세를 취한다면 소속 회사의 발전과 변화를 방해한다는 비판을 듣지 않고도 IT조직에 애자일이 실행되는 것을 확실히 방지할 수 있을 것이다.   1. 애자일이라 부를 것. 무계획적으로 만들 것 다음 번에 프로젝트를 시작할 때는 프로젝트 관리자가 ‘애자일 방식’으로 실행해야 한다고 주장하라. 팀원 전원이 매일 아침 프로젝트를 나름대로 전진시키기 위해 그 날 할 일을 알아내는 식이다. 테스트는 어떻게 하느냐고? 팀이 어떤 기능을 테스트할 준비가 되면, 그 기능을 업무 담당 직원이 내일 써야 한다고 제품 소유자에게 오늘 알려라. 내일 기능이 준비되지 않아도 괜찮다. 다음 번 스프린트로 미루면 되니까. 프로젝트의 일정이 지켜지지 않는다고 제품 소유자가 불만을 제기할 경우에는 ‘애자일 프로젝트’에는 일정이 없다고 해명하면 멋지게 해결된다. 어차피 애자일은 ‘무계획’이라는 뜻 아닌가? 2. 아키텍처를 무시할 것 프로젝트 초반에 애플리케이션 아키텍처를 정의하느라고 시간을 낭비하지 마라. 애자일이 요건의 지속적인 진화를 의미한다면 애플리케이션 아키텍처 역시 지속적으로 진화해야 하지 않겠는가? 그러니, 추상적인 원칙을 지킬 것을 고집하면서 개발자의 창의성을 제한하지 않도록 하자. 그 대신 개발자에게 힘을 실어주어야 한다. 개발자 본인이 원하는 방식으로...

2021.01.26

‘변화했을 뿐 여전히 유효한 이야기’··· 고전 IT 원칙 11가지

기술은 빠르게 변화하고 있다. 하지만 그 유행 아래에는 여전히 원초적이고 근본적인 IT 원칙이 남아있다. 오래됐지만 그럼에도 현대화해 적용할 수 있는 IT 원칙들을 소개한다.    “많은 것이 같을수록, 더욱더 많은 것이 변한다(The more things stay the same, the more they change).” 원래 격언과 앞뒤가 바뀌긴 했지만 이는 ‘IT’라면 새겨들어야 할 대목이다. 이를테면 IT가 전자정보처리(EDP)였고, 프로그래머가 데이터센터를 지키는 문지기에 불과했던 초기 시절로부터 변한 것은 그리 많지 않다. 하지만 그러면서도 모든 것이 변했다.  다행스럽게도, IT의 초창기 시절에 나온 기본적인 원칙은 여전히 유효하다. 다만 현대화됐을 뿐이다. 여기서는 차세대 IT를 구현하는 데 있어 길잡이가 될 11가지 고전적인 원칙과 이들이 변한 부분들을 살펴본다.    1. 기술이 얼마나 좋은지는 결코 중요하지 않다  - 낡은 원칙: “IBM을 사서 해고당한 사람은 없었다.” - 새로운 변화: 오픈소스가 똑같은 이점을 제공할 수 있다   기업 입장에서 기술 구매는 장기적인 차원의 투자다. 따라서 이에 부합해 공급업체도 장기적인 지원을 약속해주길 바란다. 이러한 맥락에서 IT는 안전을 위해 ‘대형 업체’에서 기술을 구매하곤 했다. 지금은 어떠한가? 오픈소스가 그만큼이나 안전할 뿐만 아니라, 심지어는 IBM이나 다른 대형 업체에서 오픈소스를 얻을 수도 있다.  물론 모든 오픈소스가 충분한 지원 기반을 갖추고 있는 것은 아니다. 예를 들면 만약 PHP(Hypertext Preprocessor)로 필요한 기능을 모두 제공하는데, 보안 취약점이 많은 자바를 거들떠보겠는가? 물론 자바는 세계 최대의 소프트웨어 기업 가운데 하나인 오라클이 지원한다(아마도 ‘제공한다’라는 말이 더 정확한 듯하다).  -> IBM 기고 | 오픈소스 전환시 고려해야...

IT CIO 기술 구매 오픈소스 보안 위협 소프트웨어 테스트 회귀 테스트 스트레스 테스트 데이터센터 클라우드 워터폴 애자일 스크럼 Saas

2020.12.07

기술은 빠르게 변화하고 있다. 하지만 그 유행 아래에는 여전히 원초적이고 근본적인 IT 원칙이 남아있다. 오래됐지만 그럼에도 현대화해 적용할 수 있는 IT 원칙들을 소개한다.    “많은 것이 같을수록, 더욱더 많은 것이 변한다(The more things stay the same, the more they change).” 원래 격언과 앞뒤가 바뀌긴 했지만 이는 ‘IT’라면 새겨들어야 할 대목이다. 이를테면 IT가 전자정보처리(EDP)였고, 프로그래머가 데이터센터를 지키는 문지기에 불과했던 초기 시절로부터 변한 것은 그리 많지 않다. 하지만 그러면서도 모든 것이 변했다.  다행스럽게도, IT의 초창기 시절에 나온 기본적인 원칙은 여전히 유효하다. 다만 현대화됐을 뿐이다. 여기서는 차세대 IT를 구현하는 데 있어 길잡이가 될 11가지 고전적인 원칙과 이들이 변한 부분들을 살펴본다.    1. 기술이 얼마나 좋은지는 결코 중요하지 않다  - 낡은 원칙: “IBM을 사서 해고당한 사람은 없었다.” - 새로운 변화: 오픈소스가 똑같은 이점을 제공할 수 있다   기업 입장에서 기술 구매는 장기적인 차원의 투자다. 따라서 이에 부합해 공급업체도 장기적인 지원을 약속해주길 바란다. 이러한 맥락에서 IT는 안전을 위해 ‘대형 업체’에서 기술을 구매하곤 했다. 지금은 어떠한가? 오픈소스가 그만큼이나 안전할 뿐만 아니라, 심지어는 IBM이나 다른 대형 업체에서 오픈소스를 얻을 수도 있다.  물론 모든 오픈소스가 충분한 지원 기반을 갖추고 있는 것은 아니다. 예를 들면 만약 PHP(Hypertext Preprocessor)로 필요한 기능을 모두 제공하는데, 보안 취약점이 많은 자바를 거들떠보겠는가? 물론 자바는 세계 최대의 소프트웨어 기업 가운데 하나인 오라클이 지원한다(아마도 ‘제공한다’라는 말이 더 정확한 듯하다).  -> IBM 기고 | 오픈소스 전환시 고려해야...

2020.12.07

기고|대규모 ERP 프로젝트에 애자일 활용하려면?··· 6가지 과제와 해법

ERP같은 대규모 프로젝트에 애자일을 도입하기 위해서는 넘어야 할 난관들이 있다.  오랫동안 애자일은 IT 업계의 표준 개발 방법론이었으며 많은 기업에 도입돼 성공적으로 활용된 바 있다. 애자일을 통해 기업들이 덕을 보게 되면서, 점점 더 큰 작업에도 애자일을 도입하려는 경향이 나타났다. 심지어 (상당한 분량의 통합 작업 때문에 복잡하기로 악명높은) ERP 구축 프로젝트에 애자일을 응용하려는 시도도 나타나고 있다. 그러나 프로젝트의 규모가 커지면 애자일의 혜택이 소규모 프로젝트만큼 쉽게 나타나지 않는 것도 사실이다.    그간의 경험과 연구를 통해, 필자는 ERP 구축에 애자일을 효과적으로 활용하기 위해 넘어서야 할 6가지 난관과 그에 대한 조치를 아래와 같이 정리했다.  1. 주요 결정 거버넌스  애자일 프로젝트의 성공을 좌우하는 중요한 요인은 팀이다. 정예화되고 헌신적인 팀이 필요하며 팀 구성원은 고도로 숙련되고 연결돼 있어야 한다. 또 이들 구성원들에게 프로젝트 전반에 걸쳐 핵심 의사결정을 내릴 수 있는 권한이 주어져야 한다. 대규모 프로젝트에서는  각 팀이 내려야 할 의사 결정의 개수가 증가하며, 이로 인해 잘못된 결정을 내리는 경우도 늘어난다. 조직별 유불리에 따라 각 결정의 복잡성이 높아지기도 한다. 프로젝트에 참여한 팀과 결과물이 많을수록 모든 팀을 정렬시키는 작업은 어렵고 시간도 많이 소요된다.  또한 이해당사자 스코프도 증가하기 때문에 합의하는 데 더 많은 시간이 들 수 있다. 의사결정이 복잡해지고 교차기능적으로 이뤄지면 애자일 사고방식은 어울리지 않는 경향이 있다. 때문에 프로젝트의 규모가 클수록 애자일 방법론은 적용하기가 까다로워진다. 이 문제를 해결하려면 릴리즈 트레인 엔지니어(Release Train Engineers)가 주요 책임과 권한을 갖고 있어야 한다. 즉, 그가 핵심 의사결정 사안을 파악하고, 조기에 팀원에게 공유하며, 핵심 의사결정이 적시에 이루어질 수 ...

애자일 워터폴 ERP 백로그 스크럼 프로젝트 관리

2020.10.06

ERP같은 대규모 프로젝트에 애자일을 도입하기 위해서는 넘어야 할 난관들이 있다.  오랫동안 애자일은 IT 업계의 표준 개발 방법론이었으며 많은 기업에 도입돼 성공적으로 활용된 바 있다. 애자일을 통해 기업들이 덕을 보게 되면서, 점점 더 큰 작업에도 애자일을 도입하려는 경향이 나타났다. 심지어 (상당한 분량의 통합 작업 때문에 복잡하기로 악명높은) ERP 구축 프로젝트에 애자일을 응용하려는 시도도 나타나고 있다. 그러나 프로젝트의 규모가 커지면 애자일의 혜택이 소규모 프로젝트만큼 쉽게 나타나지 않는 것도 사실이다.    그간의 경험과 연구를 통해, 필자는 ERP 구축에 애자일을 효과적으로 활용하기 위해 넘어서야 할 6가지 난관과 그에 대한 조치를 아래와 같이 정리했다.  1. 주요 결정 거버넌스  애자일 프로젝트의 성공을 좌우하는 중요한 요인은 팀이다. 정예화되고 헌신적인 팀이 필요하며 팀 구성원은 고도로 숙련되고 연결돼 있어야 한다. 또 이들 구성원들에게 프로젝트 전반에 걸쳐 핵심 의사결정을 내릴 수 있는 권한이 주어져야 한다. 대규모 프로젝트에서는  각 팀이 내려야 할 의사 결정의 개수가 증가하며, 이로 인해 잘못된 결정을 내리는 경우도 늘어난다. 조직별 유불리에 따라 각 결정의 복잡성이 높아지기도 한다. 프로젝트에 참여한 팀과 결과물이 많을수록 모든 팀을 정렬시키는 작업은 어렵고 시간도 많이 소요된다.  또한 이해당사자 스코프도 증가하기 때문에 합의하는 데 더 많은 시간이 들 수 있다. 의사결정이 복잡해지고 교차기능적으로 이뤄지면 애자일 사고방식은 어울리지 않는 경향이 있다. 때문에 프로젝트의 규모가 클수록 애자일 방법론은 적용하기가 까다로워진다. 이 문제를 해결하려면 릴리즈 트레인 엔지니어(Release Train Engineers)가 주요 책임과 권한을 갖고 있어야 한다. 즉, 그가 핵심 의사결정 사안을 파악하고, 조기에 팀원에게 공유하며, 핵심 의사결정이 적시에 이루어질 수 ...

2020.10.06

칼럼ㅣ개발팀을 ‘린(Lean)’하게 운영하는 4가지 방법

오늘날 IT 리더들은 코로나19 사태로 인해 많은 과제를 안게 됐다. 이를테면 예산을 늘리거나 인력을 충원하지 않고 새로운 가치를 계속 추구해야 하는 것이다. 여기서는 '린(Lean)한 방식'의 새로운 모습을 살펴본다.   적은 리소스로 더 많은 일을 하는 것(Doing more with less)은 조직들의 오랜 목표였다. 그러나 코로나19 사태로 업계 풍경이 바뀌었다. IT 시장분석기관 IDC는 올해 업계 리더들이 기술 구매와 새로운 계획 수립을 보류하면서 IT 부문 지출은 2.7% 하락할 것으로 예상했다. 또한 IT 예산 축소, 기술 프로젝트 지연, 채용 동결, 해고와 같은 이슈로 신규 채용이 재개될 가능성도 요원하다. 이에 따라 '적은 리소스로 적은 일(Doing less with less)'을 하는 추세가 코로나19 시대의 뉴노멀로 빠르게 자리잡고 있다. 오늘날 기술 책임자들은 무거운 부담을 맞닥뜨리고 있다. 인력을 충원하거나 예산을 늘리지 않고도 새로운 가치를 추진하고 혁신을 일으켜야만 한다는 것이다.   이러한 상황에서 개발팀이 성과를 내려면 일하는 방식을 바꿔야 한다. 2008년 경기침체 당시 IT 조직은 인력과 자원을 해외에서 아웃소싱(오프쇼어링)하면서 소위 ‘린’해질 수 있었다. 하지만 코로나19 사태에서는 오프쇼어링 자체는 답이 아닐 수 있다. 대신 분산된 원격 오프쇼어링 팀들의 ‘린’한 업무 방식을 모방하는 게 도움이 될 수 있다. 다시 말해, 프로젝트에 걸쳐 자원을 공유하고, 다양한 기술과 경험을 갖춘 전문가의 자문을 구하며, 협업용 툴을 활용하는 것이다. 현재 개발팀만으로 성과를 최대화하고 싶다면 아래의 4가지 시사점을 참고하라. 1. 팀 내 개발자와 테스터 인력 비율을 재조정하라 개발자와 테스터 비율을 2대 1로 유지 중인 조직이라면, 오프쇼어링 팀처럼 인원 비율을 3대 1로 조정해볼 수 있다. 애자일 방법론을 활용한다면 속도와 스프린트 측면에서 개발자 비율을 늘릴 수 있다. 테스터를 팀에 포함...

개발 개발팀 코로나19 스크럼

2020.08.11

오늘날 IT 리더들은 코로나19 사태로 인해 많은 과제를 안게 됐다. 이를테면 예산을 늘리거나 인력을 충원하지 않고 새로운 가치를 계속 추구해야 하는 것이다. 여기서는 '린(Lean)한 방식'의 새로운 모습을 살펴본다.   적은 리소스로 더 많은 일을 하는 것(Doing more with less)은 조직들의 오랜 목표였다. 그러나 코로나19 사태로 업계 풍경이 바뀌었다. IT 시장분석기관 IDC는 올해 업계 리더들이 기술 구매와 새로운 계획 수립을 보류하면서 IT 부문 지출은 2.7% 하락할 것으로 예상했다. 또한 IT 예산 축소, 기술 프로젝트 지연, 채용 동결, 해고와 같은 이슈로 신규 채용이 재개될 가능성도 요원하다. 이에 따라 '적은 리소스로 적은 일(Doing less with less)'을 하는 추세가 코로나19 시대의 뉴노멀로 빠르게 자리잡고 있다. 오늘날 기술 책임자들은 무거운 부담을 맞닥뜨리고 있다. 인력을 충원하거나 예산을 늘리지 않고도 새로운 가치를 추진하고 혁신을 일으켜야만 한다는 것이다.   이러한 상황에서 개발팀이 성과를 내려면 일하는 방식을 바꿔야 한다. 2008년 경기침체 당시 IT 조직은 인력과 자원을 해외에서 아웃소싱(오프쇼어링)하면서 소위 ‘린’해질 수 있었다. 하지만 코로나19 사태에서는 오프쇼어링 자체는 답이 아닐 수 있다. 대신 분산된 원격 오프쇼어링 팀들의 ‘린’한 업무 방식을 모방하는 게 도움이 될 수 있다. 다시 말해, 프로젝트에 걸쳐 자원을 공유하고, 다양한 기술과 경험을 갖춘 전문가의 자문을 구하며, 협업용 툴을 활용하는 것이다. 현재 개발팀만으로 성과를 최대화하고 싶다면 아래의 4가지 시사점을 참고하라. 1. 팀 내 개발자와 테스터 인력 비율을 재조정하라 개발자와 테스터 비율을 2대 1로 유지 중인 조직이라면, 오프쇼어링 팀처럼 인원 비율을 3대 1로 조정해볼 수 있다. 애자일 방법론을 활용한다면 속도와 스프린트 측면에서 개발자 비율을 늘릴 수 있다. 테스터를 팀에 포함...

2020.08.11

칼럼ㅣ백로그 관리부터 정렬까지··· 프론트라인 관리자가 알아야 할 것

프론트라인 관리자가 되기란 쉽지 않다. 특히 ‘엔지니어’에서 ‘프론트라인 관리자’로 승진한 경우라면 깨닫는 사실이 있다. 사실상 승진한 것이 아니라 완전히 다른 업무를 맡게 됐다는 것이다. 이 전환에서 가장 어려운 과제는 엔지니어들의 요구를 수용하면서도 기업을 대표하는 역할을 해내야 한다는 점이다.    백로그(Backlog) 조직 구성원이라면 누구나 기업의 니즈를 이해해야 한다. 프론트라인 관리자가 기업을 대표하는 역할이라고 생각할지도 모른다. 하지만 프론트라인 관리자만 ‘그런 사고방식’을 가져서는 안 된다. 엔지니어의 임무는 단순히 코드 작성이 아니다. 바로 기업의 니즈 해결이다. 2019 데브옵스 현황(State of DevOps) 보고서에 따르면 소프트웨어를 잘 전달하는 조직은 목표를 달성할 가능성이 2배 이상 높다.  즉 기업의 니즈에 부응하고자 하는 사고방식이 조직 전반에 스며들어 있어야 한다. 그러나 만약 비즈니스 요구가 많다면? 해야 할 일이 많다면? 무엇부터 먼저 해야 하는지 어떻게 알 수 있을까?  애자일 소프트웨어 개발을 하고 있는 팀이라면 그 해답은 백로그에서 찾을 수 있다. ‘백로그’란 한 팀이 일정 기간 또는 일정 시간 안에 해야 할 모든 업무를 작성한 문서이다. 이를테면 업무 개선 아이디어부터 제품 개발 관련 업무, 회고, 학습 리뷰, 사후 분석까지 모두 백로그에 들어간다. 이로 인해 백로그가 엄청나게 길어질 수 있다. 그렇다면 어떻게 해야 할까? 포기(Give up) 여기서의 ‘포기’는 두 손 들고 패배를 선언하면서 물러나라는 뜻이 아니다. 백로그 내의 모든 업무를 완수하겠다는 생각을 팀 차원에서 포기해야 한다는 뜻이다. 모든 아이디어, 모든 프로젝트가 백로그에 포함되기 마련이다. 그러나 우선순위를 비롯해 기술, 계획은 모두 변화한다. 무한한 자원과 시간이 있지 않는 한, 결코 백로그에 있는 모든 업무를 완료할 수 없다. 즉 첫 번째 단계는 모든 업무를 해내겠다는 생각을...

프론트라인 관리자 엔지니어 백로그 정렬 애자일 스프레드시트 우선순위 스크럼 OKR V2MOM 세일즈포스

2020.07.07

프론트라인 관리자가 되기란 쉽지 않다. 특히 ‘엔지니어’에서 ‘프론트라인 관리자’로 승진한 경우라면 깨닫는 사실이 있다. 사실상 승진한 것이 아니라 완전히 다른 업무를 맡게 됐다는 것이다. 이 전환에서 가장 어려운 과제는 엔지니어들의 요구를 수용하면서도 기업을 대표하는 역할을 해내야 한다는 점이다.    백로그(Backlog) 조직 구성원이라면 누구나 기업의 니즈를 이해해야 한다. 프론트라인 관리자가 기업을 대표하는 역할이라고 생각할지도 모른다. 하지만 프론트라인 관리자만 ‘그런 사고방식’을 가져서는 안 된다. 엔지니어의 임무는 단순히 코드 작성이 아니다. 바로 기업의 니즈 해결이다. 2019 데브옵스 현황(State of DevOps) 보고서에 따르면 소프트웨어를 잘 전달하는 조직은 목표를 달성할 가능성이 2배 이상 높다.  즉 기업의 니즈에 부응하고자 하는 사고방식이 조직 전반에 스며들어 있어야 한다. 그러나 만약 비즈니스 요구가 많다면? 해야 할 일이 많다면? 무엇부터 먼저 해야 하는지 어떻게 알 수 있을까?  애자일 소프트웨어 개발을 하고 있는 팀이라면 그 해답은 백로그에서 찾을 수 있다. ‘백로그’란 한 팀이 일정 기간 또는 일정 시간 안에 해야 할 모든 업무를 작성한 문서이다. 이를테면 업무 개선 아이디어부터 제품 개발 관련 업무, 회고, 학습 리뷰, 사후 분석까지 모두 백로그에 들어간다. 이로 인해 백로그가 엄청나게 길어질 수 있다. 그렇다면 어떻게 해야 할까? 포기(Give up) 여기서의 ‘포기’는 두 손 들고 패배를 선언하면서 물러나라는 뜻이 아니다. 백로그 내의 모든 업무를 완수하겠다는 생각을 팀 차원에서 포기해야 한다는 뜻이다. 모든 아이디어, 모든 프로젝트가 백로그에 포함되기 마련이다. 그러나 우선순위를 비롯해 기술, 계획은 모두 변화한다. 무한한 자원과 시간이 있지 않는 한, 결코 백로그에 있는 모든 업무를 완료할 수 없다. 즉 첫 번째 단계는 모든 업무를 해내겠다는 생각을...

2020.07.07

'프로젝트 관리도 원격으로' PM을 위한 8가지 팁

IT프로젝트 관리도 재택근무로 가능하다. 프로젝트팀의 업무 산출물과 생산성을 원격으로 조율하기 위해 베테랑 원격 프로젝트 관리자는 가상 환경에서 실행할 수 있는 팁을 제시했다.   최근 몇 주 동안, 우리는 불가능하다고 생각했던 업적을 해냈다. 사전 통지, 계획이나 교육 없이도 누군가는 직접 보지 못하는 원격 팀의 프로젝트 관리자가 됐다. 원격 관리는 통신 및 중재 기술, 디지털 도구, 우수한 계획 및 시각화가 요구되는 전문 기술이다. 완전히 구축되면 원격 팀은 사무실에서 일하는 팀과 다르게 운영된다. 그 팀은 심지어 다른 사람들, 즉 원격 직업을 추구하고 선택한 사람들로 꾸려지게 될 것이다.   모든 사람이 재택 환경에서 잘 해 나가는 것은 아니다. 내셔널 리서치 그룹(National Research Group)의 최근 연구에 따르면, Z세대의 51%는 재택근무 시 산만해지고 41%는 필요한 자원이 없다고 말했다. 깃랩(GitLab)의 제품 운영 책임자인 케니 존스톤도 “원격근무에는 장단점이 있다”면서 내셔널 리서치 그룹 연구 결과에 동의했다. 깃랩은 65개국 이상에 팀을 가지고 있는 완전히 원격에 적합한 회사다. 존스톤은 “우리가 고용한 사람들은 그것을 즐기고 우리는 ‘한 명에 대한 관리자’라고 부르는 원칙에 따라 스스로 선택하는데, 이는 사람들이 능동적으로 행동하고, 그들 자신의 일을 정의하며, 그들 자신의 프로젝트에 책임을 갖기를 기대한다는 의미다”라고 설명했다. 원격 팀을 관리하는 것이 처음이라면, 몇 가지 기술을 연마해야 할 것이다. 이를 위해 나는 수년 동안 원격 팀을 관리해 온 프로젝트 매니저들과 이야기를 나눴다. 여기 그들의 충고가 있다. 의도를 가지고 커뮤니케이션하라 필자가 이야기한 모든 사람은 원격 통신이 직접적인 상호작용과는 다르다는 점에 동의했다. 내시(Nash)의 공동창업자이자 CTO인 이던 패스트는 “한 사무실에서 동료들과 이야기하는 가볍고 미묘하며 섬세한 방법들이 모두 있다”라고 말했다. 패스트는 전 ...

CIO 깃랩 스크럼 슬랙 프로젝트 관리자 프로젝트 매니저 원격관리 화상회의 문화 프로젝트 관리 재택근무 생산성 PM 원격근무 내셔널 리서치 그룹

2020.05.06

IT프로젝트 관리도 재택근무로 가능하다. 프로젝트팀의 업무 산출물과 생산성을 원격으로 조율하기 위해 베테랑 원격 프로젝트 관리자는 가상 환경에서 실행할 수 있는 팁을 제시했다.   최근 몇 주 동안, 우리는 불가능하다고 생각했던 업적을 해냈다. 사전 통지, 계획이나 교육 없이도 누군가는 직접 보지 못하는 원격 팀의 프로젝트 관리자가 됐다. 원격 관리는 통신 및 중재 기술, 디지털 도구, 우수한 계획 및 시각화가 요구되는 전문 기술이다. 완전히 구축되면 원격 팀은 사무실에서 일하는 팀과 다르게 운영된다. 그 팀은 심지어 다른 사람들, 즉 원격 직업을 추구하고 선택한 사람들로 꾸려지게 될 것이다.   모든 사람이 재택 환경에서 잘 해 나가는 것은 아니다. 내셔널 리서치 그룹(National Research Group)의 최근 연구에 따르면, Z세대의 51%는 재택근무 시 산만해지고 41%는 필요한 자원이 없다고 말했다. 깃랩(GitLab)의 제품 운영 책임자인 케니 존스톤도 “원격근무에는 장단점이 있다”면서 내셔널 리서치 그룹 연구 결과에 동의했다. 깃랩은 65개국 이상에 팀을 가지고 있는 완전히 원격에 적합한 회사다. 존스톤은 “우리가 고용한 사람들은 그것을 즐기고 우리는 ‘한 명에 대한 관리자’라고 부르는 원칙에 따라 스스로 선택하는데, 이는 사람들이 능동적으로 행동하고, 그들 자신의 일을 정의하며, 그들 자신의 프로젝트에 책임을 갖기를 기대한다는 의미다”라고 설명했다. 원격 팀을 관리하는 것이 처음이라면, 몇 가지 기술을 연마해야 할 것이다. 이를 위해 나는 수년 동안 원격 팀을 관리해 온 프로젝트 매니저들과 이야기를 나눴다. 여기 그들의 충고가 있다. 의도를 가지고 커뮤니케이션하라 필자가 이야기한 모든 사람은 원격 통신이 직접적인 상호작용과는 다르다는 점에 동의했다. 내시(Nash)의 공동창업자이자 CTO인 이던 패스트는 “한 사무실에서 동료들과 이야기하는 가볍고 미묘하며 섬세한 방법들이 모두 있다”라고 말했다. 패스트는 전 ...

2020.05.06

애자일·데브옵스는 '다다익선'··· 전사적 확장 가이드

많은 기업이 애자일과 데브옵스를 디지털 트랜스포메이션 여정의 핵심 단계로 간주한다. 그러나 소규모 팀 단위에서만 변화가 진행됨에 따라 그 효과가 제한적인 경우가 많다. 애자일과 데브옵스를 전사적으로 도입한다면, 더 큰 규모의 프로세스를 개선하여 상당한 이익을 얻을 수 있다.   애자일은 소프트웨어 최종 사용자를 비롯한 현업 및 IT 부문의 다양한 전문가들이 모여 이들의 협업을 근간으로 하는 개발 기법이다. 이는 소프트웨어 및 서비스의 개발 속도와 품질을 향상시키는 데 목적이 있다. 데브옵스는 개발 생애주기를 단축하고, 고품질의 애플리케이션을 빠르게 배포하기 위해 개발과 운영을 통합하는 방법론이다. 애자일과 데브옵스의 활용은 디지털 트랜스포메이션을 가속화하고, 업무 진행 방식에 큰 영향을 가져올 수 있다. 특히 더 많은 사용자와 프로젝트가 참여할 때 그 효과가 더 크다. 전사적으로 애자일과 데브옵스를 성공시키는 몇 가지 방법을 살펴본다.    가장 중요한 것은 ‘문화’다 애자일과 데브옵스 방법론을 도입하는 기업은 팀이 오너십과 책임감을 갖는 문화를 형성해야 한다. 에너지 관리 및 자동화 기업 슈나이더 일렉트릭의 CDO 허브 쿠레일은 "데브옵스 역량과 DNA가 전사적으로 광범위하게 확산돼야 한다. 기업 문화의 일부가 되어야 한다는 의미다"라고 강조했다.  일부 전문가에게 책임을 국한해서는 애자일과 데브옵스에 성공할 수 없다. 쿠레일은 “데브옵스 모범 사례에 부합하는 빠른 배포가 한 명의 개인이 아닌 팀 전체의 책임이 되어야 한다”라고 말했다. 그는 "슈나이더 일렉트릭은 애자일과 데브옵스로 전체적인 운영 모델을 바꾸는 데 목적이 있었다"라며, "모든 부문에서 지속적이면서 투명하게 커뮤니케이션 흐름이 구현되도록 애자일 방법론을 시행하고 있다. 이는 포트폴리오 관리, 재무 관리, 제품 관리, 제품 엔지니어링, 아키텍처, 전문 서비스, 최종 소비자 등을 포함한다"라고 설명했다.  2019...

애자일 데브옵스 워터폴 스크럼 칸반 디지털트랜스포메이션

2020.03.18

많은 기업이 애자일과 데브옵스를 디지털 트랜스포메이션 여정의 핵심 단계로 간주한다. 그러나 소규모 팀 단위에서만 변화가 진행됨에 따라 그 효과가 제한적인 경우가 많다. 애자일과 데브옵스를 전사적으로 도입한다면, 더 큰 규모의 프로세스를 개선하여 상당한 이익을 얻을 수 있다.   애자일은 소프트웨어 최종 사용자를 비롯한 현업 및 IT 부문의 다양한 전문가들이 모여 이들의 협업을 근간으로 하는 개발 기법이다. 이는 소프트웨어 및 서비스의 개발 속도와 품질을 향상시키는 데 목적이 있다. 데브옵스는 개발 생애주기를 단축하고, 고품질의 애플리케이션을 빠르게 배포하기 위해 개발과 운영을 통합하는 방법론이다. 애자일과 데브옵스의 활용은 디지털 트랜스포메이션을 가속화하고, 업무 진행 방식에 큰 영향을 가져올 수 있다. 특히 더 많은 사용자와 프로젝트가 참여할 때 그 효과가 더 크다. 전사적으로 애자일과 데브옵스를 성공시키는 몇 가지 방법을 살펴본다.    가장 중요한 것은 ‘문화’다 애자일과 데브옵스 방법론을 도입하는 기업은 팀이 오너십과 책임감을 갖는 문화를 형성해야 한다. 에너지 관리 및 자동화 기업 슈나이더 일렉트릭의 CDO 허브 쿠레일은 "데브옵스 역량과 DNA가 전사적으로 광범위하게 확산돼야 한다. 기업 문화의 일부가 되어야 한다는 의미다"라고 강조했다.  일부 전문가에게 책임을 국한해서는 애자일과 데브옵스에 성공할 수 없다. 쿠레일은 “데브옵스 모범 사례에 부합하는 빠른 배포가 한 명의 개인이 아닌 팀 전체의 책임이 되어야 한다”라고 말했다. 그는 "슈나이더 일렉트릭은 애자일과 데브옵스로 전체적인 운영 모델을 바꾸는 데 목적이 있었다"라며, "모든 부문에서 지속적이면서 투명하게 커뮤니케이션 흐름이 구현되도록 애자일 방법론을 시행하고 있다. 이는 포트폴리오 관리, 재무 관리, 제품 관리, 제품 엔지니어링, 아키텍처, 전문 서비스, 최종 소비자 등을 포함한다"라고 설명했다.  2019...

2020.03.18

'SQL, 자바, 파이썬...' 2020년 美서 인기 있을 기술력 10선

완벽한 IT일자리를 찾아 안착하는 일은 쉬운 일이 아니다. 하지만 수요가 높은 분야에서 적절한 기술력을 갖추면 이직에 유리할 수 있다. 미국 취업전문 사이트 인디드(Indeed)는 2014년에서 2019년까지 구인 광고에 가장 많이 등장한 ‘기술력’을 분석해 2019년 기술 구인 시장을 주도했던 기술력이 무엇이며 2020년 어떤 기술력이 인기 있을지를 소개했다.    인디드의 경제학자 대니얼 컬버트슨은 “사람들이 새로운 일자리를 찾을 때 종종 원하는 일자리와 관련된 최첨단 기술을 설명하는 검색어를 사용한다”라며 "고용주 측에서는 이러한 능력을 갖춘 고도로 전문화된 기술 인력이 수요가 많다"라고 말했다.  인디드는 보고서에서 2014년 9월부터 2019년 9월까지 인디드닷컴(Indeed.com)에 게시된 구인공고를 쿼리하기 위해 500개가 넘는 기술 용어를 사용했다. 컬버트슨은 “2가지 이상의 직무를 요구하는 데 따른 영향을 조사하기 위해 기술력의 변화를 2가지 구성 요소로 쪼갰다. 하나는 직무 내 기술력 포화 상태(예 : 주어진 직무에 파이썬을 추가로 넣은 구인공기 게시물 수 증가)와 달라진 직무 혼합 상태(데이터 과학자같이 파이썬을 사용하는 직무에서 더 많은 기술력을 요구하는 구인공고 게시물 수)로 기술력의 변화를 나눴다. 모든 기술 직종의 데이터 과학자 비율이 현재의 1/3 정도였던 2014년 9월 수준에서 직무 혼합을 유지하는 것은 시간이 지남에 따라 '조정된' 파이썬 추세가 어떻게 진화했는지를 보여준다. 실제로 모든 기술력에 관해 이 과정을 반복했다”라고 설명했다.  이 연구에 따르면 2020년에는 파이썬, 데이터 과학 기술 및 일부 기존 기술을 포함한 특수 프로그래밍 언어가 IT전문가의 성공 티켓임이 밝혀졌다. 2020년에도 구인시장에서 인기 있을 10대 기술력과 이들이 지난 몇 년 동안 수요가 얼마나 달라졌는지를 알아보자.. 1. SQL 2019년 전체 구인공고 게시물에서 언급된 빈도 : 21.9% 20...

CIO C++ C# 리눅스 도커 아마존웹서비스 스크럼 인디드 2020년 인디드닷컴 파이썬 닷넷 C 자바 이직 마이크로소프트 AWS 애저 구직 자바스크립트 구인 SQL 기트

2019.12.09

완벽한 IT일자리를 찾아 안착하는 일은 쉬운 일이 아니다. 하지만 수요가 높은 분야에서 적절한 기술력을 갖추면 이직에 유리할 수 있다. 미국 취업전문 사이트 인디드(Indeed)는 2014년에서 2019년까지 구인 광고에 가장 많이 등장한 ‘기술력’을 분석해 2019년 기술 구인 시장을 주도했던 기술력이 무엇이며 2020년 어떤 기술력이 인기 있을지를 소개했다.    인디드의 경제학자 대니얼 컬버트슨은 “사람들이 새로운 일자리를 찾을 때 종종 원하는 일자리와 관련된 최첨단 기술을 설명하는 검색어를 사용한다”라며 "고용주 측에서는 이러한 능력을 갖춘 고도로 전문화된 기술 인력이 수요가 많다"라고 말했다.  인디드는 보고서에서 2014년 9월부터 2019년 9월까지 인디드닷컴(Indeed.com)에 게시된 구인공고를 쿼리하기 위해 500개가 넘는 기술 용어를 사용했다. 컬버트슨은 “2가지 이상의 직무를 요구하는 데 따른 영향을 조사하기 위해 기술력의 변화를 2가지 구성 요소로 쪼갰다. 하나는 직무 내 기술력 포화 상태(예 : 주어진 직무에 파이썬을 추가로 넣은 구인공기 게시물 수 증가)와 달라진 직무 혼합 상태(데이터 과학자같이 파이썬을 사용하는 직무에서 더 많은 기술력을 요구하는 구인공고 게시물 수)로 기술력의 변화를 나눴다. 모든 기술 직종의 데이터 과학자 비율이 현재의 1/3 정도였던 2014년 9월 수준에서 직무 혼합을 유지하는 것은 시간이 지남에 따라 '조정된' 파이썬 추세가 어떻게 진화했는지를 보여준다. 실제로 모든 기술력에 관해 이 과정을 반복했다”라고 설명했다.  이 연구에 따르면 2020년에는 파이썬, 데이터 과학 기술 및 일부 기존 기술을 포함한 특수 프로그래밍 언어가 IT전문가의 성공 티켓임이 밝혀졌다. 2020년에도 구인시장에서 인기 있을 10대 기술력과 이들이 지난 몇 년 동안 수요가 얼마나 달라졌는지를 알아보자.. 1. SQL 2019년 전체 구인공고 게시물에서 언급된 빈도 : 21.9% 20...

2019.12.09

칼럼 | 잊지 말자, 변혁도 사람이 하는 일이다

기업이 변혁해야 한다고 누구나 이야기한다. 그러나, 의욕에 비해 실행 성과는 점점 뒤처진다. 변혁이 멈추거나 흔들리기 때문이다. 사람이 변하는 속도가 기술의 발전 속도를 따라가지 못하는 것이 원인인 경우가 많다. 팀에게 자율성을 부여하고 사용자에게 귀를 기울이며 빠른 실패를 인정하는 것은 이론적으로 맞다. 그러나, 아무리 계획이 상세하고 의도가 좋아도 팀이 제대로 기능하지 못하고 사용자 이해가 부족하며 실패를 잘못으로만 생각한다면, 현실에서 발생하는 감정적인 부조화 앞에서는 무력해질 것이다. 업무 현장은 이성이 지배하지 않는다. 사람은 매우 비이성적이지만 그 방식은 예상할 수 있다. 사람은 인지 편향에 사로잡혀 있다. 특히, 불확실성이 생기면 이미 알고 있는 것으로 회귀하는 것에 익숙하다.  사람은 감정 도화선이 있으며 여기에 불이 붙으면 자극에 맞게 이성적으로 반응하지 않는다. 사람은 길들여진 대로 행동하는 경향도 있다. 그런 행동들은 이성적으로 버려야 마땅한 이유가 있어도 버리기 어렵다. 사정이 이러함에도 직원들은 변혁이 진행되는 격변의 와중에도 마치 합리적이고 이성적인 존재로 취급된다. 기업계가 변해야 한다는 주장의 대부분은 지적인 판단에 따른다. 변화 속도 증대, 와해의 위협, ‘한 기업’이 되어야 할 필요성, 변화하는 고객 기대치 등이 자주 논의된다. 전부 이성적이고 지적인 주장들이다. 딱딱한 목록과 슬라이드 형식으로 전달되는 경우가 많다.     변화의 감정적인 측면에 대해서 많은 사람이 말로는 동의하지만 새로운 프로세스나 기술의 개발과 출시를 계획할 때만큼 철저하게 신경 쓰지 않는다. 변혁에는 신경과학적 악재가 수반되어 변화를 방해한다. 인간적인 차원을 제대로 대처하려면 CIO들은 심리학, 신경과학, 행동경제학 분야의 독서를 늘려나가야 한다. CIO들이 자주 과소평가하지만 변혁에 박차를 가하려면 알고 있어야 하는 4가지 예상 가능한 심리학적 요소는 다음과 같다. 1. 인지 부조화  변화의 필요성...

혁신 CIO 커뮤니케이션 가트너 의사소통 인지 부조화 디지털 변혁 스크럼

2019.12.03

기업이 변혁해야 한다고 누구나 이야기한다. 그러나, 의욕에 비해 실행 성과는 점점 뒤처진다. 변혁이 멈추거나 흔들리기 때문이다. 사람이 변하는 속도가 기술의 발전 속도를 따라가지 못하는 것이 원인인 경우가 많다. 팀에게 자율성을 부여하고 사용자에게 귀를 기울이며 빠른 실패를 인정하는 것은 이론적으로 맞다. 그러나, 아무리 계획이 상세하고 의도가 좋아도 팀이 제대로 기능하지 못하고 사용자 이해가 부족하며 실패를 잘못으로만 생각한다면, 현실에서 발생하는 감정적인 부조화 앞에서는 무력해질 것이다. 업무 현장은 이성이 지배하지 않는다. 사람은 매우 비이성적이지만 그 방식은 예상할 수 있다. 사람은 인지 편향에 사로잡혀 있다. 특히, 불확실성이 생기면 이미 알고 있는 것으로 회귀하는 것에 익숙하다.  사람은 감정 도화선이 있으며 여기에 불이 붙으면 자극에 맞게 이성적으로 반응하지 않는다. 사람은 길들여진 대로 행동하는 경향도 있다. 그런 행동들은 이성적으로 버려야 마땅한 이유가 있어도 버리기 어렵다. 사정이 이러함에도 직원들은 변혁이 진행되는 격변의 와중에도 마치 합리적이고 이성적인 존재로 취급된다. 기업계가 변해야 한다는 주장의 대부분은 지적인 판단에 따른다. 변화 속도 증대, 와해의 위협, ‘한 기업’이 되어야 할 필요성, 변화하는 고객 기대치 등이 자주 논의된다. 전부 이성적이고 지적인 주장들이다. 딱딱한 목록과 슬라이드 형식으로 전달되는 경우가 많다.     변화의 감정적인 측면에 대해서 많은 사람이 말로는 동의하지만 새로운 프로세스나 기술의 개발과 출시를 계획할 때만큼 철저하게 신경 쓰지 않는다. 변혁에는 신경과학적 악재가 수반되어 변화를 방해한다. 인간적인 차원을 제대로 대처하려면 CIO들은 심리학, 신경과학, 행동경제학 분야의 독서를 늘려나가야 한다. CIO들이 자주 과소평가하지만 변혁에 박차를 가하려면 알고 있어야 하는 4가지 예상 가능한 심리학적 요소는 다음과 같다. 1. 인지 부조화  변화의 필요성...

2019.12.03

주요 프로젝트 관리 방법론 17선

팀에 적용할 적절한 프로젝트 관리 방법론의 선택은 중요하다. 성공의 첫걸음이라고 표현할 수 있을 정도다. 하지만 다양하고 때로는 중복되는 접근방식이 있는 상황에서 어떤 관리 방법론이 가장 좋은지 어떻게 알 수 있을까? 프로젝트 관리자는 각 프로젝트 관리 방법론이 가지는 긍정적인 측면과 부정적인 측면을 깊게 이해해야 한다. 요즘 인기 있는 PMM(Project Management Methodology)에 관해 간략히 살펴본다.    워터폴(Waterfall) 워터폴은 오랜 기간 주류 프로젝트 관리 방법론이었다. 여러 산업에서 사용됐으며, 소프트웨어 개발에서는 보편적으로 사용됐다. 특정 순서로 실행되는 정적 단계(요건분석, 디자인, 시험, 이행, 유지보수)로 구성된다.  워터폴을 통해 각 단계 전반의 통제력이 높아지지만 프로젝트 진행 중 범위가 변경되면 그리 유연하지 못할 수 있다. 모든 프로젝트 요건을 초기에 파악할 수 있도록 돕는 계획 단계를 제공함으로써, 초기 단계의 핵심 정보 및 요건 손실을 줄여준다. 애자일(Agile) 애자일은 워터폴과 매우 다른 프로젝트 관리 접근방식이다. 처음에는 유연성과 속도가 특히 요구되는 프로젝트를 위해 개발됐다. 이를 달성하기 위해 애자일은 일명 ‘스프린트(Sprint)’라는 짧은 인도 사이클로 구성된다. 애자일은 자발적인 팀 구성 안에서 통제력 감소와 실시간 소통이 필요한 프로젝트에 가장 적합할 수 있다. 프로젝트 관리 방법론으로써 애자일은 매우 상호적이어서 프로젝트 전반에 걸쳐 신속한 조정이 가능하다. 시험이 완료될 때까지 기다리는 대신에 문제를 신속하게 확인하고 개발 과정 초기에 수정하기가 훨씬 쉽기 때문에 대부분 소프트웨어 개발 프로젝트에서 보편적으로 사용된다. 애자일은 반복 가능한 과정을 제공하고 위험을 낮추며 즉각적인 피드백이 가능하게 하고 신속한 방향 전환이 가능하며 복잡성을 낮춘다. -> ‘웨자일 피하려면…’ 성공적 애자일 팀의 조건 하이브리드(Hybrid) 많...

애자일 워터폴 스크럼 크리스탈 프로젝트 관리 방법론 칸반 린 개발 린 식스 시그마 스크럼반

2019.10.29

팀에 적용할 적절한 프로젝트 관리 방법론의 선택은 중요하다. 성공의 첫걸음이라고 표현할 수 있을 정도다. 하지만 다양하고 때로는 중복되는 접근방식이 있는 상황에서 어떤 관리 방법론이 가장 좋은지 어떻게 알 수 있을까? 프로젝트 관리자는 각 프로젝트 관리 방법론이 가지는 긍정적인 측면과 부정적인 측면을 깊게 이해해야 한다. 요즘 인기 있는 PMM(Project Management Methodology)에 관해 간략히 살펴본다.    워터폴(Waterfall) 워터폴은 오랜 기간 주류 프로젝트 관리 방법론이었다. 여러 산업에서 사용됐으며, 소프트웨어 개발에서는 보편적으로 사용됐다. 특정 순서로 실행되는 정적 단계(요건분석, 디자인, 시험, 이행, 유지보수)로 구성된다.  워터폴을 통해 각 단계 전반의 통제력이 높아지지만 프로젝트 진행 중 범위가 변경되면 그리 유연하지 못할 수 있다. 모든 프로젝트 요건을 초기에 파악할 수 있도록 돕는 계획 단계를 제공함으로써, 초기 단계의 핵심 정보 및 요건 손실을 줄여준다. 애자일(Agile) 애자일은 워터폴과 매우 다른 프로젝트 관리 접근방식이다. 처음에는 유연성과 속도가 특히 요구되는 프로젝트를 위해 개발됐다. 이를 달성하기 위해 애자일은 일명 ‘스프린트(Sprint)’라는 짧은 인도 사이클로 구성된다. 애자일은 자발적인 팀 구성 안에서 통제력 감소와 실시간 소통이 필요한 프로젝트에 가장 적합할 수 있다. 프로젝트 관리 방법론으로써 애자일은 매우 상호적이어서 프로젝트 전반에 걸쳐 신속한 조정이 가능하다. 시험이 완료될 때까지 기다리는 대신에 문제를 신속하게 확인하고 개발 과정 초기에 수정하기가 훨씬 쉽기 때문에 대부분 소프트웨어 개발 프로젝트에서 보편적으로 사용된다. 애자일은 반복 가능한 과정을 제공하고 위험을 낮추며 즉각적인 피드백이 가능하게 하고 신속한 방향 전환이 가능하며 복잡성을 낮춘다. -> ‘웨자일 피하려면…’ 성공적 애자일 팀의 조건 하이브리드(Hybrid) 많...

2019.10.29

'칸반(Kanban)', 효율적인 작업 흐름 관리의 시작

칸반(Kanban)이란 생산 과정에서 효율성과 기민성을 높이기 위한 간소화된 작업 흐름 관리 시스템이다. 일반적으로 소프트웨어 개발에 사용되지만 IT뿐만 아니라 모든 업무 영역에서 점진적인 개선을 지향한다. 1940년대 초반 일본에서 토요타에 의해 개발됐으며, 본래 프로젝트 관리를 대체하거나 개발 방법론 역할을 하려고 만들어진 것이 아니다. 대신, 더 좋은 작업 흐름 구조를 만들어 이미 확립된 공정을 개선하는 데 중점을 둔다.   칸반은 조직 내에 진행 중인 업무(Works In-Progress , WIP)가 일정 수준 이상 밀려 있지 않게 하는 데도 도움을 준다. 이 밖에도 강력한 리더십, 조직적 투명성, 팀워크, 사내 열린 소통과 협업을 지원한다. 칸반을 활용하면 눈에 보이지 않는 작업을 가시화할 수 있다. 그러면 우선순위를 놓치는 일을 막고 어떤 일이 처리되고 있는지 모든 사람이 알 수 있다. 칸반 게시판과 칸반 카드 칸반 게시판은 칸반 전략에 사용되는 기본 툴이다. 화이트보드와 같은 실제 게시판 혹은 가상 게시판 형태로, 해당 부서가 작업 내용과 진행 상태를 추적하도록 도움을 준다. 진행 상태는 칸반 카드를 사용해 추적한다. 칸반 카드는 붙였다 뗄 수 있는 포스트잇 메모처럼 간단한 형태일 수도 있고 아니면 칸반 게시판상의 여러 열로 끌어넣을 수 있는 가상 카드일 수도 있다. 각 단계는 칸반 게시판상에 열로 표시된다. 예를 들면, 첫 번째 열에는 해야 할 ‘미뤄진’ 작업이 있고 ‘오늘’ 또는 ‘이번 주’ 열에서는 지금 집중해야 할 작업을 배치한다. 칸반 카드에 포함할 작업은 완료 시간이 몇 주씩 걸리지 않을 작은 규모의 것을 선택하는 것이 좋다. 반대로 작업을 지나치게 세분하는 것도 피해야 한다. 카드가 많아지면 게시판이 지저분해지기 때문이다. 해야 할 일 목록에서 몇 가지 항목을 처리할 수 있는 작업을 선택하되 팀이 의욕을 유지할 수 있도록 빠르게 해결할 수 있는 것을 선택한다. 칸반 단계 칸반 게시판용 단계를 만들 때 일반적으로 사용...

CIO 스크럼 칸반 Kanban

2019.10.04

칸반(Kanban)이란 생산 과정에서 효율성과 기민성을 높이기 위한 간소화된 작업 흐름 관리 시스템이다. 일반적으로 소프트웨어 개발에 사용되지만 IT뿐만 아니라 모든 업무 영역에서 점진적인 개선을 지향한다. 1940년대 초반 일본에서 토요타에 의해 개발됐으며, 본래 프로젝트 관리를 대체하거나 개발 방법론 역할을 하려고 만들어진 것이 아니다. 대신, 더 좋은 작업 흐름 구조를 만들어 이미 확립된 공정을 개선하는 데 중점을 둔다.   칸반은 조직 내에 진행 중인 업무(Works In-Progress , WIP)가 일정 수준 이상 밀려 있지 않게 하는 데도 도움을 준다. 이 밖에도 강력한 리더십, 조직적 투명성, 팀워크, 사내 열린 소통과 협업을 지원한다. 칸반을 활용하면 눈에 보이지 않는 작업을 가시화할 수 있다. 그러면 우선순위를 놓치는 일을 막고 어떤 일이 처리되고 있는지 모든 사람이 알 수 있다. 칸반 게시판과 칸반 카드 칸반 게시판은 칸반 전략에 사용되는 기본 툴이다. 화이트보드와 같은 실제 게시판 혹은 가상 게시판 형태로, 해당 부서가 작업 내용과 진행 상태를 추적하도록 도움을 준다. 진행 상태는 칸반 카드를 사용해 추적한다. 칸반 카드는 붙였다 뗄 수 있는 포스트잇 메모처럼 간단한 형태일 수도 있고 아니면 칸반 게시판상의 여러 열로 끌어넣을 수 있는 가상 카드일 수도 있다. 각 단계는 칸반 게시판상에 열로 표시된다. 예를 들면, 첫 번째 열에는 해야 할 ‘미뤄진’ 작업이 있고 ‘오늘’ 또는 ‘이번 주’ 열에서는 지금 집중해야 할 작업을 배치한다. 칸반 카드에 포함할 작업은 완료 시간이 몇 주씩 걸리지 않을 작은 규모의 것을 선택하는 것이 좋다. 반대로 작업을 지나치게 세분하는 것도 피해야 한다. 카드가 많아지면 게시판이 지저분해지기 때문이다. 해야 할 일 목록에서 몇 가지 항목을 처리할 수 있는 작업을 선택하되 팀이 의욕을 유지할 수 있도록 빠르게 해결할 수 있는 것을 선택한다. 칸반 단계 칸반 게시판용 단계를 만들 때 일반적으로 사용...

2019.10.04

김진철의 How-to-Big Data | 빅데이터 조직과 시스템 (13)

애자일 프로젝트 관리란? – 스크럼으로 애자일 맛보기 켄트 벡을 비롯한 일부 소프트웨어 엔지니어들이 왜 소프트웨어 엔지니어들은 항상 야근과 과로에 시달려야 하는가, 소프트웨어 프로젝트는 왜 일정을 맞추지 못하고 과도한 요구 사항 변화와 이로 인한 일정 지연에 시달리고 유난히 실패 위험이 높은 것인가, 소프트웨어 엔지니어들도 일반 직장인들과 같은 평범한 라이프스타일을 가지면서 생산성을 높일 방법은 없는 것인가 하는 문제를 고민하기 시작했다. 이를 위해 이들은 소프트웨어 개발 방식에 새로운 방법론이 필요하다고 생각하게 되었는데 이에 대한 해답으로 제시한 것이 익스트림 프로그래밍과 애자일 방법론이다.  애자일 방법론은 반복적인 과정을 통한 소프트웨어 프로젝트 실패 위험 감소와 소스 코드 품질 향상, 코드 리뷰, 페어 프로그래밍을 통한 소스 코드 품질 향상 및 버그 감소, 정기적인 플래닝과 리뷰를 통한 개발자 간 소통과 소프트웨어 개발의 암묵적인 지식 공유를 통한 위험 감소 등으로 특징 지워진다. 애자일 방법론은 린 소프트웨어 개발 방법론과 함께 일정과 자원이 넉넉지 않은 스타트업들을 중심으로 널리 쓰이기 시작하여 그 효용이 입증되면서 이제는 많은 IT 기업들에서 널리 쓰이는 소프트웨어 프로젝트 관리 방법론이 되었다. 그림 1. 애자일 선언(“The Agile Manifesto”)의 핵심 아이디어를 설명한 그림. 애자일 선언은 과거 폭포수(waterfall) 방식의 소프트웨어 공학 방법론에서 탈피하여, 고객과의 밀접한 소통, 피드백과 소프트웨어 엔지니어 간 소통과 협업, 명세서와 문서화 위주의 소프트웨어 개발보다는 실제 동작하는 소프트웨어 개발을 목표로 하고, 반복적인 소프트웨어 개발을 통한 프로젝트 변경과 변화의 능동적 수용을 기본으로 한다. (그림 출처: https://www.slideshare.net/valtechuk/adapting-agile-to-the-entreprise) 그림 2. 애자일 선언의 핵심 아이디어가 된 익스트림 프로그래밍 방...

애자일 LHC CERN 김진철 칸반 스크럼 OSS 애자일 방법론 스프린트 데이터 과학자 빅데이터 CIO BSS

2019.10.02

애자일 프로젝트 관리란? – 스크럼으로 애자일 맛보기 켄트 벡을 비롯한 일부 소프트웨어 엔지니어들이 왜 소프트웨어 엔지니어들은 항상 야근과 과로에 시달려야 하는가, 소프트웨어 프로젝트는 왜 일정을 맞추지 못하고 과도한 요구 사항 변화와 이로 인한 일정 지연에 시달리고 유난히 실패 위험이 높은 것인가, 소프트웨어 엔지니어들도 일반 직장인들과 같은 평범한 라이프스타일을 가지면서 생산성을 높일 방법은 없는 것인가 하는 문제를 고민하기 시작했다. 이를 위해 이들은 소프트웨어 개발 방식에 새로운 방법론이 필요하다고 생각하게 되었는데 이에 대한 해답으로 제시한 것이 익스트림 프로그래밍과 애자일 방법론이다.  애자일 방법론은 반복적인 과정을 통한 소프트웨어 프로젝트 실패 위험 감소와 소스 코드 품질 향상, 코드 리뷰, 페어 프로그래밍을 통한 소스 코드 품질 향상 및 버그 감소, 정기적인 플래닝과 리뷰를 통한 개발자 간 소통과 소프트웨어 개발의 암묵적인 지식 공유를 통한 위험 감소 등으로 특징 지워진다. 애자일 방법론은 린 소프트웨어 개발 방법론과 함께 일정과 자원이 넉넉지 않은 스타트업들을 중심으로 널리 쓰이기 시작하여 그 효용이 입증되면서 이제는 많은 IT 기업들에서 널리 쓰이는 소프트웨어 프로젝트 관리 방법론이 되었다. 그림 1. 애자일 선언(“The Agile Manifesto”)의 핵심 아이디어를 설명한 그림. 애자일 선언은 과거 폭포수(waterfall) 방식의 소프트웨어 공학 방법론에서 탈피하여, 고객과의 밀접한 소통, 피드백과 소프트웨어 엔지니어 간 소통과 협업, 명세서와 문서화 위주의 소프트웨어 개발보다는 실제 동작하는 소프트웨어 개발을 목표로 하고, 반복적인 소프트웨어 개발을 통한 프로젝트 변경과 변화의 능동적 수용을 기본으로 한다. (그림 출처: https://www.slideshare.net/valtechuk/adapting-agile-to-the-entreprise) 그림 2. 애자일 선언의 핵심 아이디어가 된 익스트림 프로그래밍 방...

2019.10.02

확장형 애자일 프레임워크 'SAFe'란 무엇인가?

대기업은 신생벤처만큼 민첩하게 움직이지 못하는 경향이 있고, 변화에 더 크게 저항하기도 한다. 이는 대형 조직 특유의 문화적 문제에 기인한 것일 수 있고, 정책과 프로세스에 따른 장벽으로 인한 것일 수도 있다. 기업 환경 전반에 걸쳐 관료주의가 번성하는 경향이 있기 때문이다.  그렇지만, 애자일 개발 혜택을 놓치지 않으려는 대형 조직도 있다. 문제는 대형 조직과 애자일 개발 방식이 잘 맞지 않는다는 데에 있다. 확장형 애자일 프레임워크(Scaled Agile Framework, SAFe)는 대형 조직이 프로젝트의 성공에 부정적인 영향을 주는 문제들을 극복하기 위해 채택할 수 있는 강력한 툴이다.     SAFe는 대형 조직에 한층 민첩해질 수 있는 프레임워크를 제공해 결과물이 시장에 좀더 신속히 도달할 수 있도록 한다. SAFe란 무엇이며, SAFe의 원리와 혜택을 간단히 고찰하고, 아울러 프레임워크와 방법론을 효과적으로 구현하는 요령을 알아본다.  확장형 애자일 프레임워크(SAFe) 정의  확장형 애자일 프레임워크는 대형 조직이 고품질의 제품과 서비스를 더욱 신속히 개발하고 전달할 수 있도록 린(Lean), 스크럼(Scrum) 등의 애자일 방법론을 도입하는 데 기여하는 제반 원리, 프로세스, 베스트 프랙티스를 아우른다.  SAFe는 프로젝트, 프로그램, 포트폴리오 수준에서 여러 대규모 팀이 관여하는 복합 프로젝트에 특히 잘 맞는다. 이 프레임워크의 공급업체인 스케일드 애자일에 따르면 최신 버전인 SAFe 4.6은 디지털 변혁에 성공적으로 대처하고 변동이 심한 시장 조건, 변화하는 고객 요구, 신생 기술에 효과적으로 대응하는 데 기여하는 5가지 핵심 역량에 집중한다.   이 5가지 역량은 아래와 같다.  린 애자일 리더십(Lean agile leadership): 리더들은 조직의 변화와 운영 효율성을 유도하고 지원해야 한다. 결국, 개인 또는 팀이 잠재력을 발휘할 수 있도록...

애자일 애자일 릴리즈 트레인 Scrum ARTs agile release trains Center of Excellence 전문가조직 Lean 칸반 SaFE 스크럼 디지털 변혁 CoE CIO 확장형 애자일 프레임워크

2019.09.03

대기업은 신생벤처만큼 민첩하게 움직이지 못하는 경향이 있고, 변화에 더 크게 저항하기도 한다. 이는 대형 조직 특유의 문화적 문제에 기인한 것일 수 있고, 정책과 프로세스에 따른 장벽으로 인한 것일 수도 있다. 기업 환경 전반에 걸쳐 관료주의가 번성하는 경향이 있기 때문이다.  그렇지만, 애자일 개발 혜택을 놓치지 않으려는 대형 조직도 있다. 문제는 대형 조직과 애자일 개발 방식이 잘 맞지 않는다는 데에 있다. 확장형 애자일 프레임워크(Scaled Agile Framework, SAFe)는 대형 조직이 프로젝트의 성공에 부정적인 영향을 주는 문제들을 극복하기 위해 채택할 수 있는 강력한 툴이다.     SAFe는 대형 조직에 한층 민첩해질 수 있는 프레임워크를 제공해 결과물이 시장에 좀더 신속히 도달할 수 있도록 한다. SAFe란 무엇이며, SAFe의 원리와 혜택을 간단히 고찰하고, 아울러 프레임워크와 방법론을 효과적으로 구현하는 요령을 알아본다.  확장형 애자일 프레임워크(SAFe) 정의  확장형 애자일 프레임워크는 대형 조직이 고품질의 제품과 서비스를 더욱 신속히 개발하고 전달할 수 있도록 린(Lean), 스크럼(Scrum) 등의 애자일 방법론을 도입하는 데 기여하는 제반 원리, 프로세스, 베스트 프랙티스를 아우른다.  SAFe는 프로젝트, 프로그램, 포트폴리오 수준에서 여러 대규모 팀이 관여하는 복합 프로젝트에 특히 잘 맞는다. 이 프레임워크의 공급업체인 스케일드 애자일에 따르면 최신 버전인 SAFe 4.6은 디지털 변혁에 성공적으로 대처하고 변동이 심한 시장 조건, 변화하는 고객 요구, 신생 기술에 효과적으로 대응하는 데 기여하는 5가지 핵심 역량에 집중한다.   이 5가지 역량은 아래와 같다.  린 애자일 리더십(Lean agile leadership): 리더들은 조직의 변화와 운영 효율성을 유도하고 지원해야 한다. 결국, 개인 또는 팀이 잠재력을 발휘할 수 있도록...

2019.09.03

'제대로 쓰고 있는 걸까'··· 애자일 도구 관리 방법

애자일 도구가 잘 작동하는지 질문하면 엇갈린 반응을 보인다. 때로는 부정적인 반응도 나온다는 이야기다. 애자일 도구는 애자일 부서를 도와주지만, 제품 소유주가 일할 때 필요한 모든 기능을 제공하는 것은 아니다.   이와 유사하게 프로그램과 포트폴리오 관리자를 도와주는 기능에도 제약이 있다. 애자일 도구는 부서와 릴리즈, 에픽에 대한 보고서를 제공하지만, 일반적으로 프로그래머가 하향식 전략 이니셔티브에 대해 보고할 때 충분히 도움을 줄 수 있는 정도는 아니다. 이런 이유로 부서의 제품 오너는 애틀라시안의 지라(Jira)를 선호하지 않는 경향이 있다. 또 프로그램 매니저는 지라나 마이크로소프트 애저 데브옵스(Azure DevOps)에서 필요한 보고서를 얻지 못한다. 이 도구들은 부서의 직능 가운데 일부에만 도움을 준다. 백로그, 스프린트 보드, 스크럼 보고서는 제품 매니저가 좋은 제품을 구상할 때 필요한 도구를 제대로 다루지 못한다. 또 프로그래머 매니저가 전략 목표를 애자일 부서가 수행하는 업무에 일치할 때도 도움을 주지 못한다. 파워포인트 프레젠테이션을 통해 비즈니스 전략을 배우고, 업무 현황을 검토하는 제품·프로그램 관리자와의 회의가 많다면 애자일 제품 관리, 또는 포트폴리오 관리 플랫폼에 대한 준비가 되어 있다고 볼 수도 있다. 지라와 애저 데브옵스 같은 애자일 관리 플랫폼은 개발자와 테스터, 데브옵스 엔지니어로 구성된 애자일 딜리버리 부서가 주로 사용할 수 있는 도구이다. 활성 스프린트에 해당되는 사용자 스토리와 다른 종류의 업무 상태를 관리할 수 있는 보드가 있다. 또 미래의 스프린트를 위해 스토리를 평가, 배열, 우선순위를 부여할 때 도움을 주는 다른 백로그 관리 도구도 있다. 그리고 애자일 부서가 속도를 추적하고, 블록을 검토하고, 사이클 타임을 측정하고, WIP(진행 중인 업무)를 관리할 때 도움이 되는 번다운 보고서와 기타 보고서 기능이 내장되어 있다. 여기에 더해, 애자일 도구는 제품 오너의 스토리 작성, 승인 기준 문서화, ...

애자일 데브옵스 스크럼 스크럼마스터

2019.08.06

애자일 도구가 잘 작동하는지 질문하면 엇갈린 반응을 보인다. 때로는 부정적인 반응도 나온다는 이야기다. 애자일 도구는 애자일 부서를 도와주지만, 제품 소유주가 일할 때 필요한 모든 기능을 제공하는 것은 아니다.   이와 유사하게 프로그램과 포트폴리오 관리자를 도와주는 기능에도 제약이 있다. 애자일 도구는 부서와 릴리즈, 에픽에 대한 보고서를 제공하지만, 일반적으로 프로그래머가 하향식 전략 이니셔티브에 대해 보고할 때 충분히 도움을 줄 수 있는 정도는 아니다. 이런 이유로 부서의 제품 오너는 애틀라시안의 지라(Jira)를 선호하지 않는 경향이 있다. 또 프로그램 매니저는 지라나 마이크로소프트 애저 데브옵스(Azure DevOps)에서 필요한 보고서를 얻지 못한다. 이 도구들은 부서의 직능 가운데 일부에만 도움을 준다. 백로그, 스프린트 보드, 스크럼 보고서는 제품 매니저가 좋은 제품을 구상할 때 필요한 도구를 제대로 다루지 못한다. 또 프로그래머 매니저가 전략 목표를 애자일 부서가 수행하는 업무에 일치할 때도 도움을 주지 못한다. 파워포인트 프레젠테이션을 통해 비즈니스 전략을 배우고, 업무 현황을 검토하는 제품·프로그램 관리자와의 회의가 많다면 애자일 제품 관리, 또는 포트폴리오 관리 플랫폼에 대한 준비가 되어 있다고 볼 수도 있다. 지라와 애저 데브옵스 같은 애자일 관리 플랫폼은 개발자와 테스터, 데브옵스 엔지니어로 구성된 애자일 딜리버리 부서가 주로 사용할 수 있는 도구이다. 활성 스프린트에 해당되는 사용자 스토리와 다른 종류의 업무 상태를 관리할 수 있는 보드가 있다. 또 미래의 스프린트를 위해 스토리를 평가, 배열, 우선순위를 부여할 때 도움을 주는 다른 백로그 관리 도구도 있다. 그리고 애자일 부서가 속도를 추적하고, 블록을 검토하고, 사이클 타임을 측정하고, WIP(진행 중인 업무)를 관리할 때 도움이 되는 번다운 보고서와 기타 보고서 기능이 내장되어 있다. 여기에 더해, 애자일 도구는 제품 오너의 스토리 작성, 승인 기준 문서화, ...

2019.08.06

스크럼 마스터 자격증, 어떻게 취득하지? 혜택은?

공인 스크럼마스터(CSM) 자격증은 스크럼 이론을 수립하고, 실제 애플리케이션과 규칙을 개발하며, 개발 프로세스를 통해 팀과 이해 관계자를 이끌어 갈 표준을 정한다. CSM 자격증이란? 애자일 프랙티스는 많은 산업 분야에서 프로젝트와 제품 관리에 빠르게 채택되고 있으며 스크럼마스터는 애자일 개발에서 중요한 리더 역할을 한다. 스크럼 어플라이언스를 통해 제공되는 공인 스크럼마스터(CSM) 자격증은 팀 성과, 책임, 반복 진행과 같은 스크럼의 방법론 및 가치에 대한 인식을 전문가에게 제공하는 것을 목표로 하는 초급 인증이다. CSM이 되면 리더로서의 인지도와 신뢰도 향상, 민첩한 실행력을 갖추고 조직 내에서 새로운 기회를 얻으며 스크럼에 대한 지식을 인정받는 등 개인에게 가치 있는 혜택을 받을 수 있다. CSM 요건 CSM 자격증을 취득하려면 신청자는 먼저 스크럼 프레임워크와 원칙 및 관행을 이해해야 한다. 스크럼 마스터 교육 및 자격증으로 유명한 조직인 스크럼 얼라이언스(Scrum Alliance)는 스크럼 얼라이언스 전문가 블로그, 회원 기사, 동영상, 프레젠테이션, 보고서를 비롯하여 개인이 스크럼 기본을 배우는 데 도움이 되는 다양한 정보를 제공한다. 지원자는 공인 스크럼 강사가 가르치는 2일(16시간)간의 CSM 과정에 참석해야 한다. 이 과정은 스크럼 팀 구성 및 지원 방법에 대한 전체 개요를 제공한다. CSM 과정은 학습 목표를 다루며 여기에는 범위, 린, 애자일, 스크럼, 코칭을 비롯해 개발팀, 제품 소유자, 조직에 대한 서비스도 포함된다. 온라인 과정은 아직 선택 사항이 아니다. 그런 다음 신청자는 스크럼 얼라이언스 포털에서 CSM 시험에 합격해야 한다. 과정을 수강하고 90일이 지난 뒤 시험에 응시하려면 25달러의 비용을 내야 한다. 시험은 2일간 이뤄지며 참석하지 않으면 시험을 볼 수 없다. CSM 시험을 치른 후에는 라이선스 계약에 동의해야 한다. 다음으로 스크럼 얼라이언스 회원 프로파일을 작...

자격증 애자일 CIO 스크럼 CSM 스크럼마스터

2018.11.02

공인 스크럼마스터(CSM) 자격증은 스크럼 이론을 수립하고, 실제 애플리케이션과 규칙을 개발하며, 개발 프로세스를 통해 팀과 이해 관계자를 이끌어 갈 표준을 정한다. CSM 자격증이란? 애자일 프랙티스는 많은 산업 분야에서 프로젝트와 제품 관리에 빠르게 채택되고 있으며 스크럼마스터는 애자일 개발에서 중요한 리더 역할을 한다. 스크럼 어플라이언스를 통해 제공되는 공인 스크럼마스터(CSM) 자격증은 팀 성과, 책임, 반복 진행과 같은 스크럼의 방법론 및 가치에 대한 인식을 전문가에게 제공하는 것을 목표로 하는 초급 인증이다. CSM이 되면 리더로서의 인지도와 신뢰도 향상, 민첩한 실행력을 갖추고 조직 내에서 새로운 기회를 얻으며 스크럼에 대한 지식을 인정받는 등 개인에게 가치 있는 혜택을 받을 수 있다. CSM 요건 CSM 자격증을 취득하려면 신청자는 먼저 스크럼 프레임워크와 원칙 및 관행을 이해해야 한다. 스크럼 마스터 교육 및 자격증으로 유명한 조직인 스크럼 얼라이언스(Scrum Alliance)는 스크럼 얼라이언스 전문가 블로그, 회원 기사, 동영상, 프레젠테이션, 보고서를 비롯하여 개인이 스크럼 기본을 배우는 데 도움이 되는 다양한 정보를 제공한다. 지원자는 공인 스크럼 강사가 가르치는 2일(16시간)간의 CSM 과정에 참석해야 한다. 이 과정은 스크럼 팀 구성 및 지원 방법에 대한 전체 개요를 제공한다. CSM 과정은 학습 목표를 다루며 여기에는 범위, 린, 애자일, 스크럼, 코칭을 비롯해 개발팀, 제품 소유자, 조직에 대한 서비스도 포함된다. 온라인 과정은 아직 선택 사항이 아니다. 그런 다음 신청자는 스크럼 얼라이언스 포털에서 CSM 시험에 합격해야 한다. 과정을 수강하고 90일이 지난 뒤 시험에 응시하려면 25달러의 비용을 내야 한다. 시험은 2일간 이뤄지며 참석하지 않으면 시험을 볼 수 없다. CSM 시험을 치른 후에는 라이선스 계약에 동의해야 한다. 다음으로 스크럼 얼라이언스 회원 프로파일을 작...

2018.11.02

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.13