싱글 프로그래머를위한 스크럼? [닫은]

저는 소규모 회사에서 영업 및 교육 역할을 담당하는 기계 엔지니어와 설계, 개발 및 지원 역할을 담당하는 회사 회장으로 구성된 "Windows Expert"로 청구됩니다.

저의 역할은 일반적으로 동일하지만 주로 Windows의 최신 버전에서 실행하기 위해 제품에 필요한 모든 프로그래밍을 설계하고 구현합니다.

나는 웹 캐스트에서 주어진 스크럼 패러다임에 대한 개괄적 인 개요를 보았습니다. 제 질문은 : 개발 작업 항목이 일반적으로 "제품의 국제화 및 현지화"와 같이 매우 높은 수준으로 제공된다는 점을 감안할 때 제품 개발에 대한 이러한 접근 방식에 대해 더 많이 배울 가치가 있습니다.

그렇다면, 한 명의 프로그래머 만 사용하도록 Scrum을 적용하는 방법을 제안 하시겠습니까? 클라우드 기반 또는 그 밖의 어떤 도구가 그 목적에 유용합니까?

그렇지 않다면, 한 프로그래머가 매일 자신의 노력을 조직하기 위해 어떤 접근법을 제안 하시겠습니까? (아마도 질문은 간단한 질문으로 축소됩니다.)

스크럼 배우기 : 예. 그것에 대해 배우고 일반적인 기술 세트에 추가하십시오. (그러나 "Scrum-ban"의 풍미는 아마도 당신이 찾고있는 것입니다 ...)

스크럼은 훌륭한 프레임 워크이지만 핵심 교리는 "반복 (스프린트)은 고정 된 지속 시간입니다"라는 것입니다. 나는 작은 팀에서이 작업을 본 적이 없습니다. 고정 된 시간 상자 (1 주일)에 실제로 가입하고 일할 수 있다면 Scrum은 멋진 프레임 워크입니다. 당신이 할 수 없다면 ... 스크럼은 다른 것들과 잘 어울리는 좋은 개념을 가지고 있기 때문에 배우기에 좋습니다.

백 로그-스크럼 여부에 관계없이 우선 순위가 지정된 작업 목록을 유지하십시오. Excel (또는 Google Doc Spreadsheet ...)이 마음에 듭니다. 당신이 아주 작은 팀이라면 나는 아주 작은 도구를 유지할 것입니다. (스프레드 시트 >> 워드 프로세서는 쉽게 정렬 할 수 있기 때문에.)

계획과 커밋의 분리-추상적 표기법 (점)으로 계획하고 일관성을 유지하십시오 (8 점은 약 2 배, 4 점, 4 배는 2 점 이야기) "작업을 수행"할 때 문제를 다시보고 스케치하십시오. 몇 시간 안에. 포인트를 변경하지 마십시오.

헌신-약속 할 때 다른 사람에게 공개하고 약속을 이행

회고-당신이 전달 한 후, 더 잘했을 수있는 일에 대해 생각해보십시오.

등

스크럼은 그것이 좋은 출발점이 될 수 있음을 이해하기 쉽습니다. 원하는 경우 "Scrum-ban"변형 ( http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban)을 사용하는 것이 좋습니다. 그것을 지원하기 위해 합리적으로 활동적인 커뮤니티와 함께 ​​"잘 문서화"된 것이 없습니다.

