애자일 소프트웨어 개발이 매력적인 이유는 무엇입니까?

민첩한 소프트웨어 개발은 ​​요즘 꽤 재미있는 유행어가되고 있습니다.

개발자는 반복 개발의 실용적인 가치를 이해하지만 소프트웨어 개발에 대한 민첩한 접근 방식을 채택하는 것은 개발자의 선택이 아닙니다. 하향식 관리 선택입니다! 그것이 결정, 민첩한 방법, dsdm, rup, xp, scrum, fdd, tdd이든, 당신은 그것을 명명합니다. 개발자의 선택이 아닙니다.

모든 관리자에게있어, 내 경험상 대부분의 관리자가 자신의 삶에서 코드를 건드리지 않았을 때 민첩한 개발을 선택하는 가장 큰 이유는 무엇입니까 !

변화하는 요구 사항, 빠른 배송

애자일은 변화하는 요구에보다 신속하게 (또는 전혀) 적응할 수 있고 이러한 변경 사항을 고객에게 더 빨리 제공 할 수 있기 때문에 매력적입니다.

이것이 Agile / Scrum을 사용할 때 많은 회사가 실패하는 이유입니다. 관리자는 강력한 릴리스 (빠른 릴리스 날짜 설정 및 요구 사항 변경)가 개발자의 평가에 의존해야 한다는 사실을 이해하지 못합니다 . 민첩한 업무를 위해서는 관리자가 기꺼이 범위를 축소해야합니다.

그들은 둘 다의 힘을 원합니다.

다음 트렌드

때로는 사람들이 착수 한 것의 장점 (민첩한) 때문이 아니라 단순히 인기가 있고 다른 사람들도 같은 일을하려고하기 때문에 일을합니다.

"무엇입니까? Macrojam이 애자일을하고 있습니까? 왜 그렇지 않습니까? 우리는 느리지 않습니다. 우리는 애자일입니다, 젠장!"

어떤 사람들은 민첩한 것이 실제로 수반되는 것을 망설이지 않습니다. 그것은 단지 그들의 존재를 정당화하는 수단 일뿐입니다. 양, 동료 압력 등

코딩 자체가 관리자가 애자일을 방법으로 선택하도록 확신 할 수있는 주요 이유는 아닙니다. 변화하는 요구 사항과 우선 순위에 더 빠르게 대응할 수 있다는 사실이 매력적입니다. 결국 '관리자'는 최종 사용자 / 고객 / 관리자에게 솔루션을 제공해야합니다.

프로젝트를 시작할 때 핵심으로 보였던 기능을 프로젝트 중간에 폐지하고보다 관련성이 높은 새로운 요구 사항으로 대체 할 수 있다면 이는 큰 이점입니다.

또한 중요한 것은 (예를 들어 스크럼에서와 같이) 각각의 중간 배달이 생산에 투입 될 준비가 거의되어야한다는 것입니다. 동시에 가장 긴급한 기능이 먼저 개발되었습니다. 따라서 일부 회사 결정으로 인해 프로젝트가 취소 된 경우, 경영진은 귀하가 작동하고 생산에 투입 될 수있는 무언가를 얻게 될 것이라고 확신합니다.

도움이 되었기를 바랍니다.

진행 상황에 대한 가시성 향상 및 생산성 향상

1. 관리자는 일반적으로 가시성 민첩성, 특히 스크럼과 관련하여 관심 을 갖습니다. 관리자를 대상으로하는 세미나에서 가장 많이 사용되는 판매 지점 중 하나입니다.

2. 시연이 용이하기 때문에 (시인성 덕분에) 생산성을 높이는데도 일반적으로 높은 생산성 이 사용됩니다. 일부 민첩한 전도자들은 기존 직원들로부터 뛰어난 생산성을 약속합니다. "뭐? 나는 이미 레몬처럼 눌렀는데 더 많은 것을 얻을 수 있다고 말해 ? "

많은 관리자들이 애자일을 사용하여 직원을 조금 더 많이 부수고 나는 한 번의 대기업에서 번 다운 차트를 느슨하게 사냥하는 기계로 사용하는 것을 보았습니다.

결과? 에 많은 팀이 distress있습니다. 그들은 애자일이 모든 문제를 해결할 것이라고 생각했지만 정확히 반대였습니다. 문제는 다른 곳에있었습니다.

