Processes and Where to Store Project Related Stuff
Each person will create a folder for each client and emails related to that client will not not thrown in the trash (This is actually a legal requirement rather than a recommendation! It is our policy to retain customer email!). Once a sale is made, we prefer using Slack for project-related communications over email.
RingCentral
is mainly used by Jim, Erik and Iain for sales related meetings and sometimes developer meetings if there isn’t an available GoToMeeting account open. All recordings should be moved to ScreenCast for archive.
GoToMeeting
Pretty much every meeting with a client should be held on GoToMeeting and recorded. Recordings are wiped from GTM after exactly 1 year, so they should be moved to ScreenCast for archiving. GoToMeeting also does an OK job of providing a transcript of each meeting which can be searched.
We need to get to a point where we have all our recordings stored away with a description and a transcript so they are searchable! Keeping our videos is very important for a variety of reasons, including legal reasons and also just plain logistical so we can go back and figure things out.
Slack
is where we prefer all communication about a project and all files that are not considered permanent documentation for the project go. For example, spreadsheets from the client. Email quickly becomes unmanageable and things get lost. If the client already has Slack, they can set up the channel in an existing workspace and invite us (as EOG has done). Otherwise we can set up a channel for the client under
OneDrive
The “Clients” folder holds all pre-sales document including all Vision & Scopes, Labor Forecasts notes from each participant, screen shots, where to run the old version of the app (if applicable) login information, etc. Relatively few clients get to the project kickoff stage, so there are hundreds of client folders here and some clients have multiple projects under them. Important Note: Do NOT save multiple revisions of the same document. OneDrive maintains a change history for each document and in the past we’ve had bad and embarrassing experiences pulling the wrong version of a document. There should only be 1 Vision & Scope document and 1 Labor Forecast spreadsheet per project, not 7 or 8.
Monday .com
is a new simple and flexible app we’re trying out in an effort to help track and standardize processed within EPS. Current users are Myself, Ellen, Nancy, Erik and Tripti. The first “Board” we created is for the CIA project launch. Though it can be used for many other things, there is a need for a checklist and schedule of all the things that need to happen between the Vision & Scope and when development begins. I think of it as a place to put a checklist and timeline of everything that happens prior to development beginning in DevOps. At least, that’s our first objective with it. The first board was created for the CIA project and we’ll copy that board for the next project we start. Developers typically won’t use this software as all of there stuff will be in DevOps.
ScreenCast
is a permanent place to upload meeting recordings, ‘5-minute videos’ from projects, DEP sessions and any other type of video or audio recording. Each client should get a (private) folder named after the client. We may create an additional (private) folder for any client for internal use – recordings not to be shared with the client. DEPs have their own folder as do other EPS internal categories.
We really must make sure we do the 5-minute videos on all our projects! We must stay on top of this!
OneNote
is used to store requirements and business analysis information in its raw form, prior to it being entered as DevOps work items. This could include transcripts of interviews, documents provided by the client and links to ScreenCast recordings of interviews for example. Some of these documents may later be attached to work items in DevOps. Nancy is thinking about a document that describes a standard way to set up a OneNote Workbook for this purpose. In the past we’ve seen these devolve into a ‘big pile’ if we don’t have a solid det of guidelines to adhere to. Even though there is a pretty good search feature, good organization is always better.
DevOps
Git
Source control. We want to lean toward using and enforcing Pull Requests for all but the smallest of projects. Documentation that needs to be available to all developers should also go in here. Any 3rd party tools except for NugGet packages and the like that are guaranteed to be available forever should also go in here. That includes installation programs if necessary. Imagine a develop has to pull down a project 10 years from now onto a clean machine. They should be able to build and run the project without having to go tracking things down.
Work Items
Before creating each new project in DevOps, we should inherit the EPS Agile Process template to make a copy, named after the project. This gives all projects a common starting point and ensures we have all of the fields required by ClockWork, etc. The inherited process can then be modified as needed. Epics and Features should be entered first and must match the organization set up in the Labor Forecast. User Stories should be entered, followed by Tasks for developers. This is the default hierarchy of Work Item Types and must be followed. Iterations MUST be configured and used, otherwise there will be little or no reporting available.
Pipelines
Continuous integration and deployment should be set up for all but the smallest projects and should point to an environment named with the suffix “Dev”. A Demo environment may be set up now or later. Production environments are not set up until needed and should be set up under a different Azure ‘account’ owned by the client, not by EPS. Access to production environments should not typically be available to the development staff. Additional environments such as QA, Test or Sandbox can be set up as necessary.