pair-programming

___ qstntxt ___

Ich möchte die Situationen vermeiden, in denen meine Entwickler das gemeinsame Wissen (Lösungen für die aufgetretenen Probleme, coole Tipps, häufige Fehler, Verknüpfungen zum Erreichen bestimmter Ziele, Konfigurationsprobleme, Teilanforderungen usw.) nicht miteinander teilen . Ich nehme die Situation in Betracht, wenn ein solcher Kommunikationsmangel zufällig ist (ein Ergebnis von Missverständnissen oder unangemessenem Management) - ich denke nicht über Situationen nach, in denen Entwickler das Wissen bewusst für sich behalten.

Ich glaube, dass die folgenden Techniken äußerst nützlich sind, um den Informationsfluss innerhalb des Entwicklerteams zu verbessern:

  • XP-Paar-Programmierung - aufgrund des Wissensaustauschs innerhalb des Paares (und aufgrund der regelmäßigen Paarmischung).
  • Stand-up-Meetings - aufgrund der Gelegenheit, den anderen mitzuteilen, woran Sie gerade arbeiten und welche Probleme aufgetreten sind.
  • Schulungen / Präsentationen / Coaching, die von den Lead-Entwicklern für den Rest des Teams / der Abteilung vorbereitet werden.
  • "web 2.0 tools" - techie blogs für das Unternehmen / die Abteilung, dedizierter Twitter-Account des Teamleiters, Wiki's und ähnliches.

Irgendwelche weiteren Ideen? Welche Techniken verwenden Sie (oder haben Sie) in Ihrem Unternehmen? Wie würden Sie Entwickler ermutigen, das Wissen untereinander zu teilen?

    
___ answer687580 ___

Ich werde ein paar mehr hinzufügen

  • Stellen Sie die richtigen Leute ein - Dies ist wichtig, wenn Sie eine große Dynamik schaffen wollen (asoziale Leute benötigen viel mehr Aufwand)
  • Pre-mortem und post-mortem. Wir benutzen das Wiki dafür, erstellen eine Seite für jedes Ihrer Projekte, teilen es in Abschnitte von wiederkehrenden Dingen (sowohl Waren als auch Schlechtem). Am Ende jedes Meilensteins muss sich das Team treffen, um eine Obduktion durchzuführen. Lassen Sie den Projektkoordinator am Ende des Projekts (oder nach einer festen Zeitspanne) etwas für die Nachwelt leicht lesbar zusammenstellen (und in Ihr Wiki einfügen)
  • Tägliches Aufstehen ist ein Muss! Du hast es schon gesagt, aber ich finde es so hilfreich!
  • Wenn Sie mehrere Teams in der Firma haben, organisieren Sie eine Konferenz über eine ihrer größten Errungenschaften. Wenn möglich, in regelmäßigen Abständen, sogar accros Abteilung, würden Sie überrascht sein, wie Künstler an der Arbeit von Programmierern interessiert sein können.
  • Mittagessen ist eine gute Zeit zu teilen, in unserer Firma haben wir den Präsidenten Frühstück, Projekt führt Mittagessen, Ende des Projekts Abendessen. Ich liebe sie alle, mische und mische für bessere Ergebnisse.
  • Offsite Treffen mit der ganzen Firma ist großartig, wir machen es mindestens einmal im Jahr (am Morgen stellen wir vor, was in der Zukunft kommt, Nachmittag, ist Aktivitäten um etwas über die Projekte zu erfahren)
  • Wikis sind großartig, aber hüte dich vor Informationen, die im Laufe der Zeit falsch werden können (dies ist ein Problem, das bei allen geschriebenen Informationen auftaucht)
