Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

애자일

오픈소스컨설팅, ‘애자일 리더’ 교육 온라인 무료 과정 개설

클라우드 및 컬쳐 마이그레이션 전문 기업 오픈소스컨설팅이 ‘애자일 리더(Agile Leader)’ 교육 과정을 출시한다고 밝혔다. ‘애자일 리더’ 교육 과정은 애자일의 기초 개념부터 실제 사례까지 기업이 애자일 전환(Agile Transformation)을 추진하는 데 필요한 전략을 소개한다.   최근 전 산업 분야에서 디지털 전환과 함께 유연한 조직을 이끌기 위한 애자일 전환이 주목받고 있다. 빠르게 변화하는 시장 환경에 기민하게 대응하는 것이 기업 경쟁력을 높이는데 중요한 역할을 하기 때문이라고 업체 측은 설명했다. 이번 과정의 참가자들은 워터폴(Waterfall) 방식과 애자일 방식의 비교 분석을 통해 애자일 개념 및 가치와 원칙을 이해하고, 스크럼과 칸반 같은 애자일 프로세스에 대해 학습할 수 있다. 또한 기업의 리더와 관리자는 조직에서 어떻게 애자일을 시작해야 하는 지에 대한 지식과 인사이트를 얻을 수 있다. 특히, 이번 애자일 리더 교육 과정은 글로벌 금융기업 출신인 오픈소스컨설팅 김대일 애자일 코치가 강의한다. 유수의 금융 기업에서 CTO, CIO, COO를 역임하며 다수의 혁신적인 디지털 전환 및 IT 프로젝트를 수행한 경험을 바탕으로 그간의 노하우를 공유할 예정이다. 오픈소스컨설팅은 애자일 교육 및 컨설팅 분야에 지속적으로 투자하며 사업 영역을 확장하고 있다. 마이그레이션 및 교육 센터인 ‘열린기술공방’을 통해 현재까지 1,200여 명이 넘는 애자일 과정 교육 수료생을 배출하였으며 주요 고객사로는 LG CNS, KB국민은행, 삼성SDS, 한국GM 등이 있다. 특히, KB국민은행의 경우 애자일 전환을 위한 내부 핵심 애자일 코치를 육성하는 프로그램도 진행하고 있다. 또 전 세계에서 가장 많이 사용되는 엔터프라이즈 레벨의 애자일 방법론인 SAFe(Scaled Agile Framework)를 공급하는 스케일드 애자일과 국내 첫 공식 파트너십을 체결하고, 애자일 및 SAFe 도입을 위한 컨설팅 및 교육 서비스를 제공하고 있다. 오...

오픈소스컨설팅 애자일 2022.09.15

활용 격차 뚜렷한 마케팅 자동화 플랫폼의 활용 원칙 7가지

‘마케팅 자동화’를 성공적으로 도입했다고 밝힌 B2B 마케팅 리더가 3명 중 1명도 채 안 된다는 점에서 자동화 플랫폼을 효과적으로 활용하는 방법에 격차가 있는 것으로 조사됐다.  가트너의 수석 애널리트스 제프 골드버그가 ‘가트너 마케팅 심포지엄 엑스포(Gartner Marketing Symposium Xpo)’에서 기술, 환경, 팀 활동을 조합해 마케팅 자동화 플랫폼을 효과적으로 활용할 수 있는 방법을 발표했다.  B2B 마케팅 리더 400명을 대상으로 한 가트너의 설문조사 결과에 따르면 코로나19 위기에 대응해 마테크 투자를 확대했다고 말한 마케팅 리더가 (전체 응답자의) 1/4 이상에 달했지만 마케팅 자동화 플랫폼 활용도가 높다고 답한 비율은 29%에 불과했다. 한편 가트너의 2021년 자료에 의하면 마케팅 예산의 26.6%가 마케팅 기술 개발에 투자됐다.   그렇다면 어떻게 마케팅 자동화 플랫폼의 활용도를 높일 수 있을까? 우선, 기업의 마테크 스택이 충분히 활용되지 않는 이유를 검토하는 게 중요하다. 가트너는 활용도를 촉진하는 데 있어 기술, 환경, 팀이라는 3가지 핵심 요소를 언급하면서, 이와 관련한 주요 장애물을 다음과 같이 소개했다.  “기술 측면에서의 주요 장애물에는 스택 전반의 통합 부족에 따른 시스템 장애, 사용하기 어려운 기능, 적절한 문서 부족 등이 있다. 환경적인 측면에서는 위험 허용 한도의 부족 및 위험을 감수하려 하지 않는 문화가 있다. 팀 측면에서는 사용 사례 개발을 위한 전용 리소스 부족, 스킬 개발 및 교육 부족이 문제다.”  활용도를 높이기 위해 무엇을 하고 있는지 묻는 질문에 56%가 새로운 프로세스 또는 새로운 팀 역량을 구축하고 있다고 답했으며, 43%는 워크샵과 업체 교육에 투자하고 있다고 전했다. 골드버그는 “활용도가 낮은 주요 원인은 저조한 교육 결과”라고 지적했다. 이어 그는 “마테크 업체는 기존 기능을 업데이트할 뿐만 아니라 새로운 기능을 제공한다...

마테크 마케팅 자동화 플랫폼 마케팅 자동화 2022.07.07

