제 이름은 Russ Martin이고 저는 다음을 사용하고 있습니다. Mendix Erie Insurance에서 수석 소프트웨어 엔지니어로 거의 3년 동안 일했습니다. 우리는 Mendix 여러 프로젝트를 완료하기 위한 플랫폼을 구축했으며 매우 성공적이었습니다. 폭포에서 초점을 옮기려고 시도하면서 겪었던 시련과 고난을 공유하고 싶습니다. 애자일 프로젝트 방법론, 그리고 이를 극복하기 위한 몇 가지 팁을 소개합니다.

워터폴 팀에 Agile 소개

처음 소개할 때 상상할 수 있듯이 애자일의 개념, 폭포수 팀에서 처음에는 주저하고 우려할 것입니다. 이는 많은 사람에게 변화가 어려운 만큼, 특히 매우 다른 것으로 전환할 때 예상할 수 있는 일입니다. 우리가 발견한 두 가지 가장 큰 장애물은 반복적 개발 개념과 지속적인 요구 사항을 도입하는 것이었습니다.

많은 폭포수 조직에서 공통적인 추세는 개발을 시작하기 전에 전체 프로젝트를 설계하고 배치하는 것입니다. 폭포수에 익숙하다면 팀이 코드 작업을 시작하기 전에 몇 달 동안 요구 사항을 수집하고 설계 세션을 거쳐야 한다는 것을 알 것입니다. 또한 전체 팀이 이러한 세션에 참여하지 않고 지식 전달이 필요하기 때문에 분야 간의 단절이 발생합니다. 이 프로세스는 상당한 오버헤드를 생성하고 시간이 많이 걸립니다. 애자일 프로세스는 폭포수와 비교하면 완전히 180도 다릅니다. 사람들의 사고방식을 이전의 모든 교육과 경험에 반하는 방향으로 바꾸려고 할 때 우려가 있을 것입니다. 이는 정상적이고 예상되는 일입니다.

애자일 프로세스는 워터폴과 비교하면 완전히 180도 다릅니다. 이 변화에 대한 우려는 예상됩니다. 심지어 정상적입니다.

이를 극복하기 위해 저는 애자일 방법론의 이점을 보여주는 것이 사람들이 그 가치를 보는 데 도움이 된다는 것을 알게 되었습니다. 작은 개념 증명부터 시작하세요. 애플리케이션의 작은 부분 또는 대체하는 데 상당한 시간이 걸릴 것으로 예상되는 부분을 선택하여 몇 주 안에 무엇을 이룰 수 있는지 살펴보세요. 비즈니스 분석가, 소프트웨어 엔지니어, 품질 보증 등 다양한 분야에서 최소 한 명 이상의 사람을 참여시키세요. 그 이유는 이러한 유형의 변화에 ​​영향을 미치려면 서로 다른 관점을 가진 사람들이 필요하기 때문입니다. 여러 사람이 새로운 방법론을 이해하게 하면 나머지 조직을 참여시키기가 훨씬 쉽습니다. 또한 Mendix 팀. 그들은 이런 유형의 문화 변화를 다루는 데 경험이 있습니다. 질문에 답하는 데 도움을 줄 외부인을 두는 것은 채택을 촉진하는 데 도움이 되는 추가적인 이해의 층을 제공하는 것입니다.

이 개념 증명의 핵심은 팀워크입니다! 여러분은 확실히 힘든 싸움을 겪을 것입니다. 여러분의 팀은 스프린트 제로 연습에 참여해야 합니다. 여기서 그들은 사용자 인터페이스에서 보고 싶은 것을 결정하기 위해 몇 가지 스토리를 모을 것입니다. 팀의 모든 구성원을 참여시키면 결과에 더 많이 투자하게 될 것입니다. 그들은 프로세스에 대한 의견을 표명할 수 있다고 느낄 것입니다. 이것이 장기적으로 얼마나 중요한지 강조할 수 없습니다. 문서 중심 프로세스에서 스토리 카드 접근 방식으로 전환하는 것은 폭포수 방법론을 실천하는 많은 사람들에게 생소한 개념입니다. 팀원들의 반발에 대비하세요. 이는 정상적인 일입니다. 이 개념 증명은 실험, 즉 훈련 연습에 가깝다는 것을 기억하세요. 프로덕션으로 갈 본격적인 프로젝트가 아니기 때문에 많은 회의론자들의 우려를 완화하는 데 도움이 됩니다. 개발자 관점에서 기억하세요. 이것이 장기적으로 사용할 프로젝트라면 이것은 전체 프로젝트의 기반을 마련하고 미래에 시간을 절약할 수 있는 기회입니다.

대부분 사람들은 시작하기도 전에 과도하게 설계합니다. 메르세데스 벤츠로 업그레이드하기 전에 포드를 만드세요.

