大數據項目交付國標

by Paul McGillivray

保羅·麥吉里夫瑞(Paul McGillivray)

在緊迫的期限內交付大型Web項目 (Delivering a big web project for a tight deadline)

This week we launched the first phase of a large website for a fast-growing business, ‘Jump In’. The company was opening another new trampoline park this week, and wanted the website to go live beforehand. So our deadline was fixed, and we were committed to launching a full-fat, high class website in time for the launch.

本周，我們為快速發展的業務推出了大型網站“ Jump In”的第一階段。 該公司本周將開放另一個新的蹦床公園，并希望該網站能夠提前上線。 因此，我們的截止日期是固定的，因此我們致力于在發布之前及時啟動一個完整的高級網站。

With only two and a half weeks to build the site once the designs were approved, the whole team had to, er, jump in, and pull together to deliver a project we were proud of.

設計獲得批準后，僅用了兩個半星期的時間就建立了站點，整個團隊不得不，很費力，參與進來并共同完成了我們引以為傲的項目。

This was the first ‘under fire’ test for our newly-rebuilt team here at Remote, so it was a good process and we learned a lot about how we work together and how our new workflow performs under pressure.

這是對我們在Remote的新組建的團隊的第一個“測試中”測試，因此這是一個很好的過程，我們了解了很多有關我們如何合作以及如何在壓力下執行新工作流程的知識。

I thought it would be helpful to share the points that helped us stay on track and launch on time.

我認為分享有助于我們按時完成并按時啟動的觀點會有所幫助。

優先考慮您的用戶故事 (Prioritize your user stories)

For all our projects, we use the classic User Story backlog with a Kanban board for our task management. Being a .NET development company, we’ve inevitably ended up using Visual Studio Team Services, which we’ve found to be intuitive, simple, and powerful. In the past we’ve worked with TargetProcess, ActiveCollab, and most recently Jira, before moving to VSTS.

對于我們所有的項目，我們使用經典的用戶案例積壓和看板來完成任務管理。 作為.NET開發公司，我們不可避免地最終使用了Visual Studio Team Services，我們發現該服務直觀，簡單且功能強大。 過去，在遷移到VSTS之前，我們曾與TargetProcess ， ActiveCollab和最近的Jira合作。

We make sure that our User Story backlog is always in priority order. With our hearts happily committed to the Agile Manifesto, those priorities are our customer’s business priorities, and not our development priorities.

我們確保用戶案例積壓工作始終處于優先順序。 我們衷心地致力于敏捷宣言，這些優先事項是我們客戶的業務優先事項，而不是我們的發展優先事項。

What this means is that although we might really feel like we’d like to build the entire business layer for the whole project upfront to make our lives easier further down the road, the business layer in itself doesn’t offer any value to our client — they don’t want a business layer, they want their customers to click a ‘Book Now’ button that works, or to fill in a ‘Contact Us’ form that posts to the Constant Contact API.

這意味著，盡管我們可能真的覺得我們想為整個項目預先構建整個業務層，以使我們的生活更輕松，但是業務層本身并沒有為客戶提供任何價值。 —他們不需要業務層，他們希望客戶單擊可以正常工作的“立即預訂”按鈕，或填寫發布到Constant Contact API的“聯系我們”表單。

So we name and prioritize our tasks accordingly, with the most pressing business requirement at the top, and the business layer is naturally built on an ‘as-needed’ basis.

因此，我們以最緊迫的業務需求為首，對任務進行相應的命名和優先排序，并且業務層自然是在“按需”基礎上構建的。

We get three obvious benefits from this method:

通過這種方法，我們可以獲得三個明顯的好處：

We don’t find ourselves building architecture for features that are never built, or features that are never used.

我們不會發現自己為從未構建或從未使用過的功能構建體系結構。

If the client needs to swap out a feature in the backlog for a suddenly-more-urgent one, we haven’t wasted any development time in preparing for that feature.

如果客戶需要將積壓的功能換成急需的功能，我們就不會浪費任何開發時間來準備該功能。

If for whatever reason, the client needs to launch early, or runs out of money and can’t continue the development (although that’s never actually happened to us), the project will have already been built with the most important features, and those left behind will be the ones that don’t matter so much.

如果出于某種原因，客戶需要及早啟動，或者資金耗盡，無法繼續開發(盡管這對我們來說從來沒有發生過)，那么該項目已經具有最重要的功能，而那些功能后面將是無關緊要的那些。

It’s a comforting and efficient way of working.

這是一種舒適而有效的工作方式。

建立提前檢查清單 (Build an in-advance checklist)

