Amikor nem tudod, hogyan szólj a kollégáidnak, hogy rosszul dolgoznak

Az eredeti Stack Exchange-kérdés hű magyar fordítása · szerző: user1807 · The Workplace, q35966 · CC BY-SA.

Hogyan mondjam meg a kollégáimnak, hogy a kódbázis, amelyet felépítettek, totál káosz, és a módszereik ősrégiek?

A helyzet. Néhány hónapja egy új cégnél, egy új csapattal dolgozom. A cég bizonyos webes szolgáltatásokat kínál, a csapat szerepe pedig ezeknek a szolgáltatásoknak a fejlesztése és karbantartása. 1. probléma: a csapat nem csapat, hanem egyének halmaza. Nem működnek együtt egymással. Mindenki a saját kódrészletén dolgozik úgy, ahogy neki tetszik, a saját konvencióival és módszertanaival. A legközelebbi dolog az együttműködéshez, amit eddig láttam, ez: „Befejeztem ennek a funkciónak a megvalósítását, most elkezdhetsz rá építeni valamit.” 2. probléma: nincs modularitás. Nos, valójában minden fejlesztő munkája a saját repójában van, de ezek a repók erősen heterogének, és különféle dolgokat kevernek (gyakran újra feltalálják a kereket és duplikálják a kódot). 3. probléma: a fejlesztési gyakorlatok tényleg ősrégiek. Ismerik az „agilis” szót, de nem értik a mögötte lévő fogalmat (valószínűleg azért, mert sosem próbálták). Nincsenek kódellenőrzések, nincsenek tesztek, a szoftvert nagyon nehéz konfigurálni és testreszabni. Az egész fejlesztési folyamat lassú és nem hatékony. Sok más hiba is van, de ezek valószínűleg a fent felsorolt három probléma következményei. Röviden, a kódbázis egy káosz. Hogyan kezeljem? Itt dolgozva gyorsan észrevettem ezeket a problémákat, és először úgy döntöttem, hogy inspirációval vezetek: az első projektemen néhány agilis fejlesztési gyakorlattal dolgoztam, és a visszajelzés jó volt. Most azonban olyan helyzetben vagyok, ahol mások kódjához/gyakorlataihoz szeretnék nyúlni, és nem tudok inspirációval vezetni, mert szükségem van az együttműködésükre. Próbáltam megértetni velük, hogy ők egy csapat, amely egy terméket épít, és nem egyének, akik a saját projektjeiken dolgoznak. Ők azonban nem értették, mire gondolok, és egyszerűen figyelmen kívül hagytak. Most arra gondolok, hogy megváltoztatom a megközelítésemet: explicit módon szeretném kijelenteni, hogy hibákat követnek el, elemezve minden hibát, azok okait és megoldásokat javasolva. Alacsony szintről szeretnék kezdeni (pl. „ez a kódrészlet lassú/hibás/nem hatékony”), majd lassan a magasabb szint felé haladni (pl. iterációk a vízeséssel szemben). De attól félek, hogy azt gondolnák, támadom őket, ami nem így van. Ez a helyes megközelítés? Hogyan járjak el? 1. SZERKESZTÉS: A válaszaitok alapján egyértelmű, hogy ez rossz megközelítés. A mai naptól folytatom a példamutatással való vezetést, és explicit módon rámutatok a módszereim által hozott előnyökre. (Mostanáig folyamatosan kértem visszajelzést, de valójában sosem tettem fel olyan explicit kérdéseket, mint „hé, tetszik, hogy elfogadási teszteket írtam? Szerintetek javítani fogják a projekt általános minőségét?”) Lássuk, beválik-e! 2. SZERKESZTÉS: Ahogy mondtam, elkezdtem példamutatással vezetni, és beszélni a csapattársakkal és a vezetőkkel. Az eredmény? Kineveztek „fő reviewerré”, vagyis a szerepem most az, hogy aktívan részt vegyek minden technikai vitában, javaslatokat adjak az architektúrára, és új megközelítéseket vezessek be a fejlesztési folyamatba.

Original Stack Exchange question · author: user1807 · The Workplace, q35966 · CC BY-SA.

How do I tell my colleagues that the codebase they've built is a total mess and their practices are ancient?

The situation For a few months, I've been working with a new team in a new company. The company offers some web services and the team's role is to develop and maintain those services. Problem #1: the team is not a team, it is a set of individuals. They do not collaborate with each other. Everyone works on his own piece of code in the way he likes, with his own conventions and methodologies. The closest thing to collaboration I've seen so far is: "I've finished implementing this feature, now you can start building something on it". Problem #2: There is no modularity. Well, actually, each developer's work is in its own repository, but those repositories are highly heterogeneous and mix different stuff (often reinventing the wheel and duplicating code). Problem #3: The development practices are really ancient. They know the word 'agile' , but they don't understand the concept behind it (probably because they've never tried it). There are no code reviews, there are no tests, software is really hard to configure and adapt. The overall development process is slow and inefficient. There are many other defects but they are probably consequences of the three problems listed above. In short, the codebase is a mess How to deal with it? Working here, I've quickly noticed these problems, and at first I decided to drive by inspiration: I've worked on my first project with some agile development practices and the feedback has been good. However now I'm in a situation where I'd like to touch other people's code/practices and I can't drive by inspiration, because I need their collaboration. I tried to make them understand that they're a team that is building a product and they're not individuals working on their own projects. However they couldn't understand what I meant and simply ignored me. Now I'm thinking to change my approach: I want to explicitly state that they're making mistakes, analyzing each mistake, their causes and proposing solutions. I want to start from the low level (e.g. "this piece of code is slow/wrong/inefficent") and then slowly move to the high level (e.g. iterations vs. waterfall). But I fear that they would think I'm attacking them, which is not the case. Is it the right approach? How should I proceed? EDIT 1: Based on your answers, clearly this is the wrong approach. Starting from today, I'm going to continue leading by example and explicitly point out the benefits brought by my methods. (Untill now, I have constantly asked for feedback, but actually have never asked explicit questions like "hey, do you like the fact that I have written acceptance tests? Do you think they will improve the overall quality of the project?") Let's see if it works! EDIT 2: As I said, I started leading by example and speaking with teammates and with managers. The result? I've been nominated "master reviewer", i.e. my role now is to actively participate in all technical discussions, give suggestions on the architecture and establish new approaches to the development process.