Spędzam dużo czasu pracując nad projektami, w których jestem jedynym programistą, kierownikiem projektu, projektantem, osobą QT (Tak, wiem ... Źle!), A czasami nawet jestem klientem.

Próbowałem prawie wszystkiego do planowania projektów i zarządzania sobą, od siedzenia i freestyle'u, aż projekt się skończy, bez względu na to, jak długo to zajmie, po jednoosobową wersję scrum, w której odbyłem spotkanie postępowe ze sobą -man codziennie wypala wykres (nie żartuje).

Dla tych z was, którzy spędzają dużo czasu pracując samotnie, jaki jest najlepszy sposób na zorganizowanie siebie, zarządzanie dużymi (dla jednej osoby) projektami i utrzymanie maksymalnej wydajności?

Prowadzenie jasnej listy celów jest bardzo ważne. Funkcja pełzania funkcji może łatwo przejąć samodzielnie zarządzany projekt. Pomocne jest również podejście TDD „gotowe, gdy działa”. Zapobiega to zostaniu perfekcjonistą.

Jedną rzeczą, która naprawdę mi pomaga, jest wyobrażenie sobie, co powiedziałby inny inżynier lub kierownik projektu w danej sytuacji. Często jestem w stanie „zawstydzić się” z powodu złego kodu lub wrócić na właściwe tory, jeśli harmonogram się zmienia.

Proszę bardzo ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP ładnie się obniża, ponieważ jest optymalny dla małych skupionych zespołów.

• Możesz utworzyć arkusz kalkulacyjny z żądaniami dotyczącymi funkcji, nadać im priorytety i wybrać najwyższe.
• zdefiniuj kryteria akceptacji (jak to wygląda) i zakoduj je w teście wykonywalnym
• Następnie określ zadania inżynierskie do wykonania
• Pisz testy jednostkowe, rób najprostsze rzeczy (YAGNI) i cały czas refaktoryzuj. Celem jest zaliczenie zewnętrznego testu akceptacyjnego
• Timebox każdej sesji. Aby efektywnie zarządzać czasem, możesz również spojrzeć na technikę Pomodoro .
• Użyj kontroli wersji i skonfiguruj serwer CI / plik wsadowy, aby utworzyć instalację lub plik zip
• Demo często. Prześlij opinię do oryginalnego arkusza kalkulacyjnego i ponownie ustal priorytetyzację

Jedyne, czego nie można zrobić w jednym zespole, to programowanie w parach.

Jeśli pracujesz solo. Oto porady:

1. Wykonuj jak najmniej pracy na niskim poziomie. Używaj tyle bibliotek i narzędzi, ile możesz, w tym rzeczy, które Twoim zdaniem możesz łatwo kodować (nie rób tego, po prostu skorzystaj z biblioteki).
2. Wybierz podejście odgórne. Koduj tylko te rzeczy, których naprawdę potrzebujesz.
3. Kiedy widzisz problem w abstrakcyjnym słowie, szukaj w google i korzystaj z dokumentów naukowych ze społeczności akademickiej, które zostały już udowodnione. Musisz tylko zakodować ich algorytm.
4. Zaprojektuj swój system, aby móc dowolnie zmieniać rzeczy w jak największym stopniu. (w tym skopiuj i wklej kod odtąd do tego miejsca). Celem jest zaoszczędzenie czasu, gdy zdasz sobie sprawę, że popełniłeś błąd. Postaraj się zminimalizować ilość pracy, którą musisz wyrzucić, gdy popełnisz błąd. Kawałek kodu, który należy wyrzucić (zamiast kopiować-wkleić tu i tam) to ekwiwalent czasu, który straciłeś podczas pisania tego kodu.
5. Mają wiele automatycznych testów, dzięki czemu możesz regularnie wykonywać testy regresji za każdym razem, gdy wprowadzasz zmiany
6. Rozdziel obowiązki związane z projektem (tj. Zmniejsz sprzężenie). Spraw, aby wszystko było jak najbardziej modułowe
7. Użyj debugera do debugowania i użyj wyszukiwania binarnego, aby znaleźć defekt.
8. Stale zmieniaj kod, aby zmniejszyć (jawne) sprzężenie i ujawnienie metod publicznych (niejawne sprzężenie).
9. Nic takiego. To jest tutaj na wypadek, gdybym mógł wymyślić coś nowego: P.

