Co byś dodał w liście kontrolnej projektu rozwoju oprogramowania? [Zamknięte]

Jestem wielkim fanem list kontrolnych. Istnieje lista kontrolna podróży , ruchoma lista kontrolna, a nawet lista kontrolna Scrum .

Kontekst : zostałeś zatrudniony przez dużą korporację i powierzono ci misję skonfigurowania całego środowiska programistycznego, procesów, zespołu itp. Masz „carte blanche”. Będziesz odpowiedzialny za tworzenie przyrostów roboczych oprogramowania. Wielkość projektu: 2000 osób / dni.

Jakie elementy dodasz do poniższej (celowo małej i niekompletnej) listy kontrolnej:

• Zainstaluj serwer ciągłej integracji
• Napisz DoD
• Napisz jednostronicowe wytyczne kodowania
• Utwórz rejestr produktu
• Zainstaluj system śledzenia błędów
• Zaplanuj regularny czas na twarz

* 1.) Porozmawiaj z programistami, aby zobaczyć, czego naprawdę potrzebują! *

2.) Znajdź rozwiązanie do szybkiego uruchomienia wielu środowisk (pomyśl o wystąpieniach chmur publicznych lub prywatnych lub o starych maszynach wirtualnych, jeśli nie jesteś zgodny z modnym hasłem)

3.) Kontrola źródła / wersji

4.) System przeglądu kodu (Crucbile / Fisheye jako przykład)

5.) Ściana Kanban (lub coś podobnego)

6.) Protokoły komunikacyjne (czat w czasie rzeczywistym to duży plus), strony wiki również zachęcają do współpracy. Obejmuje to również public relations wewnętrznie - w jaki sposób zamierzasz współpracować z właścicielami firm, pracownikami pomocy technicznej i innymi grupami?

7.) Tablice elektroniczne

8.) Wygodne środowisko dla programistów (kanapy, stoły, miejsca do relaksu, dobre WiFi itp.)

9.) Świetna kawa !!!

• Konfiguracja Toolchain - IDE, serwer CI, serwer jakości kodu, kontrola źródła, serwer WWW, bazy danych, narzędzie do śledzenia problemów itp.
• Kopie zapasowe - jaką rolę ma każda osoba w zespole? Jakie procesy / moduły „posiada” i kto jest jego kopią zapasową?
• (Akceptacja użytkownika) Konfiguracja środowiska testowego - nie tylko ciągła integracja w. testy jednostkowe, ale testy integracyjne obejmujące naprawdę złe rzeczy, wiele platform, serwery aplikacji, maszyny wirtualne itp.
• Konfiguracja testów wydajności - im wcześniej, tym lepiej, ponieważ będziesz potrzebować danych historycznych, aby odpowiedzieć „Z jaką funkcją / kamieniem milowym wydajność spadła tak bardzo?”
• (Użytkownik końcowy) Zarys dokumentacji - Co będzie w dokumentacji? Jakiego rodzaju dokumentacja jest potrzebna?
• Kanały marketingowe - w jaki sposób ogłaszane są kamienie milowe wewnętrzne i wydania zewnętrzne? Czy masz fajną nazwę dla oprogramowania, logo, kolorów, sformułowań itp.?
• Komunikacja wewnętrzna - w jaki sposób koledzy z innych zespołów będą informowani o zmianach? Jak odbywa się współpraca? Wiki? Prawa dostępu?
• Pracownicy i proces zapewniania jakości - kto i co będzie testować, jak często i według jakich kryteriów?
• Proces wydawania - kiedy, jak często, jak, kto to robi, kto otrzymuje wydanie itp.
• Zarządzanie ryzykiem - scenariusz najgorszego przypadku (z projektu mgmt pov i z środowiska wykonawczego, np. „Klient traci pieniądze, ponieważ oprogramowanie nie działa w module X, jaki jest plan tworzenia kopii zapasowych?)
• Zabezpieczanie podstawowego środowiska programistycznego, np. Wirtualizacja go w Escrow
• Miejsca spotkań formalnych i nieformalnych
• Szkolenie lub wprowadzenie dla wszystkich ludzi, aby wiedzieli, na czym polega cała konfiguracja, do czego służy każda część i jak z niej korzystają.
• Identyfikowanie dozorcy i udzielanie mu wszystkich rzeczy (np. Pozwoleń), których musi się zająć, gdy coś pójdzie nie tak

