백엔드 개발자가 사용자 스토리로 정리

백엔드 개발을 사용자 스토리에 수직으로 분할 할 계획이었습니다. 그러나 우리 팀의 백엔드 직원은 이것이 그들의 작업을 볼 수 없게 만든다고 불평하기 시작했습니다.

내 대답은

• 스프린트 계획 및 검토 회의에서 우리는 이해 관계자들 앞에서 백엔드 작업을 논의하여이를 가시화하고

• 프로젝트 중에 높은 품질을 유지하면 다른 팀보다 시작 속도가 느려지지만 프로젝트 중에는 속도가 안정적입니다. 그리고 속도는 이해 당사자들에게 매우 잘 보입니다.

그는 여전히 "개발자로서 비즈니스 로직을 캡슐화 할 수 있도록 도메인 계층이 필요하다"고 주장했다.

팀이 오염되기 전에 문제를 어떻게 해결할 수 있습니까?

이 문제의 근본 원인은 경영진이 백엔드 작업을 보이지 않는 것으로 간주하고 백업 개발자 광부 또는 기타 중대한 용어로 간주한다는 것입니다.

설명 된 상황에는 몇 가지 잘못된 점이 있습니다. 명백한 문제는 백엔드 개발자에 대한 존중의 부족입니다. 이 질문에 애자일 태그가 지정되었으므로 이것이 단지 사회적 문제라는 것을 암시하는 다른 답변을 철회 할 것입니다. 당신의 이야기에는 몇 가지 나쁜 냄새와 반 패턴이있을 수 있습니다. 그중 어느 것도 무지한 관리 나 이야기를 나누는 방법과 관련이 없습니다.

팀의 개인 그룹이 일에서 영광을 얻지 못해 약간의 느낌이 들었다는 사실은 몇 가지 가능한 문제에 직면했습니다.

• 백엔드 개발 만하는 사람들이 없어야합니다. 일반적인 애자일 방식은 공유 코드 소유권을 연습하는 일반 전문가로 구성된 부서 간 팀을 구성하는 것입니다. 개인은 백엔드 또는 프론트 엔드 개발에만 집중해서는 안되지만, 다른 것보다 확실히 경험이 많거나 나을 것입니다.
• 건축은 가치를 얻지 못합니다. 사용자의 관점 (실제로 중요한 관점)에서 레이어 나 도메인 언어가 있거나 솔루션이 프로그래밍되어 있어도 문제가되지 않습니다. 중요한 것은 사용자를 위해 가치를 창출했는지 여부입니다. 백엔드 개발자가 제안한 "스토리"는 넌센스 요구 사항입니다. 이는 사용자 / 고객의 관점에서 원하는 기능을 달성하기 위해 아무 것도하지 않는 설계 결정의 요약입니다. 다시 말해서, 임의의 주어진 사용자 스토리는 수많은 다른 아키텍처 설계에 의해 달성 될 수있다. 백엔드를 전혀 수정하지 않고 사용자 스토리를 완료 할 수 있습니다. 이것은 잘못된 이야기가 아닙니다.
• 체계적으로 생각하는 것은 여전히 ​​중요합니다. 아키텍처는 가치를 얻지 못할 수 있지만 여전히 성공에 매우 중요합니다. 백엔드 개발자에게는 몇 가지 유효한 문제가 있습니다. 시스템을 어떻게 구축 할 것인지 생각해야합니다. 이러한 결정을 내려야합니다. 프론트 엔드 기능 만 모든 영광을 얻는 것임에도 불구하고 전체 시스템이 중요합니다.

저의 추천은 건축을 일류 시민으로 취급하는 것이지만 올바른 방법으로하는 것입니다. 이해 관계자와 함께 품질 속성 워크샵을 수행합니다 . 아키텍처 검토에 주요 이해 관계자를 참여 시키 거나, 중요한 이정표에서 필수 설계 결정을 요약하십시오. 큰 종이에 아키텍처를 그리고 전체 팀이 볼 수 있도록 표시하십시오.

모든 사람이 시스템의 모든 곳 (프론트 엔드 및 백엔드)을 개발하고, 필요한 경우 프로그램을 페어링해야합니다. 사용자 중심의 사용자 스토리를 계속 만듭니다. 또한 시스템이 설계 방식을 설계하고 "백엔드"설계와 관련된 의사 결정을 추진하는 주요 품질 특성 시나리오를 식별합니다. 더 이상 보이지 않게 아키텍처 디자인을 높이십시오.