___ answer687570 ___
  1. Ein internes twitter-ähnliches Dienstprogramm. Vielleicht ein Wiki, wenn du es zur Arbeit bringen kannst, ich persönlich finde es ein bisschen zu viel. Aber Twitter ist anders. "habe gerade eine Erweiterungs-Methode hinzugefügt, um einer Like-Klausel in einem Zeilenfilter zu entkommen" und solche Sachen.

  2. Manche Leute mögen es ein wenig aufdringlich finden, aber einen gemeinsamen Ort für Dienstprogramme, damit Sie wissen, wo Sie suchen und string.CountOccurrences nicht in der Codebasis verstreut ist.

___ answer687527 ___

Vertrauen.

Sie dürfen "dumm" erscheinen, aber bitte fragen , wenn Sie nicht wissen oder nicht ganz verstehen, was ich sage. Und bitte sag mir, wenn ich falsch liege (ich habe es nicht bemerkt, weil ich genauso dumm bin.)

    
___ answer687941 ___

Noch ein paar Dinge:

  • Muster & amp; Practices Meetings - Diese müssen nicht jede Woche sein, aber es sollte etwas Zeit darauf verwendet werden, wo das Team verschiedene offene Fragen diskutieren kann und einen Konsens für Dinge hat, die vielen Leuten Kopfschmerzen ersparen können.

  • Kulturfaktor - Bietet der Arbeitsplatz genug Sozialisation, um dem Team zu helfen, oder könnten einige Teambildungsübungen, z. ein Hindernisparcours oder Kochen zusammen, nützlich sein, um etwas Dynamik zu etablieren. Gibt es eine Demut unter den Entwicklern, so dass es keine großen Egos gibt, die ein Problem sein können? Ein weiterer Faktor hier ist, darüber nachzudenken, wie du das beantworten würdest: Würdest du in eine lokale Kneipe gehen und mit deinen Teamkollegen etwas trinken gehen? Wenn ja, dann haben Sie hier ein paar gute Punkte, wenn nicht, dann könnte es hier eine Untersuchung geben.

  • Retrospektive Nachbereitung - Wie werden Ideen in Retrospektiven betrachtet und umgesetzt? Wie werden Meetings im Allgemeinen behandelt?

  • Demos innerhalb des Teams - Wenn eine Story fertig ist und einige große Codepunkte enthält, dann sollte es vielleicht eine kleine Demonstration für das Team geben, um zu sehen, was getan wurde und anderen zu zeigen, was getan wurde dass das Wissen verbreitet wird. Dies kann mit meinem ersten Punkt in Bezug auf etwas, das zur weiteren Kommunikation beiträgt, in Einklang gebracht werden.

___ answer687528 ___

Ich bin ein großer Befürworter des Arbeitens in Paaren. Es ist ein guter Weg, Wissen zu vermitteln und Kommunikationswege offen zu halten. Versuchen Sie auch, die Paare für jedes Projekt zu mischen.

    
___ qstnhdr ___ Information / Wissensfluss innerhalb des Teams [geschlossen] ___ answer687576 ___

Wenn Sie ein Team haben, das ausreichend klein ist und SVN commit Kommentare verwendet, und ein Tool ausnutzt, das einen RSS-Feed generiert (wie Trac zum Beispiel), kann dies eine einfache und effiziente Art der Kommunikation sein.

Dafür gibt es mehrere Voraussetzungen, die ganz einfach zu erreichen sind: - sich häufig verpflichten (das ist an sich gut, da es jedem ermöglicht, von den lokalen Änderungen jedes Programmierers zu profitieren und Probleme frühzeitig zu erkennen); - Verwenden Sie ausführliche Kommentare (was gut ist, da es leichter nachvollziehen lässt, was geändert wurde, falls etwas zusammenbricht); - Stellen Sie sicher, dass alle Nutzer die Feeds lesen (besser noch, über einen RSS-Reader informiert).

Natürlich gibt es keine Möglichkeit, auf solche Kommentare "zu antworten", aber wenn jemand wirklich antworten muss, ist es wahrscheinlich zwischen dieser Person und dem Committer, also ist Mail in der Regel genug.

