css 파일에서 본문 내용의 리스트를 표현하는 li, ul, ol 과 관련된 list-style속성을 찾는다.
해당 속성이 none이라고 표현되어 있을텐데, 바꾸고 싶은 스타일에 맞게 바꾼다.
이 블로그에서는 컨텐츠의 마크다운 목록을 바꾸고 싶었기 때문에 컨텐츠의 ul, ol 요소를 찾아 list-style을 각각 disk, decimal로 바꿔주었다. disk는 원형, decimal은 10진수를 의미한다. 아무 요소의 list-style을 바꾸게 되면 의도하지 않은 화면의 리스트를 바꿀 수 있기 때문에 주의해야 한다.
참고) 다음과 같이 바꿔 주었다.
.bc-markdown__inner-content ol li{
list-style: decimal;
}
.bc-markdown__inner-content ul li{
list-style: disc;
}
스크럼을 적용하는데 있어서 어디서나, 어떤팀에서나 딱 알맞는 형태의 스크럼은 없습니다. 스크럼의 기본인 ‘점진적 개발’을 목표로 회고를 하며 우리팀의 상황에 맞게끔 스크럼을 점점 변형시켜 나가면서 case by team 으로 맞추어 나가야 합니다.
이 포스팅은 앞서 정리한 scrum을 jira로 관리하기 위한 가장 기본적이면서도 구체적으로 진행할수 있는 방안을 제시해보도록 하겠습니다.
Jira default 이슈 종류
Epic (큰틀) : 여러 스프린트에 걸쳐서 끝나지 않고, 여러 스토리들의 집합입니다.
Story : “{사용자} 로써 {무엇}을 하고싶다” 에 대한 액터의 유즈케이스
Chore : 사용자와는 직접적으로 관계되지 않는 개발 (DB 세팅, 분리 등)
Task : 구현에는 직접적으로 관련이 없는 업무 (문서작성 등)
Issue : 이슈 사항 (서버 다운, 클라우드 계약 등)
Bug : 테스트 엔지니어로부터 버그로 리포팅된 타입
Sub Task : 스토리 혹은 초어들을 개발하기 위해 진행되는 실제 세부 개발사항들
우리 Jira에 맞춘 이슈 정리
Epic (큰틀)
TaskStory : 요구사항 혹은 유저케이스 시나리오 개발 : 개발 요구사항 (chore) 버그 : 서비스 버그 작업 : 개발 구현과는 직접적으로 관련 없는 요구사항 이슈 : 서비스상의 이슈, 확인, 고려사항
Sub-task개발 / 버그 / 작업 / 이슈
Example
Epic : 회원가입/로그인
Task
(Story) 사내 직원이 어드민 회원가입 할 수 있다.
(Task) DB 인프라 신청
Sub-task1-1. (작업) Oauth 권한신청 1-2. (개발) 회원가입 서비스 개발
유의사항
지라는 진행 프로젝트마다 별도의 프로젝트로 생성하여 관리합니다.
Release(버전)는 Epic 단위로 정의합니다. (Epic은 필수 기능을 중심으로 프로젝트 진행의 마일스톤으로 사용합니다.)
Sprint는 Task단위로 정의합니다. (Task는 최대 3일 이내의 작업기간으로 산정합니다.)
Release > Epic > Sprint > Task
스크럼 진행순서
1. 제품 백로그 준비 (Project Owner)는 프로젝트 요구사항에 맞추어 Epic(큰틀)들을 생성 합니다. Epic은 필수기능으로써, 프로젝트의 진행 척도를 나타낼수있는 마일스톤이 될 수 있도록 생성합니다.
2. 릴리즈 계획 수립 (Project Owner)는 [1 단계]에서 생성한 Epic들을 가지고 프로젝트 릴리즈 계획을 세웁니다.
3. 스프린트 계획 수립 3-1. Task 만들기 (Project Owner + Scrum Master)는 [2단계]에서 수립된 릴리즈 계획내에 포함된 Epic들을 세부 작업 Task로 쪼갭니다. (Scrum Master)는 만들어진 Task를 적절한 팀원에게 배분합니다 배분받은(스크럼팀)은 Task의 수행시간을 예측합니다. (최대 3일 이내의 작업으로 Task가 분리되어야 합니다.)
(고려해야할 사항)
팀원의 가용 시간
각 Task에 대해서 수행 시간 예측
Task 설정시 구체적인 종결 행위를 기반으로 Task 설정 하는것이 좋습니다.
Task 설정시 분석,설계 / 구현 / 테스트 → 1:1:1 의 리소스 분배가 좋습니다.
주요 Task에 대해서는 어떤 형식으로든지 리뷰를 하는것이 좋습니다.
Task 기간 설정시 20%의 버퍼를 두는것이 좋습니다.
3-2. 스프린트 만들기 (Scrum Master)는 [3-1단계] 에서 만든 Task를 2주단위의 스프린트로 조합 합니다. 스프린트를 만들때에는 Task의 “긴급도, 난이도”에 따라 우선순위를 두고 Task 작업 순서를 정합니다.
3-3. Task 작업 Task를 할당받은 (스크럼팀)은 할당받은 Task를 실제 작업의 세부 단위로 Sub-task를 작성하여 작업을 진행합니다.
4. 스프린트 관리 스크럼팀은 매일 오전 최대 20분 내의 일일 스크럼을 진행합니다. 일일 스크럼때는 어제 작업내용, 오늘 작업예정 내용 및 Task 종료에 필요한 시간들을 공유하고(Project Owner)는 이슈사항 발생시 일정조정 및 요구사항의 수정 내용을 백로그에 수정 반영 합니다. (Project Owner)는 스크럼팀의 작업 진행상황을 확인하고 Task의 상태를 설정 해 줍니다. (완료, 작업중 등..) 스크럼팀은 본인이 작업하는 실제 세부작업인 Sub-task들의 상태를 직접 관리 합니다.
5. 스프린트 종료 제 1의 조건으로 스프린트의 정해진 기간 (2주) 단위로 스프린트를 종료하도록 합니다. 만약 Task의 이슈사항으로인해 정해진 기간내에 마무리가 되지 않았다고 하면, 해당 Task를 다음 스프린트로 넘깁니다. (스크럼팀)은 본인이 수행한 Task의 구현이 테스트까지 완료되었을때 Task가 종료되어야 합니다. (스크럼팀)은 스프린트 종료일 오전에는 일일 스크럼대신 스프린트 리뷰를 진행하며 구체적인 테스트 결과및 데모를 수행합니다. (Project Owner)는 완료된 스프린트의 작업사항들을 종합하여 QA를 진행합니다.
6. 백로그 업데이트 (Project Owner)는 스프린트 리뷰 완료후 리뷰과정에서 나온 추가 요건이나 오류사항, 변경상황을 반영하여 백로그를 업데이트 합니다.
7. 회고 (스크럼팀)은 단순 스프린트 작업에대한 리뷰가 아닌, 스크럼 방법론 자체에대한 리뷰를 진행합니다. 이 과정을 통해 우리 팀에 맞는 더 좋은 스크럼 프로세스를 찾고 개선해나갑니다.
Agile(애자일) 대표 관리 Practice인 Scrum(스크럼)은 특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발 뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크입니다. Scrum은 작은 주기(Sprint)로 개발 및 검토를 하며 효율적인 협업 방법을 제공합니다.
따라서 필요한 분석/설계/개발 가이드는 조직내에서 사용하고 있는 개발방법론, 산출물 가이드 등과 병행해서 활용 가능합니다. 실질적인 도움이 되지 않는 문서를 작성하지 않는 것이 중요하며, 효과적으로 일하는데 필요한 문서는 반드시 작성해야 합니다.
1995년에 Ken Schwaber와 Jeff Sutherland가 고안 -노나카 이쿠지로와타케우지 히로타카가 1986년 1~2월 Harvard Business Review에 올린 “The New New Product Developement Game”에서 시작
비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크(기법)
사람들이 효과적으로 성취감을 충족하며 협업할 수 있게하여, 복잡하고 정교한 제품을 생산
1. 2. 주요 특징
솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
개발 주기는 1~4주 정도로 하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라. (설명:너무 짧으면 개발(분석/설계/개발/테스트) 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로 적용해보면서 필요시 조율 필요)
개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라. (설명:해당 주기의 Goal을 작성하지 않으면 목적을 잃은 기능 목록이 될 수 있음)
매일 15분 정도의 Scrum meeting 회의를 가져라. (설명:공유이지 보고하는 자리가 아니다. 교과서적으로 Scrum meeting은 개발팀원만 참여해야하고, 팀원이 아닌 사람은 발언기회는 없다고 한다. 개인적인 생각으로는 수평문화가 되어 있는 Agile Culture의팀이라면 PO 및 관리자가 함께 참석하여 공유하면 좋다고 생각한다. 이들도 참석한다면 이 프로젝트와 관련되어 한일/할일/이슈를 공유해야 한다. 안그러면 한팀이 아닌 관리자 모드로 돌아선다.)
항상 팀을 우선으로 생각하라. (설명:자신의 task보다 주변 이슈가 더 급하면 도와줘야 한다. 마치 배에 구멍이 나면 그 문제 해결이 1순위이다.)
원활한 의사소통을 위하여, 구분 없는 열린 공간과 마음을 유지하라.
2. Scrum의 추구 가치
용기 :옳은 일을 할 수 있도록 팀원간 갈등과 도전을 위한 용기를 가져라! (설명 : 상사에게도 해당 기능이 이해가 안되거나 문제가 있다면 말할 수 있어야 하고, 더 일을 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득 시켜야 한다.)
집중 : 공동 목표 달성을 위한 일을 하라. 모든 노력과 기술은 성공을 위해 집중하고, 그 외는 걱정(신경쓰지) 마라! (설명 : Goal/업무에 집중 할 수 있도록 하며, 루틴한 반복 작업이 있다면 제거, 자동화 등 효율적화해야 한다.)
약속(헌신/책임) :팀의 목표 달성을 위해 개개인이 공약한 목표 달성을 위해 헌신하고, 필요한 모든 권한을 부여하라! (설명 : 개인 성과보다는 팀의 성과 달성이 우선이고, 이를 위해 최대한 지원/권한이 필요하다.)
존중 :경력과 경험이 사람을 만든다. 팀원과 Idea를 존중하라! (설명 : 개개인별로 경험과 장단점이 있고, 다른 생각을 하는 사람도 그 이유가 있을것이다.)
투명성/개방성 :프로젝트에 대한 모든 작업 내용을 투명하게 공개하라! (설명 : 제품백로그, 스크럼 회의, 스프린트 리뷰를 통해 공유되며, 자신에게 불리해도 숨기지 않는다. 그래야 Idea나 문제점이 보인다.)
일일 스크럼 회의(Daily Scrum Meeting): 매일 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의 (해설:모든 참여자가 보고가 아닌 수평적으로 공유 차원에서 진행해야 하며 팀원이 아니면 발언권은 없다. 개인적인 생각으로는 만약 PO, 관리자 등도 참여한다면 똑같이 3가지를 공유해야 한다. 그렇지 않으면 듣는 자리, 즉 보고 받는 자리로 변질되고, 개발자 관점에서는 관리자가 노는 사람 처럼 보인다. 또한 Sprint Planning에 없는 제3자가 시킨 잡무를 하고 있다는 것도 파악이 가능하다. 장애요소는 화이트보드에 적어놓고 지속적으로 해결한다. 만약 해결보다 쌓이는게 만다면 회사는 팀을 충분히 지원하지 않는 것이며, 일일 스크럼 회의는 생산적이지 않은 낭비로 인식된다.)
스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다. (해설:PO는 기능과 우선순위에 대한 권한이 있고, 개발팀은 Sprint내에 해야 할 업무량을 결정할 권한이 있다. 특히 개발경험 있는 PO가 너무 적은 개발량을 문제제기 하기도 하지만, 실제 개발하는 개발팀원의 개발속도(Velocity)로 예측하며 조정이 중요하다.)
스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해 한다.
제품의 리뷰를 통해 제품의 지속적 개선사항 도출이 끝나면, 스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖는다. (해설:스프린트 Review는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동이다.)
다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖는다.
'없다'고 보면 된다.(며칠 밤새가면서 해결해보려 노력한 사람으로서 자그만 희망을 기대하고 들어온 사람들에게 이 말을 하는 게 마음이 아프다 ㅠ,,) 정말 온갖 복구 방법, 도구를 활용해서 복구를 시도했지만 모두 실패했다. 그래도 세상에 존재하는 모든 방법을 시도해봤다고는 할 순 없으니, 적어도 내 경우에는 거의 포기하는 편이 낫다고 말하고 싶다. 내 경우는 '녹화 중에 의도치 않은 종료로 인한 파일 손상'이다. 예를 들어, 녹화 중에 노트북 배터리가 다 되어 종료된다거나, 갑자기 엑박이 뜬다거나 한 경우이다.
그래서 찾은 대안으로는 mkv로 녹화하는 것이다. 이전에 겪었던 문제도 해결할 수 있었다. 그나마 복구가 수월하고 복구 가능성도 높다.
☝요약: mp4 복구하려다 골병난다! 포기하고 애초에 mkv로 녹화하자! (단점: 비교적 용량이 크다)
새로운 카테고리를 만들면서 '기획자의 습관'이라는 명칭을 사용하고 싶었는데, 같은 이름의 책이 있어 차마 같이 검색되는게 부끄러워 기획자의 생각으로 지었네요.
최근 포스팅을 꾸준히 해야지 마음을 다잡고 나서 바로 다니던 회사에 사직서를 제출하게 되고 이직을 준비하게 되면서 시간이 조금 생기더라구요.
처음 사회생활을 시작할 때 개발을 업으로 사는 개발자에서 굴러굴러 생소한 기획이라는 파트로 옮기게 되었고, 기획에 대한 정론과 기초 보다는 현업에서 당장 눈 앞에 닥치는 일들을 우선적으로 처리하면서 어찌어찌 실무를 해낼 수 있는 실력은 가지게 되었지만, 계속해서 제대로 하고 있는지에 대한 고민이 많이 들었습니다.
그래서 다시금 기존에 공부했었던 내용과 준비하는 기간동안 새롭게 공부하는 내용을 적어보고자 하는 공간을 만들어 보게 되었습니다.
기획이란?
굉장히 친숙하고 주변에서도 쉽게 사용하고 어디에도 다 붙어 있는거 같은 단어입니다.
그리고 굉장히 쓰이는 곳도 많습니다.
상품 기획, 사업 기획, 전략 기획, 인사 기획, 개발 기획, 광고 기획, 방송 기획, 공연 기획, 영업 기획 등....
이것 뿐만이 아니라 어디 안쓰이는 곳 없이 많이 사용되고 있습니다.
특히나 직장에서 일을 하는 것에 기획을 붙여서 어색한 단어가 없을 정도로 심심치 않게 사용되고 있습니다.
단순하게 단어로만 풀어보면 '기획(企劃)'은 일을 꾀하여 계획한다 라는 뜻입니다. 영어로도 '기획(Planing)' 계획하다 라는 뜻이 됩니다.
많은 서적이나 인터넷 상에 다양하게 해석되고 있지만, 가장 간단하게 '무엇인가를 성취하기 위한 계획'을 세우는 일이 가장 통합되는 개념이 아닐까 합니다.
사람들은 일상생활에서도 굉장히 많은 기획들을 하고 있습니다. 단지 그것이 상상하던 기획과는 굉장히 다른 간출한 방법 또는 쉽게 지나가고 있기 때문에 기획이라 생각하지 않는 부분들이 많죠.
예를 들어서, 월급을 받고 얼마를 저축하고, 얼마를 생활비로 사용하고, 이번달엔 무엇을 살지에 대해서 고민을 하고 적어보는 것 역시 기획입니다. 본인의 한 달 생활에 대한 회계 또는 재무 기획이 될 수 있겠죠.
기획자의 역할이란?
결국 기획이란 어떤 문제가 있다면 해결하기 위한 해결책을 제시하거나 새로운 아이디어나 이슈가 있다면 현실로 만들기 위한 계획을 세우는 일입니다.
기획자의 역할은 너무나도 당연하게 이런 해결책을 제시하고 계획을 세우기 위한 기획을 하는 것이겠죠.
하지만, 회사나 기관에서 발생하는 문제를 해결하거나 아이디어를 제시하는 사람들을 모두 기획자라고 부르진 않습니다. 별도의 조직을 만들고 직군을 두면서 기획자를 활용하는 이유는 문제가 되는 현상을 해결하기 위한 '최적의 방안'을 계획하기 때문입니다.
어떤 조직에서 발생하는 문제나 해결을 필요로 하는 부분들은 같은 문제라고 해도 조직의 환경이나 상태에 따라 다양한 문제의 해결 방법이 존재한다.
어떤 조직에서는 최선의 방법이 될 수 있지만, 똑같은 문제에 대해 다른 조직에서 같은 방법을 사용한다면 반대로 최악의 결과를 발생시킬 수도 있는 것입니다.
기획자는 현재 상황, 조건에 맞는 최선의 방법을 제시를 할 수 있으며, 제시한 방법에 대해서 정확한 근거를 바탕으로 다른 사람들을 설득할 수 있는 조건을 가지고 있습니다.
기획을 시작하면서 들은 조언
기획자가 되기 위해 기획을 공부하기 위해서 가장 중요한 것은 어떤게 있을까 많이 고민도 해보았고, 먼저 기획 업무를 담당하고 있는 선배와 지인들에게 많은 질문을 던졌습니다.
책과 이론을 찾던 저한테 웃기게도 습관이나 관점에 대한 조언들만 돌아오더군요.
첫번째로 '다양한 시각에서 문제를 바라보라' 라는 것이었는데, 듣자마자 머리가 띵- 해지는 느낌이었습니다.
일반적인 개념이나 기획에 대한 정론을 배워야 되지 않나라고 고민한 저에게는 더 큰 혼란을 가지고 왔었는데, 이런 개념적인 부분들은 사실 말로 배우는 것이 거의 불가능한 것을 이미 개발쪽에서 몸소 깨달았던차라 더 버겁게 다가왔습니다.
기획을 하면서 가장 중요한 부분이라고 하는데, 특정 문제에 대해서 일반적인 개념이나 관습에 따라 기획하게 되면 결국 얻게되는 결과가 그 이상을 가지지 못한다는 말이었습니다.
결국 새로운 시각을 통한 아이디어의 싸움이라는 말이었죠.
기획에서 일반적으로 통용되고 누구나 제시할 수 있는 정형화된 것을 가지고 온다면, 그 해결책에 대한 계획은 어느 누구나 생각할 수 있을 법한 것이고 이런 해결방안을 제시하는 기획자는 필요가 없다는 점이죠.
기존의 개념과 완벽한 논리를 따라가던 기획은 이미 시대가 지난 방식이었습니다.
현재의 기획은 완벽한 논리와 타당성을 뛰어넘는 변화하는 트랜드, 사람들의 공감, 상상력이 더 중요해지는 시대가 되었습니다.
그리고 '시작하는데에 있어 완벽하려 하지 마라' 였습니다.
기획자로 이직을 해서 아마 처음 작성해보는 기획서나 보고서의 빈칸과 백지들이 답답하고 벽처럼 느껴질꺼란 말을 하면서 시작하는데에 있어 완벽을 기하지 말라는 말을 가장 많이 들었습니다.
처음 일을 시작할 때 가지는 의욕과 열정이 꼭 좋은 결과를 가지고 올 수 없다고 들었는데, 경험 많은 기획자들 역시 처음 새로이 작성하는 기획서는 논리와 구조, 심지어 문맥까지도 완벽할 수 없다 했었죠.
결과물에 대해서는 완벽을 기하고, 작은 디테일까지 잡아내는 신중함이 필요하지만, 초본을 작성하는데 있어서는 직관적으로 써내려가는 습관을 가지라고 했습니다.
지나와서 생각해보니 천재가 아니고서야 머리속에 있는 내용을 완벽하게 정리한 다음 글로 꺼낼 수 없습니다.
글을 쓰는 것이 직업이 되었고 일정 이상의 분량과 논리와 근거가 바탕이 되는 기획서를 작성하면서, 한 줄이라도 더 많은 생각을들 글로 적어두고 여러번의 검수와 수정을 거친 후에야 완벽을 기할 수 있을 것입니다.
