Mnie pomogła jeszcze analiza baz danych , mapowanie struktur z interfejsem użytkownika. Przede wszystkim masa testów i zapisywanie rezultatów. Dobry programista do debugu, a nawet wspólne analizowanie kodu źródłowego. Zgłoszenia użytkownika typu BUG i CR'y również bardzo dużo uczą i dzięki nim poznajemy system.
5 ปีที่แล้ว +3
Dzięki za rady. Są one przydatne nawet programiście/tech leadowi który musi wdrożyć się w legacy system. Zazwyczaj system bez niczego poza kodem... ;) Pozdrawiam.
Ok, filmik jest bardziej o tym skąd brać poszczególne informacje. W pełni się z tym zgadzam. Jednak w nawiązaniu do tytułu filmiku, mam nadal pytanie: jak to ogarnąć? My sobie spiszemy. Może nawet pogadamy z interesariuszami (w tym z deweloperami i testerami). Pytanie: co dalej? Czy taki dokument powinien być weryfikowany przez zamawiającego i przez niego zaakceptowany? Czy gdy przyjdzie niezasadny błąd, tester może go odrzucić powołując się na tą dokumentację stworzoną po fakcie?
Mamy różne modele pracy - dla siebie, dla 1 klienta zamawiającego, dla wielu klientów (produkt). Kiedy robisz dla siebie, to po prostu Tobie się przyda dokumentacja. Z klientami, rzecz jasna, przyda się baza do porównań tego, jak miało być z tym, co jest. Zapytałabym jakie były warunki odbioru, co było w umowie. Jeśli system działa dłuższy czas, to pewnie został "odebrany". Tutaj bym porozmawiała ze sprzedażą, osobami, które zajmowały się odbiorem i warunkami umowy, prawnikami. Jedna rzecz to kontrowersje, kiedy odkrywamy (i my i klienci) jak to naprawdę działa i może nie tak, jak działać powinno. Inna kwestia to kto ponosi za to odpowiedzialność i koszty w przypadku chęci zmiany.
Trafiłem na film 4 lata po publikacji. Czy zrobienie kroków, o których opowiadasz jest możliwe w projekcie składającym się z miliona linii kodu, a jego baz danych zawiera 400 tabel? Ewentualnie proszę powiedz mi, czy przy takich projektach pracują analitycy i wszystko odbywa się w sposób książkowy? Nasze oprogramowaniem działa w określanej branży i my developerzy jesteśmy jednocześnie analitykami, bardzo ciężko mi wyobrazić sobie, że istniałby osoba, która byłaby w stanie od A do Z nakreślać nam problem, ponieważ jego rozwiązanie niejednokrotnie polega na zebraniu informacji, a następnie przekazywaniu prototypów klientom i ewentualnym rozwijaniu danej funkcjonalności
Mnie pomogła jeszcze analiza baz danych , mapowanie struktur z interfejsem użytkownika. Przede wszystkim masa testów i zapisywanie rezultatów. Dobry programista do debugu, a nawet wspólne analizowanie kodu źródłowego. Zgłoszenia użytkownika typu BUG i CR'y również bardzo dużo uczą i dzięki nim poznajemy system.
Dzięki za rady. Są one przydatne nawet programiście/tech leadowi który musi wdrożyć się w legacy system. Zazwyczaj system bez niczego poza kodem... ;) Pozdrawiam.
Adrian Piętka o proszę :) to super - cieszę się, że nie-analitycy też mogą w tym coś dla siebie zobaczyć 🙂
Ok, filmik jest bardziej o tym skąd brać poszczególne informacje. W pełni się z tym zgadzam.
Jednak w nawiązaniu do tytułu filmiku, mam nadal pytanie: jak to ogarnąć? My sobie spiszemy. Może nawet pogadamy z interesariuszami (w tym z deweloperami i testerami). Pytanie: co dalej? Czy taki dokument powinien być weryfikowany przez zamawiającego i przez niego zaakceptowany? Czy gdy przyjdzie niezasadny błąd, tester może go odrzucić powołując się na tą dokumentację stworzoną po fakcie?
Mamy różne modele pracy - dla siebie, dla 1 klienta zamawiającego, dla wielu klientów (produkt). Kiedy robisz dla siebie, to po prostu Tobie się przyda dokumentacja. Z klientami, rzecz jasna, przyda się baza do porównań tego, jak miało być z tym, co jest. Zapytałabym jakie były warunki odbioru, co było w umowie. Jeśli system działa dłuższy czas, to pewnie został "odebrany". Tutaj bym porozmawiała ze sprzedażą, osobami, które zajmowały się odbiorem i warunkami umowy, prawnikami. Jedna rzecz to kontrowersje, kiedy odkrywamy (i my i klienci) jak to naprawdę działa i może nie tak, jak działać powinno. Inna kwestia to kto ponosi za to odpowiedzialność i koszty w przypadku chęci zmiany.
Trafiłem na film 4 lata po publikacji. Czy zrobienie kroków, o których opowiadasz jest możliwe w projekcie składającym się z miliona linii kodu, a jego baz danych zawiera 400 tabel? Ewentualnie proszę powiedz mi, czy przy takich projektach pracują analitycy i wszystko odbywa się w sposób książkowy?
Nasze oprogramowaniem działa w określanej branży i my developerzy jesteśmy jednocześnie analitykami, bardzo ciężko mi wyobrazić sobie, że istniałby osoba, która byłaby w stanie od A do Z nakreślać nam problem, ponieważ jego rozwiązanie niejednokrotnie polega na zebraniu informacji, a następnie przekazywaniu prototypów klientom i ewentualnym rozwijaniu danej funkcjonalności
00:55 ja bym rozważył poszukanie innego projektu, stracisz nerwy i zdrowie