조대협의 블로그

Azure Devops 조대협 (http://bcho.tistory.com) 페이스북 타임라인을 보다가. “Azure Devop가 나왔는데. JIRA 따위는 꺼져버려.." 라는 말이 있어서 몬가 궁금해서 살펴봤는데 이거 정말 물건이다. MS가 요즘 많이 변하하고 있다고 들었는데, 정말 잘 만든 제품인듯 Devops라고 해서 Monitoring,Logging쪽 제품으로 생각했는데, Task management, 부하 테스트, git repo & 빌드, 빌드 파이프라인, 웹테스트 툴 등이 들어있는데, 전반적으로 정말 좋은듯. 예전 IBM의 Jazz 플랫폼과 컨셉은 비슷한데, UI나 기능이나 반응 속도나 압권이고 거기다가 일부 플랜은 무료다!! 나 같은 개인 개발자(집에서는)에게는 딱이 아닐까 싶다. 대충 후..

애자일 스크럼과 JIRA를 이용한 구현 방법 근래에 강의했던 스크럼 방법론과 JIRA를 통한 구현 방법에 대한 교육 자료 입니다.상업적 용도가 아닌 사내 교육이나 스터디등으로 자유롭게 사용이 가능합니다. 애자일 스크럼과 JIRA from Terry Cho

애자일 팀 발전 모델에 대하여Functional team, Product Team, Feature Team조대협 (http://bcho.tistory.com) 개요 관리자(CTO)역할을 맏으면서 가장 고민중에 있는 것 중 하나는 팀을 어떻게 모델하여 최적화된 개발팀 구조를 가지느냐 이다.근래의 개발팀의 모델은 애자일 사상에 영향을 받아서 작고, 독립적인 팀의 모델로 진화하고 있으며 대략적인 특징은 다음과 같다.· Self organized· Cross functional· 2 pizza team Cross functional 모델은, 하나의 팀 내에서 기획부터 디자인,개발 및 테스트를 모두 진행할 수 있는 팀 모델로 팀 안에 앱,프론트,백앤드 개발, 기획,테스터와 같은 모든 역할을 하나의 팀내에 모두 가..

스크럼 모델에 대한 고민 요즘 애자일 스크럼 방법론에 대한 회의를 느끼고 있습니다.가장 널리 사용된다는 스크럼 방법론이고, 예전 몇몇 회사에서도 톡톡히 재미를 봤던 방법론이기 때문에 새로운 팀에 스크럼 방법론을 적용하기 위한 시도를 하고 있습니다. 그런데, 이 스크럼 방법론이 동작하지를 않습니다.스크럼의 전제 조건인 즉슨, 스크럼팀이 Product(상품/서비스) 단위로 움직인다는 개념을 가지고 있습니다.즉 특정 기능이나 모듈에 대해서 특정 팀이 계속해서 오너쉽을 가지고 개발을 진행하는 모델로, 이렇게 하면, 상품에 대한 경험이 지속적으로 쌓인다는 장점이 있습니다. 그리고 기획자 (Product Owner : PO)가 팀 내에 있기 때문에 궁극적으로는 각 서비스가 독립적으로 스스로 기획 부터 개발, 테스트..

프로젝트 인셉션에 대해서 원글 : http://www.infoq.com/articles/project-inception-meeting 프로젝트 시작전에, 프로젝트 팀에 대한 alignment를 하기가 어렵다.alignment란 팀이 같은 프로젝트에 대한 배경과 목표를 이해하고, 주요 기능과 일정, 그리고 인원별 역할등 전체적인 프로젝트의 컨텍스를 이해하는 것인데,일반 개발자들은 비지니스쪽 인원을 만나기 힘들 뿐만아니라, 상위 임원들의 방향과 생각을 중간 메니져를 통해서 듣기 때문에, 내용 전달이 부족하거나 오역 되었을때, 팀의 alignment가 제대로 되지 않는 경우가 많다.이런 문제를 해결하기 위해서, 하루 full day로 프로젝트 시작하기 전에 공유하는 회의를 갖는데 이를 프로젝트 inceptio..

왠만큼 바쁘더라도 새로운 것을 공부하거나, 기존에 해왔던 기술들이 어느정도 성숙했다고 느끼면 꼭 글을 써서 블로그에 정리하고는 했는데, 이번달에는 정말 바뻤나 봅니다. 12월인데, 포스팅한 글이 하나도 없네요. 안되겠다 싶어서, 예전부터 프로젝트 사용에 주로 사용하던 jira에 대한 글을 몇일간 정리해서 올립니다. 좀 길기는 하지만 jira를 이용하는 사람들에게 도움이 될거라 생각합니다. JIRA에 대한 소개http://bcho.tistory.com조대협Atlassian의 jira는 버그 트랙킹 시스템에서 시작해서, issue나 Issue 기반의 전체적인 프로젝트 관리를 할 수 있게 하는 툴이다. 클라우드를 이용한 호스팅 서비스와, 설치형 서비스 양쪽을 모두 지원하며, 10 사용자의 경우 설치형의 경우 ..

그간 정리해왔던 ALM에 대해서 전체 그림을 다시 한번 정리하였습니다. 컨버팅 과정에서 폰트가 깨져서 좀 보기가 어려울 수 있습니다. 별도로 자료가 필요하신분들은 요청하시면 보내드리도록 하겠습니다. ALM의 전체 Full Process와 어떤 제품으로 어떻게 구혀하는지, 그리고 구현 전략에 대해서 기술되어 있습니다. 감사합니다. ALM (Application Lifecycle Management) View more presentations from Byungwook.

언제 어떤 코드 리뷰 기법을 사용해야 하는가? 그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야할까? 코드 인스펙션 코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라서 개선안을 찾는 작업이다. 즉, 고도로 훈련됨 팀과 기간이 필요하고, 어느정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다. 인스펙션의 시기는 시스템이 개발되어 있는 시점인 Release이 유용하다. 필자는 두번의 Inspection을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1차 Inspection을 그리고, 개발이 끝난 후 시스템 테스트 (성능,확장성,안정성등)가 그것이다. 1차 Release는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계..

들어가기에 앞서서. 소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임웍의 사용, 개발 패턴들 수 없이 많은 방법들이 있다. 그중에서 개인적으로 생각하건데, 코드리뷰 만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 문서에서는 코드리뷰에 대한 몇가지 기법에 대한 정리와 함께 적용 방법에 대해서 간단하게 소개해보고자 한다. 코드 리뷰의 시초는 Fagan에 의해서 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난후에, 전문 인스펙션팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로스를 코드 인스펙션이라고 한다. 코드 리뷰란, “코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(Defect)를 찾아내고..

요즘 모회사의 차세대 시스템의 오픈을 막바지에 두고, 성능 향상 컨설팅에 나와 있습니다. 주로 하는 작업이 Code Inspection을 통하여 구조 개선 및 성능 개선을 하는 작업입니다. 그런데, 코드를 보면서 이해가 안되는 아키텍쳐가 종종 있습니다. 이런 의도가 아닐텐데 라던지.. 아키텍쳐 구성이 잘못되었다던지. 그런데 이미 구현이 끝나가는 단계에서 이런 아키텍쳐를 변경하기는 거의 불가능합니다. 알면서도 당하는 케이스라고나 할까요? 이미 여러 코드들이 동일 패턴으로 구현이 되어 있기 때문에, 공통부라면 어떻게 변경을 시도해보겠지만, 아키텍쳐적인 문제나, 통신 전문 같은 경우는 변경이 불가능합니다. 결국 울며 겨자 먹기로 CPU를 늘리거나, 다른 부분의 코드를 튜닝해서 목표 성능치를 내야 겠지요. 그런..