Recenzje kodu.

Są one szczególnie przydatne, ponieważ wyjaśnisz kod komuś, kto nie pracował nad tym samym projektem, aby nie miał żadnych twoich założeń dotyczących tego, jak powinien on działać.

Dodatkową korzyścią będzie dzielenie się wiedzą w firmie, więc gdy ktoś musi pracować nad projektem (z powodu ludzi zajętych gdzie indziej, z powodu choroby, rezygnacji lub zwolnienia), nie będą musieli zaczynać od zera .

Stworzyłem własną wersję zwinną, opartą na historiach, intensywnych interakcjach z klientami, częstych wydaniach i rozwoju opartym na testach. Korzystam z wiki, aby śledzić historie, jak najbardziej angażować klienta w ich pisanie, i zlecić klientowi współpracę przy ustalaniu priorytetów i organizowaniu wydań. Używam TDD do sterowania projektem i implementacją. Skonfigurowałem serwer kontroli jakości, na którym klient może wypróbować częste wersje (czasem codziennie w miarę opracowywania nowych funkcji), aby szybko uzyskać informacje zwrotne. Rzadko wybieram więcej niż 3 iteracje bez wydania QA. Klient może zdecydować, kiedy wersja kontroli jakości ma wystarczającą liczbę funkcji, aby uruchomić - i czy nie ma już potrzeby rozwijania innych funkcji z listy.

W mojej firmie cała nasza grupa pracuje nad tym samym projektem, ale na stosunkowo niezależnych odcinkach. Jedną z wielu rzeczy, które tutaj robimy, jest to, że coś, co robisz, wydaje się trochę trudne, lub jesteś na rozwidleniu drogi z więcej niż jednym sposobem na wdrożenie czegoś, łapiesz kogoś innego i przedyskutujesz zalety i wady wcześniej kontynuujesz. Jeśli czekasz, aż kod zakończy się przeglądem, zwykle zainwestowałeś już zbyt dużo czasu, aby rozważyć poważne zmiany w architekturze, choć z pewnością wiele błędów jest wykrywanych w recenzjach kodu.

Zdaję sobie również sprawę, że Test Driven Development to ostatnio modne hasło, ale może być dużą pomocą dla deweloperów solo, ponieważ zapewnia kontrolę jakości w trakcie pracy, a kiedy testy stają się trudne do napisania, wiesz, że prawdopodobnie potrzebujesz restrukturyzacji kod. Pomaga także późniejszym opiekunom nie przypadkowo złamać kodu w trudny do wykrycia sposób.

Proponuję następujące:

1. Rozwój oparty na testach
2. Wykorzystaj w swoim kodzie „TODO: uwaga tutaj”, gdy zobaczysz coś, czego nie możesz zrobić natychmiast, i wróć do nich, gdy będziesz miał czas na pozostanie na Facebooku i czekanie, aż klient oddzwoni
3. Napisz kod, ponieważ klient kupi go, patrząc na kod nie tylko na wynik, wyobraź sobie, że jest on przewodniczącym przeglądu kodu.
4. Wypełnij swój kod stwierdzeń

chciałbym móc powiedzieć, że byłem w stanie ćwiczyć to, co głosiłem w 100% przypadków, ale BDD wydaje się być dobrym podejściem do twojej sytuacji:

Oto link z dodatkowymi informacjami: http://en.wikipedia.org/wiki/Behavior_driven_development

Jestem na bardzo podobnej łodzi. Staram się przestrzegać zasad zwinnych (tak jak je rozumiem), jak to tylko możliwe. Prawdopodobnie nie robię rzeczy „poprawnie”, ale odniosłem duży sukces w swoich projektach, starając się przestrzegać zwinnych zasad. Wymaga to ogromnej dyscypliny, ponieważ nie ma zespołu, który zapewniłby, że nie zaczniesz używać skrótów.

