Offcanvas

������ ������������

때론 포기하는 게 지혜··· SW 프로젝트가 지연되는 10가지 이유

오랫동안 컴퓨터 프로그래머로 일했으며, ‘괴델, 에셔, 바흐'라는 책을 쓴 더글러스 호프스태터는 자신의 이름을 딴 ‘호프스태터의 법칙’로 컴퓨팅 분야에서의 오랜 경험을 요약해 정의하고 있다.  “늘 예상보다 더 많은 시간이 소요될 것이다. ‘호프스태터의 법칙’을 감안할지라도 그럴 것이다.”  그러나 기업과 조직, 이해관계자, 프로젝트 매니저는 여전히 소프트웨어 프로젝트에 ‘일정’을 적용한다. 심지어 프로그래머들도 이렇게 한다. 그런데 ‘호프스태터의 법칙’이 프로그래머에게 좀더 유효할까? 아니면 프로젝트 매니저에게 더 통할까? 프로젝트 매니저는 API를 사용해 2개월 정도를 절약할 수 있다. 그러나 API에 129가지 옵션이 있으며, 이 가운데 회사에 필요한 것은 한 가지라는 것을 발견하는 사람은 개발자이다. 코드 빌드도 어렵지만, 8명의 프로그래머를 관리하는 일도 어렵다. 외부의 프로젝트 스폰서는 참을성 없게 회의 탁자 테이블을 두드린다. 한편, 현업 부문 사람들과 프로젝트 관리자는 프로그래머가 게을러 진전이 없다고 생각한다. 그러나 프로그래머는 자신이 직면한 어려운 문제들을 관리자, 감독자가 이해하지 못한다고 생각한다. 오래 전, 누군가 생산성과 ‘코드 줄’ 사이의 상관관계를 과학적으로 분석해 측정하려 시도했다. 페드릭 브룩스가 1975년 ‘맨먼스 미신(The Mythical Man-Month)’이라는 책을 통해 이에 대한 이론을 제시했다. ‘선형적 진행’에 대한 수학 모델과 가설이 적용되지 않음을 보여준 책이다.  이후 프로젝트 완료를 가로막는 가시밭이 더 늘었다. 애자일과 지속적인 빌드 같은 개념은 국소적인 문제에서 일시적으로 효과가 있지만, 모든 것을 더 복잡하게 만든다. 즉, 복잡성이 궁극적인 문제이다. 고객과 이해당사자, 주주들은 갈수록 더 많은 것을 요구하고 있고, 이는 시간이 점점 더 길어진다는 의미이다.  소프트웨어 딜리버리를 앞당길 수 있는 새로운 도구와 기법들이 다수 등장했음에도 불구하고 소프트...

프로젝트 관리자 IT 관리 개발 프로젝트 소프트웨어 프로젝트 프로젝트 지연 호프스태터의 법칙

2019.08.02

