Skip to content

Latest commit

 

History

History
76 lines (60 loc) · 3.46 KB

readme_en.md

File metadata and controls

76 lines (60 loc) · 3.46 KB

dev-manifesto

The Tokardy tech team appreciates and values the following points for (future-) Tokars:

1. Production / method

Being agile, which means:

  • work on what brings the most value to Toucan at the moment t

    Examples

    To find out, I ask myself the following questions:

    • will what I am doing benefit a user/customer/designer/tokar from the moment it is launched? If so, will it allow him to do something he couldn't do before? Will it allow him to do something twice as fast as before?
    • on the other hand, is what I have done a marginal improvement, or one that does not benefit anyone in the immediate future?
    • is what I'm working on merged/integrated into the product? Or is it dropped?

  • set very progressive steps and stick to them

    Examples
    • the feature I work on has been divided into small simple steps, clearly described in a Trello card
    • the feature I work on was not properly planned, I quickly saw that it was more complicated than expected, I send the Trello card back into the design column

  • deliver these small steps as often as possible

    Examples
    • I can make a v0 of my feature and present it in a few days
    • I can start a project with confidence that PR will be opened in the evening
    • I focus on the essentials in the PRs and avoid making additional modifications, "drive by changes".

  • state your goal and communicate your progress to the rest of the team

    Examples
    • I use our daily meeting to communicate on my current projects, my difficulties
    • I update Trello, the wiki
    • my PRs are clear and self-sufficient (screenshots, test urls, examples of API use, examples of confs)
    • It's easy and enjoyable for me to speak about the projects and tasks on which I have contributed

2. Autonomy

Being autonomous means that when you start on a project, you commit yourself to it and put the necessary energy into it to deliver it. This does not mean NOT working alone.

In particular, we recommend:

  • to identify the needs to which we are responding: what is the demo of my feature?

  • to identify precisely the points on which assistance is needed

    Example
    • I know how to ask for help when I'm stuck with a task
    • I know how to get support from other devs on difficult technical project, and show that they are worth it

  • to go to his colleagues with specific and clear questions

  • to start with the tasks at the top of the common backlogs, where I feel and I can deliver and commit to process

3. Apprenticeship

To be a driving force in continuous learning, for you, your colleagues and the organisation:

  • take the time to peer-program as often as possible

    Examples
    • Communicate well with the rest of the team to synchronize with your teammate by setting events in the calendar

  • document your the learning process so that it cal help others

  • follow up on what you have learned (use a Trello board for example) and communicate it to the rest of the team, take the lead on projects in your new areas of expertise to validate them

4. Attitude

Have a good work ethic, be honest with yourself and your colleagues about:

  • skills
  • difficulties
  • our ability to deliver (there is no point in announcing the moon, if not to disappoint)