In the heat of the moment, hours from deadline, it can be easy to forget the small things that are still essential to getting a project launched.

在距離截止日期數小時的緊張時刻，很容易忘記那些對于啟動項目仍然必不可少的小事情。

Building a checklist right at the start of the project can help you keep focus in the heat of battle, and also might give you a pointer about what you might be able to do early, before the pressure mounts. Items that are relatively unimportant and small when it comes to development can mean big trouble later down the line if they’re forgotten; stuff like Google Analytics tracking code, and 301 redirects from pages on the old site, to their new replacements.

在項目開始時建立清單，可以幫助您將重點放在戰斗中，也可以為您提供在壓力增加之前可以盡早完成工作的指示。 對于開發而言相對不重要且較小的項目，如果忘記了，可能會帶來很大的麻煩。 諸如Google Analytics(分析)跟蹤代碼之類的內容，以及301從舊網站上的頁面重定向到新的替換頁面。

We created user story tasks for each item, and put them at the bottom of the backlog, so that once all the main features were uploaded and tested, we knew that these jobs also had to be done before launch.

我們為每個項目創建了用戶故事任務，并將它們放在積壓的底部，因此，一旦所有主要功能都上傳并進行了測試，我們知道在發布之前也必須完成這些工作。

There are some great web checklists available online which might help you think of what you might need to include.

網上有一些很棒的網絡清單，可以幫助您考慮可能需要包括的內容。

http://frontendchecklist.io is an open source project created by David Dias that’s incredibly comprehensive and trending highly on GitHub at the moment, with lots of community contributions. The Humaan Website checklist is both pretty and comprehensive, as is webdevchecklist.com

http://frontendchecklist.io是由David Dias創建的一個開源項目，該項目非常全面，目前在GitHub上非常流行，并做出了很多社區貢獻。 Humaan網站核對清單既漂亮又全面， webdevchecklist.com也是如此

Tom Houdmont has a very detailed and useful article on box UK on things to remember. And if you want to go deep, the ever-excellent Smashing Magazine has a list of no less than 45 Website Checklists to cover every web specialty.

湯姆·霍蒙(Tom Houdmont) 在Box UK上有一篇非常詳盡且實用的文章，內容值得記住。 而且，如果您想深入了解，則非常出色的Smashing Magazine列出了不少于45個網站清單 ，涵蓋了每個Web專業。

預先獲取重要信息 (Get important information up-front)

Now that we have our end-of-phase checklist, we know what we’ll need to know before launch. It’s really helpful to get any information or resources that you’re missing right away, so that you don’t forget to ask in the heat of the action further down the line.

現在我們有了階段結束清單，我們知道在發布之前需要知道的內容。 立即獲取您丟失的任何信息或資源，這真的很有幫助，這樣您就不會忘記在下一步的工作中進行詢問。

Take it from me, there’s nothing so disheartening as working your guts out to meet a project deadline, only to realize at the very last minute that you didn’t get a copy of the SSL certificate for the new site, and will have to wait hours for a new one to be processed because the client’s IT manager doesn’t have a copy of the private key.

從我這里拿走，沒有什么比讓您膽量大到趕上項目截止日期令人沮喪的了，直到最后一刻才意識到您沒有獲得新站點的SSL證書的副本，并且必須等待一個小時要處理一個新密鑰，因為客戶的IT經理沒有私鑰的副本。

DNS login details, Google analytics ID, SSL certificate, and any other documents, images and any other resources you might need during the project development — anything you can get right upfront might save you hours later when it matters.

DNS登錄詳細信息，Google Analytics(分析)ID，SSL證書，以及在項目開發過程中可能需要的任何其他文檔，圖像和任何其他資源-您可以直接獲得的任何內容都可以在事后節省數小時。

不要讓范圍蠕動破壞您的截止日期 (Don’t let scope-creep destroy your deadline)

When the client begins to see the project developing, new and previously-unscoped ideas can come in thick and fast. From suggestions for a new way of displaying data, to whole new features and sections that had previously been forgotten and omitted from the spec, it can be tempting to see the new must-have, and down-tools to add it to the project. That’s fine, but let’s remember the most important thing first.

當客戶開始看到項目正在開發時，新的和以前未曾討論過的想法會Swift出現。 從關于顯示數據新方法的建議，到以前在規范中被遺忘和遺漏的全新功能和部分，很容易看到新的必備功能以及將其添加到項目中的工具。 很好，但是首先讓我們記住最重要的事情。

There’s an old saying in the software development world: “Quality, Budget, or Time: pick any two”. We don’t like that. We don’t ever want to compromise on quality, go over budget, or miss a deadline. So we add a third: Scope.

