저는 금융 소프트웨어 회사를 시작하고 있으며 민첩한 원칙과 방법을 연구 해 왔으며 아직 보지 못한 개발의 한 가지 측면은 개발자가 개발에 새로운 기술과 기술을 배울 필요가있는 곳입니다. 방법.

지난 몇 년 동안 금융 소프트웨어 작업을 시작하기 전에 비디오 게임 및 GIS 및 생체 인식 소프트웨어에서 3D 그래픽 프로그래머로 일하면서 대부분의 경력을 쌓았으며 항상 절벽에서 벗어나 간단한 방법을 찾아야했습니다. 비행. 나는 항상 성공을 거두었지만 한 번에 너무 많은 100 시간 주와 몇 달을 일하면서 자신을 죽이지 않았다면 내가 살지 않을 것이라고 확신합니다.

3D 그래픽에 대한 혁신적인 요구가 많지 않은 소프트웨어 회사를 시작하면서 개발에 대한 전체적인 접근 방식을 구축하려고합니다.

어자 일은이 문제를 해결하지 못할 수도 있지만, 그렇게한다면, 지식과 전문 지식 또는 경험이있는 사람을 찾을 수 없었습니다.

이것은 실제로 애자일 또는 소프트웨어 엔지니어링과 관련이 없습니다. 모든 비즈니스에 적용되는 것은 사실입니다. 교육을위한 시간을 따로 설정해야합니다. 기간.

애자일 (Agile)은 "지속 가능한 페이스"라는 아이디어를 가지고 있는데, 이는 팀이 무한한 시간 동안 유지할 수있는 것보다 더 열심히 노력해야한다는 것을 의미합니다. 즉 "크런치 타임"이 없습니다. 이것은 훈련으로도 존중되어야합니다. 따라서 팀의 지속 가능한 속도는 "휴식없이 5 시간 이내, 하루에 9 시간 이하, 주당 40 시간 이하"이며 훈련에 10 %의 시간을 제공하려고합니다. 36 시간 동안 프로젝트를 계획해야합니다.

그러나 이것은 애자일과 아무 관련이 없습니다. 그것은 상식과 초등학교 수학입니다.

개인적으로, 나는 하루에 30 분, 주당 1 일 반, 분기마다 1 주일을 허용하는 것과 같이 팀이 서로 다른 크기의 지식 덩어리를 빠르고 일정한 속도로 습득 할 수 있다고 생각합니다.

또한 지식 전수에 도움이되는 몇 가지 애자일 관행이 있습니다. 즉, 팀 전체의 지식 수준의 차이를 완화합니다.

• 매일 회고
• 스프린트 당 회고
• 프로젝트 당 회고
• 페어 프로그래밍
• 탁구 페어링 (빨간색-녹색 리 팩터주기의 모든 단계 후 드라이버와 네비게이터 스와핑)
• 무차별 페어링 (고정 페어 없음, 페어가 무작위로 할당되고 매일 아침과 점심 변경)
• 홀수의 팀 멤버 (페어 프로그래밍을하는 경우 한 팀 멤버가 자유롭게 배울 수 있음)
• 폭도 프로그래밍 (팀 전체가 단일 컴퓨터와 화면을 사용하는 한 쌍의 프로그래밍 변형, 지정된 팀원은 단순히 "전형가"이고 다른 사람들은 그에게 무엇을 쓸 것인지 알려줍니다)
• 무차별 팀 (개발자는 매일 / 스프린트마다 무작위로 팀에 할당 됨)

페어 프로그래밍 및 몹 프로그래밍은 지속적인 코드 검토뿐만 아니라 지속적인 지식 공유를 제공합니다. 탁구 페어링을하면 한 사람이 "키보드를 휘두르는"것을 방지 할 수 있습니다. 무차별 페어링은 전체 팀을 통해 지식을 전파하고, 무차별 팀은 회사 전체를 통해 지식을 전파하며 모든 개발자가 모든 프로젝트 및 모든 코드베이스를 알고 있는지 확인합니다. 또한 코드베이스에서 높은 수준의 표준화로 이어질 것입니다. 회고의 주요 초점은 개발 프로세스에 대한 피드백을 제공하고 그에 따라 적응하는 것이지만, 드문 문제와 그 해결 방법을 전달하는 데에도 사용될 수 있습니다.

