Books & Notes

3795621 Books & Notes 3794571 2010-02-01T06:36:38Z http://swprocess.springnote.com/pages/3795621 2009-07-09T04:22:10Z   #1. 피플웨어(Peopleware) by Tom Demarco, Timothy Lister   1부. 인적 자원 관리  1. 기술 문제가 아니라 사람 문제다.   업무에서 발생하는 문제들은 대부분 기본적으로 기술의 문제가 아니라 조직사회학의 문제이다. 업무의 성공 여부는 그 과정에서 얼마나 좋은 인간 관계를 유지할 수 있으냐 아니냐에 달려있다.  2. 햄버거 마인드   만들어서 팔기만 하면 된다는 식의 '햄버거 마인드'는 부하 직원들의 사기를 떨어뜨리고, 정말 중요한 문제에 쏟아야 할 관심을 분산시켜 작업에 직접적인 악영향을 미칠 것이다. 개발 분야에서 일하는 직원들을 효과적으로 관리하려면 정반대의 관리 기법을 택해야 한다. 다음은 이를 위한 접근법들이다. <ol> <li>실수를 업무의 일부로 여긴다 : 실수를 허용하지 않는 분위기는 평균적인 기술 수준은 약간 향상될지도 모르지만, 팀은 위기에 처할 것이다. 직원들이 실수를 털어놓으면, 그것은 칭찬할 만한 일이다. 실수는 바로 업무의 일부이기 때문이다.</li> <li>스스로의 동기에 의해서 일하도록 만들어라 : 사람들의 옆구리를 찔러서 단기 생산성을 올릴 수 있을지는 모르지만 장기적인 관점에서는 효과적이지 않다. 대다수의 사람들은 자신의 일을 사랑한다. 따라서 직원들에게 일을 시키기 위해 폭군 같은 방식을 택해야 할 필요는 없다.</li> <li>직원들의 자기 주장에 위압감을 느낄 필요는 없다 : 각 직원의 고유한 특성은 생산 관리식 스타일을 맹목적으로 따라온 관리자들에게는 끊임없는 골칫거리이다. 그러나 사람을 관리하는 기법에 대해 잘 아는 유능한 관리자는 그러한 개성들이 뒷받침되어야 프로젝트가 더 생기 있고 효율적일 수 있다는 것을 잘 알고 있다.</li> <li>현상 유지만 하는 일은 이미 실패한 일이다 : 프로젝트 관리는 개발 과정이 얼마나 역동적으로 이루어지는가에 초점을 맞추어야 한다. 또한 팀원 전체가 개발 과정에서 어떠한 역동적인 역할들을 담당하고 있는가에 대해서 관심을 가져야 한다. 촉매 작용을 하는 사람들은 프로젝트를 원활하게 진행하도록 돕기 때문에 아주 중요하다. 프로젝트의 팀원들이 서로 뭉치게 하는 사람은 그저 맡은 일만 하는 두 명의 몫을 해내는 셈이다.</li> <li>일에 대해 고민할 시간이 필요하다 : 맡은 업무가 중요하면 중요할수록 더욱 더 신중하게 업무에 접근해야 한다. 일배우기에 들이는 시간을 줄이고 일 자체에 대해 생각하는 시간을 늘리려면 거의 초인적인 노력이 필요하다. 그러나 그런 많은 노력을 기울여서 프로젝트 팀원들이 서로 잘 교류하고 일 자체를 즐기는 법을 배우는 것은 무엇보다 중요하다.</li> </ol>  3. 진정한 생산성의 의미  생산성은 이익을 비용으로 나눈 것으로 정의되어야 한다. 이익은 수행한 업무로부터 벌어들인 수입과 절감한 비용을 합한 것이고, 비용은 그 과정에서 소진된 몇몇 직원들의 교체 비용이 포함된 총 비용으로 보아야 한다. 생산성을 높이려면 항상 이직률도 고려해야 한다. 어떤 성과를 얻든지 간에, 그 성과는 중요한 사람들을 잃은 대가로 얻어지는 결과이기 때문이다. 시간을 쫓기며 일하는 사람들은 일을 더 잘 하는 것이 아니라 단지 더 빠르게 일할 뿐이다.  4. 여유 시간이 있어야 품질을 따진다.   품질은 무한정이지만 그것은 품질 향상에 많은 비용을 투자할 용의가 있는 사람들에게만 유효하다. 품질 향상을 위해 한 푼도 투자할 의향이 없는 회사는 그만큼의 품질밖에 얻을 수 없다. 여유 시간이 있으면 품질을 따지는 정책을 따르는 회사의 제품에는 좋은 품질이 끼어들 여지가 조금도 없는 것이다. 휴렛팩커드 경우, 높은 설계자 중심 품질 기준 설정으로 생산성을 향상시켜 이익을 거둔 기업이다. 개발자들은 자신들이 시장에서 요구하는 것 이상으로 좋은 품질의 제품을 만들어 내는 기업 문화의 한 부분임을 인식하였고, 이러한 품질 인식은 직업 만족도를 높이고, 업계에서 유례 없는 낮은 이직률이라는 결과를 낳았다.  5. 다시 본 파킨슨 법칙   파킨슨 법칙이란 업무는 그 시간에 할당된 시간만큼 늘어지는 경향이 있다는 것이다. 그러나 파킨슨 법칙은 당신의 직원들에게는 거의 적용되지 않는다. 직원들은 빈둥거리며 일하기에는 인생이 너무 짧다는 것을 알고 있으며, 자신의 일을 즐기기 때문에 일을 무한정 질질 끌려고 하지 않는다. 또한 그런 태도는 그들이 찾는 일의 만족감을 떨어뜨릴 뿐이기 때문이다. 뉴사우스웨일즈 대학에서 나온 조사 결과, 상사가 일정에 압박을 전혀 주지 않은 경우, 프로젝트들은 최고의 생산성을 기록했다. 즉, 파킨슨 법칙을 약간 변형시켜보면 많은 회사에서 볼수 있는 놀라운 진실이 생겨나는데 회사 일정에 쫓겨 일을 해야 할때 직원들은 근무 시간만 채우도록 일을 늘이는 경향이 있다는 것이다.  6. 만병통치약은 없다.  사람들에게 의존하는 것도 최신 기술 장치를 도입하는 것도 생상성 향상에는 별로 도움이 되지 않는다. 생산성 향상을 위해 관리자가 진정 해야하는 일은 사람들에게 일을 시키는 것이 아니라 그들이 일에 전념할 수 있는 환경을 만들어 주는 것이다.   2부. 사무실 환경 7. 비생산적인 작업 환경  생산성에 문제가 있는 대부분의 회사들은 무엇보다도 사무 환경 개선을 통해 생산성을 급속히 향상시킬 수 있다. 직원들이 시끄럽고 삭막하며 불안을 일으키는 사무 환경에서 일하고 있다면 사무 환경을 개선하는 것이 가장 시급한 문제이다. 8. 도대체 여기선 일할 수가 없어요.  1984년부터 1986년까지 92개의 회사에서 600명 이상의 개발자들을 대상으로 모의 코딩 대회를 실시하여 생산성에 영향을 미치는 요소들에 대해 살펴보았다. 먼저, 생산성과 관련이 없는 요소들은 프로그래밍 언어, 경력, 결함도, 급여의 차이로 나타났다. 반면, 업무 능력에 큰 연관성이 있는 것으로는 업무 파트너가 누구냐는 것이다. 수년간 관리자들은 개인에 따른 능력차이는 원래부터 있는 것이기 때문에 관리자가 어떻게 할 수 없다는 숙명론에 가까운 입장을 지니고 있었다. 그러나 개인들이 모여 있을때 발생하는 효과에 대해서는 그런 식의 입장을 고수할 수 없다. 회사의 업무 환경과 기업 문화 속의 무엇인가가 뛰어난 사람들을 유치하고 회사에 남아 있게 하는 것을 어렵게 하거나 효율적으로 일을 하지 못하게 하는 것이기 때문이다. 따라서 업무 환경의 특징들에 대해 태만하게 대체해서는 안된다. 정신 노동직에 종사하는 사람들과 일하거나 그들을 관리해야 한다면 업무 환경은 관리자가 책임져야 한다. 9. 사무실 시설비 아끼기  업무 환경 조성 비용을 조금이라도 아끼는 것이 이익이라는 판단을 내리는 사람은 진정한 이윤이 어떤 것인지 연구해 보지도 않고 비용과 이윤 연구를 하는 우를 범하는 것이다. 비용을 아끼는 것은 좋은 일이긴 하지만 무엇과 비교하여 좋은 것인가? 이 문제에 대한 대답은 시설 비용을 아끼는 대신 얼마나 효율성이 떨어지는지를 비교해 보아야 알수 있다. 연구직에 있는 사람들은 업무를 최적화하기 위해 적절한 크기의 조용한 공간을 필요로 한다. 만일 적정 수준 이하로 사무 공간 시설비를 절감한다면 그것으로 인한 절감 비용보다 효율성 저하로 인한 손실 비용이 더 크게 될 것이기 때문이다. 10. 머리로 일한 시간, 몸으로 일한 시간  플로(Flow)란 한 가지에 깊이 집중하여 거의 명상 상태에 빠지는 것을 의미한다. 몸이 일하는 시간 대신 플로 시간을 기록하는 업무 평가는 직원들이 플로 시간의 중요성에 관심을 갖게 하고, 집중해서 일하는 의미있는 시간을 기록할수 있게 한다는 점에서 의의가 있다. 11. 전화로부터 벗어나자.  업무 시간의 질에 대한 데이터를 수집하기 시작하면, 업무 방해의 주원인인 전화에 주목하게 된다. 가령 하루에 걸려오는 전화 15통쯤 받는 일은 대수로운 일이 아니나 한 통화 끝낼 때마다 다시 일에 집중해야 하는 시간이 걸린다. 건전한 업무 환경을 조성하는 방법은 전화와 각종 방해 요소에 대해 지금까지와는 다른 태도를 갖는 것이다. 사람들은 일을 하기 위해 차분하고 조용한 환경을 제공받아야 한다. 즉 방해 요소로부터 완전히 차단된 시간이 필요하다는 것이다. 집중해서 일하고 싶으면 걸려오는 전화를 무시해도 될 만큼 효과적이고 수용가능한 방법을 찾아야 한다. 그러나 문제는 기술이 아니라 습관을 바꾸는 것에 있다. 어떤 혁신적인 도구보다 중요한 것은 태도를 바꾸는 것이다. 사람들은 때때로 전화를 받지 않아도 된다는 것을 배워야 하며 시간이- 시간의 양이 아니라 질이- 중요하다는 사실을 알아야 한다. 12. 사무실에 다시 문을 달자.  적절한 사무 공간이 누구에게나 정확히 똑같은 모양일 수는 없다. 개인의 공간과 팀의 공유 공간은 고유의 특성을 갖기 마련이다. 경영은 직원들이 자신에게 적합한 업무 공간을 만들 수 있도록 프라이버시를 보장해 줄 수 있는 방법을 제공하고, 충분한 공간과 조용한 분위기를 만들어 주는 것이어야 한다. 13. 진화하는 업무 공간   공간 문제를 회사 전체 차원에서 해결할 필요는 없다. 프로젝트 팀이나 업무 그룹을 회사 밖으로 이주시키는 것은 합리적이다. 특별히 마련된 공간에서 하는 일은 더 많은 에너지를 쏟게 하고 성공률도 높기 때문이다. 가장 핵심이 되는 프로젝트가 있다면 회사 밖에서 수행하게 하라. 정말 중요한 작업은 밖에서 더 잘되는 법이다.   3부. 꼭 필요한 사람들 14. 혼블로워 효과   조직 또는 회사에서, 엔트로피는 태도, 외모, 사고 과정의 획일성으로 간주될 수 있으며 기업 내 엔트로피는 항상 증가한다. 따라서 가장 성공적인 관리자는 비록 회사의 기준에서 벗어날지라도 유능한 사람들을 데려오고, 기업 내의 엔트로피를 줄이는 사람이다. 비록 회사가 전체적으로 이미 손쓸 도리가 없는 엔트로피 상태에 있더라도 적어도 관리자가 당당한 작은 부분에서는 그렇지 않도록 해야 한다.  15. 직원을 제대로 뽑으려면  지원자의 능력을 검증하기 위해 지원자가 만든 샘플(포트폴리오)을 제출 하도록 한다. 또한 채용 과정에 있어서 사회학적이고 인간적인 커뮤니케이션 기술을 확인하기 위해 오디션을 이용하는 것이 좋다. 다만, 적성검사는 채용 시에 사용해서는 안된다. 적성 검사는 거의 대부분 지원자가 채용 후에 수행하게 될 업무에 초점이 맞춰있으므로 단기적으로 업무를 잘할 수 있는 사람을 뽑는 데는 도움을 주지만 장기적으로는 도움이 되지 않는다. 16. 여기서 일하는 것에 만족합니다  사람들은 진정으로 머물고 싶은 느낌을 주는 회사에서 근무하고 싶어 한다. 가장 낮은 이직률을 기록하고 있는 회사들의 공통점은 끊임없는 재교육이다.  최고의 회사들은 기존 직원에 대한 재교육을 통해 지속성을 중시하는 태도를 형성하려고 한다. 그러한 태도가 기업에 자리 잡으면 이직률은 낮아지고 강력한 공동체 의식이 생겨난다. 또한 그렇게 함으로써 지출된 비용보다 더 많은 이익을 얻을 수 있다. 17. 자가 수정 시스템   호돈효과란 변화 자체가 중요한 것이 아니라 변화를 가져오는 행동 자체가 더 중요하다는 것이다. 즉, 사람들은 새로운 것을 시도할 때 더 나은 수행 능력을 보인다는 것을 의미한다. 호돈 효과를 업무에 적용하려면, 비표준화된 접근 방법을 규정으로 삼아야 한다. 만일 표준화된 방법이라면 모든 표준들의 총합은 10페이지를 넘어서는 안되며 간단하고 융통성이 있어야 한다.   4부. 드림팀 키우기 18. 전체는 부분의 합보다 더 크다. 단결된 팀은 강력하게 짜여져 전체가 부분의 합보다 더 큰 그룹을 말한다. 하나의 팀이 단결하기 시작하면, 성공의 가능성은 극적으로 커지며 그 팀은 거의 막을 수 없는 성곡을 위한 불가항력적인 존재가 된다. 하나의 팀이 굳게 단결하기 전에, 개인들은 다양한 목적을 지니고 있을 것이다. 그러나 단결의 과정에서 그들은 모두 공통의 목적을 지니게 된다. 팀의 목표는 목표의 달성이 아니라 목표의 일치이다. 팀원들이 즐겁게 일한다는 것은 팀이 단결되었다는 것을 보여주는 신호이며 단결된 팀은 프로젝트 기간 동안에 이직률이 낮다. 단결된 작업 집단은 거만하고 자족적이고 자극적이고 배타적일수 있으나 관리자의 실제적 목표 달성에 이바지 한다. 19. 블랙팀의교훈  북부 뉴욕에 한 회사에서는 최종 버그를 발견하기 위하여, 뛰어난 재능을 지닌 이들을 블랙팀으로 만들었다. 초기, 팀원들의 테스트 능력은 다른 동료들보다 약간 더 나은 정도였으나 동기부여는 다른 동료들보다 약간 더 잘되어 있었다. 블랙팀은 그들만의 특징을 형성하며 테스터 집단으로서 성공을 거두었다. 블랙팀의 구성원들은 팀의 일에 엄청난 열정을 갖게 되었고, 다른 동료들은 긍정적인 질투심을 갖게 되었다. 검은 옷을 입고 우스꽝스럽고 과장된 행동을 하는 것은 단지 그들이 느낀 재미의 일부였으나 팀 내의 공감대 형성이라는 궁극적 목표를 이루어 냈다. 20. 팀죽이기 팀 형성을 불가능하게 만드는 방법은 다음과 같다. <ol> <li>방어적 관리법 : 확실한 성곡을 보장받으려고 방어적 태도를 취하는 것은 상황을 악화시킬 뿐이다. 방어적 태도는 단기적으로 걱정을 덜겠지만 장기적으로는 전혀 도움이 되지 않는다. 결국 팀을 단결시킬 수 있는 가능성이 사라지기 때문이다.</li> <li>관료주의 : 관료주의가 팀 형성을 방해한다. 팀은 팀 내에서 만들어지는 목표가 무엇이든 그것을 신뢰해야 한다.</li> <li>팀을 따로 떨어뜨려 놓기 : 긴밀하게 상호 작용을 요구하는 사람들을 따로 떨어뜨려 놓는 것은 함께 일하는 직원들에게 소음과 방해의 원인이 된다. 반면 그들이 모두 같은 팀에 속할 경우, 동시에 함께 조용해질 가능성이 많다. 따라서 이러한 상황에서는 플로 상태를 방해발지 않고 일할 수 있다.</li> <li>여러 업무를 동시에 분담하기 : 동시에 여러가지 업무를 맡는 것은 팀 형성과 효율성에 좋지 않다. 오직 한 번에 하나의 업무만 맡도록 함으로써 여러 개의 업무를 동시에 떠맡아 시간을 쪼개게 하는 관행을 줄여 실질적으로 팀을 형성하는 기회를 제공할 수 있다.</li> <li>제품의 품질 저하 : 제품을 더 적은 시간 내에 만들어 내면 필연적으로 품질은 떨어지게 마련이다. 또한 품질을 낮추어서 제품을 생산하게 되면 제일 먼저 파괴되는 것은 팀 정체성이다.</li> <li>거짓 데드라인 : 데드라인을 촉박하게 설정해 놓으면 종종 직원들의 사기가 떨어진다. 하지만 촉박하지만 불가능하기 않은 최종 시한을 설정하면 팀은 그것을 즐거운 도전으로 받아들이기도 한다. 그러나 거짓으로 데드라인을 설정하는 것은 팀의 단결에 전혀 도움이 되지 않는다.</li> <li>소집단 관리 : 팀은 위계 질서가 있는 집단의 하부에서만 나타나는 것이다. 관리 단계에서는 단결된 팀이 존재할 수 없다. 관리자들이 팀에 결속된다면, 그것은 오직 그들이 관리자와 팀의 구성원이라는 이중적인 역할을 수행하기 때문이다. 조직의 상부로 올라가면 갈수록, 단결된 팀의 개념은 더욱더 멀어져서 결국 사라진다.</li> </ol> 21. 스파게티 회식  관리자는 팀원들이 함께 성공을 거둘 수 있는 작은 업무들을 끊임없이 제공한다. 업무는 쉬운 일들로, 팀원들이 함께 성공을 거두는 것에 익숙하게 만든다. 특별히 관리자가 개입하지 않고, 팀이 동료 집단으로서 다정하고 친밀하게 일할 수 있다면 가장 훌륭히 성공한 것이다. 최고의 관리자는 팀원들이 '관리되고 있다'라는 느낌을 받지 못하는 가운데 끊임없이 이런 기회들을 제공하는 사람이다. 22. 서로 신뢰하는 문화  최고의 회사에는 자연스러운 권위가 자유자재로 기능하고 있다. 관리자는 일반적인 방향 설정, 협상과 고용 같은 몇몇 분야에서 다른 직원들보다 뛰어나며 확실히 인정받고 있다. 각 직원들은 각각의 전문분야에서 다른 사람들보다 뛰어나고 그 분야에 자연적인 권위를 갖고 있다. 이러한 신뢰감 넘치는 분위기는 팀이 단결할 수 있는 최적의 조건이다. 23. 팀 형성을 위한 공감대 형성   건강한 기업을 만들기 위한 독자적 기법의 요소들 <ol> <li>품질을 중시하는 문화를 만들어라.</li> <li>종결감을 느끼게 하라.</li> <li>엘리트 의식을 키워 주어라.</li> <li>이질성을 허락하고 격려하라.</li> <li>성공적인 팀들을 잘 유지하고 보호하라.</li> <li>전술적인 것이 아니라 전략적인 방향을 제시하라.</li> </ol> 5부. 일은 재미있어야 한다 24. 때론 무질서가 필요하다 25. 자유 전자적 속성을 지닌 사람들 26. 잠자는 거인을 깨워라   6부. 피플웨어 그후 27. 다시 본 팀 죽이기 28. 과도한 경쟁은 단결을 해친다 29. 프로세스 개선 프로그램 30. 변화를 두려워하지 말라 31. 사람에게 투자하자 32. 조직 학습이 필요하다 33. 궁극적으로 관리자가 저지르는 죄 34. 공동체 형성   #2. 스크럼(Scrum) by Ken Schwaber, Mike Beedle 스크럼이란 애자일 개발방법론 중 하나로 복잡합을 제거하는 관리 제어 프로세스이다. 스크럼의 기본 개념은 단순하다. 앞으로 팀이 완료할수 있는 모든 것을 우선 순위에 따라 정리한 product backlog를 작성하고, 스프린트에서 수행할 일의 목록인 sprint backlog를 작성한다. 또한 매일 일정한 시간에 약 15분동안 팀원이 모여 일일 스크럼 회의 실시하고 burndown chart를 활용하여 스프린트(30일 반복주기)를 진행하는 것이다. 스크럼에서는 스프린트 동안의 관리자인 스크럼 마스터의 역할이 중요한데 팀원들이 스크럼 실천법을 실천하고 팀이 결정을 내리거나 필요한 자원을 얻을수 있도록 돕는 역할을 수행한다.   경험주의적인 관리 모델 : 스크럼에서 사용하는 경험주의적인 프로세스 관리 피드백 루프, 피드백 메커니즘을 이용해서 예측하지 못한 부분을 감시, 적응할수 있게 하고, 규칙성과 예측성을 제공한다. 스크림 팀원들은 경험에 기초해서 자신의 기술, 경험 그리고 현재 상황에 맞는 최선의 방법을 궁리하고 실행한다.  <img title="경험주의적_관리_모델.jpg" class="attachment" src="/pages/3795621/attachments/1906755" height="188" alt="경험주의적_관리_모델.jpg" width="433" style="WIDTH: 470px; HEIGHT: 248px;" />   I : 입력 또는 요구사항이나 기술  C : 일일 스크럼 회의와 매 스프린트의 마지막에 스크럼 진행 상황을 확인  O : 매 이터레이션마다 개발되는 제품 증분   생각해볼 문제.. <ol> <li> 스프린트는 반드시 30일이여야 할까? -> 몇 일로 할수 있을까? ; 저자는 30일이 절묘한 절충일임을 제안하며, 1달이 지나가면 관리자들이 프로젝트에 관여하고 싶어하는 충동을 억제하기 힘들어진다고 주장한다. 또한 먼저 30일 동안 진행한 후에, 스크럼에 어느 정도 적용이 되면 팀원들간에 상의하여 기간을 조정하도록 제안하고 있다. 그렇다면 과연 몇 일이 적당할까? 팀마다 고유의 특성과 프로젝트의 특성에 따라 팀원간의 적당한 절충점을 찾아가야 하겠지만, 2주 단위로 끊어서 생각해보는 것을 제안한다. ex) 2주, 4주, 6주, 8주.. </li> <li> 개방된 업무환경 -  항상 좋은 일만 벌어질 것인가? ; 저자는 개방된 업무환경 속에서 다양한 의견을 주고받으며 프로젝트의 생산성을 높임을 주장하고 있다. 그러나 오픈된 공간이 항상 좋은 일만 발생하도록 하는 것일까? 팀원이 한 공간에서 작업을 하는 것은 각자 떨어져서 작업을 진행하는 것보다 효과적임은 분명한 사실이다. 하지만 집중을 요구하는 개발하는 사람들에게는 오히려 개방적인 공간이 소음으로 인식될수 있음을 염두해야한다. </li> <li> 결과지향적인 스크럼이 바람직한가? - 목표를 얼마나 달성했는가를 평가, 목표를 달성하기 위해 사용되어진 시간은 평가하지 않는다 -> 생산성은 높아지지만 기능 축소, 비용 증가, 품질 저하는 어떻게 해결할 것인가? ; 스크럼은 결과지향적이다. 과정지향적이지 않다. 그러나 결과지향적인 것이 항상 생산성 향상에 도움이 되는 것일까? </li> <li> 일일 스크럼 회의를 15분간 진행하는 것이 현실적인가? ; 현실적으로 7(+-)2명의 팀원이 15분간 일어서서 미팅을 하는 것은 불가능하다고 생각한다. 어제 한일, 오늘 할일, 그리고 업무에 방해가 되는 내용을 한사람씩 보고하는 것이 일일 스크럼 회의의 목적이지만, 팀원간에 그에 따른 피드백도 요구되기 때문이다. 보고만 하기 위한 미팅이라면, 굳이 전화나 모임을 통해서가 아니라 메일같은 간접적인 의사소통으로도 가능하다. </li> <li> 변화를 싫어하는 사람들을 위해 자연스럽게 스크럼 실천법을 적용한다 -> 무엇부터 어떻게 해나갈 것인가? ; 대다수의 사람들은 변화를 싫어한다. 따라서 특정한 이름을 붙이고, 어떤 방법론을 사용하자고 제안할때 많은 사람들은 먼저 그것이 무엇인가를 확인하기 전에 거부 반응을 일으킬수 있다. 따라서 저자는 자연스러운 분위기 속에서 스크럼 실천법 적용을 제안하고 있다. 그렇다면 실제로 어떻게 적용해 나가는 것이 바람직할까? 우선 product backlog라든가 sprint backlog등 이런 개념을 명명하기보다는 자연스럽게 이루어 질수 있도록 하는 것이 필요할 것이다. 모든 프로젝트 개발에 있어서 먼저 사용자의 요구사항을 파악하고, 어떻게 일을 진행시켜나가야 할 것인가의 문제는 필수적이다. 따라서 이를 자연스럽게 적용해나가는 일이 요구된다.   </li> </ol> #3. Agile Project Management with Scrum  by Ken Schwaber 1. Backdrop : The Science of Scrum <ol> <li> Empirical Process Control In the long run, making successful products the first time using empirical process control turns out to be much cheaper than reworking unsuccessful products using defined process control.-> example(code review) Code review : 코드를 실행하지 않고, 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(defect)을 찾아내고 이를 개선하는 과정. forrnal한 코드리뷰기법일수록 결함발견에 집중하고, 소프트웨어 개발 주기의 후반에 위치하지만, lightweight한 코드리뷰기법은 결함의 발견뿐만 아니라 같은 로직을 여러 관점에서 생각하는 아이디어 회의나 주니어 개발자에게로의 지식 전달 등 부가적인 목적들을 함께 가지고 있다. Three legs that hold up every implementation of empirical process control : visibility, inspection, adaptation. Scrum Roles Three scrum roles : Product Owner, Team, Scrum Master Scrum Flow    </li> <li> New Management Responsibilities Scrum Master : managing the scrum process, like a sheepdog The ScrumMaster at MetaEco : (i) 스프린트 기간 동안 그의 팀과 일이 방해 받지 않도록 했으며 (ii) 프로세스가 MetaEco의 CEO와 회사의 요구에 부합하도록 하였다. The Product Owner at MegaEnergy : Janre(Product Owner)는 제품 백로그에서 가장 우선순위가 높은 요구사항을 반영한 작업을 선정하여 작업을 진행시켰고 MagaEnergy는 빠른 자동화를 통하여 이익을 창출시켰다. The Team at Service1st : 17명 team-> 4 subteams(3~5명) self-organizing team.    </li> <li> The ScrumMaster The ScrumMaster is responsible for the success of the project, and he or she helps increase the probability of success by helping the Product Owner select the most valuable product backlog and by helping the Team turn that backlog into functionality. (i) The untrained ScrumMaster at Trey Research : Daily Scrum에서의 오류=> self-organizing team의 중요성을 잊고 있었다. (스크럼 마스터가 지시한 일을 팀원이 지난 스크럼 미팅 이래로 이행하였는가를 확인, 지금과 다음 스크럼 미팅 사이에 할 일을 각 팀원에게 지시, 목표에 도달하기 위해서 스크럼 마스터가 도와줄 수 있는 일이 무엇인가를 찾음) c.f.) Critical shift from controlling to facilitating, from bossing to coaching (ii) The untrained ScrumMaster at Litware : ScrumMaster인 John은 ScrumMaster의 역할에 대해 이해하지 못했고 ScrumMaster로서의 역할을 충실히 수행하지 못했다. 따라서 ScrumMaster의 역할을 중요시 생각하는 다른 팀원으로 대체시켰다. (iii) Overzealous at Contoso.com : ScrumMaster는 변화가 필요하면 바꿔야 한다. 그러나 변화가 문화적으로 수용되지 않을 경우, ScrumMaster는 이를 받아들여야 한다. Scrum은 가능한 것을 바꾸는 것이다.(The art of the possible) (iv)Wolves at MegaFund :  ScrumMaster는 스크럼 룰과 실행방법을 조직에 잘 적응시키고 자신의 의무를 잘 이행해야 한다.    </li> <li> Bring Order from Chaos Service1st, Tree and Lapsec 의 프로젝트는 모두 너무 복잡해서 project planning과 control practices가 실패했다. 그러나 self-organization을 통해 풀어나갔다. 상황이 너무 복잡해서 개인들이 계획을 실행하는데 어려움이 있었지만 스크럼마스터로서 coach하고 mentor했다. </li> </ol>   Service1st : 팀에게 하나씩의 일만 부여하고, 이것에만 집중하도록 함. Tree : Scrum of Scrums – the work of many teams is coordinated by individuals from each of the teams Lapsec : 팀에게  실제  일과  비슷한  예제를  제공하여, 스크럼을  이해하도록  도왔다.     The Product Owner     ScrumMaster는  개발팀과  제품관리자와  고객 간의  장벽을  없애서  고객이  개발에  직접적으로  참여할  수  있도록  하는데  책임이  있다. 또한  제품관리자가  제품 투자수익률(ROI)를  최대화하고  제품의  목적에  충족할  수  있도록 Scrum을  사용하는  방법을  보여주어야  한다.    스프린트 리뷰 : collaboration – a vibrant demonstration of a reality XFlow at MegaFund : Goeff(product owner)는 미팅을 통해 MegaFund에서 성공적인 organization을 만들었다 – engineer와 internal customer의 요구사항이 달라 갈등이 있었지만 미팅을 통해 두 집단간이 공통으로 생각하는 우선순위 작업을 결정(7가지의 item과 bug를 fix하는 일)하고 30일간의 개발과정을 통해 output을 만들어냈다. Geoff는 전통적인 스크럼 제품관리자가 아니었고, product backlog도 사용하지 않았으나 스프린트 계획 미팅에서 개발팀을 만났다. Geoff는 “the art of the possible”과 고객과 엔지니어 팀간의 직접적인 협력을 가능하게 했다. Face to face로 만날 때, 요구와 문제들은 상당히 overlap된다. Company goal at Techcore :  Company goal at MegaBank Funds Transfer system : the importance of taking in plain language Project manager인 Pat은 FTS(Fund Transfer System)에 스크럼을 사용하면 고객들로 하여금 개발 프로젝트에 보다 참여시키는데 도움을 줄 것이라고 생각했다. Product backlog(작업의 우선순위 리스트)를 사용, 한 달을 개발주기로 삼았다. FTS팀과 경영팀간의 의사소통을 위해 공통된 언어의 사용이 필요하다. 팀(기술용어 사용)과 제품 관리자(비즈니스 요구와 목적)는 스크럼을 사용하기 전, 서로 다른 언어를 사용했다. 그러나 스크럼에서는 product backlog를 사용(common denominator), 제품 관리자와 팀 have collaborated to do the best for the business, Each collaboration has resulted in an improved ROI.       #4. 익스트림 프로그래밍(Extreme Programming Explained)  by Ken Beck, Cynthia Andres <a href="/pages/3795621/attachments/1956129" title="익스트림_프로그래밍(1).ppt" class="attachment"> 익스트림_프로그래밍(1).ppt</a> <ol> <li> XP란 ? <ol> <li>오래되고 효과가 없는 사회적 습관들을 버리고 효과 있는 새로운 습관들을 채택하는 것</li> <li>오늘 내가 기울인 모든 노력에 대해 자신을 인정해 주는 것</li> <li>내일 좀 더 잘해보려고 애쓰는 것</li> <li>팀 전체가 공유하는 목표에 내가 얼마나 기여했는지를 잣대로 자신을 평가하는 것</li> <li>소프트웨어 개발을 하는 중에도 여러분의 인간적 욕구(인간관계를 맺고 싶다는 욕구도 포함) 가운데 일부를 채우겠다고 요구하는 것</li> </ol> </li> <li>XP의 패러다임 : 깨어 있고 적응하며 변하는 것</li> <li>  가치, 원칙, 실천방법 <ol> <li>가치 : 의사소통, 피드백, 단순성, 용기, 존중</li> <li>원칙 : 인간성, 경제성, 상호이익, 자기유사성, 개선, 다양성, 반성, 흐름, 기회, 잉여, 실패, 품질, 아기발걸음, 받아들인 책임</li> <li>실천방법 : 함께앉기, 전체팀, 정보를 제공하는 작업공간, 활기찬 작업, 짝 프로그래밍, 짝 프로그래밍과 개인적 공간, 스토리, 일주일별 주기, 분기별 주기, 여유,</li> </ol> </li> </ol>              10분 빌드, 지속적 통합, 테스트 우선 프로그래밍, 점진적 설계 <참고 > 보조실천방법 : 진짜 고객참여, 점진적 배치, 팀 지속성, 팀 크기 줄이기, 근본원인분석, 코드공유, 코드와 테스트, 단일코드기반, 매일배치, 범위협상계약, 사용별지불   <ul> <li>전체 XP팀</li> </ul>   테스터 : 구현을 시작하기 앞서, 고객이 자동화된 시스템 차원의 테스트를 선택하고 작성하는 일을 돕고, 프로그래머에게 테스트 관련 기법 지도  상호작용 설계자 : 시스템 전반적인 메타포를 선택하고, 스토리들을 작성하고, 새로운 스토리들을 찾아낼 기회를 잡기 위해 이미 배치된 시스템의 사용 양상을 조사, 최종 사용자의 문제거리를 해결 -> 우선순위가 높은 작업  아키텍트 :  대규모 리팩토링을 찾아내고 실행하는 일, 아키텍처를 집중 테스트하는 시스템 차원의 테스트를 작성하는 일, 스토리를 구현하는 일  프로젝트 관리자 : 팀 내의 의사소통이 용이하도록 하고, 고객과 공급자 그리고 조직의 다른 부분과의 의사소통을 조정, 팀의 역사가로 활동, 팀에게 프로젝트의 진전 정도를 상기시킴, 게획과 현실이 계속 일치하도록 유지시킬 책임이 있음  제품 관리자 : 스토리를 작성하고, 분기별 주기에서 주제와 스토리들을 고르고, 일주일별 주기에서 스토리들을 고르고, 구현 과정 중 스토리에서 완전하게 명세되지 않은 부분들이 드러날 경우 질문에 답변하는 일을 수행  임원 : XP 팀을 후원하거나 감독하는 일, 개선을 감시하고, 권장하고, 조장하는 일  테크니컬 라이터(기술적 출판물) : 기능에 대한 빠른 피드백 제공, 사용자들과 긴밀한 관계  사용자 : 스토리를 작성하고, 고르는 일을 돕고 개발 중에 문제영역에 관련된 결정을 내림, 사용자가 전체 공동체를 대변  프로그래머 : 스토리와 과업을 추정, 스토리를 과업으로 나누고, 테스트 작성, 기능을 구현하는 코드 작성, 개발 프로세스 자동화, 시스템의 설계 개선  인적자원부 : 평가와 채용   <ul> <li> 계획짜기 : 범위를 관리하기 </li> </ul> 매일, 매주, 매분기별로. 시간과 비용 , 품질. yeasterday's weather. <ol> <li>목록작성</li> <li>시간추정</li> <li>주기를 위한 예산</li> <li> 해야할 일을 예산범위내에서   </li> </ol> <ul> <li>테스트 : 일찍, 자주, 자동화</li> </ul> 팀 내부의 신뢰와 고객과의 신뢰를 강화함으로써 개발에 기여 테스트 비용효율을 높이기 : 재확인(double checking), DCI(defect cost increase)   <ul> <li>설계하기 : 시간의 가치</li> </ul>  XP : 언제나 설계하라, 지속적인 설계비용을 낮추려는 의도를 담고 있다   <ul> <li>테일러주의와 소프트웨어</li> </ul>  테일러- 과학적 관리(공장 생산성을 개선하기 위해 관찰과 가설, 실험을 적용) <ol> <li>계획과 실행의 분리 : 교육받은 공학자(아키텍처, 프레임워크 그룹), 작업자-기계부품</li> <li> 품질부서 따로 두기 : 품질과 엔지니어링을 조직 구조에서 분리하면 품질 부서가 하는 일의 성격이 징벌적이 된다   </li> </ol> <ul> <li>도요타 생산 시스템</li> </ul>  going fast -> 자동차 생성 공정의 모든 단게에서 쓸모없이 낭비되는 노력 제거  TPS(Toyota Production System) : 엄격한 사회계층화 없음, 전체 조직이 품질 조직, 과잉 생산의 낭비가 가장 큰 낭비,  TPS와 소프트웨어개발의 유사점 : 작업자들의 교차훈련, 공장을 세포로 나누어 조직, 고객과 공급자 사이에 이익을 공유하는 계약 작성   <ul> <li>XP 적용하기예</li> </ul> 자기 자신부터의 변화 -> 조직의 변화 비즈니스와 기술관심이 조화를 이루도록 해야함 단, XP의 가치와 조직의 진짜 가치가 어긋날 때는 XP의 사용은 부적절    #5. 린 소프트웨어 개발(Lean Software Development)  by Mary Poppendieck, Tom Poppendierk  린의 7가지 원칙 1. 낭비를 제거하라 ; 실질적으로 고객의 가치를 높이는 일에 시간을 쓰기 낭비 찾기- 미완성작업, 가외기능, 직무전환, 대기, 이동, 결함 가치흐름도 작성 - 낭비확인가능(가치측정, 개선하는 시작점 찾기 가능), 고객요구 신속대응, 실제 가치를 생산하는 활동으로 묶임   2. 배움을 증폭하라 ; 어려운 문제가 있을때 피드백을 증가시키기 피드백 - 개발 프로세스에 문제가 생겼을때, 피드백 횟수를 늘리기, 스래싱이 생기지 않으면서 가능한 짧게 반복(린의 기본 원칙)- JIT(Just In Time)흐름;작업자의 충분한 의사소통->품질문제발생확인, 작은단위의 작업->짧은 피드백, 짧은 반복 주기; 설계.구현.테스트 주기를 소화할만큼 길면서 고객에게 피드백을 자주 받을만큼 짧을것, 고객이 중요하게 여기는 기능을 골라서 계획 동기화 - 코드공유; 스패닝 어플리케이션(소규모team->전체시스템), 매트릭스(전체아키텍어->독립된 컴포넌트, 서브시스템) 집합 기반 개발방법 - 점/집합(제약조건알아내기, 적은데이타->많은정보전달->강력한의사소통형태, 선택미루기)   3. 가능한 늦게 결정하라 ; 선택이 유효할 때까지 되도록 결정하지 않은 채로 두기. 그러나 그 이상은 안됨 대안적 사고 -  결정미루기(HP;전기코드, JIT;복잡성을 통제-> 되돌릴 수 없는 활동을 최소로 줄이는 것), 옵션(미래에 어떤 것을 할수 있는 권리, 고객의 요구를 명확히 이해하고  개발중인 기술이 성숙할 시간을 가질때까지 결정을 미룰수 있도록 함) 책임이 따르는 마지막 순간 - 결정을 미루는 몇 가지 전술(부분적으로 완료된 설계 정보 공유(짧고 반족적인 탐험주기를 통한 설계), 작업자들 간 직접 협력체계구성(직접 의사소통), 변화를 수용하는 방법에 대한 감각을 개발(전문가;오류가 문제를 일이키기전에 수정), 한분야에서 특히 중요한것이 무엇인지 느끼는 감각을 계발, 결정을 언제 내려야 하는지 감각 키우기, 빨리 반응하는 능력 개발 의사결정 - 너비우선(깔데기-다양한 전문적 지식을 가진 사람 필요)vs깊이우선(터널-초점을 맞추는 올바른 선택이 있을때 효과적),  단순한 규칙(결정이 필요할때 필요한 곳에서 현재 정보를 고려하여 즉시 이루어지도록함),   4. 최대한 빨리 납품하라 ; 고객이 요구하는 가치를 실현하도록 빨리 납품하기 당김 시스템 - pull(고객의 요구가 일을 끌어당기도록 하는것); 생산라인 끝에서 변화 고려, 칸반-인덱스카드+ 일일회의 대기행렬 이론 - 순환주기줄이기(일정한 도착률, 일정한 서비스율, 여유) 지연비용 - 개발 프로젝트의 간단한 경제 모델 만들기-> 개발팀의 트레이드오프 결정의 길잡이   5. 팀에 권한을 위임하라 ; 사람들이 자신의 잠재력을 써서 가치를 더할수 있도록 하기 자기 결정권 - 워크아웃(노동자->관리자) 동기 부여 - 작은 실수보다 지시하는 방식이 장기적으로는 심각 리더십 -  개발명인(개발자의 역량을 이끌어내기) 전문지식 - 뉴코, 전문 지식 커뮤니티 필요   6. 통합성을 구축하라 ; 처음부터 통합성을 생각하여 만들기(interface) 인식통합성 - 고객이 시스템을 사용하면서 겪는 경험전체와 관련 -> 시장점유율 개념통합성 - 시스템을 구성하는 중심 개념들이 총체적으로 자연스럽게 결합한 통일체 리팩토링 - 시스템을 개발하면서 설계를 변경, 지속적인 개선(린) 테스트 - 실제로 작동하는가에 대한 피드백 제공   7. 전체를 보라 ; 전체를 희생하여 부분을 최적화하려는 유혹을 경계하기 측정 - 성과측정-> 정보측정 계약 - 시간자재계약(동시개발방법, 고객이 범위를 제한 ->비용을 쉽게 조정), 단계적 계약(주계약 이용, 각반복주기에서 릴리즈), 목표비용계약(양측 작업자에게 목표비용을 맞추는 선에서 문제의 해결책을 찾는데 권한 부여), 이익공유계약(시간이 지남에 따라 상호이익을 위해 양측이 하는 일을 수정가능) => 범위를 상세히 결정하지 않음   #6. Practices of an Agile Developer   Beginnig Agility <ol> <li> <ol> <li>Work for outcome(Blame doesn't fix bugs) : 불평을 들으면 구체적인 원인을 찾고, 도울 수 있는 일을 찾기</li> <li>Quick fixes Become quicksand(Don't fall for the quick hack) : code review, unit testing</li> <li>Criticize Ideas, not people(-) : negativity kills innovation</li> <li>Damn the torpedoes, go ahead(do what's right) : 정직하게, 사실을 말하는 용기를 갖기</li> </ol> </li> <li> Feeding Agility <ol> <li>Keep up with change(keep up with changing technology) : 변화에 속도에 맞춰 career와 project를 맞춰라</li> <li>Invest in your team(Raise the bar for you and your team) : brown-bag session</li> <li>Know when to unlearn(Learn the new; unlearn the old) : 새로운 기술을 배울땐, 오래된 습관을 버릴것</li> <li>Question until you understand(keep asking why) :  이슈의 본질을 이해할때까지 질문을 계속하기</li> <li>Feel the rhythm(Tackle tasks before they bunch up) : stand-up meeting, iteration length -> 정기적인 리듬은 결정을 내리고, 프로젝트 진척을 돕는다.</li> </ol> </li> <li> Delivering what users want <ol> <li> Let customers make decisions devil - 개발자들은 창조적이고 이성적이므로 application에 대해 가장 잘 알고있다. 따라서 개발자들이 모든 critical한 결정을 내려야 한다 angle - Let your customers decide : business owners가 이해할수 있는 언어로 자세하게 제시한 다음, 그들이 결정을 내리도록 하라. </li> <li>Let design guide, not dictate(A good design is a map : let it evolve) :</li> <li> Justify technology use devil - resume driven design angle - Choose technology based on need : 먼저 필요한게 무엇인지 결정하고, 그러한 구체적인 문제에 적용할 기술적인 사용에 대해 평가하라. </li> <li> Keep it releasable devil -  지금 당장 고쳐야할 무언가를 발견하면 하고있는 일을 멈추고 결함을 고쳐라 angle - keep your project releasable at all times :언제나 프로젝트가 compilable, runnable, tested, deploy되어 있게 하라 </li> <li> Integrate early, integrate often devil - 프로젝트가 끝날때 code를 integrate할 시간이 많이 있다 angle -  code integrate를 일찍, 그리고 정기적으로 계속 할수록 위험은 줄어든다 </li> <li> Automate deployment early devil - it's ok to install your product manually, especially to QA. you don't have to do it all that often, and they are pretty good about copying all the right files. angle - deploy your application automatically from the start : Use that deployment to install the application on arbitrary machines with different configurations to test dependencies. QA should test the deployment  as well as your application </li> <li>  Get frequent feedback using demos devil -  It's not your fault : the problem lies with our customers - those pesky end users and clients angle -  Develope in plain sight : keep your application in sight during development. Bring customers together and proactively seek their feedback using demos evey week or two </li> <li> Use short iterations, release in increments devil - We've got this beautiful project plan with all the tasks and deliverables scheduled for next three years. When we release the product then, we'll capture the market! angle - Develop in increments : Release your product with minimal, yet usable, chunks of functionality. Within the development of each increment, use an iterative cycle of one to four weeks or so. </li> <li> Fixed prices are broken promises devil - We have to deliver a fixed bid for this project. We don't have all details yet but need to put a bid in. I need an estimate for the whole team by Monday, and we'll have to deliver the whole project by the end of the year angle - Estimate based on real work : Let the team actually work on the current project, with the current client, to get realistic estimates. Give the client control over their features and budget.   </li> </ol> </li> <li> Agile feedback <ol> <li> Put Angle on your shoulders devil - You can't justify the time and effort it takes to write unit tests. It will just delay the project. You're a darn good programmer anyway- unit tests are just a waste of time, and we're already in a crunch Coding feedback angle - Use automated unit tests : Good unit tests warn you about problems immediately. Don't make any design or code changes without solid unit tests in place </li> <li> Use it before you build it devil - Go ahead and complete all of your library code. There's plenty of time later to see what people think of it. Just throw the code over the wall  for now. I'm sure it's fine Write tests before writing code Good design doesn't mean more classes angle - Use Test Driven Development as a design tool. It will lead uyou to a move pragmatic and simpler design </li> <li> Diffrent makes a differnce devil - As long as the code works on your machine, that's Ok. Who cares it works on some other platform? You don't have one Automate to save time angle - RUne unit tests on each supported platform and enviroment combination, using continuous integration tools. Actively find problems before they find you </li> <li> Automate acceptance testing devil - All right, so your unit tests verify your code does what you think it should. Ship it. We'll find out it it's what the customers want s soon enough angle - Create tests for core buiness logic ; HAve your customers verify these tests in isolation, and exercise them automatically as part of your general test runs </li> <li> Measure real progress devil - Please use your time sheets to report your progress. We'll use these for project planning. Always fill in 40 hours each week., regardless of how much you really worked Focus on where you're going angle - Measure how much work is left : Don't kid yourself - or your team- with irrelevant metrics. Measure the backlog of work to do </li> <li> Listen to uers devil - Users are always complainning. It is not your fault; they are just too sEvey complaint holds a truthtupid to read the stinkinn' manual. It is not a bug; they just don't understand. They shoud know better It is a bug angle - Every complaint holds a truth; Find the truth, and fix the real problem   </li> </ol> </li> </ol>  5. Agile code <ol> <li> <ol> <li> Program intently and expressively devil - Code that works and is understandable is nice, but it's more important to be clever. You are paid for being smarts; show us how good you are angle - Write code to be clear, not clever; Expres your intentions clearly to the reader of the code. Unreadable code isn't clever </li> <li> Communicate in code devil - Comments should help out when the code is too tangled to read. Expalin exactly what the code is doing, line by line. DOn;t worry ahout why, jus tell us what on Earth it's doing Don't comment to cover up angle - Comment to communicate : Document code using well-chosen, meanigful names. Use commments to describe its purpose and constraints. Don;t use commenting as a substitute for good code (COmments fieel like helpful friends; you can read them and quickly scan code to fully understand what it's doing and why) </li> <li> Actively evalute trade-offs devil - Performance, productivity, elegance, cost, and time to market are the most important,critical issues in software development. You have to maximize all of them No best slution angle - Consider performance, convenience, productivity, cost, and time to market. If performance is adequate,then focus on improving the other factors. Don't complicate the design for the sake of perceieved performance or elegance. </li> <li> Code in increments devil - Real programmers work for hours and hours straight, without a break, without even looking up. Don't break your flow to stop and compile; just keep typing angle - Wtite code in short edit/ bulid/ test cycles : It's better than coding for an extended period of time. You'll create code that's clared, simpler, and easier to maintain </li> <li> Keep it simple devil - Software is complex business. Any fool can write simple, elegant software. You'll get fame and recognition(not to mention job security) by writng the most sophisticated, complex programs possible Simple is not simplistic angle - Develop the simplest solution that works ; Incorporate patten, principles, and technology only if you have a compelling reason to use them (Code is easy to follow and correct) </li> <li> Write cohesive code devil - You are about to write some new code. and the first decision you need to make is where to put it. It doesn't really matter where it goes, so just go ahead and add it to the class that happen to be open in your IDE now. It's easier to keep track of code when it;s all in one big class or component anyway angle - Keep classes focused and components samll : Avoid the temptation to build large classe or components or miscellaneous catchall classes (Classes and componets feel tightly focused; each does one thing,and does it well. Bugs are easy to track down, and code is easy t modify because responsibilities are clear) </li> <li> Tell, Don't ask devil - Don't trust other objects. After all, they were written by other people, or even by you last month when you weren't smart. Get the information you need from others, and then do your own calculations and make youe own decisions. Don't give up control to others Keep commands seperate from queries angel - Don't take on another object's or component's job. Tell it what to do, and stick to your own job (Smalltalk uses the concept of "message passing" instead of method calls, tell, Don't ask feels your are sending messages, not calling functions) </li> <li> Substitute by contract devil - Deep inheritance hierachies are great. If you need functionality from some other class, just inherit from it! and don;t worry if your new class breaks things; your callers can just change their code. It's their problem, not yours Use inheritance for is - a ;use delegation for has - a or uses - a angle - Extend systems by substituting code ; Add and enhance features by substituting classes that honor the interface contract. Delegation is almost always preferable to inheritance (It feels sneaky ; you can sneak a replacement component intothe code base without any of the rest the code knowing about it to achieve new and improved functionality)   </li> </ol> </li> <li> Agile Debugging <ol> <li> Keep a solution log devil - Do you often that deja vu feeling during development? Do you often get that dejavu feeling during development? That's Ok. You figured it out once. You can figure it out again Don't get burned twice angle - Maintain a log of problems and their solutions : Part of fixing a problem is retaining details of the solution so you can find and apply it later </li> <li> Warning are really errors devil - Compiler warnings are just for the overly cautious and pedantic. They are just warnings after all. If they were serious, they'd be erroes, and you couldn't cmpile. So just ignore them , and let'er rip angle - That warning as errors : Checking in code with warnigs is just as bad as checking i cde with errors or cde that fails its tests. No checked- in code should produce any warning from the build tools </li> <li> Attack problems in isolation devil - stepping line by line through a massive code base in pretty  scaray. But the only way to debug a signifucant problem is to look at the entire system. All at once. After all, you don't know where the problem may be, and that's the only way to find it Prototype to isolate angle - seperate a problem area from its surroundings when working on it, especially in a large application (When faced with a problem taht you have to isolate) </li> <li> Report all exceptions devil - Protect your caller rom weird exceptions. It's your job to handle it. Wrap everything you call, and send your own exception up instead - or just swallow it angle - Handle or propagate all exceptions : Don't suppress them, even temporarily. Write your code with the expection that things will fail (You feel you can rely on getting an exception when something bad happens. There are no empty exception handlers) </li> <li> Provide useful error messages devil - Don't scare the users, or even other programmers. Give them a nice, sanitized error message. Use something conforting like "Use Error. Replace, and Continue" angel - Present useful error messages : Provide an easy way to find the details of errors. Present as much supporting detail as you can about a problem when it occurs, but don't bury the user with it (Error messages feel useful and helpful, When a problem arises, you can hone in on the precise details of what went wrong, where)   </li> </ol> </li> </ol>   <ol> <li> Agile collaboration <ol> <li> Schedule regular face time devil - you need to hold meetings - lots of them. In fact, we're going to keep scheduling more meetings until we discover why no work is getting done question- 1. what did I achieve yesterday? 2. what am I planning to do today? 3. what's in my way? angel - Use stand- up meeting : stand-up meetings keep the team on the same page. Keep the meeting short, focused, and intense </li> <li> Architects must write code devil - Fired, our expert architect, will deliver a design for you to code. He's very experienced and very expensive, so don't waste his time with silly questions or implementation problems You  can't code in PowerPoint angle - Good design evolves from active programmers : Real onsight comes from active coding. Don't use architects who don't code- they can't design without knowing the realites of your system (Architecture, design, coding, and testing feel like diferent facets of the same activity - development. They shouldn't feel like seperate activities) </li> <li> Practice collective ownership devil - Don't worry about that crippling bug ; Joe will fix it when he gets back from vacation next week. Just work around it until then angel - Emphasize collective ownership of code : Rotate developers across different modules and tasks in different areas of the system  (You feel comfortable working on most any part of the project) </li> <li> Be a Mentor devil - It took you a long time and a lof of hard work to get where you are. Keep it to yourself so you look better. Use your superior skills to intimidate your teammates Knowledge grows when given angle -  Be a mentor : There's fun in sharing what you know - you gains as you give. You motivate others to achieve better results. You improve the overall competence of your team (You find that teaching is another way to improve your own learnining, and others come to trust that you can help them) </li> <li> Allow people to figure it out devil - You're so smart ; just provide neat solutions to others on the team. Don't waste time trying to educate them angle - Give others a chance to solve problems: Point them in the right direction instead of handing them solutions. Everyone can learn something in the process </li> <li> Share code only wwhen ready devil - Check in all code as often as you can, especially when you leave for the day, whether it's ready or not angle - Never check in code that's not ready for others. Deliberately checking in code that doesn't compile or pass its unit tests should be considered an act of criminal project negligence </li> <li> Review code devil - Users make great testers. Don't worry - if it's wrong, they'll tell us eventually angle - Review all code : Code reviews are invaluable in improving the quality of the code and keeping the error rate low. If done correctly, reviews can be practical and effective. Review code after each task, using differnt developers (Code reviews happen in small chunks, continuously. It feels like an ongoing part of the project, not a big scary event) </li> <li> Keep others informed devil - The manager, your team, and the business owners are relying on you to get tasks done. If they want your status, they'll ask you for it. Just keep your head down, and keep working angle - Publish your status, your ideas and the neat things you're looking at. Don't wait  for others to ask you the status of your work (You don't feel pestered by managers or co-workers constantly asking for your status or your lastest design or research efforts) </li> </ol> </li> </ol>   #7. 엔터프라이즈급 애자일 방법론(프로젝트 규모 확장에 따른 애자일 기법과 사례) - 딘 레핑웰   1부 . 소프트웨어 애자일 방법론 소개   (1)   폭포수 개발방법론의 문제점 – “일정관리”    (a) 요구사항을 잘 이해하고, 제대로 정의하려면 시간을 투자해야 한다. : 개발자나 고객이 모든 요구사항을 완벽하게 이해하고 있다거나 사전에 누군가가 이해하고 있을 것이라고 가정하면 안 된다. (b) 변경사항은 많지 않을 것이고 수용 가능할 것이다. : 변경사항은 지속적으로 생겨나며, 변경사항을 잘 추적하기 위해서 좀 더 시간이 필요하다고 가정하는 편이 낫다. (c) 시스템 통합은 순조로울 것이다. : 시스템 통합은 중요한 프로세스이며 위험을 줄이는 본질적인 요소라고 가정해야 한다. 그러므로 프로젝트를 시작할 때부터 통합을 시작하여 프로젝트가 끝날 때까지 지속해야 한다. (d) 일정에 맞게 완료할 수 있다. : 새롭고 최첨단에 혁신적이고 검증되지 않았으며 위험 요소가 있는 소프트웨어 프로젝트는 기능이 고정된다 하더라도 일정 안에 완료할 수 있다고 가정하면 안 된다. 오히려 할 수 없다고 가정해야 한다. 대신, 중요한 기능에 대해서는 소비자가 예상하는 것보다 빠르게 완료할 수 있다고 가정한다. 원하는 것이 아니더라도 즉각적인 소비자의 피드백 덕분에 모든 것을 재 작업하는 일은 일어나지 않는다.   (2)   XP(eXtreme Programming) 모호하고 빠르게 변하는 요구사항을 가지고 일을 하는 중소규모 팀을 위한 경량화된 방법론 문서화 작업을 최소화 -> 코드를 작성하면서 잘못된 부분을 직접 발견하고 수정하면서 비용을 최소화   XP의 특징 (i)             5명에서 10명으로 구성된 프로그래머가 고객과 함께 한 장소에서 일한다 (ii)            개발은 점진적으로 자주 이뤄지고 각 단계마다 산출물의 기능을 덧붙여 나간다 (iii)           요구사항 정의 시에는 사용자가 요구하는 새로운 기능을 스토리 형태로 구체적으로 작성한다 (iv)           프로그래머는 엄격한 코딩 규칙을 준수하고 짝(pair)를 이뤄 일하며 단위테스트를 실시한다 (v)            요구사항, 아키텍처, 디자인은 프로젝트 중간에 언제든지 발생한다   XP의 핵심가치: 의사소통, 단순성, 피드백, 용기, 존중 XP의 practices (i)             함께 앉기: 관리자와 팀원이 함께 앉기, 공동체라는 생각과 격의 없는 대화가 꾸준히 일어나는 곳 (ii)            하나의 팀: 여러 프로젝트를 동시에 수행하는 것 금지 (iii)           정보를 제공하는 작업공간: 시각적인 환경 -> 모든 스토리를 한눈에 볼 수 있도록 벽에 전시 (iv)           열정적인 작업: XP로 일하는 동안은 개인적인 업무나 사적인 일을 고려하지 않는다 (v)            짝 프로그래밍: 코드와 테스트 케이스에 대해 즉각적인 피어 리뷰 -> 좋은 품질의 코드생산 (vi)           스토리: 유동적, 정의된 이후 구현을 하는 동안 수정될 수도 있고 우선순위 변경도 가능 (vii)          주 단위 주기: 개발상황은 주단위로 평가 (viii)         사분기 주기: 주제, 서사, 릴리스, 주요산출물 등 막대한 노력이 필요한 작업들은 사분기 단위로 계획, 사분기는 업계에서 성과나 측정을 위해 지금도 사용하고 있는 단위 (ix)           느슨함: 고도의 생산성을 요하는 프로세스에서 약간의 느슨함은 팀웍과 인간미 유지에 도움 (x)            10분 빌드: 10분 안에 전체 시스템을 빌드하고 테스트 할 수 있어야 함 (xi)           지속적인 통합: XP에서 모든 변경사항은 몇 시간 이내, 최소한 하루 이내에는 통합되고 테스트되어야 한다 (xii)          테스트 우선 프로그래밍: 코드를 작성하기 전, 실패할 테스트 케이스를 먼저 작성 (xiii)         점진적 설계: 지나치게 복잡하게 설계된 부분을 찾아 재설계하고, 코드를 리팩토링한다. 그리고 자동화된 테스트를 다시 한번 수행한다.   (3)   스크럼 스크럼의 특징 (i)             소규모의 기능협업 팀들은 30일간의 제품 릴리스를 점진적으로 수행하는 개방된 환경에서 모여 함께 일한다. 이 기간을 스프린트라고 한다 (ii)            팀은 스프린트의 목적을 달성하기 위해 스스로 방향을 잡고 권한을 갖는다 (iii)           스크럼 마스터가 팀웍을 북돋운다. 스크럼 마스터는 기술적인 방향은 제시하지 않지만 스크럼의 핵심 원리를 강화하고 방해요인은 제거한다 (iv)           각 스프린트의 우선순위를 정의하는 제품 백로그를 통해 작업을 구성한다   스크럼에서의 역할 (i)             제품 책임자: 고객의 의견을 대변하고 팀에 관련된 이해관계자의 관심사항을 표명하는 책임을 갖고, 제품 백로그를 관리한다 (ii)            스크럼 마스터: 팀이 목표를 성취하도록 돕고, 팀원 모두에게 스크럼을 지도하며 스크럼 활동과 규칙을 이행하도록 이끈다 (iii)           팀: 기능을 구현한다. 팀의 구성원은 업무를 정의하고 분배, 관리하는 작업을 스스로 진행하며, 다른 사람과 수행업무를 교환하고 협업한다   스크럼의 기본원리: 경험적 프로세스 제어 반복적으로 수행되는 프로세스에서 만족스러운 품질의 산출물을 만드는 것을 정의된 프로세스 제어라고 한다. 프로세스 진행 중 예측 불가능해서 계획과 예측으로 이뤄진 ‘정의’를 통한 접근법의 사용이 어려운 경우, 측정과 조정으로 이뤄진 ‘경험’을 이용하는 접근법을 선택하는 것이 바람직 (4)   RUP 래셔널 소프트웨어 사(현재는 IBM의 래셔널 소프트웨어 사업부)에서 상용으로 개발한 프로세스와 프로세스 프레임워크 반복적이고 점진적인 개발방법론에 기반한 소프트웨어 개발 프로세스이자 프로세스 프레임워크   주요특성 (a) 4가지 생산단계: 개념화(inception) – 정교화(elaboration) – 구축(construction) – 전이(transition) (b) 소프트웨어 개발방법론과 여러 소프트웨어공학 활동을 제공하여 소프트웨어 개발에 필요한 주요 분야들을 다룬다 (c) 반복적이다. 각 단계에서 프로젝트는 여러 반복(iteration)을 거친다. 초반의 반복: 비즈니스 활동과 요구사항, 아키텍처의 기본을 만든다. 후반의 반복: 구현과 배포에 전념한다. (d) 점진적이다. 각 반복은 이전 반복단계에서 만들어진 기능 위에 덧씌워진다. 이처럼 소프트웨어 어플리케이션은 주기적이고 지속적인 피드백을 통해 진화한다.   RUP의 핵심 이론(8) (i)             주요 위험 요소들을 조기에, 지속적으로 공략하라. 그렇지 않으면 그것들이 당신을 공격할 것이다. (ii)            고객에게 가치를 전달해줘야 한다. (iii)           실행 가능한 소프트웨어에 대한 지속적 관심 (iv)           프로젝트에서 변경사항에 대한 신속한 수용 (v)            초기 실행 가능한 아키텍처의 기초작업 (vi)           시스템은 컴포넌트로 구축하라 (vii)          하나의 팀으로 함께 일한다 (viii)         뒤 늦게 고민하기보다는 품질 개선을 위해 상시 노력하라   RUP의 Best Practices(6) (i)             반복적 개발 (ii)            요구사항 관리 (iii)           컴포넌트 아키텍처 사용 (iv)           시각적 모델링 (v)            품질에 대한 지속적인 모니터링 (vi)           변경사항 확인   애자일 RUP의 변형판 –오픈 유니파이드 프로세스(OpenUP)  : 다른 프로세스에 비해 경량화된 프로세스이며, RUP처럼 반복적이고, 유스케이스(사용자 가치에 우선을 둔) 기반, 아키텍처 중심이며 RUP와 동일한 단계를 따른다.   (5)   린소프트웨어 작업공정과 재고 감축 =>정밀한 요구사항, 문서화된 설계간소화 시간 주기 단축 => 세분화된 업무단위, 스토리, 유스케이스, 더 작게 더 잦은 릴리즈 교차 훈련과 셀 기반제조 => 짝 프로그래밍과 코드 자산 공유를 통한 교차훈련 끊임없는 프로세스 개선 => 지속적인 반성과 적응   (6)   동적 시스템 개발방법론(Dynamic Systems Development Method) 고품질의 해결책을 빠르게 제시하는 것에 집중하는 프레임워크 애자일 선언문의 유럽버전 DSDM은 전통적인 가정을 거꾸로 뒤집는다: 과거 방법론이 요구사항(기능)을 확정한 후에 자원과 날짜(비용과 일정)을 측정하는 경향이 있다고 설명한다. 반면, DSDM은 기한 안에 완성하기 위해서는 자원은 고정되고 요구사항은 가변 변수가 되어야 한다. 이것은 모든 애자일의 핵심원리이고 가장 놓은 우선순위의 요구사항을 선별하고 최고 가치를 지닌 상품을 먼저 고객에게 인도하게끔 하는 원동력이다.   DSDM의 핵심원리(9) (i)             활발한 사용자 참여가 필수적이다 (ii)            팀은 반드시 모든 권한을 위임 받아야 한다 (iii)           제품은 자주 출하해야 한다 (iv)           사업 목적에 부합하는 제품을 만들어야 한다 (v)            반복 점진적인 개발은 명확한 비즈니스 솔루션을 개발하기 위해 필수적이다 (vi)           개발 중에 일어난 변경은 모두 되돌릴 수 있다 (vii)          요구사항은 고수준의 언어로 기술한다 (viii)         테스팅은 전체 개발 주기에 걸쳐 끊임없이 진행해야 한다 (ix)           모든 이해관계자의 협력과 협조는 필수적이다   DSDM의 핵심활동 (i)             타임박스: 시작부터 고정된 완료날짜(릴리즈 날짜, 혹은 큰 타임박스)까지 팀 별로 작은 타임박스(반복)을 구성하고 이것도 고정된 날짜를 갖는다. (ii)            모델링: DSDM의 구성요소, 아키텍처의 기반을 이룬다. 그러나 DSDM에서 모델은 가볍고 사용자 지향으로 설계된다 (iii)           프로토타이핑: 신속한 애플리케이션 개발에 중점을 두고 대규모 프로토타이핑도 지원한다 (iv)           테스팅: 전체 개발주기에 걸쳐서 테스트하는 것을 매우 중요시 여긴다. 이런 테스팅의 대부분은 사용자 기반 테스트이며, 사용자가 프로토타입을 받을 때 일어난다고 가정한다. (v)            형상 관리: 점진적인 개발 중 일어난 모든 변경은 취소할 수 있고 빌드 정보, 테스트 스크립트, 예상된 결과 등 모든 릴리즈/프로토 타입은 재생산할 수 있다.   (7)   기능 주도 개발(Feature-Driven Development) XP와 스크럼과는 다르고 RUP와는 유사하게, FDD는 넓은 범위와 대규모 시스템에서 개발되고 수정됐다.   FDD의 Best Practice(8) (i)             도메인 객체지향 (ii)            기능에 따른 개발 (iii)           클래스(코드 소유권) (iv)           기능팀 (v)            정밀검사 (vi)           정기 빌드 일정 (vii)          형상 관리 (viii)         결과의 보고와 가시성   l  애자일의 핵심요소 (i)             성공의 새로운 척도: 계획에 따른 성실한 수행 -> 변경사항에 대응하는 능력, 동작하는 코드 (ii)            관리문화의 차이: 명령과 관리(관리자) -> 리더십/협업(팀) (iii)           요구사항, 아키텍처, 설계에 대한 접근법의 차이: 대규모로서 앞 단에서 조기수행 -> 지속적으로 드러나며, 즉시 수행 (iv)           수정된 코드와 구현활동: 모든 기능을 각 팀에서 동시에 코딩/사후테스트 -> 코딩과 단위테스트와 배포를 순차적으로 수행 (v)            테스트와 품질보증 활동에 대한 변화: 대규모, 계획적/사후테스트 -> 지속적/동시/조기 테스트 (vi)           계획과 스케줄 작성의 새로운 방법: 퍼트(pert)-계획의 평가검토기법/상세한/확정된 범위, 시간과 자원예측 -> 두 단계 계획-릴리즈를 위한 개괄단계와 반복을 위한 상세단계/일정 확정, 범위 예측   l  가장 큰 변화: 개발 범위 vs 일정 => 일정의 승리 기존에는 개발 범위가 개발 주기를 결정했으나, 반복 주기(릴리즈 수준에서 논하는 릴리즈 주기)가 범위를 결정한다. ð  폭포수/전통적 가정: 범위는 시간을 결정하고, 범위와 시간이라는 두 변수는 모든 계획 주기와 큰 변경사항에 따라 다양하게 변화한다. 계획기반: 요구사항(고정) -> 자원, 일정 ð  애자일: 시간을 고정 -> 그에 따라 범위를 결정하도록 하므로 무엇을 만들 것인지 같은 하나의 변수만 남겨놓는다. 범위는 언제나 우선순위에 따라 결정되기 때문에, 팀 구성원은 시간이 허락하는 한 반드시 최상의 솔루션을 제공할 것이다. 가치기반: 자원, 일정(고정) -> 요구사항   *애자일의 심장: 짧은 타임박스(해당 업무를 시작해서 끝날 때까지의 일정을 정확하게 확정한 것) 내에서 동작하는 코드 만들기 정의/빌드/테스트의 각 세 가지 활동은 서로 어느 하나라도 완료되지 않으면 전체활동이 완료되지 않음을 의미 -타임박스 내에서 일하기/ 작은 덩어리로 개발하기   * 애자일 방법론이 직면하는 장벽 (i) 소규모 팀: 수백 개의 작은 팀으로 구성해 기존 조직체계에 어떻게 새로운 모델을 적용시킬 것인가? (ii) 고객의 밀접한 참여: 수천 명의 고객을 대상으로 하는 경우, 각 고객이 원하는 것이 다르거나 특정 고객층이 목소리를 높이는 경우도 있으며, 제품 관리자가 고객의 대리인 역할을 수행한다면 변화에 따른 빠른 반복주기와 신속한 반응으로 만들어낸 세부 항목을 이끌어 낼 수 있는 훌륭한 전략적 제품관리 방법을 찾아내기란 매우 어렵다 (iii) 한 공간에서 일하기: 개발자, 제품 책임자, 테스터는 시간과 언어의 장벽이 없는 같은 장소에서 함께 일한다. 그러나 서로 다른 국가, 시간대, 언어를 사용하는 경우, 이런 상황을 해결하기 위해서 방법론과 조직 체계에 무언가 변화를 줘야 할 것이다 (iv) 서서히 드러나는 아키텍처: 시스템 수준을 다루는 아키텍트의 역할이 애자일에서 다뤄지지 않기 때문에 견고한 아키텍처 없이는 성공적인 시스템을 만들 수 없다고 생각하는 사람들은 애자일 적용에 부정적이다 (v)요구사항 분석과 문서화된 명세의 부족: 엔터프라이즈급 애플리케이션을 만들면서 한 번에 하나의 스토리만을 작업하는 것이 가능한가?  (vi)업무 문화와 물리적 업무환경: 효율적이고 잘 조직화된 엔터프라이즈에서는 팀이 일을 하고 있다고 생각 할 수 없을 것이다-열린 공간에서 일을 하고, 벽에 사용자 스토리를 붙이거나, 화이트보드가 여기저기 붙어 있거나, 팀원들이 코딩보다 이야기를 하는 데 더 중점을 두는 것처럼 보이기 때문   2부. 애자일을 확장 적용하는 7가지 팀 단위 애자일 활동   (1)   정의/빌드/테스트 컴포넌트팀 -> 프렉탈(부분이 전체를 닮는 자기유사성을 특징으로 하년 형상) 소프트웨어 유닛, 애자일의 기본 조직 단위 짧은 타임박스 안에서 동작 가능한 코드를 설계하기 위해 소프트웨어 개발에 필요한 세가지 기본 능력을 보유할 수 있도록 팀을 조직해야 한다. 첫째, 고객 대리인 역할을 하며 솔루션을 정의하는 제품 책임자. 둘째, 장애를 최소화하고 다른 프로젝트와 중복되지 않는 최소의 일정을 확보해 코드를 개발할 수 있는 팀원. 셋째, 통합테스트, 테스트 자동화와 품질보증을 할 수 있는 기능   정의/빌드/테스트의 세 가지 과정은 동시에 일어나며, 협력적이고, 쪼갤 수 없다.   (i)             기능 사일로(: 기능 중심으로 독립적으로 움직이는 조직)의 제거: 제품관리, 개발, 테스트와 QA => 관리자의 역할: 사일로를 넘나드는 팀을 조직하는 것 (ii)            애자일 컴포넌트팀의 역할과 책임: 최대 8~10명의 팀 구성: 개발자, 테스터, 제품 책임자(:애자일에서 역할 중요 – 팀과 유기적으로 스토리 작성을 돕기 위해서 자세한 세부사항 필요) + 애자일/스크럼 마스터 + 아키텍트(팀 활동을 통해 나타난다) + QA 담당자(품질에 대한 기본 채임이 개발자와 테스터에게 분담, 간과됐을지도 모를 전반적 품질 재확인) – 팀은 애자일 과정을 잘 알고 있는 애자일/스크럼 마스터나 테크니컬 리더가 이끈다. 팀원은 일반적으로 외부의 아키텍트와 QA 담당자들과 의사소통하며 팀과 컴포넌트 범위를 넘는 프로세스를 테스트한다.   (2)   두 단계 계획과 추적 -> 계획 일정주기를 짧은 시간으로 나눔 첫 번째 단계: 백로그 기반의 주제와 상위 수준의 기능들을 정의하고 이에 따른 릴리스 시리즈를 정의하는 애플리케이션 또는 제품 로드맵을 작성한다 두 번째 단계: 세밀한 계획 – 세분화하여 평가 절차를 개선하고 반복에 대해 팀이 책무를 쉽게 달성할 수 있도록 한다   애자일 계획: 대단위 릴리스 계획 + 소단위 반복 계획   (3)   반복 숙달하기 작은 타임박스 안에서 테스트된 동작 코드 전체를 개발하는 팀의 능력 -> 각 반복에서 통합된 코드는 동작이 가능하기 때문에 각 반복 단계마다 잠재적으로 배포 가능한 기능들이 추가된다   반복의 주기: XP 의 경우(1주 ~ 4주), 스크럼의 경우(30일 스프린트), RUP의 경우(2주 ~6주) ð  1주일은 짧고, 30일은 길다 -> 2주 길이의 반복 표준화   반복 프로세스 모델: 1단계- 하루보다 짧은 기간을 가진 계획 단계: 반복 백로그 검토, 우선순위 결정, 예측 2단계- 개발 단계: 백로그 항목들을 코드로 구현하고 테스트 수행 3단계- 반복 중 추가된 내용에 대한 출하와 반복에 대한 평가 수행   일일스크럼미팅: 개발팀이 반복에서 수행해온 진행상태에 초점을 맞추는 것을 목적   (4)   짧고 빈번한 주기의 릴리스(작게 자주 릴리스 하기) 애플리케이션이 고객이나 의도된 시장 목적에 부합하는지에 대해 연속적인 피드백이 필요하다. 많은 IT업체에서는 각 반복 끝에서 소프트웨어 출하를 통해 연속적 피드백을 얻을 수 있다   일정주도형 릴리스: 고정된 일정에 맞춰 진행, 일정을 바탕으로 프로젝트의 범위 추정 기능 셋 추정: 과거 생산율로부터 개발팀이 주어진 시간에 할 수 있는 일의 양을 예측   주간 현장 리뷰 미팅: 컴포넌트팀이 전체적인 릴리스 게획을 어떻게 수행하는지 평가   (5)   동시 테스트 -> 애자일에서 모든 코드는 테스트된 코드 단위 테스트, 인수 테스트, 성능과 신뢰성 테스트는 각 반복에서 일어난다   반복이 진행되면서 발생하는 스토리에 대해 더 다양한 유형의 테스트 케이스가 개발과 동시에 작성된다. 테스트 케이스란 단위 테스트, 인수 테스트뿐만 아니라 시스템 테스트, 성능 테스트, 신뢰성 테스트를 모두 들 수 있다. 이 모두가 개발 초기에 관여된다.   단위테스트(개발자테스트): 개발자 스스로 그들이 작성한 모듈을 테스트할 코드를 작성하는 것 인수테스트: 새롭게 쓰여진 코드가 요구사항에 부합하는지 검증하는 기능테스트 컴포넌트테스트: 각 반복과 릴리스가 진행되는 동안 애자일팀은 다양한 도구를 활용해 컴포넌트 수준에서 시스템 검사 시스템과 성능 테스트: 시스템 전체의 기능, 성능, 신뢰도 검사   (6)   지속적인 통합 매일 개발자들이 만들어낸 변경사항을 정리하고, 이에 적합한 빌드 환경을 만들고, 통합/빌드/빈번한 ‘스모크 테스트(: 사전 테스팅, 뒤에 있을 본격적인 테스트 전에 쉽게 발견되면서 크게 영향을 미칠 수 있는 오류를 잡아내기 위한 테스트)’를 위해 필요한 툴들을 자동화하는 것과 같은 일들은 상당히 어려울 수 있기 때문에 지속적인 통합 역시 확장 적용하는 데 있어 많은 어려움을 야기한다   지속적 통합에서 모든 코드는 최소한 매일 시스템에 체크인된다. 빌드는 자동화되어 있고 자동 회귀테스트는 매일 이루어진다. 결함 발견 프로세스는 계속 이뤄지며 재작업과 리팩토링도 끊임없이 이어진다. 이를 통해 고품질의 코드를 더 빨리 만들어낼 수 있다. 소스코드통합 + 자동화된 빌드 관리 + 자동화된 빌드 검증 테스트 => 시스템은 언제나 동작한다!   (7)   정기적인 반성과 적응 주기적으로 팀은 좀 더 효율적인 팀이 될 수 있을지 숙고하여, 그에 따라 팀 활동을 조율하고 개선시켜 나간다   반복 회고: 반복의 목표를 시간 안에 달성하지 못한 주요 이유를 깨닫게 된다 정량적 분석- 반복의 측정지표들(팀에 할당된 스토리 카드관리, 오류개수, 테스트 케이스등)을 수집하고 보고하면서 진행, 정성적 분석- 무엇이 제대로 되었는지, 무엇이 제대로 되지 않았는지를 판단, 개선할 점이 무엇인지 브레인 스토밍- 모든 문제가 즉시 처리되지 않지만, 반복은 짧아서 머지않아 결국 모든 문제점 해결   릴리스회고: 많은 주요 이해관계자가 참여, 정량적 분석, 정성적 분석   3부. 엔터프라이즈 환경에 맞는 애자일 방법론   1.     계획된 아키텍처 각 팀들이 만든 컴포넌트들을 하위시스템으로 통합하고 이를 다시 대규모 시스템으로 통합한다면, (1) 컴포넌트 기반으로 작성돼야 하고, 각 컴포넌트는 가능한 한 독립적으로 개발할 수 있어야 하며, 체계적인 인터페이스 정의와 분명한 목적을 가져야 한다. (2) 아키텍처는 팀의 핵심 능력이 되고, 팀의 물리적 위치와 부합돼야 한다.   아키텍처: 이해관계자들의 요구사항을 포함해 사용자의 요구사항에도 부합하도록 논리적인 기술들을 바탕으로 시스템을 설명해야 한다 => 눈에 보이지는 않지만 매우 중요한 시스템의 구조와 행동 요소들이 정의돼야 한다.   XP: 소수의 스토리들과 한두 번의 반복을 통해 아키텍처 베이직라인을 구현, 시간이 지남에 따라 아키텍처가 시스템 요구사항을 지원하지 못한다면 시스템은 상대적으로 빠르게 재작업 또는 리팩토링 돼야한다(XP 프로젝트의 아키택처도 여타 소프트웨어 프로젝트에서와 같이 중요하다)   스크럼: 소프트웨어 아키텍처에 대해 특별한 언급 없음(자체적으로 조직된 팀에서 최고의 아키텍처, 요구사항, 설계가 나온다)   도메인 객체 모델링(Domain object modeling): 기능주도개발방법론(FDD)중 하나, 애자일 활동 중에서 특별하게 아키텍처 개념에 대해 설명하고 있는 활동, 동시에 많은 팀이 함께 작업할 수 있도록 프로젝트의 기반이 되는 아키텍처를 도메인 모델 구축을 통해 간단하고 효과적이면서 시각적으로 표현하기 시작한다     RUP: 아키텍처는 명명될 수 있고, 관리될 수 있다, 아케텍처는 유스케이스를 반영해서 설계되고, 리스크를 감소시키며 점진적, 반복적으로 발전한다.     2.     린 요구공학: 비전, 로드맵, 적시 정교화 => 간결하고 확장 가능한 요구사항 패턴은 대규모 팀과 대규모 시스템을 만드는 팀에 애자일의 장점을 적극 활용할 수 있게 된다 비전: 팀에게 공동 목표를 갖게 하고 시스템 전체에서 강조해야 할 주요 비기능적 요구사항 뒷받침 a)     비전 문서 접근방식: RUP기반에서 성공적, 애자일에 적용 용이, 알고 있는 것을 얼마나 이해하고 있는지 테스트하기 위해 비전 문서를 작성한다(아무리 대규모 프로젝트라도 문서는 20~30페이지 유지) b)    진보적인 방식의 데이터 시트 접근 방식: 매우 간결하게 작성, 의사소통에 중요한 요소(매우 간결하게 작성, 보통 2페이지) c)     백로그 접근 방식: 제품 책임자가 주의를 기울여 앞으로 발생할 작업들을 예측하고 우선순위를 고려하여 팀원들에게 프로젝트가 어떤 방향으로 가는지 알려줌   로드맵: 광범위하게 우선순위를 매긴 백로그에 따라 비전이 어떻게 구현돼야 하는지 나타냄, 릴리스 기준으로 비전을 설명하고 시간에 따라 주제와 기능을 기획하는 방식으로 제품의 로드맵 만들기. 팀은 구현 가능한 기간 안에 우선순위가 높은 기능을 구현하는데 초점을 두고 주제와 날짜를 결정해야 한다   적시 요구사항 정교화: 마지막 책임 순간(LRM)이 되어서야 상세한 요구사항 표현 -> 낭비제거   XP: 스토리, 사용자 스토리. 스토리는 고객이 작성하고, 고객이 개발자와 같은 공간에서. 지속적으로 의사소통을 같이하고 개발하는 동안 스토리에 대해 토론할 수 있어야 한다.   스크럼: 제품 책임자_ 스크럼 산출물의 핵심인 제품 백로그를 개발하고 유지 제품 백로그의 원칙: 제품 책임자에 의해 중요도, 우선순위 매갬=> 중요한 것에 대한 모호성 없음, 우선순위와 투입공수를 견주어 고객을 대신해 팀의 투자 정도를 최적화 할 수 있다 => 대규모 시스템 개발에 매우 좋은 접근방식   RUP: 유스케이스로 정교화 – 사용자 관점에서 시스템의 행동을 표현하는 일관된 표현방법, 유스케이스 안에 기술된 이벤트의 흐름을 이해하면 모든 사용자 또는 이해관계자와 관련된 논의를 할 수 있다.   3.     대규모 시스템과 애자일 릴리스 기차: 대규모 시스템에서 서로 분산되어 있는 컴포넌트팀 개발자들 사이에 의존관계를 관리하고 계획하는 것이 필수적 -> 계획적이고 중장기 릴리스 주기(3~4개월)이 필요 -> 컴포넌트를 기반으로 하는 ‘애자일 릴리스 기차’를 사용하여 애질리티, 생산성, 품질을 달성하려고 한다   대규모 회고의 결과는 모든 팀이 관심을 둘 것이고, 널리 확산될 것이다. 결과는 다음 릴리스 계획에 반영되고 이런 방식으로 대규모 시스템 릴리스에 대한 지속적인 프로세스 개선 작업이 이뤄질 수 있다.   애자일이 제품을 좀 더 빠르게 만든다면, 시장출시를 조율하는 것도 엔터프라이즈 기업의 도전 과제이다 효과적인 릴리스 계획을 수립하는 것과 대규모 시스템의 릴리스 일정을 맞추는 것은 엔터프라이즈급 애자일 프로세스을 만드는 데 있어 가장 중요한 일이다   애자일 릴리스 기차: 반복-반복-반복- 굳히기(릴리스) 기차는 동기화되어야 한다: 같은 반복일정으로 동기화 되어야 한다. 관리층은 고정된 길이의 반복에서 시작과 끝 날짜만을 지정할 수 있다. 지속적 통합이 시스템 수준에 적용되면 시스템도 컴포넌트와 마찬가지로 고객이 평가할 수 있도록 반복과 내부 릴리스를 갖게 된다.   기차가 궤도를 이탈하지 않고 일정을 준수하도록 유지하기: 스크럼 관리팀이 존재해야 한다. 기차의 일정과 모든 통합 마일스톤(전체 통합을 조절할 수 있는 중간 매체)을 결정한다, 릴리스에 필요한 공통의 요구사항과 비전을 가지고 팀과 함께 대화한다, 팀 활동을 정리할 수 있도록 릴리스 계획을 작성한다.   릴리스 관리팀은 프로젝트의 진행 상태 검토 및 진행상 장애물을 제거하고 필요에 따라 범위를 조절하기 위해 최소한 일주일 단위로 모인다. 계획 또는 범위의 변경사항에 대해 전체 팀원들과 공유할 책임이 있다.   4.     분산 개발의 관리 분산된 장소에서 발생하는 의사소통의 통합을 지원하는 환경은 팀에게 현재 프로젝트에 대한 충분한 가시적 자료를 제공하여 팀이 업무의 우선순위와 실시간 상황, 의존성을 파악할 수 있게 한다   애자일 개발의 성공 열쇠: 조직의 변화와 의사소통 장려, 분산된 팀에게 소프트웨어 개발 프로세스의 모든 부분에서 의사소통이 강조될 때 성공할 수 있다.   5.     조직변화 조직 안에 존재하는 걸림돌과 병목현상 그리고 생산성을 저하시키는 장애요소 식별 문화적 조직적 장애물: 불충분한 테스트 자동화, 시스템 수준 테스트에 대한 부족한 자원, 제품 관리에 필요한 인터페이스를 느리게 하고 방해하는 요소, 반복과 프로젝트 진행에서 고객에 대한 빠른 피드백을 방해하는 요소   스크럼과 애자일이 가진 ‘즉각 경험적으로 반응’하는 특성으로 인해 스크럼/애자일 프로세스 자체는 점진적으로 논리적인 방법으로 조직에 변화를 일으키는데 쓰일 수 있다. 이러한 프로젝트에서 경영층의 후원은 결정적인 역할을 하며, 베스트 프렉티스에 의한 리더십, 프로세스에 대한 협의와 헌신이야 말로 애자일이 엔터프라이즈 조직 전체에 가져다 주는 이익에 채워진 자물쇠를 푸는 중요한 요소이다   6.     고객과 조직에 미치는 영향 좀 더 가용성이 있는 코드와 빠른 대응이 사용자들에게 많은 영향을 줄 것이다. 또한 릴리스 계획 대비 실제 진행 상황을 파악할 수 있는 시스템과 좀더 밀접하게 사용자와 의사소통 할 수 있는 고객 접점도 필요할 것이다   애자일: 관련 마케팅 팀원에게 좀 더 지속적인 집중과 잠재적으로 높은 작업량을 주며 개발팀과 함께 의사소통을 하도록 한다.   새로운 자원과 새로운 조직구조 필요: 영업과 마케팅은 제품관리자- 제품 책임자 간의 인터페이스를 확장하여 마케팅/제품 관리 담당자를 추가할 수 있어야 한다. 가끔 새로운 팀원이 고용되거나 다른 팀원이 추가될 수 있다. 개발팀원들 역시 제품 특성, 하위시스템 컴포넌트에 대한 제품 책임자 또는 요구사항 분석가로서 역할을 수행할 수 있는 준비를 해야 한다. 또한 영업 또는 마케팅 팀원과 함께 지속적으로 의사소통 해야 한다   7.     비즈니스 성과 측정 경영진이 그들의 목표가 지속적으로 향상되고 있는지, 추가적인 진척이 필요한 곳은 어디인지를 알 수 있는 무엇인가를 만들어낼 필요가 있다   큰 수준의 문제를 다루기 위한 설득력 있는 측정 지표 셋: 균형성과기록표(BSC, balanced scorecard) – 효율성(R&D조직이 현재 조달성, 생산성, 수익성, 비용 목표에 부합하는지에 대해 평가), 가치 조달(측정기간(12개월)동안 고객에게 전달된 소프트웨어의 가치측정), 품질(고객의 환경에 맞게 결정된 제품에 대한 품질 측정), 애자일(차기 성능 목표를 위한 개선되고 이뤄야 할 조직의 능력 평가)   대기업을 위한 유연하고 자동화되고 의미 있는 BSC의 구현: 1단계- BSC 항목 수치화: 0-100사이의 점수를 갖도록 데이터 수집 2단계- 알파벳 점수로 변환: A-F; 표의 각 항목이 한 관점의 평가를 의미하고, 그 관점은 더 수치화된 상세 항목으로 자세히 알아볼 수 있기 때문에 팀은 무엇을 향상시켜야 할지 알 수 있다 3단계: 제품라인, 비즈니스 부서, 대기업에 대한 결산    Sustainable Software Development - an agile perspective  by Kevin Tate chapter 1. sustainable software development   <ul> <li>Outline: the value of sustainable development</li> </ul>   <ul> <li>the more successful an application or tools is, the greater the demands placed on the development team to keep up the pace of innovation and feature development.</li> </ul>   <ul> <li>unsustainable development:</li> </ul> <ol style="MARGIN-LEFT: 2em;"> <li>over or under design</li> <li>code first then fix defects later(code-then-fix)</li> <li>too many dependencies between code modules</li> <li>the lack of safeguards such as automated tests</li> <li>temporary patches or workarounds that are never addressed.</li> </ol>   <ul> <li>unsustainable development: reactive to changes in their ecosystem -> death spiral</li> <li>sustainable development: able to be proactive about changes in their ecosystem. -> virtuous cycle</li> </ul>   sustainable development  Sustainable development is a mindset(principle) and an accompanying set of practices.  Optimal doesn't mean fastest - that would be pure coding, such as for a prototype.   Sustainable development is about efficiency and balancing the needs of the short and long term. <ul> <li> the needs of the short term are met by regularly producing software that has the highest possible value to customers.(low cost)   </li> </ul> Chemical Manufacturing and Sustainable Development productivity at chemical manufacturing plants has parallels in software development.   Working harder(more hours) <ul> <li> short-term increase in overall capability </li> <li> long-term effect is actually declining capability(vicious cycle or death spiral) <ul> <li> unanticipated side effects -> As more hours are worked, more mistakes are made. </li> </ul> </li> <li>  Parking Lot Managers: Managers who judge the morale or productivity of their company by how many hours their employees work on evenings and weekends on a regular basis. -> No coreelation with the number of hours worked. because.. working harder may be valid in ther short-term when concerted effort is required. </li> </ul>   Working Smarter <ul> <li> taking the time to examine the entire plant's systems and processes and continually attempting to identify problems before they occur. </li> <li> consistently produced better results over the long term especially doing preventive maintenance. </li> </ul> Continual Improvement: The Accelerator Button  The main lesson is that in sustainable software development, you need to strive for continual improvement while resisting the temptation to focus on features and simply working long hours to meet demands.   <ol> <li> Many developers have a mindset that non-feathre work is not part of their job. -> focused on defect detection, not defect prevention. -> if developers don't personally pay attention to the infrastructural details of their products, it is all too easy for problems to creep in that eventually impact key performance indicators that also impact developers productivity. -> extremely expensive, wasteful </li> <li>Managers must recognize that they have a key role in leading the attitude of the organization.</li> <li> Many software teams are unable to pay attention to the "health" of the underlying software or the development infrastructure. -> this is a key part of the software development death spiral </li> <li>use shortcuts that compromise the underlying architecture  -> broken windows (ch.4)</li> </ol>   A Sustainable Development Experience the vital to the success of the company's products : produce the amount of work they did and keep quality so high.   <ol style="MARGIN-LEFT: 2em;"> <li>our software worked every day.</li> <li>we relied heavily on automated testing to catch problems while we were working on new features.</li> <li>we had high standards onf testing and code quality, and we held each other to those standards.</li> <li>we didn't overdesign our work and built only what our customeres needed.</li> <li>we were uncompromising with defects, and made sure that all the known defects that were important to our customers were fixed in a feature before we moved on th the next one.-> never had a defect backlog.</li> <li>we replanned our work as often as we could.</li> <li>we were always looking for ways to improve how we worked and our software.</li> </ol>     http://soonsam.myid.net/ ditte83 1011