Product Tech Core
Process
Team
Philosophy
Clean code is good code
write code that lasts.
write it so other people (and yourself) can easily understand and maintain
Work on your communication skills daily (spoken, written, coded)
Maintain a pleasant environment (clean, organized)
Maintain a good relationship with your co-workers
Be transparent and polite
Cerimonies
Documentation
Help other team members
do not waste people's time (and your time as well)
Share knowledge and ideas. Always.
Have fun
linting is fundamental
unit tests are cheap, extremely useful and best part of documentation. You should write them on a daily basis (red, green, refactor)
writting reusable code should be always on your mind
if you think you need to write a script to solve something for a product, think twice
pair programming is gold, don't make it fool's gold
comments lie
opportunistic refactoring is way better than "refactor day"
make it run, make it better, make if fast
Products Boards
Issues & Bugs
Clean
Effective
Useful
Alive
Rich in visual resources
succinct
tasks being done always have onwers
small tasks are the best
tasks should take at least 1 hour and maximum of 8 hours (1,2,4,8)
daily meetings
Weekly Reviews
one task at a time
tasks with clear definition of done
pursue constant improvement
tasks execution should only start after task card is "active"
Bugs with the highest priority, should be tackled immediately
Issues priority should be defined with team lead and PM
when in pair programming, tasks should be duplicated
tasks are always related to a feature/User-story/Use-case
Version Control
Small Pre-Integration Reviews when necessary
(choose pair programming over code reviews)
very small commits
what was done yesterday
what will I do today?
is there any impediment keeping me from concluding a task?
15 minutes long
What were the increments in the product developed within the iteration ?
further clarification over business rules or functionality is needed?
30 to 60 minutes long
Is there any change in priority?
what is the new priority?
dev team + PM
dev team (PM optional)
Retrospective
what went well?
what needs improvement?
output: actions to take to improve.
with person in charge and date to do it
output: PM/customer validation
30 minutes long
Planning
what is the main goal for the next cycle/iteration/sprint?
what are the stories/functionalities/use-cases to be developed during the cycle?
is there any additional setup?
when: at the end of a cycle
small branches
Good written tests can help a lot to track and solve issues and bugs.
Whenever possible, write tests that proves the bug/issue was solved.
test coverage is just a number. It doesn't mean good tests were written
Security is everyone's responsibility (bad code is insecure code)
BRD
High level business rules
PM is responsible for building it
PRD
Ubiquitous language (should be reflected in every document or conversation related to the product)
entities and value objects definitions
Use-cases logics (diagrams, etc)
tech stack definition
Services definitions (C4 Model)
what will be logged and when?
dev team is reponsible for building it
live prototyping (Figma, Marvel, Sketch, etc)
output: document per se, Stories, high fidelity model
low fidelity sketches
general product info
main timeline
Infrastructure
02 or more daily merges to dev/main is awesome
No daily merge to dev/main is already a potential problem
01 daily merge to dev/main is fine
With live Monitoring
Cost-efficient
Secure
Clean