Jak mogę pokonać źle skonstruowany model tworzenia oprogramowania?


11

Dołączyłem do firmy, nad którą pracuję jako świeższy. Ze względu na ograniczoną liczbę wykwalifikowanych pracowników w zakresie tworzenia oprogramowania GIS, a ponieważ byłem jednym z nich, zostałem bezpośrednio zatrudniony jako kierownik projektu.

Znałem się dobrze z Javą i GIS i przeprowadziłem samodzielnie zmotywowane badania usług opartych na lokalizacji, ale nie z zarządzaniem projektami i programowaniem strukturalnym. To było rok po ukończeniu specjalizacji z geologii, a podczas poprzedniego roku pracowałem jako nauczyciel akademicki na uniwersytecie.

Dzięki zainteresowaniu, jakie miałem w pracy, pojawiła się okazja i ostatecznie zostałem również odpowiedzialny za dział Business Intelligence firmy. Firma we mnie uwierzyła. Sam studiowałem koncepcje hurtowni danych i BI i udało mi się również połączyć GIS z BI.

Obecnie współpracuję z dwoma programistami nad naszym narzędziem BI w C # WPF, w którym czasami gram rolę programisty (co lubię).

Bardzo starałem się zastosować dobre metodologie tworzenia oprogramowania przy zwinnym zarządzaniu projektami, ale nie było to bardzo udane. Ponadto, chociaż wierzę w dobrze zaprojektowany kod, jeśli chodzi o produkt, z powodu braku wiedzy technicznej mojego CEO (który jest bezpośrednio nade mną), zwykle nie mam czasu potrzebnego na to. Czas ten znacznie poprawia brak wiedzy specjalistycznej w zakresie konkretnego języka kodowania jako całości (na przykład WPF w przeciwieństwie do Javy). Nie ma również systemu kontroli wersji.

Jestem bardzo zmęczony sposobem, w jaki wszystko idzie, ponieważ nie jest on ustrukturyzowany i spędzam większość czasu zastanawiając się nad tym, jak uporządkować rzeczy. Mam nadzieję, że z dobrym doświadczeniem zawodowym pomożesz mi przezwyciężyć tę sytuację.


4
Nie jestem pewien, czy już to zrobiłeś, ale czy rozmawiałeś o tej sytuacji ze swoimi bezpośrednimi kolegami?
Fanatic23

Odpowiedzi:


14

Mieliśmy podobny problem (oczywiście bez szczegółów technicznych) w firmie, w której pracuję około dwa lata temu.

Musisz to zrobić krok po kroku. Nie staraj się szybko wdrażać zwinnego oprogramowania. Jest wiele rzeczy do nauczenia się i zastosowania. Nie pozwól też, że brakuje ci wiedzy specjalistycznej.

Buduj powoli (ale tak szybko, jak to możliwe: P), stabilnie i pewnie.

Poleciłbym kolejne kroki (aby to zrobić, możesz na chwilę przełączyć się z zarządzania na rozwój, ale to powinno być w porządku)

  1. Naucz się dobrego systemu kontroli wersji i naucz się go dobrze. Osobiście polecam git lub mercurial. Na obu jest dużo dokumentacji.
  2. Zbuduj solidny rdzeń na praktykach i wzorcach . Czytaj książki, czytaj blogi, oglądaj screencasty z członkami zespołu. To da nowe spojrzenie na rozwój.
  3. Naucz się TDD / BDD i spróbuj zastosować go w nowym kodzie , a także w starym kodzie, którego możesz dotknąć podczas wykonywania nowej funkcji.
  4. Wykonaj programowanie w parach . Dwie głowy myślą lepiej niż jedna, a także 4 oczy są lepsze niż 2 :).
  5. Znajdź najnowsze i najczęściej używane narzędzia w społeczności aktualnie rozwijanego języka. Dowiedz się o nich i spróbuj włączyć niektóre z nich do projektu. Zobacz, jak zostały zbudowane i dowiedz się.
  6. Użyj scrum . Iteracje, historie, punkty historii, przeszkody to wszystkie pojęcia, z którymi powinieneś się zapoznać. Dla mnie scrum okazał się najlepszym przepływem pracy do tworzenia i zarządzania oprogramowaniem. Zastosuj i ucz się z każdego dnia.
  7. Ucz przez przykład . Większość początkujących programistów chętnie uczy się nowych rzeczy, ale także niektórzy są bardzo leniwi. W każdym razie pokaż im nowe rzeczy, których się nauczyłeś i które stosujesz, i miejmy nadzieję, że łaskoczą ich mózg.

Jeśli to możliwe, zatrudnij konsultanta, aby mógł sprawdzić proces i udzielić lepszych porad.

Nie bądź leniwy ani zniechęcony. Po prostu ucz się na swoich błędach i wypróbuj różne podejścia. To dopiero początek!

