차례:
민첩한 소프트웨어 개발 팀이된다는 것은 사람마다 다른 의미를 지닙니다. 매우 광범위한 스펙트럼에 걸쳐 채택 정도가 있으며, 잘한다고 생각하는 조직은 거의 없습니다. VersionOne의 State of Agile Survey (2017 년 4 월 발표)에 따르면 응답자의 80 %가 "아직 성숙 수준 이하"라고 답했습니다. 불행히도 개발 팀은 반복의 "학습"부분에 많은 노력을 기울이지 않는 경우가 많습니다. 우리는 서둘러서 스크럼 의식을 끝내고 코드 작성으로 돌아가고 싶습니다. 결국해야 할 일이 너무 많습니다! 하지만 부족한 코딩 시간이 정말 문제일까요?
우리 중 많은 사람들에게 소방은 직업 설명에 구체적으로 나열되어있을 수 있습니다. 우리는 순간적으로 장대 아래로 미끄러 져 내려가 모자를 움켜 쥐고 트럭에 올라 타야한다는 것을 알고 매일 출근합니다. 우리는 그것을있는 그대로 받아들이고 우리가 할 수있는 일이 없다고 가정합니다. 그러나 우리 투쟁의 근본 원인이 심각한 효율성 부족이라면 어떨까요? 다른 회사보다 더 잘하는 것이 얼마나 중요한지 누구나 알고 있습니다. 우리는 거기에 도달 할 수없는 것처럼 보입니다. 대역폭이없는 것 같습니다. 관리자는 더 많은 사람을 추가하고 조직의 규모를 늘려도 여전히 동일한 어려움을 겪고 있습니다. 팀이 소프트웨어를 효율적으로 개발하지 못하기 때문에 (그리고 혼자가 아니기 때문에) 고비를 극복 할 수없는 것 같습니다.
효율적인 개발의 원칙
Pixabay
그렇다면 무엇이 우리를 비효율적으로 만들까요? 우리 대부분에게 가장 먼저 떠오르는 것은 자동화 (자동화 된 빌드, 배포, 테스트)의 부족입니다. "우리가 충분한 자동화를 갖추면 삶이 좋아질 것입니다." 불행히도 그것은 해결책의 일부일뿐입니다. 재 작업이 프로젝트에 미치는 영향을 고려하십시오. 기능을 빌드하는 가장 효율적인 방법은 올바르게 한 번 빌드하고 다시 돌아가서 터치하지 않는 것입니다. 버그, 리팩토링 및 기타 유사한 활동은 환자가 수술실을 떠난 후 본질적으로 환자를 재개하고 그와 관련된 내재 된 위험이 있습니다. 재 작업을 없앨 수는 없지만 최소화하기 위해 노력해야합니다.
"하지만 애자일은 재 작업 (예: 리팩토링)을 수용하지 않습니까?" 애자일 제작자는 재 작업의 두 가지 주요 원인이 예상치 못한 상황과 변화하는 비즈니스 요구 사항이라는 사실을 이해했기 때문입니다. 인간은 미래를 예측하는 데 끔찍한 것으로 나타났습니다. 민첩한 제작자는 또한 개발자가 "금도금"이라고 부르는 것이 비 효율성에 크게 기여하는 요인이라는 사실을 이해했습니다. 최종 사용자가 실제로 요청한 적이 없는데도 누군가가 사용할 것이라고 생각하는 기능을 담았습니다. 그것은 당신의 소프트웨어 제품을위한 돼지 고기와 같습니다. 그것은 완전한 시간 낭비입니다. "그들이 요구하는 것이 볼보뿐이라면 우주 정거장을 건설하지 마십시오." 따라서 기업은 현명하게 돼지 고기를 버리고 리팩토링을 채택하고 분명한 필요가있을 때만 기능을 추가하기 시작했습니다. 그러나 삶의 예측 불가능 성은 재 작업의 유일한 원동력이 아닙니다.
기능 개발의 모든 단계에서 누락 된 세부 정보는 궁극적으로 시간과 비용을 낭비하게됩니다. 효과적인 사전 협업은 시간이 지남에 따라 많은 재 작업을 절약 할 수 있습니다 (요구 사항 누락, 근시안적인 설계 등을 처리). 우리 모두는 사각 지대가 있고 우리 모두는 추가 눈이 필요합니다. 많은 개발 팀이 코드 검토 중 백엔드에서이를 수용하지만, 최소한의 투자로 문제를 저렴하게 해결할 수있는 초기에 협업에 훨씬 적은 에너지를 투자합니다.
기능을 구현하고 요구 사항 / 설계 논의 중에 포착해야 할 중요한 결함을 마지막에 발견 한 적이 몇 번입니까? 마치 애틀랜타에서 몽고메리까지 운전을하면서 실수로 버밍엄으로 운전 한 여행에 몇 시간이 걸린다는 사실을 깨닫는 것과 같습니다. 중요한 요구 사항을 놓 쳤기 때문에 나중에 환자를 다시 열 때만 코드를 올바르게 가져 오는 데 얼마나 많은 시간이 걸렸습니까? 집단 지능을 활용하면 절대적으로 시간과 비용을 절약 할 수 있지만 개발자는 종종 기능을 분리하여 작업합니다.
전통 무리
Pixabay
전통적인 스웜은 팀이 동시에 작은 기능에 대해 작업하는 여러 사람과 함께 스토리에 대해 공동 작업하여 피드백 루프를 단축하고 기능의 전체 완료 시간 (예: 분할 및 정복)을 줄이는 것을 의미합니다. 이것은 본질적으로 각 분야 (백엔드 개발자, UI 개발자 등) 내에서 밀집되어 있습니다. 개발이 시작되기 전에 UI 개발자는 동시에 수행 할 수있는 독립적 인 작업을 식별하기 위해 노력합니다. 그들은 각 사람이 자신의 작품이 전체에 어떻게 맞는지 알 수 있도록 인터페이스 포인트를 논의합니다. 그런 다음 팀 구성원은 할당 된 작업을 완료하고 통합 중에 마지막에 모든 것을 통합 할 수 있습니다. 빈번한 커밋과주기적인 코드 검토는 모든 것이 레일에 머물러 있는지 확인하는 데 도움이됩니다. 이 접근 방식에는 개발자 간의 협력이 필요합니다.어쨌든 더 나은 최종 결과를 만드는 데 도움이됩니다. 우리는 종종 잘못된 코드를 작성하지 않도록 시간이 지남에 따라 코드 (모든 코드)를 작성하는 데 소요되는 시간을 우선 순위로 둡니다. 잠재적으로 절약되는 시간을 고려하면 값이 명확 해집니다.
차단 해제
Pixabay
군집에 대한 또 다른 귀중한 접근 방식은 여러 분야에서 동시 개발을 촉진하기 위해 초기에 종속성 완화에 팀을 집중시키는 것입니다. UI 기능의 자연스러운 개발 흐름을 고려하십시오. 자동화 테스터 (SDET)는 테스트 할 작업 UI에 의존하고, UI 개발자는 작업 백엔드 API에 의존하며, 백엔드 개발자는 구성, 데이터베이스 업데이트 및 자동화 된 빌드 / 배포에 의존합니다. 따라서 UI 개발자는 API가 완료 될 때까지 작업을 시작하지 않을 수 있으며 SDET는 기능이 완료 될 때까지 작업을 시작하지 않을 수 있습니다. 각 분야는 독립적으로 작동하므로 상호 작용해야하는 사람들이 다른 일에 바쁘기 때문에 협업을 방해합니다.그러나 이전에 종속성을 완화하고 모든 분야가 동일한 기능에서 동시에 작동하도록 할 수 있다면 어떨까요?
여기 몇 가지 예가 있어요.
1. 스텁이있는 배포 된 기능적 UI
SDET 차단을 해제하기 위해 UI 개발자는 테스트를 작성할 수있을만큼만 작동하는 UI를 제공 할 수 있습니다. 백엔드 API 통합 및 CSS 스타일은 여전히 보류 중일 수 있습니다. Selenium과 같은 자동화 된 테스트 프레임 워크는 이러한 작업이 완료되지 않았는지 상관하지 않기 때문입니다. 그것은 모두 연기와 거울이 될 수 있습니다. 일부 재 작업을 유발하는 변경이 발생할 수 있지만 테스트를 일찍 시작하는 이점이 그 위험을 능가합니다.
2. 배포 된 백엔드 API (스텁 형, 하드 코딩 된 데이터)
UI 개발자가 테스트 할 수있는 백엔드 API를 제공하면 프런트 엔드와 API 간의 통합 문제를 조기에 감지 할 수 있습니다. 제공 한 API가 프런트 엔드 개발자의 요구를 충족하지 못하는 경우가 있습니다. 전체 호출이 누락되거나 서명이 잘못되었거나 데이터 구조에 문제가있을 수 있습니다. 연결이 끊어진 경우 문제가 강화되기 전에 조기에 알아내는 것이 좋습니다.
3. 새 응용 프로그램 및 서비스의 HelloWorld 버전을 만듭니다.
새 서비스 (예: 마이크로 서비스)가 필요한 경우 리포지토리를 만들고 서비스의 "hello world"버전을 빌드합니다. 이를 통해 서비스가 실제로 개발되기 전에 dev-ops 리소스가 Jenkins 작업 및 배포 스크립트에서 시작할 수 있습니다.
이러한 최적화는 변경이 필요한 구성 요소에 대한 개발이 완료되기 전에 누군가 "다른 것이 필요합니다"라고 말할 수있는 초기 피드백 루프를 촉진합니다.
마무리
작업중인 기능에 대한 출시 시간을 단축하는 방법을 알아내는 것이 매우 중요합니다. 비즈니스는 진행중인 여러 기능을 통해 가치를 얻지 못하며 개발자는 가능한 한 주입 지점에 가깝게 결함을 해결할 수 있도록 기능을 신속하게 구현해야합니다. 개발자들은 또한 그들이 정말로 원하는 것은 코드를 작성하는 것임에도 불구하고 서로 상호 작용할 필요가 있습니다. 더 나은 제품을 원하는 최종 사용자를 포함하여 관련된 모든 사람에게 더 좋습니다. 당신이 그것을주지 않으면, 그들은 그것을 찾기 위해 다른 곳으로 갈 것입니다.
사람들이 시간을내어 방법을 배우는 경우 Swarming은 조직의 도구 상자에서 매우 귀중한 도구입니다. 그것은 프레임 워크 나 활동이 아니라 사고 방식입니다. 모든 사용자 스토리에 대해 팀 구성원은 스스로에게 두 가지 질문을합니다.
- 여러 사람이 한 번에 기여할 수 있도록이 이야기의 작업을 어떻게 구성합니까?
- 나를 기다리고있는 사람의 차단을 해제하려면 최소한 무엇을해야합니까?
팀이 여러 기능을 독립적으로 천천히 구축하지 않고 빠르게 함께 구축한다면 어떨까요? 그들은 실제로 변화하는 비즈니스 요구 사항에 대응하고 비즈니스 요구 사항을 충족해야 할 때 비즈니스 요구 사항을 충족 할 수 있습니다. 경쟁자들은 당신을 두려워하고 고객들은 당신을 사랑할 것입니다. 그것은 성공적인 사업을위한 비결입니다.
© 2017 Mike Shoemake