어떤 프로그래밍 방법이 우리에게 적합할까요?

불행히도 누군가 우리의 고위 경영진에게 "애자일 (Agile)"이라는 단어를 가르쳤으며 이제는 우리가 그 목표를 향해 나아가기를 원합니다. 나는 민첩성에 대한 말초 이해를 가지고 있지만 (실제로는) 결코 사용하지는 않았습니다. 내가 아는 한, 그것은 우리 조직에 적합하지 않을 것입니다. 지금은 상황이 꽤 지저분합니다. 그 방법은 다음과 같습니다.

우리는 두 명의 개발자, 한 명의 DBA, 한 명의 디자이너 인 매우 작은 팀입니다. 내가 일하는 회사는 규모에 비해 불균형 적으로 많은 양의 돈을 벌고 있으며 그 중 거의 95 %가 순수한 온라인 판매입니다.

개발 관점에서 볼 때, 우리는 전형적인 하루 동안 많은 책상 침략을 겪습니다 (우리는 개발자뿐만 아니라 기술 지원이기도합니다). . 우리는 더 큰 프로젝트도 수행하고 있으며 끊임없는 중단으로 악몽입니다. 우리 중 일부는 머리를 찢기 시작합니다! 프로젝트 계획은 비 기술적 인 관리자가 Excel 스프레드 시트에서 작성하며, 작업을 이해하기 쉽고 각 날짜 옆에 날짜를 넣을 수있는 간단한 크기의 문장으로 나눕니다. 이 날짜는 항상 비현실적으로 비현실적이며 종종 놓치게되며, 매주 열리는 회의는 정기적으로 "이것이 아직 완료되지 않은 이유"를 묻는 사람들과 함께 어색한 순간으로 가득합니다.

나는 애자일이 우리를위한 것이 아니라고 확신합니다. 이제, (그리고 시도한)이 회사 는 그 길을 바꾸지 않을 것이며 , 개발팀 만이 기꺼이 변할 것입니다. 우리가 채택 할 수있는 개발 방법론이 있습니까?

애자일은 실제로 많은 정확한 문제를 해결하도록 설계되었습니다. 경영진이 프로세스를 실제로 사 들여 프로세스를 왜곡하지 않으면 크게 개선 될 수 있습니다. 문제를 단계별로 해결하겠습니다. 내 경험은 스크럼과 관련이 있으므로 그 관점에서 이야기하지만 다른 구현에도 비슷한 이점이 있습니다.

• 하늘에서 떨어지는 작업 이 이야기는 제품 소유자와 팀이 만나서 동의 할 때까지 백 로그의 맨 아래에 표시됩니다. 우선 순위는 모든 팀의 다른 약속과 관련하여 결정되며, 우선 순위는 관심이있는 모든 이해 관계자에게 표시됩니다. 해야한다 매우 스프린트의 중간에 새로운 기능을 추가하는 드문, 단지 가장 높은 우선 순위의 버그가 스프린트를 방해 할 수 있어야합니다. 정기적으로 기대되는 다음 주가 끝날 때까지 얼마나 많은 "응급 상황"을 기다릴 수 있는지는 놀랍습니다.
• 대규모 프로젝트 수행 단기 우선 순위가 장기 프로젝트에 미치는 영향을 보여줄 수 있습니다. 사람들이 당신의 장기 프로젝트 앞에서 계속해서 사용자 이야기를한다면 괜찮지 만, 결정을 내리기 위해 모든 사람들이 장기 프로젝트 일정에 미치는 영향을 알 것입니다.
• 프로젝트 계획이 아닌 기술 관리자에 의해 작성되어 사용자의 이야기가되어 가정 보기의 비 기술적 인 관점에서 작성되어야하지만 스크럼 팀은 추정하고 구현 세부 사항을 결정하는 권한을 부여해야합니다.
• 날짜는 엄청나게 비현실적입니다. 팀은 귀하가하는 일을 아는 사람들이기 때문에 모든 견적을 처리합니다. 이러한 추정치가 비즈니스에 적합하지 않은 경우 기능의 우선 순위를 정하는 방법을 결정해야합니다. 그들이 당신이 처리 할 수있는 것보다 더 많은 일이 필요하다면, 더 많은 사람들을 고용해야 할 필요성이 분명하게 보일 것입니다.
• 날짜가 종종 누락됩니다. 첫째, 추정치가 더 현실적이어서 도움이 될 것입니다. 또한 작은 청크를 물고 실제로 마무리 하므로 기능이 완벽하지 않아도 유용한 것을 생산 한 것처럼 느끼게합니다.
• 어색한 순간으로 가득 찬 회의 Agile은 제품 소유자가 크게 참여하여 가시성이 향상되고 피드백주기가 훨씬 빨라졌습니다. 차단 문제와 지연 이유는 놀라운 일이 아닙니다.
• 또한 기술 지원 수행 민첩성과 달리 애자일은 분할 된 일정과 호환되지 않습니다. 팀 속도에 방해가되는 스크럼 요소. 일반적으로 기술 지원을하는 데 절반의 시간을 소비하면 속도의 절반을 얻게됩니다.

