The Practical Software Methodology can help any size company – from early start-ups to large enterprise software application companies – with the art of doing software right.
Practical Software Methodology preceded Agile and was improved and matured in parallel with the Agile movement. Practical and Agile share many of the same best practices and concepts, although facets of Practical Software should be incorporated into Agile to make it more effective and, well, practical. Practical Software Management incorporates effective tools and proven processes to deliver high quality software quickly and with agility.
To learn more about how the Practical Software Methodology was developed and the details about how it was applied, Jan’s book, “It Starts with an Idea,”, the book about her start-up, Intelic/Azerity, gives software engineers, managers, and CEOs insight into how to build “Practical Software” – software that is high performance, scalable, reliable, and robust – software that is on-schedule and low cost – using a software development methodology that is more agile than “Agile.” That’s practical software!
Software 2020 is a tool developed to help companies implement Practical Software Management or Agile.
Beat the software gorillas !
Win the game and deliver high quality code your customers will love. Quickly and with agility.
Practical Software for the 21st century
Practical Software Practices yield quality software products. Practical Software Practices includes a Practical Software Process for tracking software from inception to production, Practical Software Tools to enhance and enable the process, and the use of Practical Software Design for clean and simple architectures which enable efficient, high-quality products.
Practical Software Process
The Practical Software Process is a lightweight process supported by effective, useful tools.
Requirements and/or Fuzzy Ideas Evolve to Final Requirements
Practical Software can start with either a detailed requirements/design spec or a fuzzy idea (similar to an Agile “Story”), available on-line for the developers to easily access and refer to. Unlike “Waterfall” or “phase-gate” methodologies, Practical allows and encourages updates to requirements/stories during design and implementation due to Product Owner (PO) changes or due to better solutions the developers identify during implementation. The final requirements must be on-line, up-to-date and accurate for QA to test against. Because the developers and PO work together, using the on-line requirements as an integral part of the process, requirements management is streamlined and effective. See who the users of on-line specs are in Who Needs Documentation?
An easy-to-use, effective task tracker is a core part of the process. The Tracker must be web-based for access anywhere, must display all comments and discussions in an easy to review fashion, and must support key process tracking components (e.g., priority, severity, issue class, release and status).
Any spec changes must link to a task in a Tracker system to make the code change matching the spec change and visa versa. This yields a true iterative approach, very agile, and ensures on-line specs are always accurate and up-to-date. In addition, any other change due to a bug, customer issue, or need to refactor code must be represented by a task in the Tracker system. No change is made to the code without reference to the Tracker task it was made for.
Task requests can be entered by anyone – the Call Center, customers, services, the PO, developers, testers or managers. New requests are reviewed regularly by a cross-functional team and assigned to the appropriate release and organization to resolve them.
Developers only work on tasks assigned to them to fix in the current release, considering task priority. A code reviewer is assigned to review each change. Developers are responsible for unit testing and first pass integration testing as their code is checked into the main branch.
Developers are also responsible for checking in any data schema changes or data migration required for their code changes so that all of the developer’s workstations use the data migration scripts which validates final production data migration for customers.
The PO, other stakeholders and testers are encouraged to review the release incrementally, as soon as a feature is sufficiently ready to evaluate. That way any misunderstandings or changes can be incorporated as early as possible into the cycle.
QA performs final regression test and final verification against completed spec requirements for release to production. This step can be done in increments, such as recommended by Agile/Scrum, or in longer cycles depending on customer need.
Production releases should have no “known bugs”. “Known bugs” are where the code and spec are out of alignment and an issue is known that will cause a user difficulty. The amount and level of QA testing should be decided by the company based on product requirements. For example, products requiring FDA or government inspection sign-off would have more testers and a more stringent/longer test cycle than commercial software. A policy of “no known bugs” does not insure the customer will never encounter a bug because customers may use the software differently than anticipated. “No known bugs” should still be the goal.
Ensure cross-functional communication and collaboration with team-based, efficient processes and tools.
That’s practical !
Software 2020 – The New Practical Software Tool
Want to implement Practical practices easily and have a “document” at the end that accurately presents the final requirements specifications in a readable, useful, on-line form? That’s why Software 2020 was developed – a tool to do it all. Quickly, painlessly, with agility. One tool to capture requirements and/or Agile Stories, to track tasks and organize the results into on-line documentation automatically. Software 2020 and proven processes – that’s “Practical”
Practical Software Design
Software architecture projects should always aim for simplicity of design. A simple, uniform design reduces development time, improves maintainability, and makes modifications quicker and easier.
Often developers and software architects think they have an “elegant” design because they have tried to design very generically and/or very object-oriented, used a lot of open software components, and/or tried to plan for yet undefined requirements. But often the result is software that is much more complicated and bulky than needed. Over-designed, bulky software is costly to develop and maintain.
How can you tell if you truly have a good design or not? Here are the five keys to good software design:
#1 Is there a simpler approach?
#2 Is it customer-focused?
#3 Is it designed for the expected user base?
#4 Was performance considered?
#5 Is it reliable, maintainable, supportable?
Read more in Jan’s Simplicity of Design Blog.