나는 적극적으로 반대하고 있습니다. 그렇기 때문에 perverted경영진 이 민첩한 방법론보다 확률이 높은 경우가 있기 때문에 회사 내에서는 언급하지 않는 것이 좋습니다.

그 질문에 대한 답은 책을 채울 수 있습니다.

주요한 이유 중 하나는 민첩한 개발이 결과물에 초점을 맞추고 있기 때문입니다. 항상 현재 가장 시급한 것을 제공하는 데 중점을 둡니다.

또 다른 이유는 민첩한 프로세스가 따르는 스토리 기반 계획 및 추정 관행이 무엇을 언제 전달할 수 있는지 훨씬 더 잘 추정 할 수 있기 때문입니다.

효과적인 스토리 기반 계획의 좋은 예는 제가 작업 한 프로젝트입니다. 프로젝트 리더는 민첩한 개발을 채택하기 전에 몇 달 동안 제 시간에 인도 할 수 있다고 생각했으며 마감일로부터 약 18 개월이 걸렸습니다. 모든 개발자는 아마도 비현실적이라고 생각했습니다. 민첩한 계획을 시작한 후에도 프로젝트 리더는 상황을 낙관적으로 평가했습니다. 그러나 단 몇 번의 스프린트 후, 프로젝트 리더는 팀이 예상 시간에 모든 요구 사항을 전달할 수있는 능력이 없다는 것을 깨달았습니다. 그리고 그것은 여전히 ​​마감일로부터 12 개월이 넘었습니다.

따라서 민첩한 관행은 현실을 훨씬 빨리 분명하게 만듭니다.

마지막으로, 민첩한 팀은 테스트 중심 개발, 빈번한 리팩토링, 지속적인 통합, 피어 코드 검토 / 쌍 프로그래밍 등과 같이 더 나은 코드 품질을 만드는 관행을 더 자주 채택하는 경향이 있습니다. 전통적인 소프트웨어 프로젝트는 이러한 관행을 금지하지 않습니다. 그다지 집중하지 마십시오.

대부분의 관리자는 자신의 삶에서 코드 조각을 만지지 않았습니다!

나는 12 년 동안 개발자 였고 지금은 5 년 동안 관리자였습니다. 5 년 동안 나는 주로 순수한 관리자로 코딩하는 관리자에서 점차적으로 전환했습니다 (여전히 버그를 수정하거나 프로토 타이핑 연습을합니다).

애자일 개발을 선택하는 가장 큰 이유는 무엇입니까

• 가시성 또는 빠른 성공 / 실패 – 우리는 6 개월에서 24 개월 주기로 제품 개발 상점입니다. 작동하고 테스트 된 기능을 사용하여 반복 개발하면 프로젝트 상태를 더 잘 반영 할 수있었습니다.
• 변화-우리 환경에서는 요구 사항과 시간이 고정되는 경향이 있습니다. 그러나 너무 규칙적인 사업은 방향이 바뀌면서 빠르게 진행됩니다. 반복적이고 눈에 띄는 개발로 프로젝트 방향을 쉽게 바꿀 수있었습니다.
• 반복 개발이 포함 된 스토리 기반 요구 사항을 통해 요구 사항의 기술적 측면을 항상 이해하지 못하거나 일부 세부 사항의 비즈니스 동인을 완전히 이해하지 못하는 비즈니스에 대해 작업하기가 더 쉬워졌습니다. 과거의 노력에서 높은 수준의 사양이나 마케팅 요구 사항 문서가 항상 충분하지는 않았습니다. 이제 프로젝트가 발전함에 따라 병렬 시장과 고객 조사가있을 수 있습니다.
• 프로세스 변경에는 TDD, 자동화 된 테스트와 수동 테스트, 더 긴 테스트주기 (더 이상 QC 그룹이없고 QA 그룹 만 있음), 품질과 관련된 높은 평가 및 노력 (우리는 더 많은 도구와 측정 항목).

우리는 다른 방법으로 이것을 달성 할 수 있었지만 민첩한 방법론과 아이디어를 활용하면 엄청난 도움이되었습니다.

