Jak oszacować zadanie programistyczne, jeśli nie masz w nim doświadczenia [zamknięte]


97

Mam trudności z pytaniem kierownictwa o oszacowanie zadań programistycznych korzystających z kontrolek innych firm, z którymi nie mam wcześniejszego doświadczenia.

Zdecydowanie rozumiem, dlaczego chcieliby oszacować dane, ale czuję, że jakiekolwiek oszacowanie, które podam, będzie albo a) za krótkie i sprawi, że będę wyglądać źle lub b) za długie i sprawi, że będę wyglądać źle.

Jakich szacunków lub odpowiedzi mógłbym udzielić kierownictwu, aby zdjąć ich z moich pleców, abym mógł dalej wykonywać swoją pracę!


To pytanie wydaje się być nie na temat, ponieważ dotyczy szacowania czasu, nie ma nic o programowaniu ..
Ajay S

Odpowiedzi:


91

Najlepszą odpowiedzią, jaką możesz dać, jest poproszenie o czas na wykonanie szybkiego prototypu, aby umożliwić dokładniejsze oszacowanie. Bez pewnego doświadczenia z narzędzia lub problemu, każdy szacunek dajesz jest w zasadzie bez znaczenia.

Nawiasem mówiąc, bardzo rzadko występuje problem z podaniem zbyt długich szacunków. Pojawiają się nieprzewidziane problemy, zmieniają się priorytety, a wymagania są „aktualizowane”. Nawet jeśli nie wykorzystasz całego czasu, o który prosiłeś, będziesz miał więcej czasu na testowanie lub możesz wydać „wcześniej”.

Zawsze byłem zbyt optymistyczny w moich szacunkach i może to spowodować wiele stresu w twoim życiu, zwłaszcza gdy jesteś młodym programistą bez doświadczenia i pewności siebie, by mówić szefom niewygodne prawdy.


+1 jeśli zaczynasz od zera, potrzebujesz trochę czasu z produktem innej firmy, aby przynajmniej go obejść.
Brett McCann

Popełniłbym również błąd po stronie nieco wyższego oszacowania czasu po wykonaniu prototypu, ponieważ kontrolki innych firm zwykle dodają nieoczekiwany czas rozwoju, dopóki nie poczujesz się z nimi naprawdę komfortowo.
Crescent Fresh

8
Uważaj na te prototypy. Mają własne problemy z nierealistycznymi oczekiwaniami, jak opisano w tym doskonałym artykule: joelonsoftware.com/articles/fog0000000356.html
JohnFx

„bezsensowne” nie powstrzyma cię oczywiście przed poproszeniem o oszacowanie na miejscu :(
annakata

2
Moje doświadczenie z szacowaniem, które wydaje się rozsądne, jest takie, że zarządzanie zagrożeniem zdecyduje, że jest ono zbyt długie i wymaga niższej. Nie ma to sensu, ale zdarza się to cały czas. Zdarza się to mnie i współpracownikom, na tym stanowisku iw poprzednich miejscach pracy. Z mojego doświadczenia wynika, że ​​warto poprzedzić i zamknąć oszacowanie z zastrzeżeniem, że wymagania, których potrzebujesz, nie są dostępne lub że nie możesz znać wszystkich zmiennych. Jeśli chodzi o prototypy, nigdy nie wspominam, że robię prototyp. Zbyt często prototypy są pierwszą wersją. Powiedziawszy to, na pewno mogą być przydatne.
JMD

39

Zdradzę ci sekret. Nawet jeśli byłeś ekspertem w tej technologii, Twoje szacunki mogą być bardzo niedokładne. Taka jest natura bestii, gdy robi coś, co jest z natury zadaniem badawczo-rozwojowym. Niestety kierownictwo często próbuje zastosować model produkcji i żąda dokładnych szacunków. Aby zilustrować mój punkt widzenia, rozważ trudność w dokładnym oszacowaniu następujących dwóch wysiłków:

A) Wyprodukuj kolejne parasole 11K, które są dokładnie takie same jak 2K, które wypuściłeś w zeszłym miesiącu. B) Zaprojektuj nowy rodzaj parasola i zbuduj pierwszy.

Rozwój oprogramowania to B, ale proszą o oszacowanie przy założeniu, że A.

