애자일 마스터 Agile Samurai. 조너선 라스무슨. p237
(less document-oriented) code-oriented communication!
애자일 원칙_작동하는 소프트웨어를 몇 주 혹은 몇 달마다 고객에게 전달하라. 주기는 짧을수록 좋다.
#1 애자일의 핵심
정말 중요한 것은 제대로 작동하는 소프트웨어를 정기적으로 고객에게 전달하는 것이다
*매주 가치 전달하기
-큰 문제들을 작은 문제들로 세분화하라(아무도 모든 일을 일주일 안에 끝낼 수는 없다)
-가장 중요한 것에 먼저 집중하고, 다른 것들은 다 잊어버려라(전통적인 소프트웨어 프로젝트를 통해 전달하는 것들은 대부분 고객에게 아무런 가치가 없다)
-소프트웨어가 제대로 작동하는지 확인하고 또 확인하라
-피드백을 구하라(정기적으로 고객에세 묻지 않고서 목표를 행해 잘 나아가는지 어떻게 알 수 있겠는가?)
-필요하다면 계획을 바꿔라
-책임감을 가져라(기대치를 세우고 품질,일정을 책임진다)
애자일 원칙_우리가 가장 우선시하는 것은 신속하고 지속적으로 가치 있는 소프트웨어를 고객에세 전달함으로써 고객 만족을 이루는 일이다
해야 할 일이 너무 많다면, 여러분이 할 수 있는 건 하나뿐이다. 더 적게 맡아라.
애자일 원칙_작동하는 소프트웨어는 프로젝트의 진척을 알 수 있는 주된 척도다
*세 가지 진실
1)프로젝트는 초기에 요구사항을 모두 수집하기는 불가능하다(다 알지 못하는 상태로 여행을 시작하는 걸 두려워하지 않는다)
2)수집한 요구사항들이 무엇이든 반드시 변하기 마련이다(변화를 두려워하거나 피하려 하지 않는다)
3)시간이나 비용이 허락하는 것보다 해야 할 일들이 항상 더 많다(주어진 시간과 자원보다 해야 할 일이 더 많더라도 스트레스에 시달리지 않는다)
#2 애자일 팀 만나기
애자일 프로젝트는? 각 팀원 간의 역할이 불분명하다. 작은 스타트업에서 일하는 것과 비슷, 직위나 주어진 역할에 상관없이 누구든 프로젝트를 성공시키기 위해 필요한 일에 참여할 수 있다!
우리 모두는 한 배를 탄 하나의 팀이다. 우리가 한 일에 대해서는 한 팀으로 책임을 져야 한다
참여하는 고객!
아직도 많은 소프트웨어가 고객과 전혀 소통하지 않는 팀에 의해 개발되고 있다. 참으로 슬픈 일이다. 이건 거의 범죄라고 할 수 있다.
고객이 전혀 참여하지 않는데 어떻게 그들이 원하는 혁신적인 소프트웨어를 만들기를 기대할 수 있단 말인가?
애자일 원칙_프로젝트가 진행되는 동안 ‘업무 전문가들business people’과 ‘개발을 하는 사람들’은 매일 함께 일해야 한다
***자기 조직화self-organizing
자기 조직화된 팀은 팀원 각자가 자존심이나 자신만이 옳다는 식의 태도를 버리고 자신의 특별한 기술, 열정, 재능을 사용해서 한 팀으로써 프로젝트를 성공적으로 전달하기 위해 최선의 방법을 모색한다. 팀을 단속하려는 규율이나 통제를 없애고 믿음과 권한을 부여하면서 일하도록 하라.
애자일 원칙_최고의 아키텍처, 요구사항 그리고 설계는 자기 조직화된 팀에서 나온다
애자일 원칙_의욕이 가득한 사람으로 팀을 구성하라. 그들에게 필요한 환경과 자원을 아낌없이 하고 난 후에는 이들이 맡은 바 일을 완성할 것이라고 믿어라.
*교차기능팀 cross-functional team
generalist! 팀을 구성할 때는 다방면에 걸쳐 많이 알고 관심을 갖는 사람을 구하도록 하자
교차기능팀의 매력은 속도에 있다. 팀원들은 프로젝트 첫날부터 누군가의 승인을 기다리거나 자원에 대해 협상하는 일 없이 가치를 전달하기 시작할 수 있다.
*애자일 개발자
테스트를 많이 작성하고, 이 테스트를 설계를 구성하는 수단으로 사용한다
개발하는 동안, 끊임없이 설계하고 소프트웨어 아키텍쳐를 향상시킨다.
코드베이스가 항상 출시production가 가능한 상태로 준비되어 있고 언제든지 배치deploy할 수 있도록 한다
***좋은 팀원?
-제너럴리스트를 찾아라
-애매모호한 상황을 개의치 않는 사람을 찾아라
-제멋대로 행동하는 사람이 아닌, 팀 플레이어를 찾아라
##애자일 프로젝트 Inception
#3 모두 한 버스에 타는 법
*시작도 하기 전에 대부분의 프로젝트가 실패하는 이유
1)적절한 질문을 하지 못해서? 어떤 새로운 프로젝트를 시작하 건 간에, 사람들이 생각하는 성공의 의미가 서로 다르게 해석되는 경우가 많다(동상이몽!)
2)물어보기 껄끄러운 질문을 할 용기를 내지 못해서
inception deck? ‘프로젝트와 관련이 있는 사람들을 모아, 모든 사람들이 프로젝트에 기대하는 바가 동일하도록 적절한 질문을 통해 생각을 공유한다면 프로젝트가 성공할 확률이 높을 것이다’라는 아이디어에서 시작되었다
#4 크게 보기
소프트웨어는 디자인, 건축, 예술,과학이 모두 합쳐진 독특한 활동 중 하나다
*질문하라: 우리는 왜 여기 모였나요?
-직접 가서 보고 배워라
-지휘관의 의도 파악하기
*엘리베이터 피치 만들기
간결한 표현의 어려움? 여러분꼐 조금 더 짧은 편지를 작성했어야 했지만, 시간이 없어 그럴 수가 없었습니다!
*제품 광고를 직접 디자인해보자
제품의 기능을 고객에게 일일이 설명하려는 바보 같은 짓은 절대 하지 말자. 고객은 그런데 관심이 없다. 고객이 정말 알고 싶어 하는 것은 과연 이 제품이 자신의 삶의 질을 더 낫게 할 수 있는지에 있다. 자신에게 어떤 혜택이 올 것인지 알고 싶어한다
제품의 첫 단계는 사라들이 이 제품을 사고 싶어 하는 이유가 무엇인지 팀원들과 고객이 함께 브레인스토밍하는 데서 시작한다!
*NOT 리스트를 작성하라
프로젝트 범위에 대한 적절한 기대치를 정하려고 할 때, ‘하지 않을 것’이 무엇인지 정확히 아는 게 무엇을 ‘할 것’인지 아는 것만큼 중요하다
*프로젝트와 관련된 다양한 사람들과 만나라
이 프로젝트에 관련된 사람들이 누구인지 파악하고 있다
*어떤 팀을 선택하느냐가 아키텍쳐를 결정한다? 망치를 쥔 사람에게는 모든 것이 못으로 보이기 마련이다!
*우선순위 정하기
전설의 4총사? 시간,비용,품질, 범위!
할 게 너무 많다면, 일을 줄여라. 계획했던 것처럼 현실이 따라주지 않는다면, 현실이 아니라 계획을 바꿔야 한다. 시간과 비용을 맞추는게 다가 아니다. 프로젝트 범위는 변할 수 있도 있다고 고객에게 알려줘라.
랜디 모트의 비밀 철학? 어떤 프로젝트도 6개월보다 길어서는 안 된다!(작은 단위로 생각하기)
#6 사용자 스토리 수집하기
모든 것을 전부 다 받아 적기에 인생은 너무나 짧다
*과도한 문서 작성의 문제점?
변화를 받아들이지 못한다
고객이 원하는 것이 아닌 적혀있는 스펙에 따라 개발한다
잘못된 추측과 가정이 난무한다
많은 시간을 낭비한다
애자일 원칙_개발 팀 내의 누구에게든 가장 정확하고 효과적으로 정보를 전달하는 방법은 그 사람과 직접 대면하면서 이야기하는 것이다
*좋은 사용자 스토리의 요소
1)고객이 쉽게 이해할 수 있도록 어려운 용어를 피하고 간단명료하게 써야 한다
비즈니스적으로 가치 있을 만한 글로 써라? 고객이 좋아할만한 것을 쓰자!
데이터베이스 풀링 추가하기? 페이지 로딩 시간을 10초에서 2초로 단축하기!
2)’케이크 한 조각’? 비록 케이크 한 조각이지만, 그 한 조각에 모든 레이어가 갖춰 있을 때 그 케이크는 상품으로써의 가치가 있다
3)독립적이다(independent)
4)협상 가능해야 한다(negotiable)
5)테스트 가능해야 한다(testable)
6)작고 추정가능해야 한다(small & estimatable)
“소프트웨어 추정의 주된 목적은 프로젝트의 결과를 예측하는 것이 아니다. 프로젝트의 목표가 통제가 가능할 만큼 충분히 현실적인지 알아보기 위한 것이다.”-스티브 맥코넬
#8 애자일로 계획 짜기
애자일 원칙_뒤늦게 요구사항이 바뀌더라도 즐겁게 받아들여라. 애자일 프로세스는 고객이 경쟁에서 우위에 서도록 변화를 활용한다.
릴리즈 정의하기? 출시할 만한 최소한의 기능 세트MMF(minimal Marketable Feature set) (린스타트업의 MVP)
애자일 원칙_단순함, 하지 않아도 되는 일은 최대한 안 하게 하는 기교, 이것이 핵심이다
변화란 항상 존재하는 것이다. 우리는 그저 이를 얼마나 창의적으로 드러내고, 다루어야 할지를 고민해야 할 뿐이다.
#10 애자일 커뮤니케이션 계획
“수지, 지난 이터레이션에 프린트 모듈 작업을 아주 훌륭하게 했더군요. 그 정도의 섬세함을 단위 테스트에 적용 해봐요. 아마 곧 세계 최고가 될 거예요.”
건설적인 피드백을 주는 방법? ‘그런데‘, ‘하지만‘과 같은 단어의 사용을 피하면, 분위기를 완전히 바꿔서 전달할 수 있다.
애자일 시각화? 고객이나 이해관계자들과 가능한 최대로 투명하게 정보를 나누고, 나쁜 소식일수록 빨리 공유하는 것, 이게 바로 애자일 방식이다!
이터레이션을 마치기 전에 해야 할 일은 우리가 ‘더 잘할 만한 일이 없나’ 스스로에게 물어보는 것이다
완성되지 않은 스토리? 스토리는 완벽히 완성됐느냐 아니냐 두 가지 상태만 있을 뿐이다!
#11 시각적인 작업환경 조성하기
스토리보드(Story Wall)-시작안함/개발 중/테스트 할 준비 됨/완료
릴리즈 상황판(Release Wall)-완성된 스토리/아직 남아있는 스토리
*공통된 도메인 언어를 만들어 팀원들과 공유하자
개발 언어와 비즈니스 언어가 맞지 않는다면? 잘못된 추측으로 소프트웨어를 개발한다
#12 단위 테스트: 제대로 작동하는지 확인하기
버그를 고치기 전에 실패하는 단위 테스트를 작성하자
#13 리팩토링: 기술적 부채 갚기
리팩토링이란 겉으로 보이는 결과에는 변화를 주지 않으면서, 조금씩 점진적으로 설계를 향상시키는 실천법이다
코드를 더 잘 파악하고 변화를 받아들일 수 있도록 만들어, 코드의 이해력을 향상시키는 데 주력한다
변수 이름, 메서드 이름 바꾸기? 리팩토링이 코드의 품질과 유지 보수성에 미치는 영향은 절대적이다
#14 테스트 주도 개발 Test-Driven Development , TDD
*테스트를 먼저 쓰라!
“어떻게 이렇게 깔끔하고 좋은 코드를 쓸 수 있는 겁니까?”
“아주 쉬워요”? “전 테스트를 먼저 쓰거든요”!!
매우 짧은 주기를 사용하면서 소프트웨어의 설계를 점진적으로 향상시키는 소프트웨어 개발 기법
TDD 원리? (테스트 실패->테스트 통과 -> 리팩토링 사이클 반복)
1)적색: 새로운 코드를 쓰기 전에, 먼저 새로운 코드로 성취하고자 하는 바가 무엇인지를 보여주는 ‘실패하는 단위 테스트’를 쓴다
2)녹색: 테스트를 통과시키기 위해 무엇이든 할 차례
3)리팩토링: 코드를 다시 검토하면서 깔끔하게 정리해보자
#15 지속적인 통합: 출시 준비
애자일화(being agile) 되었나? 애자일화 되는 것이 목적이 아니라 훌륭한 제품을 개발해서 고객에게 최상의 서비스를 제공하는 것이 목적이라는 것을 꼭 기억하도록 하자
우리는 매주 가치 있는 것을 고객에게 인도하는가?
우리는 계속 발전하기 위해 노력하고 있는가?
#애자일 선언 Agile Manifesto
프로세스와 도구보다 개인과 상호작용을
포괄적인 문서보다 제대로 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획에 따르기보다 변화에 대한 대응을(더 가치가 있게 여긴다!)