관리 및 판매가 인식해야 할 점은 민첩성이 개발 팀을보다 세밀하게 제어 할 수있는 방법이 아니라는 점입니다. 팀은 업무를 할당 할 때마다 비즈니스가 현실적으로 모든 우선 순위를 고려할 수 있도록 도와주는 한편 팀이 자신이하는 일을 더 잘 수행 할 수 있도록합니다. 팀.

나는 당신의 경영 변덕을 활용한다고 말하고 싶습니다! 그들이 당신에게 호의를 베풀고 작업 방법을 향상시키는 데 도움이되는 것처럼 들립니다.

그들에게 우리는 다른 것들 중에서도 민첩하게 갈 것이라고 말하십시오.

• 개발과 지원의 분리
• IT 팀의 통제하에 공식 요구 사항 수집 프로세스 "스토리"등은 모두 모호하게 들리지만 실제로는 "공식적인"방법으로 비공식적으로 보입니다.
• 스케줄링은 IT 팀의 통제하에 있습니다.

그들이 이것을 받아들이지 않으면 민첩하게 갈 수 없다고 말하십시오.

애자일은 프로그래밍 방법론이 아니며, 애자일은 프로젝트 관리 방법론입니다. 경영진이 실제로 발견 한이 새로운 유행어를 시험해보고자한다면 애자일 방법이 처음부터 시작하여 모든 단계의 관리가 필요하다는 것을 이해할 수 있어야합니다. 그들에게 어려운 현실을 주어야한다면, 애자일에 대한 30 분 파워 포인트 프레젠테이션을 구성하여 그들에게 약간의 교육을 줄 수 있습니다. 관리자는 Powerpoint를 좋아합니다.

그러나 당신이 말한 것처럼 dev 팀이 기꺼이 바꾸려는 사람들이라면 개발 방법론이 당신을 도울 수 없습니다. 나머지 의무를 완화하지 않으면 중단이 계속 발생하며 단순히 충족 할 수없는 기한을 지키라는 요청을 계속 받게됩니다.

이 시나리오에서 저의 조언은 경영진이 실제로 최전선에 어떻게 있는지에 대해 교육하고, 욕설하지 않는 것입니다.

영업 사원이 일상 일정을 지시하는 조직에서는 소프트웨어 개발 및 프로젝트 관리 방법론이 도움이 될 수 없습니다. 일주일에 혼란스럽고 산만 해지면서 프로젝트를 어떻게 관리해야합니까?

따라서 많은 상급 관리자는 Agile의 가치를보고 그 이점을 원하지만 이동이 성공적인지 확인하는 데 필요한 내부 변경은 거의 불가능합니다. 내가 아는 유일한 성공적인 애자일 상점은 그런 식으로 시작되었습니다. 문화의 근본적인 변화가 필요하기 때문에 영업 관리 또는 폭포수 소프트웨어 개발 상점의 전문적인 경험에서 한 가지 사례를 떠 올릴 수 없습니다.

문화의 변화가 가능합니까? 예, 그러나 귀하의 경우에는 거의 확실하지 않습니다.

문화의 변화는 일반적으로 회사의 존재를 위협하거나 경쟁사를 정당화하기 위해 회사의 상황 또는 제조 또는 중단 상황 또는 이와 유사한 기타 상황을 위협하는 경쟁 업체에 의해 필요합니다. 당신의 상황에서, 당신의 회사는 지금 돈이 쉽고 모든 사람들이 살찌게되는 스펙트럼의 다른 끝에 있습니다.

돈이 편할 때 회사는 절대 변화하지 않습니다. 소프트웨어 개발 성공 때문이 아니라 소프트웨어 개발 실패에도 불구하고 성공해야하는 이유.