오랫동안 컴퓨터 프로그래머로 일했으며, ‘괴델, 에셔, 바흐'라는 책을 쓴 더글러스 호프스태터는 자신의 이름을 딴 ‘호프스태터의 법칙’로 컴퓨팅 분야에서의 오랜 경험을 요약해 정의하고 있다.  “늘 예상보다 더 많은 시간이 소요될 것이다. ‘호프스태터의 법칙’을 감안할지라도 그럴 것이다.”  그러나 기업과 조직, 이해관계자, 프로젝트 매니저는 여전히 소프트웨어 프로젝트에 ‘일정’을 적용한다. 심지어 프로그래머들도 이렇게 한다. 그런데 ‘호프스태터의 법칙’이 프로그래머에게 좀더 유효할까? 아니면 프로젝트 매니저에게 더 통할까? 프로젝트 매니저는 API를 사용해 2개월 정도를 절약할 수 있다. 그러나 API에 129가지 옵션이 있으며, 이 가운데 회사에 필요한 것은 한 가지라는 것을 발견하는 사람은 개발자이다. 코드 빌드도 어렵지만, 8명의 프로그래머를 관리하는 일도 어렵다. 외부의 프로젝트 스폰서는 참을성 없게 회의 탁자 테이블을 두드린다. 한편, 현업 부문 사람들과 프로젝트 관리자는 프로그래머가 게을러 진전이 없다고 생각한다. 그러나 프로그래머는 자신이 직면한 어려운 문제들을 관리자, 감독자가 이해하지 못한다고 생각한다. 오래 전, 누군가 생산성과 ‘코드 줄’ 사이의 상관관계를 과학적으로 분석해 측정하려 시도했다. 페드릭 브룩스가 1975년 ‘맨먼스 미신(The Mythical Man-Month)’이라는 책을 통해 이에 대한 이론을 제시했다. ‘선형적 진행’에 대한 수학 모델과 가설이 적용되지 않음을 보여준 책이다.  이후 프로젝트 완료를 가로막는 가시밭이 더 늘었다. 애자일과 지속적인 빌드 같은 개념은 국소적인 문제에서 일시적으로 효과가 있지만, 모든 것을 더 복잡하게 만든다. 즉, 복잡성이 궁극적인 문제이다. 고객과 이해당사자, 주주들은 갈수록 더 많은 것을 요구하고 있고, 이는 시간이 점점 더 길어진다는 의미이다.  소프트웨어 딜리버리를 앞당길 수 있는 새로운 도구와 기법들이 다수 등장했음에도 불구하고 소프트...

2019.08.02

SW 프로젝트를 산으로… 서툰 리더십 행태 11가지

소프트웨어 개발자들은 ‘해서는 안 될 일’을 경고하는 ‘안티패턴(Antipattern)’이라는 개념을 만들어냈다. 중세 시대 지도의 ‘용이 있는 지역이니 조심’ 표시 같은 것이다. 코드를 구성할 때 적용해서는 안 되는 방법, 아키텍처로 적용해서는 안 되는 방법, 데이터베이스 스키마 디자인(고안)에 적용해서는 안 되는 방법 등이 이에 해당된다. 이런 안티패턴은 오늘날 여러 개발자들이 기능적 디자인 패턴으로 존중을 할 만큼 유용해졌다. 소프트웨어 프로젝트에도 고유의 ‘안티패턴’이 존재한다. 물론 프로젝트 운영과 팀 관리는 코드 개발과 같이 특정한 체계를 적용하기 어려울 수 있다. 또 일부 안티패턴은 서로의 ‘거울상’이다. 같은 것을 놓고, 수용하라기는 이야기와 피하라는 이야기가 공존할 수 있다. 그러나 실제 요구하는 것은 ‘중용’이다. 제 아무리 좋은 개념도 지나치면 팀 관리에 도움이 되지 않는다. 지금부터 소프트웨어 개발 관리와 관련된 11가지 안티패턴을 소개한다. 개발자들을 인도하거나 관리할 때 피해야 할 행동이나 행태로 생각하면 된다.   ‘팀 플레이’라는 안티패턴 로버트 프로스트는 ‘좋은 울타리가 선한 이웃을 만든다’는 말을 즐겨 했다. 사람은 자신만의 공간이 필요하며, 이는 개발자도 마찬가지이다. 사람이 많으면 일이 쉬워질 것이라고 기대하면서, 팀에 더 많은 개발자를 추가 영입하려 들기 쉽다. 그러나 지나칠 경우, 개발자들이 서로 반목하면서 동일한 코드를 업데이트하려 경쟁하게 된다. 그러면 검토할 코드가 많아지고, 그 누구도 코드를 일일이 검토해 통합하기 원하지 않게 된다. 마이크로서비스 아키텍처는 여러 단점도 가지고 있지만, 개발자에 숨쉴 공간을 준다. 독립적으로 자신이 맡은 코드 작업을 할 수 있다. 코드를 커밋하고, 테스트를 생성하는 등 작업을 해 나갈 수 있...

소프트웨어 개발 개발 프로젝트 개발자 관리 안티패턴

2019.03.11

