Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
When you work remotely, you want to have some kind of a standup meeting regularly. In our team, after experimenting with many different approaches, we settled with text-based, asynchronous standups every day. Additionally, every project has a weekly 'sync' meeting.
Whatever tool we currently use for remote communication (irc in the past, now Slack), we create a channel that is dedicated to #standup. We don't have a specific time to post there, usually we do it, when we begin our work session - so, in the spirit of async - different people at different times.
I consider #standup to be a very good opportunity to communicate cross-project, to educate, to learn, to help. Short standup messages are not bad, but they miss this opportunity.
When writing the standup message, think more about the others, than about yourself - what can they get from it by reading your status?
Yesterday I finished the "fix the price calculator" feature, which was mostly about removing the Coffee code and rely on the value retrieved from the backend, via ajax. The nice thing was that the backend code was already covered with tests, while the Coffee one wasn't. After that I helped Jack with the "allow logging in with email" feature (we need it now because we have a batch import of users from system X soon). After that I did a small ticket, where I block buying licences for special periods of time. This was nicely TDD'ed, thanks to the concept of aggregate, introduced by Robert recently - all the tests pass < 1s. Here is a commit worth looking at: .
Today I'm going to start with foreman'ing the recent commits and after that I want to work the XYZ system to allow a better editing of entries. I'm not sure how to start it, so all help is welcome.
- many details,
- letting other people jump in and help me,
- some opinions about the code that I saw,
- some details about practices I applied (TDD, foreman'ing)
- reminds about some business information - import of users from the X system, happening soon
- links to the commit (potential education)
3. good thing
4. bad things
6. call for help
7. reminder about good practices (tdd, foreman, help colleagues)
8. code examples (link)
9. business-related info
(this blog post is a work-in-progress chapter in the Developer-oriented Project Management book.)
Published at DZone with permission of Andrzej Krzywda , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.