열두가지 애자일 원칙에 대한 개인적인 의견
- 고객을 만족시키기 위해 소프트웨어를 빠르고 지속적으로 배포한다.
- 새로운 요구 사항은 개발 후기에도 기꺼이 받아들인다.
- 동작 가능한 소프트웨어를 몇 달 주기가 아닌 몇 주 주기로 배포한다.
- 업무 담당자와 개발자 간의 긴밀한 소통을 지향한다.
- 믿을 수 있는 동기부여된 개인들로 구성된 팀이 소프트웨어를 개발한다.
- 직접 만나 얼굴을 보며 이야기하는 것이 최선의 의사소통이다.
- 동작하는 소프트웨어가 가장 중요한 진척의 척도다.
- 일정한 속도를 유지함으로써 지속 가능한 개발을 추구한다.
- 좋은 기술과 설계를 향해 지속적으로 관심을 기울인다.
- 단순함(하지 않는 일을 늘리는 기법)을 중요시 한다.
- SOT(self-organized team)를 추구한다.
- 새로운 환경에 지속적으로 적응한다.
1. 고객을 만족시키기 위해 소프트웨어를 빠르고 지속적으로 배포한다.
전적으로 공감이 가는 내용이다. jenkins 를 이용하여 매일 배포를 하고 개발서버를 현업에게 오픈하여 프로그램 사용하게끔 유도를 하는게 성공적인 프로젝트의 지름길이다. 다만, 현업의 참여를 유도하는게 무엇보다 중요하다. 실제 현업은 프로젝트 이외에 업무가 존재하며, 그 업무를 수행하면서 프로젝트에 참여하는게 대부분이기 때문이다.
2. 새로운 요구 사항은 개발 후기에도 기꺼이 받아들인다.
이 부분은 고민이 필요한 부분이다. 전체 프로세스를 변경해버리면 프로젝트에 큰 영향을 줄 수 있기 때문이다.
간단한 문구 수정이나 레이아웃 변경등 사소하지만 빠르게 대응할 수 있는 부분은 당연히 받아 들여야 하지만, 전체 프로세스가 변경되는 부분은 신중히 검토 후 받아들어야 한다.
3. 동작 가능한 소프트웨어를 몇 달 주기가 아닌 몇 주 주기로 배포한다.
1번과 중복되는 이야기일 것 같다.
4. 업무 담당자와 개발자 간의 긴밀한 소통을 지향한다.
국내 대부분의 프로젝트는 PM, PL, 개발자로 나누어 프로젝트를 진행한다. PL과 현업(업무 담당자)은 긴밀하게 소통을 해야 한다.
5. 믿을 수 있는 동기부여된 개인들로 구성된 팀이 소프트웨어를 개발한다.
프로젝트 진행에서 가장 중요한 부분이다. 동기부여 뿐만 아니라 개발하고 있는 모듈에 대해 정확히 이해하고 있는 개발자들이 필요하다. 하지만 소위 스타 플레이어(역량이 너무 뛰어난 나머지...)는 팀에서 매우 중요한 역할을 하지만 그 사람에게 너무 많은 업무가 가중되지 않도록 적절히 조치를 취해야 한다.
6. 직접 만나 얼굴을 보며 이야기하는 것이 최선의 의사소통이다.
메신저나 메일로 업무를 하기보다는 직접 만나서 이야기 하는게 가장 확실한 방법이다. 하지만 중요한 내용은 다시 한번 메일로 정리해서 보내거나, 수신 받는 일 또한 매우 중요하다. 현업(업무 담당자)는 천재가 아니다. 본인이 했던 말을 잊어 버리고 다른 말을 할 수 있기 때문이다.
7. 동작하는 소프트웨어가 가장 중요한 진척의 척도다.
예전 S사 프로젝트를 진행했을때 막바지에 큰 결함이 발견되었다. 하지만 고객은 엄청난 문서를 요구해왔고, 혼자서 감당이 되지 않았다. 문서를 작업하는 것 보다는 프로젝트의 결함을 최우선으로 조치 하였고, 문서는 늦게 제출하여 일정에 차질이 생겼었다. 하지만 문서는 문서일뿐 소프트웨어의 결함을 최소화 하는 것이 성공적인 프로젝트로 가는 올바른 방향이다. 문서가 중요하지 않다는 이야기는 아니다.
8. 일정한 속도를 유지함으로써 지속 가능한 개발을 추구한다.
개발 초기에는 매일 칼퇴를 하거나 휴가를 여유롭게 사용하다가도 개발 막바지에 이르러서 항상 야근을 하는 프로젝트를 수도없이 많이 봐왔었다. 개발 개획을 수립하여 초기에도 계획대비 일정이 늦어진다면 야근을 해서라도 완료하는 것이 중요하다.
또한 주제와 약간 벗어날 수 도 있는 이야기일지도 모르겠으나, 팀원들 간의 업무가 가중된 사람이 있는 반면에 여유로운 사람도 분명 존재한다. 이런 부분을 빠르게 캐치하여 적절히 배분하는게 무엇보다 중요하다. 바쁜 사람은 매일 야근하고 여유로운 사람은 칼퇴를 한다면 그 프로젝트는 분명 좋은 방향으로 가지는 못 할 것이다. (물론 여유로운 사람이 매우 뛰어난 역량을 가지고 일을 빠르게 마무리 해서 칼퇴를 할 수 도 있고, 야근 하는 사람은 역량이 부족하여 매일 업무에 시달릴 수도 있다.)
9. 좋은 기술과 설계를 향해 지속적으로 관심을 기울인다.
PL이 설계를 진행 후 개발자나 다른 PL에게 자신이 설계한 내용을 공유하거나, 리뷰를 받는 시간을 가지면 좀 더 나은 품질의 소프트웨어를 만들 수 있을 것이다. (물론 시간과 비용이 허용하는 범위내에서)
10. 단순함(하지 않는 일을 늘리는 기법)을 중요시 한다.
하지 않아도 되는 일을 찾아 과감하게 없애 버리는게 중요하다. 가령 현업이 요구한 주간보고가 매우 복잡한 양식으로 되어 있고, 그 작업을 하는데 2시간이 걸린다고 가정하면, 이 부분은 이야기를 나누어 심플하게 줄이거나 자동화 할 수 있는 방법을 찾아야 할 것 이다.
11. SOT(self-organized team)를 추구한다.
개발자는 개발만, 설계자는 설계만 하는게 아니라, 이슈가 발생했을 경우 다같이 회의를 통해 (혹은 간단한 미팅) 문제를 공유하고 해결방법은 다 같이 찾는게 중요하다. 예전 프로젝트에서 PM과 PL 끼리의 회의가 있었다. 특정 모듈에 알 수 없는 문제가 발생했었는데 (분명 코딩 로직이 잘못 된 건 아니였다.) 몇시간째 회의를 하고 있는 중간에 개발자가 지나가다 회의 내용을 듣고 해결책을 알려 준 적이 실제로 있었다. 그렇다고 매번 이슈가 생길때마다 전체 회의를 소집해 불필요한 시간을 뺏으라는 이야기는 아니다.
12. 새로운 환경에 지속적으로 적응한다.
새로운 기술이나 툴을 발견했거나, 누군가로 부터 들었을 경우, 두려워 하지 말고 프로젝트 적용 해 보는 것도 중요하다. 요새는 대부분의 프로젝트에서 버전관리로 git을 사용한다. 하지만 예전에는 subversion을 많이 사용했었다. 예전 프로젝트 진행 시 초반에 버전관리로 무엇을 사용할지 결정하는 부분이 있었는데 익숙한 툴인 subversion을 사용하기로 결정했었다. 하지만 프로젝트 중간에 현업의 요청으로 git으로 변경되었다. 초반부터 git을 사용했다면 좀 더 빨리 git에 적응했을 것이고 버전관리를 변경하지 않아도 되었을 것이다.
SOT : (self-organized team) 모든 구성원이 참여해 문제를 정의하고 해결하는 팀을 지칭한다. 기존의 관리자-개발자 방식과 다르게 개발자도 참여해 문제를 분석하고 일정을 조율한다.
http://agilemanifesto.org/iso/ko/principles.html
'개발 > etc' 카테고리의 다른 글
| 오즈리포트 바코드 출력 예제 (0) | 2021.03.18 |
|---|
댓글