소프트웨어 개발자들은 ‘해서는 안 될 일’을 경고하는 ‘안티패턴(Antipattern)’이라는 개념을 만들어냈다. 중세 시대 지도의 ‘용이 있는 지역이니 조심’ 표시 같은 것이다. 코드를 구성할 때 적용해서는 안 되는 방법, 아키텍처로 적용해서는 안 되는 방법, 데이터베이스 스키마 디자인(고안)에 적용해서는 안 되는 방법 등이 이에 해당된다. 이런 안티패턴은 오늘날 여러 개발자들이 기능적 디자인 패턴으로 존중을 할 만큼 유용해졌다. 소프트웨어 프로젝트에도 고유의 ‘안티패턴’이 존재한다. 물론 프로젝트 운영과 팀 관리는 코드 개발과 같이 특정한 체계를 적용하기 어려울 수 있다. 또 일부 안티패턴은 서로의 ‘거울상’이다. 같은 것을 놓고, 수용하라기는 이야기와 피하라는 이야기가 공존할 수 있다. 그러나 실제 요구하는 것은 ‘중용’이다. 제 아무리 좋은 개념도 지나치면 팀 관리에 도움이 되지 않는다. 지금부터 소프트웨어 개발 관리와 관련된 11가지 안티패턴을 소개한다. 개발자들을 인도하거나 관리할 때 피해야 할 행동이나 행태로 생각하면 된다.   ‘팀 플레이’라는 안티패턴 로버트 프로스트는 ‘좋은 울타리가 선한 이웃을 만든다’는 말을 즐겨 했다. 사람은 자신만의 공간이 필요하며, 이는 개발자도 마찬가지이다. 사람이 많으면 일이 쉬워질 것이라고 기대하면서, 팀에 더 많은 개발자를 추가 영입하려 들기 쉽다. 그러나 지나칠 경우, 개발자들이 서로 반목하면서 동일한 코드를 업데이트하려 경쟁하게 된다. 그러면 검토할 코드가 많아지고, 그 누구도 코드를 일일이 검토해 통합하기 원하지 않게 된다. 마이크로서비스 아키텍처는 여러 단점도 가지고 있지만, 개발자에 숨쉴 공간을 준다. 독립적으로 자신이 맡은 코드 작업을 할 수 있다. 코드를 커밋하고, 테스트를 생성하는 등 작업을 해 나갈 수 있...

2019.03.11

기고 | 애자일과 워터폴을 공존시키는 4가지 방법

이론적으로 이들 두 기법은 서로 섞일만한 것들이 아니다. 하지만 현실적으로는 대개 공존해야만 한다. 여기 애자일과 워터폴이라는 상반되는 기법이 함께 존재할 수 있도록 하는 4가지 방법을 정리한다. Image Credit : Getty Images Bank IT 부서는 애자일(Agile) 프로젝트의 민첩성과 생산성을 으레 선호한다. 하지만 경영진과 재무 조직에 프로젝트를 소개할 때는 워터폴(Waterfall) 개념을 거의 항상 필수요건으로 소개하게 된다. 사실 따져보면 애자일과 워터폴은 반대에 가까운 개념들이며, 특히 많은 소프트웨어 프로젝트에서 두 기법을 두고 꽤나 불편한 상황이 연출되기도 한다. 폴라 압둘의 노래와는 달리 상반되는 성격이 그리 매력적으로 다가오지 않는 것이다. 그렇다면 이 둘을 어떻게 함께 활용할 수 있을까? 대응 전략 #1: 적극적 계정 관리 워터폴에는 고정된 사양뿐만이 아니라 고정된 예산과 일정이 수반된다. 따라서 유연하거나 모호하게 정의된 스프린트(Sprint) 성과물과 조합하려면 꽤나 고민을 해야 한다. 하지만 워터폴의 ‘사양’이 불분명하거나 (고객은 무엇이 필요한지 정확하게 모르기 때문) 신축성이 있는 경우 (임원이 우선적으로 결정하기 때문) 의외로 효과가 있을 수 있다 하지만 이 전략은 조심스럽게 적용될 필요가 있다는 점에 주의해야 한다. 프로젝트 범위 확대 및 우선순위 충돌 문제로 비화되서는 안 된다. 베스트 프랙티스: 매 스프린트 시작과 끝에 서면으로 기대치를 명시적으로 관리한다. 또한 스프린트 중 제공되는 각 기능에 대해 고객의 승인을 받는다. 워스트 프랙티스: 문제 자체가 알아서 해결되기를 바라면서 현실을 외면하는 태도. 대응 전략 #2: 주문 변경 공식화 워터폴 프로젝트에서 고객은 걸핏하면 주문을 변경한다 (계약서가 그렇게 조장하는 측면도 있다). 그렇다면 이런 메커니즘을 조기에 자주 활용하자. 예전에 참여한 70만달러짜리 프로젝트에서 50건의 주문 변경이 ...

