Konserwacja wiki dla programisty

Question

Niedawno byłem odpowiedzialny za wiki dla zespołu programistycznego. Wiki jest wciąż w powijakach, więc mam dużo miejsca do pracy. Celem jest udostępnienie wewnętrznego zespołowi programistów. Obecnie główną informacją, którą posiada wiki, są standardy kodowania.

• Jakie są najlepsze praktyki, które zespół programistów wykorzystuje w swojej wewnętrznej wiki?
• Jakie informacje są ważne na stronie dev?
• Gdybyś miał wejść na stronę wiki dla swojego zespołu programistów, jakich informacji spodziewałbyś się zobaczyć?
• Czy są jakieś informacje, które nie powinny wejść na wiki, mimo że wydaje się to dobrym pomysłem?

- edycja -

• Ponadto, jest to dobry sposób, aby organizować informacje? (Takie jak po warstwie (dane UI), przez Porject lub inne)

Answer 1

• Wprowadzenie do bazy źródłowej dla nowych programistów
• Dokumentacja ogólna (nie dokumentacji API per se, ale bardziej samouczka jak rzeczy)
• wykaz personelu/kto robi co i jak do nich dotrzeć
• Uwagi/resources/artykułów, które wyjaśniają pojęcia stosowane w oprogramowaniu
• Dokumentacja procesu budowania i układ plików w kodzie

Inne rzeczy ja zazwyczaj pakowane są

• Planowanie/todo list
• informacje, które są interesujące dla innych, aby przeczytać
• Wszystko inne, co czuję powinny być dzielone

Answer 2

• Burndown charts
• com mon informacji konfiguracyjnych dla środowisk programistycznych (miłe, gdy nowi ludzie zaczynają)
• Specyfikacja
• Znane problemy i ich rozwiązania z narzędzi programistycznych

Answer 3

Jedno, co podkreślamy na naszej dev wiki jest to, że jest aktualizowany, gdy sprawy zmiana. Nie chcemy naszej wiki, która ma dostarczać informacji i być głównym źródłem zebranej wiedzy, aby stała się tak nieaktualna, że ​​jest bezużyteczna. Wraz z aktualizacją kodu programiści proszeni są o aktualizację wszelkich powiązanych informacji na wiki.

Poza standardami kodowania przechowujemy porady i wskazówki dotyczące pracy z bazą kodu, informacjami o konfiguracji dla nowych pracowników i ogólnymi informacjami o środowisku.

Answer 4

Wymyśl coś w rodzaju przewodnika po stylach i naucz innych, jak stylizować rzeczy.Kiedy zajmowałem się korporacyjną wiki, wszyscy inni twórcy napisali tylko marną prozę, która była ledwo sformatowana i wyglądała okropnie.

Trzymaj z dala od rzeczy wymagających dyskusji. Próbowałem buthorn w sekcji przeglądu książek, ale było to zbyt trudne, aby inni komentowali rzeczy.

Przykłady bibliotek domowych są dobre. I/lub "storyboardy" prowadzące użytkownika przez proces, gdy wywoływany jest MethodX.

Answer 5

Jakie są najlepsze praktyki, które zespół programistów wykorzystuje w swojej wewnętrznej wiki?

Spraw, żeby ładnie wyglądała. Wiem, że to nie brzmi ważnie, ale jeśli poświęcasz trochę czasu na brandowanie, to opłaca się w kategoriach ludzi, którzy go używają. A pobór jest kluczowy, albo po prostu uschnie i umrze.

Jakie informacje są ważne na stronie dev?

• Ogólne informacje na temat projektu, etapy, termin dostawy itp
• Streszczenia projektu decyzji/spotkań. Ważne, aby ponownie nie odwiedzać tych samych obszarów.
• prowadnice HowTo dla ogólnego rozwoju obecnych projektów (na przykład, jak rozwijać nowe wtyczki)

Jeśli było przejść do wiki dla swojego zespołu dev jakie informacje można oczekiwać, aby zobaczyć?

Informacje o projekcie, kto pracuje nad tym itp. Decyzje projektowe. Także najlepsze praktyki i linki do przydatnych stron.

Czy są jakieś informacje, które nie powinny wejść na wiki, mimo że wydaje się to dobrym pomysłem?

Niskopoziomowe listy zadań mają tendencję do fluktuacji, nie są uaktualniane i mogą wprowadzać w błąd. Ponadto, komunikacja krytyczna między działami jest lepiej dostosowana do poczty e-mail, THEN konwersację można skopiować na wiki. Zbyt łatwo można to zignorować w inny sposób!

Answer 6

Mieliśmy wiki programistyczne i było to wspaniałe narzędzie. Użyliśmy go dla wszystkiego!