Edytować:

Oto niektóre linki i książki, które ostatnio czytałem / używam ...

Uczenie się git: Pro Git

Oto niektóre z blogów, które poleciłbym (większość z nich jest zorientowana na platformę .NET):

W przypadku książek możesz zobaczyć listę Buiding A Solid Programming Core na Amazon. Poleciłbym również te:


@Edgar, bardzo dziękuję. To jest fajne i myślę, że to, co wyjaśniłeś, będzie dla mnie dobre. Ponieważ nie widzę innego sposobu, daj mi znać, czy dobrze jest przyjąć odpowiedź jako poprawną i trzymać się jej na ślepo.
pikmate

1
@picmate Pewnie stary, to jest twój telefon. Również na przykładzie techniki chwalcie wszelkie postępy poczynione przez programistów.
Edgar Gonzalez

@Edgar, jasne. Jeśli znasz jakieś dobre zasoby, z których mógłbym skorzystać, proszę również o podanie ich dla każdego punktu w odpowiedzi (jeśli dotyczy). Czy w ten sposób każda dobra firma programistyczna rozwija swoje oprogramowanie? (ponieważ nigdy nie miałem okazji być w dobrej firmie deweloperskiej)
pikmate

1
@picmate przede wszystkim tych kroków nie należy stosować osobno. Nakładają się na siebie, nie są w żadnej określonej kolejności (z wyjątkiem pierwszej). Później opublikuję kilka linków
Edgar Gonzalez

2
@picmate. Ponieważ CEO nie ma wiedzy technicznej na temat tego, co robisz, możesz go przekonać dzięki temu, co wie. Na przykład możesz wyjaśnić, że jeśli masz kontrolę wersji, możesz uniknąć utraty pracy, a tym samym finansowo zapobiec utracie dochodów z przywracania utraconego kodu. Lub ucząc się najlepszych praktyk programistycznych, możesz pomóc firmie, będąc wydajnym, a tym samym skrócenie czasu na opracowanie funkcji.
Onesimus Bez ograniczeń,

6

Jako menedżer Twoim zadaniem jest uzyskanie czasu potrzebnego do prawidłowego ukończenia projektu. Zbliżając się do dyrektora generalnego, upewnij się, że masz wszystkie dane , które Cię popierają, i powody, dla których szacunki są tak samo długie. To twoja odpowiedzialność jako kierownik aby uczynić prezes zrozumieć, dlaczego to trwa n godzin / dni / tygodni do ukończenia danego zadania. Czasami może to być trudne, ale nie spotkałem prezesa, który chciałby , aby jego firma upadła, i założę się, że jeśli powiesz to w takich kategoriach (jeśli wszystko inne zawiedzie), może zmienić melodię.

Jeśli dyrektor generalny nie chce dać ci czasu potrzebnego na wykonanie zadań, to IMHO bądź gotowy przejść do innej pracy lub przygotować się na ciągłe marsze śmierci. W ostateczności wyjaśnij dyrektorowi generalnemu wypalenie, które bez wątpienia wyniknie z nierealnych oczekiwań.

Powiedziawszy to, musisz także upewnić się, że programiści dostarczają ci dokładnych szacunków (niezwykle trudne, prawie niemożliwe bez odpowiednich projektów technicznych, które również powinny gdzieś tam być).

Zwinność nie jest dobra we wszystkich domenach programistycznych. Działa w przypadku niektórych typów projektów, w innych niestety zawiedzie. Być może będziesz musiał wypróbować kilka różnych metodologii, zanim znajdziesz taką, która działa dobrze .

Skonfiguruj kontrolę wersji . Naprawdę zajmuje to 5–10 minut, aby skonfigurować Git, jeszcze kilka minut, aby uprościć podstawowe operacje, i dzień lub dwa czytanie, aby upuścić bardziej zaawansowane koncepcje.


1

Hmm, nie jestem pewien, czy spotkałem cię na imprezie Agile / XP w Toronto - brzmi znajomo

Wygląda na to, że potrzebujesz przerwy. Spędź długi weekend, upij się, jeśli chcesz, i zapomnij o pracy na kilka dni.

Uspokój się. Samokształcenie jest dobre i tylko dlatego, że metodologia nie działa z zaangażowanymi osobowościami, nie oznacza, że ​​robisz to źle i nie jest to osobista porażka.

Istnieje strona (beta) pm.stackexchange.com, skierowana do zarządzania projektami, możesz tam znaleźć przydatne porady / wsparcie - ale na pewno nie zapomnij o tym tutaj.

Przechodząc do rzeczy technicznych:

nie ma systemu kontroli wersji

Postaw jeden jako najwyższy priorytet. Wolę scentralizowane systemy, takie jak SVN (Subversion), niż git / mercurial, ponieważ skradziony laptop nie będzie miał tak dużo historii lokalnie. Szczególnie ważne, jeśli coś super tajnego (np. Hasła i klucze ssh) zostało przypadkowo wpisane. Ale to kwestia gustu. Nic nie marnuje więcej czasu niż błędy z „ręcznej kontroli wersji” - np. Przywracanie kodu do tego, co myślisz.

Powodzenia


Cześć, dzięki za odpowiedź i prawdopodobnie to nie ja spotkałem się w Toronto. Jestem na tej pozycji od prawie półtora roku. Myślisz, że tracę czas bez powodzenia?
pikmate

0

Wygląda na to, że masz kilka problemów: 1. Komunikowanie się z nietechnicznym kierownictwem wyższego szczebla, aby mogli wspierać Twój program doskonalenia; oraz 2. Prowadzenie programu usprawnień do sukcesu.

Najtrudniejszą częścią numeru 1 jest po prostu pamiętanie, że kierownictwo wyższego szczebla często nie będzie zainteresowane szczegółami tego, nad czym pracujesz. (Gdyby tak było, robiliby to sami, zamiast wręczać to tobie!) Wydaje się, że wielką przeszkodą jest „dlaczego” i możesz spojrzeć na CMM 1.1 w celu uzyskania opisu korzyści biznesowych z udoskonalenia procesu program. Niezależnie od tego, czy użyjesz CMM, czy czegoś innego do faktycznego ulepszenia swojego procesu, nie będzie to miało znaczenia w tej dyskusji, tylko dane z badania Carnegie-Mellon, które pokazuje, że bardziej dojrzałe organizacje dostarczają projekty szybciej przy mniejszym zróżnicowaniu czasu dostawy.

Istnieje wiele dróg do sukcesu w procesie doskonalenia procesów, wszystkie są zwykle bardzo długie. Doświadczenie z CMM pokazuje, że przejście z poziomu 1 na 5. może zająć od 8 do 10 lat. Doświadczenie z 6 sigma pokazuje, że każda iteracja daje pewną poprawę, ale potrzebuje wielu iteracji, aby usunąć większość potencjalnych problemów i zanim do niej dojdziesz 6 znaków jakości, praca jest wykonywana zupełnie inaczej, bez ryzyka podjęcia próby zastąpienia wszystkiego na raz.

Jeśli w twojej branży powszechnie stosowane jest podejście do poprawy jakości, poświęć trochę czasu, aby sprawdzić, jak ma ono zastosowanie do oprogramowania i użyj go, aby reszta firmy słyszała o czymś, co już zna i wspiera. Możemy godzinami rozmawiać o konkretnych narzędziach i praktykach programowych, ale dyrektorzy generalni niebędący programistami szybko się zorientują. Porozmawiaj o standardowych praktykach branży, a on ożywi się, ponieważ mówisz w jego języku. Porozmawiaj o oprogramowaniu w typowych warunkach branżowych, a on zacznie zadawać odpowiednie pytania, aby lepiej zrozumieć Twoje wyzwania i Twoje plany poprawy wyników firm.

W ten sposób nie wygrasz każdego prośby o wsparcie, prawdopodobnie dostaniesz o wiele mniej pustych spojrzeń i więcej wygranych!

Powodzenia, proszę pana!


0

Wszystkie wasze sugestie są rzeczywiście rozsądne i są drogą dla wielu firm. Ale nie są uniwersalne, szczególnie w zespołach, które nie są tak doświadczone. Powodem, dla którego tak nie jest, jest to, że wymagają trochę pracy, aby skonfigurować i utrzymywać - nawet kontrolę wersji - co wielu uważa, że ​​jest to stawka dla każdego projektu oprogramowania. Ponieważ wymagają one trochę pracy, muszą również zapewnić pewne korzyści. I może być tak, że w twojej konkretnej sytuacji tak nie jest! A przynajmniej ludzie, których zadaniem jest podejmowanie decyzji, nie widzą korzyści!

Jak zauważyli inni, musisz:

  • Spróbuj po kolei zastosować praktyki. Nie próbuj ich wszystkich naraz, bo to przytłoczy ludzi.
  • Musisz znaleźć na to dobre zamówienie. Zacznę od kontroli wersji. Wybierz też te łatwiejsze. Gdy ludzie zaczną ufać, że podejmujesz dobre decyzje, i zobaczą korzyści, będą bardziej skłonni do wprowadzania bardziej ryzykownych zmian.
  • Zbuduj solidne uzasadnienie, dlaczego coś trzeba wdrożyć. Z 2-3 deweloperami, którzy stale robią postępy widoczne dla użytkowników końcowych, trudno uzasadnić przyjęcie na przykład bardziej skomplikowanej metodologii programowania. Będziesz postrzegany jako skoncentrowany na procesie, a nie na wynikach.
  • Pamiętaj, kogo musisz przekonać. Devs? Dyrektor Generalny?
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.