Najlepsze, co możesz zrobić, to rozbić zadanie na najmniejsze możliwe części (nie więcej niż pół dnia każdy), a następnie potroić ostateczną liczbę, którą wymyślisz. (Metoda Spolsky'ego)

Alternatywnie, Steve McConnell ma całą książkę (prawdopodobnie kilka) na temat tego aspektu inżynierii oprogramowania. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351


2
+1 - „Niestety kierownictwo często próbuje zastosować model produkcji i żąda dokładnych szacunków”
NLV,

5
Żądanie dokładnych szacunków nie jest nierozsądne. Założę się, że chcą też dokładnego kodu. Dobre szacowanie powinno być celem każdego profesjonalisty. Potrzeba praktyki i przeglądu niepowodzeń, aby stać się lepszym, tak jak przy tworzeniu kodu.
Jim Blizard,

31

Steve McConnell (i inni) mówi o stożku niepewności . Zasadniczo podajesz oszacowanie, które wygląda mniej więcej tak:

Prace potrwają od 3 do 9 tygodni, przy czym najbardziej prawdopodobne są 4 tygodnie.

W miarę postępów projektu możesz zawęzić swoje oszacowanie. Gdy wykonujesz więcej pracy i lepiej rozumiesz wymagany wysiłek, możesz zawęzić oszacowanie, aby było dokładniejsze.

Dla mnie to zadziałało, ale może wymagać pewnego wysiłku, aby inni interesariusze projektu zrozumieli proces.


2
Szczególnie podoba mi się jego rada „Nigdy nie podawaj szacunków punktowych”. Nie można błędnie zinterpretować terminu „od 3 do 9 tygodni” jako gwarancji, tak jak w przypadku zwykłego stwierdzenia „4 tygodnie”.
Brian Laframboise

1
Ale często jesteśmy badani pod kątem udoskonalenia (zmiany ich perspektywy) oszacowania. Pytają tylko „dlaczego przedłużasz harmonogram?”.
NLV

Jak powiedziałem, „... może wymagać pewnego wysiłku, aby inni
interesariusze

13

Możesz rozważyć podanie zarówno szacunku, jak i poziomu ufności, tj. 50/50, że zajmie to 3-6 miesięcy lub 6-9 miesięcy lub 75% szansy na wykonanie w ciągu 9 miesięcy i 90%, że będziesz zrobione w ciągu roku.

Inną rzeczą, którą warto rozważyć, jest podejście „ mądrości tłumów ”. Przejdź się po okolicy i zapytaj 25–50 osób, jak długo według nich to zajmie i uśrednij ich szacunki. Planning Poker Mike'a Cohna jest, jak sądzę, bardzo podobny do tego, choć trudny do zaplanowania z jednym tylko deweloperem.


10

Podziel swoje oszacowanie na:

  • Znane znane ; jak długo zajmie zrobienie tego, co umiesz. Powinieneś być w stanie podać to oszacowanie z dużym stopniem pewności.
  • Znane niewiadome ; jak myślisz, ile czasu zajmie zrobienie tego, czego nie wiesz, jak to zrobić. Możesz użyć metody takiej jak dacracot, aby podać różne poziomy zaufania do tego oszacowania.
  • Nieznane niewiadome ; to jest czarna dziura w czasie rzeczywistym. To są rzeczy, które odrastają w najbardziej nieodpowiednich momentach i gryzą cię w tyłek. Podaj zakres oszacowania wraz z uzasadnieniem na podstawie przewidywanego ryzyka.

Zaproponuj dostosowanie oszacowania i niektórych kamieni milowych po drodze. Wszelkie nieznane niewiadome staną się znanymi niewiadomymi, znane niewiadome powinny stać się znane jako znane w miarę zdobywania doświadczenia, a oszacowanie liczby znanych znanych wam informacji może być korygowane na podstawie dotychczasowych postępów. Możesz dokonać wstępnego oszacowania, a następnie ponownie oszacować, gdy wykonasz około 25%, potem ponownie przy 50%, a następnie ponownie przy 85%. Przy każdym kamieniu milowym twoje oszacowanie powinno zacząć zbieżne z faktycznym czasem trwania zadań.


7
Donald Rumsfeld
wysyła do Stackoverflow

Zamknij;) Nauczyłem się tego w środowisku DoD. Lubiliśmy myśleć, że Remik (jak go nazywaliśmy) nauczył się tego od nas.
Patrick Cuff