마지막 조언은 내가 당신이라면 더 좋은 것을 찾겠다는 것입니다. 여기 사람들은 훌륭한 조언을하지만이 노래와 춤을 본 적이 있으며 여러분의 상황에서는 효과가 없습니다.

extremeprogramming.org를 보십시오 -XP 는 쉽게 이해할 수있는 측면을 가진 민첩한 형태입니다. 시작하기에 아주 좋은 곳

대화 중에 마음을 바꾸지 않기로 한 고객의 약속 은 환경의 소리에서 좋은 출발점이 될 것입니다. ;-)

전통적이든 현대적이든 방법론의 전망을 고려한다면, "애자일"은 방법론보다 "방법론"에 가깝다는 것을 깨닫게 될 것입니다. 패턴은 특정 상황 내에서 주어진 문제에 대해 "최상의 사례"솔루션을 묘사하는 것을 목표로합니다. 그러한 해결책이나 패턴을 직접 위반하려는 시도는 일반적으로 "반 패턴"또는 더 나쁜 사례라고합니다. 마찬가지로, 진정한 소프트웨어 개발 방법론은 솔루션 개발에있어 모범 사례를 규정하려고 시도하지만 "애자일"(Scrum, XP 등)은 우연한 혼란에 찬성하여 소프트웨어 개발 프로세스 내의 모든 구조를 직접 위반하려고 시도합니다. 접근 방식-(늦은) 또한 (순진한) 구경꾼의 박수를 요구하는 것 같습니다.

따라서 애자일 철학이 생겨난 상황을 염두에 두는 것이 적절합니다. 당시에는 정교한 반복적 방법론 (예 : 통합 프로세스)이 존재했지만, 주요 방법론은 여전히 ​​완전한 폭포수 접근 방식으로, 완벽한 요구 사항 분석의 "우수 사례"를 규정 한 다음 설계를 완료 한 다음 솔루션을 개발 / 코딩 한 다음 구현했습니다. 해결책. 분명히, 소프트웨어 개발에 대한이 엔지니어링 접근 방식은 잘못 권고되어 실행 가능한 솔루션을보기 전에 (때로는 없던) 많은 서류 작업이 필요했습니다.

그러나 애자일의 요술사와 마찬가지로 목욕물로 아기를 버리는 것을 여전히 보증하지는 않습니다. 애자일 접근 방식은 솔루션의 실제 코딩을 제외하고는 이전에 사용 된 모든 것을 직접 무시합니다. 분명히 이것은 발신자 측에 대한 통찰력이 제한되어 있음을 나타내거나 단순히 "보고 싶지 않은 사람들만큼 맹인이없는 경우"일 수 있습니다.

그럼에도 불구하고 애자일의 장점은 간소화 된 프로세스를 장려하고 실행 가능한 코드에 초점을 맞추는 것입니다.

이제 귀하의 질문에보다 직접적으로 답변하십시오 :

환경에 대한 개요를 감안할 때 먼저 Agile 구현 (예 : Scrum, XP 등)을 선택하는 것이 좋습니다. 그런 다음 환경에 맞는 접근 방식을 사용자 정의하여 팀의 작동 방식을 명확하게 설명하십시오.

• 사용자 (들)로부터 요청을 수신;

• 사용자 요청의 우선 순위를 정합니다.

• 기존 시스템에 대한 개선의 게이지 영향 (일별 / 주간 스탠드 업 회의 일 수 있음)

• 각 개선 사항의 개발 시간을 예측하고이를 다양한 요청 사용자에게 다시 전달하십시오.

• 기존 시스템 (예 : 코딩)에서 실제 향상을 수행합니다.

• 사용자 테스트를 수행하고 요청 된 변경 사항이 성공적으로 구현되었다는 전자 메일을 통해 사용자로부터 약속을받습니다.

이것은 민첩한 접근 방식의 유사성을 유지하면서 일부 구조 (및 순서)를 제공해야합니다.

위에서 말한 것처럼, "원숭이로서의 애자일"이라는 오래된 영어 연설은 이유없이 만들어지지 않았다는 것을 기억하십시오!

나는 애자가 같은 당신이 방법을 필요로 말을 필수 당신의 팀. 회사가 너무 조직적이기 때문에 자신의 개발자 팀 내에서 더 체계적으로 구성해야합니다. 그러나 귀하의 비 기술 관리자는 그와 관련이 있다고 생각하지 않습니다.

영업 사원에게 밀리고 현실적인 마감일을 요구할 경우, 체계적인 계획으로이를 정당화해야합니다.