말할 것도없이, 고용주는 광범위한 도서관, ACM, Springer, IEEE 등에 유료 구독을 제공 할뿐만 아니라 강의실에서 공부할 수있는 조용한 방과 강의실을 제공해야합니다. 물론 어디에서나 프로젝터는 훈련뿐만 아니라 일반적으로 현명합니다.

나는 Jörg W Mittag가 말한 대부분의 내용에 동의 할 것이지만 "이것은 실제로 Agile과는 관련이 없다"는 말이 아닙니다. 다양한 애자일 기술은 개인과 팀의 학습과 개발을 지원합니다.

애자일 방법은 증분 또는 연속 흐름을 기반으로하는 경향이 있습니다. 두 경우 모두 우선 순위, 가치 및 종속성과 같은 요소를 고려하여 작업이 정렬됩니다. 단기 작업에 중점을두기 때문에 팀은 전달하는 데 필요한 지식을 식별하고 지식이 부족한 경우 적시에 해당 지식을 얻을 수 있도록 계획합니다. 가시성과 투명성은 다양한 애자일 방법의 주요 측면 인 경향이 있으므로 이해 관계자는 팀이 무엇을하고 있는지, 가치를 제공하는 능력을 향상시키기 위해 어떻게 노력하고 있는지 확인할 수 있습니다. 광범위한 학습이 필요한 경우 가까운 미래 또는 현재 반복으로 계획 할 수 있습니다.

팀의 개인이 지식을 얻은 후에는 페어링 및 몰려 오는 기술이 있습니다. 페어 프로그래밍은 익스트림 프로그래밍의 주요 관행으로서 다른 방법에도 적용되었으며 무엇보다 학습을 용이하게하도록 설계되었습니다. Mobbing은 이것을 두 사람 이상에게 적용하고 있습니다. 팀의 긴밀한 협업 및 교차 기능은 사일로가 없으며이 정보가 유포됨을 의미합니다.

즉각적인 작업에 필요한 것을 계획하고 학습 할 수있는 능력이 있더라도 지식이 풍부한 팀원을 확보하는 것이 매우 중요합니다. 도구, 기술 및 도메인에 대해 어느 정도의 기존 지식을 가진 사람들이 있으면 학습 과제를 수행 할 때 더 많은 정보를 얻고 다른 팀 구성원에게 지식을 전파 할 때 더 효과적 일 수 있습니다.

기술을 익힐 시간을 책정하려는 스프린트에 대한 개념 증명 작업을 계획하십시오. 접근 가능한 HTML 테이블을 만드는 방법을 배우는 것과 같이 매우 구체적인 것에 집중하십시오. 스토리에 필요한 기술을 익힐 때까지 개념 증명 작업을 예약하십시오. 각 POC 작업에 스토리 포인트와 마감일을 지정하여 타임 박스를 올바르게 작성하고 스프린트가 끝날 때 진행 상황을 표시하십시오.

숙련 된 개발자에게 스토리가 5 점만 있으면 어떻게 될까요? 어쩌면 각각 8 포인트에서 3-4 작업이 필요할 수 있습니다. 이러한 POC 작업 후에도 스토리는 여전히 5 점에 불과하지만 스토리와 POC 태스크가 최대 40 점을 추가하더라도 5 점 스토리가 40 점이되지 않도록 새로운 기술을 배울 시간을 따로 마련해야합니다.

스크럼은 '스파이크'라는 아이디어를 가지고 있습니다. 팀이 새로운 기술이나 기능을 도입하고 있다면 스파이크는 그 작업을 캡슐화하는 이야기입니다. 따라서 민첩한 스토리는 사용자 중심의 기능성 비트이지만 스파이크의 결과는 배운 내용을 문서화하고 실제 애플리케이션에서 실제로 활용하기위한 작업 분석입니다.

실제로, 최소한 소규모 교육을 관리하는 것이 좋은 방법이라는 것을 알았습니다. 새로운 시스템이나 프레임 워크로 개발자가 속도를 낼 수있을뿐만 아니라 일정에 책임을지게됩니다.

나는 다른 답변에서 이것을 보지 못했기 때문에 많은 조직이 기술 영역 주위에서 길드 또는 장 또는 우수 센터를 시작한다고 덧붙이고 싶었습니다. 기술과 같은 광범위한 주제 나 React Native Development와 같은 특정 주제 일 수 있습니다. 참여 관심이 회사에 있는지 여부에 따라 다릅니다.