在軟件開發界有句老話：“質量，預算或時間：任意選擇兩個”。 我們不喜歡那樣。 我們永遠都不想在質量上做出妥協，超出預算或錯過最后期限。 因此，我們添加了第三個：范圍。

So we keep our quality, we stick to budget, and we meet our deadline, but what’s delivered on that deadline is continually up for discussion and consideration.

因此，我們保持質量，遵守預算，并在截止日期之前完成任務，但是在該截止日期之前交付的內容仍在不斷討論和考慮中。

So when a client asks for a new feature — mid-development — that will for example take half a day to build, we reply “certainly — which feature would you like to remove from the release to make way for this new feature?”

因此，當客戶要求開發一個新功能(例如開發中)時，例如可能要花半天的時間，我們會回答“肯定地-您想從發行版中刪除哪個功能，以便為該新功能讓路？”

The resultant discussion will make sure that the client is focusing on their priorities, and will help inform them whether that new idea is worthy of the current release or whether it should be held off for a future phase. By keeping control of the scope, we keep the other values (and our evenings) protected. Which leads me nicely to my next point:

由此產生的討論將確保客戶專注于他們的優先事項，并將幫助告知他們該新想法是否適合當前版本，或者是否應推遲到以后的階段。 通過控制范圍，我們可以保護其他值(和我們的夜晚)。 這很好地引出了我的下一個觀點：

保持高質量 (Keep quality high)

New features are built and uploaded quickly as the deadline approaches, and we can easily forget to test as thoroughly as we would normally. And quality control for stylesheets and interactions can just as easily be compromised.

新功能會隨著截止日期的臨近而快速構建和上載，我們很容易忘記像往常一樣進行徹底的測試。 樣式表和交互的質量控制同樣容易受到影響。

I’d much rather spend that extra time when I’m in the code for a feature to make sure I’m going to deliver it properly — looking as it should, working as it should, with the correct stylesheets and appropriate validation on forms and so on.

我寧愿花一些額外的時間在功能代碼中，以確保我能夠正確交付它-看起來應該正確，應該正常工作，使用正確的樣式表并在表單上進行適當的驗證等等。

I’m not saying we should over-build and write code that’s not required, but it’s much nicer to spend the time doing it right than having to go back and look at it again at the client’s request when I’m much closer to the deadline. It’s stressful, and I don’t need that kind of negativity in my life, thank you.

我并不是說我們應該過度構建和編寫不需要的代碼，但是花些時間正確地做起來比在我離客戶越來越近時不得不回頭再看客戶的請求要好得多。最后期限。 壓力很大，我一生都不需要這種消極情緒，謝謝。

Keep it lean, keep your patterns in check, write your tests, and do your QA. First time, not when it’s about to launch — or worse, after it’s launched!

保持精益，檢查模式，編寫測試并進行質量檢查。 第一次，不是在它即將發布時-或更糟糕的是，在它發布后！

不要在壓力下失去流程 (Don’t lose your process under pressure)

Flowing from what I’ve just been saying, as well as keeping your code clean, it’s important to keep your project management process in place when you’re under fire too, especially if you’re working in a team.

從我剛才講的內容以及保持代碼的簡潔性來看，重要的是在遇到麻煩時也要保持項目管理流程到位，尤其是在團隊中工作時。

I’ve totally been there — I’m running out of time, and so instead of adding my user stories to the VSTS backlog, I write a little checklist in Notepad++ or Todoist (my new favorite productivity tool). Before I know it, none of the team knows what tasks I’m working on, no one knows what tasks have been done, and another one of the dev team are working on something I’ve already fixed.

我已經去過那里了-我時間不多了，所以我沒有在VSTS待辦事項列表中添加用戶案例，而是在Notepad ++或Todoist (我最喜歡的新生產力工具)中編寫了一個清單。 在不知不覺中，沒有一個團隊知道我正在執行的任務，沒有人知道已經完成了哪些任務，而另一個開發團隊正在研究我已經解決的問題。

Stick to the process — there’s a reason it’s in place, or you’ll end up slowing down by trying to go more quickly.

堅持這一過程-這是有原因的，否則您將試圖加快速度而最終減慢速度。

There’s a fantastic book about this called ‘Work Clean: The Life-Changing Power of Mise-En-Place to Organize Your Life’ by Dan Charnas. In the book, Charnas talks about ‘Slowing Down to Speed Up’ — taking time to make sure everything is prepared and processes are in place actually helps you reach a much faster productivity speed when you’re in the flow. Give it a try, and check out the book, too; I loved it.

