IT/Agile
-
애자일 개발을 위한 팀 회의 규칙 6가지IT/Agile 2016. 3. 6.
회의는 2명 이상이 모여서 특정 주제에 대하여 논의하는 것을 의미한다. 즉 여러 사람이 모여서 이야기 하는 것이기 때문에 최소한의 규칙을 정하지 않으면 결론이 이상해지거나 결론 없이 시간만 소비하는 회의가 될 수 있다. 2015/04/07 - [일상/생각] - 회의를 효과적으로 이끌어 갈 수 있는 5가지 방법작년에 작성한 5가지 방법에 대해서 규칙을 6가지로 확대하였다. 이유는 개발 팀내의 회의에서는 기존 5가지뿐만 아니라 추가적인 규칙이 필요하다고 느꼈기 때문이다. 기존 5가지에 대해서도 불필요한 단어는 삭제하였고 생각이 바뀐 문장에 대해서도 변경하였다. 1. 우선, 회의 참석자들에게 회의 주제와 내용을 미리 공유한다. 빠른 회의 진행을 위해서는 진행할 주제를 미리 공유하는 것은 필수적이다. 아무런 준..
-
일일스크럼은 왜 해야하나요?IT/Agile 2016. 1. 25.
일일 스크럼 일일 스크럼이란 말 그대로 매일 정해진 시간에 행하는 회의로써 팀 구성원들은 진행한 일, 오늘 진행할 일, 그리고 업무 진행에 있어서 장애사항을 공유해야 한다. 일일 스크럼은 왜 해야 할까? 사실 스크럼을 진행하게 되면 업무 진행사항은 보드를 통해서 업데이트 된다. 일일 스크럼에서 이야기하는 진행한 일이나 오늘 진행할 일은 보드를 통해서 확인할 수 있거나 유추할 수 있다. 그럼에도 불구하고 팀원이 모두 모여서 회의를 해야 하는 이유는 무엇일까? 그 이유는 애자일 선언문을 보면 알 수 있다. 애자일 선언 아래는 애자일 매니페스토 사이트에서 가져온 애자일 선언 내용이다. 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다. 이 작업을 통..
-
애자일 스크럼의 시작을 되돌아보며IT/Agile 2016. 1. 14.
주변 동료들과 애자일 이야기를 하면서 우리 팀이 애자일을 어떻게 시작하게 되었는지를 회상하게 되었다. 나의 생각을 정리할 겸, 경험한 여러가지 중에서 애자일을 도입하게 된 배경과 변화들을 이야기하려 한다. 배경 지금도 그렇지만 약 2년전에도 업무와 관련되어 추정을 실패하거나 계획의 변경은 자주 일어났다. 우리는 연간 해야할 일을 계획한다.놀랍게도 매달 새로운 해야할 일이 탄생한다.생물처럼 이슈들이 계속 증식하고 발생한다. 연간 2-3회 최소 1달이상은 연속으로 야근하게 만드는 높은 중요도와 긴급도를 갖는 이슈들이 탄생한다. 연말에 1년간의 일을 되돌아보면 계획한 일들의 내용은 많이 바뀌어 있었다. 예상되지 못하는 일들이 우리를 힘들게 했는데, 특히 유지보수를 위한 비용이 많이 들었다. 이 과정에서 나를 ..
-
애자일 스크럼은 생각보다 어렵다IT/Agile 2015. 12. 3.
개발팀에서 이제는 전통적인 waterfall 방식을 사용하는 경우는 많지 않을 것 같다. 스크럼은 애자일 개발 프로세스 중 하나를 말한다. 개인이 아닌 팀으로 활동하게 된다면 대부분 애자일 프로세스를 알거나 취하고 있을 것이다. 임기 응변식의 대응이 아닌, 체계적이고 변화에 대응하기 위해 팀에서 약 1년 반동안 스크럼을 반영하고 활용해가면서 느꼈던 여러가지를 글로 남긴다. 무엇이 좋은가?첫째, 스프린트 계획 회의를 통해서 팀 전체가 정량의 업무를 정하고 논의할 수 있다. 둘째, 매일 스크럼(Daily scrum) 회의를 통해서 팀원간 업무 진행을 잘 알 수 있고 필요한 사항들을 공식적으로 요청할 수 있다. 셋째, 개발자 본인이 능동적으로 할당받은 업무에 대해서 세부 할 일들을 계획하고 실행할 수 있다.특..
-
회의를 효과적으로 이끌어 갈 수 있는 5가지 방법IT/Agile 2015. 4. 7.
효과적인 회의를 위해서 고려해야할 것이 뭐가 있을까 고민하다가 이야기들을 적는다. 결국 회의에서는 효율적인 의사 소통이 핵심이겠지만, 미리 준비할만한 사항이나 회의를 진행하면서 꼭 지켜줘야하는 규칙들이 있다. 1. 우선, 회의 참석자들에게 회의 전 어떤 주제로 이야기를 할 것인지를 공유한다. 빠른 회의 진행을 위해서는 진행할 주제에 대해서 미리 공유하는 것은 필수적이다. 고민해볼만한 사항들도 함께 제시해준다면 이야기가 빨리 진행될 것이다. 또한 회의 초대할 때 정말로 필요한 사람인지 고민해봐야 한다. 회의는 아이디어 생산, 지식 공유, 의사 결정등 많은 장점이 있지만 항상 많은 사람들을 회의에 참석 시킨다면 일을 하기보다는 회의를 진행하느라 시간을 낭비하게 될 것이다. 2. 회의를 시작할 때에는 목적과 ..
-
XP(eXtream Programming) - 3IT/Agile 2011. 2. 5.
프로젝트와 소프트웨어의 기민함을 최대화 하기 위해서 XP는 일련의 프로세스보다 기본원리를 강조한다. [XP의 기본적인 원리] 1. 개발원리 1-1 Pair Programming 모든 프로그래밍은 하나의 컴퓨터에 2명의 프로그래머가 같이 공동작업을 한다. 1-2 Collective Ownership 팀의 모든 프로그래머가 소스코드에 대해서 공동책임을 지는 것으로, 언제 어디서 누구든지 소스코드를 수정할 수 있다. 1-3 Continous Integration 컴포넌트 단위 혹은 모듈 단위로 나누어서 개발된 소스코드들은 하나의 작업이 끝날 때마다 지속적으로 통합되고 테스트 된다. 2.관리원리 2-1 Planing Game 프로젝트 전체의 계획과 주기 계획으로 나누어 지며, 각각의 계획은 비지니스적인 측면과 ..
-
XP(eXtream Programming) - 2IT/Agile 2011. 2. 5.
Waterfall 방식의 프로세스를 사용하지 않기 때문에, 산출물(개발문서)에 집중하지 않는다. 요구사항이 변경될때 마다 산출물을 변경하게 된다면 그 비용도 만만치 않으며, 그 비용 때문에 개발 시간 확보가 되지 않을 것이다. [개발방법] 1. 고객과 개발자의 의사소통을 통하여 요구사항을 확인하고 스토리카드 작성 - 스토리카드란 기능에 명시 및 요구사항을 의미하며, 처음부터 완벽하게 작성하지 않고 차츰 완성해나간다. 2. 메타포를 이용하여 고객에게 시스템을 설명하고 팀원들과의 메타포를 이용하여 의사소통을 하여 오너쉽을 공유 - ※ 메타포 : 시스템을 설명하기 위한 표현방법 3. 페어프로그래밍을 하고 개발은 간략한 디자인을 추구하며 TDD를 통한 단위테스트와 리팩토링 수행 4. 고객과의 개발사항 확인과 요..
-
XP(eXtream Programming) - 1IT/Agile 2011. 2. 5.
XP는 Agile 방법론으로써, 개발 프로세스에 있어서 요구사항이 변한다를 전제로 개발 방향과 방법들을 제시한다. 일반적인 개발 관리 개발요청자는 PL or PM을 통하여 관리와 의사소통하며, 개발자는 PM에게 개발요청사항을 확인하여 설계/개발을 한다. 단적인 예로, PM or PL의 판단 오류 및 의사소통의 문제가 발생한다면 요구사항대로 개발이 될 수 없으며 비용이 증가할 수 밖에 없다. XP 개발 관리 개발요청, 고객 및 요청자와 개발자가 직접 의사소통하고 요구사항을 업데이트 한다. 그럼 관리가 되는 것인가요 라는 질문이 있다면, PM과 PL이 제외되는 것은 아니다. 개발 요구사항에 대해서 직접 개발자와 요청자가 함께 진행할 뿐이다. 게다가 개발자는 개발사항을 메타포 형식으로 구현한 사항을 요청자를 ..