우리가 하려는 것을 강조하는 데 사용한 한 가지 개념은 다음과 같습니다. "A 지점에서 B 지점으로 이동하기 위해 메르세데스 벤츠가 필요한 것은 아닙니다. 그저 그곳에 도착하기만 하면 됩니다. 그러니 포드를 개발해 봅시다. 그런 다음 도로에 나서면 차량에 원하는 업그레이드에 집중할 수 있습니다." 이것은 유용한 개념이었습니다. 대부분의 사람들이 완성된 제품을 원하기 때문입니다. 그들은 시작하기도 전에 과도한 디자인을 원합니다. 더 작은 규모로 시작하면 개발자가 작업을 완료하는 최소 실행 가능 제품인 "핀토"를 개발할 수 있습니다. 그런 다음 차량을 기능이 향상된 본격적인 제품인 "캐딜락"으로 얼마나 빨리 업그레이드할 수 있는지 보여주세요. 이를 통해 사용자가 핀토에 들어가 피드백을 제공할 수 있으며, 그런 다음 새로운 기능을 개발하는 것이 얼마나 쉬운지 보여줄 수 있습니다.

프로젝트 작업으로 전환

개념 증명이 순조롭게 진행되고 이제 전체 프로젝트에 대한 승인이 내려졌다고 가정하면, 전환을 원활하게 진행하기 위해 프로젝트에 통합할 수 있는 몇 가지 항목을 살펴볼 수 있습니다.

비즈니스 분석가 및 품질 보증 관점에서 이해 과정을 더욱 활성화하기 위해 활용할 수 있는 몇 가지 사항이 있습니다. 우리는 처음에 "아미고 세션"이 매우 도움이 된다는 것을 발견했습니다. 아미고 세션은 개발자, 분석가 및 테스터가 특정 스프린트에 할당된 카드를 검토하기 위해 즉석 회의를 갖는 것입니다. 이를 통해 모든 참가자가 각 카드에 대해 개발 중인 내용에 대해 동일한 페이지에 있게 되고 작업에 대한 구체적인 질문을 할 수 있는 기회를 제공합니다. 이러한 회의는 비공식적이어야 하며 개발 전에 임시 형식으로 진행되어야 합니다. 그런 다음 개발이 완료되면 완성된 코딩을 검토하기 위해 또 다른 아미고 세션을 갖습니다. 이를 통해 모든 사람이 완료되는 대로 작업을 검토할 수 있습니다. 동시에 개발자는 변경해야 하는 항목에 얼마나 빨리 적응할 수 있는지 보여줄 수 있는 기회를 얻습니다. 예를 들어 분석가는 최종 아미고 검토에서 놓친 요구 사항을 지적합니다. 이를 통해 개발자는 그 자리에서 변경을 하고 수정된 코드를 화면에 표시하여 팀원에게 코드 기반의 적응성과 변경 요청에 대한 빠른 응답 시간을 증명할 수 있습니다. 이는 다른 사람들이 플랫폼으로 무엇을 할 수 있는지 이해하는 데 큰 도움이 됩니다. 의도는 이것이 영원히 계속되는 것이 아닙니다. 처음에는 모든 사람이 새로운 프로세스에 익숙해질 때까지 amigos 검토를 진행해야 합니다. 그 시점에서 스토리 카드 개발이 끝날 때만 이 기술을 활용하면 됩니다.

품질 보증 관점에서 볼 때 Agile의 가장 중요한 이점은 테스트 주도 개발입니다.

품질 보증 관점에서 볼 때 애자일의 주요 이점은 테스트 주도 개발(TDD)입니다. TDD는 IT 커뮤니티에서 사용되는 잘 알려진 프로세스입니다. 단위 테스트 모듈 사용할 수있는 Mendix App Store에서 개발자는 각 개발 스프린트에 묶인 여러 단위 테스트를 만들 수 있습니다. 단위 테스트 모듈을 사용하면 각 배포에서 보고서를 실행하여 단위 테스트가 통과하는지 실패하는지 확인할 수 있으며(개발자가 새로운 결함을 만들지 않았는지 확인하는 데 도움이 됨) QA 팀은 이를 통해 코드가 안정적이며 이전에 테스트한 코드가 여전히 작동하는지 확인할 수 있습니다. 물론 QA 팀은 스스로 테스트를 수행하고 싶어할 것입니다. 하지만 이 방법을 사용하면 완료된 각 스프린트에서 코드 기반이 저하되지 않는다는 것을 어느 정도 이해할 수 있습니다. 이는 프로젝트가 끝날 때 한 번 테스트하는 것과 달리 반복적인 일정에 따라 테스트하기 때문에 중요합니다. 테스트 노력이 낭비되지 않았다는 것을 알려주는 모든 것은 장기적으로 큰 이점입니다.

