это каждые 12 минут по человеку без перекуров — даже с учетом кризиса и многочисленных уволенных сотрудников, в такую скорость потока сложно поверить :)
Ну, премодерация это слишком, на мой взгляд. Если будет появляться много подобных команд — обязательно введем контроль заполнения профиля команды, спасибо за совет.
Насчет дизайна — ребят, красивая картинка не поможет успешно находить и завершать проекты, это же очевидно.
В настоящий момент наш приоритет — это минимально необходимая функциональность для того, чтобы можно было работать с сервисом и иметь возможность получать конструктивный фидбек от вас, потенциальных пользователей.
Новый дизайн будет чуть позже, если хотите, можете поучаствовать в его создании.
«Agile software development is a group of software development methodologies» — перечисляем либо Scrum и XP, либо просто говорим Agile.
en.wikipedia.org/wiki/Agile_software_development
Очень похоже на конспект семинара — вам понятно, а для тех, кому вы это писали, на мой взгляд, слишком скомкано.
Пара уточнений: в манифесте лучше переводить over = важнее во всех четырех пунктах. Ну и придуман и подписан он был скорее не руководителями крупных софтверных компаний, а идеологами различных гибких методологий (Scrum, XP, Crystal etc). agilemanifesto.org
Scrum — это не часть Lean, а отдельная методология семейства Agile.
В прошлом году проводили встречу AgileRussia на тему ретроспектив, осталась достаточно подробная презентация.
Еще из полезного — помимо опроса в стиле «что было хорошо, а что плохо», очень здорово проходят ретроспективы c помощью диаграммы starfish, когда команда опрашивается в стиле «что работало хорошо, чего не хватало, что нужно улучшить и т.п. (см картинку по ссылке)».
Этот способ позволяет взглянуть на прошедшую итерацию немного под другим углом, нежели обычная ретроспектива.
Разбор полетов обычно проводится после завершения проекта, когда уже поздно что-то менять (и скорее всего проект уже оказался не совсем успешным:) ).
Прелесть ретроспективы же в том, что мы анализируем двух (или одно-)недельную итерацию и можем улучшить свою работу прямо на следующий день после ретроспективы.
Видно, что у автора тема наболела :)
Согласен с «полетом» для нормального программиста, но среднестатистический стартап гораздо менее наукоемок и сложен тех больших проектов, в которых вам приходилось участвовать за свою карьеру.
И, соответственно, является отличным способом что-то попробовать и получить ценный опыт. За плохие стартапы ведь на кол не сажают. Не нравятся — просто не обращай на них внимания, интернет большой и они не мешаются.
Люди учатся, и это здорово!
Постоянно использую метафору разбитых окон в применении к модульному тестированию — сколько бы вы не внедряли модульные тесты и TDD, стоит вам только пару раз вовремя не исправить сломавшийся тест, как они будут ломаться один за другим, и для команды этот станет нормой…
Да незачто :) (не знаю, как правильно слово пишется).
Basecamp и похожие системы статистику не умеют собирать по скорости разработки, например, и делать прогнозы на будущее по срокам завершения реализации некоторого объема функциональности — а это часто бывает очень полезно.
Но, конечно, пользоваться каким-либо новым инструментом нужно только в том случае, если чувствуется необходимость в этом, вы совершенно правы.
Хорошие отчеты для наглядной иллюстрации состояния бизнеса.
А чем вы пользуетесь на уровне проектного управления?
Мне кажется, для «Полигона» и подобных ему «песочниц» здорово пригодился бы инструмент, который позволял бы вести целый набор проектов, учитывая загрузку людей между проектами; который бы показывал текущее состояние по каждому проекту и прогноз завершения реализации того или иного этапа. Ну и конечно поддерживал планирование, возможность фиксировать требования и связывать задачи с исходным кодом.
Один из таких инструментов DEVPROM, думаю, окажется вам очень полезным, особенно при росте количества команд и проектов.
Я бы предложил добавить на сайт форму быстрой обратной связи, чтобы пользователи могли оставлять сообщения об ошибках и свои предложения по улучшению сервиса — а их скорее всего будет очень не мало :)
Форму можно взять здесь: devprom.net/co/feedback/, добавляется на сайт несколькими строками.
Когда ошибка или предложение на улучшение будут реализованы, пользователь получит соотвествующее почтовое сообщение и вернется на сервис воспользоваться им еще минимум раз.
Мне кажется, что подзадачи это явно лишнее, а так же пункт 3, когда девелопер устанавливает _календарную дату_ выполнения задачи — зачем лишнее действие, если у задачи есть оцененная трудоемкость?
Если вашего техдира интересует календарный план, расписанный с точностью до задачи, то вы правы — это всего лишь бюрократия и может быть ему просто нужно показать бурную деятельность в компании, раз он у вас «новый».
Насчет облегчения работы с JIRA посмотрите плагин GreenHopper — добавляет очень удобный интерфейс и ускоряет работу в разы.
А вообще, как правильно уже здесь заметили выше — JIRA нифига не инструмент для управления проектом, а просто багтрекинговая система.
Поэтому, если вы не хотите обременять себя лишними сложностями при работе с инструментом для управления проектом, посмотрите на devprom.net.
В нем нет ничего лишнего, работать с ним просто и удобно, а ваш техдир будет видеть все что ему хочется.
Taskboard'ы гораздо информативнее коробочек, потому что с одного взгляда на доску видно, что и как. А тут придется вынимать задачи из коробки, рассматривать, класть обратно — явно не удобно.
и живая очередь из разработчиков у входа в офис с 7 до 22 :)
это каждые 12 минут по человеку без перекуров — даже с учетом кризиса и многочисленных уволенных сотрудников, в такую скорость потока сложно поверить :)
Насчет дизайна — ребят, красивая картинка не поможет успешно находить и завершать проекты, это же очевидно.
В настоящий момент наш приоритет — это минимально необходимая функциональность для того, чтобы можно было работать с сервисом и иметь возможность получать конструктивный фидбек от вас, потенциальных пользователей.
Новый дизайн будет чуть позже, если хотите, можете поучаствовать в его создании.
en.wikipedia.org/wiki/Agile_software_development
Вы сами-то читали?
Пара уточнений: в манифесте лучше переводить over = важнее во всех четырех пунктах. Ну и придуман и подписан он был скорее не руководителями крупных софтверных компаний, а идеологами различных гибких методологий (Scrum, XP, Crystal etc). agilemanifesto.org
Scrum — это не часть Lean, а отдельная методология семейства Agile.
на презентацию по ретроспективам: lobasev.ru/2008/06/blog-post.html
на Starfish ретроспективу: www.thekua.com/rant/2006/03/the-retrospective-starfish/
Еще из полезного — помимо опроса в стиле «что было хорошо, а что плохо», очень здорово проходят ретроспективы c помощью диаграммы starfish, когда команда опрашивается в стиле «что работало хорошо, чего не хватало, что нужно улучшить и т.п. (см картинку по ссылке)».
Этот способ позволяет взглянуть на прошедшую итерацию немного под другим углом, нежели обычная ретроспектива.
Прелесть ретроспективы же в том, что мы анализируем двух (или одно-)недельную итерацию и можем улучшить свою работу прямо на следующий день после ретроспективы.
Согласен с «полетом» для нормального программиста, но среднестатистический стартап гораздо менее наукоемок и сложен тех больших проектов, в которых вам приходилось участвовать за свою карьеру.
И, соответственно, является отличным способом что-то попробовать и получить ценный опыт. За плохие стартапы ведь на кол не сажают. Не нравятся — просто не обращай на них внимания, интернет большой и они не мешаются.
Люди учатся, и это здорово!
Basecamp и похожие системы статистику не умеют собирать по скорости разработки, например, и делать прогнозы на будущее по срокам завершения реализации некоторого объема функциональности — а это часто бывает очень полезно.
Но, конечно, пользоваться каким-либо новым инструментом нужно только в том случае, если чувствуется необходимость в этом, вы совершенно правы.
А способ выражения своих мыслей сделайте повежливее, пожалуйста.
А чем вы пользуетесь на уровне проектного управления?
Мне кажется, для «Полигона» и подобных ему «песочниц» здорово пригодился бы инструмент, который позволял бы вести целый набор проектов, учитывая загрузку людей между проектами; который бы показывал текущее состояние по каждому проекту и прогноз завершения реализации того или иного этапа. Ну и конечно поддерживал планирование, возможность фиксировать требования и связывать задачи с исходным кодом.
Один из таких инструментов DEVPROM, думаю, окажется вам очень полезным, особенно при росте количества команд и проектов.
Форму можно взять здесь: devprom.net/co/feedback/, добавляется на сайт несколькими строками.
Когда ошибка или предложение на улучшение будут реализованы, пользователь получит соотвествующее почтовое сообщение и вернется на сервис воспользоваться им еще минимум раз.
Если вашего техдира интересует календарный план, расписанный с точностью до задачи, то вы правы — это всего лишь бюрократия и может быть ему просто нужно показать бурную деятельность в компании, раз он у вас «новый».
Насчет облегчения работы с JIRA посмотрите плагин GreenHopper — добавляет очень удобный интерфейс и ускоряет работу в разы.
А вообще, как правильно уже здесь заметили выше — JIRA нифига не инструмент для управления проектом, а просто багтрекинговая система.
Поэтому, если вы не хотите обременять себя лишними сложностями при работе с инструментом для управления проектом, посмотрите на devprom.net.
В нем нет ничего лишнего, работать с ним просто и удобно, а ваш техдир будет видеть все что ему хочется.