今日推薦開源項目：《貓言貓語 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://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
還好沒有讓我唱《學貓叫》，只是寫寫貓語，今天項目很有意思。英文文章講的是怎麼才能說一個軟體項目是成功的？我自己也深有感觸。一些問題出在項目或者功能開始前，有沒有想清楚？一些問題出在執行過程中，缺乏堅強的執行力。總之，想做好一個項目，技術原因非技術原因都很多，不容易。