'

Happier Teams Through Tools

Понравилась презентация – покажи это...





Слайд 0

Happier Teams Laura Frank @rhein_wein Software Engineer @codeship


Слайд 1

Happy people are productive people.


Слайд 2

Happiness and Productivity


Слайд 3

Can a team’s choice of tools make developers happy, and therefore more productive?


Слайд 4

Yes. (duh)


Слайд 5

Each process and tool impacts how developers spend their time.


Слайд 6

The Happiness Equation


Слайд 7


Слайд 8

University of Warwick Study • People treated with positive stimuli were, on average, 12% more productive than the control group • People treated with negative stimuli were similarly less productive • Still, hard to quantify what we consider ‘negative’ and ‘positive’ • tinyurl.com/warwickhappiness


Слайд 9

Track Your Happiness


Слайд 10

Happiness Metrics • How do you feel? • What are you doing right now? • Do you have to be doing what you’re doing? • How productive are you being right now? • Do you want to do what you’re doing?


Слайд 11

Time-based pressure is nearly universally negative


Слайд 12

Fun Fact Commuting to and from work is typically the unhappiest time in a person’s day


Слайд 13

The Real Happiness Equation happiness = autonomy + no interruptions + no time pressure


Слайд 14

“The driving force seems to be that happier workers use the time they have more effectively, increasing the pace at which they can work without sacrificing quality.” – DR DANIE L SG ROI , UNIVE R SIT Y OF WARWICK


Слайд 15

There are several areas within development where we can maximize for happiness ✨


Слайд 16

Team Communication


Слайд 17

Employees report feeling stressed when they are either being unproductive or interrupted


Слайд 18

All incoming communication needs to have a process behind it.


Слайд 19


Слайд 20

Centralized Manager (Pivotal, Trello, Jira, ZenDesk etc)


Слайд 21

Treat your task manager as a means for persistent communication


Слайд 22

Remember that commuting to and from work is typically the unhappiest time in a person’s day?


Слайд 23

Persistent communication is essential to a remote team.


Слайд 24


Слайд 25

A clear, persistent record of business decisions.


Слайд 26

This type of communication is ‘pullbased’. You can choose when to consume it and it’s not as disruptive unless you allow it to be.


Слайд 27

Meetings ಠ_ಠ


Слайд 28

“This meeting could have been an email.” – E VERY P ER SO N EVER


Слайд 29

Unnecessary meetings are disruptive and expensive


Слайд 30

Meetings are good for complex discussion… But they go against the pattern of persistent communication.


Слайд 31

You MUST document the discussion and outcome of a meeting if you intend to have a team that can function remotely.


Слайд 32

My team uses Google Docs in place of many meetings.


Слайд 33


Слайд 34

Choose one mode of communication only Try to make it as least disruptive as possible Document the discussion and outcomes


Слайд 35

Architecture Patterns


Слайд 36

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” – M E LVIN CO NWAY


Слайд 37

Conway’s Law Any piece of software reflects the organizational structure that produced it


Слайд 38

If you have three engineering teams working on one piece of software, you’ll probably end up with three pieces of software


Слайд 39

super-cool application


Слайд 40

super-cool subsystem super-cool subsystem super-cool subsystem


Слайд 41

The interaction between components reflects how well teams communicate.


Слайд 42

Similarly, a unified team will selfseparate to tackle a problem with discrete components.


Слайд 43

super-cool service super-cool service super-cool service


Слайд 44

super-cool service super-cool service super-cool service


Слайд 45

In a SOA or microservices architecture pattern, each of the services is autonomous and can operate independently


Слайд 46

A service team can choose the correct tools — like languages, deployment processes, and incident management systems — specific to their component


Слайд 47

The pattern for people and the pattern for software mirror one another. Conway’s law in action


Слайд 48

Smaller teams with a targeted focus have autonomy over the software they build. autonomy happiness


Слайд 49

Continuous Deployment


Слайд 50

A human-initiated and monitored deployment is a huge disruption, distractor, and demotivator.


Слайд 51

Deployment should be an automatic step triggered by a change to a designated branch in your repo.


Слайд 52

We call this Repository-Driven Deployment.


Слайд 53

push Dev Team automated tests feature review and merge continuous delivery master review and merge production timed release


Слайд 54

push Dev Team automated tests feature review and merge continuous delivery master review and merge production timed release


Слайд 55

• The team shares responsibility for deployment, and each engineer is empowered to control the flow of his or her code into production • Your customers are always getting the best product you have to offer


Слайд 56

“Embrace the green button, Laura.” – NICK GAUT HIE R , CO DE SHIP


Слайд 57

I hate(d) the green button.


Слайд 58

If the checks pass, merge it. From bed. Or from the U-Bahn. Or wherever.


Слайд 59

Incident Management


Слайд 60

Interruption is sometimes necessary…


Слайд 61

Don’t confuse priority with urgency


Слайд 62

Priority measures how important a task is, relative to other tasks.


Слайд 63

Urgency is a measure of how quickly the task must be completed.


Слайд 64

A P0 incident is urgent, and communication for this incident requires interrupting people in order to accomplish the task


Слайд 65

“You pay for urgency with interruption; and you should understand whether or not you are getting a good deal.” – NICO APP E L, T IGHTOPS.COM


Слайд 66

Have policies, training, and docs that allow each developer to solve incidents assigned to them.


Слайд 67

Incident


Слайд 68

With a better system in place, I can have more autonomy and reduce the duration of the interruption


Слайд 69

Incident


Слайд 70

“If an engineer is on call, make sure he or she has access to logs, metrics, and the ability to deploy new code to production.” – CAP TAIN O BVIO US


Слайд 71

#alwayskeepshipping


Слайд 72

thanks!


Слайд 73


×

HTML:





Ссылка: