Page History
...
모델을 만드는 단계에 참석을 시키는, 개발문화의 변화와 성숙에 대한 도전 과제로이야기가 이어집니다.
DDD가 단순하게 개발자만해서 개발팀만 해서 되는것은 아니고, 비즈니스를 잘아는 정확하게는 도메인전문가인도메인전문가
대표님/사업/영업 책임등을 개발초기단계에 참석 시켜야한다란 컨셉이기때문에 가장 얇고 가벼운책을
사비를 털어 기획/개발자 포함 20권을 배포한적이 있습니다.
지금 생각해보면 관심도 없는 특정 지식을 책을 통해 강요를 당한것처럼 느낄수 있기때문에 이제는 하지못하는 활동중에 하나이지만
좋은의도가 어딘가에 전파되고 미비하게 작동하고 있기도 하기때문에 개인적으로는 만족했던 활동입니다.
DDD를 하기위해서는 애자일이 필요하다. 애자일이 좋은 소프트웨어를 만들기위한 가치와 마음가짐을 포함
/사용자 모두를 개발 초기 단계에 참여를 시키는것을 권장합니다.
DDD를 하기위해서는 애자일이 필요하다. 애자일이 좋은 소프트웨어를 만들기위한 가치와 마음가짐을 이야기한다고 하면
DDD는 그것을 실천하기위한 구체적인 전략/전술을 이야기하며 방법론을 이야기한다고 하면 DDD는 그것을 실천하기위한 구체적인 전략/전술을 이야기하며 애자일의 코어영역과 상당수 일치한다.
...
- 구성원들이 일을 지금보다 빨리해서 결과물이 빨리나오길 기대하면, 그것은 애자일이 아니라 스피드이다. 팀이 지시를 받아 수동적으로 움직이는게 아니라 권한을 위임받아 주변 환경 변화에 스스로 민첩하게 대응할수 있게만드는것이 애자일이다. 사실은 변화에 대응하여 우리의 프로덕트가 살아남을수 있을까? 생존과 관련된것이다.
- 선거제도(애자일 프랙티스)만 있다고 민주주의 국가가 아니지만, 애자일 프렉티스를 작게 수행하다보면 애자일이 어디쯤 있는가? 가늠은 할수 있다.
- 애자일 마인드셋과 환경제공을 하는것 'Being Agile'은 탑다운에서, 실천하는 'Doing Agile' 은 바텀업을통해 균형을 이루어질때 작동된다.
- 애자일을 하면서 생기는 문제가 애자일때문이 아닐수 있다. 원래 드러나지 않았던 고약한 문제이며 애자일을 통해 발견할 가능성이 더 크다.
- 애자일에 숙련되기전 애자일을 위한 조직변경은 추천되지 않는다.애자일을 하면서 성숙도가 어떠한 조직이이던 성숙도가 생기면 스스로 팀이 어떻게 구성되야 효율적일지 생각하게된다. 좋은 애자일팀은 좋은팀은 자주 변경이되는것이 아니라 오래 지속된다. 우리가 경계해야 할것은 팀이 아무런 성장도없는 변화없는 그 자체이다.
애자일과 애자일과 수평
수평적 개발문화를 이해하기위해 애자일의 선언을 다시 살펴보자
- 공정과 도구보다 개인과 상호작용을
- 계획을 따르기보다 변화에 대응하기
- 포괄적인 문서보다 작동하는 소프트웨어를
애자일 마인드셋과 환경제공을 하는것 하는것은 'Being Agile'은 탑다운에서, 탑다운에서 그것을 실천하는 'Doing Agile' 은 바텀업을통해 균형을 이루어질때 작동된다작동됩니다.
수직과 수평개발문화 많은 논란이 있고 아직고 정의되고 있지만, 애자일과 상관없이 그 둘의 균형을 위해 노력하는것 자체를 수평이라고 정의를 내리고 싶습니다.
Beging Agile 은 회사 또는 기존 관리자급에서 고찰을 해야하는 내용입니다.
애자일의 시작은 사실, 실무자뿐만 아니라 권한과 책임을 나눌수 있는 분위기및 함께 학습하는 분위형성이 중요합니다.
전통적인 워터폴에서 사용되었던 관리방식이 완전하게 바뀌어야함을 의미하고 생각보다 많은 변화와 큰 비용이 들수 있습니다.
가령 다음과 같은 고민입니다.
"계획과 기획이 완료되어야, 완료되고 변경이 없어야 착수 가능한 개발팀에서 필요한것은 무엇이 필요할까개발방법론에서 , 우리에게 필요한것은 무엇일까요?"
Doing Agile은 Agile은 기존 실무자가 고찰해야하는 내용입니다.
수평적 개발절차를 워라벨(칼퇴보장/워터폴 보다 스트레스가 적은/수평으로인한 편안함)로 생각하면 오해입니다.
오히려 애자일을 너무 열심히 해서 프로덕트를 런칭시킨팀에서 번아웃이 발생할수 있습니다.
수평은 가만히 있어서 유지할수 있는 상태가 아니라, 연필을 손바닥에 세워 떨어트리지 않으려고 계속 균형을 맞추는
사실은 모두의 구성원이 능동적이고 적극적으로 프로젝트에 참여하고 책임을 분산하는 밸런스 게임이며 구성원이 적극적이지 않고 움직이지 않으면 그 수평은 유지될수 없습니다.
>실리콘밸리의 애자일은, 움직이지 않는다고 판단되면 다음 스프린트에 제외되는 사실은 무서운 수평게임입니다.
다음은 인터뷰때 많이 많이 듣는 이야기중 하나입니다사례는 팀을 운영하는 리더였을때 , 수평과 관련한 인터뷰내용중 FAQ를 요약하였습니다.
"수평적 개발문화를 희망합니다, 개발문화가 좋은것 같습니다만~ 제 사수는 어디있나요?" , "프로세스가 없는것 같아요?", "저는 주니어이기때문에 설계에 자신없습니다."
- 여기서 사수는 군용어로 가장 수직적 단어입니다.
수평적 개발문화는 평등,복지를 의미하는것이 아닙니다. 상위에서만 알고 결정하던 정보를 공유하고, 위임을 통해 결정과 책임을 나누는것에 가깝습니다.
- 코칭을 해줄 시니어가 존재하지만 당신의 성장을 책임 지지는 않습니다. 그러나 모두의 성장을 위해 함께 노력할수 있는 팀을 빌딩할것입니다.
"프로세스가 없는것 같아요?"
- 공정과 도구보다 개인과 상호작용을 더 중요하게 생각하며 이해와 상호작용을 조금씩 변화에 기여해주십시오, 좋은 개발문화가 정착될수 있도록 환경적 지원을 해드리겠습니다. 상호작용을 통해 변화하는 것이 우리의 가치이며 우리가 워터폴의 한계를 극복하려는 지난 노력들은 아직 완성되지 못했습니다.
"저는 주니어(3년차)이기 때문에 설계에 자신 없으며 이것은 팀리더의 역할또는 책임인것같습니다."
프로세스는 공정과 도구를 이용하는 방법일수 있습니다. 애자일의 정신중, 공정과 도구보다 개인과 상호작용을 - 애자일을 따라할필요는 없지만 애자일의 정신은 참고할수 있습니다. 개인과 상호작용을 통해 우리는 도구를 포함 프로세스를 함께 만들수 있습니다.
- 설계자와 구현자가 따로있는것은 실천적 해결방법에 멀어질수 있으며, 워터폴을 이해한다고 하면 워터폴의 절차속에 단순하게 코더 역할을 하는것입니다. 우리모두는 아마추어가 아닌 프로가 되어야하며 리더가 이 부분에 도움을 줄수 있지만 모두 대신할수는 없습니다. 프로세스보다는 그 공정에 설계가 없는것에 그리고 그것에 참여를 못하는것에 대한 문제를 저에게 주십시오 필요하면 함께 참여해서 어려운 문제를 같이 풀어갈수 있습니다
Task가 없이 진행되는것이 문제가 될수 있지만 Task의 가치를 아는것이 더 중요합니다. Task의 일정준수도 중요하지만, 프로세스가 없는것보다 설계가 없었던것에 더 고민을 해야합니다. 설계는 잘 드러나지 않는 중요한 활동이며 시니어가 이것에 도움을 줄수 있지만 설계를 하지 않는 개발자는 코더가 될 가능성이 높습니다. 모두가 이해하고 참여할수 있는것이 프로세스가 될수 있으며 개발문화가 될수 있습니다. 팀장이 모든것을 결정하고 책임지고 분배하는것은 수직적 절차에 가깝습니다
- .
기존방식의 변화
...
기획 - UI/UX는 디자이너에게 맡기세요
...