Ein anderes nützliches Werkzeug ist es, jeden Entwickler zu bitten, sagen wir einmal pro Woche, eine ungefähre Liste von 10 Empfehlungen für andere Programmierer zu einem Thema zu schreiben, mit dem er / sie wirklich vertraut ist.

    
___ answer689054 ___

Zeit.

Offiziell

Wenn du aus deinem staubigen Büro gehst, um deine Gedanken zu klären, dir wirklich die Zeit zu nehmen, zu einem Vortrag oder einer Schulung zu gehen, hilft das alles, Wissen zu verbreiten.

Es ist auch einfach zu budgetieren: N Entwickler gehen für T Stunden zu treffen.

Nicht offiziell

"On the Job" Training ... Die Dinge, die Sie für Ihre spezifische Arbeit brauchen, können nur von jemandem gelernt werden, der den Job kennt.

Im aktuellen Klima, unter dem gegenwärtigen Druck (muss jetzt versenden), braucht niemand Zeit, um etwas vollständig zu erklären. Nur wenn die Leute entspannt sind, sind sie bereit für den Informationsaustausch. Die Leute sind entspannt, wenn sie genug Zeit haben.

Abgesehen davon müssen Sie auf einen bestimmten Linker-Fehler stoßen, bevor Sie wirklich anfangen darüber nachzudenken. Ohne die Zeit zu denken, zu fragen, zu lesen, wirst du nicht in der Lage sein, das Wissen zu bekommen. Du kannst es nicht auf ein offizielles Linker-Training verschieben.

Viel schwerer zu budgetieren: Entwicklerin Mary hat die Entwicklerin Sophie über anderthalb Stunden über dynamische Verbindungen gefragt. Am nächsten Tag ging sie mit einigen Fragen zurück. Erfahrene Entwickler verbringen mehr Zeit mit dem Verteilen, während jüngere mehr Zeit zum Lernen benötigen.

    
___ tag123projectmanagement ___ PROJEKTMANAGEMENT FRAGEN SIND OFF-THEMA. Bitte stellen Sie diese Fragen auf ProjectManagement.SE - https://pm.stackexchange.com ___ tag123pairprogrammierung ___ Die Paarprogrammierung ist eine agile Softwareentwicklungstechnik, bei der zwei Programmierer an einem Arbeitsplatz zusammenarbeiten. ** Wichtiger Hinweis: ** Fragen zur Entwicklungsmethodik sind nicht Thema und sollten stattdessen an Software Engineering SE gerichtet werden. ___ tag123agile ___ FRAGEN ZU SOFTWAREENTWICKLUNGSMETHODEN UND -PRAKTIKEN ODER PROJEKTMANAGEMENT SIND OFF-THEMA. Bitte beachten Sie Software Engineering oder Project Management Stack Exchanges für diese Fragen. ___ answer687569 ___

Ich habe viele Ansätze ausprobiert und bin ein großer Fan, wenn ich paarweise an Projekten arbeite und regelmäßige Diskussionen oder Treffen mit dem Team mache.

Ich habe aber auch festgestellt, dass das Beste, was ich tun kann, darin besteht, eine Kultur der ständigen Kommunikation zwischen den Entwicklern zu fördern. Ich versuche alle meine Entwickler miteinander kommunizieren zu lassen, während sie arbeiten - nicht einmal bis zu einem wöchentlichen oder monatlichen Treffen.

Für mich ist das ein wenig komplizierter, da die meisten meiner Entwickler nicht am gleichen Ort sind. Daher haben wir einen einzigen XMPP-Chatroom-Setup, und wir alle sind immer eingeloggt, wenn wir an dem Projekt arbeiten. Einige der Entwickler (einschließlich mir) werden sich auch während unserer Bürozeiten einloggen.

Ich mache das gleiche mit den Leuten in meinem Büro - wir neigen dazu, ein ziemlich ruhiger Haufen zu sein, aber ich bin sehr offen dafür, dass Leute sich gegenseitig mit Fragen unterbrechen oder sich einen Stuhl nehmen und sich jederzeit zu einem Brainstorming hinsetzen .

