今日推荐开源项目：《猫言猫语 nyaruko_lang》
今日推荐英文原文：《Defining Software Project Success》
今日推荐开源项目：《猫言猫语 nyaruko_lang》传送门：GitHub链接
推荐理由：这个项目是一个新的编程语言——仅供娱乐，请勿拿去实际工作中使用。它允许你用极其不可思议的颜文字来编写程序，当然了实际编写出的东西会极其复杂，在试图娱乐时务必保证有充分的时间能够一次性编写完成——一旦你忘了你在写什么，就再也没人能知道了。
一段示例：(」・ω・)」うー(／・ω・)／にゃー(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!CHAOS☆CHAOS!(」・ω・)」うー!!(／・ω・)／にゃー!!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー!(／・ω・)／にゃー!(」・ω・)」うー(／・ω・)／にゃー(」・ω・)」うー!!!(／・ω・)／にゃー!!!I WANNA CHAOS!
今日推荐英文原文：《Defining Software Project Success》作者：Michael Krisher
原文链接：https://medium.com/swlh/i-want-to-share-some-thoughts-about-setting-software-projects-up-for-success-6e25ad44d55b
推荐理由：赚钱和成功实际上是两码事
Defining Software Project Success
I want to share some thoughts about setting software projects up for success. Success can mean many different things, so I’ll discuss a couple of meanings in this post. Mostly solid quality and team happiness, rather than budgets and timelines.
Photo by Austin Distel on Unsplash
I’ve been writing software for over two decades now. I’ve been a part of both successful and failed projects across a variety of topics. Everything from writing software for a smart TV remote, marketing sites for Kodak and P&G, search functionality, and most recently streaming data platforms with nearly a billion events per day at Nike. Regardless of the domain, some common traits stick out in my mind that impact the outcome of the project on the success or fail scale. I add a note below about team turnover as an outlier for measuring success. I won’t cover obvious things like costs and budgets. Most projects are simply measured by money to be determined successful. But is money the only factor? For this post, I am focused on things that can be done for the team to consider the project a success, not the CFO.
The first consideration is the size of the project. Not the number of lines of code, or even daily users. Size in this context means scope. Is the body of work trying to do too much from the beginning and setting the team up for failure? A report from the Standish Group in 2016 listed the size of a project as the top reason for succeeding or failing. From my experience, I completely agree.
Photo by Alvaro Reyes on Unsplash
Ideally, I like to see teams take the first couple of days of starting a new project to just write out user stories. I’ve been an individual contributor in these “planning” sessions, as well as lead them. The goal is to brainstorm all the little pieces that make up the project and catalog them via consistently formatted user stories. At the end of the exercise, you start your story mapping of the functionality and scope. You identify the various iterations and priorities. To me, the takeaway in all of this is the identification of functionality that is required for the first iteration. This breaks the entirety of the project down into small deliverable chunks of work. By narrowing the focus, even with knowing what comes next, you set the team up for success. They can hold the entire scope in their head and concentrate on delivering it. Not to mention the shared understanding. I’ll write a followup post on how much I value shared understanding. If each iteration is a success, it’s more than likely the entire project will be a success.
But what do we mean by success in this context? Is it simply shipping the first iteration? That seems like a success. Not shipping seems like a failure, assuming we are shipping the correct thing, but let’s assume we are. Shipping makes the team happy. That’s a success! Establishing the foundation and setting the project up for future iteration seems like a success. There are a lot of success definitions that can and should be celebrated. Breaking projects down into small deliverable pieces is key to making a project successful.
Let’s back up a bit though. Is simply taking the time to define the project first before you jump into it a beneficial step for success? I would say so. There have been too many times I’ve recognized where a sense of urgency meant skipping the essentially planning phase. It happens all the time. We receive a bug report, or there is some new functionality that needs to extend something as simple as the login form. A 15-minute meeting happens to describe the problem to at least one engineer and they go off to implement a solution. Without taking the proper time, maybe say an hour or two, to properly plan the “project”, meaning the scope, the result can be a failure. Maybe in the form of technical debt, maybe in the form of implementing the wrong thing.
Right after size of the scope of the project, I would list proper planning as a quick second factor to set projects up for success. As a manager, I am constantly reminding myself to identify when we as a team are being impulsive and jumping into some work without properly planning it and treating it as a project.
Now that we’ve covered proper planning and size of projects, let’s discuss having the right team to be successful. Teams take on many shapes and sizes. I’ve written about team roles in the past. I won’t discuss the various roles that can make teams successful, I’ll just mention the continuity of the team as being a different way to measure success. Simply shipping a project can’t be thought of as successful if the whole team quits in the months afterward. Hiring takes time and is costly and will impact the project. I’ve experienced this more than a few times. The start and stop and turnover always impacts the quality and therefore impacts the success of the project in my mind.
It’s easy for all of us to focus on the technical bits and the functionality requirements when starting a project, but how often do we ask ourselves what would make the project successful in the end, before we get started? Given the scenario, we define a project scope that is pretty straight forward and small but the engineer has no domain knowledge and takes 2 weeks versus 2 days to complete the project, is it still a success? Impulsively, we might say it was a failure because it took too long. But, maybe one of the “success” factors going into the project is to provide a learning opportunity in addition to the completion of the functionality. Without defining that ahead of time, it would be easy to say the project took too long and was a failure.
There are many ways beyond money and shipping that can play into the definition of success for a software project. Something I will be spending my efforts on in the near term is defining what success looks like before we even start a project. If you have a practice of defining what success looks like, I would be very interested in seeing it. As an industry, I think our definition of “success” or “failure” needs to be examined. Once we define success, we might get a little better at setting ourselves up for it.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/