또한 Alistair Cockburn의 Crystal 방법론 (http://alistair.cockburn.us/Crystal+methodologies+main+foyer 및 http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Small / dp / 0201699478 / ref = ntt_at_ep_dpt_3 )이지만 더 많은 읽기 및 파기를 포함합니다.

XP와 같은 것들이 특정 관행에 대한 자세한 내용을 제공하므로 다음 책을 읽으십시오. http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= books & ie = UTF8 & qid = 1304359834 & sr = 1-1

최종 독서 조언 : 애자일 선언문에 동의하고 원칙을 준수하는 한 http://agilemanifesto.org/principles.html 당신은 괜찮은 모양이어야합니다.

개인 권장 사항 : TDD (협상 불가능, IMHO) 채택 백 로그 유지 (스크럼 별) 항상 우선 순위에 따라 크기와 정렬을 유지하십시오. "중단 사이에 너무 큰 일"을 소규모 청크로 분해하십시오. 두 항목이 동일한 우선 순위를 갖습니다.) 5-10 분 내에 빌드 환경을 빌드 / 테스트 / 배포 (실험실 환경으로) 할 수 있도록합니다. 고객 (내부 및 외부)에게 스토리 완료 결과를 보여줍니다. 고객이 동의합니다. 현재 스토리를 완성 할 때 더미 맨 위에서 스토리를 가져와 작업하십시오. 한 번에 두 개 이상의 항목을 열어 두지 마십시오. 주의를 분산시키기 전에주의를 분산 시키십시오.

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

제품 백 로그, 우선 순위 지정, 상대 추정, 증분 전달과 같이 Scrum에서 사용되는 일부 관행을 사용할 수 있지만 전체 Scrum을 자체 조직의 교차 기능 구성원 팀이 제품 개발을 관리하는 프로세스로 사용하는 것은 한 사람의 공연에 적합하지 않을 수 있습니다. .

문제는 작업 항목을 작은 조각으로 나누고 점진적으로 전달할 수 있는지 여부입니다. 대부분의 관행을 사용하지 않으면 의미가 없습니다. 또한 Scrum은 제품 소유자 / 고객과의 높은 협력에 관한 것입니다. "여기에는 과제가 있고 일단 완료되면 다시 돌아 오십시오."

1 인 Srum에 대해서는 반대의 말은하지 않지만, 1 인 Kanban 풀 시스템은 매우 잘 작동한다고 말할 것입니다. 자동화 된 단위 테스트와 함께 Kanban을 사용하면 훨씬 더 생산적이고 "문서화"되었습니다. 실제로는 방법론이 아니지만 더 많은 도구 (그리고 그와는 매우 다른 도구)이지만 둘 다 큰 솔로 프로젝트를 한 입 크기로 나눌 수있게 해 줄뿐만 아니라 더 많은 일을하도록 격려하는 일종의 의식을주었습니다. 일. "모든 테스트 실행"을 클릭하고 각 항목이 녹색으로 바뀌는 것을 보는 것만 큼 만족스러운 것은 없습니다. Kanban 보드의 "진행 중"열에서 "테스트 중"으로 카드를 가져가는 것 (또는 보드 전체에서 제외) .

솔로 작업의 실제 문제는 개발자 그룹을위한 여러 방법을 선택하고 선택하여 자신에게 가장 잘 맞는다는 것입니다. 최종 목표는 실제로 책임감, 생산성 및 행복을 유지하는 것입니다. 누가 자신보다 더 잘하는 방법을 알고 있습니까?

나는 한 시점에서 혼자 일할 때 이것을 시도했습니다. 잘 작동하는 것은 다음과 같습니다.

