all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Orange
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
Working with Alan on more processes and documentation stuff. We reviewed the notes from last Wednesday and then moved on to new stuff. See element of time # 2520 for an earlier session. - Useful use cases - These are ways to describe what the application does from the user's point of view. These use cases are great for complicated processes and/or possible different choices and channels. It puts the specifications into somewhat of a story based format vs. just plain requirements. Depending on the scenario, you should choose between plain specs or use cases - usually not both unless they are needed. - Test Cases - How can I prove that this works? Do this, then this, then this, you should get... These are virtual step-by-step instructions that could be used for testing. Test cases show that we have met the requirements. Test cases are easy if you have a good set of requirements. - Use cases are stories on how to use the application based off of the requirements. This often involves different choices and/or flow processes. Test cases show that the application works and/or the requirements are being met while using the application. - The secret is to consider the project, the client, and then make a plan that fits. There is no special secret that has to be done every time. Make a specific plan for each project based on size, dollar value, the client, and other available assets. Don't be afraid to make a new plan if needed. If it is different, treat it differently. That is ok. It is also ok to reuse and/or modify something that already exists. - Use the sign-off as more than just being legally covered. It is more of defining the project scope and defining key points and features as well as getting client buy-in on the process. That helps to manage the expectations for the project. Based on the project size, there may be one or more sign-off's periods or sections required. Mix and blend as needed. Once again, think about the project, the client, and other variables. - Sometimes use cases and test cases can be one in the same. Repurpose and keep things simple. Sometimes it is hard for developers to test their own code... they already know exactly what to do to make it work. We need to test and use things from a fresh pair of eyes that may not know all of the tricks and/or sequences that are needed. Think about user errors and/or the full user experience. Use/Test Cases allow someone who is not familiar with the code to walk through a process with an expected outcome. That could really be a great benefit for the application and/or project. - Help the requirements set bounds - both - it will do this and this and it won't do this and this. Cover both sides. Set a clear ending and/or strategy for deploying and sustaining the usage of the project. Nobody wants a never ending project... - As a side note, "the top is only half way" - Remember the 90/10 rule. What about testing, sign-off, merging, documentation, education, maintenance, etc. Building the project is only half way there. Think of the full trip and/or full project from start, clear to sustaining the project through other phases. If we build a new feature and nobody knows how to use it or even knows that it exists, it is almost like not even having it. Two of the biggest components are: education and maintenance. - Change orders - We have lost our shorts on change orders and project scope creep. Literally, thousands and thousands of dollars and even months and months of time. All of this was basically pushed off onto our shoulders and the clients have either been unsatisfied and/or frustrated due to set backs and changes in time lines and project scope. This is something that we really want to change and get more control over. If control is the wrong word, maybe think more of managing these issues. We need to mange the change orders better. Sometimes we get addicted to progress and progression. That has cost us dearly over the years. - Change orders could be alterations, expansions, simplifications, or enhancements to a project that happen mid-stream. That is totally ok, but we just need to make a conscious effort to get them covered and/or paid for. A change order could alter the cost, the timing, and even the functionality of a project. They can be small, big, numerous, and/or even a virtual game changing piece. If you have good documentation and good processes, that is half of the battle. If they, the clients, have read and signed off on other documents, they will be more willing to admit that the new requests were not part of the original scope that was previously signed off. We need to adjust requirement, costs, time lines, and get a new sign-off before proceeding. - A change is just progression. We love that. We just need to make sure that we get covered and are able to adjust the price, cost, time lines, and specs as needed. We love doing custom, but that comes with a price tag. That is ok and we just need to communicate that. Part of our reason for looking more into processes and documentation is due to the pain we have encountered from un-managed change orders and change requests. This has been our Achilles heel in many ways. - We have been trying to implement tons of these processes over the years. We have made some great progress and learned tons of lessons as we have made this journey. Keep applying what we are learning. - We may need to slow down a bit. We keep going so fast that we are skipping steps and virtually shooting ourselves in the foot. Starting up a process will take more time at the beginning but will pay off huge dividends as we go forward. It is time to focus more on project management in order to help us keep up team morale, provide awesome products and features, keep our clients happy, and help our bottom line so we can keep building and maintaining what we like to do. We have really enjoyed building adilas. What a journey. |