| Home | Questions | About | Contact Us |
igeejo
our next startup: simple, sane, and a tad unconventional
Dev Mod FAQContents
Dev Mod System Overview
Projects Dev Mods Dev Mod Documentation Todo List Prioritization Alerting System Miscellaneous Notes
Phase Steps
-- top -- Dev Mod System Overview-- top --Mission StatementThe dev mod system is a tool for project management. The system will help us plan projects, monitor their progress, and provide everyone with information on what to work on, all in a methodical and orderly manner. -- top -- ObjectivesIn designing the dev mod system, the following objectives were considered.
Develop in a an organized, methodical way.Developing Internet technology projects requires a lot of coordination and organization. Projects involve managing computers and their components: networks, hardware, programs, databases, permissions, module libraries, security and configuration settings. Projects involve managing people: planners, designers, network admin, coders, documenters, testers, and end users. Projects involve managing resources: time and budgets. Projects involve managing unpredictables: hardware malfunction, software bugs, version incompatibilities, cost increases, inaccurate time estimates. Projects involve managing aspects beyond your control: assessment delays, outsourcing errors, bank charges, tax changes, and litigation suits. With all these factors to juggle, we need a tool that permits development in an organized and methodical manner or else we are sure to slide into chaos.
Do what is most important first.Emergency and critical issues need to be addressed first. Ensure the development system has a means of alerting people of critical issues and placing them at the top of people's todo lists.
Do tasks in the required order at the appropriate time.You have to build the floor before you can build the walls. You have to build walls before you can build the roof. But you can frame the walls while the floor is being built, and you can order the roof trusses while the walls are being put up. The development system should schedule tasks so dependent tasks are done first and allow users to work on parallel tasks so projects are completed efficiently.
Work so high priority projects are completed in the shortest time possible.Everyone's effort should be put towards the project deemed highest priority. Using critical path analysis the development system should arrange tasks on people's todo lists so that the top priority project can be completed in the shortest time possible.
Do one thing at a time.We can only do one thing at a time. Attempting to juggle several things at once creates stress and reduces productivity. The development system should provide each person with one task to do at any time.
Dynamically adjust to change.Rarely if ever are project carried out exactly according to the original plans. Unpredictables and factors beyond our control require plans to be altered. The development system needs to dynamically adjust to change, immediately reprioritizing tasks on people's todo lists when project or task priorities are changed.
Visually display progress.The development system should include reports and visuals that allow everyone to see the scope of a project and monitor its progress.
Add tasks to todo lists with mininum effort.Ideas can pop into our heads at any time. We may think of a task we overlooked during the planning stage of one project while working on another. The development system needs to have a convenient way for people to record those ideas with little effort to ensure they get recorded with minimum interruption to the task at hand.
Have work available for everyone at all times.The dev mod system should be able to manage several projects at once. If there are no tasks from the high priority project suitable for a person, the system should make available to them tasks from lower priority projects.
Automate management and task allocation.Management uses up people's time and energy that could be better applied to producing output. The dev mod system should reduce the amount of time spent managing people and tasks by automating the process.
Remind everyone of what they should be working on.With instant messaging, email and pagers, the dev mod system can alert people to changes in project schedules and remind them which tasks they should be working on.
Document everything.With todays large hard drives and efficient search programs there is no reason not to record every detail of project development and make the details available at our finger tips. We aim to fulfill these objectives with our dev mod system. The design of the system should be such that working with it feels natural, requires as little effort and involves as little waste as possible. The dev mod system is constantly being tweaked. This is what we have so far. -- top -- Terminology
ProjectA project is a problem we want to solve or a goal we want to achieve. Typical projects include "Allow customers to renew Internet subscription online.", "Install v92 compatible modems in system servers.", "Upgrade phone system to latest version." A project consists of a many dev mods.
Project PhasesTo help organize projects and ensure a methodical approach, projects are broken into phases. Phases include Brainstorming, Planning, and Development. Details on each of the phases will follow.
Phase StepsEach project phase is further divided into phase steps. The Brainstorming phases is divided into the steps of Individual brainstorming and Group brainstorming. Each phase step has different dev mods. Dev mods from the first phase step are worked on first. Once all dev mods from a particular phase step are completed, we move onto dev mods from the next phase step.
Dev ModDev mod is short for development modification. A dev mod is a task, one step of all the steps that needs to be completed in order for project to be completed. Generally a dev mod should take from two hours to two days of focused effort to complete.
Dev Mod StagesDev mods are broken down into different stages. The current stages we use originated from requirements of Programmers. When programming a feature, there are a series of stages that one goes through including writing a solution specification, defining tests, coding the solution, alpha testing and documenting. For each dev mod, each of these stages may be assigned to a different person.
DependencyA dependency is a dev mod that must be completed before another mod can be started.
Do Not DisturbIn order to focus on completing dev mods, people need extended periods of time free from interruption and distractions. We've implemented two Do Not Disturb (DND) periods each day to accomodate this, one in the morning and one in the evening, each consisting of three hours. During this time communication is minimized to scheduled meetings. Messenger services are limited to alerts and reminders, and most office doors are closed. During the several hours between the DND periods everyone is welcome to engage in open discussion about whatever dev mods they may be working on, or the latest release of Ubuntu, or whatever. The terminology may be a little daunting at first. It should be noted the phases, steps and stages were implemented as a way of organizing the system. In the day to day workings, people encounter the dev mod stages only. As they check the stages off as completed, the system updates the progress of the projects and alerts people if actions are necessary providing them with instructions of what to do next. -- top --ProjectsAll development is done by project. There are several types of projects.
Standard ProjectsMost common are Standard projects that address a specific problem or feature. These projects are large and normally involve many dev mods and the participation of many people.
Feature/Bugfix ProjectsThe Feature/Bugfix Projects contain miscellaneous feature requests and bug fixes that don't warrant a project unto themselves. Each mod is self contained and can normally be completed by one or two people.
Ongoing ProjectsSeveral projects are flagged as ongoing. These projects do not proceed by phases and are never considered completed. Dev mods are continually added to them on an ongoing basis. Examples include the Reminder project, which contains dev mods for miscellaneous tasks that are completely on a daily or weekly basis, and the Review Dev Mod project, which contains dev mods to review mods recently added to the system. This is the "Project Tree", a list of projects, with one project expanded: 
-- top -- Dev ModsA Dev Mod is a task that needs to be completed. Since many tasks involve coding software, dev mods are divided into stages for spec'ing solutions, developing, testing, and so on. Each stage can be assigned to a different person. This is what the dev mod edit page looks like: 
-- top -- Dev Mod DocumentationEach dev mod has its own wiki-style document. Problem definitions, specifications, and suggestions from reviewers are recorded in the document. The wiki-style makes it simple for users to add content quickly and apply basic formatting. The docs permit text snippet highlighting, revision timestamping, ordered and unordered lists, and web page links. Apart from specifications, we use wiki docs to communicate our ideas about the dev mod to each other. Rarely do we do anything verbally. Everything is written in the doc and then passed on to the next person, somewhat like an email conversation. One person records the problem and assigns the dev mod to another. That person suggests a solution writing it in the wiki doc, and assigns the mod to another person. That person reviews the solution and adds their ideas and comments. A spec is recorded. The mod is passed to the person assigned to complete it. As they work on it, they record pertinent information, minor obstacles and work arounds, configuration settings, concepts that should be formally documented. These notes are stored in the wiki doc. What's happening is we're documenting the system as we go without any extra effort. The wiki doc *is* the documentation. If ever we need to look up how something worked, how it was designed, it's recorded in the wiki doc. Wiki docs may include many suggestions for solutions and debate about which is best. They may include false starts, plan A is started but midway we come across an unforseen obstance and determine it is not feasible, and plan B is implemented. The wiki doc doesn't just record what we do, it records why we do things a certain way. This is invaluable. We record our mistakes so we can reference them later and not repeat them. We use the wiki style for all documentation. We have a document search tool that indexes all wiki docs and simplifies digging up material and information on file. Here is what a dev mod wiki document looks like: 
-- top -- Todo ListThe todo list reports all dev mods assigned to you at any given time displayed in order by priority. Under normal conditions, you select the dev mod from the top of the list and work on it. When you are done, you flag it completed. If you refresh your todo list, the completed dev mod will be removed and a new dev mod will be at the top of the list. Here is an example todo list: 
-- top -- PrioritizationAn integral part of the dev mod system is dev mod prioritization. Dev mods are ordered on everyone's todo lists in order of priority. The system dynamically reprioritizes all todo lists as changes occur. The priority is determined by many factors, listed in order below. -- top --Flagged as Super CriticalDev mods that have been flagged Super Critical are prioritized ahead of all other dev mods. Super critical flags can be used in emergencies and for time-sensitive issues. A dev mod to fix a crucial bug can be flagged critical so it appears at the top the todo list of the person it's assigned to. -- top -- Project PriorityThe system follows multiple projects at any given time, and each project is ranked by priority. By default, new projects are ranked lowest priority, but project managers can move any project up in priority at any time. Dev mods belonging to a higher priority projects are prioritized on todo lists ahead of dev mods belonging to a lower priority projects. -- top -- Dev Mod Priority CategoryEach dev mod is categorized as High, Medium, or Low priority. This is used to control prioritization of dev mods within the same project. Dev mods categorized as High priority are prioritized on todo lists ahead of dev mods categorized as Medium priority. By default dev mods are categorized as Medium priority and in practice this is rarely changed. The feature is available to allow project managers to override systematic prioritization and allow them to order mods however they see fit. Dev mods that are set to High priority are ranked higher priority than the Medium priority dev mods on the critical path. -- top -- Critical PathThe critical path is the longest estimated line of dependencies in the project. It represents the shortest possible time that it would take to complete the project. Any time not spent on dev mods on the critical path, delays the project completion date. As such, dev mods on the path are prioritized on todo lists ahead of dev mods in the same project that are not on the path. The critical path is dynamic. If a dev mod is completed, an estimate time is modified or a dev mod is added to the project, the critical path is recalculated and mods are reprioritized accordingly. -- top -- Dev Mod PriorityThe Dev Mod Priority allows project managers to prioritize dev mods at the most basic level. Within any given project, dev mods are ranked for priority just as projects are. This ensures no two dev mods have the same priority. New dev mods by default are prioritized lowest in the project. It is rare that project managers change the priority, but the feature is included to give them control to arrange the priorities in any order they desire. -- top -- Alerting SystemThe dev mod system can alert users of changes using our internal instant messaging system. If someone has added a critical dev mod to the system, and it is assigned to you, you will receive a message indicating you should switch to the critical dev mod as soon as possible. If your todo list is reprioritized, the system will send you a message indicating the dev mod you should work on. When all dev mods are completed for a project phase step, the system messages project managers indicating they should move the project on to the next phase step. This is an example of an alert message: 
-- top -- What is the Do Not Disturb zone?The Do Not Disturb (DND) zone was implemented to guarantee everyone quiet time when they can focus on dev mods without interruptions or distractions. DND hours are as follows
11:15 am to 2:00 pm
6:15 pm to 8:45 pm *
* On Fridays, DND ends at 7:45 since everyone leaves an hour earlier.
During DND periods, everyone should focus on working on dev mods on their todo list. Respect others by not talking to them unless it's necessary to do the dev mod you are working on, and then arrange a meeting in an office so it will not disturb others. Jabber, the messenger service, is configured to withhold messages during DND. Others won't receive messages you send them until the period is over. If you have questions about the dev mod you are working on, you can ask the question in the dev mod and then send the mod back to the person that assigned it to you, or wait until the DND is over to ask them. The jabber conference room is also available to discuss issues. It is important to understand the spirit of DND. It is not about imposing an overbearing system and trying to control how you work. It's about understanding human nature, computers and priorities. Everyone who has ever used a messenger service I am sure has found themselves intending to send a short message and then discovered they got into a conversation with someone and before they knew it a half hour had passed. Messengers don't distinguish high priority messages from trivialities. When you receive a message, you feel compelled to reply. Replying distracts you from your current train of thought and makes you less efficient. -- top -- What should I be working on?In the vast majority of cases, everyone should work on the on the dev mod at the top of their list. The dev mod system is designed to work most efficiently when everyone does this. In some circumstances it is necessary to postpone the dev mod at the top of your list as, for example, when you have to wait for a test program to complete and it's expected to take several hours. Use common sense. If you have to wait 15 minutes before you can continue, then it's not worth the mental effort to turn your focus to another mod, and then a few minutes later refocus back to the original mod. If you find yourself waiting, see if there is something you can do related to the mod. Review the work you've completed, comment code, prepare documentation, plan the next step, etc. Finally, you should avoid working on two mods at once. It may seem more efficient, but jumping back and forth between two objectives takes time and energy, and makes you prone to mistakes and doing an incomplete job. -- top -- What if someone asks me to work on something without a dev mod?There are very few situations where tasks are done without a dev mod. If someone asks you to do something, request that they create a dev mod and assign it to you. The use of dev mods is not a "control freak" issue. It's about maintaining order so management can see current progress and have some small ability to predict future progress. It's about ensuring everything we do is documented, and it's about keeping your sanity. If five people ask you to do something at once you are going to a) forget a few of them, b) do them quickly and not document them well and c) be exhausted by the end of the day. The dev mod system will ensure you only have to work on one thing at a time, you get to focus and do each thing well, nothing gets dropped, and you can pace yourself. Don't let yourself get into the habit of not using it! Critical situations are an exception to the rule. If essential services are down, if the network is unavailable, if the building is on fire, then certainly, ask people to drop what they are doing without a dev mod. Dev Mod System Reference-- top --Project PhasesHere is a picture of a single project displaying its phases: 
-- top -- RationaleThe basic idea behind project phases is to separate the work into coherent sections. Normally ideas for a project have to be brainstormed before planning can begin. Planning has to be completed before development can be started. The projects phases categorize the steps involved in completing a project and have no functional purpose in the system. The phases are listed and described here: -- top -- BrainstormingThe Brainstorming phase involves these aspects:
-- top -- PlanningWith the goal of the project clearly defined and the solution selected, the next phase involves planning. This includes:
-- top -- DevelopmentThe Development phase involves these aspects:
-- top -- ReleaseThe Release phase involves the following aspects.
Testing in the Release phase differs from testing in the Development phase. Here testing focuses on the project as a whole. Development tested individual parts. Release tests how well those parts work together. Wrapping up involves doing tasks that were dependent on the completion of the project. For example, if new hardware was setup, the old hardware may need to be disposed of. If new services were used, old service contracts may need to be ended. -- top -- Project DocsThe Project Docs phase involves final documentation. This may include:
-- top -- Phase StepsProject phases are divided into phase steps. Dev mods stages belong to a particular phase. The dev mods stages for all dev mods are completed one phase step at a time. For example, Planning phase has a Problem Definition step. For each dev mods in the project, a clear definition of the goal of the task is recorded. Once that is completed the project moves on to the Development phase. Then all dev mods are developed. All dev mods from the current phase of a project must be finished before the project moves to the next phase. Here is a project displaying its phases and them in turn displaying their steps:  A list and description of the Phase Steps follows: -- top -- IndividualIndividual brainstorming involves a person recording their definition of the project problem/goal and documenting as many ideas for solving as possible. At the brainstorming stage, solutions are recorded regardless if they are known to be feasible or not. -- top -- GroupGroup brainstorming involves everyone reviewing the Individual brainstorming results. The group determines a formal project definition and determines the best solution. Group brainstorming may be done in a group meeting, or by circulating a dev mod to members of the project. -- top -- Define Project ObjectiveThe formal project definition is recorded. Included are the objectives of the project. Those will be reviewed at the end of the project and used to measure the success of the project. -- top -- Problem Definition (Phase Step)A tree structure of tasks and dependencies is created and critiqued by project members. People are assigned to tasks. A dev mod is created for each task. Assigned people create a clear problem definition for the dev mod. The definition explains the objective of the specific dev mod, and may include supplementary information that will be useful for the person responsible for spec'ing the solution. -- top -- Development (Phase Step)The Development phase step is where work on tasks is done. Each dev mod is completed one at a time. Work on dev mods proceeds through different stages as explained in the Dev Mod Stage section. -- top -- Pre-Beta TestingDuring development work within individual dev mods is tested. In the Pre-Beta Testing, the project system as a whole is tested. Do the parts work together as a whole? Testing is done in a test environment. If any problems are found, the project is returned to the Development phase where issues are resolved. -- top -- User DocsBefore a project can be released to live, end users need to know how to use the new features. Documentation is written and distributed. The end-users will vary from project to project. They can be customers, employees, developers, and business associates. The means of providing the documentation varies as well. They include internal wiki docs, emails, and bulletin board notices. -- top -- Beta Test (Phase Step)The project is released to live. Users test all features of the project and report problems, suggestions for improvement, etc. If there are critical problems, the projects is returned to the Development stage. Minor issues are recorded as dev mods in Feature/Bug Fix projects. -- top -- WrapThis step encompasses any tasks that need to be completed after release of the project. These could include retiring systems replaced in project, ending service contracts made obsolete by project, and general cleanup. -- top -- Dev Mod Documentation (Deprecated)This phase step is deprecated. At one time we did not use wiki docs for dev mods. Nor did we have a good tool for searching dev mod documents. Admin tagged sections of dev mods suitable for archiving and ran a script that extracted the sections and archived them. -- top -- Summarize ProjectThe end result of the project is compared to the original goal to ensure all objectives were met. Any specific lessons learned from the project are documented. -- top -- Formal DocsFormal technical documentation for network admins and coders are created as necessary. -- top -- Dev Mod StagesThis is a dev mod stage checklist:  Here is a list of the stages and their descriptions: -- top -- Problem DefinitionBriefly but clearly describe the objective of the mod. If the mod is for a new feature, define the what and the why of the feature. If the dev mod is a bug fix, include a description of the symptoms and instruction on how to simulate it. Include any pertinent information related to the dev mod, for example, reference sources, preliminary research results, and example data. -- top -- Spec SolutionInvestigate how to solve the problem, determine the solution and record the steps involved. If one solution does not stand above others, brainstorm different possibilities, indicate the pros and cons of each, select the option you think is best, and indicate your reasons. Do not implement any changes at this stage. -- top -- Solution ApprovalReview the solution provided from the Spec Solution stage. If the solution is agreeable, add any additional recommendations you may have, and move the mod onto the next stage. If you see problems or shortcomings with the solution, indicate you concerns and return the dev mod back to the Spec Solution stage. -- top -- Assign to EmployeesReview the employee assignments for all remaining stages of the dev mod and make changes where necessary. -- top -- Estimate TimesEstimate the time required for the each of the remaining stages of the dev mod. -- top -- Define TestsDefine a test or set of tests that will prove that the objective is met. Troubleshooting a problem involves running a test, proving failure, making a change, then re-running the test proving success. Indicate the test(s) suitable for this dev mod. If the problem involves a new feature, create a complete checklist of expectations and requirements, and tests that will illustrate that the solution has satisfied them all and is thus complete. -- top -- Code SolutionImplement the solution in the test environment. -- top -- Alpha TestRun the tests defined in the Define Tests stage to prove that the solution is complete. Return the dev mod to the Code Solution stage if any tests fail. -- top -- Code ReviewReview the solution implemented in the Code Solution.
Questions to ask: * Is the solution complete? * Are there any bugs? * Does the solution follow standard procedures? * Is the solution well commented? * Does the solution fit the big picture? * In general, are there any improvements recommended? If modifications are deemed necessary, indicate them in the dev mod and return the dev mod to the Code Solution stage. -- top -- SummaryReview the Specifications and summarize the mod for the person doing the User Documentation. If the dev mod is complex, for example, it forked or included several solution approaches, then indicate the approach that was eventually used. Summarize and indicate in the dev mod anything that the end user should be aware of. If a dev mod doesn't change anything that will affect the end user, or the change is minor, and thus no user docs are required, then indicate so. -- top -- User DocumentationProvide documentation for the end user. The documentation should include a brief description of the problem and the solution, general usage instructions, procedure or policy changes, setup instructions if necessary, and a list of the effects the end user can expect when the changes in the dev mod are made live.
As necessary * Send end users jabber messages. * Send end users a bulletin. * Create a KB entry and send end users links to it. -- top -- Apply SolutionInstall the solution in the live environment. -- top -- Beta TestTest the solution in the live environment. -- top -- DocumentationCreate documentation suitable for developers and administrators. -- top -- Documentation ReviewReview the documentation created in the Documentation stage. -- top -- CategorizeThis is not one of the standard steps included in each mod. The mods that contain this step only have this one stage, and the purpose is solely to categorize dev mods. To do it: Review the dev mod in terms of its location in the project tree.
Questions to ask: * Is the dev mod necessary? * Is the dev mod in the correct project? * Is the dev mod in the correct project phase? * Does the dev mod have the correct priority. |
||