애자일 소프트웨어 개발

No description »
Youngrok Pak

애자일 소프트웨어 개발
박영록
SI 프로젝트의 어려움
개발자들의 불만
요구사항이 이렇게 애매모호한데
어떻게 개발하라고?
아니 처음에는 아무 말 없다가
왜 이제와서 바꾸자는 거야!
고객도 불만이 있다.
이건 내가 원하는 게 아니야!
그거 좀 바꿔주면 되지 그게 그렇게 어렵나?
좋은 방법이 있으면 좀 제안해주면 좋을 텐데
시키는 것만 하려고 하는군.
그렇게 쪼은다고 내일 결과물을 볼 수 있는 건 아니라고.
나는 야근이 싫어요.
왜 이런 문제가 발생할까?
고객은 변경을 원한다
개발자에게 변경은 비용이다
vs

변경 이력 관리
뭐 바꾸고 싶으면 절차를 밟아주세요.
간접적으로 변경을 막는 효과
변경을 원하는 것이 잘못일까?
처음부터 제대로 했으면 되는 거 아닌가?
처음부터 완벽하게 설계할 수는 없다
고객은 자신이 원하는 것이 뭔지 잘 모른다
잡스가 만들어주기 전까지는
이게 나한테 필요한 건지 몰랐다
직접 써보기 전에는 잘 모른다.
소프트웨어를 개발하는 동안 사람들은 발전한다
개발자는 고객의 니즈에 대한 이해도가 높아진다
고객은 기술에 대한 이해도가 높아진다
기술적인 위험성을 모두 고려하기 힘들다
새로운 개발 언어
대용량의 데이터
다양한 시스템 간 연동
레가시 시스템
새로운 서버 환경
예상 밖의 트래픽
현실을 인정하자
요구사항은 변한다
해보기 전에는 알 수 없다
Agile != Fast or Quick
Agile == Early and Often
Agile
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
반복적인 개발
Weekly Release
1주일 단위로 반복
이렇게 하면 뭐가 좋은데?
개발된 기능을 빨리 사용해볼 수 있기 때문에 유용성도 더 일찍 판단할 수 있다.
개발 진도 == 릴리스된 제품
프로젝트 끝날 때 다 되서 뒤집는 일은 없어진다
막판 야근 러시 대신 일찍부터 일정 예측이 가능하다.
고객과의 협업
고객의 이중적 속성
내 맘대로 소프트웨어를 만들었으면 좋겠어
하지만 내 맘이 뭔지는 니들이 알아내
고객이 참여하지 않으면 고객이 원하는 제품은 나오지 않는다
한 공간에서 함께 일하기
매주 릴리스를 하고 고객의 피드백 받기
Not enough!
먼저 제안하라!
고객은 소프트웨어 전문가가 아니다
이러면 개발자만 죽어나는 거 아냐?
YES!
하지만, 꼭 그런 것은 아니다
Weekly Release의 효과
불필요한 기능은 고객이 빼고 싶어한다
고객이 기능 범위와 비용을 스스로 저울질한다
Negotiated Scope Contract
fixed time, cost, quality
20%의 핵심 기능은 약속하되, 80%의 다른 기능은
개발 진도와 변경 사항을 봐가면서 조절한다
이콜레모가 경험한 사례
고시 학원의 인터넷 강의 앱 개발
아이폰 / 안드로이드
Creative Commons Korea
기능 명세서 작성 후 기능별 소요시간 산정
개발 완료 2주 전까지 어떤 종류의 변경이든 수용
변경하는 비용만큼 기존의 명세서에 있는 기능은 제외
고객과 함께 사용자 스토리 작성
고객이 애자일 방법론으로 일하는 개발사를 찾아옴
문화부 산하 저작권위원회 예산
분석 / 설계
개발
테스트
Motivated Individuals
좋은 작업 환경
원하는 시간에 일하기
보람 있는 일
학습
경력 계발
Test Driven Development
자동화된 테스트로 변경에 대한 대응력 높이기
자동화된 테스트가 가능한 코드는 설계도 좋다
생산성 높이기
Continuous Integration
Informative Workspace
작업 진행 상황 
이슈
회의, 등 이벤트 일정 
언제든지 원할 때 전체 통합 빌드를 하고
테스트를 해볼 수 있다
Refactoring
코드의 설계를 점진적으로 개선한다
처음부터 좋은 설계를 하는 것은 어렵다
일단 동작하게 만들고, 그 다음에 개선한다
한 번에 대규모로 코드를 뜯어고치기보다
조금씩 코드의 설계를 개선해 나간다
Baby Step
잘 안 풀릴 때는 할 수 있는 가장 작은 단계를 생각한다
새로운 시도를 할 때는 한 번에 큰 변화보다 조금씩 적용하기
Agile Manifesto
Individuals and interactions
over processes and tools
Working software
 over comprehensive documentation
Customer collaboration
 over contract negotiation
Responding to change
 over following a plan
Embrace Change!

Loading comments...

Please log in to add your comment.

Report abuse

More presentations by Youngrok Pak