Log in

No account? Create an account
07 Сентябрь 2007 @ 11:37
Сравнение TrackStudio и JIRA - реакция от Atlassian  
Еще и недели не прошло с момента публикации нашего сравнения с JIRA, а мы уже получили первый комментарий от Atlassian.
Если коротко, то Charles пишет, что JIRA все-таки используется в Atlassian для разработки софта, а наше сравнение - брехня :-)

Итак, в сравнении упоминалось, что в Atlassian не используют JIRA для управления процессом разработки софта. Charles опроверг это утверждение, но не привел каких-либо дополнительных аргументов, поэтому будем ориентироваться на его оригинальный пост:

  • "All the issues marked as outstanding for the next release are printed out, two to an A4 sheet of paper." Т.е. первым делом они выбирают из JIRA задачи, которые будут делать в следующей версии. Тут все замечательно - в JIRA есть информация о всех задачах, есть комментарии пользователей, есть результаты голосования, указаны связи с другими задачами. Только зачем все это печатать ? Сейчас узнаем.
  • "The issues are divided between the developers, who are asked to estimate their pile purely on gut instinct. Developers are free to swap issues if they feel someone else is in a better position to estimate a particular task." Это значит, что процесс назначения задач происходит не в JIRA, а разработчики сами делят между собой распечатки.
  • "Estimates start at half an hour, and then increase roughly exponentially: one hour, two hours, half a day, one day, two days, four days, two weeks. Estimates are written on the printed issues in some bright, unmistakeable colour." Т.е. первоначальные оценки времени на выполнение задач они делают не в JIRA, а на бумаге. Может быть потому, что оценки времени в JIRA нельзя скрыть от клиентов ?
  • "Now you have your issues estimated, it’s time to go through them again and make sure there is at least some sanity to your schedule. Add up all the estimates, compare them to when you feel you want to release, and cull your issues until the former fits into the latter." Для оценки предполагаемых затрат времени и планирования релизов используются все те же распечатки багов. Предполагаемые затраты времени суммируют вручную ?
  • "Find a stretch of uninterrupted wall in easy reach of the whole development team. Blue-tac all the issues to that wall, grouped in vague areas of functionality." Для группировки задач и для оценки прогресса все так же используется стена.
  • "Developers take an issue off the wall, and work on it until it is done". Для информирования о том, что разработчик начал работать над проблемой, он просто снимает листок со стены. Отражается ли процесс ли процесс назначения задач в JIRA - не понятно.
  • "Developers must never take more than one issue off the wall at a time." Правила назначения задач - не в JIRA.
  • "Once an issue is done, the developer records the actual time taken in the other corner of the issue, dumps it in the ‘done’ pile, and updates the whiteboard."  Трекинг реальных затрат времени - не в JIRA.
  • "The state of the wall is a clear indicator of progress, and as it empties there is a palpable feeling of satisfaction". Оценка общего прогресса - опять стена.
  • "As a bonus, you end up with a pile of paper that records differences between estimated and elapsed time". Разница между планируемыми завтратами времени и актуальными - по бумажкам.

Я не говорил, что их процесс разработки программного обеспечения хороший или плохой. Но где тут использование JIRA для управления процессом разработки ПО - я не знаю.
Максим Крамаренкоmaximkr on Сентябрь, 8, 2007 11:14 (UTC)
Thanks, I'll try to answer in English, it is not perfect, but (I hope) better than Google Translate :-)

> Firstly, this is not a response from Atlassian, it's a response from me. You linked to my personal
> blog, which I maintain in my own time, and which isn't at all affiliated with Atlassian. I don't
> think my employer even knows I responded, to be honest.

ok, I understand. I have decided that you discuss this with co-workers, because we got almost 50 unique visitors from extranet.atlassian.com. Not sure what that site is, but seems like internal corporate wiki (I can be wrong).

> It's like saying we don't manage our project entirely in the issue tracker because we
> use whiteboards, or because we have face-to-face conversations.

This is what we mean, when wrote "Atlassian developers uses JIRA primary to communicate with external users, but they do not use it to manage software development." :-)

We are in simmetric position there - we use TrackStudio to manage software development (task assignment, estimates, employee time tracking, internal discussions, etc), but DO NOT use it to discuss problems with customers or gather feature requests - I am prefer more personal ways, like IM, e-mail, phone or forum. Change requests are finally goes to TrackStudio, but I cannot say that we use TrackStudio for customer support now.

Nothing wrong with our way or Atlassian way - both can work for different companies in different position. I know several users, which decided to use JIRA after reading your blog post, because they use very similar way to develop software. But for our target customers (we wrote the comparison for them) Atlassian way looks a little strange. Showing the difference, we allow customers to make more informed decision, which is benefical for both our companies.

Please check this (a little outdated) link:
There are many cases where it would be useful to have issue-level
concepts (type, lifecycle, priority, due date, scheduling, custom fields)
apply to projects, and project-level concepts (permissions,
notifications, URLs) apply to issues. Effectively treating projects as
aggregate issues.

JIRA will evolve to greater levels of generality as users request it.
You might want to file an enhancement request for project-level custom
fields on jira.atlassian.com.

In general, JIRA needs to keep a balance between simplicity for 80% who
don't need advanced features, and generality for the 20% who do. Giving
users the source (or just JSP source, as illustrated above) lets us err
on the side of simplicity.

It seems like Atlassian strategy not changed since that time (custom fields for projects still not implemented :-), so I don't think that JIRA team members are really welcome pressure from that 20% of users.