2009-09-23 6 views
35

Pracuję jako samotny programista w bardzo małej firmie. Moja praca jest dość chaotyczna i szukam sposobów na jej lepsze zorganizowanie.Jaki rodzaj procesu tworzenia oprogramowania powinien mieć samotny programista?

Jednym z problemów jest to, że moje projekty praktycznie nie mają zarządzania. Rzadko ktoś pyta mnie, co robię, lub jeśli mam jakiekolwiek problemy. W pewnym momencie mówiono o cotygodniowych spotkaniach statusowych, ale to już jakiś czas temu. Wydaje mi się, że gdybym chciał czegoś takiego, sam musiałbym to zorganizować ... Czasami jestem trochę zagubiony w tym, co powinienem zrobić, ponieważ nie mam zadań ani jasnego harmonogramu.

Z książek i artykułów Znalazłem wiele rzeczy, które mogą być pomocne. Podobnie jak w przypadku dobrego standardu kodowania (istnieje tylko szorstki przewodnik, który jest nieco przestarzały w mojej opinii), inspekcje kodu, TDD, testowanie jednostkowe, baza danych błędów ... Ale w małej firmie wydaje się, że nie ma zasobów ani czasu wszystko, co nie jest niezbędne. Fakt, że pracuję w domenie osadzonej sprawia, że ​​rzeczy stają się bardziej skomplikowane.

Czuję, że istnieje również zwyczaj robienia zakrętów i szybkiego robienia szybkich ataków. Prowadzi to do niedokończonych i nieprofesjonalnych produktów i błędów czekających na pojawienie się w późniejszym terminie. Wyobrażam sobie, że są one również trudem do utrzymania. Tak więc, mam zamiar odziedziczyć trudną bazę kodu, robiąc nowy rozwój, który wymaga uczenia się wielu nowych rzeczy i myślę, że staram się zbudować proces dla wszystkich w tym samym czasie. W końcu może to być satysfakcjonujące, ale jako niezbyt doświadczony nie jestem pewien, czy mogę to zrobić.

W małym takim sklepie środowisko jest dalekie od optymalnego do programowania. Jest wiele innych rzeczy, które należy wykonywać od czasu do czasu, takie jak obsługa klienta, odpowiadanie na telefon, podpisywanie paczek, testowanie sprzętu, montaż i wszelkie inne zadania, które mogą się pojawić. Więc masz pomysł na temat zasobów. To nie wszystko, co złe (czasami jest to oświecające rozwiązanie niektórych problemów klientów) i uważam, że można go poprawić, ale inne rzeczy mnie naprawdę interesują.

Czy możliwe jest przeprowadzenie procesu rozwoju w takim miejscu?

Czy pomogłoby to w zarządzaniu? Jakiego rodzaju?

Czy można wytwarzać wysokiej jakości produkty przy użyciu niewielkich zasobów?

Jak przekonać siebie i innych, że firma, która od dziesięcioleci z powodzeniem działała, musi się zmienić? Co byłoby niezbędne?

Może jest ktoś, kto pracuje w podobnym sklepie?

+0

Podobne pytania: http://stackoverflow.com/questions/130592/is-continuous-integration-important-for-a-solo-developer i http://stackoverflow.com/questions/131282/would-it- make-sense-to-use-wersja-control-if-im-the-only-developer-closed. Ale nie twierdzę, że zidentyfikowałem duplikat, BTW. – dmckee

+0

Dzięki. Jakoś tęskniłem za tagiem autora solo. –

Odpowiedz

6

Moja rada nie jest ekstremalna. Z mojego doświadczenia, czysty zwinny lub czysty tradycyjny nie zadziała. Zanim użyjesz jakiegoś procesu, wiedz, co to znaczy rozwiązać.

Ja osobiście używam wersji Agile RUP. Wykonuję pewne wysiłki, takie jak zbadanie faktycznych potrzeb, wykonanie projektu na wysokim poziomie z możliwym rozszerzeniem. Poproś klienta o podpisanie ważnych wymagań na wysokim poziomie.

Jeśli pracujesz w małej grupie, szczegóły projektu lub specyfikacji mogą nie być warte. Oczywiście, jeśli istnieje wiele bibliotek, które są wspólne dla wielu, to będzie to warte kłopotów.

Decyzja o inwestowaniu z góry w zależności od ryzyka (prawdopodobieństwa i skutku).

Co więcej, wiele najlepszych praktyk SW jest naprawdę "najlepszą" kontrolą wersji, automatycznymi testami (dla mnie użyłem jej tylko do wczesnego wykrywania regresji, ponieważ nie wierzę w TDD jako siłę napędową rozwoju). Sugeruję przeczytanie "Pragmatic Programmer" przedstawia wiele z tych technologii.

