Sollte ein Softwareunternehmen ein spezielles Team für Forschungs- und / oder Hilfsbibliotheken haben?

Ich arbeite in einem Unternehmen, das Webanwendungen für verschiedene Banken und einige kleinere E-Shops erstellt. Wir beschäftigen ungefähr 20 Entwickler und haben jeweils 4-5 Projekte in der Entwicklung. Unsere Entwicklungsteams interagieren nicht viel und viele der gleichen Probleme werden auf unterschiedliche Weise gelöst (gut bis schlecht).

Ich habe mich gefragt, ob es eine gute Idee für ein Unternehmen ist, ein Team von Programmierern zu haben, das nach aktuellen Frameworks forscht und kontinuierlich eine gemeinsame Bibliothek von Funktionen und ein gemeinsames Framework verbessert, um aktuelle und zukünftige Projekte viel schneller und effizienter zu erstellen.

Wie groß sollte ein solches Team sein?

Sollte es auch ständige Mitglieder haben, die andere ausbilden, oder sollte es Leute drehen?

Update: Ich habe über ein gemeinsames Projekt nachgedacht, an dem die Leute zum Spaß arbeiten können und das Interesse wecken könnte. Es scheint, dass die Lösungen, die sie finden, nicht die besten sind, wenn die Menschen unter Arbeitsdruck stehen.

Ein wichtiger Punkt ist, dass es unmöglich ist, ein gutes Framework in völliger Isolation zu entwickeln. Gute Frameworks sind organisch gewachsen : Wenn ein Programmierer feststellt, dass er eine bestimmte Funktionalität benötigt, fügt er diese dem Framework hinzu, und so wächst das Framework nach und nach - im Gegensatz zur Entwicklung eines "perfekten Frameworks" im Voraus, das niemals funktioniert, weil Der Architekt kann nicht wissen, dass irgendwann Anwendungsfälle auftauchen.

Natürlich hat der organische Anbau des Frameworks den Nachteil, dass seine innere Integrität möglicherweise nicht allzu gut ist und sich in Spaghetti verwandelt. Wenn Ihr Team eine gute interne Kommunikation aufrechterhält, können Sie möglicherweise das Beste aus beiden Welten kombinieren: Ein separates Architektenteam, das die Integrität des Frameworks beibehält, jedoch auf die tatsächlichen Bedürfnisse der Endbenutzer (Entwickler) aufbaut.

Mein Gefühl ist nein.

Ich vermute, dass Sie in diesem Fall feststellen würden, dass anstelle einzelner Teams, die Bibliotheken produzieren, die niemand außerhalb des Teams verwendet, ein spezialisiertes Team Bibliotheken produziert, die niemand außerhalb des Teams verwendet (und dies auch tut) zu erheblichen Mehrkosten).

Es gibt verschiedene Probleme mit der Art von Team, die Sie beschreiben, aber für mich ist die Hauptsache, dass es nicht das Problem anspricht, das Sie tatsächlich haben.

Das Problem, das Sie haben, ist nicht, wer die Bibliotheken produziert (nach den Klängen von Dingen, die Sie bereits für diese Probleme haben, wie kann man Ihnen weiterhelfen?), Sondern, dass die Teams nicht miteinander reden und interagieren.

Es gibt gute Gründe, warum Teams den Code der jeweils anderen nicht wiederverwenden (zum Beispiel, dass die Probleme, obwohl sie sich oberflächlich ähneln, geringfügig voneinander abweichen oder dass das Timing des Projekts nur die zusätzliche Abhängigkeit der gemeinsamen Entwicklung von etwas nicht zulässt), aber Sie müssen dies tun Schau dir an, wie du sie zur Interaktion bringen kannst, wenn es möglich ist.

Ich würde vorschlagen:

• Teams zwischen Projekten wechseln
• Halten Sie zwischen Team Mittagessen und Diskussionsgruppen
• Post-Projekt-Reviews über die Art und Weise, wie Probleme gelöst wurden (von den anderen Teams besucht)
• Richten Sie einen Bereich des Wiki-Gliederungscodes ein, der wiederverwendbar sein kann (und mit wem Sie darüber sprechen können).
• Denken Sie darüber nach, einen Anreiz für eine gute Wiederverwendung zu schaffen - zahlen Sie den Menschen tatsächlich extra dafür. Wenn die Wiederverwendung einer Komponente 5 Tage spart und 2000 US-Dollar kostet, geben Sie dem Team am Ende des Projekts 200 US-Dollar des jetzt zusätzlich erzielten Gewinns für eine Auszeit (wenn Sie die Echtheit der Einsparung bestätigt haben).

Ein Bibliotheksteam wäre, wie ich vermute, ohne Nutzen.

In Bezug auf ein gemeinsames Projekt, an dem Entwickler zum Spaß arbeiten - kein Unternehmen sollte sich darauf verlassen, dass Programmierer in ihrer Freizeit an Dingen arbeiten. Das sind nur unbezahlte Überstunden und auf jeden Fall unzuverlässig, da es wahrscheinlich große Zeiträume geben wird, in denen niemand an Dingen arbeiten möchte.