애자일 소프트웨어 폭포수 개발 프로젝트 데브옵스 워터폴

2016.07.12

이론적으로 이들 두 기법은 서로 섞일만한 것들이 아니다. 하지만 현실적으로는 대개 공존해야만 한다. 여기 애자일과 워터폴이라는 상반되는 기법이 함께 존재할 수 있도록 하는 4가지 방법을 정리한다. Image Credit : Getty Images Bank IT 부서는 애자일(Agile) 프로젝트의 민첩성과 생산성을 으레 선호한다. 하지만 경영진과 재무 조직에 프로젝트를 소개할 때는 워터폴(Waterfall) 개념을 거의 항상 필수요건으로 소개하게 된다. 사실 따져보면 애자일과 워터폴은 반대에 가까운 개념들이며, 특히 많은 소프트웨어 프로젝트에서 두 기법을 두고 꽤나 불편한 상황이 연출되기도 한다. 폴라 압둘의 노래와는 달리 상반되는 성격이 그리 매력적으로 다가오지 않는 것이다. 그렇다면 이 둘을 어떻게 함께 활용할 수 있을까? 대응 전략 #1: 적극적 계정 관리 워터폴에는 고정된 사양뿐만이 아니라 고정된 예산과 일정이 수반된다. 따라서 유연하거나 모호하게 정의된 스프린트(Sprint) 성과물과 조합하려면 꽤나 고민을 해야 한다. 하지만 워터폴의 ‘사양’이 불분명하거나 (고객은 무엇이 필요한지 정확하게 모르기 때문) 신축성이 있는 경우 (임원이 우선적으로 결정하기 때문) 의외로 효과가 있을 수 있다 하지만 이 전략은 조심스럽게 적용될 필요가 있다는 점에 주의해야 한다. 프로젝트 범위 확대 및 우선순위 충돌 문제로 비화되서는 안 된다. 베스트 프랙티스: 매 스프린트 시작과 끝에 서면으로 기대치를 명시적으로 관리한다. 또한 스프린트 중 제공되는 각 기능에 대해 고객의 승인을 받는다. 워스트 프랙티스: 문제 자체가 알아서 해결되기를 바라면서 현실을 외면하는 태도. 대응 전략 #2: 주문 변경 공식화 워터폴 프로젝트에서 고객은 걸핏하면 주문을 변경한다 (계약서가 그렇게 조장하는 측면도 있다). 그렇다면 이런 메커니즘을 조기에 자주 활용하자. 예전에 참여한 70만달러짜리 프로젝트에서 50건의 주문 변경이 ...

2016.07.12

‘모바일 앱 프로젝트’ 완성도 향상을 위한 5가지 조언

