Przygotuj plan przekazania kodu źródłowego [zamknięty]

12

Nasza firma ma zamiar zdobyć kod źródłowy ogromnego produktu.

Co należy wziąć pod uwagę przy rozpoczęciu przekazania, aby upewnić się, że mamy wszystko i jesteśmy w stanie utrzymać ten produkt w przyszłości?

documentation maintenance knowledge-transfer Ahmed Aswani
źródło
1
Jeśli to możliwe, poproś o przejęcie dla niektórych inżynierów pracujących nad projektem. Pomoże to w problemie z ciągłością zasobów.
tehnyit
nie mamy szczęścia. nie możemy tego zrobić, możemy maksymalnie udostępnić inżyniera na 3-4 tygodnie.
Ahmed Aswani,
Znalazłem powiązaną odpowiedź Myślę, że uzupełnia to, co większość odpowiedzi tutaj.
Ahmed Aswani

Odpowiedzi:

8

Po pierwsze powodzenia.

Oto niektóre z rzeczy, o które prawdopodobnie powinieneś poprosić / otrzymać.

  • Lista znanych wad.
  • Lista zapisów incydentów i problemów.
  • Szczegóły dotyczące dwóch ostatnich wydań, takie jak; ile czasu zajęły wdrożenie, czy był okres zwiększonych incydentów po wydaniu itp.
  • Kim są kluczowi eksperci merytoryczni.
  • Jakie są godziny pracy i podstawowe wsparcie.
  • Jak długo istniał produkt i jak stabilna jest podstawa kodu.
  • Jaka jest mapa drogowa produktu.
  • Jaki jest stos technologii.
  • Jakie są punkty integracji i kto obsługuje zintegrowane systemy.
  • Czy są jakieś elementy DR
  • Kto jest odpowiedzialny za wywołanie DR
  • Jakie są umowy SLA aplikacji lub cele usługi.
  • Jaki jest oczekiwany wzrost systemu plików / bazy danych / kolejek komunikatów.
  • Kiedy wykonywane są kopie zapasowe systemu, kto jest odpowiedzialny i jaka jest strategia przywracania.
  • Kto jest odpowiedzialny za zarządzanie zaległościami produktu.
  • Jakie umowy SLA dostawcy i dane kontaktowe są dostępne.
  • Czy są jakieś harmonogramy wsadowe lub długotrwałe procesy.
  • Czy system jest całkowicie transakcyjny i jak zarządza współbieżnością.
  • Jaki jest główny proces zarządzania incydentami dla aplikacji.
  • Co, kiedy, kto i jak są powiadamiani interesariusze o zmianach i wyłączeniach.
  • Jakie są uzgodnione okresy / czasy przestoju.
  • Gdzie jest przechowywany kod źródłowy.
  • W jaki sposób tworzona jest kopia zapasowa kodu źródłowego, przywracany i zarządzany dziennik zmian.
  • Gdzie, co i kto jest właścicielem architektury rozwiązania.
  • Co to jest cel wdrożenia (DEV, ST, UAT, Pre PROD, PROD, DR).
  • Kiedy są przedłużane licencje innych firm?
  • Czy istnieje wykres RACI?
  • Ilu użytkowników tam jest i gdzie się znajdują.
  • Jakie są typowe problemy lub skargi związane z rozwiązywaniem problemów?
  • Kto jest odpowiedzialny za udzielenie dostępu do systemu.
  • Kiedy przeprowadzane są stenty testy / audyty bezpieczeństwa.
  • Gdzie jest CI i automatyczny proces kompilacji.
  • Kto jest odpowiedzialny za administrowanie kontrolą źródła i budowaniem serwera.
  • Gdzie są przewodniki instalacji.
  • Czy istnieje dokumentacja dla docelowej infrastruktury i sieci.
  • Jakie są rodzaje dotkliwości i wpływ ostatnich incydentów.
  • Czy są instrukcje konfiguracji stacji roboczej dla programistów.
    • Jakie pomoce rozwojowe i ramy są używane i czy są licencjonowane dla twojego zespołu.

To wszystko, o czym mogę teraz myśleć.