하이브리드 업무 환경에서 애자일 스프린트 리뷰ㆍ회고를 개선하는 방법

애자일 방법론을 이용하면 자기조직화 팀이 고객에게 집중하고 증분 형식으로 결과물을 배포하면서 피드백을 활용해 우선순위를 조절할 수 있다. 가장 보편적인 애자일 방법론은 소규모 팀이 1~4주 단위의 스프린트로 작업하는 스크럼(scrum)이다. 이 방법론에 따라 팀은 스프린트에 대해 정해진 양의 작업을 완료하는 데 목표를 둔다.   스크럼의 기본은 단순하다. 우선순위화된 사용자 스토리의 백로그를 리뷰하고 스프린트 중 확실히 완료할 수 있는 작업을 찾아 사용자 스토리에 문서화된 “완료의 정의” 상태를 목표로 둔다. 스크럼 세레모니는 팀 협업에 도움이 되며 보통 제품 소유자, 기술 리드 또는 스크럼 마스터가 정한 스케줄에 따라 반복되는 회의 형식으로 진행된다.   다양한 작업 환경에 맞춰 스크럼 조정하기 팬데믹 봉쇄 중에 스크럼 팀은 줌, 마이크로소프트 팀즈와 같은 툴을 사용해 가상으로 이와 같은 세레모니를 진행했다. 이에 따라 회의 구조도 변화해 가상 참가를 지원하고 유연한 작업 시간을 반영하게 됐다. 오늘날 많은 기업의 숙제는 하이브리드 업무 환경으로 영구적으로 전환하도록 스크럼 세레모니를 조정할 방법을 찾는 것이다. 팀원 중 일부는 사무실에서, 일부는 원격으로 작업한다. 이 같은 하이브리드 작업은 조직과 팀이 애자일 사고방식을 되돌아볼 새로운 기회이기도 하다. 애자일 팀이 하이브리드 작업을 성공적으로 수행해야 할 이유는 명확하다. 최근 실시된 한 설문조사에서 응답자의 40%는 직원의 절반이 매주 3일 이상 원격 근무를 지속할 것으로 예상했다. 또 다른 설문에서는 엔지니어의 75%가 대부분 시간 동안 원격 작업을 선호한다고 답했다. 이제 하이브리드 작업 지원은 개발자를 채용하고 근속시키는 핵심 요소가 됐음을 알 수 있다. 애자일 팀내 영구적인 하이브리드 작업을 원하는 엔지니어도 기업이 스크럼 세레모니를 재편성하고 부가적인 하이브리드팀 데브옵스 권장사항을 검토하도록 적극 협력해야 한다.   시작은 '스프린트 리뷰' 대부분 팀이 도입...

애자일 스프린트 하이브리드워크 2022.05.06

“CI/CD란?” 알기 쉽게 설명한 지속적 통합과 지속적 제공

지속적 통합(Continuous integration, CI)과 지속적 제공(Continuous delivery, CD), 줄여서 CI/CD는 애플리케이션 개발팀이 더 자주, 안정적으로 코드 변경을 제공하기 위해 사용하는 문화와 운영 원칙, 일련의 작업 방식으로 구성된다.  CI/CD는 데브옵스팀을 위한 권장 사항이자 애자일 방법론의 권장 사항이기도 하다. CI/CD는 통합과 제공을 자동화함으로써 소프트웨어 개발팀이 코드 품질과 소프트웨어 보안을 보장하는 동시에 비즈니스 요구사항을 충족하는 데 집중할 수 있게 해준다.       CI/CD의 의미  지속적 통합은 개발팀이 작은 코드 변경을 수시로 구현해 버전 제어 리포지토리에 체크인하도록 유도하는 코딩 원칙이자 일련의 방식이다. 대부분의 현대 애플리케이션에서는 다양한 플랫폼과 툴을 사용해 코드를 개발해야 하므로 팀은 변경을 통합하고 검증할 일관적인 메커니즘이 필요하다. 지속적 통합은 애플리케이션을 빌드, 패키징, 테스트하기 위한 자동화된 방법을 구축한다. 일관적인 통합 프로세스를 두면 개발자는 자연스럽게 더 자주 코드 변경을 커밋하게 되고 이것이 더 나은 협업과 코드 품질로 이어진다.  지속적 제공은 지속적 통합이 끝나는 지점부터 시작되며, 프로덕션, 개발, 테스트 환경을 포함해 선택한 환경으로 애플리케이션을 제공하는 과정을 자동화한다. 지속적 제공은 이런 환경으로 코드 변경을 적용(push)하기 위한 자동화된 방법이다.    CI/CD 파이프라인 자동화  CI/CD 툴은 각 제공 단계에서 패키징해야 하는 환경별 매개변수를 저장하는 데 도움이 된다. CI/CD 자동화는 재시작해야 하는 웹 서버, 데이터베이스 및 기타 서비스를 대상으로 필요한 서비스 호출을 수행한다. 또한 배포 후 다른 절차도 실행할 수 있다.  목표는 양질의 코드와 애플리케이션을 제공하는 데 있으므로 CI/CD에는 지속적 테스트도 필요하다. 지속...

CI/CD 지속적통합 지속적제공 2022.04.20

'애자일은 뭐고 폭포수는 뭐야?' 애자일 방법론 역사 이해하기

