W jaki sposób należy wprowadzić standardy i usprawnienia procesów w organizacji bez nich?


10

Miałem za zadanie ulepszenie procesu tworzenia oprogramowania poprzez wdrożenie ulepszeń procesu, z których najprawdopodobniej będziemy korzystać z CMMI for Development, wersja 1.3 jako wytycznych i przyjmując najlepsze praktyki w całości lub w części. Jaki jest najlepszy sposób wprowadzenia standardów i ulepszeń procesów, aby zminimalizować stopień wypychania i opór ze strony programistów?


Ciekawe, czy masz już pojęcie, dlaczego więcej błędów przechodzi przez to, co jest pożądane?
Chris Pitman

2
@ S.Lott Czy możesz uzasadnić, że błędy nie są redukowane (po stronie konsumenta) bez standardów? Z mojego doświadczenia wynika, że ​​proces i standardy znacznie ograniczają to, co konsument widzi na błędach ... nie dlatego, że nie istnieją, ale klient nigdy ich nie widzi.
Przypon

@RobZ: Nie pytałem, co aktualnie masz. Wciąż próbuję zrozumieć pytanie. „wdrażanie ulepszeń procesu” wydaje się być najdokładniejszym opisem tego, o co pytasz. Sugerowałbym, że „standardy” to mylące pojęcie, ponieważ ma formalną definicję i nie używasz tej formalnej definicji.
S.Lott,

@Robz: „Standardy kodowania” to nie „Standardy formalne”. To wyjaśni pytanie. Jeszcze raz. „Formalne standardy” to standardy W3C, Posix, ISO, IEEE, ANSI. Opracowane i zatwierdzone przez uznaną organizację zajmującą stanowisko. Jeśli mówisz o standardach kodowania, zaktualizuj pytanie, aby usunąć słowo „Formalne” i użyj słowa „Kodowanie”. Przy tej zmianie twoje pytanie ma sens. I jest duplikatem.
S.Lott,

„Jeśli chodzi o słowa„ standardy ”w tytule w powiązaniu z ulepszeniami procesu, słowo standardy nie dotyczy tylko kodu, który ktoś pisze”? Co? Oto podpowiedź. Proszę nie używać słowa „standard” bez jakiegoś kwalifikatora; to jest mylące. Jeśli masz na myśli „standardy kodowania”, użyj tego wyrażenia. Jeśli masz na myśli inny rodzaj „standardu”, wpisz słowo „standard” w zdaniu kwalifikującym, aby wyjaśnić, o czym mówisz. „standard” jest niejasny i mylący.
S.Lott,

Odpowiedzi:


2
  1. Rozpocznij projekt poprawy procesu oprogramowania (SPI) . Określ jego zakres i cele. Z pewnością pomoże, jeśli normalizacja ma swoje własne cele i środki mające zastosowanie do Twojej organizacji.
  2. Wyznacz osobę odpowiedzialną za przyjęcie standardów . W przypadku dużej organizacji może to być kilka osób, a nawet dział. Ważne jest to, że wszyscy odpowiedzialni za normalizację to:
    • wystarczająco profesjonalny, aby zobaczyć cały obraz
    • wystarczająco wpływowy, aby radzić sobie z zespołami i pomagać im w przyjmowaniu / negocjowaniu zmian
  3. Opracuj szkolenia obejmujące zarówno standard, który chcesz przyjąć, jak i jego specyfikę stosowaną w Twojej organizacji. Jest to naprawdę ważne, o ile wszystkie osoby, które nie zostały przeszkolone, są potencjalnie odporne na zmiany. Na przykład, kiedy pracowałem w dużej firmie, poinstruowałem wszystkich nowych pracowników o procesach zapewniania jakości, CMMI, ISO i systemie zarządzania jakością. Takie szkolenie było obowiązkowe. Pomogło to poprawić wiedzę na temat procesów zarządzania jakością i podnieść świadomość pracowników na temat ważnej kwestii jakości oprogramowania.
  4. Negocjuj zmiany i dostosuj ogólnie przyjęte praktyki do swoich konkretnych potrzeb. Pomoże to uniknąć biurokracji i wdrożenia ciężkich procesów, których tak naprawdę nikt nie potrzebuje.
  5. Ustanowić monitorowanie, w jaki sposób obsługiwane są usprawnienia procesów wdrożonych i czy są one wystarczająco skuteczne w organizacji.

Pomoże to również, jeśli znajdziesz wszystkich ludzi w organizacji, którzy są naprawdę zaniepokojeni jakością. Najprawdopodobniej byłyby one najważniejszym zasobem pomagającym w promowaniu zmian i ustalaniu dojrzałych praktyk.


6

Kilka myśli ze szkoły mocnych uderzeń:

1) Większość inicjatyw doskonalących procesy spędza 80% swojego czasu na projektowaniu procesów, a 20% na edukacji i socjalizacji. Odwróć te wartości procentowe. Przeciętny miernik, który jest przestrzegany, bije doskonały, który nie jest.

2) Zidentyfikuj wyraźne powody, dla których prosisz ludzi o zmianę sposobu pracy. Jaki jest przypadek biznesowy? Idealnie przyniesie korzyści każdemu zespołowi indywidualnie. Czasami jest to tylko poprawa systemowa. Tak czy inaczej, spraw, aby obudowa była widoczna.

3) Uprość, a następnie ustandaryzuj, a nie na odwrót.

4) Nie możesz w pełni przekazać tego PMO. Bezpośredni menedżerowie muszą zostać wykupieni, a kierownik jednostki biznesowej będzie musiał zerwać więzi, gdy pojawią się skargi.

5) Znajdź przyjaznych wczesnych użytkowników. Ludzie będą narzekać na to, ile czasu to wszystko zajmuje. Potrzebujesz kogoś, kogo możesz wskazać i powiedzieć: „zajęło im to tylko 15 minut”

6) W przypadku wskaźników mocno naciskaj na ilościowe ponad jakościowe. W przeciwnym razie masz projekty, które są zielone, aż do dnia przed uruchomieniem Live, kiedy wszystko potoczy się o miesiąc.

7) Nacisk na techniki na narzędzia. Dobre planowanie jest ważniejsze niż MS Project.

8) Ustaw poziom procesu w zależności od potrzeb. Każda restauracja potrzebuje procesu, ale Nobu i francuska pralnia potrzebują innego rodzaju niż McDonalds. To samo dotyczy firm zajmujących się oprogramowaniem.

Powodzenia!


1
Świetna odpowiedź - dodam też bardzo ostrożnie z wprowadzonym procesem - Upewnij się, że nie wpadniesz w pułapkę robienia tego, co najlepsze dla procesu, a nie tego, co najlepsze dla klienta - tzn. Proces musi być zorientowany na klienta. Uważaj także na to, co mierzysz - z definicji to, co jest miarą, jest ważne, a to, co nie jest mierzone, jest nieistotne. Zmierz złe rzeczy (SLOC / Dzień, Błędy / SLOC itp.), A nie uzyskasz poprawy, ale pomiary pokażą, że tak.
mattnz

1
@mattnz - Nie wiem, błąd / SLOC może być użytecznym miernikiem, jeśli zastosujesz go poprawnie. Gdyby ktoś powiedział, że średnio 1 błąd / 10 SLOC, prawdopodobnie byłbym zaniepokojony. Sztuką jest to, że musisz wiedzieć, gdzie są paski, co może być trudne.
rjzii

Słuszna uwaga. Ludzie optymalizują swoje dane. Jeśli najpierw stworzysz miary finansowe, ludzie zoptymalizują się do tego kosztem funkcjonalności lub obsługi klienta. Chodzi o równowagę i priorytety.
MathAttack

1
Zmierz mnie przez błędy / SLOC, SLOC / dzień, a będziesz zaskoczony, jak bardzo mogę zrobić mój kod źródłowy bez dodawania niczego użytecznego. Na przykład zawsze umieszczanie nawiasów klamrowych w nowej linii - im więcej linii, tym mniejsza statystyka, tym lepszym programistą się natychmiast. Daj mi KAŻDĄ miarę, a pokażę ci, jak mogę sprawić, by ten pomiar sprawił, że wyglądam lepiej.
mattnz

1
@mattnz - Do tego właśnie służy przegląd kodu, jeśli ktoś niepotrzebnie wypowiada swój kod, aby ukryć fakt, że jest on pełen błędów, istnieje prawdopodobieństwo, że nie powinien pisać kodu na początku. Możesz także spojrzeć na defekty na punkt funkcji, które są niezwykle trudne do sfałszowania, ponieważ albo widzisz ekspozycję liczby funkcji ze spadającą liczbą (zły znak), albo liczba zaczyna się zmniejszać wraz z poprawą kodu (dobra znak).
rjzii

2

Oparcie swoich wysiłków na CMMI jest prawdopodobnie dobrym pomysłem, nawet jeśli nie poddasz się ocenie i nie zostaniesz formalnie skontrolowany i oceniony. Dostępnych jest wiele literatury na temat CMMI , CMMI i innych technik doskonalenia procesów, takich jak Lean i Six Sigma , oraz CMMI i zwinne tworzenie oprogramowania . SEI ma całą kolekcję zasobów , niektóre dostępne za darmo, na temat różnych aspektów CMMI oraz wytycznych dla różnych typów organizacji.