Kane
źródło
8
Proszę zdefiniować „DR”, „DEV, ST, UAT, Pre PROD, PROD, DR” i „RACI”. Zauważ, że niektóre z nich nie mają znaczenia dla kodu źródłowego (tj. Wykresy RACI są organizacyjne, w ogóle nie związane z kodem.)
S.Lott
Chciałbym mieć dostęp do repozytorium kodu źródłowego whoel, a nie tylko bieżących wersji kodu źródłowego. Komentarze w tym często mówią, dlaczego kod został zmieniony w określony sposób. Ważne jest, aby iknwo je utrzymywał.
HLGEM
@HLGEM przepraszam, że moje oświadczenie w sprawie bieżących wersji kodu źródłowego sugerowało (w każdym razie dobrze dla mnie) pełny kod źródłowy dla wszystkich składników.
Kane
@ S.Lott DR służy do opisania „odzyskiwania po awarii”. Dev jest powszechnym terminem określającym „środowisko programistyczne”, niezależnie od tego, co składa się na środowisko. ST to skrót od System Testing Environment. Nie zgadzam się, że RACI jest narzędziem organizacyjnym, ponieważ służy do opisania, kto jest odpowiedzialny, odpowiedzialny, poinformowany i konsultowany. Więc kiedy kod zostanie popełniony, kto jest za niego odpowiedzialny? Z kim konsultuje się w ramach recenzji? Kto jest informowany, że kompilacja zakończyła się powodzeniem / niepowodzeniem? I tak dalej
Kane
@kame: Zaktualizuj odpowiedź definicjami. Nie dodawaj więcej komentarzy do odpowiedzi. Proszę zaktualizować odpowiedź.
S.Lott,
6

Co należy wziąć pod uwagę przy rozpoczęciu przekazania, aby upewnić się, że mamy wszystko i jesteśmy w stanie utrzymać ten produkt w przyszłości?

Należy upewnić się, że:

  • widzisz, jak pomyślnie budują kod
  • widzisz, jak budują testy jednostkowe i zaliczają
  • widzisz, jak pomyślnie przeprowadzają inne testy, a wszystkie pomyślnie przechodzą (akceptacja, integracja itp.)
  • masz bazę danych otwartych problemów (łatwą do zdobycia, jeśli używają Bugzilli lub podobnej)
  • produkt działa (instrukcje instalacji).

Wszystko inne zależy od bieżącego opiekuna.

BЈовић
źródło
2
Proponuję zmodyfikować je tak, aby zawierały słowa „Musisz je zobaczyć ...”, np. „Musisz zobaczyć, jak budują kod” i „Musisz zobaczyć, jak przeprowadzają testy jednostkowe” itp. Dowody są tutaj ważne.
S.Lott,
@ S.Lott Niezależnie od tego, czy pokazują, czy piszą w dokumencie, nie powinno to mieć znaczenia. Ahmed Aswani i jego zespół zamierzają utrzymać aplikację i powinni być w stanie wykonać wszystkie powyższe kroki samodzielnie. Trochę zmodyfikowałem odpowiedź, ale nie jestem pewien, czy to właśnie zasugerowałeś.
BЈовић
1
Twierdzenie, że kod buduje, nie jest tym samym, co faktyczne widzenie kodu. Byłem tam Skończone. Dokumentacja może być niejasna, myląca lub niekompletna. Jest to stara zasada „Ufaj, ale weryfikuj”. Dopóki tego nie zobaczysz, nie wierz w to.
S.Lott,
1
@ S.Lott Ok ma sens. Teraz, gdy o tym myślę, byłem w podobnej sytuacji, kiedy zmusili nas do wdrożenia czegoś na zepsutych płytach sprzętowych. Spędziliśmy dobre 4 miesiące, zanim odkryliśmy, co jest naprawdę nie tak.
BЈовић
5

Musisz upewnić się, że zespół przekaże kod przez pewien czas. Zrób z tego podpisaną umowę!

Później będziesz mieć pytania, o których nie wiedziałeś, że musisz zadać z góry, więc muszą „trzymać się”, aby wyjaśnić ci różne rzeczy, a nie tylko podać kod, dokumenty i wszystko, co mają na temat projektu.

Po przekazaniu projektu tracisz jedną ważną rzecz: oryginalne doświadczenie zespołu.

Czasem dostajesz także coś, czego się nie spodziewałeś: wrogość.

Czy firma dokonująca przekazania ma dobrą umowę z przekazaniem? Jeśli stracą biznes, ponieważ zwrócą się z tobą o projekt, (dumni) programiści, którzy stworzyli kod, mogą oburzyć się faktem, że ich „dziecko” zostało rozdane. Możesz otrzymać odpowiedzi takie jak: „Jest w dokumentach, które masz” ... nawet jeśli nie jest.

Aspekty techniczne są dobre do omówienia, ale należy również wziąć pod uwagę ludzką stronę tego.

YMMV!

JohnDoDo
źródło
0

Czy kod zawiera pakiet testowy? Czy wszystkie testy w zestawie testów przeszły pomyślnie? Ile obejmuje pakiet?

Poleciłbym, aby pominięcie pakietu testowego uczyniło z niego budowanie pakietu testowego i powiązanej frameworka.

Blueberryfields
źródło