This post is in progress, and comes from years of finding things that work, as well as slamming into the pain and not having the authority to change the process (That’s called using power for good, people), or saying, “Good luck with that”. One thing I have learned in all the org’s I have frequented is that most orgs that have problems recognize this and sincerely want and are trying to improve the process. Getting the process right is an art.
SDLC – Increasing Efficiency and Throughput, Decreasing Bottlenecks
Whether you are new to Agile or seasoned, you should read The Agile Manifesto – poetry for the weary.
Software development lifecycle improvements can increase throughput, manageability and maintainability, vastly increase overall efficiency, and decreases bugs. A major factor is improving the agile process for the organization (from planning to deploys), for which you need to not only educate staff but also have employee buy-in to the process. Jumping into this with a system that is in need of re-architecting could create more bottlenecks and technical debt so timing and rollout of new processes must be planned well.
Planning And Requirements
Insure that requirements are broken down into what can be completed and demoed correctly in each sprint. Scoping each unit of work for a feature, enhancement, bug fix or task must be done in such a way that dependencies are never a bottleneck and goals are achievable and testable. The business should set requirements in a scope that is achievable, partitioning work sometimes over multiple sprints.
Do not overlook a very important part of the process that lends to success – your process tooling. Tools like JIRA are often underutilized. Leveraged properly, it makes the work and process transparent, improving not only efficiency but accuracy of implementations, testing, and deploys. If you don’t already have Greenhopper for JIRA, get it. JIRA is not just a bug tool, it is a SDLC tool.
- I would not do a project without JIRA (with Greenhopper)
- I would not do a project without GIT as the repo. Anything else and you are asking for pain and incredible inefficiency
Turning Requirements Into Stories
This may be the starting directive: Build in real-time asynchronous stock ticker updates to the client. In Agile, the Story should look like this:
As a User I want to receive real-time updates of stocks I have selected to watch, so that I can take immediate, accurate advantage of market fluctuations
We can not proceed without covering dependencies. A functional dependency is something that requires or depends on another thing being done first. Example: I want to tweet, I have a dependency on an internet connection to send the tweet in order to accomplish that task.
This assumes or highlights many things, for instance, what could be done in parallel as tasks of the same story? What may more appropriately completed in a prior Sprint?
- Is there a UI dependency to create a form where the user can select stocks to watch, submit the form?
- Does a new db table need to be created for persisting stock selections by user?
- What in the messaging system needs to be added to do this?
- What could be done in parallel as tasks of the same story?
- How can this be architected to allow for consecutive sprint development?
- How can QA best test this over each sprint until the final task is committed?
- Do we put this in a feature branch or roll each part in by sprint so QA can test?
A business dependency, which may also be called a requirement, is something engineering needs from the business in order to complete a Story or Task. For example:
As a business owner I want to authorize all incoming user requests from the client to insure that user has been granted rights to do what they are requesting to do in the system.
Say the Product Manager brings this up in a Sprint Planning meeting to the team, reviews the requirements, and one of the engineers says, “I see a requirement missing, there is no failure scenario”. If the client is simply making API REST calls to the server, then any client can call what it is not granted authority to do. A failure plan is needed for what is generated on the server and sent to the caller/client and if the client is a UI, how this is displayed. This could need a new UI task and time.
Story Points And Time Boxing
Possibly the most highly-debated part of any SDLC process methodology, whether agile, lean or other.
Planning Poker is an interesting read.
Planning And Effective Use Of Tooling
First, a Project Manager should identify the availability in hours per day of each team member for a sprint to get the total hours of the team for a sprint. I should note here that I have fought with QA many times over the years and may be biased.
- Product Manager Creates a Story ticket that will have child tasks
- The business insures that business requirements are accurately and granularily described in the story’s description
- Team (Dev/QA) assesses the business requirements, and identifies questions or information lacking by the business
- Project Manager assigns the Story ticket to the business/Product Manager to complete – and everyone can see where in the process this ticket is. When complete, the business/Product Manager assigns ticket back to Project Manager
- Product Manager and Project Manger reviews with team
- If team deems requirements are adequate to proceed, Project Manager can schedule the Story
- Team (Engineer(s) – Dev) votes on the number of story points to assign to the Story – how many days will it take to complete? What is the difficulty of the story?
- Does this story have dependencies?
- If so, are they completed or scheduled? How long will they take?
- Does this story require an architect before developers come on?
- Do we need to prototype or vet a new technology decision or strategy first?
- Is there a functional or UI dependency?
- Dependencies in the same sprint must be scheduled in such a way that no
- Team (Engineer(s) – Dev) create Child Tasks under Story – if a junior team, Team Lead insures accuracy and that nothing is left out
- Developers task out what needs to be done to complete a scoped story
- Developers pick task tickets and assign to self
- Developer / QA timeboxes task – how many hours will this take?
- Team (Engineer(s) – QA) create Child Tasks under Story
- Create task ticket to create test plan for story
- Review test plan with the business and developers
- Attach approved test plan to Story’s JIRA ticket
- more coming
Now insure that the hours it will take to complete the work is achievable given the availability of the team.
Development – and Effective User Of GIT
- TDD – Test Driven Development
- 1:1 correlation between requirements from the business and unit/integration test methods
- Unit test: testing a method or small unit of code
- Integration test: testing a Service method that covers multiple component (DAO, Util, Messaging, etc)
- Tests must be written in such a way that they are OS and Environment independent
- Tests must be written in such a way that they can be run by an automated process – Continuous Integration (CI)
- If CI tests fail, the team should be notified by email that tests have failed, and attended to quicky
- Before code check in
- Latest changes in the current branch should be pulled in
- The new code must compile with the latest code in the branch
- Tests should be run by the developer and pass
- This means that every developer is responsible for all of their tests passing when a team mate checks out the latest code
- New code must be deployed successfully by the developer
- Coding Standards
- Every org needs coding standards and a means to insure that such standards are being implemented
- Code Reviews
- Developer training
- Best Practices instruction
- Lunch and Learn presentations for the team
- Team education of the system, tools, processes – the more everyone knows, the faster and less error prone things will be
- How to properly test code
- Architecture enforcement with AOP in codebase
- Automate catching poor architecture or code implementations in dev-time
- No engineer has time to stay on top of static code standard documentation
If an org is accumulating technical debt in part due to the business: sales and marketing pressures for new features and bus fixes faster than engineering can also take care of issues that need to be resolved as well as doing work properly the first time, then the risk management of the system is put on the back burner and accumulates. This will eventually blow up.
Technical debt time must be built into R&D sprints, and often are done as sprints on their own.
QA, Staging, Deploys, and Rollback Strategies
Not a free-for-all, I have not written this yet. However, deploys should be automated. If you need to do it manually, there is something wrong with your application architecture and/or deployment architecture.