每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，歡迎關注開源日報。交流QQ群：202790710；微博：https://weibo.com/openingsource；電報群 https://t.me/OpeningSourceOrg
今日推薦開源項目：《Flutter 的回合 awesome-flutter》傳送門：GitHub鏈接
推薦理由：Flutter 是一個用於開發移動應用的 SDK，現在已經擁有了 45K 的 star 數，可以說不少人都對它有過了解了。這個列表就是在 Flutter 上用的上的庫，工具或者教程的集合，如果你正好在使用 Flutter 的話，這個列表裡的東西會幫上你的忙。
今日推薦英文原文：《Three drawings I use to explain agile》作者：Michael Williams
原文鏈接：https://medium.com/swlh/three-drawings-i-use-to-explain-agile-9c0ef15b64b8
推薦理由：敏捷開發相信各位都聽說過了，這篇文章中作者使用了三幅圖來解釋敏捷
Three drawings I use to explain agile
Sometime in grade school, I had an epiphany.
I discovered that my memory for numbers, dates, and equations was average at best, but my memory for images and stories was fantastic. If I found a way to represent something visually there was a pretty good chance I would remember it forever. If not, ?.
What started as a study hack quickly became my default way to absorb and retain knowledge. Whether it』s machine learning algorithms, statistical concepts, or organizational design, visualizations are a huge part of how I interpret and internalize the world.
For the past couple of years, I』ve been coaching product leaders and product teams trying to transform the way a giant organization works. We talk about things like communicating priorities, why iterative development is important, and how to balance tech debt versus refactoring. When those concepts come up, I draw out my mental model of that idea and it (almost) always helps us communicate much more effectively.
Here are a few of the drawings I make over and over again.
Small, frequent releases are safer than big, infrequent releases.
Most companies (particularly big established ones) operate a lot more like the red line than the blue. They let work build up over time and only release infrequently. Sometimes it』s because they have some technology that inhibits them from releasing more often. Sometimes it』s a cultural thing. But regardless of the cause, they don』t ship as often as they could.
Delaying releases increase risk. There』s the risk of bugs, the risk that priorities change and you have to throw the code out before it ships, and the risk of having built completely the wrong thing. Shipping early and often is an antidote to those risks.
With small releases, it can seem like you have problems more often. But those problems will be minor and manageable instead of big and ugly. If you let work build up before releasing, then you risk problems that are an order of magnitude worse.
Faster releases = lower risk.
Iterations
Iterative improvements beat big bets.
Big bets are exciting. They feel great to announce and watching people rally around an idea is super satisfying. But, as anyone who』s tried something new knows, it』s pretty hard to get it right on the first try. Big, inflexible bets often cause more problems than they solve.
To illustrate this idea, I like to use a golf metaphor. (The worst offenders of this fallacy tend to be big fancy executives so using golf makes the snarky party of my brain all warm and fuzzy.)
Imagine you』re playing golf on a dim, damp, foggy morning. You know the hole is somewhere to the east but you』re not sure exactly where. To complicate matters, your absentminded caddy forgot all but one of your clubs.
Would you rather have a driver (big, powerful, decisive, can cover lots of distance with ease) or a putter (puny, timid, can only hit the ball a few feet at a time)?
In this thinly veiled metaphor, most people pick the driver. They spend hours bashing the ball around a hundred yards per swing trying to get closer and closer to the hole. They overshoot it, turn around, redirect, and try again. After a few dozen swings most people give up, call the ball close enough, and retreat to the clubhouse for a consolation drink.
Meanwhile, the people who pick the putter are slowly chipping away at the distance to the hole, making constant small adjustments to direction. Once they get close enough to see the hole clearly it』s a simple matter of tapping it in. The putter may look inefficient in the short-term but long-term it』s much better.
In the long run, small, incremental improvements to a product are a much more efficient path to success.
Backlogs & Story Sizing
Well-sized stories mean less wasted work.
A lot of the teams I coach are used to working on gigantic hunks of work. For those teams, a single task might take weeks or months to accomplish. That』s fine if priorities never shift but in an agile environment, priorities tend to move around a lot (Responding to change over following a plan). And when priorities shift, work in progress gets paused or thrown out. That』s how it should work. Teams should always focus on the most important things. But all of that shelved and tossed work leads to a lot of waste.
One way to limit waste is controlling how quickly priorities can change. If you』ve ever heard 「that』s not in scope for our next sprint」 you』ve heard this approach in action. Locking scope does a good job of limiting waste but it comes at the cost of flexibility. For most teams, that cost is too high.
A five-minute copy change should never take four weeks and a formal prioritization process.
We can also approach waste from the other direction. Instead of trying to stop priorities from changing, we can focus on making priority shifts as painless as possible (Welcome changing requirements, even late in development). Appropriate story sizing is a fantastic way to do that.
Stories should be as small as possible while having some self-contained nugget of customer value.
If a story is too big when priorities shift you』ll have invested a bunch of time into work that can』t be put into production. If a story is too small, when priorities shift you』ll be left with a bunch of work fragments that are 「done」 but not useful without more time.
Well-sized stories keep your work in progress small, your level of risk low, and your teams nimble.
Are these visuals helpful?
If so, let me know in the comments below or on twitter. If the feedback is positive, I』ll write up a few of my other favorites.
每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，歡迎關注開源日報。交流QQ群：202790710；微博：https://weibo.com/openingsource；電報群 https://t.me/OpeningSourceOrg