Zalecałbym głębsze przyjrzenie się ciągłemu podejściu do wdrażania CMMI zamiast podejścia etapowego. Uderza mnie to jako o wiele bardziej skuteczny sposób na dokładne określenie, gdzie obecnie znajduje się Twoja organizacja i ulepszenie obszarów, które zapewniają największą wartość biznesową. Pozwoli to nie tylko dostosować wysiłki związane z poprawą do celów biznesowych, ale także szybko osiągnąć kamienie milowe postępu i wykazać efekty poprawy, zwiększając zaangażowanie na wszystkich poziomach.

Należy jednak pamiętać, że udoskonalanie procesów jest ogólnie bardziej skuteczne, gdy jest to wysiłek oddolny. Kiedy zmiany procesu są podyktowane z góry - przez ludzi, którzy programiści „w okopach” mogą uznać za nieczułych na to, jak rzeczy są wykonywane w okopach - prawdopodobnie nastąpi odepchnięcie, nawet jeśli pomysł jest dobry. Przygotuj się na to.

Korzystny może być również pewien rodzaj grupy procesów inżynieryjnych . Zbierz przedstawicieli różnych elementów organizacyjnych i zespołów, których dotyczy poprawa, aby każdy mógł usłyszeć głos. Dotyczyłoby to nie tylko przedstawicieli każdej roli, ale być może różnych zespołów opracowujących produkty. Nie wiedząc, jak jest zorganizowana Twoja organizacja, nie mogę powiedzieć dokładnie, na kogo możesz chcieć spojrzeć, ale uwzględnij osoby z każdego poziomu organizacji w grupie. Udostępniaj także dyskusje i decyzje podejmowane przez tę grupę organizacji w celu uzyskania komentarzy i zgłaszania wszelkich problemów.


Nie jestem pewien, jak dobrze będzie działać wysiłek oddolny, ponieważ bardzo niewiele zespołów projektowych formalizuje jakiekolwiek procesy, dlatego będzie to proces bardziej odgórny. To powiedziawszy jednak, wszyscy martwią się, aby uczynić rzeczy tak delikatnymi, jak to możliwe, aby zapobiec niepowodzeniu wysiłków z powodu braku faktycznego wdrożenia.
rjzii

@RobZ Z definicji nie można naciskać na oddolne wysiłki - musi to oczywiście pochodzić z dołu do góry. O ile zespoły projektowe nie zdadzą sobie sprawy z tego, że istnieje prawdziwy problem, tendencja polega na tym, aby nie zmieniać się i przeciwstawiać zmianom, które są w pewien sposób postrzegane jako złe (takie jak komplikowanie lub utrudnianie pracy, co często wiąże się z ulepszaniem procesu, chociaż nie jest często tak jest).
Thomas Owens

Właśnie i dlatego zarządzanie formalizuje sprawy. Wystąpiły problemy z niektórymi programami, które zniknęły za drzwiami, i chcą oni także zmienić kulturę firmy, a także upewnić się, że złe produkty nie znajdą się ponownie w terenie.
rjzii

@RobZ A gdy zarząd wkracza i dyktuje działania, programiści się opierają. Nie można nakazać zmiany kulturowej i oczekiwać, że nastąpi ona w prosty i cichy sposób. To długi, bolesny proces.
Thomas Owens

Nikt tak naprawdę nie spodziewa się, że tak się stanie, i już napotykamy opór, w tym momencie szukamy sposobów, aby go zminimalizować.
rjzii

0

Dla każdej zmiany:

  • Wywołaj 1 zmianę i jak poprawi ona rozwój.
  • Wprowadź zmianę.
  • Wykazać poprawę
  • Usuń zmiany, które nie wykazały poprawy

Oczywiście analiza musi nastąpić z czasem, ale żadna zmiana nie powinna zostać zaakceptowana, dopóki nie zostanie udowodniona, że ​​jest skuteczna. Dlatego też wprowadzałbym nie więcej niż 2-3 zmiany na cykl, w przeciwnym razie często nie można zmierzyć, czy nastąpiła poprawa, czy nie.

Nic nie drażni mnie bardziej niż ślepe przestrzeganie najlepszych praktyk bez przeprowadzania analizy, która pokazuje, że jest to najlepsza praktyka dla twojego środowiska. Najlepszych praktyk , które nie wykazuje poprawy jest w najlepszym marnotrawstwem aw najgorszym uszkodzenia.

Wszystkie etapy procesu i wszystkie praktyki metodologiczne powinny zostać przeanalizowane i okazały się korzystne. Jeśli nie, należy go usunąć. Analizę tę należy przeprowadzać na bieżąco, niezależnie od dodawania lub usuwania kroków lub praktyk.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.