프로그래머 위키 유지 [폐쇄

https://stackoverflow.com/questions/247967

wiki

05-07-2019
|

문제

나는 최근에 개발 팀을 위해 위키를 담당했다. 위키는 아직 초기 단계에 있으므로 함께 일할 여지가 많습니다. 목표는 개발 팀 내부를 수용하는 것입니다. 현재 Wiki가 보유한 주요 정보는 코딩 표준입니다.

Dev 팀이 내부 위키에 사용하는 모범 사례는 무엇입니까?
Dev Wiki에 중요한 정보는 무엇입니까?
Dev 팀을 위해 위키에 가려면 어떤 정보를 볼 수 있습니까?
좋은 생각처럼 보이지만 위키에 가지 말아야 할 정보가 있습니까?

-- 편집하다 --

또한 정보를 구성하는 좋은 방법이 있습니까? (예 : 레이어 (데이터, UI), porject 또는 기타)

해결책

새로운 프로그래머를위한 소스 기반 소개
일반 문서 (API 문서가 아니라 더 많은 튜토리얼과 같은 튜토리얼)
직원 목록 / 누가 그들에게 도달하는 방법과 방법을하고있는 사람
소프트웨어에 사용 된 개념을 설명하는 메모 / 리소스 / 기사
빌드 프로세스 문서 및 코드베이스의 파일 시스템 레이아웃

내가 보통 거기에 두는 다른 것들이 있습니다

계획 / TODO 목록
다른 사람들이 읽을 수있는 흥미로운 정보
내가 느끼는 다른 모든 것은 공유해야합니다

다른 팁

우리는 개발 위키를 가지고 있었고 훌륭한 도구였습니다. 우리는 그것을 사용했습니다 모든 것!

새로운 아이디어를 브레인 스토밍 할 때 Wiki에서 아이디어를 포착 할 것입니다. Wiki의 마찰 특성이 낮기 때문에 조직의 모든 사람이 생각했던대로 아이디어를 추가 할 수있었습니다. 우리는 각 아이디어에 대한 철저한 설명이 포함 된 자세한 페이지에 연결된 높은 수준의 "브레인 스토밍"페이지를 가지고있었습니다.
각 반복마다 "브레인 스토밍"목록에서 해당 반복의 기능 목록으로 아이디어 항목을 "이동"합니다. 이 기능의 세부 사항은 설계 및 구현 세부 사항을 포함하도록 플러시되었습니다.
기능이 완료되면 반복 페이지는 릴리스 노트 페이지가되었습니다. 여기에는 버전 제어 시스템의 릴리스 태그도 포함되었습니다.
기능 페이지와 매우 유사한 버그 페이지가있었습니다. 버그 수정은 반복/릴리스 페이지가 작업/완료 될 때 추가되었습니다.
또한 Wiki에 대한 사용자 문서를 작성하고 해당 페이지를 릴리스로 내보냈습니다.

시간이 지남에 따라. 이 도구는 점점 더 가치있는 것으로 간주되었습니다. 우리는 회사가 작업하고있는 제품에 대한 새로운 위키를 만들었습니다.

개발 위키가 우리처럼 유용하다는 것을 알게되기를 바랍니다!

Wikipatterns 최고의 Wiki 관행을 문서화하기위한 웹 사이트입니다. 그들은 또한 반란을 묘사하고 그들을 다루는 방법에 대해 이야기합니다. 나는 그들의 책을 읽었고 150 명 이상의 사람 조직에서 위키를 시작하는 것은 큰 자산이었습니다.

우리가 Dev Wiki에 강조하는 한 가지는 상황이 바뀔 때 업데이트된다는 것입니다. 우리는 정보를 제공하고 수집 된 지식의 중심적인 원천이되는 위키를 원하지 않습니다. 코드가 업데이트되면 개발자는 위키에 대한 관련 정보를 업데이트하도록 요청받습니다.

코딩 표준을 제외하고는 코드 기반으로 작업하기위한 팁과 요령, 신규 고용에 대한 정보 설정 및 일반 환경 정보를 유지합니다.

번 다운 차트
개발 환경을위한 일반적인 설정 정보 (신입 사원이 시작될 때 좋습니다)
명세서
개발 도구를 사용한 알려진 문제 및 해결 방법

어떤 종류의 스타일 가이드를 생각해 내고 다른 사람들에게 스타일을 스타일링하는 방법을 가르쳐주십시오. 내가 회사 위키를 담당했을 때, 다른 모든 개발자들은 거의 형식이 아니고 끔찍한 끔찍한 산문을 쓸 것입니다.

토론이 필요한 것들로부터 멀리하십시오. 서평 검토 섹션에서 Shoehorn을 시도했지만 다른 사람들이 사물에 대해 언급하기가 너무 어려웠습니다.

집 도서관의 예는 양호합니다. 및/또는 "스토리 보드"는 메소드 X가 호출 될 때 프로세스를 통해 사용자를 걷는다.

Dev 팀이 내부 위키에 사용하는 모범 사례는 무엇입니까?

멋지게 보이십시오. 나는 그것이 중요하지 않다는 것을 알고 있지만, 당신이 약간의 시간을 브랜딩하면 실제로 그것을 사용하는 사람들의 관점에서 돈을 지불합니다. 그리고 흡수가 핵심이거나, 그냥 시들고 죽을 것입니다.

Dev Wiki에 중요한 정보는 무엇입니까?

프로젝트, 이정표, 배달 날짜 등에 대한 일반적인 정보
디자인 결정/회의 요약. 같은 영역을 다시 방문하지 않도록 중요합니다.
현재 프로젝트의 일반적인 개발을위한 방법 (예 : 새 플러그인 개발 방법)

Dev 팀을 위해 위키에 가려면 어떤 정보를 볼 수 있습니까?

프로젝트 정보, 누가 무엇을 연구하고 있는지. 디자인 결정. 또한 유용한 사이트에 대한 모범 사례 및 링크.

좋은 생각처럼 보이지만 위키에 가지 말아야 할 정보가 있습니까?

저수준 작업 목록은 변동하는 경향이 있으며 최신 상태로 유지되지 않으며 오해의 소지가있을 수 있습니다. 또한 부서 간의 비판적 커뮤니케이션은 이메일에 더 적합한 다음 대화를 위키에 복사 할 수 있습니다. 그렇지 않으면 무시하기가 너무 쉽습니다!

위키는 대화식이라는 것을 기억하십시오. 게시에 대해 생각하고 있다면 번 다운 차트를 게시 할 때와 같이 충분히 생각하지 않습니다. 해당 정보를 배포하는 것은 그 일부일뿐입니다.

예를 들어, "현재 번 다운 차트"페이지가없는 대신 "10-27-27-2008 주에 대한 번 다운 차트에 대한 페이지를 작성한 다음 사람들이 차트에 댓글을달라고 권장합니다. 그 주가 잘되지 않습니다.

가장 어려운 부분은 개발자가 위키를 사용하도록하는 것입니다. 여기에는 몇 가지 오랜 제안이 있습니다. http://possibility.com/wiki/index.php?title=gettingyourwikiadopted

위키를 입양하는 것은 어렵습니다

챔피언이 있습니다

반대 의견을 제거하십시오

콘텐츠를 만듭니다

회사 프로세스에서 Wiki를 enmesh습니다

전도

포기하지 마십시오

대화를 위해 Wiki를 사용하지 않는 것을 고려하십시오

그냥 해! 예산을 기다리지 마십시오

전환 계획이 있습니다

위키 홍보

좋은 관행 중 하나는 Wiki를 통해 각 빌드에 대한 전체 문서 및 소스 코드를 제공하는 것입니다. 그런 다음 개발자는 Wiki로 가서 빌드 정보에 액세스하여 매우 귀중합니다.

Wikis는 소프트웨어 개발 팀에게는 귀중한 리소스가 될 수 있지만은 총알은 아닙니다. 빨리 무시하거나 심하게 구식이되는 위키를 만드는 것은 너무 쉽습니다.

제 생각에는 성공적인 위키의 열쇠는 전체 팀을 탑승시키는 것입니다. 즉, 사람들이 다른 리소스 (및 특히 이메일 아카이브)에서 지식 저장소로 멀어지게하고 사람들이 기여할 수있는 인센티브를 제공하는 것을 의미합니다.

그러나 형식 Czar가 아닌 것도 중요합니다. MS Word에서 생성하는 문서가 많이 있다면 Wiki 형식으로 모든 것을 수행하는 것이 이상적이지만 시간이 걸리고 성가신 일 수 있습니다. 다이어그램, 문서 등이 있습니다.이 경우 최신 버전에 액세스하는 유일한 방법이 위키를 통해서는 한, 타협하고 사람들이 단어 형식으로 유지하는 것이 좋습니다.

관리자가 아닌 경우 "집행"이 필요하기 때문에 관리자를 탑승해야합니다.

Wikis에 대한 연구와 경험과 소프트웨어 엔지니어링에 대한 사용이 축적되었습니다. 예를 들어 ACM 디지털 라이브러리를 검색 할 수 있습니다. 저는 SE를위한 Wikis에서 연례 워크숍의 협력자이며 우리는 몇 가지 흥미로운 경험 보고서를 받았으며 Wikis 국제 심포지엄에는 추가 자료가 있습니다.

우리는 집과 사내 팀 Wiki를 수용합니다. 그리고 우리는 개발중인 각 프로젝트에 필요한 모든 정보를 넣었습니다.

저장소
가상 기계의 주소
비밀번호
프로젝트 문서
프로젝트 개요
프로젝트 상태

그리고 우리가 채우는 다른 것은 프로젝트에 작성해야합니다. 그리고 우리가 실행중인 가장 유용한 웹 애플리케이션입니다 (게다가 사마귀). 보다 일반적인 페이지에서 우리는 우리가 사용하는 모든 분류 체계, 일반 프로젝트 지침, 경찰, 코딩 및 개발 관행에 대한 정의를 제시합니다. 거기에 있습니다. 간단하고 효과적이며 모든 팀에는 그 중 하나가 있어야한다고 생각합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow