GitHub의 주소의 그룹 프로젝트 : https://github.com/ShangXuecheng-git/2019software
A, 스크럼 회의
1, 열 번째 주 회의
2, 주 11 분
둘째, 시험 보고서
셋째, 우리는 문제의 어려움 및 장소를 기쁘게
(제 10 주)
우리는 문제가 발생했습니다 :
1. 먼저, 프로젝트에 대한 책임으로 배워야 그룹의 각 구성원, 많은 것들을은 문법과 첫 접촉, 비동기 프로그래밍 아이디어뿐만 아니라 GitHub의에 자바 스크립트의 사용은, 우리는 전에이 힘내 배쉬를 사용하는 방법과 접촉은 GitHub의에 문제를 게시, 자신의 코드를 업로드하지 않고 로컬 코드를 동기화
2, 우리는 프론트 엔드 인터페이스 디자인에 약간의 차이가 있고, 모든 사람들이 자신의 의견을 가지고, 합의에 도달하기 어렵다
3, 프로젝트 설계는 크게 발전의 효율을 저하, 반복적으로 프로젝트의 구조 조정 선도, 사전에 충분히 설명되지 않는다
우리는 기쁘게 장소 :
1, 우리는 바쁜, 그러나 우리는 적극적으로 작업을 수행 할 수 있지만
이 프로젝트의 베타 단계를 입력 한 후, 우리는 더 큰 영향력을 가지고있다. 우리는 매우 혼란 알파 단계의 시작의 시작을 기억하고 원하는 목표를 달성 할 수 있는지 여부를, 우리는 분업해야한다 방법을 모르겠어요. 우리는이 프로젝트의 개발을 더 잘 인식하게하지만, 우리는 점점 더 확신, 우리는이 프로젝트가 더 잘 할 우리에게 도움이 될 것입니다 확신 느낌
3, 우리는 통일 된 관리 작업이 없을 때 더 이상 알파 단계로 프로젝트 작업을 지원하기 위해 GitHub의 문제에 게시 된 할당 할 수 배웠습니다. 문제의 사용의 도입 후, 우리는보다 효율적으로 개발했습니다.
(주 11)
어려움 발생 문제 :
1, 지난 주에 우리는 새로운 기능을 많이 준비하는 회원을 개발하지만, 때문에 비동기 프로그래밍 및 버그 많은 결과, 혼돈의 논리를 이해하지 못하는
2, 우리는 점차적으로 일부 페이지가 너무 복잡한 논리입니다 이제 더 좋을 수 있다는 것을 발견했다 "컴포넌트 기반"프로그램이 문제를 해결할 수 있지만, 프로젝트의 전체 디렉토리 구조를 다시 이동하는 문제에 가고 싶습니다 우리가 따라하기로 결정, 그래서 매우 어렵다 원래의 계획은 준비하기 위해 계속
우리는 기쁘게 장소 :
소프트웨어 버그를 많이 생산하지만, 기능의 점진적 개선과 함께, 우리의 소프트웨어는 또한 더 만드는 완벽한 제품의 경향이 있지만 1, 우리는 매우 기쁘게 느낌
2, 우리는 문제에 적용 힘내 배쉬 더욱 편리하게는, 우리는 크게 개발 효율성을 향상시킬 수 있습니다
넷째, 작동 원리 소프트 \ 방법을 배웠습니다
1, 설계 과정에서 고려하지 쉽게 통계의 타겟 고객의 많은 수를 고려, 팀은 사용자의 범위, 교과 과정 설계 및 홍보, 전체 기능의 첫 번째 작은 규모의 평가를 축소하고 그 범위를 확대하기로 결정했다.
2, 고려 우리가 약화의 기능 지점으로 기능 점수 프로그램 구현 작업을 적절하게 변경 한 후에 발생할 수있는 실제적인 문제를 복용.
3 원래의 인터페이스 디자인 개선 및 확장의 일정 금액을 기준으로 소프트웨어 블레이드를 사용하는 학습.