'2018/05/04'에 해당되는 글 1건

  1. 2018.05.04 Agile 기반의 일하는 방식 혁신 과정 (교육내용 정리) 1/2

교육명 : Agile 기반의 일하는 방식 혁신 과정 

일   자 : 2018.05.02 ~ 05.03 (2일간)

장   소 : 본사 



[1일차 교육 내용]

1. 3 Key-Words Meeting : Ice Breaking 도구

  1) 좋아하는 것, 최근에 배웠던 내용, 현재 나의 관심사 세가지 키워드를 카드에 적음 ( 레포츠, 스키, 드럼)

  2) 1:1 마주하고, 2분안에 자기와 상대의 소개를 진행함. (상대와의 거리는 마주앉은 자리에서 10cm 내외)

  3) 상대를 바꿔가며 ( 한쪽 자리 바꿈) 반복 진행 


  <Point : 집중을 만드는 환경>   

  1. TIME BOX : 2분이라는 시간적 제약 

  2. SHARED GOAL 

  3. TASK 

  4. 환경  - 1:1 , 거리, 음악 (Sound Masking)


2. 강사 소개 : 박진표 

  1) 독일에서 초등학교 졸업

  2) OOD-E 다국적 기업 소속

  3) 취미는 DJing 


   위의 항목중 2개는 진실이고, 1개는 거짓. 


<Point : 진진가> 

 1. 내성법 : 자기자신을 돌아보는 방식   

 2. 빌헤름 분트 : 현대 심리학의 아버지 

   1) 자신의 경험에 대한 주관적인 관찰, 자기의 내부 성찰법, Introspection   



3.  http://www.online-stopwatch.com : 회의시간 체크



4. 관지자 주도 개발 실습 

  1) 2인 1조 ( 1명 개발자, 1명 관리자)

  2) 준비 : 바닥에는 기하학적인 폴리곤이 테이블사이에 연결되어 있음.

  3) 목표 : 2분안에 보폭 60cm 기준으로 60 걸음 가는 것. 

  4) 관리자가 사용할 수 있는 프로토콜 

     ㄱ. 가, 멈춰, 좌로, 우로, 빠르게, 느리게  

  [결과] 10여개 팀중 목표를 달성한 팀은 1개 팀 


5. 자기주도 개발 실습 

  1) 관리자 전원 해고 

  2) 각자의 자율적으로 동일 목표를 실행  

  [결과] 모든 팀 목표 달성 


 

관리자 주도 

자기 주도 

 생산성

높지 않음 

높음 

 품질관리

어려움 

쉬움 

커뮤니케이션 비용

높다 

적다 

멈춤 

발생 

비발생 

개발자 자세 

수동적 

능동적 (프로세스에 대한 고민)

충돌 

자주발생 

자연스런 흐름 

기록

발생 

미발생 

관리자 부담

높음 

감소 

만족도 

낮음 

높음 


<자연스러운 흐름>

1. SHARED GOAL

2. 재량권

3. Fixed TEAM 

4. FEEDBACK - 투명한 정보




6. 부정적인 것, 하지말아야 할 것을 정리하는 것이 더 창의적일 수 있음.



7. 복잡도에 따른 Project 구분 

  

       단순 영역을 제외한 모든 분야에 Agile 적용 가능 

       단순 영역은 Waterfall 방식이 더 효율적임 


8. WaferFall 방식의 한계 

  1) 고객도 요구사항을 잘 모름

  2) 해당 프로젝트의 이해도가 가장 높은 시기는 현재이다.  ( 시간이 지날 수록 점진적으로 높아짐) 

  3) 프로젝트 초기에 모든 것을 예측할 수 없음 

  4) 개발 진행하면서 요구사항이 명확해 지는 것이 많음


   1. 요구사항 변경

   2. 세부사항은 개발 중 명확해짐

   3. 변경사항이 발생할 수 밖에 없음

   4. 오해   ( 고객 - 설계자 > 요구사항 문서 - 개발자 > 코딩 - 프로그램  ) 2번의 추상화 단계 발생

   5. 실수



9. Agile Manifesto (애자일 선언)

   1) 2001년 2월

   2) traditional 방법론 

       ㄱ. 사람은 도구      ㄴ. Know-How 가 중요 

   3) Agile 기법 

       ㄱ. Scrum : frame work

       ㄴ. XP : Extreme Programming 

       ㄷ. kanban : 방법론

       ㄹ. DSDM : Dynamic System Development Method

       ㅁ. FDD ( Feature Driven Development) 

       ㅂ. TDD  (TEST Driven Development)

       ㅅ. Crystal


[애자일 선언] 출처 : http://gyumee.egloos.com/1021784



애자일 선언을 위키백과와 애자일 선언 홈페이지의 내용을 참고하여 번역해 올립니다.


http://en.wikipedia.org/wiki/Agile_Manifesto

http://agilemanifesto.org/


---------------


애자일 선언은 애자일 소프트웨어 개발의 토대를 강화하는 원칙을 발표한 것이다. 초안은 2001년 2월 11일에서 13일까지 유타의 워새치산맥에 있는 스노우버드 스키 리조트 라운지에서 만들어졌다. 여기에서 기존의 무거운 방법론보다 가벼운 대체방법론들의 필요성에 대해 토의하고자 Extreme Programming, Scrum, DSDM, AdaptiveSoftware Development, Crystal, Feature Driven Development, Pragmaticprogramming 같은 다양한 새 방법론의 대표자들이 만났다.


---------------


Manifesto for Agile Software Development

애자일 소프트웨어 개발에 대한 선언


We are uncovering better ways of developing software by doing it and helping others do it.