Ein Teil der Gründe dafür ist, dass ich versuche, die Kommunikation nicht auf die Arbeit oder ein bestimmtes Projekt zu beschränken. Mein Gefühl ist, dass die Leute über andere, nicht arbeitsbezogene Dinge reden werden, ob ich das nun fördere oder nicht. Ich würde den "Wasserkühler" lieber in einem offiziellen Kanal sprechen lassen, als draußen.

Damit fühlen sich alle wohler, die Fragen zu stellen, die "offensichtlich" erscheinen. Außerdem stellen die Leute ständig Fragen, da sie genau dort sind und gewohnt sind, mit jedem zu reden. Es ist leicht zu ignorieren, wenn es nötig ist, aber es ist auch viel einfacher, einfach eine allgemeine Frage zu stellen und zu sehen, ob jemand Ideen hat, ohne sich wie ein Schmerz zu fühlen, usw.

Meine Erfahrung ist, dass die Zeit, die durch die Unterbrechung verloren geht, viel kleiner ist als die Zeit, die gespart wird, weil eine Gruppe immer bereit ist, ein Problem zu lösen.

    
___ answer690957 ___
  • keine Wände - Haben Sie alle Ihre Entwickler in einem großen, nicht ummauerten Raum - wo jeder sehen und miteinander reden kann.
  • gemeinsame Ziele - Sicherstellung, dass Ihr Team Ziele gut versteht, einschließlich des Ziels der Selbstverbesserung
  • Belohnen - Belohnen - auch wenn nichts mehr als Kommunikation - das verstärkt, was Sie erreichen möchten

Sozialisierung und gemeinsames Ziel fördern immer den Austausch von Informationen.

    
___ answer687536 ___

Ich arbeitete in einer Firma, wo wir jeden Freitag Mittagstreffen für Entwickler hatten. Das Management würde Essen bereitstellen, während die Entwickler ihr Wissen teilen mussten. Präsentieren Sie ein Werkzeug oder eine Technik, die Sie kürzlich gelernt haben, oder geben Sie eine Demo eines Projekts, an dem Sie gerade arbeiten, usw. Es war nicht auf die Technologien beschränkt, die das Team zu dieser Zeit nutzte, die Entwickler wurden ermutigt, neue Technologien zu lernen und dem Team eine Demo zu geben.

Und bei meiner jetzigen Arbeit haben wir monatliche IT-Gruppentreffen, bei denen Entwickler von verschiedenen Teams manchmal die Projekte vorführen, an denen sie gearbeitet haben.

    
___
6
Antworten

Tools zur Paarprogrammierung, die nicht remote sind

Ich bin gerade in einem Job, in dem wir ernsthafte Paar-Programmierung auf Windows-Maschinen üben. Wir haben beide eine Reihe von Tastaturen und Mäusen, und wir haben zwei Monitore, die gut funktionieren, um zu wechseln, wer der Treiber wirklich...
27.03.2010, 05:08
16
Antworten

Bedeutet Pair-Programmierung, dass Sie keine Design-Dokumentation benötigen?

Bei der Paarprogrammierung kann die Erfahrung jedes Teammitglieds auf neue Mitglieder übertragen werden. Diese Erfahrung ist immer synchron mit dem Code, weil der "Senior" des Paares weiß, wie der Code funktioniert und was das Design ist. Was...
06.04.2009, 14:40
10
Antworten

Information / Wissensfluss innerhalb des Teams [geschlossen]

Ich möchte die Situationen vermeiden, in denen meine Entwickler das gemeinsame Wissen (Lösungen für die aufgetretenen Probleme, coole Tipps, häufige Fehler, Verknüpfungen zum Erreichen bestimmter Ziele, Konfigurationsprobleme, Teilanforderungen...
26.03.2009, 20:51