본문 바로가기

전체 글

 (271)
VOC 임시로 운영되는 VOC 페이지
개인정보처리방침 ('https://bb-library.tistory.com/ '블랙빈 다이어리')은(는) 개인정보보호법에 따라 이용자의 개인정보 보호 및 권익을 보호하고 개인정보와 관련한 이용자의 고충을 원활하게 처리할 수 있도록 다음과 같은 처리방침을 두고 있습니다. ('블랙빈 다이어리') 은(는) 회사는 개인정보처리방침을 개정하는 경우 웹사이트 공지사항(또는 개별공지)을 통하여 공지할 것입니다. ○ 본 방침은부터 2024년 3월 17일부터 시행됩니다. ​ 1. 개인정보의 처리 목적 ('https://bb-library.tistory.com/ '블랙빈 다이어리')은(는) 개인정보를 다음의 목적을 위해 처리합니다. 처리한 개인정보는 다음의 목적이외의 용도로는 사용되지 않으며 이용 목적이 변경될 시에는 사전동의를 구할 예..
애자일 개발의 기술 2/e - 품질 No Bugs 이는 소프트웨어 개발 시에 버그를 최대한 빠르게 발견하고 수정을 중점에 둔다. 버그 비난 게임을 하지 말라. 낭비하는 기업은 책임을 '정확하게' 할당하기 위해 버그, 결함, 오류, 문제, 이상 등 의도하지 않은 기능을 정교하게 구분한다. 중요한 것은 무엇을 할 것인가. 버그는 여러분의 팀이 '완료'했다고 생각하지만, 이후 수정을 해야 하는 모든 것이다. 즉, 무언가 할 일이 필요하다면 카드로 만들어라. 그 뿐이다. 내부에서 품질을 구축하는 법 내부품질: 코드를 얼마나 쉽게 수정할 수 있는가 외부품질: 사용자가 볼 수 있는 소프트웨어 측면에 관한 것 내부에서 품질을 구축하는 법은 이해관계자가 만족시키는 수준으로 외부 품질을 유지하면서 내부 품질을 가능한 높게 유지..
애자일 개발의 기술 2/e - 디자인 디자인 시간이 지남에 따라 코드 변경 비용은 증가한다. 애자일이 당면한 문제가 바로 이것이다. 시간이 지날수록 변경 비용이 많이 든다면 가능한 비용이 저렴할 때 많은 걸 결정해야 한다. 애자일이 작동하려면 비용이 상대적으로 일정하게 유지되거나 시간이 지남에 따라 감소해야 한다. 이것이 기술적 전제조건이다. XP는 선제적으로 변경 비용을 줄이는 프랙티스를 포함한다. 이를 '진화적 디자인(evolutionary design)'이라고 한다. 이는 시간이 지남에 따라 디자인이 꾸준히 개선되므로 소프트웨어를 더 쉽게 변경할 수 있다. 점진적 디자인 개발자는 계획이 변경되면 작업이 낭비될 수 있는 디자인보단 스토리를 구현하여 고객에게 가치를 전달해야 한다. 이것은 위험해 보이지만 점진적 디자인을 활용..
애자일 개발의 기술 2/e - 개발 제로 프릭션 개발 속도는 마찰(friction)을 제거하는 데 있어 가장 중요한 영역이다. 여러분이 무언가를 변경한다면 5초 이내에 해당 변경에 관한 피드백을 받을 수 있어야 한다. 1초 이내라면 최고다. 아무리 늦더라도 10초 이내에 피드백을 받아야 한다. 이는 매우 쉽게 실험하고 이터레이션할 수 있음을 의미한다. 1초 피드백을 위해 하나는 빠른 피드백을 위한 빌드, 다른 하나는 프로덕션 배포를 위한 빌드다. 로컬 빌드가 프로덕션 빌드와 동일한 것이 바람직하지만, 빠른 피드백이 훨씬 중요하다. 코드 베이스가 커지면 테스트가 너무 많아져 1초 이내에 모두 실행할 수 없게 된다. 이런 때는 하위 테스트 집합만 실행되도록 수정해야 한다. 5분 통합 CI를 활용하면 하루에도 수 차례씩 통합을 진행할 것이다. ..
애자일 개발의 기술 2/e - 협업 집단 코드 오너십 팀이 코드에 대한 책임을 공유한다. 개선된 코드 품질은 이를 통해 얻을 수 있는 이점 중 하나이다. 집단 오너십이 생소할 때는 모든 사람이 실제로 함께 작업하기보다는 사실상 개별 스토리에 대한 오너십을 갖게 되는 실수가 발생하기 쉽다. 객관화 프로그래밍 집단 코드 오너십을 위해선 자아를 어느 정도 버려야 한다. 당신의 코드가 아니라 팀 코드에 자부심을 가져라. 집단 코드 오너십은 당신이 완벽하지 않아도 된다는 것을 의미한다. 더 개선하기 어려울 것 같으면 그대로 두라. 다른 사람들이 이를 개선할 수도 있다. 익숙하지 않은 코드로 작업하기 한두 명만 이해하고 있는 코드에서 작업한다면 집단 코드 오너십이 다소 위압적으로 보일 수 있다. 여러분이 이해하지 못하는 코드에 대한 오너십을 어떻게 ..
애자일 개발의 기술 2/e - 개선 개선 피드백과 적응은 애자일의 중심이다. 회고 유형 하트비트 회고: 이터레이션 종료 시점에서 진행 마일스톤 회고: 중요한 마일스톤마다 진행 진행 1.제 1원칙(5분) 놈커스의 제 1원칙을 상기하여 사람들에게 심리적 안전감을 조성한다. 우리가 발견한 것이 무엇이든 모든 사람이 그 당시 알려진 것, 그들이 가진 능력과 기술, 이용할 수 있는 리소스 및 주어진 상황을 고려할 때 그들이 할 수 있는 최고의 작업을 했음을 이해하고 진실로 믿어야 한다.[Kerth2001] 소방관 역시 사람이기에 당연히 실수를 한다. 그러나 소방관의 실수는 그 자신은 물론이고 동료나 그들이 서비스를 제공하는 시민들의 생명을 위협한다. 그럼에도 불구하고 소방관은 계속해서 실수를 하고, 때로 그 실수를 이터레이션한다.[Montagna1..
애자일 개발의 기술 2/e - 책임 책임 XP는 고객과 관리자에게 프로그래밍이 진행되는 매주 최대한의 가치를 얻을 수 있게 할 것을 약속한다. 이해관계자 신뢰 한 회사의 두 개의 팀이 있다. 한 팀은 애자일 팀으로, 커밋먼트를 달성하고 정기적으로 릴리스 했다. 한 팀은 일정이 늦어지고 작동하는 소프트웨어는 찾아볼 수 없었다. 그러나 기업이 규모를 줄였을 때 애자일 팀을 없앴다. 경영진은 고전하는 팀을 관찰하면서 멋진 다이어그램과 오래 일하는 프로그래머를 봤다. 그러나 애자일 팀은 대화하고 웃고 떠들며 정시에 퇴근하는, 그러면서도 화이트보드에 간단한 스케치와 차트만 그려 놓은 사람들을 봤다. 이를 조직적 항체라고 부른다. 애자일이 투입될 때 조직적 항체를 그대로 내버려두면 결국 애자일 팀을 압도하고 무너뜨릴 것이다. 즉, 이해관계자나 스폰서..

티스토리툴바