요즘은 모든 기술 조직이 어떤 형태로든 애자일 방법론을 실천하거나 그렇게 하고 있다고 믿는 것 같다. 소프트웨어 개발에 처음 발을 들여놓는 사람이든 수십 년 경력자든, 지금 하는 모든 작업이 많건 적건 애자일 방법의 영향을 받는다 해도 과언이 아니다.   애자일은 도대체 무엇이고, 개발자와 조직이 애자일 방법론을 도입하려면 어떻게 해야 하는 것일까? 애자일 개발의 역사, 전통적인 폭포수 방법론의 차이점을 간략히 알아보자. 애자일과 폭포수 방법론의 차이점을 실무 관점에서 살펴보고, 특히 오늘날의 개발 환경에서 개발자와 팀이 작업할 때 왜 애자일이 훨씬 더 나은 방법인지를 설명한다.     애자일 이전 : 폭포수 방법론 폭포수 방법론이 소프트웨어 개발의 금본위였던 시절을 기억하는 사람이 아직 있을 것이다. 폭포수 방법론을 사용하려면 코딩을 시작하기 전에 상당한 문서 작업이 필요했다. 보통 비즈니스 애널리스트가 애플리케이션에 필요한 기능을 정리한 비즈니스 요구사항 문서를 작성하면서 프로세스가 시작됐다. 이 문서는 길고 세부적이며, 전체 전략부터 포괄적 기능 사양, 사용자 인터페이스 시각 디자인에 이르기까지 모든 요소를 포함했다.   기술자는 이 비즈니스 요구사항 문서를 사용해서 애플리케이션의 아키텍처와 데이터 구조, 객체 지향 기능 설계, 사용자 인터페이스, 기타 비기능적 요구사항을 세부적으로 정의한 기술 요구사항 문서를 작성했다.   비즈니스와 기술 요구사항 문서가 완성되면 비로소 개발자가 코딩을 시작한다. 이후 통합을 거쳐 마지막으로 테스트가 이어졌다. 애플리케이션이 프로덕션 단계에 이르려면 이 모든 과정과 작업이 먼저 마무리되어야 했다. 전체 프로세스가 완료되기까지는 몇 년이 걸리는 것도 흔한 일이다.   실무에서의 폭포수 방법론 폭포수 방법론에 사용된 문서를 ‘사양’이라고 했는데, 개발자는 문서를 작성한 당사자들 못지않게 이 사양을 철저히 파악해야 했다. 예를 들어 200페이지짜리 문서의 77페이지에 ...

폭포수 개발 방법론 폭포수모델 애자일 2022.04.12

'기초부터 다시 시작하는' 애자일 방법론의 이해

애자일(Agile) 방법론이 등장한 지 2021년을 기준으로 꼭 20년이 됐다. 일부 스타트업이 공동 장소에서 스티커와 화이트보드를 가지고 협업하던 비주류 방법론이 이제는 정교하고 확장성 있고 널리 쓰이는 애자일 소프트웨어 개발 프로세스와 툴로 발전했다.   애자일 개발은 오랜 기간 사용되고 많은 기업이 스크럼, 칸반 등의 애자일 기법을 이용해 애플리케이션을 현대화하고 고객 경험을 개선하고 디지털 트랜스포메이션을 이행하는 데는 그만한 이유가 있다. 디자인 씽킹, 제품 관리, 데브옵스와의 접점에 대한 방대한 지식이 쌓이는 것도 같은 맥락이다. 이제 사람들은 ‘애자일이 무엇인가?’라고 묻지 않는다. 오히려 자기 팀에 최고의 애자일 방법론을 적용할 방법을 활발하게 논의한다. 여기서는 다시 기본으로 돌아가 사람과 팀, 프로세스, 툴과 함께 애자일 방법론의 기초를 알아본다. 또한, 애자일이 데브옵스와 어떻게 연결되는지 살펴보고, 애자일 문화를 양성하고 고품질의 소프트웨어를 완성하는 모범 관행을 소개한다.   애자일 방법론에서의 주요 역할들 애자일 소프트웨어 개발 프로세스는 언제나 특정 제품의 사용자를 정의하고, 다뤄야 할 문제와 기회, 가치의 범위에 관한 비전을 문서화하며 시작한다. 제품 소유자(Productowner)는 이 비전을 포착하고 이를 달성하기 위해 다양한 팀과 협업하며 애자일 개발 프로세스에는 여러 역할이 관여한다. 사용자 : 애자일 프로세스는 언제나 사용자(User) 또는 고객을 염두에 두면서 시작한다. 오늘날에는 일반적으로  고객 요구 및 행동의 다른 워크플로우 역할/유형을 정형화한 사용자 페르소나(User Personas)를 정의한다. 제품 소유자 : 제품 소유자는 내부 이해관계자 등 고객의 목소리를 담당한다. 통찰, 발상, 피드백을 종합해 제품 비전을 만든다. 보통 제품 비전은 단순하고 직접적이지만, 고객 또는 사용자가 누구이고, 어떤 가치를 다루는지, 이들을 다루는 전략에 대한 전체 그림을 반영한다. 예를 들면 ...

애자일 agile 2022.04.11

'선택적 집중을 위한' 애자일 및 앱 개발 회의 개선의 필요성

