일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- hbase
- leadership
- RFID
- Spain
- Java
- erlang
- hadoop
- France
- Book
- Book review
- Programming
- ubuntu
- UK
- agile
- program
- Linux
- programming_book
- Kuala Lumpur
- Python
- QT
- Italy
- Malaysia
- django
- management
- comic agile
- MySQL
- history
- web
- psychology
- Software Engineering
- Today
- Total
함께 자라기 애자일로 가는 길 본문
개선 효과가 높은 것은... 관리, 시스템, 사람, 도구 순서... 실제로 프로젝트가 아주 성공하거나 실패하거나 하는 이유는 첫 번째가 관리라는 변수 때문
추상화
• 전산학의 모든 문제는 또 다른 차원의 간접성(indirection)으로 해결할 수 있다. - 버틀러 램슨
All problems in computer science can be solved by another level of indirection. - Butler Lampson
• 전산학은 추상화의 과학이다. - 알프레드 아호와 제프리 울면
Computer Science is a science of abstraction - A. Aho and J. Ullman
• .... 소프트웨어 공학의 전체 역사는 추상화 수준을 높이는 것으로 특징지을 수 있다. - 그래디 부치
...the entire history of software engineering can be characterized as one of rising levels of abstraction. - Grady Booch
• 복잡한 현상에 대한 이해를 발전시켜 나갈 때, 인간 지성에서 가장 강력한 도구는 추상화다. 실세계의 특정한 대상체, 상황, 과정 간의 유사성을 인식하는 데에서, 그리고 이러한 유사성에 집중하고, 차이점은 일시적으로 무시하는 결정에서 추상화가 생겨난다. - 토니 호어
In the development of the understanding of complex phenomena, the most powerful tool available to the human intellect is abstraction. Abstraction arises from the recognition of similarities between certain objects, situations, or processes in the real world and the decision to concentrate on these similarities and to ignore, for the time being, their differences. C.A.R. Hoare
추상화를 높일 수 있는 방법... '다른 시각을 가진 두 사람이 협력하기'
켄트 벡과 함께 익스트림 프로그래밍의 짝 프로그래밍 개념을 형상화한 워드 커닝햄
• 익스트림 프로그래머는 작업하면서 프로그래밍 각 단계에 대해 함께 이야기한다.
Extreme Programmers discuss each step of programming as they work.
• 주의해서 생각하지 않으면 프로그래밍은 특정 프로그래밍 언어로 명령문을 타이핑해 넣는 것에 지나지 않는다고 생각할 수 있다.
If you don't think carefully, you might think that programming is just typing statements in a programming language.
추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고, 대화하세요.
신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다
신뢰를 쌓는 데에 널리 사용되는 한 가지 방법은 투명성과 공유, 인터랙션
복수 공유는 같은 시간을 투자했을 때 신뢰도 높아지고 성과도 더 좋았다
신뢰를 깎아먹는 공유 vs. 신뢰를 쌓아가는 공유
- 상대에 대해 이해하지 않으면 설득도 실패한다는 이야기
- 웹툰 송곳이 생각난다 “사람들은 옳은 사람 말 안 들어. 좋은 사람 말을 듣지.”
- 애자일 이야기 : 하향식 변화 도입에 대한 환상
품질 전문가 제럴드 와인버그
품질이란 누군가에게 가치가 되는 것이다.
Quality is value to some person.
고품질을 얻으려고 노력하는 사람들은 '인간'에 대한 이해가 필수적
결국 결정하는 것은 사람입니다. 그 사람 마음에 드냐 안 드냐 이겁니다. 안 들면 어떤 이유를 들어서든 반대하게 됩니다. 도대체 '누구'의 객관이냐 이거죠.
- 역시 위에 썼던 웹툰 송곳이 다시 생각나는 지점
의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다
좌뇌와 우뇌의 기능을 깨끗하게 분리할 수 없는 것처럼 감정과 이성을 분리할 수 없습니다.
남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 합니다. 그래야 현실적으로 설득이 가능합니다. 내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 합니다. 출발은 결국 내가 설득하려는 사람에게서 하는 것입니다. 자료에서 출발하는 것이 아닙니다.
누군가가 이렇게 내 에너지 레벨을 높여주고 확인해주고 지지해주고 다독여주는 사람이 있다면?
개발에서 경력과 실력은 상관성이 낮다는 결론
상호 참조 전략 (crossreferencing strategy) 고수는 프로그램을 연구하면서, 프로그램에서 이해한 것을 도메인 어휘로 번역합니다. 그러고는 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증합니다.
• 한 사람이 다기능을 갖추도록
• 협력이 쉽게 되도록
- 내게는 server의 scale up과 scale out이 연상되는 지점. 하나의 server가 아무리 고성능을 갖추도록 하더라도 비용도 비쌀뿐더러 한계가 닥칠 수 밖에 없다. scale out역시 비싸고 어렵지만, 그래도 확장성에 있어서는 scale up이 절대 따라갈 수 없다.
'삼투압적 의사소통' '배어드는' 소통방식
더 높은 품질을 얻기 위해서는 이 사다리를 오르락내리락 반복하는 것이 필요... 어느 한 단계를 한번에 완료하는 것은 더 낮은 품질로 가는 지름길
협력 개입, 팀원들은 정보를 공유해서 더 통합된 해결책을 제시
- Oxygen Project re:Work - Managers
에이미 에드먼드슨 교수, 《티밍》, 실수율이 낮은 조직은 실수를 적게 하는 게 아니라 실수를 공개하는 것이 공격을 받을 수 있는 그래서 실수를 감추는 조직
심리적 안전감 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음
단순히 우리팀의 현상황에 대해 열린 대화를 시작하는 것만으로 변화가 시작될 수 있다
하지만 이 모든 것 이전에 우선적으로 중요한 게 있습니다. 어떤 새로운 프로그램을 도입하기 전에 리더와 관리자가 매일매일 팀원들과 갖는 마이크로 인터랙션에서 다른 행동 양태를 보여줘야
워드 커닝햄 “작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다."
일이 진행될수록 점점 추정 정확도가 높아집니다.
- 그렇다면 추정 정확도가 계속 정체된다는 건 뭔가 잘못된 지점이 있는 걸까?
학습과 협력이 애자일이 불확실성을 다루는 핵심적인 구동원리
불확실한 상황일수록 리스크가 높은 것이고, 고로 안 좋은 일이 벌어질 확률이 높을 것
전체에 문제가 생길 확률은 기하급수적으로 낮아... 모든 사람이 실수해야지만 구멍이 뚫리는 경우
한 사람이라도 통찰을 얻으면 그걸 공유해서 전체가 개선
애자일의 핵심 구동원리가 학습과 협력, 즉 함께 (협력) 자라기 (학습)
고객에게 매일 가치를 전하라.
'매일'에는 빈도와 동시에 이른 시점부터 시작한다는 의미
소프트웨어 개발이건 뭐건 간에 홀로 결과물이 나오는 경우는 드뭅니다. 협력을 통해서 결과물이 나옵니다.
신뢰가 있을 경우 협력의 비용이 낮아지고 원활해진다
고객 참여는 계수가 0.77, 고객 참여를 잘하는 프로젝트는 성공도가 0.77 만큼 높아질 수 있다는 뜻
고객 참여 다음의 세 가지는 성공 기여도가 비슷. 리팩터링, 코딩 후 자동화 단위 테스트 붙이기, 코드 공유... 어쨌건 이 4가지가 잘 되어야 프로젝트 성공에 애자일이 도움
많은 조직들이 고객 참여와 코드 공유를 뒤로 미룹니다. "우리 상황에서는 할 수 없다. 어렵다" 라고 생각... 고객 참여는 고객을 설득해야 하고, 코드 공유는 개발자를 설득해야
"우리가 애자일을 도입한 지 얼마 안 되었다. 잘 못 한다. 그런데 어떻게든 프로젝트가 더 성공적이 되었으면 좋겠다" 라는 입장이라면 답은? 고객 참여뿐
애자일에 대해 어느 정도 이해는 하고, 실험도 좀 해봤다 싶은 조직에서 성공 기여도를 높이려면 짧은 반복 개발 주기, 고객 참여, 코드 공유
진정 중요한 것은 프로젝트의 성패를 좌우하는 사람과 최대한 가까운 사람을 참여시키려고 우리가 계속 노력 성장 사고관
- 스탠퍼드 대학교의 캐롤 드웨(Carol Dweck) 교수는 사람들의 사고관을 성장 사고관 고정 사고관로 나누어 설명
- 성장 사고관은 내가 노력만 하면 뭐든지 더 잘할 수 있다고 믿는 것
- 고정 사고관은 내 능력은 정해져 있다고 믿는 것
- 애자일 이야기 : 나는 왜 학습을 이야기하는가
애자일 코치는 어느 누가, 어느 조직이 정해줄 수 있는 것이 아닙니다. 조직적, 정치적 위치와는 관계가 없습니다. 오로지 자신의 선택. 내가 애자일 코치가 되어야지 결심하는 것이 가장 중요
매뉴얼이 제공된 경우 치료의 효과 크기가 그렇지 않은 경우에 비해 절반. 상담사가 매뉴얼을 정확히 따르면서 명시된 단계를 끝내려다가 내담자의 상태를 제대로 확인하지 못하고 단계를 마무리한 부작용이 생겼다고 해석
과학자이자 철학자였던 마이클 폴라니 (Michael Polanyi)는 "우리는 말할 수 있는 것보다 더 많이 알고 있다" 라고 암묵지의 중요성을 이야기. 사실 더 나아가서 모든 지식이 근본적으로는 암묵지라고 역설
맥락을 가로지르는 보편적 규칙들이 별로 없다고 생각이 든다면, 결과를 예측하기 어렵고 불확실성이 높다면, 해당 분야는 '복잡한 도메인'... 통상 사람 요소가 차지하는 비율이 많을수록 복잡한 도메인... 이런 복잡한 분야일수록 어떤 특정 기법의 효과보다도 치료자 효과가 더 큰 영향
문제 상황을 단순 영역, 난해(complicated) 영역, 복잡(complex) 영역, 카오스 영역으로 나누어 접근하는 쿠너빈(Cynetin) 프레임워크에 따르면 복잡 영역이 됩니다. 복잡 영역은 난해 영역과 다르게 사전 분석으로 예측할 수 없습니다.
새 프로젝트를 진행할 때에 우리가 어떤 방법론을 쓰느냐는 문제보다도 누가 참여하는가가 훨씬 더 압도적으로 중요한 문제
우리가 배워야 할 것은 칸반 이면의 칸반이 나올 수 있었던 구조와 문화
애자일은 불확실한 상황에 대한 접근법인데, 애자일을 도입할 때 확실성 위에서 진행하려고 한다면 문제
방법론 도입은 태생적으로 불확실성이 높음... 그럴 때 현명한 전략은 정해진 수순을 따르는 것이 아니라 곁에 있는 사람들과 함께 주변을 탐색하고 조금 나아가고 확인하고를 반복하면서 우리의 현 맥락에맞는 좋은 전략들을 스스로 만들어 나가는 것
- 함께 보면 좋은 책
- 실용주의 프로그래머
- 익스트림 프로그래밍 2판
- 테스트 주도 개발
- 통찰, 평범에서 비범으로
- 추천 도서 목록 Agile Coach Squared - Reading