HipChat blog runs a rather lengthy post on what ChatOps are – “What is ChatOps? A guide to its evolution, adoption & significance“, which provides some insight into how the new generation of teams communicate.
At Qobo, we are at Stage 3 – Gimini, with a whole lot of dedicated rooms (one for each project, and a few more), some workflows (most notably “Hey Leonid, can you merge and deploy this pull request please“, or a shorter “@leonid, please m&d”), and some automation (we get monitoring notifications from Nagios and Zabbix, repository activities from GitHub and BitBucket, as well as do project deployments using slash commands).
We haven’t eliminated email completely, but combined with Redmine project management tool, we’ve significantly decreased the role of unstructured emails in our work.
“Agile Failure Patterns In Organizations” explains why Agile is simple and complex at the same time.
Finally! Something I can distract all those Agile prophets with, while I sneak out to do some work.
deadline driven development:
when management believes that the only path to improved developer productivity is imposing arbitrary, unrealistic deadlines.
… there are more good ones.
CandyCane – Redmine ticketing system port to CakePHP
Tools of the Trade – a huge collection of tools (mostly software as a service) for all kinds of web work: development, troubleshooting, project management, testing, emails, etc.
Thoughts on Running an Open Source Project
I love it when people share their code, just make something and publish it, but to my mind it isn’t an open source project until it has people around it. There’s nothing wrong with building something as a hobby, but it’s quite different to have people around it.
north – design and development standards to align and guide your project
Often referred to as waterfall, the old method of a static page being created by a designer, approved by a product owner, and then handed off to developers without further communication does not produce results in the best interests of anyone involved. The product owner doesn’t see the final product until it is all finished and ready for launch, much too late to make any significant corrections or alter the path of the project.
Instead, a more agile process, where product owners, designers, and developers all work in conjunction with one another to build value in a product throughout its development cycle, is needed. One where a small amount of work and constant feedback between all parties can build a large project out of small parts. One where the final project may not have every bell and whistle hoped for, but rather has an array of features that fulfill the maximum potential of the cost of development based on business and user needs. This is a large change in the way most individuals and organizations have done this type of work in the past, but by sticking to this process, a better product will be built in the long run, and those involved in the building will not be exhausted or burnt out by the process.
Yesterday I came across a really elegant solution to the TODO list problem. I tried it out and got immediately hooked! If you are one of those people who practice variations of Zero Inbox approach – especially with your Desktop icons, I strongly recommend you try it out.
After using it for a few hours, I however patched it up a bit. Here is mine. It’s the same approach, just slightly more tilted towards my needs. More specifically:
- Use directories instead of empty files. Empty files are handy for any notes you need to throw into the TODO item, but directories are even more useful, cause I can drop related files into there and then get rid of all of them in one go, once the task is done.
- Run “todo” without any parameters to get the list of TODO items.