많은 개발자가 자기 조직화된 애자일 팀에 소속돼 혁신적인 솔루션을 개발하는 것을 좋아한다. 이들은 스프린트 리뷰에서 문제 논의, 장애물 해결, 회고, 결과 공유의 필요성도 인지하고 있다. 하지만 개발자는 너무 많은 회의에 참석하거나 제대로 관리되지 않는 회의에 시간을 낭비하는 것을 극히 싫어한다. 쏟아지는 긴급 이메일과 즉흥적인 줌 회의, 잦은 슬랙 메시지는 생산성을 갉아먹을 수 있다. 코딩은 집중이 필요한 작업이다. 산만함은 소프트웨어 결함과 품질 문제로 이어질 수 있다.     회의 관행 및 방식 점검 애자일과 스크럼 초창기에는 화이트보드와 포스트잇을 사용해 백로그를 관리했지만 지금은 많은 팀이 지라 소프트웨어(Jira Software)와 digital.ai, 애저 데브옵스(Azure DevOps) 등 애자일 툴로 이런 아날로그 방식을 대체했다. 많은 애자일 전문가가 개방된 공간에 여러 팀이 모여서 작업하는 방식을 선호하지만 지리적으로 분산된 팀 환경에서의 애자일을 위한 지침도 많다. 어쩌면 지금이 바로 하이브리드 환경에서의 회의 방식을 점검해야 할 때일지도 모른다. 링크드인(LinkedIn) 생산성 엔지니어링 부문 부사장 사브리 토진은 “최상의 툴을 사용하는 것은 엔지니어링 및 개발자 커뮤니티에서 중요하며, 개발자의 행복과도 직결된다. 개발자는 중단 없이 작업을 완료하는 것을 선호하기 때문에 하이브리드 환경의 조직은 더욱 매끄러운 하이브리드 작업 경험을 실현하면서 인재를 유인하고 보존하는 툴에 투자해야 한다”라고 말했다. 데브그래프(DevGraph) 최고 제품 책임자인 라비 두두쿠루 역시 토진과 입장을 같이하며 개발 관리자와 제품 소유자, 스크럼 관리자가 회의 관리 방식을 조정해야 하며 시간과 의제를 관리하는 것은 더욱 중요하다고 말했다. 두두쿠루는 “모두가 사무실에서 일했던 시절에는 스탠드업 미팅으로 회의의 효율성을 달성했다. 원격 애자일 및 앱 개발 회의에도 동일한 방법을 적용해야 한다. 목적과 의제가 명확하고 모두가 무엇...

애자일 앱개발 회의 2022.03.23

성공적인 소프트웨어 개발 관리를 위한 7가지 조언

필자는 최근 ‘하이브리드 근무 체제 속 전문 개발자 채용 및 고용 유지를 위한 최선의 방법 4가지’에서 의사소통 개선, 다양성 추구, 워라밸 지원과 같은 다양한 조언을 했다. 조직의 리더는 팀과의 소통을 늘리면서 개인이 최선을 다할 수 있도록 권한을 부여하고, 신뢰해야 한다.    이런 방법은 중요한 리더십 목표이지만, 소프트웨어 개발자와 딜리버리 담당자, 그리고 애자일팀 사이의 일상적인 상호작용에서는 적용하기 어려울 수 있다. 필자는 여러 전문가에게 개발 관리자, 팀 책임자, 데브옵스(DevOps) 책임자, 데이터 사이언티스트 매니저를 위한 조언을 구했다. 마이크로매니지먼트(micromanagement) 없이 소통과 생산성을 높일 수 있는 방법을 7가지로 정리했다. 목표를 전달하고 공감을 얻어라 소프트웨어 개발업체 업레벨(Uplevel) CTO 라브스 카우르는 개발 관리자가 항상 릴리즈나 스프린트마다 더 많은 기능을 제공해야 한다는 압박을 받고 있음을 인지했다. 카우르는 “동기 부여와 동감의 균형을 맞추고 인간적인 유대감을 형성하라. 엔지니어링 관리자는 목표를 설정하고 개방적인 의사소통을 하는 것처럼 다양한 방식으로 팀원을 지원할 수 있지만, 무엇보다 가장 영향력 있는 행동은 ‘공감’이다”라고 말했다. 공감하는 리더십은 코로나19 팬데믹으로 인해 주목받고 있다. 카우르는 “지난 2년 동안 우리의 개인적인 삶과 직장 생활이 얽히게 됐고, 팀원 모두에게 공감이 필요한 문제가 있음을 이해하는 것이 관리자로서 중요하다. 인간적인 유대감이 없으면 팀원은 고립감과 불만을 느끼고 결국 회사를 떠난다”라고 조언했다. 스트레스로 인한 개발자의 번아웃을 방지하라 공감에서 한 걸음 더 나아가기 위해서는 소프트웨어 개발 관리자가 팀원의 ‘번아웃’ 증상을 인지해야 한다. 생산성 저하나 동료에 대한 냉소적인 반응 증가, 회사와의 거리감이 대표적인 번아웃 징후다. 기능 플래그 관리 솔루션 업체 런치다클리(LaunchDarkly)의 개발 마케팅 관리자 던 파...

애자일 소프트웨어개발 개발자 2022.03.04

애자일 업무 역량 계획을 세울 때 던져야 할 5가지 질문