Recenzje pośmiertne - Ponieważ pracujesz nad blokami, zaplanuję od 1 do 2 godzin przeglądu (w zależności od wielkości zespołu), aby spotkać się osobiście (jeśli to możliwe), gdzie wszyscy chodzą i mówią, co zostało zrobione dobrze, co można to zrobić lepiej, a co nie było potrzebne. Umiejętność wczesnego uczenia się na błędach w procesie programowania oznacza, że ​​możesz uniknąć ich później, gdy nie masz tyle czasu na pracę.

Zacznijmy od zatrudnienia dobrego zespołu odpowiednich specjalistów dla twojego projektu. W typowej aplikacji biznesowej trzeba zatrudnić programistę bazy danych i dba, osobę odpowiedzialną za kontrolę jakości, administratora systemu, analityków biznesowych, programistów aplikacji, specjalistę ds. Interfejsu użytkownika i kierowników zespołów. DBA, administrator systemu, analitycy biznesowi i kontrola jakości powinni znajdować się w osobnym łańcuchu raportowania niż zespół programistów. Specjalista ds. Programowania baz danych powinien podlegać temu samemu przewodnikowi technicznemu, co twórcy aplikacji i specjalista ds. Interfejsu użytkownika.

Ustaw powierzchnię biurową. Prywatne biura są świetne, jeśli możesz je zdobyć (życzę ci dużo szczęścia), ale co najmniej potrzebujesz biurków, telefonów, komputerów, tablic i kilku dedykowanych sal konferencyjnych. Upewnij się, że jest miejsce na przerwy obiadowe, lodówkę, napoje bezalkoholowe, przekąski i kawę. Darmowe napoje bezalkoholowe i kawa jeszcze lepiej.

Skonfiguruj serwery dev / qa / staging i prod dla aplikacji i baz danych. Bazy danych nigdy nie powinny znajdować się na tym samym serwerze, co aplikacje. W zależności od wielkości i zakresu projektu może być potrzebnych wiele serwerów lub sieci SAN itp. Dla każdego środowiska.

Gdy tylko serwery zostaną skonfigurowane, zaplanuj kopie zapasowe systemu plików, bazy danych i dzienników transakcji bazy danych. Zrób to już pierwszego dnia. Zatrudnij firmę taką jak Iron Mountain, aby co tydzień wykonywać kopie zapasowe poza witryną.

Skonfiguruj system kontroli źródła i utwórz dokument opisujący, w jaki sposób będzie on używany. Nie zapomnij nalegać, aby WSZYSTKIE zmiany strukturalne bazy danych i wstawienia danych dla tabel typów wyszukiwania były w skryptach w kontroli źródła. Ułatwi to wdrożenie.

Kup oprogramowanie komercyjne lub pobierz oprogramowanie open source dla zestawu narzędzi, z którego zdecydowałeś się korzystać z licencjami dla wszystkich odpowiednich użytkowników.

Kupuj szybko rozwijające się maszyny deweloperskie, które mają dwa monitory. Kup przynajmniej jedną testową maszynę użytkownika, która jęczy powoli i typowa dla tego, co użytkownicy będą mieli na swoich komputerach.

Naucz swoich nowych programistów, w jaki sposób chcesz robić rzeczy. Jeśli masz wystarczająco duży zespół, aby mieć kilku młodszych programistów, zaplanuj dla nich dodatkowe szkolenie i uwzględnij czas w planowaniu projektu. Monitoruj juniorów bardzo dokładnie przez co najmniej trzy miesiące. Monitoruj uważnie wszystkich nowych pracowników przez pierwszy miesiąc. Pozbądź się Deadwood i nieuczciwych programistów jak najszybciej.

Określ, co należy zrobić w jakiej kolejności (ścieżka krytyczna). Nie przypisuj zadań na końcu ścieżki krytycznej, dopóki zadania, na których polegają, nie zostaną ukończone.

Twórz plany i wymagania testowe.

Ustaw regularnie zaplanowane spotkania z klientami. Zasługują na to, aby wiedzieć, co robisz i jakie są blokady. Nie zapomnij powiedzieć im, kiedy będzie późno. Jeśli minęły trzy tygodnie od terminu i już wiesz, że go przeoczysz, deficyt nie zniknie magicznie, zanim będziesz musiał powiadomić klienta. Upewnij się, że klient wie, że dodatkowe wymagania oznaczają dodatkowe koszty i czas oraz że każde dodatkowe wymaganie będzie musiało zostać usunięte z innych zadań lub termin zmieni się o liczbę godzin w nowych zadaniach. Wyjaśnienie tego od samego początku pozwoli zaoszczędzić wiele bólu i nadgodzin oraz nadmiernych kosztów wchłoniętych przez twoją grupę, a nie klienta.

Skonfiguruj środowisko do testowania wydajności, nie tylko szybkość jednego użytkownika, ale takie, w którym możesz przetestować oczekiwaną liczbę jednoczesnych użytkowników. Nie czekaj, aby wykonać te testy, aż do dnia przed uruchomieniem.

Przy planowaniu projektu załóż, że kontrola jakości znajdzie błędy i że ich naprawa zajmie trochę czasu. Nie planuj kontroli jakości tylko na jeden dzień pod koniec.

Utwórz dane testowe, których rozmiar będzie mniej więcej odpowiadał wielkości bazy danych. Niech wszyscy programiści przetestują swój kod na bazie danych o tym rozmiarze. Nie zezwalaj programistom na tworzenie tylko w oparciu o małą bazę danych na ich komputerach osobistych. Jest to częsta przyczyna kodu, który działa dobrze, dopóki nie trafi do produkcji.

Zaplanuj nagrody w budżecie. Demotywuje ludzi, gdy pracują od miesięcy przez tyłki, a tylko menedżerowie otrzymują premie. Dziękuj również często i na piśmie.

Możesz potrzebować systemu zarządzania projektem lub przynajmniej skonfigurować arkusze kalkulacyjne, aby śledzić to, co musisz śledzić. Podczas planowania projektu, weź w planie nie więcej niż sześć godzin dziennie. Pomaga to uwzględnić czas, który nie zostanie poświęcony na projekt, taki jak urlop, czas choroby, wakacje, spotkania HR, oceny wydajności itp. Jeśli wiesz, że projekt jest w okresie wysokiej niedostępności (powiedzmy, że projekt jest realizowany od 1 listopada do 1 stycznia w Stanach Zjednoczonych), może być konieczne dokonanie dodatkowych dodatków na dłuższy urlop i urlop. Niesprawiedliwe jest oczekiwanie, że programiści zrezygnują z urlopu i wakacji i nikt nie jest w stanie przewidzieć, kiedy wydarzy się coś takiego jak czas choroby, obowiązek przysięgłych, czas żałoby itp. Załóż, że przydarzą się Twojemu zespołowi przy tym projekcie.

Niektóre rzeczy, których nie widzę w pytaniu i kolejnych odpowiedziach:

• Plan odzyskiwania po awarii. Jak tworzysz kopie zapasowe skrzynek programistycznych, inscenizacji, testowania itp.? Czy każdy programista ma to, czego potrzebuje do pracy z domu w okazyjny dzień śniegu? Itp.

• Plan treningowy. Ile tygodni roku szkolenia potrzebują twoi deweloperzy, aby zachować ostrość? Czy ktoś to śledzi? (Arkusz kalkulacyjny może wystarczyć większości zespołów.) Mają mechanizm zgłaszania się (wysyłanie komuś wiadomości e-mail z informacją, że obejrzały 2 godziny transmisji na „cokolwiek” jest prawdopodobnie wystarczające) i zarządzania, aby zaplanować - np. Komu powinniśmy wysłać konferencja w tym roku.

