Last modified 16 years ago
Last modified on 03/23/09 15:25:07
Analysis
Overview
The tasks for imroving the process define rules that ease the work process.
Task requirements
- Throughly review PROCESS
- See comments section for some improvement ideas
- Create a list of documents similar to important docs that contains only the documents that every team member MUST read.
- Create sub-pages for the processes of different teams
- Discuss with team leaders of the functional teams the differences between their processes - you may decide PROCESS/Functional? more adequate than Base Main Server.
- Explain meetings further
- Interteam meetings
- Weekly
- Progress checks
- Sprint opening
- Sprint closing
What is done on these meetings, what should one prepare. Exact times are not important - just which meetings are regular and periods.
- A new requirement is to simplify the PROCESS.
Task result
Improved PROCESS page. Subpages of the process page linked in it. A simplified version of the current page.
Implementation idea
- Pair with the team leaders or team members for sub-team team process pages.
Suggestion for the simplified PROCESS page
SCRUM * iterative incremental process of software development * counts on one to take the initiative * roles * product owner - the voice of the customer * scrum master - solves problems * self-organizing team - does the progress * regular standup meetings to show progress, plan and solve problems * opening, closing and other meetings Teams * Analysis - does the specification of features, keeps the product consistent * Functional - does the design and implementation of the platfoem and features * Release - does the final touch, delivers the final product Workflow Tickets are the product backlog * New - part of the product backlog, hasn't been worked on * Analysis - what has to be done * Design - how it should be done * Implementation - actual implementation * Testing - problems, documentation Each of these has * Started - in progress, someone works on it * Finished - ready for a review * OK - reviewed and ready for the next phase (if any) Discipline * workday starts 9:30 * work outside of office should be approved by the team leader * daily and monthly reports * internal backlog * meetings Member requirements * Work towards the goal * Be honest * Take initiative * Look around * Seek improvements * Seek the most appropriate solution * Quality is not negotiable. Scope and resources are. * Accept the challenge
Process subpages:
PROCESS/Overview
PROCESS/SCRUM?
PROCESS/InternalBacklog
PROCESS/Teams
PROCESS/Workflow
PROCESS/Rules
PROCESS/Discipline
Related
PROCESS_R2
PROCESS_R1
PROCESS_R0
How to demo
Show Process page and subpages. Explain improvements.
Design
The following structure will be used as it seems to be more accurate
process requirements for joining - related to all people interested in participating discipline - related to internal rules software development process - scrum terms in the project product backlog sprint (iteration) meetings sprint backlog task splitting choosing a task implementing a task workflow explanation team - team split, roles
- For sections will be used bold instead of headings
- The aim is to make the document as compact as possible
- Links will be more visible
- The PROCESS will be done by including the subpages with "Edit" link for each section for more convinent editing.
- Following should be updated:
- Workflow - groups (group tickets) will be added
- Teams - analysis, functional and release
- Rules section will be renamed to MemberRequirements
- Inconsistent formatting will be removed
- Overview page
In order to produce the highest quality product (both internal and external), we have defined process guidelines in this section. (This is related to the SCRUM mandatory definition of the done status state.) This will help us meet the following challenges: * Internal quality (quality of code) * External quality (quality of the visible product) * Documentation reading (many things are written, few things are read) * Reducing unuseful process overhead - Scrum page
We are continuing to use SCRUM methodology (info at http://en.wikipedia.org/wiki/SCRUM). What is new: * Trying to have much higher quality. * The sprint backlogs are on wiki pages ([wiki:ITERATION_01] for example). * The [wiki:PROCESS/Meetings Meetings] are: * weekly meetings * progress checks * Using a customized and flexible [wiki:PROCESS/Workflow Workflow] We have an internal backlog which should track: * Impediments backlog * Documentation backlog * Smells * Open Questions Here is the document: Backlog
The internal backlog structure may be found and linked in this document instead of bullet listing it.
- Teams
As team splitting is different now, the Teams subpage should contain different information:
== Teams == === Team splitting === We define three teams for improved performance and management while developing Sophie 2. The three teams are as follows: * Analysis team - responsible for analysing the tasks for the current and the next iteration and for the testing reviews. * Functional team - designing and implementating the tasks from the product backlog. * Release Team - responsible for the releases, the reviews of the implementation phase, the testing phase and bug fixing(See [wiki:PROCESS#TaskStates]). For now the analysis reviews are made internally in the team which is responsible for the corresponding task(i.e. S2S_TESTING_SERVER_R0 analysis review is made by the server team). The design reviews are done by a functional team member(not necessary from the same team). The teams are not fixed, it is recommended to change the team members each iteration or for every several iterations. == Team Roles == For each team there is team leader defined. They are not fixed also and can be changed even during the process depending on their productivity as team leaders. The other developers are called team members. The team leader should: * be responsible for the progress of his/her team on the progress checks * represents team members on the weekly meetings if they are not present * gives direction to the team members if they don't know which task to take * helps the team members if they have questions and obscurities or directs them to the person who can help them. The team members for each task can be in the role of: * reviewers - a person who is assigned to review a task * implementors - the workers on a given task * freelancers - remote implementors (or reviewers) with different working time The Release team has an internal process described in [wiki:ITERATION_03/Release/Process]. [[BR]] Here is the Analysis team working process: [wiki:ITERATION_03/Analysis/Process].
- Workflow
== Workflow == === Diagram === Each taken task in the current sprint should pass trough the following phases described in this diagram: [source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png] === Explanation Of States === * '''new''' * task is waiting to be taken, and someone to determine what should be done * '''analysis started''' * to learn how to write good analysis, see [wiki:PLATFORM_STANDARDS_ANALYSIS Platform Standards Analysis] * there should be at least one example of how to do one or more things that should be done * it should take not more than 0.25 of the task effort * '''analysis finished''' * it is already determined what should be done * the task is waiting for review. (Wait for the review of the analysis before starting the design otherwise your work can be for nothing!) * '''review''' * the reviewer looks through the analysis to see if it is correct(observing the [wiki:PLATFORM_STANDARDS_ANALYSIS] document and trying to improve it) * the analysis should apply to [wiki:PageTemplates/TaskPageTemplate#Analysis its template] * '''analysis ok''' * the reviewer decides that the analysis of the task is correct * '''design started''' * the implementor is designing the task or in other words tries to decide how it should be done * it is not compulsory but recommended that the design should be made by the implementor * it is recommended that the design should not be made by the analyzer of the task * designing is not only getting an idea of how to do something but understanding the concept, step by step * for many tasks the design phase should take most of the time * '''design finished''' * it is determined how the task should be done * it is designed and is waiting for review. * '''review''' * the reviewer looks through the design to see if it is correct (observing the [wiki:PLATFORM_STANDARDS_DESIGN] document and trying to improve it) * The reviewer can imagine himself as an implementor and see if he can implement the task following the design without problems * '''design ok''' * the reviewer decides that the design of the task is correct * '''implementation started''' * the implementor makes an attempt to complete the task * he/she should fulfill task requirements * he/she should follow the design * he/she should write an Implementation section of the task as the result of the implementation * '''implementation finished''': the implementer decides that the implementation of the task is ready * '''review''': the reviewer look through the implementation to see if it is correct * '''implementation ok''' * the reviewer decides that the implementation of the task is correct * the implementation section must be filled * '''testing started''': there should be appropriate tests written for the task * Standards for testing can be found in the following documents: * [wiki:PLATFORM_STANDARDS_AUTO_TESTS] note that auto tests are usually part of the design. * [wiki:PLATFORM_STANDARDS_MANUAL_TESTS] * '''testing finished''': testing state is done, waiting for review * '''review''' * the reviewer looks for missing or wrong tests * if there are any, the reviewer may decide they can be added later * if they are too important or wrong they should be fixed - the review fails * '''testing ok''' * the last task state * notes * failing a state (for example moving from implementing to analyzing because implementation failed) requires that the state of the product is reversed to the initial state * the transitions of each state are defined in [source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png Workflow diagram] * for every task we have tickets which are available for reading and filtering in the View Tickets section in Trac. For every state of a particular task, you have to go to its ticket and update its status depending on the state you are working on. There are custom ticket fields which we should filled with information about the task phase owner, reviewer and score. There is also importance field(See [wiki:SCHEDULE_WBS_DEPENDENCIES_R1#Design] for its usage). See [wiki:SCS_ISSUE_TRACKER_SETUP_R1] for more information about our issue tracking. * Reviews should have reasoning for the given mark. These better be connected to concrete requirements in the standards.
- Team member requirements
1. '''Work towards the goal!''' * No matter what this document defines, or how specifically your task is defined, there is no way to define exactly what should be considered good for reaching our goal, and what should be considered bad. * You have to work towards the goal. * When you work on something, you have to understand why and how it is related to our goal. * You have to try to drive the whole team towards the goal (no one alone is capable of reaching it). 2. Be honest! * You have to present the situation to the leader as is. * Do this, even if it does not look good. * For example, if you have no idea how to make something, don't say "almost done" to the leader. 3. Take initiative! * If you find a way that you can make something better for the team, don't wait but propose that it to be done. 4. Look around! * If you see problems in the code, in the product, in the organization, or whatever, announce them. * Try to keep an eye on what other people do (either for things you can learn from, or for things they are doing poorly). * Try to get a global vision of what is happening in our team. 5. Seek improvements (for yourself and for the team) * No matter how good you are, there are always more things you can learn, or skills you can acquire (note that knowledge and skills are different things). * Improving and learning is your responsibility. * Not trying to understand how things work, but learning that this does this, and that does that will lead you nowhere! Really! Even if you've programmed for 20 years it's possible to make this mistake. 6. Seek the most appropriate solution! * There is no perfect code. There is no perfect solution (or even if there is it is not reachable). * There are no general good design rules - a design is good if it works well, if it is easy to use (for example, if it is a library, the clients don't need to write much), if it is simple, has good performance, is modifiable/extensible, testable, etc. Neither the number of design patterns used solves this, nor a code convention... nothing. You have to find a design that is good. * Hacking around just to make things work is usually a time bomb. It is not acceptable to do this, because saving 1 day this month usually costs 7 days the next month. * What we should do is to seek something between just making it work and making it perfect, but closer to perfection than just working. * That is, seek a good solution. 7. Quality is not negotiable! Scope and resources are * If something cannot be done with acceptable quality, given the resources (time) and scope (functionality) that it has, then we will either reduce the scope or increase the resources. * We are not allowed to reduce quality! 8. Accept the challenge! * We are not doing the next Store Information System, the next Lawyer's web site, nor the next database module for big company X * What we are doing is something that only few companies in the world can do, and even many of them are not good enough. * There are no instructions on "how to make the next generation desktop publishing software"!
- Discipline
1. You whether follow the process or suggest improvements. * Self-discipline is needed. * If you don't have enough self-discipline, then this team is not appropriate for you (you should go to a company that forces you to be disciplined by other means). 2. Our workday starts at 09:30 am sharp. 3. You may work from home, or from other locations but only with the approval of the team leader. 4. You have to write in the end of every working day a daily report about what have you done that day. You have to write at the end of every iteration a monthly report - see [wiki:REPORTS] page to learn how to write reports. 5. You have to fill the internal backlog(especially the Daily Availability Sheet) every working day or at least before weekly meeting. Here it is: http://spreadsheets.google.com/ccc?key=p-0Oq38E1ayuX-E_kPfPxbg&hl=en 6. You must be present at the meetings or at least you have to be represented by someone.
- Timeboxing will probably be linked into the workflow.
- Current project requirements should be moved to platform standards general.
- Edit button will be added for each section as these will be included in process page, not copied Edit
- Links between PROCESS and PROCESS/Simple will be included.
- For analysis, functional and release team subpages the existing pages from Iteration 3 will be used (not for the functional)
Implementation
- PROCESS/Simple done according to the Design
- PROCESS/Meetings explained all of the meetings
- PROCESS All of the subpages are included. The problems with the table of contents for the PROCESS page remains - when headings are part of the subpage, toc macro doesn't work.
- The Release and Analysis teams processes are added. The functional team doesn't need to have separate process (since the PROCESS is enough itself)
- The comments from PROCESS are taken in mind and described where needed
Testing
Comments
(Write comments for this or later revisions here.)