Uważam, że użycie narzędzi do formatowania kodu, takich jak ReSharper, zapewnia, że ​​przynajmniej wizualnie kod jest łatwy do pobrania dla innych programistów.

Jeśli chodzi o rzeczywiste metodologie, pojedynczy programista ma trudności z trzymaniem się konkretnego. Jestem konsultantem, który zasadniczo pracuje sam i uważam, że zarówno ja, jak i klient najłatwiej jest zastosować zwinny proces. Zazwyczaj staram się, aby moi klienci bezpośrednio wprowadzili swoje wymagania do narzędzia takiego jak Trac (lub zrobię to w ich imieniu). To nie tylko pomaga innym programistom zidentyfikować cel kodu, ale także ciebie 3 miesiące później!

filozofia: XP / TDD + GTD

Ogólny zarys:

• rozmowy z zainteresowanymi stronami
• makiety ekranów, instrukcje, prototypy papierowe (w razie potrzeby)
• burza mózgów na temat fabuły / historii (z udziałem zainteresowanych stron i bez nich)
• „burza mózgów” (z udziałem zainteresowanych stron i bez nich)
• ogólny czas projektowania / architektury (w razie potrzeby)
• planowanie iteracji (z interesariuszami)
• iteracje
• przegląd procesu, szkolenie, planowanie konserwacji itp. (w razie potrzeby)

Każda odpowiednia metodologia pomoże - bez względu na liczbę osób biorących udział w projekcie. Wybierz jeden na raz i zobacz, jak możesz aplikować i mapować domenę oraz mierzyć ich sukcesy.

Być może bardziej interesujące jest pytanie, jakich metod nie należy wyrzucać, ponieważ nad projektem pracuje tylko 1 osoba.

Kluczową rzeczą, która mnie wyróżnia, jest Kontrola Źródła (Tak, to narzędzie, ale jest częścią twojego przepływu pracy, a więc także procesu). Ludzie mogą mieć pokusę, aby dać to hasło, ponieważ „nie muszą obsługiwać wielu osób edytujących kodu w tym samym czasie”.

Jak na ironię, dystrybucja kontroli wersji, taka jak GIT, jest lepsza dla osób indywidualnych niż SVN.

Jeśli zostanie wyrzucony, kod może być nieco luźny z metodologią, ale cokolwiek ważnego i powiedziałbym, że twój sposób traktowania go jako projektu zespołowego z jedną osobą jest bardzo miły i zdyscyplinowany.

Napisz swój kod do przeczytania przez następnego faceta, a nie ty ... bądź dla niego miły. Nawet kod „wyrzucania” pozostaje na zawsze.

Zwinny

funkcje, historie i przypadki testowe są o wiele bardziej pouczające niż bardziej formalna dokumentacja, a zestaw testów roboczych lepiej pokazuje, jak czegoś użyć lub jak działa coś, niż jakakolwiek ilość martwych drzew

Łatwiej jest także przekazać pracę pomiędzy iteracjami.

Jako konsultant z mojej strony sugerowałbym, abyś znalazł sposób, aby zawsze mieć co najmniej dwóch programistów przy każdym zadaniu.

Zgadzam się na zwinność i pozostawienie zwinnego śladu historii i testów, które inni mogą wykonać, ale nie wierzę, że jakikolwiek inny proces lub metodologia będzie się utrzymywać, gdy ludzie będą pracować solo.

Myślę, że recenzje kodu są dobrym początkiem, ale podoba mi się, gdy są nieformalne i przyjemne, np. Przeglądanie kodu pary lub programowanie w parę w celu rozwiązania określonego problemu / problemu lub ulepszenia (np. Zmiana starszego kodu w celu spełnienia nowych standardów kodowania ). Czasami dwa zestawy oczu są lepsze od jednego i jest to również zabawne, czuję, że dzielenie się i dyskusja wydają się bardziej otwarte. Możesz także zjeść oficjalny / nieformalny lunch i przedyskutować sesje, aby porozmawiać o tym, co zrobiłeś indywidualnie lub w grupie, np. Wspomnieć o nowym wzorcu, który zastosowałeś lub nowych technologiach, w jaki sposób problem został rozwiązany?