• Gdy burzymy mózgi nad nowymi pomysłami, przechwycimy je na wiki. Niski współczynnik tarcia wiki ułatwiał każdemu w organizacji (byliśmy małym startupem) dodawanie pomysłów, kiedy o nich myśleli. Mieliśmy stronę "burzy mózgów" wysokiego poziomu, która zawierała szczegółowe strony zawierające dokładny opis każdego pomysłu.
• Dla każdej iteracji "przenieśliśmy" elementy pomysłu na funkcje z listy "burzy mózgów" na listę funkcji dla tej iteracji. Szczegóły tej funkcji zostały przepłukane w celu uwzględnienia szczegółów dotyczących projektu i implementacji.
• Po zakończeniu operacji strona z iteracją stała się naszą stroną uwag do wydania, która zawierała również znacznik wydania z naszego systemu kontroli wersji.
• Mieliśmy stronę błędu, która działała bardzo podobnie do stron funkcji. Poprawki zostały dodane do stron iteracji/wydania w trakcie ich pracy/ukończenia.
• Stworzyliśmy również naszą dokumentację użytkownika na wiki i wyeksportowaliśmy te strony wraz z wydaniem.

Z biegiem czasu. To narzędzie było coraz bardziej cenne. Zlikwidowaliśmy tworzenie nowych wiki dla różnych produktów, nad którymi pracowała firma.

Mam nadzieję, że Twoja wiki programistyczna będzie równie przydatna jak my!

Answer 7

Pamiętaj, że wiki jest interaktywne. Jeśli myślisz o publikowaniu, tak jak przy publikowaniu wykresów z burndown, to nie myślisz wystarczająco daleko. Dystrybucja tych informacji jest tylko częścią tego.

Na przykład, zamiast mieć stronę "Bieżący rozkład emisji", utwórz stronę dla "Wykresu Burndown dla Tygodnia 10-27-2008", a następnie zachęć ludzi do komentowania wykresu i jego znaczenia, a także dlaczego zrobiłeś tak źle w tym tygodniu.

Answer 8

Najtrudniej jest zachęcić programistów do korzystania z wiki. Mam kilka długich sugestii tu stoją: http://possibility.com/wiki/index.php?title=GettingYourWikiAdopted

Pierwsze Wiki Przyjęte jest trudne

Have a Champion

Usuń Sprzeciw

tworzyć treści

wzajemnego zazębiania wiki w firmie Procesy

Evangelize

not Give Up

Rozważmy Nie Korzystanie z Wiki do rozmów

po prostu zrób to! Nie czekaj na budżet

mieć plan przejściowy

promowanie swojej Wiki

Jedną dobrą praktyką jest, aby cała dokumentacja i kod źródłowy dla każdego budować dostępne za pośrednictwem swojej wiki. Następnie programiści przejdą do wiki, aby uzyskać dostęp do informacji o kompilacji, co czyni ją nieocenioną.

Answer 9

Wikis mogą być cennym źródłem informacji dla zespołów programistycznych, ale nie są srebrną kulą. Łatwo jest stworzyć Wiki, która szybko przestałaby być używana lub stała się nieaktualna.

Moim zdaniem kluczem do sukcesu Wiki jest uzyskanie całego zespołu na pokładzie. Oznacza to odciąganie ludzi od innych zasobów (w szczególności archiwów wiadomości e-mail) jako repozytoriów wiedzy i zachęcanie ludzi do wnoszenia swoich wkładów.

Jednak ważne jest również, aby nie być formatem samochodowym: Jeśli masz dużo dokumentów, które generujesz w, powiedzmy, MS WORD, może to być idealne, aby zrobić je wszystkie w formacie Wiki, ale to wymaga czasu i może być denerwującym, jeśli masz diagramy, dokumenty itp. W takich przypadkach lepiej jest pójść na kompromis i pozwolić ludziom trzymać go w formie słownej, o ile jedynym sposobem uzyskania dostępu do najnowszej wersji jest Wiki.

Jeśli nie jesteś menedżerem, musisz zatrudnić menedżera na pokładzie, ponieważ wymagałoby to "egzekwowania".

Odnotowano gromadzenie badań i doświadczeń na temat Wiki i ich wykorzystania w inżynierii oprogramowania. Możesz na przykład przeszukać bibliotekę cyfrową ACM. Jestem współorganizatorem corocznych warsztatów na temat wiki dla SE i mieliśmy kilka interesujących raportów z doświadczeń oraz dodatkowe materiały na międzynarodowym sympozjum na temat Wiki.

Answer 10

Mamy dom wiki zespołu. I tam umieścić wszystkie niezbędne informacje dla każdego projektu jesteśmy rozwijającym:

• repozytoriów
• adresy dla maszyn wirtualnych
• haseł
• dokumentacje projektowe
• projekt przegląd
• Status projektu

i wszystko inne, co wypełnimy n zapisy do napisania na projekcie. Jest to najbardziej przydatna aplikacja internetowa, którą używamy (poza Mantis). Na bardziej ogólnych stronach umieściliśmy definicję każdej używanej taksonomii, ogólne wytyczne projektowe, zasady, kodowanie i opracowywanie praktyk, z których korzystamy. To tam jest proste i skuteczne. Myślę, że każdy zespół powinien mieć jedno z nich.

Answer 11

Wikipatterns to witryna poświęcona dokumentowaniu najlepszych praktyk wiki. Opisują również wzorce antypirackie i mówią o sposobach radzenia sobie z nimi. Czytałem ich książkę i to było dla mnie wielkim atutem, że mogłem stworzyć wiki z ziemi w ponad 150-osobowej organizacji.