What would you add in this Software Development Project Checklist? [closed]

Question

I'm a big fan of checklists. There is Travel Checklist, Moving Checklist and even a Scrum Checklist.

Context: you have been hired by a large corporation and given the mission to setup the whole software development environment, processes, team, etc. You have "carte blanche". You will be responsible for the creation of the working increments of the software. Project size: 2000 man/days.

What items would you add to the following (intentionally small and incomplete) checklist:

• Install a Continuous Integration Server
• Write a DoD
• Write a one page coding guidelines
• Create a product backlog
• Install a Bug Tracking System
• Schedule Regular Face Time

Answer 1

* 1.) Talk to the developers to see what they really need! *

2.) Investigate a solution for bringing up multiple environments really rapidly (think public or private cloud instances or old fashioned virtual machines if you'e not buzzword compliant)

3.) Source/version control

4.) Code review system (Crucbile/Fisheye as an example)

5.) Kanban wall (or something similar)

6.) Communication protocols (real time chat is a big plus), wikis also encourage collaboration. This also covers public relations internally - how are you going to engage with your business owners, tech support staff and other groups?

7.) Electronic whiteboards

8.) Comfortable environment for developers (couches, tables, chillout areas, good WiFi etc)

9.) Great coffee!!!

Answer 2

• Toolchain setup - IDEs, CI server, code quality server, source control, webserver, databases, issue tracker etc.
• Backups - What role does each person in the team have? What processes/modules does he 'own' and who is his backup?
• (User-Acceptance) Test environment setup - Not only continuous integration w. unit tests, but integration tests to cover the really bad things, multiple platforms, application servers, VMs, etc.
• Performance Tests setup - The earlier the better, since you will need historic data to answer "With which feature/milestone did the performance drop so badly?"
• (End-User) Documentation outline - What is going to be in the documentation? What type(s) of documentation is needed?
• Marketing channels - How are internal milestones and external releases being announced? Do you have a cool name for the software, a logo, colors, wording etc.?
• Internal communication - How are peers from other teams going to be informed about changes? How is collaboration being done? Wiki? Access rights?
• Quality Assurance people & process - Who is going to test what, how often and with what criteria?
• Release process - When, how often, how, who is doing it, who is receiving the release etc.
• Risk management - Worst-Case Scenario (from a project mgmt pov and from a runtime pov, e.g. 'customer is losing money because software failed at module X, what is the backup plan?)
• Securing of the core development environment, e.g. virtualizing it for Escrow
• Locations for formal and informal meetings
• Training or intros for all the people, so they know what all the setup is, what each part is for and how they use it.
• Identifying the caretaker and give him all the things (e.g. permissions) he needs to actually take care of when things go bad

Answer 3

Postmortem Reviews - Since you are working on things in blocks, I would schedule a one to two hour review (depending upon team size) to have a face to face meeting (if possible) where everyone goes around and says what was done right, what could be done better, and what wasn't needed. Being able to learn from your mistakes in the development process early means that you can avoid doing them later on when you don't have as much time to work with.

Answer 4

Let's start with hire a good team of the right professionals for your project. In a typical business app you would need to hire a database developer and a dba, a QA person, a system admin, a business analysts,application developers, a UI specialist and team leads at a minimum. DBA, System Admin, business analysts and QA should be in a separate reporting chain from the development team. The development database specialist should report to the same technical lead as the application developers and UI specialist.

Set up the office space. Private offices are great if you can get them (I wish you lots of luck with this), but at a minumum you needs desks, phones, computers, whiteboards and a couple of dedicated conference rooms. Make sure there is a place for lunch breaks, a refrigerator, soft drinks, snacks, and coffee available. Free soft drinks and coffee even better.

Set up dev/qa/staging and prod servers for both the application and the databases. Databases should not ever be on the same server as the applications. Depending on the size and scope of the project, you may need multiple servers or SANs, etc for each environment.

As soon as servers are set up, schedule backups of the file sytem, the database and the database transaction logs. Do this the very first day things are set-up. Hire a firm like Iron Mountain to take backups off-site weekly.

Set up a source control system and create a document describing how it will be used. Do not forget to insist that ALL database structural changes and data inserts for lookup type tables be in scripts in source control. This will make deployment easier.

Buy commercial software or download open source software for the toolset you decided to use with licenses for all the pertinent users.

Buy developer machines that are screaming fast and have two monitors. Buy at least one test user machine that is moaning slow and typical of what the users will have on their desktops.

Train your new developers in how you want things done. If you have a large enough team to have some junior developers, then schedule extra training for them and include the time in your project planning. Monitor juniors very closely for at least three months. Monitor all new employees closely for the first month. Get rid of deadwood and rogue developers as soon as possible.

Determine what needs to be done in what order (the critical path). Do not assign tasks at the end of the critical path until the tasks they depend on are complete.

Create test plans and requirements.

Set up regularly scheduled progress meetings with the clients. They deserve to know what you are doing and what the roadblocks are. Do not fail to tell them when things will be late. If you are three weeks away from a deadline and you already know you will miss it, that deficit will not magically disappear before you have to tell the client. Make sure that the client knows that added requirements means added costs and time and that every added requirement will either have to have other tasks dropped or the deadline will change by the amount of hours in the new tasks. Making this clear from the start will save lots of pain and overtime hours and cost overruns absorbed by your group and not the client.

Set up an environment to performance test, not just the speed of one user, but one where you can test the expected number of simultaneous users. Do not wait to do this testing until the day before you go live.

In project planning, assume QA will find bugs and that they will take time to fix. Do not schedule QA for only one day at the end.

Create test data that is roughly the size you think the database will be. Make all developers test their code against the database of this size. Do not allow developers to only develop against a small database on their personal machines. This is a frequent cause of code that works fine until it hits production.

Plan rewards into the budget. It demotivates people when they work their butts off for months and only managers get bonuses. Also say thank you frequently and in writing.

You may need a project management system or at least set up spreadsheets to track what you need to track. When doing the project planning, assume no more than six hours a day person in your plan. This helps account for the time that will be spent not on the project, such as vacation, sick time, holidays, HR meetings, performance reviews, etc. If you know the project is in a period of high unavailability (say a project that runs form Nov1 - Jan 1 in the US), you may need to make extra allowances for more leave and holiday time. It is not fair to expect that developers will give up their leave and holidays and no one can predict when things such as sick time, jury duty , bereavement time etc will happen. Assume they will happen to your team on this project.

Answer 5

Some things I don't see in the question and subsequent answers:

• Disaster Recovery Plan. How are you backing up the dev boxes, staging, testing etc? Does every dev have what they need to work from home on the occasional snow day? Etc.

• Training Plan. How many weeks of year of training do your devs need to keep sharp? Is anyone tracking it? (A spreadheet can suffice for most teams.) Have a mechanism for them to report (sending someone an email saying they watched 2 hours of webcasts on "whatever" is probably enough) and for management to plan - eg who should we send to what conference this year.

• a Tool Position. Is this a "we give you all an MSDN subscription; please don't install anything else on your work machines" kind of place or a "we want your code but we don't care what you use to edit, compile and test it" kind of place. Make and record the decision.

• as much integrated ALM as you can stand or afford. Usually the reason for the "impedance mismatch", double entry, tool overlap, and swivel chair application integration is that the system grew by bits and pieces. Starting from scratch, you want to show that your people can stay in a single tool throughout the cycle. Not typing code in X, compiling with Y, testing with Z, changing the status of the work item / task with A, reporting their time spent with B, telling the person who was waiting that they can now proceed with C, trying to figure out what to do next with D, guauging overall progress with E, etc.

Answer 6

Negiotiate more man-days.

It is a rare event when people allocate enough initially.

[Later... re-negiotiate even more...]

Answer 7

Seeing as I've had the most problem with 3rd party libraries and their usage:

1. Determine the libraries and versions you're going to be using.
2. Create the process of integrating library updates to your project.
3. Make sure the developers are all on board the library choices.
4. Create a beneficial channel for open discussion on technologies being used.

Why? I can't tell you the number of times 3rd party libraries (proprietary) have had henious bugs which sent us back weeks of development time because we had no process for moving up or back down. Or dealing with developers saying "which version did you use? Why did you use functions marked deprecated?"

Answer 8

A large cost to organisations is not assigning budget to security throughout the development lifecycle, this means security usually ends up being in after the fact ineffective, expensive set of activities or controls put in place too late to do much good.

Get security built in from initial project plan, with key milestones, the same as you would with all other aspects of development, and use an iterative process to keep security guidance up to date. Final signoff from security should ten be a no-surprises check that all security controls were implemented as per design.

Otherwise you'll end up running security after implementation - where it could cost 8 - 10 times as much (figures from Gartner, IBM and others), will upset people as functionality is likely to be impacted and it may be too late to prevent exploitation and damage.

Answer 9

1. Take it to the team

Ask the programmers! Really, that's the most important thing. You'll meet lots of resistance if the devs are not directly involved in this change. After all, it's about how they work, not you. It goes without saying, but trying to force methods and tools on people usually backfires horrible.

2. Inspect and adapt

Have the team figure out the best way to work, using your experience to gently help them get on the chosen track. Then, regularly and collaboratively, look back on how you (they) are doing and adapt the process to make it better.