Skip to content

Commit 7dc6e8a

Browse files
committed
tmp add operations/ and other dirs
1 parent f120049 commit 7dc6e8a

File tree

151 files changed

+3024
-587
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

151 files changed

+3024
-587
lines changed

README.md

-10
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,4 @@
11
# Dwarves Playbook
2-
32
Dwarves Foundation is an innovation service firm. We have been building an organization with high standard software practices and business growth capabilities, helping tech startups, entrepreneurs and makers deliver their innovative software product since 2013.
43

54
We stand for the craftsmanship in software development. More than telling people how to do things, as a team, we take responsibility for collaboratively creating the product of innovation with the client. We value the long-term partnership, and we brought the economic impact through massive product distribution and brought to the market by the clients.
@@ -9,7 +8,6 @@ This repo is our playbook which contains our practices in software development a
98
![](/engineering/img/team-images.png)
109

1110
## Product Design
12-
1311
<Design Workshop>
1412

1513
- [Design Sprint](/design/design-sprint.md)
@@ -24,19 +22,16 @@ This repo is our playbook which contains our practices in software development a
2422
- [The Design System](/design/design-system.md)
2523

2624
## Developing
27-
2825
- [Software Philosophy: Engineering-Driven, Craftsmanship & Minifesto](/engineering/README.md)
2926
- [Workflow: Agile & Scrum Framework](/engineering/workflow.md)
3027
- [Technology stack: Our POV on Technology](/engineering/stack.md)
3128

3229
### Setup
33-
3430
- [Automate your development environment](/engineering/setup-laptop.md)
3531
- [Using right editor for the job](/engineering/editor.md)
3632
- [Keep your devices safe](/engineering/basic-security.md)
3733

3834
### Practices
39-
4035
- [Start a new project](/engineering/setup-project.md)
4136
- [Repository setup](/engineering/setup-repository.md)
4237
- [Write a good README file](/engineering/readme-how.md)
@@ -63,31 +58,26 @@ This repo is our playbook which contains our practices in software development a
6358
- [Defect Template](/engineering/testing/defect-template.md)
6459

6560
### Platforms
66-
6761
- [Android](/engineering/android.md)
6862
- [iOS](/engineering/ios.md)
6963
- [Frontend](/engineering/frontend/tech-ecosystem.md)
7064
- [Backend](/engineering/backend.md)
7165
- [API Security Checklist](/engineering/security/api-security.md)
7266

7367
## Production
74-
7568
- [Logging](/engineering/log.md)
7669
- [Monitoring](/engineering/monitoring.md)
7770
- [Production Checklist](/engineering/production.md)
7871
- [Handover Checklist](/engineering/handover.md)
7972

8073
## Business
81-
8274
- [Overall Process](/business/README.md)
8375
- [Fixed Budget, Scope Controlled](/business/fbsc.md)
8476
- [Collaboration Guildeline](/collaboration-guideline.md)
8577

8678
## Contributing
87-
8879
We love pull requests. If you have something you want to add or remove, please open a new pull request. Please leave all PRs open for at least a week to get feedback from everyone.
8980