이것은 사회적 문제인 것처럼 보이므로 사회적 해결책이 필요합니다.

백엔드 개발자가 무시하고 경미하게 느끼고 자신의 작업이 가치가 충분하지 않다고 생각하면 개발 프로세스가이를 변경하기 위해 할 수있는 일은 거의 없습니다.

내가 올바르게 이해한다면, 개발자들은 적어도 "자신의"사용자 스토리를 가져야한다고 생각하는 것처럼 보이며, "이것은 우리가 한 일입니다. 우리는 백엔드 녀석"이라고 말할 수 있습니다. 그러나 이와 같이 "수평으로"슬라이스 된 스토리를 갖는 것은 좋지 않은 생각이며 세로로 슬라이스하는 것에 동의합니다.

가장 좋은 해결책은 문제의 개발자 (개인 또는 그룹)와 조용히 이야기하고 근본적인 문제를 해결하는 것입니다. 언젠가는 관리 부서로 이관해야 할 수도 있습니다.

이 문제의 근본 원인은 경영진이 백엔드 작업을 보이지 않는 것으로 간주하고 백업 개발자 광부 또는 기타 중대한 용어로 간주한다는 것입니다.

실제로 이것이 문제입니다. 이야기로 해결하지 않을 것입니다!

일반적으로 애자일 개발의 특징 중 하나는 투명성입니다. 이것은 또한 조직의 문제가 더욱 명백하게 되었음을 의미합니다 .

이 문제에 대한 표준 민첩한 솔루션은 개발에 대한 "수직"또는 "풀 스택"접근 방식을 채택하는 것입니다. 백엔드 개발자는 단순히 백엔드 계층의 편안한 영역에서 작업하지 않고 위에서 아래로 스토리를 가져옵니다. 프론트 엔드 개발자도 마찬가지로 백엔드 (*)쪽으로 확장됩니다.

다시 말해, 모든 사람이 최종 사용자에게 가치를 제공하게하십시오.

^{(*) 참고 : 모든 스토리에 프런트 엔드 구성 요소 나 백엔드 구성 요소가 필요한 것은 아닙니다. 추가 백엔드 작업없이 UI 요소를 다시 섞을 수 있으며 성능이 특징 입니다.}

당신의 문제는 다음과 같습니다

• 비즈니스에는 목적이없는 관리 계층이 있습니다. 스크럼, 민첩, 상관 없어요 기술에 대한 단서가있는 제품 관리자가 처리하는 비즈니스 문제로 관리 및 개발을 격리해야합니다. 아마도 스티브 잡스에게는 효과가 있었지만, 기술에 능숙하지 않은 관리자가 개발에 가까워지는 건 건강한 일이거나 궁극적으로 팀이 만들 수있는 최고 품질의 제품을 생산하는 데 봉사 한 적이 없었습니다.

• 문제를 해결하는 것보다 외모가 더 걱정되는 개발자가 있습니다. 그것은 매우 심각한 문화 문제이거나 (이것이 "광부"현상을 고려했을 가능성이있는 것으로 보임) / 혹은 개발자 품질 문제가있어서 자신감이 부족하여 충격을주지 않습니다.

계획을 세우지 않고 서있을 필요가없는 사람들을 구하십시오. 백엔드가 프론트 엔드보다 덜 중요하다는 개념을 가진 사람은 그곳에있을 필요가 없으며 실제로 그곳에 있으면서 프로세스를 방해하는 사람입니다.

도랑 이야기. 예, 진심입니다. 그들이 이런 종류의 문제를 일으키고 있다면, 에어 록을 던져 버리십시오. 현재 업무에서 우리는 주어진 작업에 대한 "완료"기준을 고수합니다. 일반적으로 민첩한 생각을하는 사람들 (20 년 동안 꾸준히 변화하고 있음)이이기려는 사용자보다 앱에 더 집중하고 있습니다. ' 편지를 따르지 않으면 효과가 없지만 실제로 전문가라면 문제를 일으키는 어떤 것도 필요하지 않습니다. 무너 뜨리고 어깨 너머로 던져 버려

그리고 당신은 그들이 정말로 걱정해야 할 사람들이 스프린트 계획에 너무 실마리가없는 사람들이 아니라 그들의 직접적인 동료라는 것을 상기하고 싶을 수도 있습니다.