애자일 개발
지금 애자일 개발, 대부분의 애자일 개발 모델에서 팀 존경
이해하기 시작뿐만 아니라 결국 궁금하면 혜택이 무엇인지 애자일 개발, 그리고?
또한 단지 초보자의 진입은 오래 걸리지 않았지만, 애자일 개발의 일부 이해 저자 자신은, 포괄적이지, 서로 다른 이해 / 또는 깊은 이해는 서로 배울 응답 할 수 있습니다. 아직 시간이 오래 걸리는 연습의 깊은 이해를 침전
1. 애자일 개발은 무엇입니까?
애자일 개발은 인간 중심, 반복, 증분 개발 방법론이다.
2. 어떻게 이해 하는가?
첫째, 우리는이 기술 아니라는 것을 이해해야합니다, 그것은 소프트웨어 개발 과정 개발 방법론, 그것은 한 단계 프로젝트의 단계 개발에 의해 부분의 조항을 사용하는 우리를 안내 할 것, 그리고 그러한 발전의 주요 방법 코어는 사람 구동 그것은 반복적 인 개발을 사용;
3. 애자와 스크럼 대표 개발 운영팀
사실, 존경 스크럼과 애자일 개발을 중심으로 기반 개발 운영 팀에 많은 수의
스크럼 문맹 퇴치 기사 https://www.cnblogs.com/taven/archive/2010/10/17/1853386.html (공유 블로거 주셔서 감사합니다)
문맹 퇴치 기사를 개발 운영 https://www.cnblogs.com/jetzhang/p/6068773.html (공유 블로거에 대한 감사)
모두 애자일 개발에서의 역할은 무엇인가 3.1인가?
개인의 이해는 다음과 같습니다
스크럼은 생산에서 수요하는 개발 프로세스이다 - 검토 - - R & D - 테스트 - 온라인 - 새로운 요구 사항의 형태로 폐쇄 루프 폐쇄 상호 작용의 숫자로 나누어 제품을 생산하고 피드백 반복 버전입니다.
개발 운영 팀에 전달 각 링크의 반복적 인 버전에 대한 개념, 옹호 / CD 도구 체인이 자동으로 온라인 사용자의 전달 될 때까지 작업의 전달의 모든 측면을 완료하기 위해 도구를 통해 CI의 사용을 통해 연결되어있다.
두 보색 관계에 있으며, 스크럼 개발 프로세스가 개발 운영 CI / CD 툴 체인을 제공을 제공한다
스크럼의 이해 3.2
(네트워크에서 사진)
개인 이해 스크럼입니다 : 수요가 빠르게 / 더 / 더 정확한 구현을 얻을 수 있도록하는 방법 제품 / 프로젝트의 관점에 서.
들어 제품 직원 , 빠른 실현 될 수있는 제품 기능을 설계하려면, 온라인, 업데이트를 확인합니다. 전통적인 폭포 개발이 종종 온라인 시장이 다시 불가능 이미 육개월 후 다시 줄 수 있으며, 새로운 조정을 충족하기 위해가 발견되면, 모든 요구 사항을 완료 할 때입니다, 인터넷에 대한 제품은 단순히 치명적인 부상입니다. 제품의 분해 특성의 분석을 기획를 들어, 추출 특성에 시장 온라인 사용자 인증에 의해 달성 신속한 개발을 중점을하고 기능이 풍부한 인터넷 제품 시장을 점유 의심 할 여지없이 가장 좋은 방법을 계속합니다.
스크럼에서 제품 요구 사항이 엄격한 직원이 될 수 있도록, 제품 요구 사항은 시장의 반응에 제품 특성, 풍부하고 정확한 비행기 분해 분석 (제품 포지셔닝, 분해 사용자의 세로, 데이터, 특성 분석, 응답 할 수 있습니다 수요 관리)은 큰 도전이다
를 들어 개발자 , 편차의 요구를 이해 / 수요 / 버그 수정 문제의 변화는 항상 두통되어 있어야합니다. 연구자가 요구를 이해하기위한 편차가있을 경우, 테스트 단계 전체 제품 라인 확장을 재 작업하는이 시간은 다시 이어질 것 편차를 찾기 위해 달성해야 할 때까지만이었다 (이 폭포 모델, 항목이 더 비용이 더 긴 지연 시간 인 경우) . 수요 변화는 (제품 / 시장 / 정책 요인 등 때문에), 연구자들은 요구 사항이 더 큰 재 작성 전체 제품 라인에 대한 것입니다 코딩하기 전에 변경하면 요구 사항을 이해해야합니다 또한 인 개발 과정에서 발생하는 경우 확장 (폭포 모드에서 주요 사업 스트림으로 수요의 변화를 일으킬 수있는 경우 전체 프로젝트가 재 설계 중지). 테스터가 신속하고 정확하게 편차 / 검색 시스템 버그의 요구 사항을 식별 할 수없는 경우, 심지어 숨겨진 위험을 가져올 지연 배달의 제공으로 이어질 것입니다, 결과는 언제라도 예상 할 수 없습니다.
스크럼 빠른 반복 버전이 아닌 폭포수 모델을 촉진 그래서, 목적은 프로젝트 비용의 손실을 최소화하는 것입니다;
스크럼은 또한 요구 사항을 이해하기 위해 R & D 인력에 초점을 맞추면서, 목적은 연구자들이 요구, 그 사람들이 평가는 편차가 누락 여부를 확인하기 위해 이해 있도록 수행 분해 제품의 필요에 따라 자세한 이해를 수행 할 수 있도록하는 것입니다;
그리고 논리적 빠른 분석 / 위치를 달성하기 위해 시험 제품 / R & D 분야에 걸쳐 참여 인력, 제품 개발의 상세한 지식의 필요성이 요구 사항 / 버그의 존재를 충족뿐만 아니라, 작업의 감소의 테스트 부분의 효율성까지 속도를 기존의 수동 테스트 자동화를 촉진하기 위해 비용.
스크럼 팀 퓨전 3.3
각 팀의 제품 방향 / 인력 / 팀 분위기가 다르다으로 스크럼를 들어, 자신의 R & D 프로세스는 반드시 모든 팀에 적용되지 않습니다.
스크럼은 개인적으로하지 스크럼 프로세스를 복사, 학습 그렇게 생각하지만, 빠른 반복 배달을 이해하고 다음에 대한 여러 가지 다른 요인의 자신의 팀에 따라 결합 된 연구 개발 프로세스의 자신의 팀에 대한 출력 .
물론, 스크럼의 여러 측면이 있습니다 / 학습 모드 직접적 작업 칸반 / 매일 스테이션 것이다 / 워크로드 평가 / 수요 분해 세션으로, 올 할 수 있습니다. 작업 칸반 준비하기 위해 다음 단계를 용이하게 당신에게 신속하게 동기화 작업 진행률을 도울 수 있으며, 매일 스테이션이 될 것입니다, 그래서 우리는 진행과 위험의 질문을 물어 동기화 할 수 있음을 우리는 전투의 성능을 정량화하기 위해 자신의 작업을 계속 할 수 있도록, 작업 부하 평가, 검토 음성 개선과 일반적인 진행에 대한 회의.
필자는 개인적으로의 통합을위한 스크럼 팀을 생각한다 (1) 시험 전체 버전의 반복이 소집 후 상태 및 기타 요인 팀에 따르면, (2) 역할의 세부 다양한 측면에서 과정을 설명 민첩 (3)의 전체 보편적 인 개념을 수행하는 R & D 프로세스의 집합을 개발 리뷰 (4) 적절한 R & D 프로세스가 문제가 처리되면 월별 또는 분기 별 또는 각 버전에 대한 기록 (5), 검토 토론의 각 버전의 중간에 발생하는 이행을 촉진하기 위해 강제로 결정하는 최적화 프로세스 단계를 앞으로 복용의 집단적 지혜를 논의 할 예정 최적화 및 구현하기 위해 계속
사고 후 모니터링 프로세스의 필요성의 구현에 어려움 거짓말 때문에 주로 애자일 개발의 시간 / 에너지의 일정 금액을 소비하는 적절한 애자일 개발 프로세스를 개발하기 위해 배울 수있는 매우 어려운 일이 어려운 일이 아니다입니다 팀은 새로운 개발 프로세스에 적응하자 핵심은 사람을 구동된다. 스크럼 팀의 통합은 우리가 새로운 R & D 과정에 실제 통합의 습관을 개발하는 것을, 우리는 집행 감독을 강화해야한다 진정한 통합을 달성하고 싶다 등의 링크 / 회의의 일부를 증가시킬 수있다
이해 개발 운영 3.4
(네트워크에서 사진)
(네트워크에서 사진)
个人对于DevOps的理解是：站在集成/交付的角度，怎么让研发流程各个环节无缝连接，同时推动工具链减少人员操作（当然DevOps是一种理念，理解起来肯定不仅如此，只是在落实方面CI/CD思想比较着重）
对于研发流程而言，一个好的研发流程就是一个完整的闭环，每个环节都有其存在的意义并且每个环节的完成都意味着工作交付（产品人员将需求交付给开发人员编码，开发人员将系统交付给测试人员测试，测试人员将系统交付给运维人员上线，运营人员将系统交付给客户使用，客户将使用意见交付产品人员分析）。完整闭环就需要产品／开发／测试／运维／客户等角色共同参与，闭环的形成、多种角色的参与都意味着每个环节、角色的交付都是一个重点。更好的交付将减少下游环节、角色的工作成本；更好的交付将提高研发流程的流畅度（对于研发流程的推进也有帮助）；更好的交付将提高产品的市场、乃至提高产品的收益。
笔者接触到的大多数DevOps的讲解，DevOps是将开发、测试、运维融合起来，但是笔者认为DevOps并不仅仅是这３者的融合，而是整个产品至上线所有环节／角色的融合
DevOps提倡使用工具链，将所有的交付／监控等等环节操作工具化，并通过工具之间的API互相关联形成一套完整的工具链体系。通过工具减少人员的操作，即减少了人员成本又极大的避免了人为操作失误带来的损失。
笔者之前看到过一个比较完整的DevOps工具链概览，分享给大家（同时也感谢作者的分享）https://blog.csdn.net/qq_31977125/article/details/82796739
顺便再分享一个 DevOps BookMarks ，涉及了DevOps方方面面的工具和内容，有兴趣的同学可以去学习下。http://www.devopsbookmarks.com/
（笔者也有简单分享过一些工具相应的介绍／安装／配置文章，后面笔者也会继续学习继续补充）
3.5 团队融合DevOps
对于DevOps，它是一个理念。个人认为对于DevOps的学习，首先是真正的理解集成／交付的思想，然后就是工具链的学习使用（硬核技术）。
团队对于Devops的融合是需要全员参与的，也是对团队整个技术栈的全面提升。首先是组织推广CI/CD的思想，让大家理解交付的意义；然后团队整体寻找适合团队的工具链，进行技术栈的全面提升。
4. 团队走向敏捷开发
个人认为团队想要真正的走向敏捷开发，需要对于Scrum和DevOps进行一个完整的融合。
通过DevOps闭环的思想、Scrum迭代的思想，结合Scrum可以借鉴的环节／方式，制定一套闭环、适合团队的研发流程。
通过JIRA等项目管理工具将研发流程工具化管理，再将研发环节交付工具化执行，然后打通项目管理工具、研发各环节交付工具形成一个完整的工具链。
最最重要的一点还是人，一个团队想要真正的走向敏捷开发，首先也是必须要让团队人员都认同迭代、闭环、集成、交付思想。只有思想上的认同，才会让整个团队共同努力向着敏捷开发的方向不断前进
