애자일 개발 팁 10가지

대부분의 사람들은 프로그래밍과 소프트웨어 개발을 컴퓨터 애호가들이 방에 틀어박혀 수백만 줄의 코드를 망치는 고독한 일이라고 생각할 것입니다. 그러나 그것은 진실과 거리가 멉니다. 실제 소프트웨어 개발은 ​​기능적이고 사용하기 쉬우며 올바른 기능을 갖춘 소프트웨어를 개발하기 위해 서로 다른 전문 분야를 가진 개발자 팀이 함께 작업해야 하는 상당한 그룹 노력입니다.

개발 팀이 개발 주기 전반에 걸쳐 동일한 페이지에 있게 된다는 것은 프로세스를 가장 잘 촉진할 수 있는 모델을 따르는 것을 의미합니다. Waterfall, Spiral, V-model 등과 같은 이름을 가진 꽤 몇 년 동안 개념에서 완성된 제품을 가지고 유지 관리에 이르기까지 소프트웨어가 개발되는 방법을 보여줍니다.

이미지 출처: Adam Weisbart의 Agile 선언문 포스터.

현재 많은 대형 개발자들이 돌리는 프로세스는 적응성과 끊임없는 진화라는 핵심 신조 때문에 명명된 애자일로 알려진 프로세스입니다. Agile Manifesto라고 하는 것을 기반으로 하며 경험이 풍부한 소규모 개발자 그룹이 작성했습니다.

그들은 협업을 개발의 중심 기둥으로 보았고 요구 사항과 솔루션은 모두 협력에서 발전할 수 있습니다. 애자일 개발을 마스터하는 데 시간이 오래 걸리지만 여기에 도움이 될 수 있는 10가지 팁이 있습니다.

개발자와 테스터를 위한 훌륭한 하드웨어

랩톱을 사용하여 코드를 작성하는 것이 가능할 수도 있지만 충분하지 않은 장비로 소프트웨어를 개발하는 것이 좋습니다. 성능 문제와 상관없이 발생하는 버그와 결함을 보고 싶기 때문에 테스터가 작업을 수행할 고품질 기계를 보유하는 것만큼이나 중요합니다.

그러나 프로그래머가 정말로 원하는 것은 다중 모니터가 코드를 작성할 만큼 많은 화면 공간을 갖는 것입니다. 좋은 키보드는 입력 코드가 빵과 버터이기 때문에 큰 도움이 됩니다. 기계식 키보드는 내구성이 뛰어나고 타이핑하기에 좋습니다(적어도 촉각 스위치가 있는 키보드).

결과에 집중

누구의 생각이 옳은가가 아니라 올바른 생각을 하는 것입니다. 결국 방향은 위에서 아래로 내려온 Agile 초기와 달리 상위 경영진에서 나옵니다. 이는 상위 관리자가 프로젝트 감독 및 관리에 집중할 수 있는 반면 개발자는 상위 경영진이 설정한 매개변수 및 경계를 준수하면서 작업에 집중할 수 있기 때문에 최상의 프로세스 흐름인 것으로 나타났습니다.

이러한 하향식 관리 모델로 인해 개발 팀은 구체적이고 측정 가능한 결과를 얻을 것으로 예상됩니다. 그들은 코드뿐만 아니라 실제로 의도한 대로 작동하는 작업을 보여줄 수 있어야 합니다. 그런 다음 애자일 개발에서 큰 역할을 하는 프로세스인 테스트 주도 개발(TDD)을 통해 신호를 받습니다.

지속적 배포를 먼저 구현

기본적으로 계속 오세요. 이렇게 하면 개발이 일정한 속도로 이루어지고 개발자가 조기에 자주 피드백을 받을 수 있습니다. 끊임없는 의사 소통과 피드백은 Agile Development의 모든 것이므로 팀이 필요할 때 갑작스러운 변화와 예기치 않은 상황에 적응할 수 있습니다. 여기에서 "빌드"가 발생합니다.

