잘못 구조화 된 소프트웨어 개발 모델을 어떻게 극복 할 수 있습니까?

저는 현재 신입생으로 일하는 회사에 합류했습니다. GIS 소프트웨어 개발 분야의 숙련 된 인원이 제한되어 있기 때문에 그 중 하나이기 때문에 프로젝트 관리자로 직접 채용되었습니다.

Java와 GIS에 정통했으며 프로젝트 기반 관리 및 구조화 된 소프트웨어 개발이 아닌 위치 기반 서비스에 대한 자체 동기 연구를 수행했습니다. 지질학으로 졸업 한 지 1 년이되었고 전년도에는 대학에서 학업을하고있었습니다.

내가 일하고있는 관심과 기회가 생겨 나서 결국 회사의 비즈니스 인텔리전스 부서를 책임지게되었습니다. 회사는 나를 믿었다. 저도 데이터웨어 하우징과 BI 개념을 연구했으며 GIS와 BI를 결합하는 데 성공했습니다.

또한 현재 C # WPF의 BI 도구에서 두 명의 개발자와 함께 일하고 있으며, 개발자는 때때로 개발자의 역할을 수행하고 있습니다.

민첩한 프로젝트 관리를 통해 훌륭한 소프트웨어 개발 방법론을 채택하려고 매우 노력했지만 성공하지 못했습니다. 또한 제품에 관한 한 잘 설계된 코드를 믿지만 CEO가 가지고있는 기술적 지식이 없기 때문에 (나를 직접 능가하는 사람) 일반적으로 코드를 작성하는 데 필요한 시간을 얻지 못합니다. 특정 코딩 언어에 대한 전문 지식 부족 (예 : Java와 반대되는 WPF)으로 인해 소요 시간이 크게 향상되었습니다. 또한 버전 제어 시스템도 없습니다.

나는 그것이 구조화되지 않았기 때문에 일이 진행되는 방식에 극도로 빠져 있으며, 구조화하는 방법에 대해 일하는 것보다 대부분의 시간을 생각합니다. 좋은 경험을 가진 여러분이이 상황을 극복하는 데 도움이되기를 바랍니다.

우리는 약 2 년 전에 일했던 회사에서 (물론 기술적 세부 사항없이) 비슷한 문제를 겪었습니다.

한 번에 한 단계 만 수행하면됩니다. 신속한 소프트웨어 개발을 서두르지 마십시오. 배우고 적용해야 할 것들이 많이 있습니다. 전문 지식이 부족하여 당신을 무너 뜨리지 마십시오.

꾸준하고 확실하게 천천히 (하지만 가능한 빨리 : P) 빌드하십시오.

다음 단계를 권장합니다 (이를 수행하려면 관리에서 개발로 잠시 전환 할 수 있지만 괜찮을 것입니다)

