SHE-Blogpicks

Arbeitsplatzkultur remote?

Posted by in Allgemein

Diese Seite teilen:

Viele Büros werden heute so gestaltet, dass sie offene, hierarchiefreie und agile Arbeitsformen unterstützen: keine Trennwände, keine geschlossenen Türen, formelle und informelle Kommunikationsbereiche. Das funktioniert oft ziemlich gut. In Teams, die gar nicht räumlich zusammenarbeiten, müssen jedoch andere Regeln gelten, weil zum Beispiel eine bestimmte Arbeitsplatzkultur fehle, schreibt John Chen in Techcrunch. Er hat anhand der Teams, die die Open-Source-Projekte Basecamp und WordPress betreiben, untersucht, wie weltweit verteilte Arbeit funktioniert, was die Erfolgsfaktoren sind und worin die Schwierigkeiten bestehen. Bild: Symbolbild

0

Es muss nicht immer Slack sein

Posted by in Allgemein

Diese Seite teilen:

Slack gilt als eierlegende Wollmilchsau der Collaboration (Symbolbild). Außerdem: Wer die Plattform nutzt – ob Menschen oder Unternehmen –, präsentiert sich als dynamisch, flexibel  und innovativ. Dabei gebe es durchaus eine Kehrseite der glänzenden Medaille, wie Sonia Cuff in The Register schreibt. Den niedrigen Zugangsbarrieren (kostenfreie oder –günstige Nutzung, einfache Oberfläche) und nützlichen Features sowohl für Nerds als auch Nicht-Techniker stünden unter anderem das fehlende Back-up und die (kaum gesicherte) Datenspeicherung ausschließlich in den USA gegenüber. – Die Autorin hat sich mit Alternativen zu Slack befasst und bewertet sie. Darunter: einfach weiter E-Mail benutzen…

0

Wie agiles Arbeiten Nutzen bringt

Posted by in Allgemein

Diese Seite teilen:

Agile Methodik in Projektmanagement und Softwareentwicklung sind Mainstream. Probleme gibt es trotzdem: Unternehmenslenker beschweren sich, dass ihre Erwartungen nicht erfüllt worden seien, schreiben Diana Larsen (li.) und James Shore. Ein  „Fluency Model“, das sie als Gastautoren des Blogs von Martin Fowler präsentieren, soll Abhilfe schaffen. Das Modell sortiert die Verläufe agiler Projekte in vier Zonen ein: Fokussieren und Lernen, wo Projekte ihren geschäftlichen Wert haben. Liefern von nachhaltig funktionssicherer Software. Optimieren der Teamarbeit mit der Fähigkeit zur schnellen Reaktion auf sich ändernde Anforderungen des Marktes. Und schließlich die Köngisklasse: das Stärken agiler Strukturen durch die Zusammenarbeit mehrere agiler Teams.

 

0

Design Thinking: Was ist das Problem?

Posted by in Allgemein

Diese Seite teilen:

Agilität – schön und gut. Aber mit Design Thinking (Symbolbild) als zusätzlichem Hebel lassen sich Organisationen auf ein noch höheres Niveau der aktiven Problemlösung hieven, schreibt Ed Hadley in einem Gastbeitrag für die Information Week. Die beiden Ansätze ergänzen sich nach seiner Überzeugung ideal: Agiles Projektmanagement sorge für eine hohe Problemlösungsquote. Mit Design Thinking jedoch lasse sich vorab sicherstellen, dass man auch die wirklich relevanten Probleme angeht. – Die Methode beginnt mit der Beobachtung vorhandener Arbeits- und Kommunikationsprozesse und definiert dabei auftretende Probleme. Prototypische Problemlösungen werden dann in einem iterativen Prozess gegen ihre unmittelbaren Effekte auf die Arbeitsprozesse getestet – bis ein grundsätzlich funktionierender Lösungsansatz (Minimum Viable Product, MVP) gefunden ist.

0

Projekte? Es geht auch anders!

Posted by in Allgemein

Diese Seite teilen:

Projekte sind nicht der einzige Weg, Softwareentwicklung zu organisieren und zu finanzieren. Die Alternative seien Produktentwicklungen („product-mode“), schreibt Sriram Narayan (Bild) im Multiautoren-Blog von Martin Fowler. Demnach könnten permanente Teams – die dann allerdings über einen längeren Zeitraum betrieben und finanziert werden müssten – ebenso gut für Entwicklung und Support einer Software sorgen. Zwei Beispiele für Vorteile des Verfahrens – das in großer Ausführlichkeit erörtert wird: Noch mehr als (herkömmlichen) agilen Entwicklungsprojekten sei es im Product Mode ziemlich einfach, neue Ziele zu definieren. Darüber hinaus reduziere sich, selbst im Vergleich zu modernen DevOps-Organisationen, die Dauer einzelner Entwicklungszyklen, weil Entwicklungs- und Betriebsverantwortliche Bestandteile eines Teams seien.

0