Aby odpowiedzieć na pytania:

(1). Czy możliwe jest przeprowadzenie procesu rozwoju w takim miejscu?

Tak, ale jak już mówię, dodaj to do swojej organizacji.

(2). Czy pomogłoby to w zarządzaniu? Jakiego rodzaju?

Zarządzanie pomaga, ale nie ma maniaka kontroli. Zaplanuj, co należy zrobić, gdy: zintegrować, rozwiązać konflikt, martwą linię kamienia milowego. I z grubsza trzymajcie je zgodnie z harmonogramem (szczególnie lubię sprint Scruma).

(3). Czy możliwe jest wytwarzanie wysokiej jakości produktów przy użyciu niewielkich zasobów?

Zdecydowanie tak szybko, jak wielkość pracy, czas opracowania i wielkość zespołu jest równowaga. Jeśli definicja jakości jest taka sama jak dla mnie. Dla mnie jakość oznacza: rozwiązać problem, na który się stara, w sposób skuteczny i niezawodny.

(4). Jak przekonać siebie i innych, że firma, która od dziesięcioleci z powodzeniem działała, musi się zmienić? Co byłoby niezbędne?

Wskaż problemy. Jeśli ich nie ma, po co zmieniać? Jeśli chcesz się zmienić, powinieneś być w stanie zidentyfikować problem LUB potencjalne problemy. Wskaż problem.

Niektóre duże jeden to:

  • Bez procesu, to jest trudniejsze dla nowych zwerbował do mieszają się jak muszą nauczyć z obserwacji innych, jak radzić sobie z rzeczami.

  • Bez procesu trudniej jest pracować w stresie.

  • Bez harmonogramu trudno jest określić postęp.

  • Bez automatycznego testowania identyfikacja problemów i regresja będą wymagały więcej czasu.

  • Bez kontroli wersji trudniej będzie się wycofać z błędu, a oddzielenie pracy od każdego członka zespołu będzie nieładne.

Po prostu moje.

+0

Przyjmę to jako najbardziej kompletną odpowiedź. Dzięki. –

17
  1. Zastosowanie sterowania źródło wszystkiego
  2. Opracowanie specyfikacji i dostać SIGNOFF przed rozpoczęciem - nie będzie opór, ale wytłumaczyć, że to dla ich własnego dobra.
  3. Testy jednostkowe! To boli, ponieważ po prostu chcesz to zrobić, ale to cię uratuje na dłuższą metę.
  4. Śledzenie błędów - Bugzilla lub FogBugz, jeśli możesz sobie na to pozwolić.
+2

Nie zgadzam się na specyfikacje, ale mam ogólny plan. Proponuję trac na błędy, jest on darmowy i trywialny w konfiguracji i całkiem piękny. –

+0

Co robisz zamiast specyfikacji? – lod3n

+1

W domu? Po prostu piszę ogólne plany. Nie będę miał długiego i nudnego spotkania z samym sobą, w którym przedstawiam każdą potrzebną rzecz, udokumentuję ją, a następnie zgłoś się, jeśli spełni moją specyfikację. Po prostu planuję ogólną funkcjonalność, ogólny projekt i dążę do tego. –

2

Musisz pracować z właścicielem i ustawić krótkie średnio- i długoterminowe cele. Będziesz chciał poinformować ich o postępie, nawet jeśli tylko przez e-mail.

Musisz egzekwować niektóre zamówienia w dniu pracy lub nigdy nie będziesz mieć nic do zrobienia (te długoterminowe cele).

Podzielić dzień się na kawałki, kiedy można kod, gdy pracuje na hacki do utrzymania go togther, podczas odbierania wiadomości e-mail itd.

Zdecydowanie setup bug tracker. Może to pomóc w utrzymaniu czystości poczty e-mail. Możesz nawet skonfigurować adres e-mail, aby przesyłać dalej błędy, które mają zostać skategoryzowane później. Jest to dobre, ponieważ reporterzy błędów będą w końcu zmęczeni śledzeniem błędów i mimo to chcą tylko wysyłać e-mailem te błędy.

edit

I jak lod3n powiedział, kontroli źródła, ale używasz już prawo ??? !!?!

+0

Tak. Mam konfigurację źródła dla mojego nowego projektu, ale nie było w przeszłości nic. –

1

Masz system śledzenia błędów, zarówno w przypadku usterek, jak i nowych funkcji. Nie polegaj na swojej pamięci.

Ciągła integracja i zautomatyzowana kompilacja mogą pomóc nawet jednemu deweloperowi.