Wenn Sie sagen, es wären Leute, die in der Zeit zwischen Projekten in der Firma arbeiten, dann kann es vielleicht funktionieren, aber ich denke immer noch nicht, dass es das eigentliche Problem ist. Sie müssen noch herausfinden, wie Sie die Benutzer dazu bringen, die Bibliotheken zu nutzen. Wie gesagt, Sie haben bereits Lösungen für diese Probleme, die für jedes Projekt entwickelt werden. Ihr Problem ist, warum sie nicht geteilt werden.

Das ist die Aufgabe eines Architekten .

Die Hauptaufgaben eines Software-Architekten umfassen:

• Einschränkung der während der Entwicklung verfügbaren Auswahlmöglichkeiten durch Auswahl einer Standardmethode für die Anwendungsentwicklung
• Erstellen, Definieren oder Auswählen eines Anwendungsframeworks für die Anwendung
• Erkennen der potenziellen Wiederverwendung in der Organisation oder in der Anwendung durch Beobachten und Verstehen der umfassenderen Systemumgebung
• Erstellen des Komponentendesigns Kenntnisse über andere Anwendungen in der Organisation

Erfahren Sie mehr über: - Softwarearchitekt - Lösungsarchitekt - Unternehmensarchitekt .

Das Sprichwort " Essen Sie Ihr eigenes Hundefutter " befasst sich mit diesem Problem. Wenn Ihr Top-Cool-Rockstar-Coder eine Bibliothek hervorbringt, die er in der Praxis nie benutzt hat, wie kann er dann sagen, dass es eine gute ist?

Die Hauptgründe für die Entwicklung von Funktionalitäten zu Frameworks sind:

1. Es ist nützlich für den
Entwickler 2. Es gibt einige Fälle, in denen es nützlich war
3. Es könnte für andere nützlich sein

Wenn Sie auf 2 geklickt haben, ist die Funktionalität bereits vorhanden. Wie können Sie sie an eine andere Person weitergeben?

Ich bin etwas spät dran, aber ich hatte das Gefühl, dass sich niemand darum kümmert:

Ihre einzelnen Teams, die unterschiedliche Probleme auf unterschiedliche Weise lösen, würden definitiv von der gemeinsamen Funktionalität profitieren, und es gibt eine Vielzahl von Möglichkeiten, dies auf eine Weise zu erreichen, die kein einziges Team der Entwicklung widmet, aber ich habe viel gesehen von Orten, die tun.

In den meisten Fällen wird dies als "Kern" Ihrer Produktlinie bezeichnet, und manchmal ist ein Team für die Wartung zuständig, das von einem Architekten geleitet wird (wie von Amir vorgeschlagen). Auf diese Weise können Sie in der Regel Wege finden, ein Framework zu nutzen oder zu erstellen, das den strengsten Standards entspricht, die Sie in Ihrem Unternehmen festgelegt haben, aber nur die unbedeutendsten Funktionen bereitstellt, die möglicherweise für die vollwertigen Anwendungen erweitert werden müssen oder nicht dass Ihre individuellen Produktteams bieten. Auf diese Weise haben Sie den Vorteil, dass Sie Ihren Kerncode "dogfooding" können, indem Sie ihn an jedem einzelnen Ort, an dem Sie ihn verwenden, implementieren und dann zu verschiedenen Produkten verzweigen, die möglicherweise völlig unterschiedliche Implementierungen haben. Auf diese Weise können alle Ihre Teams einen Beitrag zu den Kernbibliotheken leisten, ohne die Funktionalität einzuschränken, die nur sie benötigen.

Ich denke, das ist KEINE GUTE IDEE , denn damit Bibliotheken nützlich sind, müssen sie Ihnen helfen, echte Projektprobleme zu lösen, und Sie lernen sie nur dadurch kennen, dass Sie in echten Projekten arbeiten.

Ansonsten kann man mit einer "theoretisch" sehr guten Bibliothek abschließen!

Bei der einen Firma, bei der ich gearbeitet habe, war es wirklich ähnlich, es schien nicht gut zu funktionieren. Die Leute im inneren Team hatten eine gute Idee und einen Prototyp, der größtenteils funktionierte. Dann ging er über die Mauer und wir erwarteten, dass wir daraus ein Produkt machen würden.

Was ich erwartet hätte, wäre, dass die Tool-Gruppe ihr eigenes kleines Programm ausführt und Funktionen produziert, die nicht wirklich nützlich sind, aber die API überladen und ausreichend genutzt wurden, so dass sie nicht einfach zu bedienen sind entfernt. Sie würden nicht angemessen dokumentieren.

Wenn die Toolgruppe einem Systemarchitekten unterstellt ist, der in ständigem Kontakt mit den Personen steht, die die Tools tatsächlich verwenden, funktioniert dies möglicherweise. Wenn die Werkzeuggruppe häufig gedreht wird (was eine umfangreiche Außenforschung behindern würde), funktioniert dies möglicherweise. Ich hätte jedoch Angst, den Kontakt zu den Leuten zu verlieren, die die bezahlte Arbeit erledigen.

Wie viel Zeit werden Sie in die Diskussion investieren, ob die Verwendung des Frameworks in jedem Fall von Vorteil ist oder nicht? Verzögert sich ein Projekt, wenn es auf die Aktualisierung des Frameworks wartet? Irgendwann muss die Verwendung des Frameworks erforderlich sein, um seine Existenz zu rechtfertigen.