![]() |
![]() |
![]()
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%) ![]() ![]() |
nie sądzę, że każdy klient chce płacić byle najtaniej i na pewno są klienci z profesjonalnym podejściem, nie każdy musi mieć taką klientele jak Ty kayman,
Po za tym nieświadomość klienta nie przeszkadza w stworzeniu zaplanowanego projektu. Trzeba po prostu wiedzieć co od klienta wyciągnąć, żeby móc dokładnie zaplanować projekt i jak już mówiłem, wcale to się z ceną nie kłóci, bo czas pracy nad projektem, bardziej może się skrócić niż wydłużyć. Cytat Często koncepcje się zmieniają w trakcie trwania projektu. Oczywiście za każdym razem jak jest zmiana która znacząco ingeruje w projekt to jest ponownie wyceniana. Okej zmieniają się czasem koncepcje, ale to jest wymówka, żeby nie planować szczegółów, tylko uprawiać freestyle? Cytat Można spotkać też podejście "watefall" czyli mamy ogólny koncept. Dzielimy to na moduły. Najpierw jest dokładne dogadanie 1 części, programiści siadają i piszą to co już jest ustalone, a potem w trakcie uzgadniany jest kolejny etap/moduł. Ciekaw jestem jak taki ogólny concept chciałbyś wycenić i co kiedy nagle okazuje się, że ten concept wymaga o wiele więcej pracy, co wychodzi dopiero w trakcie i po wycenie projektu. Jest ktoś kto uważa, że jak najdokładniejsza specyfikacja jest potrzebna? Ten post edytował Omenomn 18.12.2015, 15:35:54 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 8.10.2025 - 09:22 |