CP<sup>2</sup> RFC-01 [LEADERSHIP STRUCTURE]
-
Requested by: Nitron All Request For Comments (RFC) should be posted on my message board[^] where I will then post them here at the proper time. BEGIN ================================================= Nitron wrote: When forming the teams, we will need to fill several positions: Project Manager - responsible organize WBS / tasks / deadlines / deliverables Systems Lead - responsible for keeping systems engineers on track | |----- Systems Engineers - responsible for system design and defining requirements Software Lead - responsible for keeping programmers on task | |----- Software Engineers - responsible for implementing system requirements Test Lead - Responsible for keeping testers on track | |----- Software Testers - responsible for verifying bulletproof code | |----- System Testers - responsible for independently verifying system requirements Configuration Managment Lead - responsible for versioning / bug tracking / problem resolution | |----- Quality Control - responsible for CM and formal release procedures Then aside from coding, we need graphics artists, marketing, and support personnell. This will provide well defined roles and create synergy within the teams. ================================================= END
NOTE: Keep in mind how I would like to see the article series structured. See [this post](http://www.codeproject.com/script/comments/forums.asp?forumid=1645&df=100&app=50&select=514096#xx514096xx)[[^](http://www.codeproject.com/script/comments/forums.asp?forumid=1645&df=100&app=50&select=514096#xx514096xx "New Window")] for more info.Jason Henderson
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
First off wanted to say thank you Jason. You've done a great job so far and we wouldn't be this far without your lead. :rose: As for the proposed structure. I like the fact that it lays out roles. Who fills the roles should be up to the PLs for each project. While this particular structure may not be the best in the opinion of everyone, I think it is a good start. No doubt some individuals will fill more than one role. Some roles will have more than one person. The PL will probably fill most of the lead roles. The structure lays out an important timeline of how to proceed. 1. We gather resources (people) for each project. (PL) 2. Then divide assignments to each person based upon qualifications and strengths. (PL) 3. Then define requirements for the project. (Those interested in project, or just involved) 4. Decide what will be included in first rev. Keeping in mind that the shorter the dev cylce the more likely success. Future revs to follow. (PL and leads) 5. Requirements defined and documented (Systems Engineers) 6. Review and testing of requirements to ensure everything in order. (System Testers. Should not be same as Systems Engineers. Never debug your own work.) 7a. Once requirements approved by PL coding begins. (Software Engineers) 7b. In parrallel, Test plans are created and documented based upon requirements documentation. (Software Testers) 8. Coding completed and reviewed by testers. Modifications made if discovered. Additional tests documented based upon specific code segments. 9. Testing done and results reviewed. 10. Fixes made due to test results. 11. Repeat steps 8-10 as necessary. 12. Product release. As for QA, this would be active throughout entire process. They would be integral in code reviews. Code reviews should be periodic and not wait till end. Final code review for purposes of forming new tests. --
"The money power of the country will endeavor to prolong its rule by preying upon the prejudices of the people until all wealth is concentrated in a few hands and the Republic destroyed." -- Abraham Lincoln
-
Marc Clifton wrote: Of course, in reality, several of these jobs will probably be combined or shared by one or more people. Yes. I'll probably end up in more than 1 job. :) Marc Clifton wrote: How is a system lead different from a software lead? The software lead leads the creation of the software, and the systems lead leads the care of the systems the devs work with (CVS, etc). Marc Clifton wrote: What's the difference, functionaly, between a lead and an engineer/tester? the lead coordinates the work, the engineer does the work. :)
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiWell, yes, I suppose that's obvious, but these things really need some formal definition so people know what is expected of them. Personally, I think it's too management topheavy. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files" -
Well, yes, I suppose that's obvious, but these things really need some formal definition so people know what is expected of them. Personally, I think it's too management topheavy. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"Marc Clifton wrote: Personally, I think it's too management topheavy. And it would be, except that one person can take more than one role. It would be nice if people could "slide" into it according to their abilities, but I don't know how that would work. Maybe in the course of discussions, we will get some kind of idea of who will do best at what.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
Requested by: Nitron All Request For Comments (RFC) should be posted on my message board[^] where I will then post them here at the proper time. BEGIN ================================================= Nitron wrote: When forming the teams, we will need to fill several positions: Project Manager - responsible organize WBS / tasks / deadlines / deliverables Systems Lead - responsible for keeping systems engineers on track | |----- Systems Engineers - responsible for system design and defining requirements Software Lead - responsible for keeping programmers on task | |----- Software Engineers - responsible for implementing system requirements Test Lead - Responsible for keeping testers on track | |----- Software Testers - responsible for verifying bulletproof code | |----- System Testers - responsible for independently verifying system requirements Configuration Managment Lead - responsible for versioning / bug tracking / problem resolution | |----- Quality Control - responsible for CM and formal release procedures Then aside from coding, we need graphics artists, marketing, and support personnell. This will provide well defined roles and create synergy within the teams. ================================================= END
NOTE: Keep in mind how I would like to see the article series structured. See [this post](http://www.codeproject.com/script/comments/forums.asp?forumid=1645&df=100&app=50&select=514096#xx514096xx)[[^](http://www.codeproject.com/script/comments/forums.asp?forumid=1645&df=100&app=50&select=514096#xx514096xx "New Window")] for more info.Jason Henderson
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
Firstly, the intent wasn't to formally structure or "compartmentalize" a team. I just wanted to formally identify roles that define a well balanced software team. As was mentioned, some people will likely fill several roles at the same time, while others may not. So for a clearer definition of the terminology, consider this: Systems Lead - When assuming this role, you need to view things from the system-level. That is, not to have vision clouded by the details of the bug you spent all morning trying to fix. A system-level view has one target audience: the customer. What does the customer need? (Remember, the customer most likely doesn't know what they want.) How do you plan to meet that need? Is the current design in line with the project goals and mission statement? The systems lead has the highest view of the project, sometimes higher even than the project manager. Systems Engineer - These people carry out the system-level objectives and produce concrete output in terms of documentation and system design. The systems engineer carefully considers the customer's need and approaches it with a software mind. The systems engineer takes these high-level goals and visions and breaks them down into system-level requirements. That is, functional requirements that are divided into manageable and logical components that, when all met successfully, roll up into a deliverable product and lead to a happy customer. Software Lead - The software lead is different than the systems lead in that the level of requirements is lower. Rather than dealing with global high-level requirements, the software lead has a logical set of functional requirements from which to work. This is where the rubber meets the road so to speak. The software lead considers things like the actual implementation of a certain module of code. (Notice the systems engineer never even came in contact with the mechanics of the actual implementation.) The software lead keeps the software engineers focused and on task. Software Engineer - These are the individuals responsible for designing the detailed mechanics of an implementation and actually coding it. In all aspects, these individuals are more involved than the proverbial "code-monkey". In this infrastructure, the software engineer commits more than just code to the project, they commit experience and design. The software engineer has a dark side as well... Just as the systems engineer documents and delivers system-level functional requirements,
-
Firstly, the intent wasn't to formally structure or "compartmentalize" a team. I just wanted to formally identify roles that define a well balanced software team. As was mentioned, some people will likely fill several roles at the same time, while others may not. So for a clearer definition of the terminology, consider this: Systems Lead - When assuming this role, you need to view things from the system-level. That is, not to have vision clouded by the details of the bug you spent all morning trying to fix. A system-level view has one target audience: the customer. What does the customer need? (Remember, the customer most likely doesn't know what they want.) How do you plan to meet that need? Is the current design in line with the project goals and mission statement? The systems lead has the highest view of the project, sometimes higher even than the project manager. Systems Engineer - These people carry out the system-level objectives and produce concrete output in terms of documentation and system design. The systems engineer carefully considers the customer's need and approaches it with a software mind. The systems engineer takes these high-level goals and visions and breaks them down into system-level requirements. That is, functional requirements that are divided into manageable and logical components that, when all met successfully, roll up into a deliverable product and lead to a happy customer. Software Lead - The software lead is different than the systems lead in that the level of requirements is lower. Rather than dealing with global high-level requirements, the software lead has a logical set of functional requirements from which to work. This is where the rubber meets the road so to speak. The software lead considers things like the actual implementation of a certain module of code. (Notice the systems engineer never even came in contact with the mechanics of the actual implementation.) The software lead keeps the software engineers focused and on task. Software Engineer - These are the individuals responsible for designing the detailed mechanics of an implementation and actually coding it. In all aspects, these individuals are more involved than the proverbial "code-monkey". In this infrastructure, the software engineer commits more than just code to the project, they commit experience and design. The software engineer has a dark side as well... Just as the systems engineer documents and delivers system-level functional requirements,
That was fantastic Nitron, a wealth of knowledge and good sense. I certainly see us putting together a CPSF (Code Project Solutions Framework) for developing software. We cannot just come out of CP2 with just applications. We should come out with a strong process model as well. From the sounds of it you would be the lead of that project :)
Paul Watson
Bluegrass
Cape Town, South AfricaChris Losinger wrote: i hate needles so much i can't even imagine allowing one near The Little Programmer
-
Requested by: Nitron All Request For Comments (RFC) should be posted on my message board[^] where I will then post them here at the proper time. BEGIN ================================================= Nitron wrote: When forming the teams, we will need to fill several positions: Project Manager - responsible organize WBS / tasks / deadlines / deliverables Systems Lead - responsible for keeping systems engineers on track | |----- Systems Engineers - responsible for system design and defining requirements Software Lead - responsible for keeping programmers on task | |----- Software Engineers - responsible for implementing system requirements Test Lead - Responsible for keeping testers on track | |----- Software Testers - responsible for verifying bulletproof code | |----- System Testers - responsible for independently verifying system requirements Configuration Managment Lead - responsible for versioning / bug tracking / problem resolution | |----- Quality Control - responsible for CM and formal release procedures Then aside from coding, we need graphics artists, marketing, and support personnell. This will provide well defined roles and create synergy within the teams. ================================================= END
NOTE: Keep in mind how I would like to see the article series structured. See [this post](http://www.codeproject.com/script/comments/forums.asp?forumid=1645&df=100&app=50&select=514096#xx514096xx)[[^](http://www.codeproject.com/script/comments/forums.asp?forumid=1645&df=100&app=50&select=514096#xx514096xx "New Window")] for more info.Jason Henderson
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
I'm not sure I really like that structure, it needs a lot of people. To be honest it looks like something they use at IBM or other big old compagnies ;) I think the project lead should pich his own structure, because the structure always depends on the team, and the people on the team. - Anders Money talks, but all mine ever says is "Goodbye!"
-
I'm not sure I really like that structure, it needs a lot of people. To be honest it looks like something they use at IBM or other big old compagnies ;) I think the project lead should pich his own structure, because the structure always depends on the team, and the people on the team. - Anders Money talks, but all mine ever says is "Goodbye!"
Anders Molin wrote: I think the project lead should pich his own structure I think so too, but are there any basic roles you think need to be filled? Examples: Source Manager, Tech. Writer, QA Manager, etc.
Jason Henderson
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
-
Anders Molin wrote: I think the project lead should pich his own structure I think so too, but are there any basic roles you think need to be filled? Examples: Source Manager, Tech. Writer, QA Manager, etc.
Jason Henderson
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
Of course there is, but I don't know all of them before I see the tools we have to work with here on CP, and before I see the size/type of my team ;) I hate when people make rules, saying we are going to do it this way, and then they force the team to work like that. I love flexibility, and like to make the rules so they fit the team, this way your team is more happy, and if you do it right, you get a better product. - Anders Money talks, but all mine ever says is "Goodbye!"
-
Of course there is, but I don't know all of them before I see the tools we have to work with here on CP, and before I see the size/type of my team ;) I hate when people make rules, saying we are going to do it this way, and then they force the team to work like that. I love flexibility, and like to make the rules so they fit the team, this way your team is more happy, and if you do it right, you get a better product. - Anders Money talks, but all mine ever says is "Goodbye!"
Don't get me wrong, I don't want to force rules on you. These posts are just requests for comments that will help these projects get off the ground and on the right path.
Jason Henderson
"If you are going through hell, keep going." - Winston Churchill
-
Well, yes, I suppose that's obvious, but these things really need some formal definition so people know what is expected of them. Personally, I think it's too management topheavy. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"Marc Clifton wrote: Personally, I think it's too management topheavy. Me too :) - Anders Money talks, but all mine ever says is "Goodbye!"
-
I'm not sure I really like that structure, it needs a lot of people. To be honest it looks like something they use at IBM or other big old compagnies ;) I think the project lead should pich his own structure, because the structure always depends on the team, and the people on the team. - Anders Money talks, but all mine ever says is "Goodbye!"
Anders Molin wrote: I'm not sure I really like that structure, it needs a lot of people. Please, don't think of it as "structure". That was a bad term. Think of it as an offensive lineup, or the types of players that need to take the field during a pariticular play. I bascially gave an overview of an entire (american) football team. You need an offense, defense, and kick-off/punt/fieldgoal speciality teams, each customized for their task. The flexibility is there for project leads to do as they choose, but somehow in some form those roles need to be filled. I am not saying one person per role, several people will fill several roles, that is certain. I do however feel that you cannot deliver an SEI level 3 or higher product with any of those roles missing. (especially as the projects get larger and more ambitious) Anders Molin wrote: To be honest it looks like something they use at IBM or other big old compagnies Relative to other areas of engineering disipline, software engineering is quite new, and is in need of some form of measurement of quality IMO. It's not intended as an imposing paradigm but as a standard against which to judge. - Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
-
That was fantastic Nitron, a wealth of knowledge and good sense. I certainly see us putting together a CPSF (Code Project Solutions Framework) for developing software. We cannot just come out of CP2 with just applications. We should come out with a strong process model as well. From the sounds of it you would be the lead of that project :)
Paul Watson
Bluegrass
Cape Town, South AfricaChris Losinger wrote: i hate needles so much i can't even imagine allowing one near The Little Programmer