Nie można wystarczająco podkreślić zaleceń dotyczących kontroli źródła.

-1

Po pierwsze, rozróżnienie pomiędzy procesem rozwoju i najlepszymi praktykami. Najlepsze praktyki, takie jak sterowanie źródłami, śledzenie defektów, testowanie jednostkowe itp. Są podane.

Następnie są rzeczywiste procesy rozwoju. Zawsze polecałbym proces, bez względu na to, czy jest to mały czy duży zespół. Sztuką jest znalezienie odpowiedniego procesu. Masz teraz proces - to tylko proces ad-hoc, który wydaje się nie działać zbyt dobrze dla Ciebie. Rzadko można wziąć proces opracowywania podręcznika i bezpośrednio go zastosować. To, co musisz zrobić, to dostosować proces do potrzeb i kultury firm. Spójrz na jak najwięcej paradygmatów rozwoju i spróbuj znaleźć coś, co dobrze pasuje i zacznij formować je według własnych potrzeb. Być może będziesz musiał spróbować zakończyć się niepowodzeniem z wieloma różnymi procesami. Być może proces Personal Software będzie dobrym początkiem, może proces zwinny, wariant RUP? Masz wiele opcji, zacznij je wypróbowywać.

Będziesz także musiał współpracować z resztą organizacji - muszą one być częścią procesu. Możesz być samotnym programistą, ale proces rozwoju wymaga czegoś więcej niż programisty, angażuje każdą osobę, która ma głos lub wpływ na produkt.

To może nie być konkretna odpowiedź, ale moim celem jest, abyś potrzebował jakiegoś procesu. Więc zacznij je badać i wypróbowywać i dopasowywać do swoich potrzeb, aż znajdziesz coś, co działa.

2

Byłem tam, zrobiłem to.

Bardzo pomogła książka Planning Extreme Programming. Użyłem 3x5 kart przyklejonych do ściany. Dzięki temu mój szef był informowany o moich postępach, pomógł mi w oszacowaniu i planowaniu i utrzymał mnie na dobrej drodze. Gra planistyczna daje dobrą amunicję, jeśli oczekiwania twojego szefa są nierealne.

Testowanie jednostek, jak stwierdzili inni, pomaga nawet jeśli jesteś jedynym programistą. Uważam, że styl TDD jest wartościowy.

lod3n ma absolutną rację co do kontroli źródła.

Wcześniej przeszedłem z iteracjami w stylu XP; możesz również utworzyć zaległe pozycje (nawet coś prostego, jak arkusz kalkulacyjny lub karty 3 x 5).

Unikaj morderstw. Trzymaj się 40 godzin w tym sensie, że nie pracujesz w nadgodzinach 2 tygodnie z rzędu. Poświęć dodatkowy czas poza pracą, ucząc się nowych umiejętności - nie tylko technologii, ale także zasad i najlepszych praktyk.

1

Szalony, jak to brzmi Używam scrum tylko dlatego, że lubię koncepcje sprintów i zaległości. Ułatwia wyznaczanie realistycznych celów. Oczywiście pomysł mistrza scrum i zespołu to wszystko, ale jeśli pracujesz nad projektami zewnętrznymi, gdzie możliwe jest, że możesz wybrać dodatkowego członka zespołu z zaległościami, łatwo będzie rozprowadzić pracę. Może po prostu lubię zaległości. W przypadku scrum, musisz poprosić kogoś, aby był menedżerem produktu i mówić o funkcjach produktu. Kontrola wersji jest koniecznością prawdopodobnie powinna być zaimplementowana b4 nawet martwiąc się o proces tworzenia oprogramowania. Pracowałem w firmie, która zaczęła od 2 deweloperów i poszła do 12 w roku. Zaczęliśmy bez kontroli wersji i niskich standardów kodowania. Zmiany, które musisz wprowadzić, będą stopniowe, więc nie przejmuj się spieszyć, aby zrobić 180. Ustaw cel, aby zmienić jedną rzecz na miesiąc i znaleźć zwolenników swoich zmian, aby wszystko poszło gładko.

0

Oprócz zaleceń innych osób powiedziałbym, że jeśli masz ograniczone zasoby, ale masz więcej do powiedzenia na temat sposobu, w jaki można zrobić coś, powinieneś dobrze wykorzystać produkty z półki i otwarte oprogramowanie oraz biblioteki. Wykorzystuje to wysiłki innych, oszczędzając czas, sprawia, że ​​baza kodów nie staje się zbyt ezoteryczna i dodaje do twojego zestawu umiejętności, dzięki czemu nie stajesz się ekspertem od czegoś, co jest bezużyteczne wszędzie.

Powiązane problemy