Pracuję dla małej firmy. Dział rozwoju oprogramowania firmy, zanim zostałem zatrudniony, składał się z jednego samouka, przepracowanego faceta. Teraz, gdy piszę oprogramowanie dla firmy od kilku lat, mam za zadanie ustanowienie formalnych praktyk rozwoju oprogramowania w całej firmie. Obecnie nie mamy żadnych innych wytycznych niż
Napisz kod, przetestuj go, umieść w pliku .zip i wyślij do klienta. Punkty bonusowe za TDD i kontrolę wersji.
Mój szef chce, żebym napisał podręcznik dla programistów, który określa ogólne procesy, protokoły, narzędzia i wytyczne, których używamy do wykonywania zadań. Innymi słowy, chce książki „Oto, co tu robimy”, aby ułatwić nowemu pracownikowi zapoznanie się ze sposobem, w jaki robimy rzeczy, a także by pomóc mojemu szefowi zrozumieć, co robią jego podwładni i jak się zachowują to.
Z mojego punktu widzenia kładę podwaliny i trzeba to zrobić dobrze. Jak zabrałbyś się do wybierania tematów do takiego podręcznika? Czy możesz podać jakieś przykładowe tematy?
Uwaga boczna: jeśli to ważne, jesteśmy przede wszystkim sklepem Microsoft .NET. Patrzymy na zwinne praktyki, takie jak XP i Scrum, ale być może będziemy musieli je poważnie zmodyfikować, aby działały w naszej firmie.
Odpowiedzi:
Podzielę to na części takie jak
Dzięki modułowej konfiguracji Ty i inni możecie osobno aktualizować elementy osobno, na przykład nazwiska i stanowiska pracowników będą się często zmieniać, gdy ludzie przychodzą i odchodzą.
Dla każdej sekcji postaram się napisać ją z punktu widzenia „początkującego”. Najważniejsze będzie upewnienie się, że to naprawdę ma sens dla początkującego. Twój szef oczywiście nie jest właściwą osobą do przeglądu tego, ponieważ nie jest on zamierzoną publicznością. Ma prawo tego chcieć, po prostu upewnij się, że treść nie zostanie przez niego przetestowana . Także „nowicjusz” oboje mają „1 tydzień” jako nowicjusz… i ma tylko jeden punkt widzenia. Jest więc prawdopodobne (i zalecane), że dokument zostanie dopracowany przy każdym nowym pracowniku. W rzeczywistości całkiem dobrym zadaniem jest przypisanie ich również na pierwszy tydzień, tj. „Zaktualizuj podręcznik dla początkujących”.
Dla Agile / SCRUM:
Najtrudniejszą częścią robienia Agile i SCRUM jest „naprawdę” robienie tego.
Do czytania zacznę od http://agilemanifesto.org/ i zacznę od tego miejsca.
Przeczytałbym również dobrze znany http://www.halfarsedagilemanifesto.org/, który dodaje wagi temu, że naprawdę musisz uwzględnić wszystkie aspekty, aby to zadziałało. Jeśli musisz mocno zmodyfikować Agile w swoich organizacjach, prawdopodobnie ludzie będą chcieli uzyskać korzyści - bez korzystania z odpowiednich procesów. Sam fakt ten powinien zostać przedstawiony, aby odeprzeć jakąkolwiek półpoważność.
źródło
Wygląda na to, że będziesz musiał wprowadzić pewne praktyki, zanim je udokumentujesz!
a) Kontrola źródła - w jaki sposób przechowujesz źródła i kontrolujesz zmiany
b) Zarządzanie wersjami i ich monitorowanie - w jaki sposób wykonujesz kompilację, numerujesz wersję, porównujesz aktualnego kandydata do poprzedniej wersji
c) Zarządzanie problemami - jak śledzić błędy w swoich wydaniach.
Są to dość podstawowe rzeczy, ale ich wdrożenie może zająć dużo czasu (i być może kosztować).
źródło
Tematy, które chciałbym zawrzeć w podręczniku programisty:
Należy pamiętać, że ten podręcznik powinien zawierać wyłącznie elementy specyficzne dla rozwoju, a nie informacje dotyczące całej firmy (które powinny znajdować się w podręczniku dla pracowników).
źródło
Korzystanie z kontroli źródła
źródło