애자일 매니페스토는 ‘프로세스와 툴보다 개인과 상호작용’에 더 가치를 둔다. 창안자의 핵심 원칙은 “최선의 아키텍처와 요구사항 및 설계는 자기조직화(self-organizing)가 된 팀에서 나온다”는 것이다. 필자도 이 원칙에 동의하지만, 실제 환경에서 자기조직화 팀이 어떻게 움직여야 하고, 최선의 결과를 달성하는 과정에서 의사결정 권한이 얼마나 도움이 되는지에 관해서는 실용적인 관점으로 접근해야 한다.   예를 들어 팀이 이상적인 아키텍처를 선택해 설계할 권한을 얻는다면 성과도 최적화되겠지만, 20개에 달하는 팀이 모두 각각 독립적인 아키텍처를 관리한다면 조직 관점에서는 상당한 골칫거리다.   또한, 프로세스와 툴이 더욱 개인과 원활하게 상호작용할 필요도 있다. 백로그 상태를 캡처하고 사용자 스토리를 표준으로 범주화하며 아키텍처를 문서화하면 팀 상호작용을 개선하고 회의에 소비하는 시간을 줄이는 데 도움이 된다.   애자일 자기조직화 팀에는 업무 역량 계획이 필요 애자일 업무 역량 계획은 많은 애자일 팀에서 기피하는 영역이다. 업무 역량 계획은 사람마다 생각하는 뜻이 다르므로 업무 역량 분석을 요청하거나 기술 공백 계획을 수립할 때는 맥락이 필요하다. 또한 업무 역량 계획 방법은 프로그램 관리 및 시스템 엔지니어링 분야에서 처음 개발됐는데, 이 분야는 애자일과 반대되는 영역으로 인식되는 경우도 있음을 생각해야 한다.   난점은 조달, 온보딩, 통합에 리드 시간이 필요하기 때문에 인력, 기술, 파트너십 등 애자일 팀에 필요한 요소 상당수에 사전 예측이 필요하다는 것이다. 애자일 리더는 업무 역량 계획을 생산성을 개선하고 무력감을 방지하고 데브옵스 투자에 대한 지지를 얻고 목표를 가로막는 장애물을 줄일 기회로 생각해야 한다.   그 외의 시간에는 애자일 팀은 비즈니스 관계자와 파트너가 되어 예정된 결과물에 대한 시야를 제공해야 한다. 팀의 속도와 생산성에 영향을 미칠 수 있다는 면에서 업무 역량 계획도&n...

애자일 CI/CD 프로세스최적화 2022.01.12

데브옵스에 애자일과 ITSM 도구가 통합되어야 하는 3가지 이유

데브옵스 원칙을 따르고 데브옵스 문화로 전환하려는 조직이 점차 늘어나고 있다. 데브옵스의 주 실행법에는 버전 제어, 지속적 통합 및 배포(CI/CD), 코드형 인프라(IaC), 머신러닝을 운영에 적용하기(AI옵스), 지속적 테스트 등이 포함된다. 더 발전 팀은 지속적 계획, 클라우드 네이티브 애플리케이션 설계, 마이크로서비스 개발, 기능 플래그를 사용한 코드 제어, 보안의 시프트 레프트 촉진, 서비스 수준 목표 설정, 오류 예산 관리, 데이터 지향성 강화 등에도 초점을 둔다.   위의 각 실행방법은 데브옵스 조직의 두 가지 주요 IT 기능인 개발(새 애플리케이션 구축하기, 품질 향상 자주 릴리스하기)과 운영(비즈니스 시스템, 데이터베이스, 애플리케이션의 안정성과 성능 보장하기)을 바꾸는 데 도움이 된다.   데브옵스를 데브섹옵스(DevSecOps)로까지 확장하고, 보안을 다른 요소와 동등한 지위에 올려두는 조직도 늘고 있다. 데브섹옵스의 주요 IT 실행방법에 필요한 요소로는 경쟁에 필요한 속도와 민첩성, 비즈니스 운영에 필요한 혁신, 안정성, 보안, 성능간의 균형을 들 수 있을 것이다.   데브옵스 협업에는 애자일 및 ITSM 도구 통합이 필요하다 데브섹옵스 실행방법 하나만 가지고는 개발과 운영, 보안 기능을 결합해 목표 달성에 필요한 협업을 완성할 수 없다. 각 기능을 포괄하는 워크플로우를 구현, 추적하고 측정해야 한다.   많은 조직에서 이런 워크플로우는 스크럼, 칸반 등 개발 팀에 사용되는 애자일 방법론과 요청 관리, 사고 관리, 문제 관리, 변경 관리, 구성 관리 데이터베이스(CMDB) 유지보수, 그리고 운영 팀이 관리하는 IT 서비스 관리(ITSM) 실행방법을 결합해 실행된다.   그러나 애자일과 ITSM 도구를 통합하는 조직은 많지 않다.   개발 팀은 애저 데브옵스, Digital.ai, 지라 소프트웨어, 기타 애자일 도구로 개발 프로세스에서 사용자 스토리, 스프린트, 릴리스의 백로그를 관...

데브옵스 애자일 ITSM 2021.11.17

최소 기능 제품, MVP에 던지는 5가지 질문