빌드는 기본적으로 개발 중인 소프트웨어의 사용 가능한 버전입니다. CD(Continuous Delivery) 개념을 통해 이전 빌드에 대한 피드백에서 가져온 개선 및 수정을 수행한 후 릴리스된 연속 빌드를 자주 배포해야 합니다.

고위 경영진을 위한 후원 받기

애자일 개발은 하향식 접근 방식을 취하지만 무언가를 구현하거나 변경하기 전에 상위 경영진의 승인을 기다리는 것은 다소 시간이 많이 걸릴 수 있습니다.

잘못하면 허가를 기다리는 데 많은 시간이 낭비될 수 있습니다. 좋은 해결책은 이러한 문제를 개발자로부터 권위자에게 더 빨리 전달할 수 있는 대변인을 두는 것입니다. 가급적이면 아이디어를 제시하는 데 능숙하고 요구되는 내용을 이해할 수 있는 사람이 좋습니다.

더 짧은 개발 및 테스트 주기로 이동

개발 지옥은 주요 소프트웨어를 포함하여 많은 소프트웨어에 만연해 있습니다. 또한 긴 개발 주기로 인해 사용자가 궁극적으로 거부하는 기능이 발생하여 전체 주기가 회사에서 즉시 복구할 수 없는 시간과 비용을 크게 낭비하게 되는 경우가 있습니다. 이러한 위협을 완화하는 좋은 방법은 개발 및 테스트 주기를 단축하는 것입니다.

애자일 개발은 피드백의 유입을 포함하여 가능한 한 빨리 일을 진행하는 것이므로 "최소 실행 가능한 제품"을 내놓기 위해 더 짧은 개발 주기를 갖는 것이 중요합니다. 이를 통해 사용자는 이빨을 파고들고 그에 따라 피드백을 제공할 수 있으며, 이는 다음 빌드에서 해결할 수 있습니다.

첫날부터 자동화 달성

AD1이라고도 하는 이것은 가능한 한 빨리 모든 것을 설정하면 작업을 더 빠르게 진행할 수 있는 고상한 목표입니다. 현실적으로, 당신이 좋다면 2년이나 3년이 되면 모든 것을 자동화할 수 있을지도 모르지만, 적어도 가능한 한 첫째 날에 계속 완료해야 합니다.

그것은 시간을 절약하는 것이기도 하고, 열심히 생각한다면 생명의 은이기도 합니다. 간단한 프로세스를 자동화하면 개발자와 다른 구성원이 불필요한 바쁜 작업을 처리하는 데 도움이 됩니다.

유효 팀 비율

“요리사가 너무 많으면 육수를 망친다”는 말이 있듯이. 팀에 구성원이 너무 적으면 작업이 더 어려워질 수 있지만 너무 많으면 좋지 않을 수 있습니다. 또한 프로젝트에 비용을 지불해야 하기 때문에 프로젝트에 너무 많은 것을 보유하는 것은 재정에 큰 손실입니다. 따라서 프로젝트와 팀 자체의 요구는 물론 주어진 기간 및 기타 여러 요인을 고려하는 것이 중요합니다.

미해결 문제 계획

팀은 모든 단일 문제를 해결하려고 시도할 수 있지만 항상 일부 문제가 해결되지 않거나 결국 미해결 문제가 됩니다. 이것은 다음 개발 주기에서 이러한 미해결 문제를 처리함으로써 처리됩니다.

피드백 요청

이것은 아무리 강조해도 지나치지 않습니다. 피드백은 Agile Development의 생명선입니다. 소프트웨어가 발전하는 데 도움이 되는 것은 데이터이며 개발자와 고위 경영진은 현재와 장기적으로 가장 시급한 데이터에 최소한 주의를 기울여야 합니다.

프로세스 평가

작업 중인 소프트웨어뿐만 아니라 개발 프로세스도 평가해야 하므로 개발의 진화가 시작됩니다. 미세 조정할 수 있는 항목이 너무 많지만 현재 프로젝트와 미래의 프로젝트에서 주어진 시간 프레임에서 최상의 결과를 얻을 수 있는 항목을 결정해야 합니다.