1. 모든 작업 항목을 화이트 보드에 둡니다. 나는 뛰어난 작업이 무엇인지 매우 빨리 알 수있었습니다. 의존성과 막힘이 있었던 곳. 또한 많은 사람들이 내 보드에 들러서 읽어 보았습니다. 우리는 그것에 대해 이야기 할 것입니다. 나는 그들이 "괴짜"가 하루 종일 무엇을하고 있는지 이해하는 데 도움이되었다고 생각한다 ;-)
2. 번 다운 차트도 훌륭했습니다. 방금 Excel을 사용했습니다. 그 환경에서 더 나은 견적을 얻을 수있었습니다. 반복으로 어디로 향하고 있는지에 대한 훌륭한 개요를 제공했습니다. 기술 담당자가 아닌 내 관리자는 기능과 관련된 모든 다른 항목과 위치를 볼 수 있으므로 이것을 좋아했습니다.
3. 매일 일어 선다. 최선을 다해 매일 아침, 나는 모든 작업 항목과 번 다운 차트를 업데이트하고 해결해야 할 모든 장애를 기록했습니다.
4. 자동화 테스트 및 연속 통합 (MSTest / TFS), 바람직하게는 TDD는 모든 방법론을 사용하여 모든 개발 팀에 도움이되지만 여기서 언급 할 가치가 있습니다.
5. 짧은 반복 (1 주)은 실제로 무언가를 제공하는 데 집중하는 데 도움이되었습니다.
6. 백 로그를 유지하는 것은 새 작업을 받았을 때 다른 모든 작업의 ​​맥락에 배치하고 제품 소유자가 우선 순위를 다시 잡을 수있게하는 것처럼 훌륭했습니다.

작동하지 않은 것은 다음과 같습니다.

1. 혼자서 일할 때, 같은 생각을 가진 사람들과 협력하는 데 결코 도움이되지 않습니다. 또는 정말 큰 사기와 문화를 가진 팀에서 나온 경쟁과 집중력. 당신이 붙어있을 때 선택할 수있는 다른 두뇌가 없으므로 매일 그런 일에서 스크럼 마스터가 그와 같은 막힘을 제거 할 수 없습니다.
2. 스크럼 마스터가 없으므로 중단을 막을 사람이 없습니다. 나는 사람들이 끊임없이 다른 것들에 대해 질문하고 흐름을 깨뜨리는 데 많은 어려움을 겪었습니다. 좋은 스크럼 마스터 하에서, 그런 것들이 가로 채서 당신은 탈 수 있습니다. 나는 사람들에게 무례하고 싶지 않았으며 (아마도 부드럽다) 문제였습니다. 또한 스크럼 마스터가 없으면 프로세스를 쉽게 벗어날 수 있습니다.

재미있는 운동 이었지만 조금 후에 그 일을 그만 두었습니다. 전통적인 폭포 팀과 달리 스크럼의 이점을 고려해야한다고 생각합니다. 그러나 당신이 혼자있을 때 둘 다 일종의 약탈입니다. 의사 소통이나 협업 문제가 없습니다. 설정 한 작업을 수행 한 다음 완료하면됩니다.

나는 모든 사람들이 백 로그를 유지하고 TDD를 수행해야한다고 생각합니다.

단일 개발자 세계에서 의미가 있다고 생각하는 애자일 / 스크럼 / 칸반 요소 :

1. 칸반과 같은 색인 카드에 사용자 스토리 / 액티브 백 로그 항목을 구성하는 보드를 준비하십시오.

2. 다음 원칙의 가치에 대해 비 개발자로부터 바이 인을 확보하십시오.

   • 저의 우선 순위를 바꾸거나 미세 관리 (스프린트 지점)없이 일할 시간을주십시오. 시간을 줘서 내가 할 수있는 일을 정확히 알아 내려고 노력하고 최선을 다해 그 일을 할 것입니다.

   • 무언가가 필요하고 (차단됨) 내가 찾아 와서 분류 할 수없는 경우 스프린트가 비정상적으로 취소되어야 할 수 있습니다. (새로운 계획이 필요하다는 의미입니다.)

   • 스프린트 도중에는 아무것도 바꾸지 않습니다. 또는 그렇게하면 스프린트를 취소하고 새로운 스프린트를 만듭니다. 이런 일이 많이 발생하면 생산성이 떨어집니다.

   • 이해 관계자와의 의사 소통은 일상적인 스탠드 업 미팅에서 발생할 수 있으며, 이는 개발자의 하루의 성과를 포함하여 일반적인 스크럼과 거의 동일한 내용을 전달합니다. 기본적으로 생각보다 오래 걸렸거나 잘 진행된 사항과 구현 계획에 대한 조정 내용을보고 할 수 있습니다. (새로운 버그 4 개를 찾아서 기록했는데,이 옵션 기능보다 더 중요하다고 생각합니다. 따라서 시간을 보내고 수정하고이 옵션 기능을 푸시 할 것이라고 생각합니다.)