또한 프로세스를 계속 개선합니다. 예를 들어, 초기 설계 작업과 구현 직전의 설계 사이의 균형. 우리는 모든 결정을 정기적으로 검토하여 과거의 디자인 결정을 연기 할 수 있었는지 판단합니다. 그리고 일이 잘못되면 오류가 확인 될 때까지 얼마나 많은 선행 작업이 필요했을 것입니다. 종종 실패는 심층 분석이 필요한 코너 사례입니다. 세부 정보를 얻는 노력은 종종 그것을 따라 가고 리팩토링하는 비용과 동일합니다. 이러한 유형의 오류에 대해서는 팀이 불이익을받지 않으며보다 적극적으로 참여하도록 권장됩니다.

많은 회사들이 "민첩한"행동을하는 것을 보았습니다. 불행히도, 민첩성을 채택한 사람 은 거의 없습니다 . 내가 의미하는 바는 단지 반복적 인 개발을하고 매일 스탠드 업 (대부분의 팀이 앉는 곳)이 팀을 민첩하게 만들지 않는다는 것입니다. TDD, 리팩토링, 지속적인 통합, 고객 존재, SOLID 사례는 팀을 민첩하게 만듭니다. 그것들이 없으면 서클에서 돌아 다니는 것입니다.

애자일의 메시지가 전하는 많은 호소력이 있습니다. 가장 큰 변화를위한 적응력. 불행히도 프로젝트 관리 방식을 변경했기 때문에 코드가 더 적응력이 떨어지지 않습니다. 더 많은 회사가이를 인식 할 때까지 점점 더 실패한 민첩한 프로젝트에 대해 듣게됩니다.

나는 버즈 단어 부분에 대해 모른다. 나는 공식화되지 않았거나 식별되지 않은 프로세스로이 모든 것을 실제로 해왔다. 웹 사이트를 구축 할 때 고객이 말 그대로 내 어깨 너머로 보도록했습니다. 약 50 개의 이메일을 저장했고 고객은이 프로세스에 대해 알게되었습니다. 쉽지 않습니다.

사용자가 소프트웨어가 원하는 모든 것을 기록하는 데 오랜 시간이 걸리고, 앱을 시도한 후 2 초 이내에 발견하고자하는 것을 구축하는 데 더 오랜 시간이 걸린다는 통념 그들이 기대하는 것이 구역질이 아닙니다. 다른 조각을 만들기 전에 프로젝트 나 응용 프로그램을 적당한 조각으로 나누어서 피드백을 얻는 것이 얼마나 어려운가요?

나는 이것이 지나치게 단순화 된 것으로 알고 있으며 실제 개발자 관행을 다루지 않지만 가장 기술이 아닌 관리자 나 고객에게도 판매하는 것은 어렵지 않습니다. 더 매력적인 다른 접근법은 무엇입니까? 고객은 폭포 프로젝트 중에 개발하는 동안 프로그래머가 6-12 개월 동안 머리카락을 벗어났다는 사실을 정말로 좋아합니까? 이런 식으로 집을 짓기 위해 누군가를 고용하겠습니까?

경영진은 이러한 것들을 개발자에게 강요하지 않습니다. 개발자와 팀은 주도권을 행사하고 더 나은 업무 수행을 위해 노력해야합니다. 경영진의 임무는 이러한 이니셔티브를 지원하는 것입니다.

내 경력에 공정한 코드를 작성한 관리자로서 나는 당신이 이것에 대답하고자하는 사람이 아닐 수도 있습니다. 어쨌든, 요즘 애자일은 고객의 요구에보다 신속하게 대응하고 사양, 코딩, 테스트 및 고객 간의 피드백 루프를 단축하는 것과 가장 관련이 있다고 생각합니다. 우리는 바로 이러한 이유 때문에보다 민첩한 개발로 나아가고 있습니다.

민첩한 프로세스와 코딩 / 개발 관행을 망쳐서는 안된다고 생각합니다. 예를 들어, Scrum은 코드 개발 방법을 알려주지 않으며 변경을 환영하는 프로세스에 관한 것입니다.

하루가 끝나면 개발자에게 힘을 실어주는 것입니다. 그것은 계층 구조의 맨 아래에있는 사람들이해야 할 일의 범위와 수행 방법을 진정으로 이해하는 유일한 사람이라는 사실을 인정하는 것입니다. 따라서 이미 전문성을 위해 고용 한 경우 이유는 무엇입니까? 그들이 완전한 통제권을 가지도록하지 말고, 왜 실제 의사 결정과 거리를 두어야합니까?