Information
systems
Policies
Document Revision and History
|
Document Purpose |
Setting the engineering policies that guides the implementation of processes and work products generation |
|
Generation Date |
1 Feb 2014 |
|
Modification Date |
September 2, 2015 |
|
Generated By |
G.Ghoniem Abdel Azim,DM |
|
Update By |
G.Ghoniem Abdel Azim,DM |
Contents
PLC2.
Tools for the
organization
b.
Development
Team virtual organization
PLC4.
Roles and
responsibilities VS function
PLC6.
Requirement
Gathering process
PLC7.
Solution
architecture and implementation process
PLC8.
Configuration
management policies
5.
Done criteria for the tasks
PLC10.
Project
tracking policy
PLC11.
Software
quality control policy
PLC12.
Software quality
assurance policy
Abbreviations
|
S# |
Abbreviation |
Description |
|
1. |
BVR |
Business validation rules |
|
2. |
B2C |
Business to customer. |
|
3. |
CCB |
Change Control board, means the responsible committee for taking decision. |
|
4. |
DEV |
Development |
|
5. |
DM |
Development manager |
|
6. |
HR |
Human resources |
|
7. |
ITR |
Iteration |
|
8. |
New Comers |
New employee in development team |
|
9. |
PI |
Process improvement |
|
10. |
QA |
Quality Assurance |
|
11. |
QC |
Quality control |
|
12. |
RCA |
Root cause analysis |
|
13. |
TL |
Team Leader |
|
14. |
REPO |
Repository: The container of set of work products. Ex: 1. source safe : the repository for source code 2. Trello : the repository for tasks 3. Tracking system: the repository for issues (Bugs & REQs) |
Scope of
the document
This document is to cover all organization policies that direct the organization processes and procedures execution.
Mission
Statement
Providing business solutions for the SME covering the retail, hospitality and all ERP modules that meet the latest technology.
Vision
Statement
Being one of the market automated integrated solution providers, built upon desktop, web and mobile technologies and platforms.
Values
1. Innovation: for both methodologies and products
2. Integrity: between methodologies and teams
3. Quality
4. Agility
5. Team play
Ethics***
1. Quality is every one job, so everyone should provide high quality output to save others effort and prevent rework
2. spread positive energy, so report negatives directly ,instead of spreading negative energy
3. Respect is independent than your role in the organization, so respect all team members cause it is the key for success
4. Be professional, not emotional, so you should focus on objectives and be quantitative.
5. Decisions and point of views are built upon facts, not narratives.
6. Keeping focused not only save your time, but also save others, wasting time is not allowed.
7. Escalation to higher level of management is respected after communication with direct management level, and needs arise for higher level of management involvement is required
PLC1.
Policies
policy
1. Policy is the reference to guide the engineering process
2. Policy CCB consists of:
a. Development Director
b. Operation Director
c. Delivery Manager
d. HR director
3. The organization values is the guide to develop and update the policies
4. Violation of the policies is not permitted without policies CCB approval
5. Policies are subject to change and improvements.
6. Institutionalization of the policies should take place after each modification
7. All Development units should focus on the usage of automated tools in order to save time and effort for process and procedures standards
PLC2.
Tools
for the organization
|
S# |
Tool |
Description |
Reference |
|
1. |
EA |
Used for modelling the business requirements, analysis, and solution architecture. |
\\10.10.1.83\Source\Enterprise.Architect.12.0.1210.Corporate.Edition |
|
2. |
.Net 2013 .Net 2015 |
Used for developing desktop, and web applications |
\\10.10.1.83\Source\Microsoft Visual Studio Ultimate 2013 en-US x86 Nov8-2013 \\10.10.1.83\Source\visual studio 2015 enterprise iso serial keys fullstuff |
|
3. |
SQL-Server 2012 |
Used as a content media for the database layer |
|
|
4. |
TFS for projects |
Task management and reporting tool |
http://tfs-13:8080/tfs/AladwaaProjects/EditorWebApplication http://tfs-13:8080/tfs/InternalProjects/Unity http://tfs-13:8080/tfs/AladwaaProjects/AladwaaDigital http://tfs-13:8080/tfs/AladwaaProjects/AladwaaDigital-SchoolVersion http://tfs-13:8080/tfs/AladwaaProjects/AladwaaDigital-Wesite http://tfs-13:8080/tfs/AladwaaProjects/Aladwaa-PortalWebsite http://tfs-13:8080/tfs/AladwaaProjects/AladwaaQrcodeReader http://tfs-13:8080/tfs/AladwaaProjects/Editor http://tfs-13:8080/tfs/AladwaaProjects/Qr%E2%80%93CodeCrawler http://tfs-13:8080/tfs/AladwaaProjects/TeacherTool http://tfs-13:8080/tfs/AladwaaProjects/TrackingSystemWebsite Internal Projects:- http://tfs-13:8080/tfs/InternalProjects/NationalGeographic External Projects:- |
|
5. |
VSS |
Visual source safe, configuration management tool for saving source code versions. |
Embedded in TFS |
|
6. |
Trello |
Task Management Portal |
|
|
7. |
TFS |
Software Management tool |
\\10.10.1.83\Source\vs2013.4_tfs_enu_2.iso |
PLC3.
Organization
structure
a. Organization chart
PLC4.
Roles
and responsibilities VS function
|
S# |
Function |
Organization Role |
Agile Role |
Guidelines |
|
1. |
Requirement management |
DM + TL |
Product Owner |
Collection and Representation of customer requirements, then analyze them |
|
2. |
Technology Selection |
DM +TL |
Scrum Master |
Select suitable technology for implementing solution(s) |
|
3. |
Architecture and design |
DM + TL |
Scrum Master |
Define main solution components and relationship between them |
|
4. |
Development |
Development team |
Development team |
Transform logical design to physical design elements and building blocks |
|
5. |
Quality control |
QC Team |
QC Team |
Assure software quality against predefined standards and scope. |
|
6. |
Quality Assurance |
QA |
QA |
DM, TL acts till building up the process and remove current overheads. |
|
7. |
Process improvement |
DM + TL |
PI |
Virtual team. All team members share in process building. |
|
8. |
GFX (Graphic Design) |
Web Graphic Designers |
Web Graphic Designers |
Design the graphical representation to be displayed in the solution |
PLC5.
Proposals
process
1. Presales or implementation team should write the proposal in user stories format in order to clarify the scope for estimators
2. Product Owner [TL] should be assigned for the proposal
3. There are 2 ways of planning the project:
a. Agile
1. A team should be grouped in order to estimate the project
2. Proposal estimation should be occurred using Story point, considering the predefined reference point[1]
3. Poker technique is the effort estimation method[2]
4. Presales team should take the responsibility for generating the user stories
5. Both Reference points and team velocity should be identified in order to estimate both effort and schedule
b. Traditional way:
1. Estimation sheet should be prepared per feature
2. Estimation from each team should be gathered
4. Selection of the estimation methodology should be identified according to the team availability and time frame
5. Estimation should be reviewed from both TL and DM
PLC6.
Requirement
Gathering process
1. User stories should be an input to requirements gathering phase and subject to change by the analyst role
2. No dependency on Emails to be considered as source of requirements, so requirements documents should be updated by approved communication channels requirements
3. Scrum master [TL] should arrange elicitation meeting schedule with the client
4. TL should act the analysis role with the client in requirements phase
5. TL should act the architect role with the client in integration phase
6. The UI team should attend the requirements gathering meeting
7. UI should follow the UX patterns for each platform according to the usability checklist.
8. Acceptance test should take place in requirements gathering phase
9. TL is responsible for resolving the conflicts between teams in UX, GFX and requirements
10. Escalation can take place to top management (DM) in order to resolve conflicts
11. Localization document should be ready for all platforms in order to clarify the following:
o Captions
o All Messages
PLC7.
Solution
architecture and implementation process
1. Business analysis models (Use case model, use cases, activity diagram) should take place in solution design document
2. Absence of the analysis models is subject to prevent the solution implementation
3. Project technical facilitator should act as a reference point in proposed or required architecture in order to provide platforms consistencies
4. Modifications to the base-lined architecture by the team should be approved from the platform TL
5. The following measures should be subject to track in order to support teams and organization performance, and can be an evaluation factor for platform KPI:
1. Reusable components used
2. No. of developed reusable components
6. System test cases preparation should take place in this phase
7. Static models should take place in solution design document
8. Interaction models should take place in solution design document
9. Deployment models should take place in solution design document
10. Integration document should be provided by the client with our latest integration document format
11. Unit test activities should be conducted on the given integration methods (API or web services) using the given integration document specification
12. Code review should take place by team lead to the selected areas of concerns.
13. RCA should be conducted and corrective actions should take place in order to prevent such issues and increase team knowledge.
14. Considering defensive programming in development in order to cover alternative business scenarios and exception handling even if not covered in use cases definition.
PLC8.
Configuration
management policies
1. CCB Definition
1. Project CCB should be identified for each project
2. Product CCB consists of:
1. DM
2. Technical team lead (Scrum Master)
3. Product Owner or any of customer representatives
4. CC (Configuration controller)
2. Change request Scope
1. Requirements scope should be clear [written in user stories format] in order to evaluate the change request within the higher level scope or not.
2. Evaluation of the change request to identify effected work products
3. functional and physical audits should take place.
3. REPO
1. For internal projects, DM or TL can be the product owner, so he can do the same PM and CM responsibilities.
2. CM representative generates the REPO [Trello Board or TFS, as process] according to REPO Standard
3. Access should be given to the team members throw only the CM representative
4. CM representative should conduct functional and physical audit each iteration
5. Identification of configurable items should take place within the project, and plan for readiness in its correct time, and use it as a base for the project.
6. Change request approval should take place by project CCB
7. All team members should submit the work every day in order to prevent work loss.
8. CM representative should backup the CM TOOL periodically in order to prevent organization assets loss
9. Version labels should be generated in the following cases:
1. for each iteration and solution delivery
2. in critical modifications for the solutions, like refactoring or replacement of the components or classes.
10. CM TOOL commit should include comments for submission
11. Communication for the project work products should be kept only under configuration management environment
12. CC is the responsible to distribute the work products between the producers and the consumers of the documents
13. Only one version of the work products should be kept under the Configuration management tool in order to prevent confusion
14. CC should check the existence of latest changes before building the solution in order to save both testing team and development team effort
15. CM representative is responsible for continuous integration in order to keep software updated by latest scope and other changes.
4. Version Management
A. Version No. definition
|
S# |
Status |
Description |
Type |
Example |
|
1.
|
Minor |
Beta |
Internal |
64.1, 64.2 ,64.3 |
|
2.
|
Major |
Final |
External |
64, 65, 66 |
-
The internal is beta versions not to be communicated with the client
-
Beta version will be issues each iteration independent of the
completeness of the scope.
-
Version is issued from development team to QC team only according to the
iteration time-box.
-
Release note is issued with the released version of what be done on the iteration release.
-
QC scope for the iteration is to
o
confirm that mentioned issues in the sheet is covered
o
confirm that the system does not be affected in different areas
-
QC is the release issuer to real version issuer to CS with the final
update of what actually be done in the release note.
b. Versions types
|
S# |
Type |
Definition |
constraints |
|
1.
|
Beta |
Internal version for
testing purposes only. |
-Not to be communicated with the client. -Not to be issued
if: ·
Screen does not open, save, edit and delete ·
Client Life cycle process does not complete |
|
2.
|
Final |
To be communicated with the client |
-Not to be issued
if: ·
Screen does not open, save, edit and delete ·
Client Life cycle process does not complete |
|
3.
|
Service back |
1.
For show stoppers or
sales needs issues. 2.
Comes throw Support unit manager. 3.
Maximum No. of service backs for release is 3
service backs. 4.
Service back effort will replace another
batch of issues will the same equal effort. |
-Not to be issued
if: ·
Screen does not open, save, edit and delete ·
Client Life cycle process does not complete |
PLC9. Project planning
1.
Guidelines
1. User stories should be prepared by Pre-Sales team or implementation team
2. Effort [Re] estimation should be done using user stories and poker technique
3. Software lifecycle is iterative time-boxed model
4. Product owner and scrum master should be identified for each the project
5. Project planning should be based on 6 hours work estimation
6. The difference between planning calculation base and total working hours is related to direct manager responsibility in order to communicate and facilitate function issues
7. Effort estimation should contain all activities within the project (UX-GFX-ANS-ARCH-DESIGN-QC-QA)
8. Assumptions should be given to the proposal in case on non-clear requirements
9. Iteration time box will be as follow:
1. One week for projects less than 2 months
2. Two weeks for projects more that the given time box
11. Project tasks should be prioritized by the product owner and the customer using task dependencies between project resources.
12. Project tasks should be sliced by development team according to customer perspective
13. Iteration stories should be unified across all platforms in order to increase support in between both development teams and QC team
14. Plan should be sent to relevant stakeholders in order to define the work scope for each iteration, for example QC should know the iteration scope in order to focus on
15. Project calendar should be settled including (employees VAC days and public holidays)
16. Rework% ranges can support the risk management effort estimation margin
17. Reusability cost% and saving% should be calculated in order to support the management for price negations, scope risk management and competition
2. Agile process
|
Release 1 |
Release 2 |
Release 3 |
|||||||||
|
ITR-01 |
ITR-02 |
ITR-03 |
ITR-04 |
ITR-01 |
ITR-02 |
ITR-03 |
ITR-04 |
ITR-01 |
ITR-02 |
ITR-03 |
ITR-04 |
- Each release time box is 2 months, and the iteration is 2 weeks
- Release planning will take place 2 weeks before the release start in order to do the following:
o Select issues from issues backlog according to the team power
o Setting priority for the issues
o Set iteration planning
- Each release will contain four iteration
- The first three iterations will be dedicated for the following activities
o 20% refactoring till finish, and then moved to development %.
o 60% development
§ 25% of them requirements
§ 75% of them for bugs
o 20% testing and rework
- The fourth iteration will be dedicated to consolidation of the previous three iteration and issues closure.
- After scope selection between the CCB, the development Rep and QC rep share in setting the user stories before the detailed analysis occurs.
- A detailed analysis should be occurred and delivered to the QC team
- Peer review process should be occurred between DEV and QC Rep.
- Building test cases upon the delivered test cases should take place in parallel while development team is building the solution architecture.
- Test cases should be delivered to development team before releasing the version to the QC team in order to consider the test cases alternative paths and exceptions.
- Development team consider objective points before releasing.
- Development team release the version to the QC team
- QC team execute the test cases and report issues on the tracking system.
- RCA for bugs should take place in order to prevent such issue
- Development team allocate 20% of the iteration for resolving issues considering RCA.
3. Main Planning activities
|
1st Of the month |
15th of the Month |
1M |
|
Iteration planning |
Iteration planning |
Release planning |
|
UML Models Beta Version Code Metrics |
UML Models Beta Version Code Metrics |
Final Release Release note Release RETRO |
4. Task Priorities guidelines
|
Issue Type |
Priority |
|
Bugs |
1. Client 2. Bug Severity evaluated by Implementation team and DEV team |
|
Requirements |
1. Client 2. Missing Requirements 3. New client requirements 4. Improvement requirements |
|
Modules |
1. Client 2. Contracted 3. New trend |
5. Done criteria for the tasks
|
Role |
Done Criteria Definition |
|
Development Lead |
1. Task done according to the predefined process 2. Code Handover occurred 3. Code metrics are reviewed and all issues were resolved 4. Internal Testing occurred 5. Tested by the QC Team 6. All Related issues were resolved 7. Source Code Checked in 8. All related documents and models are updated and checked in 9. Update the status on Trello |
|
Senior Developer |
1. Task done according to the predefined process 2. Code metrics are reviewed and all issues were resolved 3. Internal Testing occurred 4. All Related issues were resolved 5. Test all his deliveries before delivery to QC 6. Source Code Checked in 7. All related documents and models are updated and checked in 8. Update the status on Trello |
|
Junior Developer |
1. Task done according to the predefined process 2. Internal Testing occurred 3. All Related issues were resolved 4. Source Code Checked in 5. All related documents and models are updated and checked in 6. Update the status on Trello |
|
Senior QC |
1. Task done according to the predefined process 2. Recording the issues on the tracking system 3. Bugs reviewed and approved 4. Tracking system report for the following: a. Approval Trend b. Updated Trend c. Postponed trend d. NMI Trend e. Non-Fixed Trend 5. All related documents and models are updated and checked in 6. Update the status on Trello |
|
Junior QC |
1. Task done according to the predefined process 2. Recording the issues on the tracking system 3. All related documents Checked in 4. All related documents and models are updated and checked in 5. Update the status on Trello |
6. Issue type definition
|
Type |
Definition |
|
Issue |
A general definition for features, requirements, and bugs. |
|
Feature |
A new added value group of requirements to be added to the solution. Ex: Hijri support in software |
|
Requirement Or Enhancement |
A detailed execution instructions that belongs to main feature. It needs analysis, architecture, detailed design, and implementation phases. Ex: Main Feature: Issuing items from stores Requirement: Check balance before issuing items from stores. |
|
Bug |
Un-matched result to the expected one. Expected result is the agreed result from business, not the comparison with the old or equivalent products. Neither missing features nor missing requirement do not have expected results, so it can’t be recorded as new bug. |
7.Bug Severity setting
|
S# |
Status |
Description |
|
1. |
High |
-
Unexpected Hang or crashes while execution -
Blocking the client core process and reports
execution -
Incorrect calculation for transactions
information -
Incorrect calculation for reports information -
System does not save required contents -
Security violation |
|
2. |
Normal |
-
All high issues with different way to execute
it. -
Inconsistency with BVR -
Misleading messages for process status |
|
3. |
Low |
-
Incorrect localization -
Incorrect colors and display -
Non descriptive messages and labels -
UI Spelling mistakes |
7.
PLC10. Project tracking policy
1. Iteration Inputs:
1. Iteration inputs should be ready before iteration start (Clear requirements, GFX, UI)
2. Iteration (n) plan should take place on the closure of the iteration (n-1).
3. Planning means:
1. Who
2. Do what
3. When
4. with what effort
5. Definition for done criteria
6. Obtain resources commitment on the assigned tasks.
2. QC Involvement:
1. Version should be sent the QC team at the end of the iteration by the updated actual scope by both TL and PM
2. QC team should document the test cases for the current iteration at earlier stage
3. QC Team run the setup over the client original client(s) database version, in order to detect missing DB structure updates in beta version
4. In order to have updated quality status, Review for the old issues, and changing status to its relevant is one of the majors to be done.
5. Testing for the previous iteration scope should be occurred with documenting for the issues under the tracking system.
6. Daily review the entered issues by other teams, like support team, in order to act proactive to the version
7. Update for the issue status as required, for Example if it needs additional clarification, QC Rep should update the status to NMI, and the same for each issue as required.
8. Update test case according to the findings in order to publish the changes between teams
3. Evaluate iteration
In order to enhance team performance and reduce rework, the following measures should be calculated and analyzed for both internal and external delivery:
1. Team velocity, the productivity of the team which leads to know the actual delivery date according to the performance
2. Follow-up effort[1]
3. Interruption: Interruption should be tracked within iteration in order to re-plan consideration
4. Idle time
5. Rework effort
6. Task ownership
7.
4. Follow-up Meetings:
1. Daily startup meeting should be conducted between development team and product owner in order to support and track the project performance, so that will increase platform consistency, project focus, reduce tracking time, and taking corrective actions early.
2. Mid-day meeting: for confirming that all work is working under the correct track.
3. Meetings scope clarifies the following:
· What done
· What in progress
· What leaks the project performance?
4. Raising issues should be performed in the suitable time in order to take corrective actions early from required resource(s)
5. Lessons learnt should be documented incrementally within the project execution, and take process and procedures required changes and suitable project corrective actions.
6. Technical issues feedback should be approved by the TL and PM before communicating with the client
5. DM Involvement:
1. Set suitable standards, and procedure for software development lifecycle
2.
Share in software analysis
and architecture design
3. Software Process improvement activities
4. Utilizing new technologies and trends in current process and solutions
5. Should support the TL’s in project technical issues
6. Weekly meeting between Managers should be conducted in order to track the projects status and support its performance
7. Action items should be sent to relevant stakeholders in order to behave towards
8. Consolidated view should be sent to the operation director
9. In delivery mode, no permissions, vacations, and leaving the office without both development manager and team leader approval.
6. Tracking method:
1. All projects should have a unified tracking method
2. Agile workspace tracking is the DM and TL responsibility
3. All issues should be controlled under tracking system
7. Board guidelines:
1. TL is the responsible for generating the backlog and moving it to the to-do list
2. Project resources is responsible to get from the to-do list with the TL support
3. No development task should be greater than 21 hrs
4. No research task should be greater than 28 hrs
5. Resources are not permitted to start 2 parallel tasks, or setting the under execution together.
6. Junior level is authorized only for updating board cards detailed tasks status
7. Junior level should be supported from higher level by selecting relative cards, and moving the card to the next status
8. Follow-up intervals:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PLC11. Software quality control
policy
A. Inputs
· Release notes [Automatically generated from Tracking System]
· EA Models
· Impact analysis document
B. Scoping
A. A clear scope should be sent to the QC section in order to restrict bugs for the given scope and have accurate Rework% over the scope, so QC team will not depend on planned iteration scope.
B. Peer Review should be done by the technical team lead before delivering solution to QC
C. Preparation Process
Use cases should be sent to the QC team in order to:
A. Detect missing scenarios (Main or alternatives)
B. Detect expected exceptions
C. Generate test cases focusing on:
i. Pre-conditions
ii. Scenarios
iii. Exceptions
D. Test cases should be generated incrementally upon use cases according to the planned iterations
D. Execution
A. QC lead should review the testing result before delivering it to the development team
B. Rework% should be analyzed and resolve root causes strategically
C. A consolidated review meeting should be occurred between all platforms development teams and QC team in order to assure consistency between platforms.
D. Issues lifecycle till closure
A. Recorded issues will be in draft status if needed to a higher level of review, otherwise approved status
B. Development team looks only for approved status
C. After finding issue and resolving it, development team should change the status to be completed
D. A new version will be delivered to the QC team
E. QC team retest the version after resolving the issues and close all resolved issues
F. No transfer for bug status from Approved to neither cancelled [Not found] nor suspended without backing to QC team to get their feedback
G. No transfer for bug status from Completed to Approved [still found] without backing to development team to get their feedback
H. A higher level of management should be involved if issue will be suspended.
I. Any conflict of issues understanding should be raised to higher level for concluding, and set consensus for understanding.
J. Revision for suspended issues should take place each iteration in order to finalize them.
E. Regression
A. Isolate issues in separate data if applicable
B. Test the delivered version on the isolated data
C. Test the delivered version on the isolated data
D. Test all related alternative scenarios to the test case.
F. Releasing version
A. Exceptions% should not exceed 5% from overall module issues
B. Exceptions% should not exceed 5% from overall Client issues
C. Tracking system issues should not exceed 2 releases without closure
D. Draft issues should be concluded after two weeks by maximum
PLC12.
Software
quality assurance policy
A. A function for the QA should take place in order to confirm the implementation of organizational policies, procedures and work products.
B. Each work product should be reviewed by a higher level in order to reduce deviations to quality attributes.
C. Quality system should be established and populated
D. Audit checklist should be followed in order to proceed in audits
E. Audit points should be defined in planning phase
F. Source code audit checklist should be generated by TL in order to review the source code against
G. Source code Audit checklist findings should take place for solve before each iteration delivery
H. Rework% should be analyzed and resolve root causes strategically
I. Release should not be incremented without adding the code metrics on tracking system with analyzing all inputs and following QMS guidelines and rules
J. LOC should not exceed the previous version without RCA, and approval from higher level of technical management level according to the policy
PLC13.
Communication
policy
1. Methods
1. Documents: In order to facilitate ease tracking, Issues be kept in predefined documents, and all replies should be kept in the same document, and should be kept under Configuration management tool.
2. F2F: In order to meet understanding between project stakeholders, Use face to face communication instead of documentation
3. Core hours for communication between development team and support team will from 2:00 PM to 5:00 PM
4. Email:
1. Email folders should be created for each internal section [Departments] and external entities [clients], with applying rules for.
2. Checking mails should be performed at start of date, and end of date in order to highlight issues, plan and prioritize tasks
3. Mails should be sent only to relevant stakeholders only.
4. Higher level of management [Only one level] should be informed in the following cases:
1. Reminders
2. Conflicts
3. Escalations
4. Cross functions communication
5. between subordinates team leaders.
5. Periodic meetings/Follow-ups
|
S# |
Meetings |
Time |
Duration |
Points |
|
1. |
Daily Start up meeting for teams |
9:15 |
10-30 |
· What finished in each area to support all teams (QC, Support and DEV), like analysis models and final products · What not finished · Bottle nicks and resolutions |
|
2. |
Daily status check and update |
|
|
· Start of day · Immediate changes |
|
3. |
Mail checking |
|
|
· Start of the day · Mid of day |
|
4. |
Iteration review |
|
1 Hr |
· Iteratively |
|
5. |
Retrospective |
|
2 Hrs |
· Each Release |
|
7. |
Operation meetings |
|
60 |
What finished What not finished Bottle nicks and resolutions |
|
8. |
Project Planning |
|
5 D |
Plan overall project releases |
|
9. |
Release planning |
|
5 D |
Plan for release iterations |
|
10. |
Iteration planning |
|
2 D |
Plan for next iteration |
6. Plans
1. Communication plan should take place within the project in order to define when different stakeholders communicate, with which media
2. Identify who will deliver what when to whom and in which media
2.
Responsibilities
1. Communication between technical teams should be throw TL’s and PM
2. PM should be in CC in all communications between different teams in case of external projects, otherwise the heads of the teams.
3. PM is the responsible stakeholder to communicate project issues, status and work products of the projects
3.
Meeting and conference call should take place in the following subjects:
1. Conflicts issues
2. Meeting the understanding between different stakeholders
4.
Synchronization for the scope, issues, and change requests is the
responsibility for the TL.
5. PM
is the communication gate between external teams and internal teams
6. Delegation
from PM to technical teams can be occurred in case of technical issues, so PM
should be presented in CC in these cases
7. Working area policy
· Keep your mobile in silent or low tone mode
· Communication between team members should be in private methods, not public methods
· Working area is not subject for meetings, but meeting rooms
· Non-business discussions are permitted only in the public area
PLC14.
Benchmarks
|
S# |
Benchmark |
Description |
|
1. |
Supported Products Versions |
One Version backward compatibility |
|
2. |
Supported SQL Version |
SQL Server 12 |
|
3. |
Tracking System History |
Should cover only up to 3 releases |
PLC15.
KPI’s
1. Project KPI
|
S# |
KPI |
Description |
Media |
|
1. |
Performance |
Planned/Actual effort |
|
|
2. |
Rework Effort |
QC resolving issues/Planned execution for tasks. |
|
|
3. |
No. Reusable Components |
The resulted reusable components |
Source code |
|
4. |
Impact Of Cost for related Tasks |
The saving effort% for the related tasks if no reusable component is created. |
|
|
5. |
Code Metrics |
Source code metrics to measure the source code quality |
Source code Tracking system |
|
6. |
Code Clones |
The similar group of lines within the same modules. It should take place in refactoring process. It includes: 1. Exact Matches 2. Strong matches |
Source code Tracking system |
|
7. |
Quality Metrics |
1. Draft Trend 2. Approval Trend 3. Updated Trend 4. Postponed trend 5. NMI Trend 6. Non-Fixed Trend 7. Exceptions Trend: If exceeded more than 3% for selected product or selected client, then prevent the issuing of version. |
Tracking system |
2. Resource KPI
|
S# |
KPI |
Description |
Media |
|
1. |
Performance |
Planned/Actual effort |
|
|
2. |
Utilization |
Actual Effort/ Employee power[2]. |
|
|
3. |
PU |
Performance% * Utilization |
|
|
3. |
Task Ownership% |
1 – (Coaching effort/Task actual effort) |
|
|
3. |
Rework% |
QC resolving issues/Planned execution for tasks. |
|
3. Units
KPI
|
S# |
KPI |
Description |
Media |
|
|
1. |
|
Performance |
Planned/Actual effort |
|
|
2. |
|
Utilization |
Actual Effort/ Employee power[2]. |
|
|
3. |
|
PU |
Performance% * Utilization |
|
|
3. |
|
Task Ownership% |
1 – (Coaching effort/Task actual effort) |
|
|
3. |
|
Rework% |
QC resolving issues/Planned execution for tasks. |
|
|
1. |
|
Performance |
Planned/Actual effort |
|
|
2. |
|
Rework Effort |
QC resolving issues/Planned execution for tasks. |
|
|
3. |
|
No. Of Reusable Components |
The resulted reusable components |
|
|
4. |
|
Impact Of Cost for related Tasks |
The saving effort% for the related tasks if no reusable component is created. |
|
|
5. |
|
Code Metrics |
Source code metrics to measure the source code quality |
|
|
6. |
|
Code Clones |
The similar group of lines within the same modules. It should take place in refactoring process. It includes: 1. Exact Matches 2. Strong matches |
|
PLC16.
Facilities
|
S# |
Facility |
Responsible for communication |
|
1. |
Stationary |
HR |
|
2. |
Food and beverages |
Office boys |
|
3. |
Financial issues |
HR |
|
4. |
IT Services |
IT Department |
PLC17.
New Comers Policy
a. Development section
The new comers first week will be allocated for the following:
|
S# |
Task |
Duration/ HR |
|
1. |
Contract signing and HR introductory session |
1 |
|
2. |
Setup machine working environment |
4 |
|
3. |
Read and understand the policy. |
2 |
|
4. |
Training on the management and engineering tool, Trello, and TFS |
4 |
|
5. |
Introduction of how to engineer SW project using organization process, Our development lifecycle. |
4 |
|
6. |
Introduction of how to manage SW project using organization process, Agile Process. |
4 |
|
7. |
Training on the engineering tool, on EA. |
7 |
|
8. |
Brief introduction on organization solutions. |
6 |
|
9. |
Setting the first Iteration plan |
2 |
|
10. |
Training on Internal System |
1 |
|
11. |
ERP Concepts |
5 |
|
12. |
Sample Project for Practice (If Needed) including unit testing and CI setting definition and application |
… |
|
|
|
40+ Hrs |
b. Quality control section
|
S# |
Task |
Duration/ HR |
|
1. |
Contract signing and HR introductory session |
1 |
|
2. |
Setup machine working environment |
4 |
|
3. |
Read and understand the policy. |
2 |
|
4. |
Training on the management and engineering tool, Trello. |
4 |
|
5. |
Introduction of how to engineer SW project using organization process, Our development lifecycle. |
4 |
|
6. |
Introduction of how to manage SW project using organization process, Agile Process. |
4 |
|
7. |
Training on the engineering tool, on EA. |
7 |
|
8. |
Brief introduction on organization solutions. |
6 |
|
9. |
Training on Comsys Structure |
2 |
|
10. |
Training on Security module |
1 |
|
11. |
Training On GNR module |
5 |
|
12. |
Training on selected allocation module for the resource For example : AP, AR, e-Commerce. |
… |
|
|
|
40+ Hrs |
[1] -Helps in understanding the task ownership
Task ownership% = Follow-up Effort/Resource power
[2] -Employee power = No. Working days * 7
PLC16.
Remote Working
Policy
- Remote working is one of the core benefits to enable the commitments delivery.
- Each employee can have up 2 days per sprint to work remotely
- Clear tasks with clear estimations should take place before the application of the policy
- Leaders and management level can decide to work from the office according to the nature of the sprint, commitment sensitivity, and workspace enablement
- Remote Matrix per each SQUAD should be prepared, and delivered before the execution in order to have managed process:
|
Employee |
Mon |
Tue |
Wed |
Thurs |
Fri |
|
Emp 01 |
X |
X |
|
|
|
|
Emp 02 |
X |
|
X |
|
|
|
Emp 03 |
|
X |
|
|
X |
- Managing the SQUAD remote matrix are under the responsibility of the SQUAD lead.
- Abuse of the remote working policy is subject to prevent this facility from the employee and SQUAD lead
- Employee should be accessible during the core working hours over the network, and accessible via communication channels during the working hours
- Ensuring employees availability is under the control of the SQUAD lead
- Critical events and meetings days should be eliminated from the remote working days
- Balanced attendance of SQUAD team members should take place in order to support the daily operation and ad-hoc activities
C16.
Bonus Policy
-
Yearly bonus is one of the
employees benefits
- Each employee can have up 2 months according to their performance that exceed expectations
- 6 months evaluation should take place in order to enable the employee performance assessment
- By kicking of this policy, Neither overtime nor compensation policies will take place anymore
-
Bonus