실리콘 밸리의 많은 혁신 방법과 용어는 독일 기업에는 새로운 영역이다. 최소 기능 제품(Minimum Viable Product)이라는 용어 역시 마찬가지다. 이와 관련된 가장 중요한 5가지 질문과 대답을 살펴보자.   다음 그림에는 두 가지 전혀 다른 스위스 아미 나이프가 있다.   왼쪽의 스위스 아미 나이프는 87개 도구와 141가지 기능을 가진 “콜렉터 나이프”라는, 실제로 존재하는 제품이다.. 상상할 수 있는 모든 상황에서 유용한 도구를 제공하지만 일상적인 용도로는 썩 적합하지 않다. 필자는 오래전에 약 1,000유로를 주고 이 제품의 한정판을 구매했다. 이제 더 이상 생산되지 않는 모델이다. 지금은 필자의 사무실에 는데 실제 사용하는 제품이 아닌 장식품에 가깝다.   오른쪽 제품은 코르크 따개, 병따개, 나이프의 세 가지 기능으로 축소된 간소한 모델이지만 일상 생활에서 유용하다. 바텐더가 일하는 데 필요한 모든 도구를 갖추었다고 해서 보통 “바텐더 나이프”로 불린다. 대략 15유로에 구매가 가능하며 전 세계적으로 수백만 개가 팔린 모델이다.   적은 것이 더 좋을 때가 많다 사실 첫 번째 모델은 엔지니어링의 나라 독일에서 많은 기업이 앓고 있는 질병인 “기능추가 집착증”에 해당한다. 일반적으로 새로운 제품 개발을 위해 프로젝트 팀이 구성되면 팀은 몇 개월, 심지어 몇 년에 걸쳐 비밀스럽고 복잡한 과정을 통해 완벽을 추구하는 제품을 개발한다.   많은 기업은 모든 잠재고객의 모든 요구사항을 충족하기 위해 너무 많은 기능을 동시에 제공하는 실수를 저지른다. 그 결과는 고객에게는 실제로 필요 없는 온갖 기능으로 무장한 지나치게 값비싼 제품이다. 그 사이 실질적 타겟 그룹의 실질적인 요구사항은 간과되는 경우가 많다. 솔직히 말해 톱과 손톱 줄, 코르크 따개가 동시에 필요할 일이 있는가? 전혀 필요 없는 기능은 무엇인가? 이런 생각에서 나온 것이 두 번째 나이프에서 볼 수 있는 MVP 방법이다.  &nb...

최소기능제품 애자일 2021.10.26

Smart CIO : 디지털 민첩성의 효과

지난해 발생한 글로벌 팬데믹은 전 세계를 완전히 바꾸어 놓았습니다. 사회적 거리 두기는 일상의 소통을 축소시켰을 뿐만 아니라, 점점 더 많은 직원이 원격 근무를 시작하면서 일의 성격도 변화시켰습니다. 어느 지역에서 활동하든 간에, 당분간은 이 새로운 환경에 적응해야 합니다. 그리고 CIO는 미래 IT 계획의 중요성을 실감해야 합니다. Workday에서 발행하는 계간지인 Smart CIO에서는 “디지털 애질리티의 효과 -확장 가능한 비즈니스 연속성” 이라는 주제로 현실의 애질리티를 조명했습니다. 디지털 혁신의 속도를 높이는데 강력한 리더십이 중요한 이유에 대해 다양한 경험을 가진 업계 리더들의 통찰력 있는 인사이트를 들어 보았습니다.<28p> 주요 내용 - 애자일 정부를 지향하는 디지털 정부 혁신 - 애자일 캠퍼스 혁신: 학생 중심의 거대한 변화에 대응하는 CIO의 역할 - 아시아 태평양 지역의 디지털 민첩성 진단:인식의 부족 - 불의의 사태에 대비하는 3가지 전략 - 예측 불가의 비즈니스 변화에 대비하는 BPO 기업의 노하우 - 농식품 업계 CIO가 생각하는 애자일 조직: 하림그룹 CIO 최인경 전무 인터뷰

애자일 민첩성 디지털트랜스포메이션 2021.07.21

깃옵스가 '아직' 주류로 부상할 준비가 되지 않은 이유

깃옵스(Gitops)는 2017년 처음 고안된 이후, 특히 요즘 유행하는 분산 컨테이너 전반에 배포되고 쿠버네티스(Kubernetes)에 의해 조율되는 마이크로서비스를 구축하는 기업에서 데브옵스, 코드형 인프라, CI/CD 원칙과 같은 현대 소프트웨어 개발 방식의 자연스러운 발전 방향으로 부상했다. 그러나 업계에서 깃옵스가 애자일 및 데브옵스가 지금까지 이룬 규모의 주류 기술로 채택되기 위해서는 업계가 극복해야 할 여러 중대한 문화적, 기술적 장애물이 아직 남아 있다.   깃옵스란 무엇인가? 깃옵스는 데브옵스를 더욱 확장해 코드를 인프라로 다뤄 애플리케이션과 기반 인프라가 코드로 취급되고 버전 제어 시스템(주로 깃)에 저장되어 개발자와 운영자에게 단일 진실 공급원(single source of truth)을 제공할 수 있도록 한다. 제대로 구현되면 모든 변경 사항이 선언형 코드를 통해 푸시되고, 바람직한 상태로부터 이탈되는 경우 자동화된 단계를 통해 교정된다. 이론적으로는 흠잡을 데가 없지만, 펠로톤(Peloton), 볼보(Volvo), 티켓마스터(Ticketmaster), 저스트 잇 테이크어웨이닷컴(Just Eat Takeaway.com) 등 깃옵스 방식을 테스트 중인 것으로 알려진 기업 가운데 어느 한 곳도 현재 단계에 대해 본지와의 인터뷰에는 응하지 않았다.  IDC의 데브옵스 솔루션 부문 연구 책임자인 짐 머서는 “깃옵스 이니셔티브를 도입 중인 기업과 대화를 해본 적이 없다. 내가 대화를 나눈 기업은 깃옵스라는 말을 들어본 적도 없는 경우가 대부분”이라고 말했다. 2018년 컨테이너 기술 전문업체 애플라틱스(Applatix)를 인수한 후 깃옵스 조기 도입 기업이 된 핀테크 업체 인튜이트(Intuit)의 내부 개발자 플랫폼 부문 제품 관리 책임자인 무쿨리카 카파스는 “깃옵스의 성숙도는 여전히 초기 단계”라고 말했다. 그보다는 소규모 클라우드 네이티브 기업이 소프트웨어 제공 프로세스를 개선하기 위한 깃옵스의 가능성을 탐색하기...