이제 기업으로서는 직원들과 고객들을 위한 더 나은 서비스를 제공하기 위해 모바일 앱을 개발하는 것이 당연시되고 있다. 그러나 일부 기업들은 앱을 너무 조급히 개발하고 있다. 그리고 사후약방문 격으로 업데이트를 제공하고 있다. 미숙한 모바일 앱의 출시를 방지하기 위해 어떤 것들이 필요한지 알아본다. 1. 모바일 앱 로드맵을 개발하라 모바일 앱을 출시하기에 앞서 반드시 정확한 계획을 세워야 한다. 앱의 전반적인 목표, 그 성공을 측정하는 방법, 사용자들이 얻게 될 혜택 등을 검증해야 한다. "대부분의 기업들이 겪고 있는 가장 큰 문제는 그들이 진정으로 원하는 것을 정확히 정의하지 못하고 있다는 점이다"라고 J. 골드 어소시에이츠(J. Gold Associates)의 창업자이자 수석 애널리스트 잭 골드는 말했다. 골드는 기업들이 어떤 조치를 취할지에 관한 세부적인 로드맵을 구성하고 각각이 언제 어느 정도의 비용이 발생할지를 분석해야 한다고 설명했다. 포레스터에 따르면 설계 및 개발 비용은 평균적으로 20만~ 35만 달러 수준이기 때문에 지출을 잘 관리해야 한다. 또한, 반드시 로드맵의 시간계획에 사소한 것들을 포함시켜야 한다. 골드는 "생각보다 시간이 오래 걸리고 비용이 많이 발생할 수 있다는 것을 염두에 두어야 한다"라고 조언했다. 각 단계에 있어서, 궁극적으로 앱을 사용하고 이로부터 혜택을 받을 사용자들과 그들의 습관을 심도 깊게 분석할 필요가 있다. 골드는 "원하는 것을 정의하며 고객들로부터 피드백을 얻으라"라며 "가능하다면 처음부터 바로잡고 자신이 개발하고자 하는 것을 파악한 후에, 시작하라. 단순히 경쟁심 때문에 시작하는 것은 좋은 방법이 아니다"라고 말했다. 2. 외부 에이전시 또는 풀타임 모바일 앱 개발자 사이에서 선택하라 개발을 내부적으로 처리해야 할지 아니면 에이전시 또는 프리랜스 개발자에게 외주로 맡길지를 신중하게 결정해야...

개발자 모바일 앱 개발 개발 프로젝트

2013.03.21

이제 기업으로서는 직원들과 고객들을 위한 더 나은 서비스를 제공하기 위해 모바일 앱을 개발하는 것이 당연시되고 있다. 그러나 일부 기업들은 앱을 너무 조급히 개발하고 있다. 그리고 사후약방문 격으로 업데이트를 제공하고 있다. 미숙한 모바일 앱의 출시를 방지하기 위해 어떤 것들이 필요한지 알아본다. 1. 모바일 앱 로드맵을 개발하라 모바일 앱을 출시하기에 앞서 반드시 정확한 계획을 세워야 한다. 앱의 전반적인 목표, 그 성공을 측정하는 방법, 사용자들이 얻게 될 혜택 등을 검증해야 한다. "대부분의 기업들이 겪고 있는 가장 큰 문제는 그들이 진정으로 원하는 것을 정확히 정의하지 못하고 있다는 점이다"라고 J. 골드 어소시에이츠(J. Gold Associates)의 창업자이자 수석 애널리스트 잭 골드는 말했다. 골드는 기업들이 어떤 조치를 취할지에 관한 세부적인 로드맵을 구성하고 각각이 언제 어느 정도의 비용이 발생할지를 분석해야 한다고 설명했다. 포레스터에 따르면 설계 및 개발 비용은 평균적으로 20만~ 35만 달러 수준이기 때문에 지출을 잘 관리해야 한다. 또한, 반드시 로드맵의 시간계획에 사소한 것들을 포함시켜야 한다. 골드는 "생각보다 시간이 오래 걸리고 비용이 많이 발생할 수 있다는 것을 염두에 두어야 한다"라고 조언했다. 각 단계에 있어서, 궁극적으로 앱을 사용하고 이로부터 혜택을 받을 사용자들과 그들의 습관을 심도 깊게 분석할 필요가 있다. 골드는 "원하는 것을 정의하며 고객들로부터 피드백을 얻으라"라며 "가능하다면 처음부터 바로잡고 자신이 개발하고자 하는 것을 파악한 후에, 시작하라. 단순히 경쟁심 때문에 시작하는 것은 좋은 방법이 아니다"라고 말했다. 2. 외부 에이전시 또는 풀타임 모바일 앱 개발자 사이에서 선택하라 개발을 내부적으로 처리해야 할지 아니면 에이전시 또는 프리랜스 개발자에게 외주로 맡길지를 신중하게 결정해야...

2013.03.21

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

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

Copyright © 2022 International Data Group. All rights reserved.

10.5.0.5