开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《舍近求远 img2css》
今日推荐英文原文:《4 ways developers can have a say in what agile looks like》

今日推荐开源项目:《舍近求远 img2css》传送门:GitHub链接
推荐理由:如何在一个 HTML 页面中插入一张图片呢?除了 img 之外,还有一些令人不解的方式,比如说拿 css 把这张图强行画出来。这个项目就提供了这样的转换功能:上传一张图片,它会用 css 将其画出来,结果实际上意外的还挺像的,颜色形状都不算太偏,唯一的问题就是:生成的代码占的空间能达到原来图像大小的十倍左右……
今日推荐英文原文:《4 ways developers can have a say in what agile looks like》作者:Clement Verna
原文链接:https://opensource.com/article/19/10/ways-developers-what-agile
推荐理由:介绍敏捷开发的好处

4 ways developers can have a say in what agile looks like

How agile is implemented—versus imposed—plays a big role in what developers gain from it.

Agile has become the default way of developing software; sometimes, it seems like every organization is doing (or wants to do) agile. But, instead of trying to change their culture to become agile, many companies try to impose frameworks like scrum onto developers, looking for a magic recipe to increase productivity. This has unfortunately created some bad experiences and leads developers to feel like agile is something they would rather avoid. This is a shame because, when it's done correctly, developers and their projects benefit from becoming involved in it. Here are four reasons why.

Agile, back to the basics

The first way for developers to be unafraid of agile is to go back to its basics and remember what agile is really about. Many people see agile as a synonym for scrum, kanban, story points, or daily stand-ups. While these are important parts of the agile umbrella, this perception takes people away from the original spirit of agile.

Going back to agile's origins means looking at the Agile Manifesto, and what I believe is its most important part, the introduction:
We are uncovering better ways of developing software by doing it and helping others do it.
I'm a believer in continuous improvement, and this sentence resonates with me. It emphasizes the importance of having a growth mindset while being a part of an agile team. In fact, I think this outlook is a solution to most of the problems a team may face when adopting agile.

Scrum is not working for your team? Right, let's discover a better way of organizing it. You are working in a distributed team across multiple timezones, and having a daily standup is not ideal? No problem, let's find a better way to communicate and share information.

Agile is all about flexibility and being able to adapt to change, so be open-minded and creative to discover better ways of collaborating and developing software.

Agile metrics as a way to improve, not control

Indeed, agile is about adopting and embracing change. Metrics play an important part in this process, as they help the team determine if it is heading in the right direction. As an agile developer, you want metrics to provide the data your team needs to support its decisions, including whether it should change directions. This process of learning from facts and experience is known as empiricism, and it is well-illustrated by the three pillars of agile.

Unfortunately, in most of the teams I've worked with, metrics were used by project management as an indicator of the team's performance, which causes people on the team to be afraid of implementing changes or to cut corners to meet expectations.

In order to avoid those outcomes, developers need to be in control of their team's metrics. They need to know exactly what is measured and, most importantly, why it's being measured. Once the team has a good understanding of those factors, it will be easier for them to try new practices and measure their impact.

Rather than using metrics to measure your team's performance, engage with management to find a better way to define what success means to your team.

Developer power is in the team

As a member of an agile team, you have more power than you think to help build a team that has a great impact. The Toyota Production System recognized this long ago. Indeed, Toyota considered that employees, not processes, were the key to building great products.

This means that, even if a team uses the best process possible, if the people on the team are not comfortable working with each other, there is a high chance that the team will fail. As a developer, invest time to build trust inside your team and to understand what motivates its members.

If you are curious about how to do this, I recommend reading Alexis Monville's book Changing Your Team from the Inside.

Making developer work visible

A big part of any agile methodology is to make information and work visible; this is often referred to as an information radiator. In his book Teams of Teams, Gen. Stanley McChrystal explains how the US Army had to transform itself from an organization that was optimized on productivity to one optimized to adapt. What we learn from his book is that the world in which we live has changed. The problem of becoming more productive was mostly solved at the end of the 20th century, and the challenge that companies now face is how to adapt to a world in constant evolution.

I particularly like Gen. McChrystal's explanation of how he created a powerful information radiator. When he took charge of the Joint Special Operations Command, Gen. McChrystal began holding a daily call with his high commanders to discuss and plan future operations. He soon realized that this was not optimal and instead started running 90-minute briefings every morning for 7,000 people around the world. This allowed every task force to acquire the knowledge necessary to accomplish their missions and made them aware of other task forces' assignments and situations. Gen. McChrystal refers to this as "shared consciousness."

So, as a developer, how can you help build a shared consciousness in your team? Start by simply sharing what you are working on and/or plan to work on and get curious about what your colleagues are doing.
下载开源日报APP:https://openingsource.org/2579/
加入我们:https://openingsource.org/about/join/
关注我们:https://openingsource.org/about/love/