너무 자극적인 제목 이였나요? ㅎㅎ
공감가는 부분이 많던 동영상인데 요지는 리더의 중요성인거 같네요.
재미있게 본 영상인데 알고보니 대단한 분이시네요 어우...
너무 자극적인 제목 이였나요? ㅎㅎ
공감가는 부분이 많던 동영상인데 요지는 리더의 중요성인거 같네요.
재미있게 본 영상인데 알고보니 대단한 분이시네요 어우...
[스팀한당] [개발한당] [스팀한당]: PC 게임 소모임 https://www.clien.net/service/board/cm_steam [개발한당]: https://www.clien.net/service/board/cm_app
동영상 포프 님이시죠? 약간 다르게 생각 하시는건 아닌가 하네요~~
제가 아는 애자일의 핵심은 릴리즈 시기등을 대부분의 구성원이 결정할 수 있어야 한다로 알고 있어요. 그런데 대부분은 그렇게 할 수 없죠. 그런 문화가 아니었으니깐요. 그 기존 문화에 맞춰 생각하면 애자일을 다르게 이해하게 된다고 생각합니다.
그래도 확실히 프로젝트마다 방법이 다른건 사실인 듯 합니다~ 개임 개발은 파이프라인이 확실해서 워터폴이 맞을 수 있죠. 하지만 프리 프로덕션에선 다양한 요구를 시도 해 볼 수 없기 때문에, 워터폴 역시 문제를 가지고 있고요. 뭐 라이브 중에도 첫 단추 잘못 끼우고 그냥 계속 진행하기도 하구요. 폭포는 다시 거슬러 오를 수 없으니... 중요한건 ‘구성원이 누구인가. 그 구성원이 일을 스스로 결정할 수 있는 권한과 훈련이 되어 있는가’가 동영상 말 처럼 맞는 것 같습니다. 그리고 팀이 어떤 상태에 놓여있는거 등이요... 하지만 헛소리로 치부할 건 아닌것 같아요.
성당과 시장이 있으니깐요.
개발 리드가 완벽하면 다 해결된다는 것 또한 굉장히 이상적인 얘기라서, 스크럼이 별로야 그러니 완벽한 리더가 있으면 된다라는게 무슨 의미가 있는지 잘 모르겠습니다 ㅎㅎ 이게 개발 프로세스 잡는 것보다 더 어렵습니다. 개발 프로세스라는게 그런 리더들의 성공 사례를 모아서 만든게 프로세스인데 프로세스가 의미없다고 하면 으잉? 하게 되는거죠. 그런 리더를 채용하기 힘드니까 이 프로세스라도 따라해서 생산성을 좀 유지해보자는거지 이 프로세스를 따라하면 너흰 세계최고가 될꺼야라는 프로세스는 없으니까요.
프로세스는 무형자산 같은거라서 어느 조직이든 존재하고 있습니다. 표준 프로세스는 기존 프로세스의 생산성을 높이기 위한 가이드라인이지 정답이 아니죠. 근데 이걸 정답이라고 오해하시고 이렇게 얘기하시는 부분은 좀.. ㅎㅎ 잘못된 정보를 제공하는 영상 같아서 안타깝네요. 아직 잘 모르는 주니어급 친구들이 보면 안될 영상같군요.
애자일만 입에 붙은 사람을 본 적이 있는데
자기가 아는 내용이 적은데 상대방을 불신하면서 압박을 가하는데 사용하는 경우였더군요.
방법론은 개발리더의 스타일에도 따라서도 다른 것 같습니다.
마치 축구 전략처럼 각자 맞는 옷을 찾아서 입듯, 개발방법론도
현재 멤버의 구성과 회사내 정치역학에 맞게 구성하는 것도 중요하죠.
개발 방법론은 다른 댓글에도 언급된 것처럼 각각 장단점을 가집니다. 조직이 만들어지고 방법론을 결정할 때는 기존에 있는 방법론을 베이스로 하고 우리 조직에 맞는 형태로 조금씩 변형을 하여야 합니다. 모든 조건이 같지 않은데 문법을 따르듯이 그대로 맹신한다면 당연히 잘 되지 않을 것이고 그렇다고 처음부터 방법론은 우리가 만든다고 했을 때 뭐부터 할 수 있을까요?
방법론도 일종의 문화이며 이 문화는 만들고자 하는 의도대로 바로 만들어지지 않고 녹아나는 것입니다.
그냥 치부할 것은 아닌 듯해서 말씀드립니다.
저도 저 영상에 100% 공감하는 것은 아니나,
볼만한 가치와 경험이 담겨져 있는 것 같습니다.
일단, 어떤 개발 프로세스든 당연히 그 프로세스를 운영하는 리더가 그것을 제대로 이해하고 실행할 수 있는 역량이 있어야 합니다. 왜 이것이 "개발 프로세스 헛소리좀 그만" 이라는 제목과 연관이 있는지 모르겠네요.. (NO)프로세스 환경에서도 리더가 바보면 프로젝트는 망하죠.
두번째, 작은 프로젝트에는 오히려 "워터폴"이 더 적합하다는 주장은 설득력이 떨어지네요. 프로세스 도입에 영향을 미치는 주는 프로젝트의 크기라기 보다는 프로젝트의 결과를 기대하는 Stakeholder들의 관점이 어떠한가 입니다. 아무리 작은 프로젝트라 하더라도 그것을 지시하고 결과를 평가하는 측에서 수시로 요구사항을 변경하거나, 심지어 무엇을 원하는지 조차 모르는 상황이면 "워터폴" 방식 보다는 "애자일"이 더 나은 접근이라 생각합니다.
세번째, 좀 어려운 부분이긴 한데.. 스크럼은 기본적으로 Self-Estimation을 전제로 합니다. 즉, 초반에는 구성원들이 스스로의 Speed를 잘 파악하지 못해서 예상계획이 어긋나는 일이 많죠. 하지만 짧은 주기의 구체적인 목표에 대한 Self-Estimation을 반복하는 과정에서 자신의 Speed를 이해하기 되고 프로젝트 중후반부를 지나면서 점점 예측가능해지게 됩니다. 다시 말해, 프로젝트 리더가 어떤 것을 언제까지 하라고 지시하는 게 아니고, 구성원들이 능동적으로 일의 양과 우선순위, 소요시간을 결정하는게 핵심입니다. 물론, 이것 또한 프로젝트 리더의 매니징 역량을 전제합니다만... ㅎㅎ
제 개인적인 견해는, 적어도 저 시점에서의 포프님은 누구나 한번쯤 거쳐가는 프로세스 무용론 상태에 빠지신게 아닌가 조심스레 짐작해봅니다. 어떤 개기로 인해 빡치신거죠 ^^;;
프로세스를 제대로 적용하는 것은 굉장히 어려운 일입니다. 개발이라기 보다는 관리의 영역이며, 사람과의 관계 영역입니다. 개발과는 전혀다른 영역의 문제죠.
관련해서, 좋은 글을 많이 써 주신 제럴드 와인버그님의,
"프로그래밍 심리학",
"테크니컬 리더"
이 두 책을 추천하고 싶네요.
아, 중요한 거 하나 더,
그래서 어설프게 "우리도 한번 해볼까?" 하는 식으로의 접근은 프로세스라는 것에 대한 부정적 인식을 가지는 결과만 초래하니 주의해야 합니다.
일을 해내는 사람과 하느냐와
핑계를 만다는 사람과 일하느냐의 차이로 나눠지더군요.
그 부수적인 결과물로 일 잘하는 경우를 관찰해서 나온 것들이 방법론이겠죠.
반드시 결과물이 원인을 다 설명하지는 않으니까요.
중간관리자만 좀 편해짐...ㅋ
각자 칸반에 업무 추가하고 플랜을 하면
시각화되어 스프린트 기간동안 심리적 압박이 느껴집니다.
달성하지못하면 티가나니까요.
그래서 보수적으로 플래닝을 하게되더군요.
중간관리자는 팀원 업무가 시각화되어 정리하기 편하고요.
애자일 코치같은 쓸데없는 인력만 추가된 느낌.
애자일 코치는 어떻게하면 할수 있는지 알아보기도 했습니다. ㅋㅋ
너무 편해보여서요.ㅎㅎ
결론 진짜 리더가 중요하다.
프로세스는 도구일뿐 쓰는넘이 잘해야함.