또한 기술 상담없이 견적을 받으면 빈칸으로 표시하지 않습니다.

아마도 점진적 / 반복적 측면에 초점을 맞추는 것은 팀과 낙담 한 이해 관계자가 정기적으로 일관되게 제공 할 수 있어야하는 것입니다. 시간이 지남에 따라 영업 팀과 경영진은 새로운 기능 요청을 할 때 팀이 적절한 시간 내에 제공 할 수 있다는 확신을 갖게됩니다.

물론 단위 / 시스템 / 회귀 테스트, 자동화 된 빌드, 개밥 등으로 투자하지 않아도됩니다.

먼저 데이터를 수집하는 것이 좋습니다. 조용한 시간에 앉고 현 상태가 실제로 어떻게되는지 알아보십시오. 경영진이 애자일이라고 부를 수있는 것을 구현하는 데 어려움을 겪고 있다면 팀에 적합한 것을 찾아 내고, 문서를 작성하고, 이름에 "애자일"을 두드리면 좋습니다. 그들이 애자일에 대해 실제로 아는 유일한 것은 단어이며, 영어로 일반적인 정의를 위해 신속 함과 모호한 연관성이 있다는 것을 명심하십시오. 따라서 내가 주장하는 것은 팀이 문제를 해결하고 자신에게 적합한 맛을 찾은 다음이를 경영진에게 Agile (tm) 방식으로 제시한다는 것입니다. 그렇지 않으면 일부 PHB가 책을 집어 들고 사각형 구멍을 둥근 구멍에 맞추려고 시도하지만 아무도 행복하지 않을 것입니다.

"순수한"형태의 민첩성을 사용한다면 팀이 지원 역할을 수행하기가 어려울 수 있습니다. 당신의 상사는 "백 로그 항목을 만들도록하겠습니다. (스프린트 종료까지) 몇 주 안에 그 내용에 도달 할 것입니다."

가장 큰 장애물은 돈입니다. 모든 것이 녹색 국물이라면 무언가 잘못되었다고 말하기가 훨씬 어렵고 변경이 필요합니다.

행운을 빌어 요.

반대로, 기한이 빠진 마감일, 비현실적인 기대치 및 잘못 계획된 프로젝트를 처리하는 데 필요한 민첩한 방법 인 것 같습니다.

경영진은이 새로운 버즈 단어에 관심이 있음을 나타 냈습니다. 아마도 그들은 제품의 마케팅을 강화하기 위해 그것을 사용하기를 원할 것입니다. 이 반드시 나쁜 것은 아니지만, 당신이 민첩한 방법 작동하게하려면 매우 신중하게 관리해야합니다 위해 당신.

전투의 절반은 경영진으로부터 바이 인이되고있다. 애자일이라는 개념을 받아들이는 것이 대부분의 싸움입니다. 나머지는 기대치를 관리하여 계속 민첩하게하기를 원하고, 관리자가 프로젝트 관리에 대한 통제력이 손가락을 통해 크게 미끄러지는 것처럼 느껴질 때 언제라도 마음이 상하지 않게하는 것입니다.

귀사가 무엇이든 결정하기 전에 반나절 세미나와 워크샵을 위해 애자일 코치를 만나는 것이 좋습니다. 애자일이 자신에게 효과가 있다고 생각하는 것과 그렇지 않을 것 같은 것에 대해 팀, 관리자 및 개발자 모두에게 모두 생각하십시오. 반면에 경영진이 귀하의 판단을 신뢰하는 경우, 여러 민첩한 관행과 방법에 매우 익숙해 져야하고 세미나 나 자신 만의 세미나를 만들어야합니다. 개인적으로, 나는 숙련 된 코치를 데려와 많은 시간을 낭비하지 않고 운동량을 유지하기 위해 노력하고 있습니다. 그 동안, 좋은 애자일 책 몇 권을 참고 문헌으로 들고 철저히 읽은 다음, 관리인이 볼 수있는 책상 주위에 매달아 두십시오. 잠재 심리학은 당신이 묘사 한 것과 같은 상황에서 놀라운 일을 할 수 있습니다.

최소한 다음을 읽는 것이 좋습니다.

• 린 소프트웨어 개발 -Mary & Tom Poppendieck
• 민첩한 소프트웨어 개발 -Robert C. Martin

그리고 추가 신용을 위해 (내가 언급 한 다른 책의 훌륭한 동반자라고 생각하기 때문에) :

• 깨끗한 코드 -Robert C. Martin