애자일이 잘못되면 [폐쇄]

최근에 탑승 한 일부 새로운 사람들을 위해 애자일 코스를 작성하고 있으며, 애자일이 모든 프로젝트에 해당되는 것은 아니라는 점에주의를 기울이고 싶습니다.

내 문제는 Agile과 함께 작업하는 프로젝트의 특성으로 인해 지금까지 꽤 잘 작동했기 때문에 무엇이 잘못 될 수 있는지, 왜 잘못된 종류의 프로젝트에서 그것을 사용할 때 솔직하게 지적 할 수 없다는 것입니다.

애자일 프로젝트가 잘못 될 때주의해야 할 사항은 무엇입니까?

"Agile"팀의 가장 큰 실패는 Cargo Culting 의 결과입니다 . 본질적으로 팀은 성공적인 민첩한 팀의 효과를 원하므로 가시적 인 행동을 모방합니다.

• 일일 스탠드 업 (1 시간 정도 실행)
• 스프린트로 작업 중단
• 사용자 스토리 (보통 문장보다 약간 작지만 견적이 예상 됨)

이것들은 이러한 환경에서 일관되게 "적용"되지만 실제로는 민첩하다는 약속은 거의 없습니다. 실제로 경영진이 "민첩하게 행동하고있다"고 말하는 것을들을 수 있습니다. (이 두 단어를 도망 치면 나쁜 신호입니다.)

또한 기술적 채무에 대해 많이 듣게 될 것입니다하지만 기술적 부채의 자신의 정의는 "빠른 그것을하고 더러운 어쩌면 우리가 더 나은 나중에 만들기 위해 주위를 얻을 것이다." (번역 : 우리는 유지 관리에 관심이있는 것처럼 들리 겠지만 실제로는 과거에 우리에게 효과가 있었기 때문에 동일한 보일러 실 정신을 유지할 것입니다).

다른 주요 문구 : "이 이야기가 완전히 정의 된 것은 아니지만 우리는 민첩하게 행동하고 있으므로 문제를 해결할 수 있습니다."

"우리는 민첩한 개발을 수행하고 있기 때문에 스프린트 내에서 필요로하는 것을 식별 할 수 있어야합니다."

"우리는 스프린트 초기에 커밋 된 스토리를 막을 수 없어 스프린트 중반에 계속 변화해야하기 때문이다."

애자일 프로젝트의 성공 여부에 대한 핵심 지표는 프로젝트 리더 (스크럼 마스터 또는 그 밖의 역할)가 애자일 프로젝트를 주도한 경험이 있거나 공식적인 훈련을 받았는지 여부입니다. 나는 종종 사람들이 책에서 애자일에 대해 읽거나 스크럼 마스터가되는 2 일 과정을 밟아서 그것을 성공적으로 구현할 수 있다고 생각하는 것을 보았다. 캡틴이 일어나지 않아서 죄송합니다.

민첩성이 무엇인지 이해하지 못하는 사람들은 무엇입니까?

• 마감일까지 의견을 밝힐 수없는 고객
  ... 그리고 법적 조치를 취한 후에;

• 개발자가 클라이언트에서 멀어지게 하는 관리자 (아마도 약간의 임금이 부과되고 배송을 건너 뛰고 해당 클라이언트를 위해 일할 수 있기 때문에) 절망적 인 (종종 성공적인 경우) 시도에서 " 손상된 전화 " 게임을합니다. 바쁘고 유용하게 보일 때

  또한 버섯 관리 , 일명 "분명한 모기, 먹이를 낸 분뇨" 및 뾰족한 머리 보스를 참조하십시오 . :)

• 어느 곳에 도 갈 수없는 팀 ;

• 웅장하고 실용적이지 않으며 실현하기 어려운 UML 사그라 다 파밀리아 를 과도하게 설계 하여 실제 코딩 기술을 완전히 잃어버린 사실과 절실히 주목을 받고있는 한때 유명한 시스템 아키텍처 디자이너의 급여를 유지하고있는 회사 .

민첩한 계약 또는 고정 가격 계약에는 적합하지 않습니다. 그런 짐승에 가입하면 배달해야합니다. 애자일은 고객이 마음을 바꾸고 요구 사항을 '명확하게'바꾸면서 개발을 계속하는 데 매우 능숙합니다. 돈이 다 떨어지 던 날에는 도움이되지 않지만 여전히 일을 끝내야합니다.

그러나 증분 업데이트 및 버그 수정을 수행하는 경우 프로젝트 후 단계에 민첩성이 매우 좋습니다.

애자일이 실패하는 또 다른 측면은 애자일의 결함이 아니며, 이는 완전한 프로젝트 문서, 초기 설계 및 빈약 한 의사 소통과 같은 모든 오래된 것들을 주장하는 사람들의 잘못입니다. ( 반쯤 주장되는 민첩한 선언문 ).

다음은 Agile 시도가 제대로 수행되지 않는 예를 찾는 데 도움이되는 몇 가지 질문입니다.

• 애자일은 새로운 미세 관리입니까?
• 민첩한 프로세스 : 어떻게 그리고 무엇을 문서화해야합니까?
• 새로운 프로젝트에 대한 계획 및 프로그래밍의 올바른 조합

"의사 민첩성"에 대해 들어 본 적이 있습니까? 여기 몇 가지 블로그 항목이 있습니다.

• Pseudo-Agile에서 Waterfall까지 – 작고 새로운 소프트웨어 회사의 길
• 의사 민첩성!

