본문 바로가기

개발 안하는 공대생/SW 관리  (ง°̀ﾛ°́)ง

Scrum 에서 품질 담당자의 역할은?? 스크럼과 V 모델 스크럼팀에서 품질 담당자 또는 테스트 엔지니어는 단계별로 무엇을 해야 하는가? 일반적인 스크럼 프레임워크에서 테스트에 대해 직접적으로 명시하고 있지 않다. 개발 단위를 잘게 쪼개어 개발을 수행하는 특성을 생각하면 예측할 수 있는 이유는 몇 가지 있다. 개발 완료 조건을 통해 원하는 품질을 달성할 수 있다. 테스트 엔지니어도 개발팀에 소속되어 프로세스 내에서 품질 활동을 해야 한다. 데일리 미팅을 통해 개발 중 발견된 이슈를 해결해야 한다. 스프린트 리뷰를 통해 제대로 개발되었는지 확인해야 한다. 하지만, 하나의 제품에 여러 스크럼팀이 함께 개발을 할 수도 있다. 스프린트가 완료되면 개발된 항목은 마스터 소스에 머지되어야 하며 이때 사이드 이슈가 발생할 가능성이 있다. 보통 CI/CD 에.. 더보기
요구 공학 (Requirement Engineering) 요구 공학은 소프트웨어 공학에서 요구사항 부분이 파생된 학문으로 Wiki 에서 확인할 수 있다. 위키 백과 바로가기 요구사항은 사용자 요구사항과 시스템 요구사항으로 구분할 수 있으며 비 개발 직군인 기획자의 경우 사용자 요구사항을 담당하고 개발직군은 시스템 요구사항을 담당해야 한다. 하지만 요구사항 분석가나 아키텍트나 그에 준하는 직무가 없는 경우 자신의 업무가 아니라는 식으로 작성하지 않는 경우가 태반이다. 비 개발직군은 아래 링크만 확인하고 요구 사항_수집?분석?정의?명세? 우선 펼쳐보자 본 글은 필자의 경험과 교육, 세미나를 통해 얻은 지식을 바탕으로 공유하는 내용입니다. 기획은 답이 없다. 단지, 지금 시점에서 더 옳다고 판단되는 것을 구체화하는 작업이다 6987.tistory.com 개발직군은 .. 더보기
소프트웨어의 글로벌화 준비하기 (개발관점) 소프트웨어 개발을 하면서 글로벌 론칭이라는 목표 아래 무작정 영어만 추가하여 개발을 시작하는 팀이 있다. 영문으로만 만들어지면 글로벌화된 것인가? 에 대한 질문에 그렇다 아니다 라고 단정 지어 대답하기는 어려운 것 같다. 제품의 방향과 도메인 특성에 따라 글로벌화 준비 항목들이 차이가 있을 수 있다. 글로벌화 관련하여 기본 내용을 확인하여 활용하는 것이 좋다. 개요 글로벌화의 개발 목적은 다양한 언어나 문화권의 사용자들이 제품을 이용하는 데 있어 발생할 수 있는 문제를 최소화하기 위함이다. 용어 정의 현지화 (Localization, L10n) - 제품을 특정 언어나 문화권에 적합하도록 커스터마이징 하는 작업. - 현지의 제품과 비교하여 차이가 나지 않도록 특색을 반영하는 것이 중요함. 국제화 (Inte.. 더보기
소프트웨어의 글로벌화 체크리스트 (개발관점) 소프트웨어의 글로벌화에 대한 정리 글로벌화의 개발 목적은 다양한 언어나 문화권의 사용자들이 제품을 이용하는데 있어 발생할 수 있는 문제를 최소화하기 위함이다. 현지화 (Localization, L10n), 국제화 (Internationalization, I18n), 글로벌화 (Globalization, G11n) 6987.tistory.com 소프트웨어의 글로벌화를 위한 점검 항목은 아래와 같이 구분하고 있다. (출처 : NIPA) 아래 상세 점검 항목을 기반으로 현재 글로벌 서비스로 준비 중인 소프트웨어를 점검하고 보완할 수 있다. NIPA 점검 항목에 내용이 더 추가되었다. 기본 점검 항목 코드 점검 항목 BASE-01 서비스 범위(지역), 지원 언어를 식별한다. BASE-02 글로벌화 요구사항을 수.. 더보기
Product Owner Framework - Summary (PO라면 한번쯤 고민..) ©Copyright 2015 - Daisy Pilbrow, Javier Ubillos, and Viktor Cessan. productownerframework.wordpress.com 공유된 프레임워크에 대한 이용은 유료로 사용이 가능하다. 2015년도 PO Framework 를 Beta 로 오픈하고 더 이상의 업데이트는 없다. 망했거나..... 아직도 유용하거나.... (전자겠지..) 전반적인 내용은 좋은 시도라고 보인다. (뻔한 내용임) 4개의 범주와 8개의 영역으로 PO 에 대한 평가가 가능하도록 구성되었다. - 실제 항목에 대한 자세한 설명과 함께 체크를 하여 점수를 매길 수 있도록 구성됨. 그리고 평가 결과로 무엇을 더 발전시켜야 할지 알 수 있을 것이다. 하지만 평가에 대한 코치를 해줄 사람.. 더보기
User-stroy, Testable in the INVEST Testable – 테스트 가능해야 한다 출처 : xp123.com/articles/testable-stories-in-the-invest-model/ 테스트 가능한 스토리는 입력이 주어지면 예상되는 시스템 동작 또는 출력에 동의할 수 있는 스토리이다. 좋은 스토리는 테스트할 수 있다. "내가 원하는 것을 충분히 이해하여 테스트(케이스 or 명세)를 작성할 수 있다." 여러 팀이 스토리를 구현하기 전에 고객 테스트를 요구함으로써 팀의 생산성이 더 높다라는 보고도 있다. "테스트 가능성" 은 항상 좋은 요구 사항의 특징이다. 실제로 테스트를 일찍 작성하면이 목표가 충족되었는지 알 수 있다. 팀은 비 기능적 요구 사항 (예 : 성능 및 사용성)을 테스트해야 하는 것으로 취급할 수 있다. 이러한 테스트를 운영.. 더보기
User-stroy, Small scalable in the INVEST Small Scalable – 작아야 한다 출처 : xp123.com/articles/small-scalable-stories-in-the-invest-model/ 좋은 스토리는 작은 경향이 있다. 스토리는 일반적으로 최대 몇 주 분량의 작업을 나타낸다. (일부 팀에서는 며칠의 작업으로 제한한다.) 이 규모보다 크면 스토리 범위에 무엇이 있는지 알기가 너무 어려워 보입니다. "한 달 이상 걸릴 것이다." 라는 말은 종종 "무엇이 수반되는지 이해할 수 없기 때문에" 묵시적으로 추가한다. 작은 이야기는 더 정확한 추정치를 얻는 경향이 있다. 주요 포인트 - High-Level Stories: Themes and Activities - Middle Level: The Headline - Low Level: T.. 더보기
User-stroy, Estimable in the INVEST Estimable – 추정 가능하다 출처 : xp123.com/articles/estimable-stories-in-the-invest-model/ 좋은 스토리는 추정할 수 있다. 정확한 추정은 필요하지 않지만 고객이 스토리 구현의 순위를 매기고 일정을 잡는 데 도움이 될 만큼 충분하다. 우리가 이해하지 못하는 스토리는 추정하기가 어렵기 때문에 추정 가능하다는 것은 부분적으로 협상의 기능이다. 또한 크기의 함수이기도 합니다. 더 큰 스토리는 추정하기가 더 어렵습니다. 마지막으로 이는 팀의 기능입니다. 예측하기 쉬운 것은 팀의 경험에 따라 다릅니다. 때때로 팀은 적절한 추정을 내기 위해 충분한 정보를 제공하는 "SPIKE" 와 원하는 기능을 실제로 구현할 나머지 스토리로 나누어야 할 수 있습니다. 개발자들.. 더보기
User-stroy, Valuable in the INVEST Valuable – 사용자와 고객 혹은 구매자에게 가치 있다 출처 : xp123.com/articles/valuable-stories-in-the-invest-model/ 스토리는 가치가 있어야 한다. 우리는 누구에게나 가치가 있어야 하는 것이 아니라 고객에게 가치가 있어야 한다. 개발자는(합법적인) 우려 사항이 있을 수 있지만 이러한 우려는 고객이 이를 중요하게 인식하게 만드는 방식으로 구성된다. 이것은 스토리를 분할할 때 특히 문제가 될 수 있다. 전체 스토리를 네트워크 계층, 지속성 계층, 논리 계층 및 프레젠테이션 계층과 같은 다중 계층의 케이크라고 한다. 스토리를 나누면 그 케이크의 일부만 제공한다. 우리는 고객에게 전체 케이크의 본질을 제공하고 싶으며 가장 좋은 방법은 레이어를 수직으로 자르는.. 더보기
User-stroy, Negotiable in the INVEST Negotiable - 협상가능하다 출처 : xp123.com/articles/negotiable-stories-in-the-invest-model/ 좋은 스토리는 협상 가능하다. 기능에 대한 명시적인 계약("contract")이 아니다. 오히려 세부 사항은 개발 중에 고객과 개발팀이 공동으로 작성한다. 좋은 스토리는 세부 사항이 아닌 본질을 포착한다. 시간이 지남에 따라 카드는 메모(주석), 테스트 아이디어 등을 얻을 수 있지만 스토리의 우선순위를 지정하거나 예약하는 데 이러한 정보가 필요하지 않다. 주요 포인트 - The importance of collaboration (협업의 중요성) - Evolutionary design (혁신적인 설계) - Response to change (피드백) "Car.. 더보기
User-stroy, Independent in the INVEST Independent - 독립적이다 출처 : xp123.com/articles/independent-stories-in-the-invest-model/ 스토리는 독립적인 경우 작업하기 가장 쉽다. 즉, 개념이 겹치지 않도록 하고 어떤 순서로든 일정을 잡고 구현할 수 있기를 바란다. 항상 이것을 달성할 수는 없다. 때때로 우리는 "첫 번째 보고서에 대해 3 점, 나머지 각각에 대해 1 점"과 같은 말을 할 수 있다. 유저 스토리 간의 의존성을 제거하여 독립성을 유지한다. 독립적인 스토리는 프로젝트의 비즈니스 및 기술 측면 모두에 도움이 된다고 한다. 사업적 관점 : 기술에 종속되지 않고 사업 목표에 초점을 맞출 수 있음. 기술적 관점 : MVP(최소 가치 제품)의 구현 실현 및 종속을 최소화하는 설계 가능.. 더보기
요구사항_INVEST in Good User-story 좋은 유저 스토리란 아래 6가지 특성을 만족한다라고 한다. INVEST in Good Stories, and SMART Tasks - XP123 (French) XP teams have to manage stories and tasks. The INVEST and SMART acronyms can remind teams of the good characteristics of each. Are you a Product Owner or a writer of user stories? I’d love to hear about your challenges and successes at william.w xp123.com 좋은 유저 스토리를 위한 6가지 특성 좋은 유저 스토리를 작성하기 위해서는 좋은 유저 스토리의.. 더보기
Essential XP : Card, Conversation, Confirmation 애자일 소프트웨어 개발 선언 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다 : 공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hun.. 더보기
Scrum 에 맞춰본 테스팅 V-Model 테스트 분야 공부를 하게 되면 반드시 만나는 V-Model 에 대한 생각이다. ISTQB 공부를 하면서 실라버스에 나온 내용과 테스트 실무 등.. 프로세스 및 정책은 언제나 웅장한 느낌을 받는다. 그럼 실무에서는 어떻게 적용해야 할 것인가? 여태 다녀본 회사에 품질, 테스트 조직이 있다한들 테스트 정책을 명문화하여 지키는 것을 본 적이 없었다. 그리고 앞으로도 없을 것 같다. 그만큼 실무와 거리가 생기는 내용이라 생각한다. 개발 프로세스를 개선하면서 늘 품질 파트를 어떻게 접목해야 하는가라는 고민이 생겼다. 일전에 스크럼을 공유하면서 고민했던 내용을 끄적여 본다. Scrum 프레임워크를 통해 개발자들은 어떻게 개발을 해야되는지 알게 된다. 하지만 품질 담당자에 대한 언급은 없었던 것 같다. 개발을 잘하면.. 더보기
프로젝트의 시작, PM 으로써 무엇을 먼저하는가? 본 글은 필자의 경험과 교육, 세미나를 통해 얻은 지식을 바탕으로 공유하는 내용입니다. Project Manager VS Product Manager SW 관리자를 우리는 보통 PM 이라 부른다. 명확하게 PM 이 지칭하는 역할이 Project Manager 인지 Proudct Manager 인지를 확인해보고 싶다. 두 직무는 명확히 다른 목적을 가진 업무로 헷갈리지 않기를 PM vs PM SW 공학, 품질 관리 등 책을 보면 프로젝트 시작을 위해 가장 먼저 해야 될 업무에 대해 정의가 되어 있다. 물론 책마다, 글쓴이마다, 도메인 특성에 따라 다를 것이다. 나는 내부 SW 개발 프로젝트를 참여하면서 그 누구도 그것을 하는 사람을 보지 못했다. 다들 운영을 하고 있던 프로젝트라 신경을 쓰지 않았던 부분이.. 더보기
스크럼마스터는 누가하나요?? (묻는 사람이 하세요) Scrum 을 도입하고자 할 때 또는 셋업 하려고 할 때 가장 먼저 무엇을 신경 쓸 것인가? 나는 당연히 업무 분장이라고 생각한다. (Role and Responsibilities) 스크럼의 구성원은 보통 3가지로 구분된다. PO (Product Owner) SM (Scrum Master) SD (Scrum Developer / Scrum Team) 그럼 조직에서는 현재 구성원을 어떻게 배치할지에 대해 고민을 해야 한다. 보통의 조직은 이렇지 않을까.. - PO : 기획자 or PM - SM : PM - SD : 개발, 디자인, 기획, 테스터 이제부터 개인적인 배치에 들어갑니다. PO : 기획자가 적합. - 기술 기반의 지식이 중요하지 않음. (사용자, 유저 친화적이어야 함) - 이해관계자와 커뮤니케이션.. 더보기