Zgadzam się z potrzebą ponownego oszacowania ... bardzo ważne jest w takim przypadku, od samego początku, uświadomienie kierownictwu możliwości odchyleń od wstępnego oszacowania oraz potrzeby ponownego oszacowania.
Kwang Mark Eleven

8

Używam określonego systemu etykietowania dla moich szacunków ... klasa A, klasa B i klasa C.

Oszacowanie klasy C jest pierwszym, jakie otrzymują. Jest otwarcie określane jako plus minus 50% z powodu niewiadomych. Jeśli chcą, żebym nadal dawał im klasę B, potrzebuję pieniędzy na badania.

Klasa B to plus lub minus 25%. Czasami to wystarczy i dają mi pieniądze na budowę. Jeśli nie, mniej pieniędzy i więcej badań.

Klasa A to plus / minus 10%, ostateczna i idź lub nie idź. Jeśli tak jest i zbyt daleko odbiegam od szacunku, to przyznaję się często i wcześnie.


8

Myślę, że jeśli usuniesz wyrażenie „które używają kontroli innych firm, z którymi nie mam wcześniej doświadczenia”, możesz lepiej opisać swój większy problem.

Jeśli „Agile” czegoś nas nauczył, to dlatego, że jeśli kierownictwo oczekuje, że będziesz na bieżąco oceniać projekty w ten sposób, i będziesz „źle wyglądać”, jeśli powiesz, że nie można tego zapewnić, ponieważ nie masz wystarczająco dużo informacji, jesteś na autostradzie do FAIL.

Największym problemem będą te, nad którymi nie masz kontroli i których jeszcze nie zidentyfikowałeś. Jak często oglądałeś się za siebie i mówiłeś sobie: „Cóż, trafiłem w moje oszacowanie tuż przy przycisku - za trzecim podejściem, po tym, jak się zorientowałem… i potrzebuję wersji… i że dba będzie włączona urlop na tydzień i że Kierownik Projektu będzie mnie potrzebował przez… tydzień i że moja żona była w ciąży i… ”.

Bardzo bym się starał powiedzieć: „Potrafię zidentyfikować krytyczne czynniki ryzyka i wymyślić listę kontrolną wyników, aby przetestować je w ciągu xx dni. W tym momencie dam ci kolejny przyrostowy szacunek”.

Byłoby naprawdę miło, gdybyś mógł zasugerować, że powinni: „Nalegaj, żebym nigdy nie próbował przedstawiać Ci wiarygodnych szacunków tego typu w przyszłości. Zwolnij mnie, jeśli spróbuję”.

(Zawyżone, ale tylko nieznacznie).


7

Nawet nie próbuj szacować. W żaden sposób Twoje oszacowanie nie będzie prawidłowe. W końcu to tylko szacunek.

Zamiast tego zalecałbym podzielenie funkcji na małe części (nie więcej niż, powiedzmy, 1-2 dni) i próbę dostarczenia tych części jako działającego, kompletnego, testowalnego i wartościowego kodu klientowi / menedżerowi. W ten sposób zobaczy na własne oczy Twoje codzienne postępy. Oznacza to również, że może on w rzeczywistości zdecydować o zatrzymaniu rozwoju, gdy jest już usatysfakcjonowany i uznać go za zakończony, nawet jeśli nie osiągnął wszystkich celów.

Zapoznaj się z praktykami zwinnymi „Planowanie wydania” i „Planowanie iteracji”, aby uzyskać bardziej szczegółowe informacje na temat tego podejścia.


5

Pamiętaj, że jeśli poprosisz o szersze oszacowanie czasu, ale zrobisz to w terminie, wygląda to znacznie lepiej niż niedoszacowanie i konieczność proszenia o przedłużenie.

Spróbowałbym wyszydzić prototyp, abyś miał lepsze pojęcie o czasie, jaki to zajmie. Bądź uczciwy wobec swojego kierownictwa, aby mógł on przeznaczyć na nieoczekiwane opóźnienia w krzywej uczenia się.

EDYCJA: Możesz również sprawdzić, czy możesz uzyskać bardziej „iteracyjny” termin. W „Myśleniu i uczeniu się pragmatycznym” Andy Hunt podkreśla, że ​​ludzie są ekspertami projektowymi bliżej końca projektu i mają najmniejszą wiedzę na samym początku. Nie ma sensu robić całego projektu i oszacować czas na samym początku, kiedy wszyscy mają najmniejszą wiedzę o projekcie. Jeśli „iterujesz” terminy i rozwiążesz problem w kawałkach, odniesiesz większy sukces.


5

Wiele trafnych oszacowań to wiedza o sobie. Jeśli napisałeś dużo kodu, jeśli musiałeś nauczyć się wielu interfejsów API, zaczynasz wyczuwać takie pytania, jak:

  • Ile czasu zajmuje mi nauka nowego interfejsu API?
  • Ile czasu zajmuje mi nauka nowego języka?
  • Ile czasu zajmuje mi nauczenie się nowego zestawu narzędzi (kompilator / linker / IDE)?
  • Ile czasu zajmuje mi realizacja typowego zadania?
  • Ile czasu zajmuje mi przetestowanie mojej pracy?
  • Ile czasu zajmuje mi wdrożenie mojej pracy?

W trakcie tego powinieneś mieć poczucie takich rzeczy, jak:

  • Ile typowych błędów tworzysz i jak są one podzielone na kategorie (tj. Łatwe, trudne, niemożliwe)
  • Ile komplikacji zostało wprowadzonych (tj. Potrzeba refaktoryzacji z powodu braku interfejsu API innej firmy lub błędnego interfejsu API; potrzeba przeprojektowania z powodu niezrozumienia możliwości; niestandardowe narzędzia / procesy kompilacji)
  • Ile czasu jest tracone z powodu przerw / problemów zewnętrznych

Na podstawie tych wszystkich rzeczy będziesz w stanie zrozumieć, jak długo coś zajmie i będziesz w stanie sformułować swoje założenia („Zakładając, że API jest rozsądne ...”) nawet w obliczu żałośnie niekompletnych informacji.


5

Oszacuj, ile czasu potrzebujesz, aby nauczyć się wystarczająco dużo, aby dokonać lepszego oszacowania, na przykład: „Nie wiem: nigdy wcześniej z tym nie pracowałem. Prawdopodobnie zajmie mi wstawienie tutaj Twojego oszacowania , aby dowiedzieć się, co musisz się o tym dowiedzieć, o czym będę musiał wiedzieć, zanim będę mógł oszacować, jak wykorzystać to do ukończenia projektu ”.


3

Podczas programowania zawsze brałem to, co naprawdę sądziłem, że zajmie mi to i mnożę to przez 3, aby oszacować. Jeśli myślę, że mogę wykonać pracę w 1 tydzień, mówię klientowi, że zajmie to 3 - jeśli myślę, że to naprawdę zajmie mi 3 tygodnie, mówię klientowi 9 tygodni.

Robiąc to, wyznaczyłem sobie postawę „pod obietnicą, z nadwyżką” - jeśli uda Ci się to zrobić, Twoje życie będzie znacznie lepsze, a Twoi klienci będą niezwykle szczęśliwi.

W twoim przypadku z pewnością będziesz chciał uzyskać przynajmniej CZĘŚĆ zrozumienia tego, w co się nurkujesz, zanim przedstawisz oszacowanie. Może nawet musisz oszacować, ile czasu zajmie przedstawienie oszacowania. Pomnóż przez 3, aby klienci byli zadowoleni.


3

Podziel to na rzeczy, z którymi masz pewne doświadczenie. Akt rozdrobnienia tego da ci lepsze pojęcie o tym, co wiesz, a czego nie.

Gdy elementy będą wystarczająco małe, aby można je było postrzegać jako pojedyncze, zdefiniowane zadania, kilka z nich będzie całkowicie niemożliwych do oszacowania. Dla nich najpierw wykonaj prototyp lub po prostu zostaw sobie rozsądną ilość czasu, w zależności od rozmiaru elementu. Jeśli stwierdzisz, że masz nieocenione kawałki większe niż 2-4 tygodnie pracy, wróć najpierw do ich rozdrabniania.

W końcu przejdziesz do kilku bardzo dziwnych rozwiązań technologicznych (które Twoim zdaniem powinny działać, ale nie wiesz na pewno) i mnóstwo pracy do wykonania, aby je poprzeć. Będzie kilka brakujących fragmentów projektu, dla których najlepiej wybrać dobrze znaną bibliotekę lub bardzo prosty algorytm dla początkowej wersji.