1. 좋은 버전 관리 시스템 을 배우고 잘 배우십시오. 개인적으로 나는 자식이나 수은을 추천합니다. 둘 다에 대한 많은 문서가 있습니다.
2. 관행과 패턴 에 견고한 핵심 을 구축하십시오 . 팀원과 함께 책을 읽고, 블로그를 읽고, 스크린 캐스트를 시청하십시오. 이것은 개발에 새로운 바람을 줄 것입니다.
3. TDD / BDD를 배우고 새로운 코드 및 새로운 기능을 수행 할 때 만질 수있는 기존 코드 에 적용 해보십시오 .
4. 수행 페어 프로그래밍 . 두 머리가 하나보다 더 잘 생각하고, 또한 4 눈이 2보다 낫습니다. :).
5. [정보 찾기 최신 및 가장 일반적으로 사용되는 도구 는 현재 개발중인 언어의 커뮤니티입니다. 그들에 대해 배우고 프로젝트에 그들 중 일부를 포함 시키십시오. 이것들이 어떻게 만들어 졌는지 배우십시오.
6. scrum을 사용하십시오 . 반복, 스토리, 스토리 포인트, 장애는 모두 익숙해 져야 할 개념입니다. 저에게는 스크럼이 소프트웨어 개발 및 관리를위한 최고의 워크 플로우 인 것으로 입증되었습니다. 그것을 적용하고 매일 경험에서 배우십시오.
7. 예를 들어 가르쳐 주십시오. 초보자 개발자의 대부분은 새로운 것을 배우고 싶어하지만 일부는 매우 게으르다. 어쨌든, 당신이 배우고 적용하고 새로운 두뇌를 간질이게 할 새로운 것들을 보여주세요.

또한 가능하면 컨설턴트를 고용하여 프로세스를 확인하고 더 나은 조언을 제공 할 수 있도록하십시오.

게 으르거나 낙담하지 마십시오. 실수로부터 배우고 다른 접근법을 시도하십시오. 이것은 시작에 불과합니다!

편집하다:

최근에 읽거나 사용한 링크와 책 중 일부는 다음과 같습니다.

학습 git : Pro Git

다음은 내가 추천하는 블로그 중 일부입니다 (대부분 .NET 지향).

• 자바 블로그
• Karl Seguin의 블로그 와 프로그래밍 기초 시리즈.
• CodeBetter.com
• 생각한 코드
• 손실 기술자
• 클린 코더
• 또한 스택 오버플로 질문에 대한 링크 입니다.

책의 경우 Amazon에서 Buiding A Solid Programming Core 목록을 볼 수 있습니다 . 나는 또한 이것을 추천 할 것이다 :

• 깨끗한 코드
• 민첩한 소프트웨어 개발, 원칙, 패턴 및 실습
• Pragmatic Bookshelf의 거의 모든 책

관리자 는 프로젝트를 올바르게 완료하는 데 필요한 시간 을 얻는 것이 귀하의 임무 입니다. 대표 이사에 접근 할 때, 확인 당신이 가진 것을 모두 당신을 백업하는 인물과 이유를 왜 그들이으로 추정 긴과 같습니다. 이다 당신 에 관리자로서 책임을 만들 걸리는 이유는 CEO가 이해 n은 주어진 작업을 완료하는 데 시간 / 일 / 주. 이것은 때때로 어려울 수 있지만, 나는 그의 회사가 아직 실패하기 를 원하는 CEO를 만나지 못했고 만약 당신이 그런 종류의 용어로 (다른 모든 것이 실패한다면) 내 놓으면 그는 그의 노래를 바꿀 수 있습니다.

CEO가 업무를 완료하는 데 필요한 시간을주지 않으려는 경우 IMHO는 다른 직무로 넘어가거나 지속적인 사망 행진을 준비 할 준비를합니다. 최후의 수단으로, 비현실적인 기대에서 비롯된 소진을 CEO에게 설명하십시오.

그런 말을하는 데, 당신은 또한 확실히 개발자가 정확한 견적 당신을 제공하고 있는지 확인해야합니다 (대단히 어려운없이 거의 불가능 적절한 또한이 곳에서해야 할 기술 설계).

애자일은 모든 개발 영역에서 좋은 것은 아닙니다. 일부 프로젝트 유형에서는 작동하지만 다른 프로젝트에서는 비참하게 실패합니다. 당신은 당신이 작동하는 하나 발견하기 전에 몇 가지 다른 방법을 시도해야 할 수도 있습니다 잘 .

버전 관리 설정을 가져옵니다 . 실제로 Git을 설정하는 데 5-10 분, 기본 작업을 중단하는 데 몇 분, 고급 개념을 적용하려면 하루나 이틀의 독서가 필요합니다.

흠, 토론토에서 열린 애자일 / XP 행사에서 당신을 만났는지 잘 모르겠습니다.

휴식이 필요한 것 같습니다. 긴 주말을 보내고, 원한다면 취하고, 며칠 동안 일을 잊어라.

자신을 편하게하십시오. 자기 교육은 훌륭하며, 방법론이 관련된 성격과 작동하지 않는다고해서 그것이 잘못하고 있다는 것을 의미하지는 않으며 개인적인 실패가 아닙니다.

프로젝트 관리를 목표로하는 pm.stackexchange.com 사이트 (베타)가 있습니다. 유용한 조언 / 지원이있을 수 있습니다. 그러나 반드시 여기에도 질문을 보관하십시오.

techie 물건으로 이동 :

버전 관리 시스템이 없습니다

하나를 최우선으로 생각하십시오. 도난당한 랩톱에는 로컬로 많은 역사가 없기 때문에 git / mercurial보다 SVN (Subversion)과 같은 중앙 집중식 시스템을 선호합니다. 비밀번호 나 ssh-key와 같은 슈퍼 비밀이 실수로 체크인 된 경우 특히 중요합니다. 그러나 맛의 문제입니다. '수동 버전 관리'의 버그보다 더 많은 시간을 낭비하지 않습니다. 예를 들어 코드를 생각했던대로 되돌려 놓는 것입니다.

행운을 빕니다

다음과 같은 몇 가지 문제가있는 것 같습니다. 1. 비 기술적 고위 경영진과 의사 소통하여 개선 프로그램을 지원합니다. 그리고 2. 성공을위한 개선 프로그램 추진.

번호 1의 가장 어려운 부분은 단순히 고위 경영진이 종종 작업중인 세부 사항에 관심이 없다는 것을 기억하는 것입니다. (만약 그들이 그들에게 넘기지 않고 스스로하고있는 것입니다!) 큰 장애물이 '이유'인 것 같고 CMM 1.1에서 프로세스 개선의 비즈니스 이점에 대한 설명을 원할 수도 있습니다. 프로그램. CMM을 사용하든 실제로 프로세스를 개선하기 위해 다른 것을 사용하든,이 논의에서는 중요하지 않습니다. 더 성숙한 조직이 배달 시간의 변화없이 프로젝트를 더 빨리 전달한다는 것을 보여주는 Carnegie-Mellon 연구의 데이터 만 해당됩니다.

공정 개선에서 성공으로가는 길은 많지만 모두 길다. CMM을 사용한 경험은 레벨 1에서 5로 이동하는 데 8-10 년이 걸릴 수 있음을 보여줍니다. 6 시그마를 사용한 경험은 각 반복이 약간의 개선을 제공하지만 잠재적 인 문제를 대부분 제거하려면 여러 번의 반복이 필요하다는 것을 보여줍니다. 품질의 6 시그마, 작업은 모든 것을 한 번에 교체하려는 위험을 감수하지 않고 완전히 다르게 수행되고 있습니다.

업계에서 일반적으로 사용되는 품질 개선 방법이 있다면, 소프트웨어에 어떻게 적용되는지 확인하고이를 사용하여 회사의 다른 사람들이 이미 잘 알고 있고 지원하는 것에 대해 들어보십시오. 특정 소프트웨어 도구 및 관행에 대해 몇 시간 동안 이야기 할 수 있지만 소프트웨어를 사용하지 않는 CEO는 신속하게 조정합니다. 업계의 표준 관행에 대해 이야기하면 그의 언어로 말하고 있기 때문에 그는 곧 일어날 것입니다. 업계의 공통된 용어로 소프트웨어에 대해 이야기하고, 문제를보다 잘 이해하고 회사의 결과를 개선하려는 계획을 이해하기 위해 관련 질문을 시작합니다.

당신은 이런 식으로 지원을 요청하는 모든 사람을 이길 수는 없지만 아마도 빈칸이 적고 더 많은 승리를 얻을 것입니다!

행운을 빈다!

귀하의 모든 제안은 실제로 합리적이며 많은 회사에 갈 수있는 방법입니다. 그러나 그것들은 보편적이지 않으며, 특히 경험이없는 팀에서는 그렇지 않습니다. 그렇지 않은 이유는 소프트웨어를 설정하고 유지하기 위해 약간의 작업이 필요하기 때문입니다. 심지어 버전 관리조차도 많은 소프트웨어 프로젝트에 대한 테이블 스테이크라고 가정합니다. 그들은 약간의 작업이 필요하기 때문에 약간의 혜택도 제공해야합니다. 그리고 당신의 특별한 상황에서는 그렇지 않을 수도 있습니다! 또는 적어도 결정을 내리는 사람들은 이점을 보지 못합니다!

다른 사람들이 지적했듯이 다음을 수행해야합니다.

• 연습을 차례로 채택하십시오. 한 번에 모두 시도하지 마십시오. 사람들을 압도 할 수 있습니다.
• 이를 위해서는 좋은 순서를 찾아야합니다. 버전 관리부터 시작하겠습니다. 더 쉬운 것들로 가십시오. 일단 사람들이 당신이 올바른 결정을 내린다는 것을 신뢰하기 시작하면 더 위험한 변화를 채택 할 가능성이 더 큰 이점을 보게됩니다.
• 무언가를 구현해야하는 이유에 대한 확실한 사례를 작성하십시오. 최종 사용자에게 지속적으로 진전을 보이고있는 2-3 명의 개발자는보다 정교한 개발 방법론을 채택하는 것을 정당화하기가 어렵습니다. 결과에 중점을 두는 것이 아니라 프로세스에 중점을 둔 것으로 볼 수 있습니다.
• 누구를 설득해야하는지 명심하십시오. 개발자? CEO?