깃옵스 Gitops 컨테이너 2021.05.12

'기술·문서 부채를 남기지 않으려면' 애자일에서 지식관리가 중요한 이유

“철저한 문서보다 제대로 작동하는 소프트웨어가 우선”, 애자일 선언(Agile Manifesto)에 명시된 두 번째 가치다. 이 선언의 서명자들은 기존 폭포수(waterfall) 소프트웨어 개발 프로젝트와 밀접하게 연관된 비즈니스 및 기술 요구사항 문서에 맞서 저항했다. 이들은 많은 소프트웨어 개발 프로젝트에서 이러한 문서가 실패와 좌절을 나타내는 신호라는 사실을 간파했다. 작성하는 데 너무 많은 시간이 걸렸고 이해하기에도 너무 복잡했으며 개발팀이 문서를 검토할 시점이면 이미 내용의 유효기간이 지난 경우가 많았다.   애자일 방법론의 성공과 인기의 이유 중 하나는 이해관계자와 개발팀의 협업 방식이다. 이해관계자가 (대부분의 경우 개발팀의 의견 반영 없이) 긴 요구사항 문서를 쓰는 대신 지속적인 계획, 사용자 스토리 작성, 스토리 추정, 스프린트 약속 및 기타 애자일과 스크럼 작업에서 계속 협업이 이뤄진다. 그러나 이 원칙을 지나치게 확대해서 애자일팀에는 문서가 필요 없거나 문서를 만들지 않아도 된다고 주장하는 사람도 일부 있다. 이와 같은 주장에는 나름대로 이유가 있다. 특히 이해관계자와 제품 소유자가 개발팀을 신뢰하지 못해 신뢰 대신 세부적인 문서를 요구하는 경우가 그렇다. 또한 지금은 기술자의 개발 플랫폼 및 워크플로우와 통합되는 툴이 있지만, 애자일의 첫 10년 성장기 동안에는 지식 자료를 만들고 유지 관리하고 검색하고 사용하는 과정이 지금처럼 편리하지 않았다.   문서를 만들고 유지해야 하는 이유 현재 기업은 과거와는 비교할 수 없을 만큼 많은 소프트웨어를 개발하고 데브옵스팀은 수시로 변경을 릴리스한다. 따라서 지식 관리와 기술 문서 유지보수는 매우 중요하다. 사람들은 데브옵스팀이 API를 만들고 클라우드 네이티브 애플리케이션과 다른 시스템을 통합하고 장기간에 걸쳐 기능을 개선할 것으로 기대한다. 또한 이해관계자는 사고, 보안 문제 또는 기타 결함이 발생하면 애자일팀이 손쉽게 문제를 수정해 변경 사항을 릴리스할 것으로 믿는다...

문서부채 애자일 데브옵스 2021.03.24

지금 클라우드가 필요한 이유 : IT 리더를 위한 가이드

급변하는 글로벌 환경에서 기업의 운영 상황은 복잡할 뿐만 아니라, 과거와 달리 빠르게 변화하고 있습니다. 이에 대응하여 기업과 조직은 효율성 제고 및 수익 증대를 목표로 운영의 모든 요소를 새롭게 구상하는 한편 탄력적인 애자일 조직을 구축하려 합니다. 갑작스러운 변화를 초래하는 코로나19 같은 자연재해와 글로벌 위기가 닥치면 운영상의 복잡성은 훨씬 더 커집니다. 전례 없는 변화에 직면한 지금, 최고정보책임자(CIO)를 비롯한 기술 리더들은 탄력적인 운영을 위해 조직의 역량을 집중할 분야를 결정하기 위해 고심하고 있습니다. 이 가이드에서는 기본에 충실하여 혁신을 이끌어 내는 방법, 그리고 진정한 클라우드로 구현되는 IT 코어의 ROI를 자세히 알아봅니다. 주요 내용 - 클라우드 아키텍처의 중요성  - 애자일 조직에 최적화된 핵심 비즈니스 시스템  - 직원의 참여도를 높이는 단일 경험  - 유용한 보안 기능과 신뢰할 수 있는 데이터 보호  - 모든 고객이 단일 커뮤니티와 단일 서비스 경험 사용

애자일 참여도 코로나19 2021.01.27

개발자 생산성을 측정하는 최고의 방법과 최악의 방법

