[pypy-svn] rev 1657 - pypy/trunk/doc/funding
lac at codespeak.net
lac at codespeak.net
Fri Oct 10 11:24:29 CEST 2003
Author: lac
Date: Fri Oct 10 11:24:29 2003
New Revision: 1657
Added:
pypy/trunk/doc/funding/B5.0_manage_bea.pdf
pypy/trunk/doc/funding/B5.0_manage_bea.txt
Log:
Bea's first draft at Mangement Structure stuff. Comments especially
wanted/welcome. Bea is very flexible -- if this isn't quite what
you want, we will change it. Now isn't the time for long debates
on this -- just let us know what changes you want.
Laura
Added: pypy/trunk/doc/funding/B5.0_manage_bea.pdf
==============================================================================
Files (empty file) and pypy/trunk/doc/funding/B5.0_manage_bea.pdf Fri Oct 10 11:24:29 2003 differ
Added: pypy/trunk/doc/funding/B5.0_manage_bea.txt
==============================================================================
--- (empty file)
+++ pypy/trunk/doc/funding/B5.0_manage_bea.txt Fri Oct 10 11:24:29 2003
@@ -0,0 +1,375 @@
+ B 5.0 Project Management
+
+ PyPy as a project will be implementing an agile development lifecycle.This choice of
+ development method will have effects on the way the project will be structured and managed.
+
+ The project will have a structured project plan as is showed in this proposal (workpackages,
+ Gantt-chart, deliverables, quality control etc). It also means that the project process, once the
+ project get started, will work from a evaluate-feedback-change perspective, or so called
+ "learning loops" in which project management will continuosly follow up on the intital
+ project plan but also evaluate process, teameffectiveness, communication climate. From these
+ learning loops change, when necessary, will be applied throughout the process.
+
+ To illustrate the focus on development process as well as project focus:
+
+ Stakeholders;
+ - EU
+ - partners
+ - Python communities etc.etc
+
+
+
+
+
+
+Development
+process
+
+ Sprint/ Sprint/ Sprint/ Sprint/ Sprint/
+ team team team team team
+
+Project process
+
+
+
+
+
+
+
+
+
+
+
+ Stakeholders;
+ - EU
+ - partners
+ - Python communities etc.etc
+
+
+ Both the project and the development process are based around critical workshops, so called
+ "sprints" that will take place on a six week cycle throughout the project (24 months). Around
+ these sprints input and output to stakeholders will be structured. The arrows above symbolize
+ the evaluation-feedback-change system that will be implemented.
+
+
+
+This method will affect the role of the project management, management structure, role of
+coordinator, project meetings, quality control and communication in the project in what we
+have experienced to be a very constructive way.
+Our reasons for choosing this development and projectmethod are several:
+·This project has a history of 6 months in which the team succesfully implemented sprints
+ and agile development methods
+·In this project, teammembers from 5 (?) different countries will work continuosly in separate
+ places, sprints will be the main forum in which the teammembers meet up and work
+ together in real life
+·The sprints will be open for nonteammembers to participate in the development process, thus
+ allowing for an open and feedbackdriven process
+·The sprints will be the forum in which knowledge will be shared and the transparancy within
+ the project organisation will be measured
+
+We will during the project focus on evaluating and documenting our projectmethod and share
+knowledge and experience in that area as well. It is our goal that the overall deliverables from
+this project will be a functioning PyPy as well as an effective projectmethod for agile
+development/Open Source projects.
+
+On the following pages we will describe in more detail how this choice of method will
+influence the way this project will be managed.
+
+
+B 5.1 Project manager
+
+The PyPy project will have a project management structure that is based upon two resources,
+Jacob Hallén as project manager and Beatrice Düring as assisting project manager.
+
+The role of the project manager is to:
+ manage the project and its scope of time, budget and deliverables
+ lead the work of the management board and report to the management board
+ execute decisions made in the management board
+ report to the project coordinator
+ support the project coordinator concerning the relations to the EU
+ manage the sprints
+ manage routines for quality assurance of the technical development
+
+The role of the assistant project manager
+ report to the project manager
+ participate in reports to management board and project coordinator
+ manage project administration (reports, documentation,etc)
+ manage routines for sprints, quality assurance of project process, resourceallocation
+ manage contact with external partners
+ manage the day-to-day operations of the project (ex. executing decisions made by
+ management board)
+ manage the knowledge process and actively spread information to the Open Source
+ community regarding methods used
+
+The reasons for having a structure based on a project manager and assisting project manager
+are:
+
+
+
+ both the development and the project process will recieve due attention in that the persons
+ chosen have expert skills in these different areas
+ the project will not be exposed to the risk that a single project manager would mean
+ (hhmm dåligt formulera om)
+ a project of this size with team and stakeholders distributed in several countries needs more
+ project management resources
+
+The skills and experience of the combined project management team are as followed:
+
+Large scale projects:
+
+Jacob Hallén have been working since 1994 with large scale development projects. He was a
+consultant for, and later employee of, the LIBRIS Department of the Royal Library of Sweden
+(http://www.libris.kb.se) in the role of Technical Project Manager, with main focus on being
+systems architect for the national bibliography system and interlibrary loan system.
+Participated in international standardisation groups for search systems (Z39.50) and
+interlibrary loans.
+
+He was also the initiator of the international standardisation effort for library services
+information. Participated as the Royal Library representative in ONE-2, an EU funded project
+under the Telematics for Libraries project (http://www.one-2.org)
+
+Since 2000, Jacob have been involved in co-founding AB Strakt (http://www.strakt.com), a
+company developing workflow and document handling systems. There he works in roles as
+developer, project manager, CTO and CEO. The company has grown from 3 employees to
+having 12 full time employees and 6 part time employees so far.
+
+Connected to his work at AB Strakt, Jacob has also been active as co-founder and chairman of
+the Python Business Forum, an international trade organisation for companies that use Python
+as their main tool of business. The PBF has approximately 50 member organisations.
+He is also the project leader for the Europython 2004 conference, to be held in
+Göteborg, Sweden 9-11 June 2004.
+
+Beatrice Düring have experience in large scale education projects involving working with
+consortiums of three companies servicing a stakeholdergroup of about 30 recruiting
+companies. These large education projects was part of a national program to solve shortages
+of skilled IT-personel during the years 1998- 2000. 200 students participated in the projects
+and the projects met their deliverables in that over 80% of the student were employed after the
+education. The project team consisted of 7 persons working full time. As a project manager,
+Beatrice was responsible for meeting project goals, meeting profit margins, leading the team
+and creating strategies for stakeholder participation in the projects. She was also responsible
+for reporting and documenting the project to the client.
+
+Since 2000 she has been involved in similar assigments, one recently finished for University
+of Blekinge in which the education was directed towards recruiting companies in the
+gamedevelopment industry. She has also worked as project manager for several development
+projects during the time 1998-2002.
+
+
+
+She has also developed project methods for the companies and teams shes been working with
+and have also been working with quality assurance of development projects. Her current
+company, Change Maker is also working with supporting smaller companies in the
+application process for the EU Framework 3 (Växtkraft Mål 3) and has a experience of
+working with similar EU-funded projects since 1997.
+
+Financial tracking in projects:
+
+Jacob Hallén has a widespread experience of founding and managing companies as well as
+being project manager for large scale projects. This means that
+
+The large scale education projects that Beatrice managed had a profitmargin of 20% which
+was met. The total budget for these projects was 20 million SEK. She has also recently been
+involved in the prestudy, budgeting and start of a 6 year long education project in Arvika,
+Sweden with a total budget of 18 million SEK.
+
+During her time as a manager for the education and consultdepartment in NetGuide
+Scandinavia (1999-2002) she had budget and resultresponsibility.
+
+Leadership skills:
+
+Jacob Hallén have experienced leadership challenges in different situations. Since
+
+Beatrice Düring have experience from leadership situations in projects as well as in
+lineorganisations since 1998. During four years she was a part of a management team of five
+people, leading teams of 5 to 14 people. As a leader, Beatrice was responsible for coaching,
+motivating and developing her personel.
+
+Beatrice employs strategies of empowerment, active listening combined with creating and
+maintaining an open communication climate based on honesty and trust the achieve goals
+together with her team. Beatrice have been teaching management oriented courses
+(leadership, project management, communication, conflictresolving) for Learning Tree
+International since 2003 in both Sweden and USA.
+
+
+B 5.2 Management structure
+
+B 5.3 Coordinator dont write
+
+B 5.4 Project meetings
+
+Project Meetings
+
+Management Board will meet at the start of the project and two times per year or on an ad hoc
+basis as requested. The meetings will normally be scheduled to rotate between countries of the
+EU and mainly the principal contractors home base. The project manager is responsible for
+the invite and agenda as well as managing the meetings. Objectives on these meeting are
+tracking progress regarding workpackages, budget, timescale and strategies for involving
+
+
+stakeholders as in partners or new partners. Agenda and discussions/decisions on these
+meeting will be documented and put up in the internal project web.
+
+Team Meetings
+
+The project team will meet at the "sprints" which take place on a six week cycle ( se below).
+During the sprints, there will be time allotted to discuss and evaluate the project process, track
+progress, discuss resource allocation, new teammembers. The project manager is responsible
+for the invite and agenda as well as managing the meetings.Agenda and discussions/decisions
+on these meeting will be documented and put up in the internal project web.
+
+Project review workshops ("learning loops")
+
+Every six months, as preparation for the Management Board meetings and project reviews
+from the EU project office, the project management team invites the team to an evaluation
+workshop, lasting for a day, in which product as well as process is being reviewed.
+Riskassessment is also an important part of this workshop. This meeting could result in
+proposed changes that will then be reported to the Management Board for decision.
+The project manager is responsible for the invite and agenda as well as managing the
+meetings.Agenda and discussions/decisions on these meeting will be documented and put up
+in the internal project web.
+
+
+"Sprint" Meetings are the key to PyPy's technical development
+
+Key to PyPy's technical development and research are so called "sprints". These publically
+announced one-week meetings serve as an intense working forum to rapidly discuss and
+implement key PyPy ideas with agile methodologies. Developers usually pair up and write
+unit-tests to test the to-be-implemented features before actually adding them. The unittest-first
+approach helps to understand the planned feature. Additionally, the discussion in a pair makes
+sure that obviously wrong pathes of development are avoided. If something seems too hard to
+test or to pin down explicitely this is taken as an indication of an underlying design problem.
+
+Note that more traditional approaches usually follow a model where developers work alone
+and only meet to talk. Instead with sprint-driven development talking and actually
+implementing resulting ideas ensures a more focused approach with fast feedback cycles.
+While the free software community is successful especially because of it's open
+communication model sprints are an accelerator to this process. While coding in pairs
+developers educate each other which leads to a broader common understanding of the project.
+During a sprint multiple pairs want to work in parallel which adds pressure on design
+decisions so that independent development of components of the system is possible. Thus
+sprints not only deepen the communication and understanding among researchers and
+developers but they imply a working process which enhances the software design in multiple
+ways. The project manager is responsible for the invite (stated goal) and agenda as well as
+processmanagement during the sprints. Agenda and discussions/decisions on these sprints will
+be documented and put up in the internal project web.
+
+With a very-high-level-language like Python rapid development in coding-sprints becomes
+especially effective. A VHLL-language generally allows to focus on ideas rather than on low-
+level language details. In combintation with pervasive test-driven development this eases
+
+
+high-quality rapid evolution towards the intendent goals. Obviously, the PyPy developers are
+very experienced with Python and bigger applications in general. Thus the full potential of
+agile methodologies is unvealed during PyPy sprints. In less than five weeks worth of
+development (during four sprints) the group produced a working prototype which is a big
+success not only in the eyes of its developers.
+
+Technical decisions
+
+Major design or technical decisions are usually reached through consensus during the sprints.
+If a conflict cannot be resolved there then the technical board gets the final say. The members
+of the technical board are appointed by a vote of everyone who has commit rights to the
+source repository. However, it is expected that design and implementation choices will
+usually be determined by consensual agreement or by informal votes on the development
+mailing list. This is common practice within the Python and many others free softare
+communities. Also, the PyPy developers and researchers will construct few if any formal
+hierarchies between them. Constantly working together with agile methodologies and the
+visilibity of each individual contribution help enforce high-quality program code and good
+design decisions.
+
+B 5.5 Quality control of technical development
+The PyPy project will ensure quality by a variety of means. On the grand scale, the
+involvement of excellent researchers ensures that the general direction takes care of latest
+insights in language research. Moreover, we will publish our research results on conferences
+and to scientific and free software communities. This forms the basis to maintain a high-
+quality general technical direction.
+
+The developers deploy agile methodologies like unittest-driven development and pair-
+programming. By the end of the project we expect to have produced more than 3000 unittests
+testing every aspect of the runtime system. The presence of such tests also allows to rapidly
+change parts of the implementation without fear of breaking functionality elsewhere. We also
+plan to release our runtime system often and thus gather additional feedback from early
+adopters, developers and researchers.
+
+To support the open development we base all of our documents, source code and website
+information on a version control system. In combintation with a notification on all changes
+this ensures that all interested parties can review and react to developments.
+
+The PyPy developers have produced a working prototype within four one-week sprints and a
+little development in between. The code and design quality of the project is already widely
+accepted. There are now 400 unittests. As a consequence, Guido van Rossum, the inventor
+and maintainer of today's Python, listed is as the number one project he would like to succeed.
+He previously attended one of our sprints and got deeply involved with our architecture and
+source code which he immediately found intuitive to work with.
+Thus we believe that our choices for technical quality management are fit to meet highest
+standards.
+
+Additional Quality procedures
+
+
+
+The project manager will circulate a draft Quality Management plan for the project prior to
+first Project Meeting and and then present it for approval at the first Meeting. It should
+complement the prescribed quality approach with respect to the following aspects:
+
+ Document procedures, standards and control
+ Issue control for documents
+ Reporting procedures, frequency and format
+ Communication procedures
+ Corrective actions
+ Exception control
+ Conflict resolution
+ Meeting draft agenda
+ Format of meeting minutes
+ Tracking system for actions
+ Risk assessment
+ Evaluation routines
+ Specific responsibilities within the project
+
+
+B 5.6 Communication and reporting
+
+The project process will be reported as follows:
+ monthly written status reports to the Management Board/Technical Board by the project
+ management team. These reports will be posted on the internal project web for the entire
+ team to access.
+ project review report to the EU project office. These reports are the result of the project
+ review workshops (every 6th month) and are produced by the project management team.
+ These reports will be posted on the internal project web for the entire team to access.
+ Project evaluation report. At the end of the project, an evaluation report will be produced in
+ which both product, process and deliverables will be evaluated. This report will be
+ presented to stakeholders (consortium companies and partners) and the EU project office.
+
+The technical development of PyPy is driven by open continous discussion. Many of the
+involved decisions are made and verified during one-week working meetings, so called
+"sprints". Members from the larger Python software community are publicly invited and have
+the chance to interact and work with the PyPy developers or become one themselves.
+Mailing lists, chat-sessions, Wikis and notification of program changes provide a constant
+flow of information between PyPy project members and the wider community. Additionally,
+groups of developers can start interactive "screen" sessions which allows sharing their
+workspace and implement and communicate efficiently. Therefore conflicts out of missing or
+conflicting information or due to misunderstandings will be minimized.
+
+Each sprint meeting is planned for by all developers. The sprint goals are usually agreed upon
+before the meeting starts. This is also important to allow new developers or contributors to
+join specific efforts. Sprint results are subsequently published to email and web-channels to
+gather feedback and educate others about changes.
+
+We will present multiple reports and scientific papers on major conferences such as
+EuroPython (Python's european community conference), OSCON (Open Source Convention),
+PyCon (python developer conference) and to domain specific audiences such as embedded
+
+
+device developers.In a later phase of the project the PEP (Python Enhancement Proposals)
+procedures may be implemented. This is the standard procedure for applying changes to the
+C-implementation of Python as of today. It forces an author to clearly state the benefits of the
+proposed Enhancement and provides an rationale. However, such a formal method will only
+by required when the project reaches the point where users begin to rely on aspects of our
+implementation.
+
+
+B 5.7 Consortium dont write
+
+B 5.8 Ip dont write
+
+
More information about the Pypy-commit
mailing list