본문 바로가기

소프트웨어 개발방법론/애자일 방법론

 (9)
애자일로 이동하기 - 애자일로의 실천방법 애자일로 가기 위해 바로 적용할 수 있으며 가장 효과적인 방법은, 스탠드업 미팅 입니다. 저도 지금의 팀에서 스탠드업 미팅을 처음 시작했고, 매일 무언가를 공유한다는 일은 굉장히 어색했습니다. 하지만 그 장점은 스스로 먼저 체득하게 되었습니다. 먼저, 업무를 효율적으로 진행하게 되었습니다. 물론 타인이 내가 진행하고 있는 프로젝트의 진척도에 별 관심이 없는 경우도 있지만 공유를 위해서라도 스스로 좀 더 효율적인 부분부터 작업하게 되었습니다. 그리고 3분이라는 시간 내에 공유를 하다보니 남에게 전달하는, 말하는 능력도 상승했습니다. 또한 프로젝트 진행 간에 뭔가 허들이 있을 경우 모두가 모인 자리에서 공유함으로써 문제의 해결도 더 빨라졌습니다. 혹시 스탠드업 미팅을 하고 있지 않다면..
애자일 협력 어떤 프로젝트라도 팀은 필요합니다. 하지만 팀에서 일하는 것은 혼자 일하는 것과 상당히 다르고, 본인의 활동이 전체 프로젝트와 생산성, 진행 상황에 큰 영향을 줄 수 있습니다. 애자일의 초석인 효과적인 협력에 대해 살펴보도록 하겠습니다. - 정규 대면회의 시간을 가져라 의사소통은 프로젝트 성공의 열쇠이고, 따라서 우리는 동료 개발자와 의사소통을 잘 해야 합니다. 스탠드 업 미팅은 팀을 모으고, 모든 사람에게 정보를 제공하는 효과적인 방법입니다. 이름이 암시하듯이, 스탠드 업 미팅에서 참석자는 앉는 게 허용되지 않습니다. 이 점이 회의를 짧게 유지하도록 유도해줍니다. 지금 제가 있는 팀에서도 매일 오후 2시반에 스탠드 업 미팅을 진행합니다. 실제로는 앉아서 하지만, 확실히 앉아서 하다보니 회의가 길어지는 ..
애자일 디버깅 가장 재능 있는 애자일 프로젝트 팀에서도 일은 잘못될 수 있습니다. 언제 어느 상황에서든 버그, 에러, 결함, 실수가 나타납니다. 디버깅의 진짜 문제는 디버깅을 타임 박스에서 다룰 수가 없다는 사실인데, 그럼 이 문제를 어떻게 해야 할지 보도록 하겠습니다. - 해결책 로그를 기록하자 문제에 부딪치는 일, 그리고 문제를 해결하는 일은 개발자에게 흔히 일어나는 일입니다. 개발자들은 문제가 생겼을 때, 문제를 재빨리 해결하길 원하고 비슷한 문제가 다시 생긴다면 처음에 무엇을 했는지 기억해서 다음에는 문제를 더 빨리 해결하길 바랍니다. 하지만 오롯이 개인의 기억에만 의존한다면, 다음에 수정 방법을 기억해 내기란 꽤나 어렵습니다. • 두 번 불에 데지 말자 인터넷 검색보다는 더 생산적으로 해야합니다. 항상 접했던..
애자일 코딩 새로운 프로젝트를 시작할 때, 코드는 이해하기 쉬우며 작업하기도 쉽습니다. 하지만 개발을 진행하면서 프로젝트륵 계속 수행하기 위해선 더 많은 개발자와 상당히 많은 작업량이 소요된다는 것을 느끼게 됩니다. 프로젝트 개발에서 평범한 압박이 나중에 스트레스로 오지 않게 하려면 가장 쉬운 방법은 코드를 잘 유지하는 것입니다. - 의도적이고 의미있게 프로그래밍 하라 이해하기 어렵고 유지보수하기도 힘들며 에러가 있는 코드를 어렵지 않게 볼 수 있습니다. 코드가 어떻게 작동하는지 아무도 이해할 수 없다면 그건 아무 소용없는 코드입니다. 코드를 개발할 때, 항상 편리함보다 읽기 쉬움을 선택해야 합니다. 코드는 작성하는 것보다 훨씬 더 많이 읽히기 때문에, 코드 작성 시 성능이 좋지 않더라도 읽기 쉽다면 더 가치 있는 ..
애자일 피드백 애자일 프로젝트에서 우리는 작고 많은 변경을 지속적으로 조정하기 위해 피드백을 항상 추구합니다. 지속적인 모니터링은 코드 베이스의 품질이 떨어지지 않았으며 나아지진 않았지만 적어도 코드 베이스가 어제 작동한 것처럼 돌아간다는 사실을 확인시켜주는 피드백입니다. 그 외의 피드백을 얻을 수 있는 부분에 대해 아래에서 살펴보도록 하겠습니다. - 단위테스트 애자일은 변화를 관리하는 것이고 아마 가장 많이 변하는 것은 코드일 것입니다. 코드 변화에 대처하려면, 코드의 건강함에 대해 지속적인 피드백이 필요하고 이는 곧 자동화된 단위테스트가 필요하다는 말과 같습니다. • 코딩 피드백 애자일 형식의 단위테스트에서는 스텁 코드를 치워버리지 않고 보존해서 계속해 스텁 코드를 자동적으로 실행합니다. (스텁 코드: 디버깅을 위..
애자일에서 고객과의 협력 소프트웨어를 개발하다보면 상황에 의해 그 전체가 완전히 바뀔 수 있습니다. 상황이 바뀌었음에도 어제의 계획에 집착하는 것은 큰 화를 불러올 수 있습니다. 애자일함, 나아가 성공적인 개발은 변화를 깨닫고 적응하는 능력입니다. 이렇게 적응한 후에야 사용자 필요를 진짜로 만족시키는 시스템을 만들면서도 여러 요구조건을 맞출 수 있습니다. - 고객이 결정하도록 하라 개발자는 설계에 관한 결정을 내릴 때 참여해야 하나, 프로젝트 및 비즈니스에 대한 결정을 모두 내려야 하는 건 아닙니다. 어떤 작업을 할 때, 한 방법은 빠르지만 사용자가 할 수 있는 기능을 제약하고 다른 방법은 구현하는데 시간이 더 걸리지만 사용자에게 더 많은 유연성을 준다고 예를 들어 보겠습니다. 만약 개발 관리자가 첫번째 옵션을 선택했다면, 여러..
애자일 기르기 애자일은 자신을 변화에 적응시켜 유지해나갈 것을 요구합니다. 이것은 계속해서 변화하고 진화하는 분야인 소프트웨어에서 특히 프로그래머에게 맞는 말입니다. 대부분의 신기술들은 기존의 기술이나 아이디어에 의존합니다. 새로운 내용을 다루는 일은 단지 점진적인 변화를 인지하느냐의 문제이지만, 계속 따라가지 못하면 기술 변화는 갑작스럽고 극복하기 힘들어 보입니다. 새로운 기술과 접근 방법을 배우는 일도 중요하지만, 때로는 오래된 구식의 접근 방법을 버리는 일도 필요합니다. 또한 잘 이해하지 못하는 사실들은 계속해서 알려고 하는 태도가 있어야 할 것입니다. - 변화에 뒤처지지 말라 기술의 발전 속도는 상당히 빠릅니다. Java 를 예로 든다면, Swing, servelts, JSP, struts, JSF, JDBC,..
애자일 시작하기 어떠한 방법론에선 하나의 프로젝트를 하기 위해 약 서른가지 이상의 구분된 역할을 수행하는게 필요하다고 제시합니다. 하지만 애자일에선 소프트웨어 개발자. 단 한 가지 역할만 합니다. (지나치게 '사람' 에 의존하는 것 같기도 합니다) 피드백은 애자일의 근간입니다. 일이 잘못된 방향으로 가고 있다는 것을 깨닫자마자 변화시켜야 하며, 때로는 과감히 비난하고 앞으로 나아갈 용기도 필요합니다. 애자일은 결국 소프트웨어 개발자가 프로다운 태도를 수용할 때만 작용합니다. - 결과를 위해 일하라 일을 함에 있어 범인을 찾는 것 보다는 문제를 고치는 일을 최우선으로 삼아야 합니다. (그러지 못하는 경우를 많이 봤습니다..) 비난을 하는 대신 문제를 해결하는데 집중해야 합니다. • 비난은 버그를 수정하지 못한다 감정적으로..

티스토리툴바