Jak napisać projekt?, Planowanie, specyfikacja Opcje

[Omenomn]

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.

[kayman]

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.

projektowanie o którym piszesz podniosło by cenę aplikacji o (gdybam) 25-30% a przecież ma być tanio, szybko etc by klienta nie stracić

[Omenomn]

a Ja sądziłem, że porządnie ma być, ehhh :/. Wszyscy tak uważają, żeby robić buble, byle by tylko zarobić?
Po za tym, nie wiem co by tak bardzo podniosło cenę? Poświęcenie paru dni na szczegółowe rozplanowanie aplikacji? Bez przesady...
Jak na aplikację przewidziane są 2 miesiące pracy to poświęcenie 3 dni na szczegółowe rozplanowanie, nie ma szans, żeby podniosło cenę nawet o 10-15 %, a do tego dochodzi, że jest szybciej pisana, więc te 3 dni się zwracają i cena się nie zmienia. Więc podważam Twój argument kayman

Ten post edytował Omenomn 18.12.2015, 15:03:31

[kayman]

a Ja sądziłem, że porządnie ma być, ehhh :/.

porządnie to jest wtedy gdy firma/programista pisze coś dla siebie, lub klient jest świadom pewnych spraw -> często jednak jego świadomość się budzi po 60 poprawce u piątego wykonawcy bo nikt go do tej pory nie uświadomił że jak wszędzie - tanio, szybko i dobrze do kupy się nie lubią

btw. porządnie zaprojektowany interfejs użytkownika kosztuje dużo, projektant interfejsów to jeden z lepiej opłacanych zawodów w it

[Pyton_000]

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.

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ł.

Dzięki temu na bieżąco mamy świeżą dokumentację i pomysły oraz na bieżąco mamy kod, który jeśli jednak klient stwierdzi że nie o to chodziło łatwo jest zmienić.

Zaznaczam że wszystkie takie operacje są uzgadniane co do czasu, i kosztu.

[Omenomn]

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ć.

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?

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

[kayman]

ale to jest wymówka

wcale nie wymówka -> https://pl.wikipedia.org/wiki/Programowanie_zwinne

[Pyton_000]

@Omenomn dla tego mówisz klientowi że wg. ogólnej specki wycena to w widełkach XXXX-YYYY, a każde zmiany koncepcyjne podlegają renegocjacji.
To Ty ustalasz czy coś jesteście w stanie zrobić wg. ustalonego budżetu czy nie.

To nie mnie powinno interesować zmiana ceny tylko klienta. To klient klepie wycenę zmian. Jeśli się zgadza to robisz, a jak nie to nie.
Czas? Czas nie gra roli chyba że klient chciał na wczoraj, to wtedy liczy się dużo wyższe wyceny.

[Omenomn]

Nie rozumecie, okej programowanie zwinne spoko.
Ale zawsze na początku jest koncepcja, którą trzeba wyszczególnić, rozłożyc na czynniki pierwsze.
Ja nie twierdzę, że można aplikacja w sposób totalny przewidzieć od a-z i to zaplanować, bo tak nie jest.
Twierdzę natomiast, że każdą koncepcję należy rozkładać na czynniki pierwsze i planować, a kiedy ktoś zleca aplikacje to ma wizję jakaś konkretną i tą wizje należy rozłożyć na czynniki pierwsze i ją wykonać i z następną wizją zrobić to samo. Wtedy jest porządek, a aplikacja się nie rozsypie.
Programowanie zwinne bez rozkładania na czynniki pierwsze każdej iteracji sprawi, że oprogramowanie zamieni się w kupę koderskiego gruzu i w końcu runie.

Jest ktoś kto podziela moje zdanie, czy sami freestylowcy od bubli programistycznych?

Ten post edytował Omenomn 18.12.2015, 15:45:39

[Pyton_000]

Sam zacytowałes moją wypowiedź w której miałeś wytłumaczone programowanie zwinne. Tym samym jest to odpowiedź na twoje pytanie z postu.

[phpion]

@Omenomn:
Żyjesz w świecie utopii. Teoria mówi jedno, a praktyka pokazuje co innego. Czas to pieniądz, często nie ma czasu na "tracenie" go na tworzenie dokumentacji i pełnej specyfikacji systemu. W pracy zajmujemy się akurat pojedynczymi modułami, dostajemy konkretną funkcjonalność do wykonania i to robimy. Mimo, że są to mniejsze kroki niż cały projekt od 0 to też nie mamy czasu na przygotowanie się do zadania. Otrzymujemy czasem wręcz szczątkowe informacje i trzeba zacząć robić. W międzyczasie uściśla się wymagania, niektóre wywalające do góry nogami to co już zostało stworzone. Problem jest w określaniu terminów takich prac gdy do końca nie wiesz co i jak trzeba zrobić. Swego czasu kolega otrzymał do oszacowania (cytat!): "Zmiany na widoku użytkowników"... To już było kuriozum

a Ja sądziłem, że porządnie ma być, ehhh :/. Wszyscy tak uważają, żeby robić buble, byle by tylko zarobić?

W moim przypadku klientem jest pracodawca więc "robić buble byle zarobić" w tym momencie nie znajduje zastosowania.

[Omenomn]

Dyskusja schodzi na drogę metodyk programowania, a Ja chciałem pogadać o specyfikacjach.
Uważam, że iteracje są spoko, ale mi chodzi o to, żeby każda iteracja była w sposób ścisły planowana.

Przykładowo można napisać specyfikację w taki sposób w przybliżeniu:
1. Rejestracja użytkownika
2. Logowanie
3. Zarzadzanie kontem
4. Admin
5. Upload zdjęć
6. Zarządzanie kategoriami

Albo rozpisać wszystko na czynniki pierwsze i zaplanować wszystkie urle, inputy, buttony, wyświetlane dane itp.

I to jest ta sama iteracja.
Okej po wdrożeniu tego można to rozwijać, dodawać kolejne iteracje spoko, ale powyższy przykład specyfikacji nie mówi praktycznie nic programiście o projekcie oprócz pokazania ogólnych funkcjonalności i tak na prawdę nie zdradza dokładnie ilości pracy jaką trzeba włożyć w projekt.

A ten temat założyłem właśnie dlatego, że widzę, że tego rodzaju ogólne specyfikacje iteracji są jakimś standardem dla mnie ciężkostrawnym.

[phpion]

Tylko, że na takie przygotowanie się potrzeba czasu, którego często nie ma.

[darko]

A ja napiszę tak: ciesz się, że w ogóle dostajesz jakieś plan. W mojej praktyce zawodowej spotykam się, zwłaszcza w pracy z systemami ticketowymi, jedynie ze skromną informacją od klienta na zasadzie: chciałbym aby to było zrobione tak i tak. Koniec. O wszystko trzeba podpytać, czasami klienta uświadomić, że rozwiązanie w tej formie jaką on sobie wymyślił nie sprawdzi się w praktyce, albo że można zrobić coś zupełnie inaczej, znacznie lepiej. Często przypomina to niedokończoną książkę, z której, pomimo materialnego braku kartek i okładki trzeba zrozumieć główny wątek, motywy bohaterów i napisać jej streszczenie. Bez sporej dozy zdrowej wyobraźni ani rusz. W idealnym świecie, programista bez otrzymania konkretnej dokumentacji technicznej planowanego projektu tj. diagramów pakietów, klas, erd, sekwencji itd. w ogóle nie powinien zabierać się do pracy. Niestety rzeczywistość wygląda zupełnie inaczej. Czasami przypomina to walkę z klientem o każdy strzęp, niemal ochłap informacji na temat planowanej modyfikacji. Jaki z tego wniosek? Zdobywanie wiedzy o wdrożeniu jest częścią naszej pracy. Odpowiednie zadawanie pytań klientowi/PMowi, logiczne wnioskowanie, budowanie pełnego obrazu na podstawie fragmentów bazując jedynie na doświadczeniu i wiedzy jest tak samo częścią naszego warsztatu jak znajomość podstaw języka programowania, w którym pracujemy, albo podstaw frameworka na którym budujemy aplikacje.

[Omenomn]

Żyjesz w świecie utopii. Teoria mówi jedno, a praktyka pokazuje co innego. Czas to pieniądz, często nie ma czasu na "tracenie" go na tworzenie dokumentacji i pełnej specyfikacji systemu. W pracy zajmujemy się akurat pojedynczymi modułami, dostajemy konkretną funkcjonalność do wykonania i to robimy. Mimo, że są to mniejsze kroki niż cały projekt od 0 to też nie mamy czasu na przygotowanie się do zadania. Otrzymujemy czasem wręcz szczątkowe informacje i trzeba zacząć robić. W międzyczasie uściśla się wymagania, niektóre wywalające do góry nogami to co już zostało stworzone. Problem jest w określaniu terminów takich prac gdy do końca nie wiesz co i jak trzeba zrobić. Swego czasu kolega otrzymał do oszacowania (cytat!): "Zmiany na widoku użytkowników"... To już było kuriozum smile.gif

no i dla mnie to jest właśnie programistyczna tragedia.

Ps. nie mówię o dokumentacji.

A ja napiszę tak: ciesz się, że w ogóle dostajesz jakieś plan. W mojej praktyce zawodowej spotykam się, zwłaszcza w pracy z systemami ticketowymi, jedynie ze skromną informacją od klienta na zasadzie: chciałbym aby to było zrobione tak i tak. Koniec. O wszystko trzeba podpytać, czasami klienta uświadomić, że rozwiązanie w tej formie jaką on sobie wymyślił nie sprawdzi się w praktyce, albo że można zrobić coś zupełnie inaczej, znacznie lepiej. Często przypomina to niedokończoną książkę, z której, pomimo materialnego braku kartek i okładki trzeba zrozumieć główny wątek, motywy bohaterów i napisać jej streszczenie. Bez sporej dozy zdrowej wyobraźni ani rusz. W idealnym świecie, programista bez otrzymania konkretnej dokumentacji technicznej planowanego projektu tj. diagramów pakietów, klas, erd, sekwencji itd. w ogóle nie powinien zabierać się do pracy. Niestety rzeczywistość wygląda zupełnie inaczej. Czasami przypomina to walkę z klientem o każdy strzęp, niemal ochłap informacji na temat planowanej modyfikacji. Jaki z tego wniosek? Zdobywanie wiedzy o wdrożeniu jest częścią naszej pracy. Odpowiednie zadawanie pytań klientowi/PMowi, logiczne wnioskowanie, budowanie pełnego obrazu na podstawie fragmentów bazując jedynie na doświadczeniu i wiedzy jest tak samo częścią naszego warsztatu jak znajomość podstaw języka programowania, w którym pracujemy, albo podstaw frameworka na którym budujemy aplikacje.

Ja nie mówię o współpracy z klientem bezpośrednim, trudno wymagać od klienta bezpośredniego specyfikacji heheh.
Mówię o podejściu głównych programistów i menadżerów projektów do tego.

tak po za tym, jak się robi marne oprogramowanie, to nie dziwota, że trzeba spinać się i pisać szybko, bo się dostaje marne pieniądze.

Ten post edytował Omenomn 18.12.2015, 16:06:01

[darko]

Nigdzie nie napisałem o bezpośredniej pracy z klientem, bo system ticketowy jednak nie jest taką formą współpracy. Ja też mam PMa nad sobą i wiem, co piszę. Spinać się nie trzeba, bo jak to ująłeś

jak się robi marne oprogramowanie, to nie dziwota, że trzeba spinać się i pisać szybko, bo się dostaje marne pieniądze

tu chodzi o specyfikę biznesu. W projektach do pewnej skali nikt nikomu nie zapłaci za zaplanowanie aplikacji, a za jej konkretne wykonanie. Tutaj liczy się czas, bo jak wiadomo - to pieniądz. Tylko tyle, albo aż tyle. Btw. projekty z marną dokumentacją albo jej brakiem wcale nie muszą być marne ani słabo płatne. Nie generalizujmy.

// edit
Jeszcze w temacie dokumentacji: możesz tworzyć kilka miesięcy nawet najlepszą dokumentację na świecie, papier przyjmie wszystko, w założeniach wszystko powinno działać i ze sobą współgrać, niestety w praktyce też tak nie jest i dopiero pewne rzeczy wychodzą w praniu, wiele osób wie o tym, dlatego często dokumentacja powstaje jednocześnie z kodem. Dla mnie dobrą dokumentacją w projektach w php jest ... phpDoc plus ewentualnie jakiś komentarz, w jakim celu dana metoda powstała. Nic więcej nie jest mi potrzebne, oprócz informacji na temat tego, w jaki sposób coś ma działać. A jak ja już to zrobię to praktycznie nikogo nie interesuje, byleby działało dobrze. Co nie oznacza, że tworzymy kod marnej jakości, niewydajny itd.

Ten post edytował darko 18.12.2015, 16:23:13

[Omenomn]

Jeszcze w temacie dokumentacji: możesz tworzyć kilka miesięcy nawet najlepszą dokumentację na świecie, papier przyjmie wszystko, w założeniach wszystko powinno działać i ze sobą współgrać, niestety w praktyce też tak nie jest i dopiero pewne rzeczy wychodzą w praniu, wiele osób wie o tym, dlatego często dokumentacja powstaje jednocześnie z kodem. Dla mnie dobrą dokumentacją w projektach w php jest ... phpDoc plus ewentualnie jakiś komentarz, w jakim celu dana metoda powstała. Nic więcej nie jest mi potrzebne, oprócz informacji na temat tego, w jaki sposób coś ma działać. A jak ja już to zrobię to praktycznie nikogo nie interesuje, byleby działało dobrze. Co nie oznacza, że tworzymy kod marnej jakości, niewydajny itd.

powtarzam, że nie mówię o dokumentacji, ona jest dla mnie nie istotna.
Mówię o specyfikacji, czyli o tym co programista ma do wykonania, nie co już wykonał.

O wszystko trzeba podpytać, czasami klienta uświadomić, że rozwiązanie w tej formie jaką on sobie wymyślił nie sprawdzi się w praktyce

To dobry ten PM, skoro musisz go uświadamiać o tym, że coś się nie sprawdzi.

Ten post edytował Omenomn 18.12.2015, 16:30:39

[darko]

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

[Omenomn]

Powiem tak:
Jak aplikacja może być przemyślana, kiedy nie jest przemyślana?

Ale to dobrze Darko, że jakoś jednak planujecie projekty, chociaż Wy

Ten post edytował Omenomn 20.12.2015, 22:00:19

[darko]

Pisząc wprost: najczęściej najwięcej wie ten, kto będzie na tym robił pieniądze. Jeśli ktoś to przemyślał i wykłada na to pieniądze, to powinien wiedzieć, co robi i najczęściej wie. Czasami trzeba spojrzeć z drugiej strony.

// to, co wydaje się nieprzemyślane z Twojej strony niekoniecznie musi faktycznie takie być od strony kogoś, kto za to płaci.

Ten post edytował darko 20.12.2015, 23:51:28