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 continuously follow up on the initial project plan but also evaluate process, team effectiveness, 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: .. image:: sprintprocess.gif 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 project method are several: - This project has a history of 6 months in which the team successfully implemented sprints and agile development methods - In this project, team members from at least 5 different countries will work continuously in separate places. Sprints will be the main forum in which the team members meet up and work together in real life - The sprints will be open for non team members to participate in the development process, thus allowing for an open and feedback driven process - The sprints will be the forum in which knowledge will be shared and the transparency within the project organisation will be measured We will during the project focus on evaluating and documenting our project method 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 project method for agile development/Open Source projects. Our goal is also to disseminate this knowledge to the developer communities inside and outside the Open Source movement as well as to commercial and academic organisations. On the following pages we will describe in more detail how this choice of method will influence the way this project will be managed. 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 tracking of quality assurance of the technical development The role of the assistant project manager is to: - report to the project manager - participate in reports to management board and project coordinator - manage project administration (reports, documentation,etc) - manage routines and tracking of sprints, quality assurance of project - process, resource allocation - 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 - stakeholders regarding methods used and knowledge acquired The reasons for having a structure based on a project manager and assisting project manager are: both the development and the project process will receive 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 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 follows: Large scale projects +++++++++++++++++++++ **Jacob Hallén** has 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 has been involved in founding AB Strakt (http://www.strakt.com), a company developing workflow and document handling systems. There he has worked 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** has experience in large scale education projects involving working with consortia of three companies servicing a stakeholder group of about 30 recruiting companies. These large education projects was part of a national program to solve shortages of skilled IT-personnel 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 assignments, one recently finished for University of Blekinge in which the education was directed towards recruiting companies in the game development 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. He has also developed several accounting programs. When being the CEO of NetGuide Scandinavia AB, the company was under budgetary squeeze in its early days, generating a lot of experience in tight cost control and progress tracking. The management was successful and the company grew to 35 employees under his leadership. The large scale education projects that **Beatrice** managed had a profit margin of 20% which was met. The total budget for these projects was SEK 20 million. 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 consultant department in NetGuide Scandinavia (1999-2002) she had budget and result responsibility. Leadership skills ++++++++++++++++++ **Jacob Hallén** has experienced leadership challenges in different situations. In his role as an officer in the reserve of the Swedish army he has been deputy rifle platoon leader in the Swedish UN forces in Cyprus, duty officer with responsibility for the battalion safety and security in Lebanon and instructor/platoon leader for training raw recruits. He has been a teacher at the Chalmers University of Technology, for Informator and for LearningTree International, all of which include being a leader for your students. At NetGuide Scandinavia his leadership was mostly focused on leading the company, initially with 4 people. A number that grew to 35 in the subsequent 3 years. At LIBRIS he assisted the project leader for the SEK 20 million modernisation project in getting consensus among the approximately 30 members of the consortium on what sort of changes should be required, wanted or tolerated in the new system. At AB Strakt, Jacob Hallén started out managing the company but changed his role to Chief Technical Officer, after successfully recruiting a suitable CEO as replacement. Jacob enjoys managing technical processes more than general corporate management. **Beatrice Düring** has experience from leadership situations in projects as well as in line organisations 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 personnel. 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, conflict resolving) for Learning Tree International since 2000 in both Sweden and USA. Management structure -------------------- The management structure will be as follows: .. image:: projectstructure_pypy.gif Representatives in the management board: - Alastair Burt, DFKI - Holger Krekel, PBF - Jacob Hallén, AB Strakt - Nicolas Chauvat, Logilab Responsibilities of the management board includes: - manage resources - manage quality assurance for the project and the technical process - track cost, timeline, tasks, budget - manage technical implementation plan and progress - manage compliance with legal and ethical obligations The operative management of these responsibilities will be delegated to the project management team and the technical board. In the management board, decisions that cannot be made by consensus and open discussions will be solved by voting (each partner have a vote, in case of tie - the project manager will have a casting vote) Representatives in the technical board: - Armin Rigo, University of Southampton - Samuele Pedroni, MPI - Holger Krekel, PBF - Christian Tismer, PBF Further representatives on the Technical Board will be selected at the outset of the project. They will be appointed by a vote of everyone who has commit rights to the source repository and used them to contribute source code. Guido van Rossum, the author of Python will act as an advisor to the Technical Board. The responsibilities of the technical board are: - make recommendations on technical strategic issues to be decided in the management board - manage the quality assurance of the technical development process - this task is delegated to the technical board from the management board - manage technical implementation plan and progress - this task is delegated to the technical board from the management board These responsibilities are reported to the management board through the technical director who is a representative on the management board. In the technical board, decisions that cannot be made by consensus and open discussions will be solved by voting (each representative have a vote, in case of tie - the technical director will have a casting vote) Since the PyPy project is implementing agile/Open Source methods ("Sprints") the goal is to have a proactive team of developers and project managers. This means that the project will be ruled by one primary management strategy - to delegate as much responsibility to the developer team and the persons responsible for each individual workpackage. This rule _will_ guide all planning and decision-making in the two boards. Coordinator ----------- The project coordinator in the PyPy project is: Alastair Burt, DFKI He has participated in several European projects, was the coordinator of the EU-funded ASWAD free software project, and is in the coordinating team of the EUTIST-AMI cluster. The DFKI itself has over a decade of experience of working with the EU's financial and reporting procedures. The responsibilities of the project coordinator will include: - to manage negotiations regarding proposal - to manage ongoing dialogue with the EU project office during the project - to appoint a project manager - to be a representative on the management board - to participate in the project review workshops - to submit reports regarding project review workshops - to participate in project evaluation and submit report of this to the EU project office - handle financial tasks and payments between the project and the EU project office The project coordinator will be able to use the project management team for support in the tasks mentioned above. 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 ( see below). During the sprints, there will be time allotted to discuss and evaluate the project process, track progress, discuss resource allocation, new team members. 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. Risk assessment 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 and take place on a six week cycle. The goals for each "Sprint" will be decided by the development team in cooperation with the project management team. The project manager is responsible for the handling of logistics before, during and after the sprints (invite, location, preparation etc). Agenda and discussions/decisions on these sprints will be documented and put up in the internal project web. During the "Sprints", developers usually pair up and write unit-tests to test the to-be-implemented features before actually adding them. The unit-test-first approach helps to understand the planned feature. Additionally, the discussion in a pair makes sure that obviously wrong paths of development are avoided. If something seems too hard to test or to pin down explicitly 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 sprints are also the forum in which interested developers can participate in the development process. This is a fast and effective way of introducing new project members into the team, its methodologies, climate and tasks. 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 combination with pervasive test-driven development this eases high-quality rapid evolution towards the intended goals. Obviously, the PyPy developers are very experienced with Python and bigger applications in general. Thus the full potential of agile methodologies is unveiled 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. 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 software communities. Also, the PyPy developers and researchers will construct few if any formal hierarchies between them. Constantly working together with agile methodologies and the visibility of each individual contribution help enforce high-quality program code and good design decisions. 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 unit-test-driven development and pair-programming. By the end of the project we expect to have produced more than 3000 unit-tests 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 combination 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 unit-tests. 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 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. Transparency concerning information and decision-making is vital for the PyPy project: - all discussions, protocols, reports, reviews and product/project information will be accessible to all people participating in the project - information of the kind mentioned above will not be altered to suit different target groups in the project - this minimizes the risk for information to be filtered The technical development of PyPy is driven by open continuous 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), FOSDEM (Free and Open Source Developer European Meeting), 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. Management of Knowledge and Intellectual Property -------------------------------------------------- Every contributor is fully responsible for not introducing program code which might infringe third party copyright or patents for that matter. Every contributor agrees to license his contributions under a MIT-style license approved by the Open Source Initiative and the Free Software Foundation. See section 3. The public availability of PyPy's source code at all times on the basis on such an open and commercially exploitable license stipulates exchange of ideas, contribution to the project and reusability all parts of PyPy from the start. In return, this provides the developers with fast feedback and improvements with respect to their current developments. At the heart of a free software community lies open communication, the free flow of information and organizing shared interests. The PyPy project is already fully involved and based on these principles. We also believe that for a language runtime system like PyPy a free license is of vital importance to reach wide deployment and recognition. Such a license is also a necessity to allow PyPy to become a reference implementation of the Python language specification. Consortium Agreement -------------------- In the case that the proposal is accepted by the EU, the coordinator and the project management team will draw up a consortium agreement that formalises the license policy outlined above. As all technical deliverables will be fully public, for general modification and reuse, all partners, and indeed the rest of the world, are free to exploit the results as they choose.