<🤷‍♂️가짜 애자일을 만드는 7가지 방법> 정말 많은 기업에서 <애자일 방법론>으로 개발을 하고 있습니다. 허나 주변에 개발자에게 애자일로 개발하냐고 물어보면 <애자일인 척>은 한다고 합니다. 왜 그럴까요? 이 기사를 통해 우리가 하고 있는 애자일이 <가짜 애자일>인지 아닌지 확인해보시는거 어떤가요? <📰기사 요약> 애자일을 향해 많은 기업들이 변화하고 있다. 그러나 당신은 애자일로 변화가 싫거나 불편할 수 있다. 여기에 애자일로의 변화를 실패하게 만드는 7가지 방법이 있다. ❌무계획으로 만들고, 애자일이라 부를 것 - 팀원 전원이 매일 아침 모여 '그날 할일'을 만들어내라. 그리고 '애자일 방식'이라고 이야기하라. - 기능을 테스트할 준비가 되면, '내일 당장' 써야한다고, '오늘' 제품 소유자(PO)에게 이야기하라. 안되면 다음 스프린트로 미루자. - PO가 일정이 지켜지지 않는다고 이야기하면, "애자일은 원래 일정이 없다"고 해명하라. ❌아키텍처를 무시할 것 - 프로젝트 초반에 아키텍처를 정의하느라 시간을 쏟지마라, 애자일은 지속적인 진화를 추구하니 아키텍처도 지속적으로 진화하는게 맞지 않는가? - 개발자에게 힘을 실어 본인이 원하는 방식으로 마음껏 개발하게 내버려둬라. 작성하는 개발자마다 의존하는 라이브러리가 다르더라도 괜찮다. 우리에겐 "리팩토링"이 있다. ❌어차피 답은 스크럼 - 애자일 방법론 중에 제일 인기있는건 스크럼이다. 당신의 프로젝트가 어떤 성향을 갖고 있건 상관없이 스크럼을 하자고 주장하라. - 스크럼을 통해 프로젝트가 실패하더라도, 당신 잘못이 아니다. 애초에 "애자일이 잘못 됐다"라고 주장하라. 이는 당신을 보호해줄 것이다. ❌워터폴에서 SAFe(확장 애자일 프레임워크)까지 한걸음에 뛰어넘을 것 - 애자일의 강점은 단순함이고, 약점은 확장이 어렵다는 것을 이야기하라. - 이 약점을 이용해, SAFe를 바로 도입하라. 실제로 SAFe는 지독하게 복잡하다. 움직이지 않는 부분과 잠재적인 실패 지점, 미래에 관한 가정이 워터폴만큼 많은데다가 익숙하지도 않을 것이다. 또한 숙련된 실무자와 꽤 많은 프로그램이 필요하다. - 준비없이 시행된 SAFe는 당연히 실패한다. 하지만 프로그램은 실패해도, 여러분의 손은 깨끗할 것이다. 애자일이 확장되지 않는다고 경고했기 때문이다. ❌ 개발 협력업체의 애자일 사용과 고정 입찰가 합의를 고집할 것 - 우리가 애자일을 쓰는데, 협력업체도 사용해야 한다고 고집해라. - 업체 입찰가는 고정해야한다. 협력 업체가 애자일을 쓴다고 프로젝트 예산과 일정에서 슬쩍 벗어나려는 삐딱한 마음이 들 수 있기 때문에 ❌ 역외 애자일(Offshore agile) - 가능하면 개발자의 비용을 줄이기 위해 지구 반대편정도 떨어진 곳에 있는 팀을 고용해라. - 애자일이 대면 대화를 중시하지만, 우린 사업가다. 비용을 절약해야한다. - 해당 팀이 만든 모듈이 엉뚱한 과녁이여도 괜찮다. 비용은 훨씬 적을 것이며, IT에서는 '회사'가 요건에 관해 명확하지 않았다는 식으로 얼버무리면된다. ❌ 프로세스를 가장 중요시 할 것 - 애자일 선언에 프로세스와 도구보다는 개인과의 소통이 중요하다고 써있다. - 하지만, 우리가 수십년간 배워온 것이 있다면 사업의 성공은 잘 규정된 반복 가능한 프로세스에 있다는 것이다. - 성공의 원천은 지시대로 한단계씩 프로세스를 잘 따르는 직원들이다. 그러니 프로세스를 중시하고, 이를 따르게 하라. <📕코멘트> 하나하나가 정말 절대 일어나서는 안되는 전략이지만, 주변에서 이런 행동을 하는 사람을 생각보다 흔히 볼 수 있습니다. 제 주변에 지인 중 한명은 팀에서 갑자기 애자일을 도입한다고 하면서 "기획서"를 없애고, 피쳐를 만들어달라고 구두로 논의했다고 합니다. 빌드를 통해 눈으로 보면서 개발 해야한다고 말이죠. 제가 본 애자일에 있던 "포괄적인 문서보다 작동하는 소프트웨어"를 잘못 해석한 예였습니다. 생각보다 주변에 애자일이 만능 열쇠라고 생각하는 분뿐만 아니라, 가짜 애자일을 경험하시고, 애자일에 대해 반감을 가지신분이 많습니다. 그럴때 저는 개발 방법론은 프로덕트를 위한 전략이고, 이 또한 매우 중요하지만 '명확한 비전'이 더 중요하다고 주장합니다. 왜(Why)이 프로젝트를 해야하는지 팀 모두가 알고 있다면, 어떤 방법론을 사용하던 좋은 프로덕트가 나오지 않을까요?