![]() |
![]() |
![]()
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: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
Fakt, nie zauważyłem, że totalnie pominęliśmy w rozmowie kwestię dokumentacji technicznej. Mój błąd. Pomińmy więc ten temat.
Specyfikacja wymagań powstaje jako jeden z pierwszych dokumentów projektowych na etapie podpisywania papierów, choć różnie to bywa w różnych firmach. Często ustalenie jej kształtu odbywa się na zasadzie negocjacji z klientem, tzn. najpierw zbiera się wymagania ogólne, następnie w porozumieniu z analitykami lub/i team leaderami dobiera odpowiednie narzędzia, planuje prace i odsyła się taki dokument klientowi do akceptacji. Klient nanosi swoje uwagi i czynność powtarza się do uzyskania akceptacji. Na tym etapie, pisząc o wdrożeniu od zera, robimy często wycenę poszczególnych elementów najczęściej sklepu internetowego, mamy rozpisanych większość czynności do wdrożenia, ale jeszcze bez konkretów, tj. często pracuje się bez makiet, z częściowym projektem graficznym lub bez itd.. Celem tego jest akceptacja wyceny czasowej prac, a zatem na jej podstawie zaplanowanie czynności do wykonania i uzyskanie wstępnej informacji o kosztach. Po akceptacji wyceny jest etap wdrożenia. Jeśli jest już wyznaczony zespół który będzie pracował nad projektem i wiadomo ile to powinno potrwać, następuje rozdzielenie zadań. Dopiero w tym momencie powstają konkretne zadania w systemie ticketowym na podstawie których można implementować. Najczęściej sporządza je klient lub ktoś z nim skomunikowany np. product owner, opisując słownie to, co należy konkretnie wdrożyć wg jego wizji. Powstają z tego user stories z mniej lub bardziej konkretnymi wymaganiami. Jeśli coś jest niejasne, to uruchamiamy serię pytań i czekamy na odpowiedzi. Ale i tutaj nie dysponujemy żadnymi diagramami, jest jedynie opis słowny, czasami jakieś screeny. Wszystko było by fajnie gdyby to jakoś ujednolicić, np. nakłonić ownera do korzystania z narzędzi BPMN, żeby wymodelował procesy biznesowe po swojej stronie i żeby było widać, jak na co dzień ludzie w jego firmie będą korzystać z systemu, który dopiero powstaje. //edit Do specyfikacji wymagań należałoby też dodać wymagania niefunkcjonalne, które pominęliśmy, czyli np. - konieczność skonfigurowania certyfikatu SSL - obowiązek wdrożenia zabezpieczeń aplikacji na konkretnym poziomie - wymagania sprzętowe - wymóg zamieszczenia informacji o ciasteczkach i ochronie danych osobowych, akceptacji regulaminu itd. - konieczność testowania oprogramowania - dostosowania treści regulaminów do prawodawstwa określonego kraju etc. Ten post edytował darko 18.12.2015, 17:00:51 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 14.10.2025 - 19:06 |