개발자 무정부 상태 란 무엇입니까?


24

나는 애자일 이후 개발 방법론으로 청구되는 것처럼 보이는 개발자 (또는 프로그래머) 무정부 상태에 대해 읽었습니다. 나는 그것에 관한 몇 가지 자료 ( 1 , 2 )를 찾았 지만 거기에별로없는 것 같습니다.

누군가 내가 그것에 대해 더 많이 알 수있는 좋은 리소스가 있는지 궁금합니다. _ 구현 방법, 장단점, 다른 방법론과 비교 등.


1
전에는 들어 본 적이 없지만 약간 모순되는 것 같습니다. 그들은 "... 형식과 규칙이 창의성과 생산성을 제한하고있다"고 말하지만 동시에 그들은 방법론의 일부로서 정기적 인 회의를 가지고있다. 나는 그러한 방법론의 설명이 규칙을 설정함으로써 시작된다고 믿을 수 없다.
Giorgio

처음으로 그것에 대해 읽었을 때, 그것은 반쯤 애자일 경험이있는 사람이나 사람들에 의해 수행 된 것 같습니다. 이 "개발자 무정부 상태"는 "민첩한 작업 수행"의 교과서 적 예이므로 예 : 적절하게 구현 된 민첩성.
Euphoric

당신이 인용 한 첫 번째 링크는 이미 당신이 찾고있는 모든 것을 포함하고있는 것 같습니다.
Michael Borgwardt

2
참 사랑스러운 유행어!
CesarGon

1
@CesarGon : 버즈 워드는 실제로 새로운 방법론보다 발명하기가 더 쉽습니다. ;-)
Giorgio

답변:


46

나는 '진정한'애자일 프로젝트의 이러한 측면에 대한 Alistair Cockburn의 생각 을 지적 할 수 있습니다.

Crystal 제품군의 방법론 중 하나가 Crystal Clear입니다. Crystal Clear는 다음 단어로 레벨 3 리스너에게 설명 할 수 있습니다.

“워크 스테이션과 화이트 보드가있는 방에 4-6 명을두고 사용자에게 접근합니다. 1 ~ 2 개월마다 실행되고 테스트 된 소프트웨어를 사용자에게 제공하고 그렇지 않은 경우에는 그대로 두십시오.”

사실, 저는 Crystal Clear를 정통한 프로젝트 후원자에게 그러한 말로 설명했습니다. 그는 그 지시를 따르고 5 개월 후“우리는 당신이 한 말을했는데 효과가있었습니다!”라고보고했습니다.

몇 달 후 팀장과 인터뷰를했으며 그의 보고서는 제 지시만큼 짧았습니다.

“당신의 제안에 따라, 우리 중 네 명은 네트워크 연결이있는이 회의실을 인수했습니다. 우리는 4 개월 동안 화이트 보드에 그림을 그리면서 소프트웨어를 제공했습니다. 잘 작동했습니다.”

그것이 민첩성에 관한 것입니다. 이것이 무정부 상태 방법론에 의해 취해진 접근법 인 것 같습니다. 요점은, 만약 당신이 경험이 있다면 , 그들에게 "정리하고 일을하도록"할 수 있고 그들은 그렇게 할 것입니다. . (이것은 경험이 부족한 사람들에게는 효과가 없으며, 주니어 팀이 최소한의 감독 없이는 할 수 없습니다)

일일 스탠드 업 및 스크럼 보드, 제품 백 로그 그루밍 세션, 제품 백 로그 스크럼 보드 그루밍 세션 계획 회의에 대한 사전 회의 회의 등 수년에 걸쳐 구축 된 민첩성에 대한 모든 멍청한 .. 성공적인 제품 배송에 대한 오버 헤드.

그러나 오늘날 너무 많은 것들이 의무적 인 것으로 보이며 '민첩한'방법론은 기존 방법보다 더 많은 과정을 가진 시스템으로 내려갑니다!


14
"오늘날 너무 많은 것들이 의무적 인 것으로 보이며 '민첩한'방법론은 기존 방법보다 더 많은 프로세스를 가진 시스템으로 내려갑니다!": 중요한 점에 부딪 혔습니다 (+1). 나는 숙련 된 개발자 팀과 SCRUM과 함께 일해 왔습니다 .2 년 후 ... 우리는 매일 회의 (매주 2 회 만나지 않았 음)와 다른 많은 활동을하지 않았을 때 더 민첩했습니다. "방법론이 규정 할 때"대신 "팀이 필요하다고 결정할 때"가 발생했습니다.
Giorgio

9
+1. 궁극적으로, 이러한 방법론은 지속적인주기를 나타내는 것이라고 생각합니다. 무거운 방법론은 반복적으로 실패합니다. (일부) 사람들은 프로그래머가 물건을 처리하고 프로세스를 제거하며 일반적으로 작동하지만 충분히 가벼운 프로세스를 시도하기에 충분히 똑똑하다는 것을 알고 있습니다. 불충분하거나 경험이 부족한 팀의 경우 예측에 실패하거나 누락되며 "확실성"및 "예측 가능성"을 높이기위한 프로세스가 추가되며주기는 계속됩니다.
asthasr 2018 년

Gahhh ... 그 사이클은 정확하고 우울하게 들립니다.
Graham


1
@ 시리 온 : 당신이 옳을 수도 있습니다. 숙련 된 프로그래머에게 민첩한 관행이 적용되었다는 내용을 읽었습니다. 그런 다음 경험이없는 팀을 코칭했던 숙련 된 프로그래머는 규칙을 적어야했습니다 (지속적인 코칭 비용이 많이 들고 책에 몇 가지 규칙을 적는 것이 더 낫기 때문). 이런 식으로 SCRUM 등과 같은 새로운 방법론이 개발되었습니다. 사람들은 이제 서적이나 인증을 판매 할 수 있습니다. 그러나 민첩의 진정한 정신은 다른 사람이 작성한 규칙 대신 자신의 상식을 적용하는 것입니다. 규칙은 지침이지만 많은 종교에 의해 고려됩니다.
Giorgio
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.