83 lines
4.3 KiB
Markdown
83 lines
4.3 KiB
Markdown
# The BTS Development Process #
|
|
|
|
## Projects ##
|
|
Our development work is organized in projects. A project is a
|
|
non-trivial effort to specify, develop and validate a related set of
|
|
additions to our Spark platform. A project can be assigned to one more
|
|
developers and a developer might concurrently be assigned to multiple
|
|
projects. Projects typically start out with specification work,
|
|
proceed to implementation and finish with validation efforts. At any
|
|
given time there will be multiple projects being worked on
|
|
concurrently. A project is concluded when the features it implements
|
|
are merged into the product and deployed to customers.
|
|
|
|
## The Details ##
|
|
Typically project ideas come from sales interactions, opposition
|
|
research and customer feedback, all tough on occasion development or
|
|
operational requirements can also suggest valuable project
|
|
ideas. Whatever the source of a project idea the final decision of
|
|
which projects to pursue is always done by management. Once a project
|
|
idea has been selected for implementation the corresponding project
|
|
will go through several phases: inception, specification, development,
|
|
validation and merge.
|
|
|
|
* Inception. In this phase the infrastructure for the project is
|
|
created. Typically this means selecting a team, creating a project
|
|
case in Jira (that is a case assigned to the team@bluetradesys.com
|
|
Jira user) and possibly creating a new branch for the project. This
|
|
phase is mostly mechanical and the responsibility of Pedro.
|
|
|
|
* Specification. The specification phase turns a usually vague and
|
|
ill-considered idea project idea into a concrete, implementable
|
|
specification that attempts to maximize the value/cost ratio of the
|
|
project. It is hard to exaggerate the impact of a this phase on the
|
|
rest of the project. *Nothing* has more impact on BTS's ability to
|
|
quickly deliver value to customers than good specification work. A
|
|
specification typically takes the form of a shared google docs using
|
|
a mix of text and UI mock-ups to capture both user requirements and
|
|
suggested implementation strategies. Taha and Kevin are responsible for this
|
|
phase.
|
|
|
|
* Development. Once a specification is complete, a team of developers
|
|
will use a project specific branch to implement the
|
|
specification. Periodically, typically once a week, progress on the
|
|
project is assessed by Pedro, possibly with the help of others. This
|
|
assessment takes the form of code reviews, demos, or just one-on-one
|
|
conversations. To ensure development does not go off on tangents,
|
|
developers are expected to continuously merge master into the project
|
|
branch as well as encouraged to create Pull Requests (PRs) early in
|
|
the project implementation, so that their work is kept visible and
|
|
integrated with that of the rest of the group. During the
|
|
implementation phase developers should reach out to Pedro for UI
|
|
reviews, architecture and design questions and specification trade off
|
|
concerns.
|
|
|
|
* Verification. Once code is complete it is the project's team job to
|
|
think carefully about the best way to verify that the work is solid
|
|
enough to go to production. We do not have a dedicated QA cycle to
|
|
flush out bugs so it is important for changes to be fully tested
|
|
before being marked ready to merge (RTM). For any non-trivial change
|
|
project teams should enlist a 'test buddy' from outside the team to
|
|
help review the code and think of test cases that they may not have
|
|
considered. Stability from release to release is especially critical
|
|
right now as we develop a reputation in the futures
|
|
world. Additionally, project teams are encouraged to make liberal use
|
|
of other testing techniques such as
|
|
- Unit tests
|
|
- System tests
|
|
- Manual tests
|
|
|
|
* Merge. Once a project is considered complete by developers, a PR
|
|
that includes Pedro should be created (unless, as mentioned above, an
|
|
early PR was already created in the development phase). Whether the PR
|
|
already existed or not, its description should be changed to start
|
|
with the RTM (Ready To Merge) acronym. This marks the project as ready
|
|
to be merged into master. Once a week, typically on Mondays, Pedro
|
|
will go through every PR marked as "Ready To Merge", build it, check
|
|
it out and if everything looks good merge it to master. At the end of
|
|
the day the resulting master will be tagged with a new version
|
|
number. This version will be go through some additional testing by
|
|
Brian and will then be deployed by Karl and Pete to customers
|
|
throughout the rest of the week.
|
|
|