大数据项目交付国标_在紧迫的期限内交付大型项目

大数据项目交付国标

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:

通过这种方法，我们可以获得三个明显的好处：

1. We don’t find ourselves building architecture for features that are never built, or features that are never used.
   我们不会发现自己为从未构建或从未使用过的功能构建体系结构。
2. 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.
   如果客户需要将积压的功能换成急需的功能，我们就不会浪费任何开发时间来准备该功能。
3. 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/

大数据项目交付国标