Czy freelancer może stosować zwinny rozwój?

Chcę poprawić sposób tworzenia oprogramowania. Chcę opracować szybszy i świetny kod! Dziś używam metody kaskadowej jako freelancer, pisząc rzeczy w sieci (strony, systemy itp.). Czy istnieje sposób wykorzystania zwinnego programowania (XP, SCRUM itp.) Działającego w ten sposób? Nie wiem nic o zwinnym rozwoju, od czego powinienem zacząć? Dziękuję Ci bardzo.

... Z pewnością inne niż programowanie parowe. ;-)

Poważnie, jestem również freelancerem i używam zwinnych technik, jak tylko mogę. To działa dla mnie bardzo dobrze. Bardzo korzystam z TDD,

Nikt nigdzie nie używa 100% XP lub Scrum, ale wszyscy używają jego części, starając się przyjąć tyle, ile dla nich działa. Moim zdaniem im więcej przyjmujesz, tym lepiej.

Najbardziej tęsknię za programowaniem par. Sposób na przezwyciężenie tego

1. Idź na wiele spotkań grup użytkowników.
2. Znajdź kilku ludzi, których szanujesz jako programistów.
3. Poproś ich, aby spotkali się przy kawie lub napisali kod. Od czasu do czasu daj im część swojej stawki godzinowej, jeśli uważasz, że jest to konieczne, lub po prostu zareaguj uprzejmie na pracę nad kodem.
4. Weź udział lub stwórz Hack Club taki jak ten: http://www.DallasHackClub.org .

Oto niektóre zasoby, z których korzystam:

• Programowanie ekstremalne - szybki, ale dokładny przewodnik online po XP.
• Świetny przegląd Scrum .
• Fantastyczna i krótka książka . Idealna dla Ciebie!

Powiedziałbym więc, że użycie Agile jako freelancera ma trzy główne „niesamowite punkty”:

1. W przypadku większych klientów, praca / rachunek w iteracjach. Pod koniec iteracji klient może kontynuować pracę nad projektem lub zakończyć projekt (tj .: osiągnął swój cel). Wiem (z doświadczenia), że nie jestem w stanie oszacować dobrze na więcej niż kilka tygodni, a płatność za iterację utrzymuje przepływ gotówki. Nie jest fajnie być w 6 miesiącu 3-miesięcznego projektu i czekać aby zakończyć projekt, aby móc bil ...

2. Zwinny oznacza zmianę. Zrobiłem mnóstwo projektów z ustalonymi stawkami (które według ciebie możesz zrobić z wodospadem), które straciły mi pieniądze, z powodu żądania klienta w połowie cyklu. Zmiana się dzieje: klient może zmienić priorytety biletu, aby szybciej wykonać inną pracę, a może źle zaplanowałeś i nie zrobiłeś tyle, ile się spodziewałeś.

3. Dobre narzędzia do współpracy z klientem. Moje standardowe oszacowanie (w przypadku czegoś mniejszego niż wartość iteracji pracy) jest w rzeczywistości serią etapów rozwoju zależnego od zachowania wywodzącego się z oczekiwań klienta. Wysyłam to do klienta i mówię „Czy to prawda?”. Zapewnia to, że wszyscy są na tej samej stronie.

4. Najprostsza rzecz, która może działać. Podczas pracy należy o tym pamiętać: nie bój się wrócić do klienta i powiedzieć: „Gdybyśmy to zrobili w ten sposób, byłoby to znacznie prostsze (lub bardziej wydajne). „

5. Scrum jest ważny. Lubię wysyłać moim klientom e-maile każdego dnia, gdy pracuję nad ich projektem. To jest dla nich moje scrum: „nad czym dzisiaj pracowałem”, „nad czym / kiedy będę pracował nad ich projektem?”, „Czy coś jest na mojej drodze?” I „Ogólnie rzecz biorąc, jak idzie postęp ?

6. Rozwój oparty na testach jest również bardzo przydatny, nawet jako pojedynczy programista. Moje „szacunki z zawartymi w nich historiami BDD” pomagają mi nakarmić ten proces.

Świetnym sposobem na rozpoczęcie swojej zwinnej podróży jest skonfigurowanie przepływu pracy za pomocą systemu KANBAN.

Po prostu mamy 3 linie pływackie:

1. Nasze zadania lub zaległości
2. Nad czym pracujemy lub W TRAKCIE
3. Rzeczy, które wykonujemy lub GOTOWE.

Ten prosty przepływ pracy Agile to świetny sposób na rozpoczęcie.

Jeśli chodzi o kodowanie, polecam korzystanie z programowania testowego (TDD). W naszym artykule umieściliśmy wiele świetnych linków opisujących TDD, ale skopiujemy je tutaj:

Aby uzyskać więcej informacji, sprawdź następujące zasoby:

• AgileData.org - Świetne źródło do programowania opartego na testach.
• JamesShore.com - Kolejna świetna awaria dla TDD
• Net Tuts - fajne wprowadzenie do TDD, które lubię!
• Artima - Wywiad z Martinem Fowlerem
• Games From Within - dobre studium przypadku TDD
• DaniWeb - Wprowadzenie do TDD dla programistów
• Mark Levison - artykuł na temat TDD