9081
## License
91-
9282
Creative Commons Attribution 4.0 International (CC BY 4.0)
9383
@ [Dwarves Foundation](https://d.foundation)
Binary file not shown.

business/business-playbook-outline.md

-3
Original file line numberDiff line numberDiff line change
@@ -7,12 +7,9 @@ date: 2023-10-16
77
description:
88
authors: []
99
menu:
10-
toc: false
11-
notice:
1210
type: playbook
1311
---
1412
# BUSINESS PLAYBOOK
15-
1613
Table of Contents
1714

1815
1. Introduction

business/collaboration-guideline.md

-16
Original file line numberDiff line numberDiff line change
@@ -7,24 +7,19 @@ date: 2023-10-16
77
description:
88
authors: []
99
menu:
10-
toc: false
11-
notice:
1210
type: playbook
1311
---
1412
# Collaboration Guideline
15-
1613
Guidelines for project collaboration between DF and Clients.
1714

1815
## Tools
19-
2016
* Project management & communication: Basecamp (invited as Client)
2117
* Sprint planning & tracking: Jira/Basecamp
2218
* Meeting: Google Meet
2319
* Source control platform: Github/Gitlab (self-hosted)
2420
* Design: Figma/Sketch
2521

2622
## Schedule
27-
2823
* Project kick-off meeting: **1 session**
2924
* Sprint length: **1 week/2 weeks**
3025
* Sprint planning meeting: **1 per sprint**
@@ -37,7 +32,6 @@ Meeting notes for Sprint planning and Sprint retrospective will be sent within 3
3732
## Workflow
3833

3934
## Project Management
40-
4135
* All team members must be involved in Sprint planning
4236
* Milestones and features (epics) should be put on Jira/Basecamp during Project kick-off phase
4337
* New features/change requests will be put into Icebox/Backlog, estimated and planned for future Sprints
@@ -46,31 +40,27 @@ Meeting notes for Sprint planning and Sprint retrospective will be sent within 3
4640
* Every 2 weeks, the Team Lead, Product Manager/Project Manager and Account Manager will have a quick 15 minutes meeting to review the work progress and resolve any conflicts (if any)
4741

4842
## Design <> Development
49-
5043
* Design team should at least provide:
5144
- Color palette (all that are used throughout the UI)
5245
- Heading / Font size should be defined by scale
5346
- Base components (.eg headings, button variants and states,…)
5447
* New design version is expected to be available and reviewed **by development team** before the Sprint started
5548

5649
## Backend <> Frontend
57-
5850
* Prerequisite:
5951
- API versioning & documentation (.eg Swagger)
6052
- Dedicated environments for Development / Staging / Production
6153
* Backend should enable CORS on either API gateway or at application level
6254
* Both sides should agree on the same glossary / naming conventions / data schema, preferably within the first Sprint
6355

6456
## Quality Assurance <> Development
65-
6657
* Bugs/issues raised should include:
6758
- Steps to reproduce, behaviorally described from - application’s entry to bug encounter
6859
- Affected platform, version, feature, language (if applicable)
6960
- Severity level
7061
* For Frontend (web), each feature’s Pull Request will have a dedicated environment for testing. Use it to run feature tests before it got merged
7162

7263
## Release
73-
7464
* We release the end of each Sprint (on Sprint wrap-up day - the day before the Retrospective meeting)
7565
* Hotfix releases are ad-hoc
7666
* What’s included in a release:
@@ -80,7 +70,6 @@ Meeting notes for Sprint planning and Sprint retrospective will be sent within 3
8070
* Backend and Frontend (or each microservice in the system) will be released individually based on Semantic version
8171

8272
## Customer feedback
83-
8473
We received and responded to feedback via direct message, email or video calls. Specific feedback should be directed to specific PIC in a project team:
8574

8675
* Implementation/Development: Team Lead, Project Lead
@@ -90,38 +79,33 @@ We received and responded to feedback via direct message, email or video calls.
9079
* Communication issues: Project Lead
9180

9281
## Issues management
93-
9482
We promise to respond and resolve in a timely fashion when problems arise, depending on priority & severity.
9583
After issues are resolved, we will conduct an investigation and provide preventive measures (if applicable).
9684

9785
There are **4 levels** of severity:
9886

9987
### Critical: 4
100-
10188
Production system is down or a major function is unusable and there is no acceptable alternative method to achieve the required results. Support in such emergency issues is available via our hotline.
10289

10390
* Contact channel: hotline
10491
* Response time: within 10 minutes
10592
* Promised resolve time: less than 30 minutes
10693

10794
### Major: 3
108-
10995
Major features of the product are failed and/or performance issues impacting the normal functioning of multiple users.
11096

11197
* Contact channel: email, primary communicate channel
11298
* Response time: within 30 minutes
11399
* Promised resolve time: from 2 to 5 hours
114100

115101
### Moderate: 2
116-
117102
Moderate loss of application functionality or performance degradation. The system is still operating but doesn’t meet promised standard operation.
118103

119104
* Contact channel: primary communicate channel
120105
* Response time: within 45 minutes
121106
* Promised resolve time: within 7 hours
122107

123108
### Minor: 1
124-
125109
Minor issues such as visual incorrectness .eg color or font size, product feature requests and how-to questions.
126110

127111
* Contact channel: primary communicate channel

business/df-workflow.md

-2
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,6 @@ date: 2023-10-16
77
description:
88
authors: []
99
menu:
10-
toc: false
11-
notice:
1210
type: playbook
1311
---
1412
* Monday:

business/fbsc.md

+1-4
Original file line numberDiff line numberDiff line change
@@ -7,12 +7,10 @@ date: 2023-10-16
77
description:
88
authors: []
99
menu:
10-
toc: false
11-
notice:
1210
type: playbook
1311
---
14-
## Budget
1512

13+
## Budget
1614
We do need to know clients' budgets. This is often uncomfortable for them but their budget helps determines what scope is possible. It saves time. If they don't know their budget, we discuss different options.
1715

1816
We talk about breaking product rollout into stages and try to improve the product's chances of success at each stage by:
@@ -24,7 +22,6 @@ We talk about breaking product rollout into stages and try to improve the produc
2422
- Designing interactions into the product for users to bring other users to the product.
2523

2624
## No Fixed Bids
27-
2825
Some consulting relationships start with a requirements document or RFP ("Request For Proposal"). The requirements are often extremely detailed.
2926

3027
The probability of this document containing the optimum feature set is extremely low. The right features are better learned through user interviews, prototyping, releasing actual software, and getting feedback from real users.
+69
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
---
2+
tags:
3+
- pm
4+
title: Fixed Budget Scope Controlled
5+
date: 2020-07-22
6+
description: null
7+
authors: null
8+
menu: memo
9+
type: null
10+
hide_frontmatter: false
11+
created: 2020-07-22
12+
---
13+
14+
Fixed-Budget, Scope-Controlled (FBSC) is applied at Atomic Object. They build custom software for our customers. Because of the complexity involved in building a great software product, software development projects are always more difficult to price than a product.
15+
16+
As a result two different strategies for pricing services, such as building software, have traditionally been used by most companies. These are called “Fixed Price” and “Time And Materials”.
17+
18+
### Fixed Price
19+
* A Fixed Price strategy locks in the total price of the project upfront.
20+
* Static Variables: Scope, Cost
21+
* Flexible Variable: Quality
22+
* Assumption: The estimate and plan are correct and will not need to be changed.
23+
* Risk: On Consultant (Responds by inflating cost; may compromise quality if estimates are inaccurate.)
24+
* Effect of New Information: Causes conflict about what’s covered by the scope vs. what requires a change order. New ideas are rarely incorporated.
25+
26+
In this strategy, the vendor is taking on all the financial risk of a project. They have committed to completing the project for a specific price. If they complete the job early, it’s a bonus for the vendor (and you the client has overpaid), if they don’t then the vendor loses. In order to mitigate this risk, they will want to know all that can be known about this project and the risks before it will commit to a fixed price.
27+

28+
Also, they will vigorously fight any variations to the scope of the project during the development of the software. When variations do occur, there will invariably be an argument as to whether this change is included in the fixed price that was agreed to or not. If not, then it’s time to generate the dreaded “change order,” determine the new pricing, and get the new pricing approved by the customer.
29+

30+
This is unrealistic, as it very difficult — almost impossible — to know everything that will affect the project at the very beginning of a project. Also, it makes it difficult for the scope to change over the course of the project as new information becomes known that helps us to create a better software product.
31+

32+
Thus what appears to be a strategy for eliminating the financial risk to the client actually ends up introducing a new risk. By fixing the price and thus the scope of the project, we risk building the wrong product, or a product that doesn’t meet the needs of its intended audience.
33+
34+
### Time and Materials
35+
In a Time And Materials pricing strategy, the vendor will work on a project and bill for every hour worked without regard to any financial constraints. An estimate may have been created, but since they are paid regardless of whether they exceed the estimated amount, they don’t do more than just track their time.
36+
37+
* Static Variables: Scope, Quality
38+
* Flexible Variable: Cost (and Timeline)
39+
* Assumption: The client can afford to do whatever it takes to accomplish the scope.
40+
* Risk: On Client (Consultant has no incentive to be efficient or monitor budget.)
41+
* Effect of New Information: Either more scope — and more cost — are added to project, or the information is ignored because there’s no more budget.
42+
43+
In this scenario, the client is taking on all of the financial risk. The client will most likely have an internal budget they are monitoring and thus are de facto responsible for ensuring the actual amount worked is tracking to the estimated amounts. Unfortunately, what is missing here is what scope has actually been completed. Without this information, the client cannot accurately gauge the progress of the project and thus does not know if the estimate is going to exceed the estimate until it actually does.
44+

45+
Also, the client may still be reluctant to make changes to the project scope in an attempt to not exceed the estimated amounts given by the vendor. But if they do make changes to the scope, the vendor will easily agree to these changes and complete them. Why not? They are being paid by the hour regardless of what gets delivered or if they exceed their estimates.
46+
So while the vendor has mitigated their financial risk, the client now shoulders that risk.
47+
48+
### Fixed-Budget, Scope-Controlled
49+
We don’t feel either of these pricing strategies helps us to build better software within a responsible budget. So Atomic prices the services using a Fixed-Budget, Scope-Controlled (FBSC) strategy. In this strategy we work with our client at the beginning of the project to get a good understanding of the project. Using this information and our knowledge about building software, we then create a responsible budget. We do not fix the scope of the entire project upfront, we only fix the budget and time.
50+
51+
* Static Variables: Budget, Quality
52+
* Flexible Variable: Scope
53+
* Assumption: There are more ideas than money, so we’ll focus on creating the best possible product for the budget. We’ll learn as we go and reassess our scope and plan regularly.
54+
* Risk: Shared by Client & Consultant (and therefore reduced)
55+
* Effect of New Information: Scope flexes as client and consultant re-prioritize features, possibly moving some to 2nd release. Price and schedule need not be affected.
56+
57+
As the project progresses, we track our hours worked on the project and the features completed on the project. We work closely with our clients, meeting with them weekly to discuss the status of the project. Part of that weekly discussion involves reviewing the financial health of the project. We are upfront on the amount of budget that we have consumed and the progress we have made towards completion of the project.
58+

59+
As the project proceeds, there are many opportunities to learn from what has been completed and ensure that we are moving in the right direction. In some cases, this information comes from additional user testing of the design, early iterations of the product, or discussions with the team.
60+
The fact that we are not constrained by a contract with a fixed scope allows us to mold the project as we go along to take advantage of new information. The final outcome is a better product that better meets the needs of its users. Because we are actively monitoring and managing the budget, the client has the information necessary to feel comfortable with these scope changes, and we can determine the impact the changes will have on the budget.
61+

62+
Changes in scope will be reviewed to determine the impact they have on the project. If these changes increase the scope to the point where the budget may be exceeded, we are able to review the remainder of the project and make changes to the project scope that offset the increase. We can either move other less-important features to a later release, or we could reduce the complexity of a specific feature to help bring the project back in line with the budget.
63+

64+
Actively managing the budget on a weekly basis does not normally happen in either a Fixed Price or Time And Materials pricing strategy. In both cases the tendency will be to discourage any changes to the scope to eliminate increases in the price of the software. This is unfortunate because we learn a lot as the project progresses that can have a positive impact on the final product.
65+
While a budget is not a fixed price, it is a number we actively work towards meeting. Atomic has a great track record of meeting its budgets.
66+

67+
We feel this pricing strategy helps us to collaborate and cooperate better with our customer. The financial risk is now better managed and does not fall solely on a single entity. Working together, feeling free to make scope changes as we progress, and having the information necessary to manage the scope and budget makes for a much better working relationship and ultimately a better product.
68+
69+
Source: [https://spin.atomicobject.com/2014/08/25/fixed-price-vs-time-and-materials/](https://spin.atomicobject.com/2014/08/25/fixed-price-vs-time-and-materials/)

business/how-to-work-with-clients.md

-3
Original file line numberDiff line numberDiff line change
@@ -7,12 +7,9 @@ date: 2023-10-16
77
description:
88
authors: []
99
menu:
10-
toc: false
11-
notice:
1210
type: playbook
1311
---
1412
# TRAINING COURSE: HOW TO WORK WITH CLIENT
15-
1613
What skills that an engineer should have in order to work with client effectively?
1714

1815
1. Strong technical skills: includes

business/invoice.md

-2
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,6 @@ date: 2023-10-18
77
description:
88
authors: []
99
menu:
10-
toc: false
11-
notice:
1210
type:
1311
---
1412

business/nda.md

-2
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,6 @@ date: 2023-10-18
77
description:
88
authors: []
99
menu:
10-
toc: false
11-
notice:
1210
type:
1311
---
1412

business/service-feedbacks.md

-3
Original file line numberDiff line numberDiff line change
@@ -7,13 +7,10 @@ date: 2023-10-16
77
description:
88
authors: []
99
menu:
10-
toc: false
11-
notice:
1210
type: playbook
1311
---
1412

1513
# GENERAL QUESTIONS FOR SERVICE FEEDBACKS
16-
1714
1. Engineer performances
1815

1916
- a. Communication

0 commit comments

Comments
 (0)