Agile Software Engineering and Development is as such new and various agile methods like Scrum, Kanban etc. Software companies are moving to Agile for their software development. I am recently into Agile Software Development and using its Methods to develop and ship Software products of different scales. So i would like to share about the Agile Engineering practice in terms of common development and practical implications on process that could help you understand and implement Agile into your Software practices.
What is this?
This document is not usual documentation, All the practice here are tried, tested and implemented, but with a slight customization to each development. This is a mix of Agile Scrum, Software Development practices and my experiences along with a flavor of people management involved. It’s the result of the the gradual shifting from the scope of development, growing developers’ team to the evolving standard of development and best practices involved in them
.
The analogy used here is that of a pirate ship, because building and running a pirate ship is an art, and Software development is an art too!
The Crew
We refer to the analogy of the development to the operation of a large ship. The crew consists of the following members with the roles.
Product Owner – Lord of Pirate
The owner who funds the project. He basically runs the whole show, under his guidance the ship sails across seven seas to the land of magic.
Project Owner – Quartermaster
They are the one who guides us on what we need to do, they talk with clients and come up with useful requirements, and they set the direction of the ship to glory
Product Team – Boatswain
They help the Project owner define the requirement into a Product Specification, they build demo of ship and see the wood turn into a ship.
Project Manager – Boatswain
They manage the project, work with the tools and makes sure the ship never stops. They are like the never ending fuel to the burning fire!
Lead Developer – Sailmakers
The lead developer works along with his team of crew. He is a Technical person who knows how the ship works, from building to sailing he does them all.
Developers – Pirates Crew
The actual brave fellows who sails the ship, they work in close with each other and the Sailmaker in sailing the ship, they control, build and sail the ship.
Lead Testing/QA - Master Gunner
They are the master of shooting down bugs and makes sure the ship is of high quality. They cannot tolerate even a house bug! They device plans to find each one of the bugs.
Testers – Gunners
They are the fellow gunners who share the passion of Master Gunner, they shoot down bugs before you even spell “B-U-G”.
Sales/Marketing Team – Cooper
They sell the ship to our clients. They know about the importance of the ship and help the Project Owner in selling the ship to prospective clients. They help in getting the Jackpot!
Building the Ship
Building the ship takes a long step, Rome is not build in a day, and so is the software. Saying that time and tide waits for none! A well-crafted ship sails beyond long waves.
Requirement
- The panel consists of the member from the Product Team, the Project Manager, Lead Developer and the Lead Tester all participating in the Requirement discussion
- End of discussion, the following happens.
- Project Manager prepares the Requirement document with the inputs of all the members in the panel. He calculates the Rick and the Time
- Project Manager then discusses with the Lead Developer in assigning the Developer to work in the product.
- He creates the Project Plan (Sprints) and the Stories/Epics in them and assigns them to the Developer
- The Lead Tester sits with his crew members and prepares the Test cases based on the Requirement of the component.
- All depart to start with the process
| Note |
|---|
| Requirements can turn messy, in that case drop down the product into parts of evolving nature, Attain the MVP (minimum Viable Product) and build features based on Increments of it in versions |
Development
Product Scope
The product scope is basically defined in the Requirement document, Developer has to follow the product scope in the requirement document and build the product according to that.
Test Case
Extensive Test case is written by the Developer before he starts to develop.
The Test case created by the Developer should not be shared by the Testing team at this phase as the testing team should be independent Testers
Coding
Coding is like crafting a Monument, it has to be built in a nice way. Proper coding standards should be followed.
Code Review
Code review has to be done on frequent basis by the Lead Developer, any optimizing in code should be done along with the developers imparting in them the knowledge of how it is optimized.
Peer Review
The Product done by the Developer is first checked by the Peer, Peer review should be independent and can use the Test cases prepared by the Developer. They test and report the bugs which are fixed by the Developers before sending out to the QA
QA/Testing
The real testing happens now, Testers find bugs in the product and report them to the Developer through the Bug Tracking Tool. Testers use the Test Cases written previously and submit their results to the Developer.
This process continues till the QA is passed and the product is sent to the Product Team. For evolving versions of Product, Incremental testing can be done.
| Note |
|---|
| Testing should be done independent of the Developers to find the possible bug missed out by the developers. Test results should be released in batches for the developers to work on and retesting can be done with the Test cases |
Product Review
The product review is done by the Product team, the product team is our internal customer, they check the product and certify it as a full “Product” ready to go to client, any disputes in product should be discussed with the Project Manager, Lead Developer and Developer.
Marketing/Sales
The marketing/Sales team does their magic with the product in getting it shipped to the client.
In the following series to this, I will be writing about how to build your crew and some best practices that could make your Shift to Agile a smooth sail. You can read Part 2 of the document A Novel Approach to Agile Software Engineering Process - Part 2
- SAP Managed Tags:
