![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 77 Pomógł: 0 Dołączył: 4.02.2014 Ostrzeżenie: (20%) ![]() ![]() |
Cześć, w swojej karierze programisty zauważyłem pewne dość popularne zjawisko, które według mnie nie koniecznie jest dobre, chodzi o sposób zabierania się do tworzenia i planowanie projektów.
Główni programiści lub menadżerowie projektów, tworzą jakieś ogólne opisy funkcjonalności na 2-3 strony w zależności od złożenia projektu i to jest wszystko co dostaję jako wiedzę o projekcie, na której mam bazować ( Jeszcze widoki psd, ale to oddzielna kwestia ). Zaczynając pracę nad projektem posiłkując się takim dokumentem w momencie kiedy zaczynam tworzyć daną funkcjonalność za każdym razem muszę dopytywać jak dokładnie ma działać i wyglądać, bo jej opis jest zbyt ogólny. Bardzo często widoki (psd) nie uwzględniają wszystkich potrzebnych funkcjonalności, o których wiadomo jest od początku, lub byłoby wiadomo gdyby bardziej szczegółowo projekt został obmyślony. Mam wrażenie jakby to był jakiś standard w pracy w zawodzie programisty i, że właśnie tak powinno się pracować. Jakieś takie spontaniczne tworzenie aplikacji i dokładniejsze planowanie poszczególnych funkcjonalności w trakcie ich tworzenia. Porównać to można do budowania domu, bez jego projektu, bezwiednego i nieprzemyślanego wcześniej zabierania się za każdy następny etap budowy (nie chciałbym w takim domu mieszkać ). Nie wiem z czego to wynika, czy to jest kwestia lenistwa menadżerów projektów i głównych programistów, natłoku zadań, podejścia, czy jeszcze czegoś innego. Według mnie przed w ogóle rozpoczęciem pisania jakiegokolwiek kodu i tworzenia widoków psd, aplikacja powinna być rozpisana tak szczegółowo jak to tylko możliwe, dzięki czemu w czasie trwania prac nie ma zaskoczeń, przestojów, zbędnego zastanawiania się za co następne się brać i jak to wykonać, bo wszystko jest rozpisane, a pracę idą płynniej, efektywniej, sam kod może być bardziej uporządkowany i przemyślany. Uważam, że porządna specyfikacja zawiera w sobie takie elementy jak: - wypisane wszystkie podstrony ( wszystkie adresy url) - wszystkie formularze odpowiedzialne za wprowadzanie i edycję danych w poszczególnych funkcjonalnościach wraz z wszystkimi polami, walidacją i przyciskami - wszystkie dane na poszczególnych podstronach jakie mają zostać wyświetlone ( index rekordów, show rekordu w zależności czy mają istnieć) - wszystkie formularze odpowiedzialne za usuwanie danych, pojedyncze lub mnogie, lub takie i takie - najlepiej wszystkie akcje, które użytkownik może wykonać tj. get, post itp. - studium przypadku poszczególnych akcji, żeby wychwycić możliwe błędy lub problemy. - jeśli to mozliwe to zaplanowanie bazy danych ze wszystkimi polami, kluczami i referencjami Chciałbym poznać Wasze zdanie na ten temat i dowiedzieć się ilu jest ludzi, którzy w jakimś stopniu podzielają moje zdanie. Może dodalibyście coś do tej listy? Sądzę, że żeby napisać optymalną i efektywnie funkcjonującą aplikację, szczegółowe jej obmyślenie jest nieodzowne. Detale uważam za całkowicie istotne, bo to one zbierają się na całokształt. Wątpię, żeby google lub inne marki w dziedzinie aplikacji www, podchodziły w sposób spontaniczny do tworzenia swoich projektów. |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 77 Pomógł: 0 Dołączył: 4.02.2014 Ostrzeżenie: (20%) ![]() ![]() |
Cytat Inna sprawa, ze PM czesto nie ogarniaja co sie do nich pisze w briefie/wstepnej specyfikacji potrzeb i potem sie robia dziwne problemy. Teraz np. mam takie wdrozenie, ze srednio raz w tygodniu musze udowadniac PM, ze cos bylo w specyfikacji i cytowac mu fragment... porazka jak dla mnie i juz widze jak sie musza programisci @$#@@! smile.gif To Ja jestem bardzo ciekaw jak ten brief jest napisany. Pewnie dlatego właśnie, że jest zbyt ogólnie nie wiadomo co trzeba zrobić. Pracowałem nad projektem, który gdyby był dobrze zaplanowany, byłby napisany 2 razy szybciej, bo poprawki wynikają z tego, że programista nie wie do końca jak ma wyglądać dana funkcjonalność pisze tak jak mu się wydaje, a później trzeba poprawiać 5 razy, bo za każdym razem jest coś nie tak, a wystarczyłoby siąść uzgodnić dokładnie co jak ma się zachowywać i dlaczego i problem z głowy. Tylko jak się nie ma bezpośredniego kontaktu z klientem, a kogoś nad sobą, to ten ktoś mówi 5 razy, że tak będzie okej, a później 5 razy trzeba zmieniać. Robiłem cmsa, przy którym za nim cokolwiek zacząłem robić rozpisałem wszystko co można mega dokładnie. Klient to dostał i wszystko dokładnie wiedział co będzie miał. Zrealizowałem projekt i praktycznie zeeero poprawek. Można? Można. Tylko jak się woli babrać, niż porządnie efektwnie pracować to później tak jest, że prace się przeciagają, a apka jest średnia. Widzę, że nikt mojego zdania nie podziela, ostra akcja (IMG:style_emoticons/default/tongue.gif) Ten post edytował Omenomn 4.02.2016, 18:28:41 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 5.10.2025 - 16:08 |