애자일 (Agile)이 무엇인지에 대한 자신의 견해를 취하고 그것을 다른 것으로 정육시킬 수있는 회사에 대해 말해야 할 것이 있습니다.

나는 성공적인 애자일 팀뿐만 아니라 애자일을 시도한 몇 명을 위해 일했지만 성공하지 못했습니다.

성공적인 사람은 다음과 같은 요소를 가졌습니다.

• 진정한 "민첩한"요구 사항. 사용자 스토리가 있었고 우리는 그것을 코드화했습니다.
• 사용 가능한 제품 소유자. 내가 코딩 한 사용자 스토리가 불완전한 경우 제품 소유자에게 쉽게 가서 무엇이 있어야하는지 물어보고 추가 한 후 코드를 완성 할 수 있습니다.
• 프로세스에 대한 헌신과 그것이 학습 곡선이라는 실현.
• 집중된 팀.
• 애자일 방식으로 일하기 위해 애자일 방식을 알고 이해 한 관리자

성공적인 팀은 애자일 (Agile)을 해냈고 실제로 잘 해냈습니다. 위의 사항 중 하나라도 없으면 쉽게 실패 할 수 있다고 생각합니다. 첫 번째와 두 번째 일이 함께 진행되며, 그렇지 않으면 애자일이 작동하지 않습니다.

내가 근무했던 팀은 애자일을 잘 수행하지 못했습니다.

• 경영진의 헌신 부족. 경영진은 철학을 믿지 않았으며 그 결과로 헌신하는 것을 주저했습니다.
• 사용자 스토리가 아닌 다른 곳에 문서화 된 요구 사항. 관리 약속에 대해서는 위를 참조하십시오. 또한, 우리는 누군가가 사용을 정당화하는 데 필요한 고비용의 요구 사항 분석가와 비용이 많이 드는 요구 사항 도구를 보유했습니다.

필자는 이미 경험 한 바에 따르면 민첩하고 구체적으로 Scrum은 경영진과 팀이 진행중인 상황에 대해 많은 가시성을 제공하려는 경우에만 효과가 있다고 게시 한 큰 답변에 덧붙일 것입니다.

즉, 공공 회사 (예 : 정부)에서는 제대로 작동하기가 매우 어려울 것입니다.

민첩하게 생각하는 것은 팀의 문화에 관한 것입니다. 문화가 짜증나고, 팀원이 함께 가지 않고, 사람들이 스프린트 커밋을 충족시키기 위해 협력하지 않으면 문화 나 팀이 부족합니다.

그러나 필자는 폭포가 반드시 그러한 환경에서 작동한다고 말할 필요는 없습니다. 흑백 상황이 아니며, 거의 흑백이 아닙니다.

좋은 애자일 팀은 공동입니다. 그들은 모든 구성원이 같은 목표를 향해 노력하는 부족 공동체 정신을 가지고 있습니다. 팀은 함께 성공하거나 실패합니다. 그들은 문제 해결을 위해 함께 일합니다. 팀원은 어려움을 겪고있는 팀원을 돕기 위해 자신의 작업으로하는 일을 중단합니다. 모든 것이 싱크대 또는 수영입니다.

그렇지 않은 경우 무엇이 잘못되었는지 신속하게 알 수 있습니다. 팀 구성원이 앉아 있거나 랩톱이나 문자 메시지를 입력하거나 매일 스탠드 업을하는 동안 구역을 설정하면 애자일 팀이 부족합니다. 프로젝트 관리자가 모든 스크럼 절차, 정의 및 용어를 시행하고 있지만 모든 사람이 케이던스를 유지하고 립 서비스를 지불하고 있다면 이것이 애자일의 진정성에 대한 미묘한 영향 일뿐입니다. 마감일을 놓치고 프로젝트에 실패했습니다.

Failing Agile은 다소 성공적인 Waterfall 팀보다 여러 가지면에서 좋지 않으며 프로젝트 성공률이 낮을 수 있습니다.

나는 개인적인 경험으로는 이것을 알지 못하지만, 민첩성이 최선의 선택이 아닌 많은 상황이 있습니다.

• 제품이 생명이나 재산에 중요한 프로젝트-예를 들어, 민첩성을 사용하여 맥박 조정기를 실행하는 소프트웨어를 개발하고 싶지 않습니다. 왜? 오류에 대해 거의 제로 오차가 있기 때문입니다. Therac 25 와 관련하여 의학 내 프로그래밍 오류의 고전적인 예를 고려하십시오 . 물론 민첩하게 만들어지지는 않았지만 요점은 다음과 같습니다. 생명이나 재산을 개발하는 것은 "다음 스프린트에서 정리할 것입니다"또는 "좋은 것이 필요하지 않습니다. 충분히."

• 주니어 개발자가 너무 많은 프로젝트-애자일은 참여 그룹 내에서 어느 정도의 자율성을 기대합니다. 팀에 대한 경험이 충분하지 않으면 자율성이 당신에게 불리하게 작용할 수 있습니다.

• 애자일이 전통적으로 제공하는 것보다 더 높은 수준의 제어 또는 계획이 필요한 프로젝트.

나는 다른 누군가가 뛰어 들어 더 나은 예제를 얻거나 내가 쓴 트립을 줄이라고 가정한다. ;-).

당신이 가진 유일한 도구가 망치 일 때 모든 문제는 못처럼 보인다는 것을 기억하십시오. 모든 프로젝트가 손톱은 아닙니다.