개발자 관점에서, 우리는 코드 검토가 모든 프로젝트의 성공에 필수적이라는 것을 발견했습니다. 그 이유는 간단합니다. 코드를 검토하는 사람이 많을수록 실수 가능성이 줄어듭니다. 또한 개발자를 위한 코딩 표준과 프로세스를 구현하는 데 도움이 되며, 모든 팀원이 활용할 수 있습니다. 다른 사람들이 코딩을 더 효율적으로 만들기 위해 무엇을 했는지 볼 수 있다면 출시 시간을 늘릴 수 있습니다. 또한 애자일에 적응하는 데 느린 사람들에게도 큰 도움이 될 것입니다. 이유는 무엇일까요? 그들은 여러분이 팀이 견고한 코드를 만들고 시스템에서 발견되는 결함의 양을 줄이는 데 도움이 될 수 있도록 최선을 다하고 있다는 것을 알고 있기 때문입니다. 결함이 적을수록 팀은 이 새로운 애자일 방식에 대해 더 기분이 좋아질 것입니다.

경영진은 어떠한가?

경영진은 팀 개발의 세부 사항에 관심이 없으며, 그래야 할 필요도 없습니다. 그들은 리소스, 속도, 품질에 더 관심이 있습니다. 글쎄요, 우리가 쉽게 유지 관리되는 훌륭한 시스템을 개발하고 있다는 것을 보여줄 구체적인 것을 어떻게 제공할 수 있을까요? 저는 다음을 사용하는 것을 강력히 추천합니다. Mendix 품질 및 보안 관리 도구.

우리는 코드 베이스 내에서 변경을 하기 전에 시스템의 메트릭을 제공할 수 있었습니다. 이렇게 함으로써 우리는 우리가 구현하고자 하는 아이디어가 AQM 점수를 높여 가치를 제공했다는 것을 쉽게 보여줄 수 있었습니다.

AQM은 리포지토리 내에서 커밋된 코드를 스캔하여 1~5점 척도로 평가를 결정함으로써 McCabe 복잡도를 활용합니다. McCabe 복잡도 측정에 익숙하지 않은 분들을 위해 설명드리자면, 이는 프로그램의 복잡도를 나타내는 데 사용되는 소프트웨어 지표입니다. AQM 도구는 코드 베이스를 XNUMX가지 범주로 나눕니다. 이러한 범주는 개발 관점에서도 매우 유용합니다. 이를 통해 팀에서 지나치게 복잡하지 않고 쉽게 유지 관리할 수 있는 항목을 만들고 있다는 것을 알 수 있습니다. 이는 새로운 개발자를 온보딩할 때도 유용합니다. 이를 통해 팀은 개발자의 이해 수준을 확인할 수 있으며, 개발자가 어디에서 잘못 코딩했는지 쉽게 지적할 수 있습니다. 이를 통해 조직의 표준에 따라 마이크로플로를 구성하는 적절한 방법을 가르칠 수 있는 기회가 제공됩니다.

그렇다면 경영진은 어떨까요? 경영진은 회의에서 사용하기 쉬운 그래프를 제공하는 간결하고 요점을 잡은 보고서를 선호한다는 것은 누구나 알고 있습니다. AQM 도구는 개발 중인 코드에 대한 통찰력을 제공하는 여러 보고 옵션을 제공합니다. 이는 우리 조직에서 매우 유용한 것으로 입증되었습니다. 코드 기반 내에서 변경하기 전에 시스템의 메트릭을 제공할 수 있었습니다. 이렇게 하면 AQM 점수를 높여 구현하려는 아이디어가 가치를 제공한다는 것을 쉽게 보여줄 수 있었습니다. 이 접근 방식을 통해 경영진에게 이전 및 이후 메트릭을 보여줌으로써 가장 큰 위반 마이크로플로 중 일부를 제거할 수도 있었습니다.

AQM을 사용하면 팀에서 지나치게 복잡하지 않고 쉽게 유지 관리 가능한 항목을 만들고 있는지 확인할 수 있습니다.

또한 관리팀에 사용자 로그인을 설정하여 이러한 지표에 액세스하고 조직 전체의 토론에서 사용할 수 있도록 할 수도 있습니다. 기억하세요: 사람들에게 더 많은 편의를 제공할수록 참여가 더 쉬워질 것입니다.

앞으로 이동

이것은 제가 조직 문화를 바꾸는 데 도움이 되는 고수준 접근 방식입니다. 처음부터 끝까지 순탄하게 진행되지는 않을 것이라는 점을 알아두십시오. 프로세스 전반에 걸쳐 많은 기복이 있을 것입니다. 결국에는 그럴 가치가 있을 것이라는 점을 기억하십시오. 이러한 항목을 사용하면 모든 사람이 새로운 프로세스에 대한 이해와 편안함을 얻는 데 도움이 됩니다. 프로세스를 반복하는 데 일관성을 유지하면 사람들에게 큰 도움이 됩니다. 각 스프린트에서 팀에 더 많은 것을 제공할수록 그들은 노동의 결실을 더 많이 보게 될 것입니다. 이러한 단계는 개발 팀이 애자일 접근 방식이 엄청나게 성공적일 수 있다는 것을 이해하는 데 큰 도움이 되었습니다.