Jeśli nie możesz podzielić zadań, powinieneś zatrudnić kogoś z wystarczającym doświadczeniem, który to potrafi (ponieważ twój brak doświadczenia będzie cię prześladować również w inny sposób). Jeśli nie możesz kogoś zatrudnić, powinieneś po prostu targować się na losowo długi okres (od 6 miesięcy do 2 lat) i udać się prosto do niechlujnego prototypu (dopóki nie zdobędziesz wystarczającego doświadczenia, aby wiedzieć, co jest dobre, a co źle). Ale jeśli zaczniesz się tym wymachiwać, ważne jest, aby nie oszukiwać się i nie myśleć, że robisz to we właściwy „sposób”. Prototypy miały zostać wyrzucone. Miejmy nadzieję, że po zakończeniu odliczania prototypu będziesz gotowy do zbudowania go naprawdę.

Paweł.


2

Po prostu odgadujesz liczbę zewnętrzną i natychmiast przystępujesz do oceny, dając im do zrozumienia, że ​​przyszłe informacje mogą wpłynąć na Twoje szacunki, ale będziesz je aktualizować.

Oceniając, informuj ich na bieżąco - albo za pośrednictwem dokumentu publikowanego w sieci, albo cotygodniowych aktualizacji, ale zawsze podawaj zaktualizowaną „szacowaną datę zakończenia” i powody (jeśli istnieją) rozszerzenia.

Większość menedżerów powinna to zrozumieć - pytając o daty zakończenia, tak naprawdę mówią „daj nam wyobrażenie, jak możemy zaplanować nasz harmonogram” i „nie trwać wiecznie”.

Jeśli w końcu przedłużasz więcej niż raz lub dwa razy, ponownie oceń cały swój harmonogram w oparciu o nową wiedzę, której nie potrafisz oszacować.


+1 Informuj swojego menedżera o swoich postępach. Dobry menedżer powinien zachować się poinformowana oczywiście ;-)
RB.

2

Dodam do tego, co powiedział RB, kiedy znajdę się w takiej sytuacji, oszacuję, ile czasu zajmie użycie narzędzi, które znam, a następnie podwoję to oszacowanie, aby zbudować jakąś krzywą uczenia się.

Ważną częścią jest zakomunikowanie kierownictwu, że szacunek jest tylko domysłem , jeśli domagają się dokładniejszego oszacowania lub jeśli spróbują - drogi Boże - sprzedać Ci limit czasu (na pewno zbudowanie statku kosmicznego zajmie Ci tylko 2 dni Enterprise, jesteś dobry, że jesteś) TRZYMAJ SIĘ DO SWOICH PISTOLETÓW , nie narażaj szacunków ani tego, że są niewiarygodne

Jeśli kierownictwo ma pierwszeństwo przed Tobą i harmonogramem zadania, np. „Cóż, trzeba to zrobić w ciągu 2 dni”, ponownie daj im znać, że to ich oszacowanie, które jest dokładnie tak samo wiarygodne jak Twoje.

Zapisz to wszystko na piśmie.


2

W swojej pracy zajmuję się estymacją i jest to prawdziwe wyzwanie. Jednym z moich największych wyzwań jest oszacowanie, ile czasu zajmie wykonanie zadania innemu programistowi bez wiedzy o tym, jak wykwalifikowany będzie ten programista.

Chociaż początkowo możesz odnieść sukces dzięki metodzie „poniżej obietnicy, nadwyżki”, z czasem okaże się, że zostaniesz przelicytowany przez inne osoby, które postępują zgodnie ze szkołą myślenia „powyżej obietnicy, poniżej dostarczenia”. Brak celności powróci i ugryzie cię tak czy inaczej. Dokładność jest bardzo związana z doświadczeniem i ogranicza liczbę niewiadomych za pomocą technologii.

Jedną rzeczą, którą chciałbym zasugerować, jest zorientowanie się, jakiego rodzaju budżet będzie dotyczył twój szacunek. Jeśli masz mały budżet, nie zwariuj na punkcie nieznanej technologii i trzymaj się tego, co wiesz. Jeśli Twój budżet jest trochę bardziej elastyczny, możesz pozwolić sobie na trochę poeksperymentowania.