Ponieważ jesteś osobą fizyczną, najlepiej jest podejść do zwinnych metodologii jako czegoś, co pomoże Ci zrozumieć, co działa najlepiej dla Ciebie . Są po to, aby pomóc ci osiągnąć płaskowyż „nie ma łyżki”, ale to, jak dokładnie to się stanie, zależy wyłącznie od ciebie, a to, co wymyślisz w końcu, będzie w dużym stopniu pokrywać się z niektórymi metodologiami na różnych poziomach, jednak będzie to coś całkowicie twojego.

Ponieważ próbujesz znaleźć swój własny sposób działania na rzecz poprawy ogólnej skuteczności, oto kilka wskazówek, które pomogą Ci przynajmniej nie popełnić tych samych błędów, które popełniłem:

Zrezygnuj ze wszystkich rozwiązań programowych ukierunkowanych wyłącznie na zwinne metodologie, tak długo jak możesz.

Fakt, że lepiej nadają się do ułatwiania współpracy w zespole, nie ma znaczenia. Oprzyj się pokusie. Nie ograniczasz się do robienia rzeczy, a potem masz nadzieję, że przyjęcie tego okaże się najlepsze. Nie, po prostu cię frustruje. Najpierw znajdziesz sposób na zrobienie czegoś, a następnie szukasz odpowiedniego rozwiązania programowego. Skończyło się na użyciu tablic (zacząłem od jednej, ale teraz mam dwie w moim pokoju) do śledzenia / rozwijania historii i techniki Pomodoro | Dzisiaj robić listy, aby śledzić swoje zadania rozwojowe i to friggin 2011. trzymać się podstaw aż dojdziemy niektóre interfejsy, takie jak te obecnie Iron Man 2 lub latające samochody zaczynają się pojawiać.

Odbicie, odbicie, odbicie

To właśnie zrozumiałem, że jest to najważniejsza część każdej metodologii dla jednostki. Chodzi o opracowanie tego przepływu pracy, który daje całościowy widok na Twój projekt, dzięki czemu możesz śledzić, co należy zrobić i kiedy w sposób łatwy do zarządzania i gdzie rzadko podejmowane są złe decyzje i wyróżniać się, aby można je szybko poprawić zanim spowodują jakiekolwiek szkody ... ale nie można po prostu zdjąć z półki. Zacznij gdziekolwiek i gdziekolwiek. Trzymasz się go tak długo, jak to działa. Zainwestuj w śledzenie dobrych, złych i tak sobie. Popraw swoje założenia, a następnie odpowiednio dostosuj sposób robienia rzeczy. To jedyny sposób na poprawę.

Przestrzegaj terminów, skup się na tym, jak szybko wykonujesz swoje zadania

Prawdopodobnie byłem jak następny facet, kiedy zaczynałem, ścigając daty. Wykresy wypalenia? Kiedyś myślałem o nich jako o sposobie wizualizacji mojej ścieżki rozwoju w terminie. To wydajność, a nie model szacunkowy. Jest czas, aby zmierzyć efektywność, zastanawiając się nad pracą wykonaną w określonym przedziale czasowym, a nie tylko głupią wartością reprezentującą odległość przed upływem terminów. Rzeczywistość jest taka, że ​​rzeczy są robione, kiedy są wykonywane, a twoja metodologia powinna to uwzględnić.

Odbiegaj odpowiednio

W końcu, kto mówi, że musisz korzystać z historii użytkowników lub czegoś, co wiemy na ten temat? Nie myśl tak. Jeśli wolisz myśleć o funkcjach, z całą pewnością przeciwstaw się globalnej społeczności programistów i zrób to po swojemu, ponieważ na koniec dnia najważniejsze jest wykonywanie zadań. Jeśli czujesz, że robisz coś źle, gratulacje - właśnie stwierdziłeś, że nadszedł czas, aby przejść do czegoś innego. Chodzi o to, co jest, a nie jak.

Odpowiedziałbym: „jak chcesz poprawić sposób tworzenia oprogramowania?”. Jakie są największe problemy dla twojego modelu biznesowego związane z metodologią wodospadu?

Czy Twoim celem jest szybszy rozwój, bardziej niezawodny kod, większe ponowne wykorzystanie, spełnianie / dostosowywanie się do zmieniających się wymagań itp.? Istnieją różne metody rozwiązywania różnych problemów.

Oczywiście przyjęcie metodologii projektowania innej niż Waterfall może być bardzo przydatne w efektywnym zarządzaniu cyklem życia projektów w zależności od wymagań biznesowych. Do sprawnego rozwoju istnieje ogromna liczba zasobów online. Zajrzałbym do AUP (Agile Unified Process), który zawiera TDD (Test Driven Development). Może to być niezwykle przydatne podczas budowania / zarządzania dużymi skalowalnymi systemami.

Nie ma metodologii „jeden rozmiar dla wszystkich” i jest to główny powód ogromnej liczby różnych podejść. Chciałbym zacząć myśleć o tym, gdzie według ciebie są wąskie gardła w procesie rozwoju, a następnie spróbować zastosować nową metodologię, aby to rozwiązać.

Na przykład, czy często nie dotrzymujesz terminów? Czy nowe funkcje wprowadzają dużą liczbę błędów? Czy nowe wymagania powodują znaczną przebudowę? Czy firma wymaga przedstawienia regularnych systemów roboczych? Sprawdź: zwinne , iteracyjne i zwinne wprowadzenie .