어쨌든,이 그룹들은 종종 그룹의 사람들이 전문적으로 성장하도록 돕는 임무를 소유합니다. 이렇게하면 매일 해당 기술을 사용하는 사람과 교차 훈련에 관심이있는 전문 분야 이외의 사람들을 위해 기술을 강화하고 확장 할 수있는 별도의 공간이 만들어집니다. 이것이이 문제에 대한 유일한 해결책은 아니지만 점점 일반화되고있는 것 같습니다.

다른 사람들은 이미 측면을 언급했지만, 민첩한 환경에서 개인 개발에 어떻게 적응하고 있는지 공유하고 싶었습니다.

1. 지속적인 개발

이것은 가장 쉬운 방법입니다. 진행중인 개발을 수행 할 충분한 시간이있을 때까지 각 스프린트의 용량을 줄이십시오. 어려운 부분은 일반적으로 계획을 고수하고 더 많은 다른 작업을 수행 해야하는 경우 개발을 수행하는 것입니다. 비상 사태가 발생하면 이번에는 희생 할 수 있지만 그렇지 않으면 그렇지 않습니다.

용량을 줄 였기 때문에이 범주에서 수행하는 모든 작업은 다른 팀 구성원의 직접적인 관심사와는 별개이므로 각 스프린트에서 특별히 걱정하거나 계획을 업데이트 할 이유가 없을 것입니다.

2. 스프린트 동안 더 큰 노력

내가 찾은 것은 더 큰 영향을 미치는 무언가를 계획 한 경우 (예 : 스프린트 동안 2 일 교육)이를 반영하도록 스프린트를 업데이트해야한다는 것입니다. 나는 이것에 대한 이론적 해결책이 무엇인지 잘 모르겠지만, 사람들이 누군가가 이것에 바쁘다는 것을 알기 위해 교육 작업을 보드에 넣는 것을 종종 보았습니다.

다른 방법으로는 특정 스프린트의 스프린트 용량을 수정할 수 있지만, 사람들이 측정 된 성능 / 효율을주의 깊게 살펴 보지 않으면 나는 이것을 피할 것입니다. 특히 신입 팀에서는 안정성이 정확도보다 더 중요 할 것입니다.

애자일 (Agile)은 일련의 철학입니다. 선언문을 살펴보십시오. 이것이 바로 애자일 (Agile)입니다. 애자일 (Agile)이 어떻게 내 문제를 해결할 수 있는지 말할 때, 애자일에 대해 더 많이 배우는 것이 좋습니다. Agile : SCRUM을 구체적으로 구현해 봅시다. 스크럼에는 스프린트와 스파이크의 개념이 있습니다. 이 두 가지 유물을 통해 학습 예산을 만들 수 있습니다.

스프린트를 원형 차트로 보는 경우 주제를 기준으로 우선 순위를 나눌 수 있습니다. 그런 주제 중 하나는 새로운 기술을 배우는 것입니다!

스파이크는 일반적으로 학습을 통해 무언가의 실현 가능성을 평가하는 스프린트에 대한 연구 작업입니다.

마지막으로, 당신이하고있는 일은 여전히 ​​테이블에 있으며 작업중 인 것을 수행하는 동안 배울 수 있습니다.이 시점에서 기술적 과제에 대처하기 위해 스토리 포인트 / 용량을 늘릴 수 있습니다.

애자일 선언문 자체 를 인용하려면 :

프로세스 및 도구를 통한 개인 및 상호 작용
포괄적 인 문서를 통한 소프트웨어 작업
계약 협상을 통한 고객 협업 계획에 따라
변경 에 응답

귀하에게 가장 적합한 부분을 강조하여 강조합니다.

기본적으로, 잘 훈련 된 민첩한 개발자는 자신의 스킬 셋을 인정하는 사람들보다 변화하는 환경에 훨씬 잘 대응할 수 있습니다.

민첩성에 대한 내 자신의 정의를 추가 할 수 있다면 "고객 협업"을 믹스로 가져올 수도 있습니다. 민첩성의 개념을 바탕으로 민첩성을 가장 잘 정의합니다. 고객 (또는 환경)이 급격히 변화하는 경우 얼마나 잘 대처하고 있습니까? 고객 협업 환경을 조성하는 경우 고객은 팀의 활동에 대해 잘 알고 있습니다.