今日推薦開源項目：《捨近求遠 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/