丹·查納斯(Dan Charnas)有一本很棒的書，名為“ 干凈的工作：在Mise-En-Place組織生活的改變人生的力量” 。 在書中，Charnas談論了“放慢速度以加快速度”-花時間確保一切準備就緒并且流程到位實際上可以幫助您在流程中更快地提高生產率。 嘗試一下，也可以檢查一下這本書； 我愛它。

確保您清楚“完成”的定義 (Make sure you’re clear on your definition of “done”)

User stories are, by their definition, usually short and concise. We ensure that our agile-inspired project management doesn’t turn into a simple waterfall in short cycles by discussing each story when it’s due to be done, instead of speccing it out weeks in advance in full detail.

根據其定義，用戶故事通常簡短明了。 我們確保通過敏捷的項目管理在短周期內不會變成簡單的瀑布，方法是在每個故事即將完成時進行討論，而不是提前幾個星期詳細說明。

The downside of this is that a developer who’s not been involved in the scoping and specification process won’t have the full background on a user story when they pick it from the top of the list. If everyone’s got their head down on their own stories as the deadline draws near, it might be tempting for the developer to just get on with the task.

不利的一面是，未參與范圍界定和規格制定過程的開發人員從列表頂部選擇用戶故事時，將不會具有完整的用戶故事背景。 如果在截止日期臨近時每個人都對自己的故事不屑一顧，那么開發人員可能會著手完成任務。

Now in many cases, a simple and concise user story will be easy to interpret. But in other cases, the developer could find themselves down a rabbit hole, working on tasks that simply don’t need to be completed by the deadline.

現在，在許多情況下，簡單明了的用戶故事將易于解釋。 但是在其他情況下，開發人員可能會發現自己陷入困境，從事的工作根本不需要在截止日期之前完成。

There are a few things we can do to try to prevent this scenario:

為了防止這種情況，我們可以做一些事情：

Taking to heart the ‘Slowing Down to Speed Up’ concept I’ve just referred to, the developer must always talk with the product manager about the story if there’s any need at all for clarification.

牢記我剛才提到的“減速以加快速度”的概念，如果有任何需要澄清的內容，開發人員必須始終與產品經理討論這個故事。

As developers, it can be very easy for us to think ‘oh it’s ok I got this’ and just get on with it. But remembering that the customer is part of the team, picking up the phone and going over the story with the client can be very enlightening most of the time.

作為開發人員，我們很容易想到“哦，我知道了”，然后繼續進行下去。 但是要記住，客戶是團隊的一部分，拿起電話與客戶討論整個故事在大多數時候都非常有意義。

At the very least, a quick conversation with the person who wrote the ticket will make sure that everyone’s on the same page.

至少，與寫票的人進行快速對話將確保每個人都在同一頁面上。

The person writing the user story in the first place should include a ‘definition of done’. This can simply be a list of things that will happen when the story is completed. For example:

首先，編寫用戶故事的人應包括“完成的定義”。 這可以只是故事完成時將要發生的事情的列表。 例如：

• The user clicks on the ‘reports’ button, and is presented with a list of reports
  用戶單擊“報告”按鈕，并顯示報告列表
• The list contains the name, description, file type, and a ‘download’ button for each report
  該列表包含每個報告的名稱，描述，文件類型和“下載”按鈕
• Clicking on ‘download’ saves the report to the user’s device
  單擊“下載”將報告保存到用戶的設備
• Access tokens must be used when retrieving the downloads to maintain security of the documents
  檢索下載文件時必須使用訪問令牌以維護文檔的安全性

So, those are the main things that either saved us or held us back, depending on when the lessons were learned during this particular project. I really hope you find some of these points useful when you’re working to a tight deadline, or even if you’re just working on your next software or web project.

因此，這些主要因素是拯救我們還是使我們退縮，這取決于在這個特定項目中何時汲取教訓。 我真的希望您在緊迫的工作期限內，甚至是在處理下一個軟件或Web項目時，發現其中的一些有用之處。

We still have a couple of phases to go, but both us at Remote, and our clients, Jump In, are delighted with the site so far. Check it out at www.gojumpin.com.

我們還有兩個階段，但到目前為止，我們Remote的客戶和我們的客戶Jump In都對該站點感到滿意。 在www.gojumpin.com上進行檢查。

Originally published at remote.online.

最初發布在remote.online上 。

翻譯自: https://www.freecodecamp.org/news/delivering-a-big-project-to-a-tight-deadline-4645aa62886d/

大數據項目交付國標

總結

以上是生活随笔為你收集整理的大数据项目交付国标_在紧迫的期限内交付大型项目的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。