나는 단일 개발자로서 많은 일을 해왔으며, 단일 개발자와 그의 비 개발자 감독자 / 보스 간의 신뢰와 좋은 의사 소통은 방법론이 아니라 열쇠라고 확신 할 수 있습니다. 그러나 좋은 원칙을 따르면 항상 더 효과적 일 수 있습니다.

이에 대한 블로그를 읽었으며 귀하의 질문에 도움이 될 것이라고 생각합니다.

첫 번째 부분 : http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

두 번째 부분 : http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

이 블로그에서 더 많은 정보를 찾을 수 있습니다.

나는 결코 연결되어 있지 않다. 내가 좋아하는 것 중 하나. 그것이 당신을 도울 수 있기를 바랍니다.

예. 그리고 Scrum에는 멋진 도구가 필요하지 않습니다. 모든 사람들이 자신이 작업하고있는 것에 대해 이야기하는 간단한 15 분 스탠드 업 미팅 일 수 있습니다. Scrum의 장점은 모든 사람이 진행 상황을 알고 있으며 문제가 발생하기 전에 문제를 해결하기가 더 쉬워지고 문제가 발생할 가능성이 있다는 것입니다.

이러한 답변 중 많은 부분에 중요한 요점이 없습니다.

스크럼 팀은 프로그래머만으로 구성 할 필요가 없습니다.

동료 중 하나는 '디자인'/ '개발'을하고 다른 하나는 '판매'를합니다.

아마도 '판매'동료가 제품 소유자 (프록시) 일 수 있습니다. 고객의 기대는 무엇입니까?

다른 동료의 디자인과 개발은 정말 스크럼 팀의 훈련과 같습니다. 스크럼 개발은 단계적이지 않고 수직적입니다 (한 번의 스프린트로 요구 사항을 철회하고 설계 및 구현).

세 사람과 함께 스크럼 프로세스를 수행 할 수 있습니다.

'이것'을 수행하는 데 무엇이 필요합니까? 스크럼의 스프린트 계획 회의는 '이것'이 무엇인지에 대한 질문을 확대합니다. 제품 소유자는 제품이 완료된 것으로 간주하기 위해 무엇을 기대합니까?

스프린트 계획 회의에서 '제품의 국제화 및 현지화'가 기술적으로 구현하기 어려운 이유에 대해 다른 동료에게 컨텍스트를 제공 할 수 있습니다.

스크럼 임호를 ​​사용해야하는 많은 이유.

Kanban을 시도하고 기본 사항 인 시각화 및 진행중인 작업 제한 (WIP)부터 시작하는 것이 좋습니다.

나중에 중단하더라도 프로세스가 더 민첩 해집니다. Kanban은 "정상적인"소프트웨어 개발에 적합하지만 Kanban + 흐름 기반 프로세스 (반복이 아닌)는 새로운 기능 개발 및 유지 관리가 모두 필요한 상황에서 다른 프로세스 도구보다 뛰어납니다.

나는 David Anderson의 Kanban 책의 추천을 두 번째로, 간단한 Kanban을 시작하는 이유와 방법 에 대한 현지 모임 이나 짧은 소개를 위해 crisp.se/kanban에 대한 슬라이드를 살펴볼 수도 있습니다 .

당신의 맥락에서 나는 몇 가지 생각을 가지고 있습니다.