• pozycja narzędzia. Czy to „dajemy wam wszystkim subskrypcję MSDN; nie instalujcie niczego więcej na swoich komputerach roboczych” w rodzaju miejsca, czy „chcemy kodu, ale nie obchodzi nas, czego używasz do jego edycji, kompilacji i testowania " rodzaj miejsca. Podejmij i zapisz decyzję.

• tyle zintegrowanych ALM, ile możesz stać lub stać. Zwykle przyczyną „niedopasowania impedancji”, podwójnego wejścia, nakładania się narzędzia i integracji zastosowania fotela obrotowego jest to, że system rozrastał się w kawałkach. Zaczynając od zera, chcesz pokazać, że Twoi ludzie mogą pozostać w jednym narzędziu przez cały cykl. Brak wpisywania kodu w X, kompilacja z Y, testowanie z Z, zmiana statusu elementu pracy / zadania z A, raportowanie czasu spędzonego z B, informowanie osoby, która czekała, że ​​może teraz przejść do C, próbując wymyślić dowiedzieć się, co dalej robić z D, sprawdzając ogólny postęp z E itp.

Negocjuj więcej osobodni.

To rzadkie wydarzenie, gdy ludzie początkowo przeznaczają wystarczającą ilość środków.

[Później ... ponownie negocjuj jeszcze bardziej ...]

Widząc, że miałem największy problem z bibliotekami stron trzecich i ich wykorzystaniem:

1. Określ biblioteki i wersje, których będziesz używać.
2. Utwórz proces integracji aktualizacji bibliotek z projektem.
3. Upewnij się, że wszyscy programiści dokonali wyboru biblioteki.
4. Stwórz korzystny kanał do otwartej dyskusji na temat wykorzystywanych technologii.

Dlaczego? Nie mogę powiedzieć, ile razy biblioteki zewnętrzne (własnościowe) miały poważne błędy, które odesłały nam tygodnie rozwoju, ponieważ nie mieliśmy żadnego procesu przejścia w górę lub w dół. Lub radzenie sobie z programistami mówiącymi: „Której wersji użyłeś? Dlaczego użyłeś funkcji oznaczonych jako przestarzałe?”

Dużym kosztem dla organizacji nie jest przeznaczanie budżetu na bezpieczeństwo przez cały cykl rozwoju oprogramowania, co oznacza, że ​​bezpieczeństwo zwykle kończy się po nieefektywnym, kosztownym zestawie działań lub kontroli wprowadzonych zbyt późno, aby zrobić wiele dobrego.

Uzyskaj wbudowane zabezpieczenia od początkowego planu projektu, z kluczowymi kamieniami milowymi, tak samo jak we wszystkich innych aspektach rozwoju, i użyj iteracyjnego procesu, aby aktualizować wytyczne dotyczące bezpieczeństwa. Ostateczne wypisanie się z zabezpieczeń powinno być nieoczekiwanym sprawdzeniem, czy wszystkie zabezpieczenia zostały wdrożone zgodnie z projektem.

W przeciwnym razie uruchomisz zabezpieczenia po wdrożeniu - gdzie może to kosztować 8-10 razy więcej (dane Gartnera, IBM i innych), zdenerwuje ludzi, ponieważ prawdopodobnie wpłynie to na funkcjonalność i może być za późno, aby zapobiec wykorzystaniu i uszkodzenia.

1. Zabierz to do zespołu

Zapytaj programistów! Naprawdę, to jest najważniejsze. Spotkasz duży opór, jeśli deweloperzy nie będą bezpośrednio zaangażowani w tę zmianę. Po tym wszystkim, to o tym, jak one działają, a nie ty. Jest rzeczą oczywistą, ale próby narzucenia ludziom metod i narzędzi zwykle są straszne.

2. Sprawdź i dostosuj

Niech zespół wymyśli najlepszy sposób pracy, wykorzystując swoje doświadczenie, aby delikatnie pomóc mu wejść na wybrany tor. Następnie, regularnie i wspólnie, spójrz wstecz na to, jak sobie radzisz i dostosuj proces, aby był lepszy.