우리는 소프트웨어를 개발하는 더 나은 방법을, 직접 실천하고 다른 이들을 도우면서 밝혀내고 있다.


Through this work we have come to value:

이 작업을 하는 동안 우리는 다음을 가치있게 여기게 되었다.


Individuals and interactions over processes and tools 

프로세스나 도구에 앞서 개인과 상호 작용을 

Working software over comprehensive documentation

포괄적인 문서화에 앞서 작동하는 소프트웨어를


Customer collaboration over contract negotiation

계약 협상에 앞서 고객과의 협력을 


Responding to change over following a plan

계획 준수에 앞서 변화에 대한 대응을


That is, while there is value in the items on the right, we value the items on the left more.

우리는 왼쪽 항목의 가치를 인정하면서도 오른쪽 항목을 더 중요하게 여긴다.


Kent Beck, Mike Beedle, Arie van Bennekum,

Alistair Cockburn, Ward Cunningham, Martin Fowler,

James Grenning, Jim Highsmith, Andrew Hunt,

Ron Jeffries, Jon Kern, Brian Marick,

Robert C. Martin, Steve Mellor, Ken Schwaber,

Jeff Sutherland, Dave Thomas


-----------------------------------------------------------------------------------

Principles behind the Agile Manifesto

애자일 선언의 배경 원칙들


We follow these principles:

우리는 다음 원칙들을 따른다:


Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

가치있는 소프트웨어를 조기에 그리고 지속적으로 인도해 고객을 만족시키는 것을 가장 우선으로 여긴다.


Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

개발 후반이라고 해도 요구사항의 변경을 환영한다. 애자일 프로세스는 변경을 고객의 경쟁적 우위 요인으로 삼는다.


Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

작동하는 소프트웨어를 수 주에서 수 개월의 주기로 자주, 가능한 더 짧은 기간에 인도한다.


Business people and developers must work together daily throughout the project.

프로젝트 기간 내내 업무 전문가와 개발자가 매일 함께 일해야 한다. 


Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

동기부여된 개인을 중심으로 프로젝트를 구축하라. 그들에게 필요한 환경과 지원을 제공하고 업무를 완수할 것으로 믿어라.


The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

개발팀에게 그리고 팀 내에서 정보를 전파하는 가장 효율적이고도 효과적인 방법은 얼굴을 직접 보고 대화하는 것이다.


Working software is the primary measure of progress. 

작동하는 소프트웨어가 진도를 측정하는 제 1 척도이다.


Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 

애자일 프로세스는 지속할 수 있는 개발을 장려한다. 후원자들과 개발자들과 사용자들은 일정한 보폭을 끝까지 유지할 수 있어야 한다.


Continuous attention to technical excellence and good design enhances agility.

기술적 탁월함과 좋은 설계에 대한 끊임없는 관심은 기민성을 강화한다.


Simplicity--the art of maximizing the amount of work not done--is essential.

단순함, 안 해도 되는 일은 최대한 안 하게 하는 기교, 이것이 핵심이다. 


The best architectures, requirements, and designs emerge from self-organizing teams.

최고의 아키텍쳐와 요구사항과 설계는 자기 조직화된 팀에서 나온다.


At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

팀은 정기적으로 더 효과적으로 일할 수 있는 방법을 숙고하고 그에 따라 자신의 행동을 조율하고 수정한다.


--------


2009/3/11 : Toby님의 지적에 따라 잘못된 번역을 수정하고 몇몇 문장을 손 봤습니다.

2009/4/2 : 문서가 망가져서 일부 다시 번역했습니다.

2010/11/23: 번역을 다듬고 오역을 수정함



10. 경험주의적 접근 

  " 경험을 통해 지속적으로 결정을 내리고, 

    개선을 통해 더 나은 가치를 전달한다." 

  결점 : 큰 그림을 보기 어렵다. 



11. FAT BUGGER 사례 

  1) 15$ 햄버거를 7$를 가지고 와서 주문

  2) 알바생 임의대로 제품을 만들어 판매  -> 사망

    

  1. 의사결정은 고객일 할 수 있도록 정보를 전달한다. 

  2. 고객의 요구에 대한 리스크 및 영향도를 고객이 알 수 있도록 한다.  

  

  3) 10% 실명 위기를 갖고 있는 시력 수술의 경우에도 실패율을 사전에 공지 받았던 환자들의 경우에는

      실패한다 해도 의사에 대한 원망이 상대적으로 크지 않을 것임.



12. Agile과 Scrum은 개발자들의 높은 Craftsman Ship을 요구한다. 


13. Scrum 실습 :  공돌리기 

   1) Rule

     ㄱ. 공은 모든 구성원의 손에 닿아야 함.

     ㄴ. 바로 옆 구성원의 구성원에게는 전달할 수 없음

     ㄷ. 공을 전달할 때는 반드시 누구에게도 닿지 않는 시간이 있어야 함.

   2) 목표 : 정해진 시간(2분)내에 최대한 많은 갯수를 진행함

   3) 총 5회, 매 횟수마다 1분의 협의시간을 통해 개선점을 찾는다. 

   4) 다름 표에 기록


 횟수

추정

실행 

개선사항 

 1


 

 

 2

 

 

 

 3

 

 

 

 4

 

 

 

 5

 

 

 


 <게임과 SCRUM 비교>

구분

게임

SCRUM 

 계획

 추정하기

 sprint planning

 실행

 2분게임 

 sprint

 학습

 1분 협의

 Review & Retrospect

 DSM (Daily Scrum Meeting)

  




14. What is SCRUM !















Posted by 꿈을펼쳐라
,