• 가시성 이 핵심이므로 (큰) 화면에 영구적으로 표시 할 수없는 경우 (공동 위치에있는 경우) 디지털 도구보다 실제 화이트 보드를 사용하십시오.
• 현재 프로세스로 시작
• 업스트림 및 다운 스트리트 핸드 오프 단계를 포함하여 영향력이있는 영역만으로 시작하십시오 (예 : 개발 준비된 기능 또는 사용자를위한 큐, 완성 된 기능, 판매 준비)
• 동료들이 시각화 업스트림 또는 다운 스트림 시각화에 관심이 있다면 더 좋습니다. 회사의 전체 가치 흐름 (또는 네트워크), 즉 개념에서 현금으로 가치가 흐르는 방식을 시각화하게 될 수도 있습니다.
• WIP를 제한하여 멀티 태스킹 (!)을 최소화하십시오. 업무 흐름이 동료에게 보이는 경우, 이유를 이해하고 접시에 무엇이 있는지 쉽게 볼 수 있어야합니다.
• 작업을 3 또는 4 개의 작업 유형 (서비스 클래스)으로 분리하는 것이 유용 할 수 있습니다. f.ex. 버그, 중요한 문제, 마감일이있는 작업, 마감일이없는 작업
• 어딘가에 병목 현상이 발생하거나 작업이 차단되거나 다소 예측 가능한 패턴으로 작업에 "굶주림"이있는 경우 작업 흐름이 어떻게 진행되는지 관찰하십시오. 디지털 도구를 사용하는 경우 마지막 슬라이드 중 일부를 참조하면 장기적으로 더 쉽습니다.
• 단계별 작업 흐름 개선

지금 결정을 내리는 동안 지금 무언가를 시도하고 싶다면 지난 주에했던 것처럼 벽이나 창문이나 찬장 에서 개인 칸반 을 시도하는 것이 좋습니다 ...

여기에있는 다른 모든 대답을 읽은 후 간단한 실용적인 대답은 다음과 같습니다.

업무 수행에 도움이되는 것을 배우기 위해 사용중인 프로세스 또는 기술 또는 방법을 사용하십시오.

이제 이것은 매일 종교적으로 업무의 우선 순위를 정하는 것을 의미 할 수 있습니다.

백 로그를 해결한다는 의미 일 수 있습니다.

그것은 당신의 상사에게 진척 상황을보고하는 것을 의미 할 수도 있습니다.

모든 종류의 방법이나 기법을 사용할 수 있습니다. 궁극적으로는 밤에 더 잘 자게됩니다.

작동하는 물건 (현재 상황에서는)을 수행하고 그렇지 않은 물건은 버립니다.

다음을 제자리에 두지 않는 한

• 들어오는 요구 사항을 구성하고 우선 순위를 지정하는 수단입니다.

• 반복에서 커밋 할 수있는 것을 알 수 있도록 수행 할 노력을 정확하게 추정하기 위해

• 반복 및 지속적인 개선-지속적으로 점검하고 적용하는 반복의 개념은 매우 중요합니다. 이 연습은 실험을 장려하고 지속적인 학습을 구축합니다. 교회의 스크럼, 4 페이지

• 글쎄, 당신은 매일 스크럼 회의를 할 수는 없지만 적어도 오늘 커밋 할 작업을 상기시킬 수 있습니다. 매일 스크럼 회의를 사용하여 팀이 수행중인 작업을 서로 동기화 할 수 있습니다.

• 스프린트 후 반영-스크럼에서 스프린트 회고전이라고합니다. 각 반복이 끝날 때마다 반복 후 발생하는 상황을 반영하고 무엇이 잘못되었는지, 어떻게 개선 할 수 있는지, 어떻게 개선 할 수 있는지,이를 유지하는 가장 좋은 방법은 무엇인지 생각할 수 있습니다 하기

나는 당신이 미니멀리스트 접근법을 취하고 지속적으로 개선함으로써 당신의 요구에 잘 맞는 스크럼을 가질 수 있다고 제안합니다.

스크럼은 필요에 맞지 않고 현재 상황에 적응할 수 없다면 스크럼이 아닙니다.