소프트웨어 개발 프로세스 개선
Download as PPTX, PDF4 likes1,155 views
소프트웨어 개발 프로세스 개선의 본질에 대한 고찰과 실천적인 방법 제시
소프트웨어 개발 프로세스 개선
- 1. 개발 프로세스 개선에 대한 고찰
- 2. About me 정도현 • 일본 Mamezou소속 컨설턴트 • 개발 프로세스 도입 및 개선 • 클라우드 컴퓨팅 아키텍처 구축 • InfoQ Japan 필진 • Qcon Tokyo 2015,2016 기획위원 • 블로그 • http://moreagile.net
- 3. 근무처소개 • 주식회사 Mamezou(豆蔵) • 2000년5월 설립 • 마메조 홀딩스 그룹산하 IT컨설팅 전문회사 • 일본내 자바와 OOP 패러다임 보급에 크게 기여한 회사로 유명 • 주요업무 기업대상 – IT전략 책정,IS부문지원,자체개발 지원 임베디드 – 프로세스개선, 기술도입지원, 품칠개선, 엔지니어링교육 SIer/ISV – 요구개발, 프레임웍 교육 - 소프트웨어 엔지니어 육성 및 트레이닝 • InfoQ 일본 파트너 • QCon Tokyo 주관사
- 4. 프로그래머를 위한 팟케스트 나는 프로그래머다 • iamprogrammer.io • 임백준(임작가), 김호광(데니스), 정도현(정개발) • ‘개발자들을 위한 유쾌한 팟캐스트’를 모토로 언어, 패러다임, 개발환경등을 주요 주제로 하여 매주 60분 분량 방송 • 나프다 미트업 • 6월24일 • 마이크로소프트 코리아 본사(광화문 앞) 11층 • 테마 : 개발자의 생존전략
- 5. 오늘의 주제 어떻게 하면 더 개발을 잘할 수 있을것인가?
- 6. 첫번째 질문 어떤 사람을 채용해야 하나요?
- 7. 성실하고 인성은 좋으나 실력이 부족한사람 VS 싸가지는 없어보이지만 실력이 뛰어난사람
- 9. 애자일 소프트웨어 개발 선언 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다: 공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
- 10. 두번째 질문 여러분이 애자일 개발에서 기대하는것은 무엇입니까?
- 11. 세번째 질문 애자일 개발은 무엇입니까?
- 12. 화물신앙
- 13. cargo cult 인과관계를 혼동하여 부차적인 것을 중요한 원인으로 믿는 것
- 14. 애자일 개발을 도입한 프로젝트들이 성공할 수 있었던 이유 개발자에 대한 신뢰 개선을 허락 스스로 결정 주인의식 /자부심 성과
- 15. 프로세스 개선을 위한 도구들
- 17. 프로덕트 기반 메니지먼트 • 프로젝트 • 한정적인 기간동안 수행 • 인원이 재 구성됨 • 외주 위주로 개발을 진행할 경우 PDCA를 제대로 실행하기 어려움 • 리스크가 높음 • 시설비용중심 관리에 적합 • 프로덕트 • 제품의 라이프사이클과 동일 • 동일한 인원으로 수행 • PDCA 사이클이 올바로 기능할 수 있음 • 리스크가 낮음 • 운영비용중심 관리에 적합
- 18. 전통적인 시설 기반 인프라
- 19. 클라우드 기반 인프라
- 20. 회고의 실천적 방법 - KPT법 • Keep-Problem-Try • 정례화에서 일상화로 • 구체적으로 • 생산성을 의식한다 • 진척회의는 별도로 진행
- 21. 배움의 선순환 • 회사는 배움의 장이 되어야 한다 • 구글에서는 모든것에 대하여 회고를 진행한다 • 잘 된것, 잘 못한것 모두 대상으로 진행 • 절대 비난하지 말 것 • 솔직하게 진행하지 않으면 결국 형식뿐인 빈 껍데기가 되어 버린다 • 배우는것을 좋아하고 즐기는 사람을 채용하라
- 22. 모던 개발을 위한 모범사례들
- 24. No ticket, No commit
- 25. 코드리뷰
- 26. Pull Request Issue Ticket • Branching Coding • UnitTest CI • Regression test • Static analysis Pull Request • Code Review • Merge
- 27. 코드리뷰의 원칙 • 기계의 일은 기계에게, 사람의 일은 사람이 • 정적 코드 분석 • 체크리스트 • 가독성과 사양 • 테스트 코드도 대상에 포함 • 리뷰어는 최소 2명 이상 • 상대방에 대한 존중
- 28. 자동화 테스트
- 29. 왜 자동화 테스트는 중요한가? • 기술적 부채 vs 기술적 자산 • 이자가 붙음 • 버그 발견 -> 테스트 케이스 추가 • 리팩토링에 대한 부담 저하 • 전체적인 코드 품질 향상 • 심리적 안정감, 만족감 • 테스트 코드가 세부적인 사양 문서를 대체
- 30. 좋은건 알지만 시간이 없어서…
- 31. 똑같은일을 계속해서 반복 하게 될 것을 생각하면 어느쪽이 더 시간 절약이 되는가?
- 32. 자동화 테스트의 오버헤드 관리 • 자율 or 강제 • 얼마나 작성해야 하는가? • 코드 커버리지 보다는 사양 커버리지 • 내부 가이드라인을 작성하고 개선시켜 나가야 함 • Unit Test or E2E Test • CI가 함께 하지 않으면 하나마나임
- 33. 문서화
- 34. 왜 문서화는 중요한가? • 문서화는 커뮤니케이션의 일부 • 읽는 사람을 배려 • 언어가 가진 불완전성을 보완 • 기술적 부채 vs 기술적 자산 • 이자가 붙음 • 애자일 선언문에 대한 해석 • 꼭 필요한 문서를 꼭 필요한 만큼만 만들것
- 35. 문서화 오버헤드 관리 • 정보를 중복해서 관리하지 않는다 • 임시 문서와 유지 문서 두가지로 나누어서 관리 • 임시 문서는 구현 시기의 커뮤니케이션을 보조하는 역할 • 유지 문서는 소스코드와 라이프 사이클을 함께하는 장기 정보 • 구현 프로세스의 장점을 도입 • 페어 프로그래밍(몹 프로그래밍), 리뷰, 사양에 대한 검증(BABOK) • 표준 언어를 사용 • UML, BPML
- 36. 팀운영
- 37. 독립적이면서 작은 팀 • 아마존의 피자 두판 팀: 팀 인원수는 피자 두판으로 끼니가 해결 될 수 있는 인원 이하로 유지하라. • 잘 정의된 인터페이스: 팀은 회사의 나머지 부분들과 효율적으로 의사소통을 할 수 있도록 적절한 의사 소통 통로를 지녀야 한다. • 완벽하게 독립적으로 운영하라: 팀에게 최대한의 자치권을 부여하라. • 자율성과 책임성: 스스로 결정하고 스스로 책임지도록 하라. 구글은 모든 서비스에 사용할 언어와 미들웨어, 플랫폼을 아무런 제약없이 팀 내부에서 자체적으로 결정할 수 있다.대신, 그에 따른 책임도 스스로 져야만 한다.
- 38. 실패를 대하는 자세
- 40. 실패에 대한 진실 혹은 오해 • 실패는 성공의 어머니? • 2번째 사업이 성공할 확률 • 첫번째 사업 성공시 : 34% • 첫번째 사업 실패시 : 23%(첫 사업의 성공확률과 비슷함) • 수치심과 죄책감 • 워싱턴DC 교도소 수감자들을 대상으로 한 심리학 연구
- 41. 결론
- 42. 모든것은 순환한다
- 43. 개발의 악순환 잦은 인원교체 커뮤니케이션 비용 증가 관리되지 않는 기술적 부채 주인의식 결여 폭탄돌리기
- 44. 개발의 선순환 적절한 근무사이클 커뮤니케이션 비용 감소 기술적 부채의 관리 기술적 자산에 투자 높은성과와 만족도
- 46. 선순환의 출발점은 ‘사람’ • 소프트웨어 기업에 있어서 사람은 가장 중요하면서 대체불가능한 자산이다. • 사람은 부품이 아니며 대체 불가능하다. • man-month기반 관리는 개발자의 긍지와 주인의식을 무너트린다. • 사람은 자산이지 원가 절감의 대상이 아니다. • 개발자가 회사에게 있어서 소중한 존재라는것을 느낄 수 있도록 하라 • 자신이 소중하게 다루어진다는 것을 느낄수록 더 열심히 일한다.
- 47. 첫번째 질문 어떤 사람을 채용해야 하나요?
- 48. 성실하고 인성은 좋으나 실력이 부족한사람 VS 싸가지는 없어보이지만 실력이 뛰어난사람
- 49. 실력은 어떻게 검증하는가
- 50. 인성은 어떻게 검증하는가?
- 51. 마이너스 생산성의 존재
- 52. 인성과 적성 모두 타협의 대상이 될 수 없다
- 53. 추천 서적
- 54. 감사합니다