Sparuj logikę biznesową programowania z osobą niebędącą specjalistą IT [zamknięte]

14

Zamknięte . To pytanie musi być bardziej skoncentrowane . Obecnie nie przyjmuje odpowiedzi.

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby skupiało się tylko na jednym problemie, edytując ten post .

Zamknięte 4 lata temu .

Czy masz doświadczenie, w którym osoba niebędąca informatykiem pracuje z programistą podczas procesu kodowania?

To jest jak programowanie w parach, ale jedna osoba to osoba niezwiązana z informatyką, która dużo wie o firmie, być może inżynier procesu z wykształceniem matematycznym, który wie, jak się rzeczy oblicza i rozumie nieidiomatyczny, proceduralny kod.

Przekonałem się, że niektóre języki proceduralne, specyficzne dla domeny, takie jak PL / SQL, są dość zrozumiałe dla inżynierów spoza IT. Osoby te są współautorami kodu i gwarantują poprawność formuł, czynników itp.

Uważam, że tego rodzaju programowanie par jest dość produktywne, tego rodzaju użytkownicy inżynierscy uważają, że są również „właścicielami” i „autorami” kodu i pomagają zminimalizować nieporozumienia w procesie komunikacji. Pomagają nawet w projektowaniu przypadków testowych.

Czy ta praktyka jest powszechna?
Czy to ma imię?
Czy miałeś jakieś podobne doświadczenia?

— Tulains Córdova
źródło

11

Chociaż opisujesz to jako wspólną sesję kodowania (nie mogę tego nazwać programowaniem parowym, ponieważ tylko jedna osoba „jeździ” - w programowaniu parowym obie strony biorą klawiaturę i piszą kod), nazwałbym to gromadzeniem kryteriów akceptacji .

Oznacza to, że weryfikujesz reguły biznesowe (poprawne obliczenia i procesy) z użytkownikiem biznesowym (choć jednym z bardzo technicznej roli, inżynierem).

W tym przypadku przekłada się natychmiast na kod napisany (SQL), ale w przypadku wielu innych czynności tak nie będzie, chociaż istnieją narzędzia do automatycznego testowania akceptacji dla różnych języków i platform (szczególnie myślę o języku korniszonu i pokrewnych narzędziach).

Ta praktyka nie jest tak powszechna, jak powinna być, ale zyskuje coraz więcej obserwujących, a ci, którzy ją przestrzegają (otrzymując kryteria akceptacji w formie, którą można wykonać) uważają ją za nieocenioną zarówno jako narzędzie komunikacji z biznesem, jak i prowadzenia rozwój.

— Oded
źródło

Przynajmniej tam, gdzie jestem (mała firma), mamy dużą komunikację między stroną biznesową i inżynierską, ale mam ochotę mieć jednego z ludzi biznesu, który wie, że jego rzeczy siedzą i omawiają kod ze mną po kolei byłoby marnotrawstwem zasobów firmy, szczególnie biorąc pod uwagę stan gospodarki i to, jak zmusza firmy do bycia tak szczupłym, jak to możliwe. Gdybyśmy mieli więcej godzin w dniu pracy, może to mieć sens, ale każda godzina się liczy. W każdym razie tylko mój wkład.

— Ampt

@Ampt - próbowałeś? Jeśli używasz specyfikacji wykonywalnych , możesz przejść przez specyfikację zamiast kodu.

— Oded

Nie próbowałem tego i nie twierdzę, że jest w jakikolwiek sposób zły! Właśnie powiedziałeś, że to nie jest tak powszechne, jak powinno być, a ja dawałem swój wkład, dlaczego tak się dzieje. Uważam, że im więcej masz komunikacji między biznesem a stroną rozwojową, tym lepszy może być twój projekt . Jakość tej komunikacji często określa, jak dobry jest twój projekt, i zgodnie z tą logiką siedzenie z przedsiębiorcą i przeglądanie kodu, który mogliby zrozumieć, prawdopodobnie należałoby do kategorii dobrej komunikacji.

— Ampt

2

Tak. Tam, gdzie pracuję, zajmuję się hardcorowym programowaniem, podczas gdy strategowie pracują nad strategią Uhm. To znaczy, że piszę programy, które wdrażają ich modele handlowe.

Kluczem do tego jest siedzi tuż obok nich i zrozumieć dokładnie, jakie pomysły są, i prosząc wiele pytań o rzeczy, które mogą być przypadkowe do nich, ale ważne jest, aby po stronie wykonania. Na przykład zapytałbym, jak szybko trzeba wykonać transakcję, czy wpływa to na ich model. Ma to ogromny wpływ na sposób pisania kodu. W rzeczywistości mam tendencję do rozpylania pytań w pokoju, ponieważ siedzimy tam codziennie i pracujemy.

Jest dwukierunkowa informacja zwrotna. Jeśli powiem im, że jakiś plan handlu nie będzie łatwy do zbudowania, wrócą i zastanowią się, które kompromisy można podjąć po stronie decyzyjnej. Jeśli zdecydują, że ich nowa strategia potrzebuje nowej funkcji, rozmawiam z nimi o tym, ile czasu zajmie zbudowanie i jakie są potencjalne pułapki.

Robią moduły kodu, które od czasu do czasu zawierają pewne aspekty strategii handlowej, ale masuję te elementy razem w architekturze, która pozwala nam śledzić wszystkie różne strategie, a także zaplecze operacyjne. W ten sposób nie muszą znać drobiazgowości systemu.

— Carlos
źródło