개발팀에 지라 소프트웨어(Jira Software), 애저 데브옵스(Azure DevOps) 또는 사용 중인 다른 애자일 관리 툴에서 시간을 캡처하도록 지시한다는 말을 들을 때마다 필자는 깜짝깜짝 놀라곤 한다. 시간 확인은 계약에 따라 고객에 비용을 청구하는 서비스 부서에는 정상적인 일이고 필요한 부분도 있다. 그러나 이런 회계적 지표를 이용해 개발 생산성을 정량화하는 것은 낡은 지휘 통제식 관리 관행에서 이어진 좋지 않은 관습이다.   개발 생산성을 정량화하는 데 사용되는 지표 중 문제가 있는 것은 또 있다. 완성한 코드 라인 수로 생산성을 산출하는 방식이다. 기업 인프라를 지저분한 코드 베이스의 '기술적 부채' 속에 파묻도록 사실상 개발팀을 독려하는 방법이다. 제공된 사용자 스토리 또는 스토리 포인트의 수로 측정하는 것은 어떨까? 개발자에게 기능을 더 많은 스토리로 쪼개 스토리 포인트 추정을 부풀리라고 지시하는 것과 다르지 않다. 완료된 릴리스의 수를 파악하는 방법은 그나마 낫지만 이 역시 부가적인 확인이 필요하다. 결함이 포함되거나 중대한 사고를 유발하거나 최종 사용자 경험의 질이 떨어지는 프로덕션 릴리스는 성공적인 릴리스와는 다르게 평가돼야 하기 때문이다. 이처럼 소프트웨어 개발 생산성을 측정하는 데는 많은 어려움이 있다. 필자는 이런 업무의 전문가인 맥밀란 러닝(Macmillan Learning)의 부사장 사가르부지발과 이야기한 적이 있는데, 그는 잘못된 평가 기준은 팀 사기를 저하할 수 있다며 다음과 같이 경고했다. "오류, 전달 지연 또는 사고의 수에 따라 개발자 생산성을 측정해서는 안 된다. 이 경우 더 많은 기능을 더 빨리, 더 효과적으로 제공해야 한다는 압박에 항상 시달리는 개발팀에 불필요한 불안을 야기한다. 대신 심리적 안정감을 주고 운영 프레임워크를 지속해서 정렬하고 엔지니어링 방식을 개선해야 한다" 여기서는 소프트웨어 개발자와 개발팀에 합리적인 생산성 지표를 적용해 이들의 (발목을 잡는 것이 아닌) 생산성과 사기를 높...

개발자 성과평가 애자일 2021.01.21

'IT 개발에 비즈니스 맥락을'… 애자일 '가치 흐름' 사용 방법

많은 기업이 디지털 트랜스포메이션에 적극적으로 투자하면서 고객의 요구에 부합하는 기능을 더 많이 제공하기 위한 문화를 구축하고 있다. 그러나 비즈니스 가치를 이해하고 노력의 초점을 고객의 혜택에 맞추기는 어려운 일이다.   소규모 IT 조직의 애자일 개발팀이나 새로운 애플리케이션을 개발하는 팀이 제공하는 가치를 이해하기는 비교적 쉽다. 이와 같은 팀은 기능 완성 속도, 릴리스를 얼마나 적시에 배포하는지, 그리고 프로덕션에서 발견된 결함의 수 등을 통해 품질을 평가할 수 있다. 또한 소규모 조직은 툴에 내장된 기본 보고서를 사용해 여러 평가 지표를 조합할 수도 있다. 예를 들어 애자일팀은 에픽 번다운 보고서 또는 IT 서비스 관리 툴의 사고 관리 지표를 사용해 비즈니스 영향을 분석할 수 있다. 그러나 수백 개의 프로덕션 애플리케이션을 지원하는 대규모 IT 조직에서 이런 지표를 정의하고 활용하는 과정은 복잡하다. 10개의 릴리스와 100개의 기능을 완성했고 프로덕션에서 발견된 결함의 수가 10% 줄었다고 기뻐할 수는 있지만, 여기에는 유의미한 비즈니스 맥락이 빠져 있다. 많은 팀에 걸쳐 지표를 공유하고 세부적인 비즈니스 영향을 설명하는 것도 비효율적이다. 마지막으로, 대규모 IT 조직은 위험 대처, 기술 부채 감소, 결함 수정 등 기능 이외의 작업에 대해서도 다른 팀에 알려야 한다. 이럴 때 '가치 흐름(value stream)'은 대규모 조직의 디지털 및 IT 리더가 비즈니스 가치, 전략적 동인 또는 장기적인 목표에 관한 하향식 주요 성과 지표를 보여주는 데 도움이 된다. 이 방법론과 평가 지표는 작업이 어디서, 어떻게 이뤄졌는지 추상화하고, 리더의 프레젠테이션은 비즈니스에 영향을 미치는 진행 상황에 초점을 맞춘다. 또한 IT 리더는 아키텍처, 보안 또는 데브옵스와 같은 기술 영역 '내부적인' 투자에 따른 혜택을 보여주는 데도 가치 흐름을 사용할 수 있다.   비즈니스 영향을 보여주는 가치 흐름 정의와 매핑 리더는 먼저 유의미한 가치 흐...

애자일 가치흐름 2021.01.12

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

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

Copyright © 2022 International Data Group. All rights reserved.