The Beginning of Collaboration

TIP

좋은 팀은 좋은 제품을 만든다 - 선릉역호랭이들의 일하는 방식

STEP 1 - kanban

매일 매일 서로 도움을 주고 받기 - Daily Meeting
- 칸반 미팅 통해여 서로의 작업 공유 - 09:15
- 서로 도와 재밋고 효율적 방법 찾기
- 타이거팀에서는 책임을 공유하기 때문에 좋든 나쁘든 그 성과는 어떤 개인이 아니라 팀 전체의 것
- 매일 같은 시간, 같은 장소에서 협업에 필요한 최신 정보들을 공유

. /\_/ヽ
/ _ノ ヽ_ \
|  ━  ━ i
\ミ (_人_) 彡
 / ̄ ̄⌒\/⌒)――――
. /    _/ 
. |   \
 \ 〇_  \
  \ノ.\_ノ

    1. 어떤 일을 끝마쳤는지
    1. 어떤 일을 진행할 예정인지
    1. 그리고 업무에 지장을 줄 수 있는 요소가 무엇이고 - 힐러와 히어로를 찾기 kanban-guideopen in new windowygwg

STEP 2 - create branch

$ pwd
~/code/oss-cashmallow.github.io

$ git pull

$ git describe --tags
v0.9.6

$ git branch v0.9.7/how2write-code-with-PR
$ git checkout v0.9.7/how2write-code-with-PR

# 버전 규칙은 https://semver.org/ 를 따름ㅎ
$ git branch --show-current
v0.9.7/how2write-code-with-PR

STEP 3 - writing todo

$ perl -p -i -e '$.==3 and print "### 0.9.7\n- [ ] The Beginning of Collaboration\n\n"' ChangeLog.md

$ head -n 5 ChangeLog.md
# ChangeLog

### 0.9.7
- [ ] The Beginning of Collaboration

STEP 4 - create PR to signal the start of coding

$ git add .

$ git status
현재 브랜치 v0.9.7/how2write-code-with-PR
커밋할 변경 사항:
	수정함:        ChangeLog.md

$ git commit -m "start write - tiger coding 101"

$ git push --set-upstream origin v0.9.7/how2write-code-with-PR
remote: Create a pull request for 'v0.9.7/how2write-code-with-PR' on GitHub by visiting:
remote:      https://github.com/oss-cashmallow/oss-cashmallow.github.io/pull/new/v0.9.7/how2write-code-with-PR

STEP 5 - art coding and testing

개발의 시작과 끝은 테스트입니다.
.  ∧,,∧
∩(^ 0 ^)∩
ヽ   ノ
 .|  |
  U⌒U.

STEP 6 - code review

개발자가 마스터가 되어가는 긴 여정
애자일 선언문 (Agile Manifesto)

우리는 스스로 소프트웨어를 개발하고, 
다른 사람들이 개발하는 것을 도와주면서
더 나은 소프트웨어 개발 방법들을 찾고 있다.

이 과정에서 우리는 다음과 같은 가치를 중요하게 생각한다.

1. 절차와 도구보다는 개성과 화합을 - Individuals and interactions over processes and tools
2. 방대한 문서 작업보다는 동작하는 소프트웨어를 - Working software over comprehensive documentation
3. 계약 조건에 대한 협상보다는 고객과의 협업을 - Customer collaboration over contract negotiation
4. 계획을 따르는 것을 넘어서서 변화에 대처하는 것을 - Responding to change over following a plan
더 가치있게 여긴다.

좌측의 사항도 가치가 있음을 인정하지만
우리는 우측의 사항에 더 높은 가치를 둔다는 것이다.
.                   ∧,, ∧
                   (`・ω・´)
                     U θ U
                 / ̄ ̄Ⅰ ̄ ̄\
                |二二二二二二二|
                |        |
찰칵  찰칵  찰칵  찰칵  찰칵  찰칵  찰칵  찰칵  찰칵
   찰칵  찰칵  찰칵  찰칵  찰칵  찰칵  찰칵  찰칵  찰칵
 ∧_∧      ∧_∧     ∧_∧  ∧_∧    ∧_∧     ∧_∧
 (   )】      (   )】    (   )】 【(   )    【(   )    【(   )
 /  /┘ .   /  /┘.    /  /┘ └\ \   └\ \   └\ \
ノ ̄ゝ     ノ ̄ゝ      ノ ̄ゝ     ノ ̄ゝ    ノ ̄ゝ     ノ ̄ゝ

STEP 7 - deploy STG & UAT

User Acceptance Testing . 사용자 수락 테스트
Agile Team Tiger@cashmallow 는
개발자 모두가 "비즈니스 요구사항에 익숙한" 사용자를 추구하며
이를 통해 SIT & UAT 를 작은 스프린트 단위로 함께 진행
가능한 빠른 결함 찾기를 추가 - 낭비와 비용의 최적화 달성
  • 개발자 : Development -> Unit Test -> Code Review
  • 개발팀 : SIT(System Intergration Testing)

  • 모두가 : UAT(User Acceptance Testing / 사용자 수락 테스트)
- 비즈니스 요구사항에 대해 sw를 검증
- 이 유효성 검사는 비즈니스 요구사항에 익숙한 최종 사용자가 수행
- 소프트웨어가 출시되기 전 수행되는 마지막 테스트
- 시장용 소프트웨어를 출시하기 전
- 모든 비즈니스 요구사항(TC)이 충족되었는지 여부를 확인

STEP 8 - deploy PRD

팀은 새 기능을 적기에 출시하고 사용자에게 신뢰성을 보장
  • SRE를 활용하는 팀은 새 기능을 적기에 출시하고 사용자에게 신뢰성을 보장
.    ∩  ∩
   / |/ /
  /   /
⊂二     二⊃
 ( 、σ, )& SRE~
  V"V

STEP 9 - 애자일 회고

업무를 민주적이고 객관적 시작으로 돌아보기
  • 회고 진행 방식open in new windowAglie Big Thing
  • 팀이 정기적으로 만나 이터레이션 기간 동안 무슨 일이 있었는지,
  • 그리고 자신들이 일하는 방식은 어떠한지 돌아보고
  • 무엇을 개선하면 좋을지 논의하는 자리
Last Updated: