Jak określa się wymagania w projektach oprogramowania typu open source?

W firmowym wewnętrznym opracowywaniu oprogramowania często określa się wymagania w drodze formalnego procesu, w wyniku którego powstaje szereg dokumentów wymagań. W rozwoju oprogramowania typu open source często wydaje się to nieobecne. Dlatego moje pytanie brzmi: w jaki sposób określa się wymagania w projektach oprogramowania typu open source?

Przez „określenie wymagań” rozumiem po prostu „ustalenie, jakie funkcje itp. Powinny zostać opracowane jako część konkretnego oprogramowania”.

Projekty typu open source czasami mają intensywne strumienie opinii użytkowników, a czasami korporacje po prostu płacą, aby zaplanować i wdrożyć niektóre funkcje (zatrudniając własnych programistów lub pierwotnych programistów).

Jeśli twój projekt ma 100 użytkowników, prawdopodobnie możesz napisać to, co najbardziej sprawia przyjemność kodowaniu.

Jeśli Twój projekt ma 100 000 użytkowników, najprawdopodobniej masz już listę problemów, które większość użytkowników chce naprawić w następnej wersji, oraz listę N najważniejszych funkcji, o które użytkownicy proszą w narzędziu do śledzenia problemów i pytają o nie na forach.

Dzięki tym informacjom możesz napisać dokumenty wymagań dla swojego głównego zespołu, stworzyć mapy drogowe, aby pomóc niezależnym współpracownikom zrozumieć twoją wizję i mieć nadzieję, że niektórzy ze 100 000 użytkowników wyślą łatki.

Śledzę oprogramowanie typu open source, odkąd po raz pierwszy usłyszałem o Linuksie w około 1995 roku i nie pamiętam, by kiedykolwiek słyszałem słowo „wymagania” użyte w tym kontekście.

Eric Raymond ma dobry esej, The Cathedral and the Bazaar , w którym mówi o „drapaniu się w swędzenie”. Jeśli próbujesz rozwiązać problem, z którym mierzysz się osobiście, nie musisz odwoływać się do dokumentów wymagań, aby dowiedzieć się, czy go rozwiązałeś, czy nie.

Ten sam esej mówi również o słuchaniu użytkowników, co jest dobrą radą dla wszystkich, nie tylko dla projektów open source. Projekty o otwartym kodzie źródłowym są zwykle merytokratyczne, więc „ten, kto pisze kod, tworzy reguły”, mniej więcej.

W firmowym wewnętrznym opracowywaniu oprogramowania często określa się wymagania w drodze formalnego procesu, w wyniku którego powstaje szereg dokumentów wymagań.

Z mojego doświadczenia wynika, że ​​jest to o wiele bardziej powszechne w przypadku programowania opartego na umowie, szczególnie gdy zewnętrzna firma zajmuje się tworzeniem oprogramowania dla Twojej firmy i istnieje prawna potrzeba umowy. Ale wiele innych firm kontroluje swój rozwój wewnętrzny przez swoich pracowników w inny sposób:

• nieformalna komunikacja

• priorytetowe wymagania / listy błędów / problemów / zgłoszeń (i zdecydowanie nie jest to wynalazek społeczności „zwinnej”)

W ten sam sposób działa większość projektów typu open source - ponieważ nie ma potrzeby formalnej umowy, nikt nie zadaje sobie trudu opracowania dużych, szczegółowych dokumentów dotyczących wymagań formalnych, tylko małe, bezbolesne listy brakujących funkcji lub biletów zebranych w numerze tracker do rozwiązania.

Jeśli problem występuje często, np. Podczas pisania kompilatora lub przeglądarki, wymagania są podane w postaci standardów językowych, docelowych systemów operacyjnych i docelowego sprzętu itp.

W przypadku takich rzeczy jak GNU Emacs, który jest wiele dla wielu oprócz doskonale wypełniającego swój pierwotny cel, jakim jest edytor tekstów, myślę, że wymagania miały sens ze względu na ogromny zakres jego rozszerzenia. Przychodzą na myśl czaty, e-maile, grupy dyskusyjne, edycja kodu, kontrola wersji. W Emacspeak pracuje naukowiec. Myślę, że podobne rzeczy można powiedzieć o przeglądarkach i innych rzeczach, które pozwalają na rozszerzenia.

Jeśli oprogramowanie nadrabia zaległości w funkcji, która jest dostępna tylko w oprogramowaniu innym niż open source, wymaganie to jest ponownie podane.

EDYTOWAĆ:

Kiedy oprogramowanie open source przechodzi do konserwacji i mniej pierwotnych wymagań pozostaje niespełnionych, większość wymagań może wynikać z błędów, trzeba dostosować się do nowych platform, takich jak wielordzeniowe procesory i inny sprzęt, który oferuje lepszą wydajność, gdy jest wykorzystywany.

W całkowicie opartym na badaniach projekcie, takim jak GNU Hurd, sądzę, że wymagania wynikają z wyników badań i artykułów.

Podsumowując

• na początku wymagania dotyczące oprogramowania, które próbuje rozwiązać typowe problemy, mogą wynikać ze standardowych dokumentów

• w przypadku oprogramowania, które nadrabia zaległości w stosunku do innego istniejącego oprogramowania, wymagania prawdopodobnie będą dotyczyć całego lub większości zestawu funkcji istniejącego oprogramowania oraz niektórych innych funkcji, które twórcy / użytkownicy uznają za interesujące

• w przypadku projektów badawczych papiery i inne publikacje mogą określać wymagania

• w trakcie konserwacji błędy w adaptacji do nowszych środowisk mogą być głównym źródłem wymagań

Nie wiem na pewno, ale raz sugeruję użycie metodologii zwinnej, w której wymagania są podnoszone jako bilety (lub „karty”), używając czegoś takiego jak JIRA, przy czym każdy bilet reprezentuje cechę lub wymaganie. Każdy bilet można następnie rozłożyć na inne bilety reprezentujące mniejsze jednostki pracy.

Jeśli chodzi o ustalenie, co powinna zrobić aplikacja lub oprogramowanie, prostą odpowiedzią jest „rozmowa z innymi programistami”. :) „Mówienie” w tym przypadku może oznaczać listę dystrybucji e-mail, forum, a nawet IRC, wszystko, co pozwala czatować w różnych strefach czasowych i lokalizacjach geograficznych.