Pamiętaj również, że będą pewne zadania, w których wszystko, co możesz zapewnić, to zgadywanie dzikich osłów (WAG). W tym celu należy ustawić minimalny czas do oszacowania i wyjaśnić, że nie wiesz, jaki jest maksymalny. Często tego rodzaju szacunki są wystarczającym powodem, aby kierownictwo wyeliminowało pewne funkcje / wymagania.



1

Wszystkie powyższe odpowiedzi obejmowały prawie wszystko, co dotyczy samego oszacowania.

Jedną rzeczą, którą chciałbym podkreślić, jest śledzenie swoich szacunków (mały arkusz kalkulacyjny Excel a la Joel lub nawet dokument Notatnika, jeśli jest to bardzo proste) i na koniec każdego dnia aktualizuj je do najdokładniejszych danych, które możesz teraz podać . Nawet jeśli nie musisz przekazywać tego z powrotem swoim przełożonym, utrzymywanie tego na bieżąco daje lepsze wyobrażenie o postępie rzeczy, a co ważniejsze, dobrze wyczujesz, dlaczego szacunki zmieniają się w miarę postępu prac .

Dzięki temu będziesz lepiej oceniać w przyszłości, zarówno dla tej konkretnej technologii, jak i innych, których wcześniej nie używałeś, po prostu dlatego, że wymaga to na pewnym poziomie zauważenia, kiedy Twoje oczekiwania zmieniają się w regularnych odstępach czasu, i ustalenia, dlaczego tak się stało. .


1

Szacowanie, ile czasu to zajmie, jest częścią Twojej pracy. O ile jest to szacunek, a nie termin, nie powinieneś się martwić. Nie ma nikogo lepiej przygotowanego do oszacowania niż osoba, która ma napisać kod. Jeśli nie możesz przedstawić dobrego oszacowania, musisz uświadomić kierownictwu ryzyko związane z twoim złym oszacowaniem, aby mogli ponownie rozważyć, czy warto podjąć ryzyko programowania w odniesieniu do tych nieznanych kontroli zewnętrznych.


1

To bardzo powszechna sytuacja: konieczność zmierzenia się z nieznanym. Użytecznym sposobem rozwiązania tego problemu jest uświadomienie sobie, że oprócz rzeczywistych zadań programistycznych trzeba się trochę nauczyć - a kierownictwo powinno być tego świadome.

Kiedy jesteś w takiej sytuacji, projekt nagle staje się projektem badawczo-rozwojowym i dłuższy czas niż zwykle nie sprawi, że będziesz wyglądać źle, ponieważ uczysz się i produkujesz programy. Nie wiem, jak szybko się uczysz ani jakie zasoby masz do radzenia sobie z ewentualnymi problemami (przepełnienie stosu to jedna z dostępnych opcji).

Powiedziałbym, że powinieneś oszacować jak zwykle, a następnie pomnożyć albo przez 1,5 (jeśli szybko się uczysz i masz dostęp do zasobów, aby rozwiązać swoje pytania) lub przez 2,5, jeśli jesteś przeciętnym uczniem i polegasz tylko na sobie.

Mam nadzieję, że to pomoże!


0

Z całych sił postaraj się podzielić zadanie na łatwe do opanowania części. Przy odrobinie szczęścia istnieją określone zadania związane z zaangażowanym komponentem strony trzeciej i inne, które są mniej powiązane (a zatem łatwiejsze do oszacowania). Przekaż kierownictwu podzielone szacunki i wskaż, gdzie znajdują się najbardziej niepewne szacunki.

W pełni zgadzam się z tym, kto zasugerował zabawę i prototypowanie niektórych. Ustaw ustalony przedział czasowy dla czynności prototypowania. („Potrzebuję najpierw dwóch dni, aby poprawić tę część mojego oszacowania”).


0

Czy możesz podać zakres? 40-60 godzin, coś takiego?

Im mniejsze są zadania, tym jest to trudniejsze, jeśli możesz je pogrupować, będziesz miał trochę więcej „pomyłki”, ponieważ błędy mogą zrównoważyć się pod koniec projektu.

Spójrz na każdą dziedzinę, z którą masz doświadczenie i wykorzystaj jako przewodnik. „Ostatnim razem, gdy trzeba było stworzyć funkcję zmieniającą bazę danych, zajęło mi X”. Powodzenia.

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.