![]() We have a “Weekly release” project in Nozbe where all the recurring tasks with their pinned comments and checklists are stored. It’s a semi-automatic-semi-manual process but thanks to it there’s a fresh Nozbe for everyone weekly! ☑️ P.S. We love checklists in tasks! This happens, but then we fix the bugs quickly and not sweat □ about it, because… □ Shipping train! We ship every week!Īlmost every Monday there’s an updated Nozbe app shipped to all the customers on all the platforms. □ Bugs do show up!Įven though we have code review, testing and dogfooding, sometimes we ship to production a feature with bugs. This ensures no crazy edge-case issues come up over longer usage. On a normal day we update Nozbe app at least 3 times on each platform! □♀️ Features wait on Dogfooding at least 1 week!Įven if a feature has been approved by the team, checked out by the Q/A engineer, we don’t release it to production for at least a week. The “ dogfooding” Nozbe builds are being pushed to our company Slack and our sync engine forces us to get the latest app by being really annoying about it. Many heated □ discussions are happening there! □ We really force people to use Dogfooding app! The programmer/author of the feature announces it to the whole team in our “Dogfooding” project in Nozbe so that everyone can check it out, test it and give their feedback. Apps for all the platforms are built automatically… and system forces all of our team to download them… NOW! □ Entire team tests and eats the dog food! When a feature is coded by the programmer, they decide when they’re done and merge it to “master”. □ Dogfooding - we use cutting edge version of Nozbe every day! Programmers comment on code in GitHub (but only code!). We comment on tasks there so that entire team can participate. We discuss the feature’s specs, behavior and design in its assigned Nozbe project. ✔️ Nozbe vs GitHub? Where’s the discussion? This is all happening in a branch or pull request (PR) on GitHub. The programmer also chooses a colleague who will review their code. If me or any manager want to know what’s up, we simply check the “Status” tasks! □ Code review! A colleague reviews it! This is where they document their work progress. ✍️ Programmers journal! Kind of.Įach programmer in their feature project has a special “Status” task with a tag. They follow the design, but they decide how they work on it or when they merge it to our “master” branch. □□ Programmers OWN their features!Įach programmer who is assigned to a feature is responsible for it. Everyone from the team can access these projects and chime in. We group projects from the same dev cycle together. We have a project template in Nozbe with “Design”, “Development” and “Bugs” sections for each new feature. Taken from 37signals playbook, we plan 6 weeks in advance and after that we decide again which features to work on in next cycle, which continue, which don’t or what to choose from the portfolio. ![]() □ Cycle? Yes, we work in 6-weeks cycles! It might be chosen in next programming cycle. When the feature is designed and has all the specs, it is being dragged down to our “portfolio of options” section in “Design” project. When we have our design meeting, we fight over each detail! □ Feature is designed? Goes to portfolio of options! ![]() We have a “Design” project in Nozbe where we post suggestions for new features. Last week I did a guest webinar (in Polish) on how we ship Nozbe app and I gave all the details… In a nutshell, we break lots of “industry standards”, and we eat dog □ food… □ NEW FEATURES? We design them and fight!
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |