GSOC Student Project Planning

[Joel Sherrill]

On 4/29/2013 9:22 AM, Deng Hengyi wrote:
> 在 2013-4-28，下午11:30，Joel Sherrill <joel.sherrill at oarcorp.com> 写道：
>
>> Hi
>>
>> I have been reviewing GSOC proposals and wanted to pass along
>> some advice. Most of the students I have reviewed, I have chatted
>> with so have a good idea of what they are proposing. But....
>>
>> All of the proposals I have reviewed so far are missing a task list
>> or work break down at all.  I encourage all the students to make
>> a very detailed todo list.
>>
>> For example, if your project involves working on a series of
>> target architectures, then the work on each architecture would
>> be at least one item in the work break down.  As another example,
>> maybe you are creating multiple new classes/handlers or
>> your project requires some work on a set of existing classes/handlers.
>> In this case, each class would be at least a work item. It may break
>> down if it is a development activity, since you would at least
>> need to address any design, coding, test, and documentation.
>>
>> Documenting and testing would likely be repeated as sub-tasks of
>> different parts of the project.
>>
>> Patch submission would show up if  the work can be incrementally
>> submitted. Which is most of the projects I have reviewed so far.
>>
>> I would expect the dates in the GSOC calendar to show up as
>> deadlines.
>>
>> Basically, you need to break things down to small incremental
>> steps. Put them in order. Plan deliverables, testing, etc.
>>
>> http://www.projectlibre.org/ is a libre planning tool which is
>> similar to MS-Project. It can be used to create work break downs
>> and display them as Gannt charts, etc.
> I have download and install the projectlibre. And anyone has a guide or some references to share?
It is a project planning tool. I don't know how good their
documentation is but it is very similar to other tools
like MS-Project and a now dead FOSS project openproj.org.

The simplest way to use any of these tools is to work on
the task list. You enter a set of task "titles" which are
meaningful. It essentially becomes a nested, collapsible
bullet list.

For a mythical project which adds a new manager to RTEMS
(and this is likely far from complete):

+ Define API
- Research comparable APIs (1 week)
- Write .h file w/Doxygen (2 days)
- Public Review (1 week)
- Incorporate Feedback (1 day)
+ Implement API
- Develop stub bodies which compile (1 week)
- Implement Method X (1 day)
- Implement Method Y (1 day)
- Test Method X (2 days)
- Test Method Y (2 days)
+ Document API
- Add API Chapter to Users Guide (2 days)
+ Submit to be Merged
- Submit API
- Submit Doc
- Review Period
- Incorporate Feedback

The "indent/outdent" button moves tasks under other headings
and lets you group them.

The "link" button says a task can't start until another is
complete.

Milestones can be noted as "0" length events with dependencies
(predecessors and successors). These are usually arbitrary
deadlines (e.g. reviews in GSOC) or real milestones as in
Basic Functionality Completed.

In this case, I would expect that writing the .h, Users Guide
and stub bodies could almost occur in parallel. Or at least
the stub bodies would be implemented in parallel with the .h
and the Users Guide could be written during the public API
review. The dependencies you create with "links" to indicate
prerequisite tasks should show you potentially overlapping tasks.

If you have a project with multiple people, they are resources.
You assign "resources" to tasks. I suppose you could assign
lab access, test equipment, etc. and plan it but I have never
done that.

Overall, all project planning tools do is give you an
organized TODO list which has dependencies in it and can
track progress. It can produce graphs to aid you in
determining what to do next, what is taking too long,
and finding the critical path through a project. My
plans often focus on when I want public review or feedback.
When I do a port of RTEMS to a new architecture, I check
that GCC, etc. are in good shape and report bugs. I have
no control over when those are fixed so want to give all
the time I can.

One thing often overlooked with the focus on Agile
and Scrum development methodologies is that you MUST
have a TODO list (e.g. Work Break Down) at a fairly
low level of granularity. You have to know what is in
each sprint and track it. Project planning tools assist
in doing that.

A good project plan is updated and corrected as the project
progresses. You add tasks, update the time from estimated
to actual, etc.

>> Your GSOC Project should be viewed from a planning perspective
>> as a fixed price contract with deliverables. Using project planning tools
>> is a part of live in the "real world". :)
>>
>> -- 
>> Joel Sherrill, Ph.D.             Director of Research & Development
>> joel.sherrill at OARcorp.com        On-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available                (256) 722-9985
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research & Development 
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805 
Support Available                (256) 722-9985