Comments 14
Я так понял, что Вы используете ТОЛЬКО «инструмент работы с Гантом» и некую свою разработку «микроблогов»? То есть системы багтрэкинга, к примеру, JIRA у вас не прижились?
Как пишете спецификации/ТЗ? Что используете для коммуникации между программистами?
Пишем Test Cases для данной фичи или запроса на измнение. Выглядит это примерно так…
Таблица в Google Spreadsheet
ID | Description | Steps | Author | Pass/Fail | Remarks
Заполняется QA инженером. Пример:
ID:
2
Description:
Breadcrumb
Steps:
1. Verify that there is a breadcrumb component which contain chainlet of subcategories for which was selected comparative dataset view.
Click on first segment of breadcrumb(category name) and verify that you was redirected to category view page
2. Click on second segment of breadcrumb(subcategory name) and verify that you was redirected to subcategory view page
… обрезано…
Author:
Ivan Petrov
Pass/Fails:
Pass
Remarks:
— Эти тест кейсы смотрит и подтверждает Product Owner.
Впоследствии они используются в процедуре «обрубания хвостов»
Таблица в Google Spreadsheet
ID | Description | Steps | Author | Pass/Fail | Remarks
Заполняется QA инженером. Пример:
ID:
2
Description:
Breadcrumb
Steps:
1. Verify that there is a breadcrumb component which contain chainlet of subcategories for which was selected comparative dataset view.
Click on first segment of breadcrumb(category name) and verify that you was redirected to category view page
2. Click on second segment of breadcrumb(subcategory name) and verify that you was redirected to subcategory view page
… обрезано…
Author:
Ivan Petrov
Pass/Fails:
Pass
Remarks:
— Эти тест кейсы смотрит и подтверждает Product Owner.
Впоследствии они используются в процедуре «обрубания хвостов»
Насчет коммуникации — в основном прямое общение, иногда доска с фламастерами. Не приветствуется удаленная работа без особых причин.
Если команда распределенная — то Skype, все инструменты Web based…
Если команда распределенная — то Skype, все инструменты Web based…
Спасибо за ответы.
Концентрация на нуждах пользователя это замечательно. :)
А как разрабатывается общая «архитектура» (структура) разрабатываемого приложения?
> Насчет коммуникации — в основном прямое общение, иногда доска с фламастерами. Не приветствуется удаленная работа без особых причин.
Угу, просто вот я замечаю, что довольно трудно передать понимание даже через прямое общение… (ибо бэкграунд у всех разный) Мы с напарником создаем математические модели, например (работает хорошо, обычно исключает многозначность трактовки).
Как делаете Вы?
Концентрация на нуждах пользователя это замечательно. :)
А как разрабатывается общая «архитектура» (структура) разрабатываемого приложения?
> Насчет коммуникации — в основном прямое общение, иногда доска с фламастерами. Не приветствуется удаленная работа без особых причин.
Угу, просто вот я замечаю, что довольно трудно передать понимание даже через прямое общение… (ибо бэкграунд у всех разный) Мы с напарником создаем математические модели, например (работает хорошо, обычно исключает многозначность трактовки).
Как делаете Вы?
>>А как разрабатывается общая «архитектура» (структура) разрабатываемого приложения?
Тут есть несколько случаев.
1. архитектура предопределена. Это случай так называемого расширения удаленной команды (team extension). Т.е. есть выделенный архитектор снаружи который все уже нарисовал или рисует архитектуру.
2. архитектура стандартная. Например заказчик хочет получить несложный динамический сайт. Тогда архитектура диктуется фреймворком — Rails для Ruby, Spring для J2EE и т.д. В этом случае в команде все должны понимать термины фреймворка (Entity, DTO, Relation… ) и говорить на одинаковом языке.
3. случай, который наверное Вас наиболее интересует. Например нужно создать и подключить нативный модуль. Или синтегрироваться с неколькими ванешними системами. В этом случае у нас назначается Архитектор в команде, который принимает решения.
В общем процесс коротко трудно описать, но при построении архитектуры мы используем простые и хорошо себя зарекомендовавшие подходы — слоистый паттерн, шина, веб сервисы для интеграции с нами, модуль протоколов для интеграции с внешними системами, шаблон интерпретатора если система будет в каком-то плане интенсивно препрограммироваться или обучаться.
Специально для создания и вникания остальных людей в архитектуру у нас в начале каждой фазы идет Архитектурная Итерация. Она не имеет или имеет мало функциональной нагрузки. Ее задача — создать общий каркас для последующей работы команды.
>>просто вот я замечаю, что довольно трудно передать понимание даже через прямое общение
Да это верное наблюдение. Передать картину из одного мозга в другой — пожалуй цивилизационная проблема. Ее можно решать например Моделингом (UML и т.д.) но у нс не прижилось. Пробуем объясняться словами, жестами, рисунками и какакулями на доске :).
Тут есть несколько случаев.
1. архитектура предопределена. Это случай так называемого расширения удаленной команды (team extension). Т.е. есть выделенный архитектор снаружи который все уже нарисовал или рисует архитектуру.
2. архитектура стандартная. Например заказчик хочет получить несложный динамический сайт. Тогда архитектура диктуется фреймворком — Rails для Ruby, Spring для J2EE и т.д. В этом случае в команде все должны понимать термины фреймворка (Entity, DTO, Relation… ) и говорить на одинаковом языке.
3. случай, который наверное Вас наиболее интересует. Например нужно создать и подключить нативный модуль. Или синтегрироваться с неколькими ванешними системами. В этом случае у нас назначается Архитектор в команде, который принимает решения.
В общем процесс коротко трудно описать, но при построении архитектуры мы используем простые и хорошо себя зарекомендовавшие подходы — слоистый паттерн, шина, веб сервисы для интеграции с нами, модуль протоколов для интеграции с внешними системами, шаблон интерпретатора если система будет в каком-то плане интенсивно препрограммироваться или обучаться.
Специально для создания и вникания остальных людей в архитектуру у нас в начале каждой фазы идет Архитектурная Итерация. Она не имеет или имеет мало функциональной нагрузки. Ее задача — создать общий каркас для последующей работы команды.
>>просто вот я замечаю, что довольно трудно передать понимание даже через прямое общение
Да это верное наблюдение. Передать картину из одного мозга в другой — пожалуй цивилизационная проблема. Ее можно решать например Моделингом (UML и т.д.) но у нс не прижилось. Пробуем объясняться словами, жестами, рисунками и какакулями на доске :).
Как ставятся задачи сотрудникам и отслеживается прогресс их выполнения?
На большом митинге в начале итерации обсуждается весь функциональный беклог что дает общее понимание задач итерации каждому разработчику. Затем раздаются первые задачи с вершины беклога программистам. При этом каждый программист получает список тест кейсов для его задачи.
Формально выдача задачи отражается на Гантте итерации в виде подсоедиения ресурса к задаче.
Прогресс выполнения также отражается непосредственно на этом Гантте. Если менеджер или тим лид хочет отследить детально этот прогресс, он кликает на задаче и видит ее микроблог со всеми постами программиста.
Формально выдача задачи отражается на Гантте итерации в виде подсоедиения ресурса к задаче.
Прогресс выполнения также отражается непосредственно на этом Гантте. Если менеджер или тим лид хочет отследить детально этот прогресс, он кликает на задаче и видит ее микроблог со всеми постами программиста.
Как справляетесь с ошибками в оценке сроков выполнения задач? И что делаете, если сроки срываются? Я не имею ввиду «внешние» сроки, раз вы выдаете обновление продукта каждую неделю- тут особых вопросов нет. И все-таки у каждой внутренней задачи есть свой срок, чем вы обеспечиваете ее выполнение к этому сроку?
Хороший, сложный вопрос.
Да, верно, довольно часто бывает что «внутренняя» задача затягивается. Давайте посмотрим что у нас есть из «оружия» на этот случай.
Во первых на нашей стороне статистика. Когда делается оценка функционала который мы включаем в итерацию, она делается крупными прикидками — мы получаем некоторые средние оценки для задач. Если задача задерживается внутри итерации процентов на 15-20%, это вполне вероятно может быть компенсировано следующей задачей, которая потребует на 15-20% меньше времени.
Оружие по-мощнее — дережирование (orchestration) — на более сложный случай. Принцип действия основан на факте что любая (практически) ситуация с задачами и ресурсами может быть оптимизирована на основании лучшего понимания деталей в момент их реализации. Пожалуй всегда можно «Васю-поменять-на- Колю,-а-задачу-Васи-передать-Тане,-поскольку-она-работает-в-том-же-наборе-классов». То есть простой перестановкой людей и задач можно выйти из ситуации средней сложности.
На этом популярные инструменты заканчиваются. Если все плохо и оба буфера не сработали — у нас есть сверхурочные часы, и (простите братья программисты), субботы… Это запрещенное оружие, но если других вариантов нет… Из того-же класса добавление экстра-ресурсов или замена людей на проекте. К сожалению и это мы проходили…
Да, верно, довольно часто бывает что «внутренняя» задача затягивается. Давайте посмотрим что у нас есть из «оружия» на этот случай.
Во первых на нашей стороне статистика. Когда делается оценка функционала который мы включаем в итерацию, она делается крупными прикидками — мы получаем некоторые средние оценки для задач. Если задача задерживается внутри итерации процентов на 15-20%, это вполне вероятно может быть компенсировано следующей задачей, которая потребует на 15-20% меньше времени.
Оружие по-мощнее — дережирование (orchestration) — на более сложный случай. Принцип действия основан на факте что любая (практически) ситуация с задачами и ресурсами может быть оптимизирована на основании лучшего понимания деталей в момент их реализации. Пожалуй всегда можно «Васю-поменять-на- Колю,-а-задачу-Васи-передать-Тане,-поскольку-она-работает-в-том-же-наборе-классов». То есть простой перестановкой людей и задач можно выйти из ситуации средней сложности.
На этом популярные инструменты заканчиваются. Если все плохо и оба буфера не сработали — у нас есть сверхурочные часы, и (простите братья программисты), субботы… Это запрещенное оружие, но если других вариантов нет… Из того-же класса добавление экстра-ресурсов или замена людей на проекте. К сожалению и это мы проходили…
Спасибо за ответ. У нас в компании организация работы, судя по Вашему посту, напоминает вашу- небольшие итерации, взаимодействие лицом к лицу, митинги, отчеты, еженедельные обновления и т.д. К сожалению, часто сталкиваемся с ситуацией, которую я бы охарактеризовал, как «объективные задержки».
Например, делаем новую фишку в реализации протокола работы с аппаратурой. Или, как вариант, взаимодействие со сторонними программами. Делаем, более-менее укладываемся в сроки. Тестируем, запускаем на продакшн. И оказывается, что у клиентов полно оборудования, которое несколько «своеобразно» трактует стандарты. Или старые/измененные версии софта, которые чуть иначе обменом занимаются. И начинается свистопляска на недели с переделыванием правильного, но неработающего, кода в неправильный, но работающий. Каждый такой сбой тянет за собой сроки по остальным задачам. Особенно болезненно, когда на человеке висят задачи, от которых зависят другие люди в команде. Перекинуть задачи можно и нужно, особенно если ситуация выявилась не в самом конце, и еще есть резервы на состыковку, чтобы не отбирать задачу на середине и не отдавать кому-то еще. Такие моменты предсказать, с одной стороны, можно, с другой- закладывать лишний месяц на каждый проект- слишком расточительно. К тому же начальство тоже знакомо со статистикой, поэтому выделятьлишнее запасное время в упор не получается.
Тасовать задачи между людьми- это, к сожалению, приводит к снижению производительности по очевидным причинам. Да и как тасовать, если людей мало, и все загружены по самое «нехочу». Экстра-ресурсы хороши в начале и середине проекта, а ближе к концу их эффективность сильно под вопросом.
Может, все дело в том, что сейчас большая часть задач у нас- новые в той или иной степени для всей команды, а оценки делаются, исходя из статистики старых задач.
Поэтому мне очень интересно, как с этим справляетесь вы, похоже, у вас диапазон задач гораздо шире, чем у нас.
Я правильно понял, что у вас основное направление- это Web?
Например, делаем новую фишку в реализации протокола работы с аппаратурой. Или, как вариант, взаимодействие со сторонними программами. Делаем, более-менее укладываемся в сроки. Тестируем, запускаем на продакшн. И оказывается, что у клиентов полно оборудования, которое несколько «своеобразно» трактует стандарты. Или старые/измененные версии софта, которые чуть иначе обменом занимаются. И начинается свистопляска на недели с переделыванием правильного, но неработающего, кода в неправильный, но работающий. Каждый такой сбой тянет за собой сроки по остальным задачам. Особенно болезненно, когда на человеке висят задачи, от которых зависят другие люди в команде. Перекинуть задачи можно и нужно, особенно если ситуация выявилась не в самом конце, и еще есть резервы на состыковку, чтобы не отбирать задачу на середине и не отдавать кому-то еще. Такие моменты предсказать, с одной стороны, можно, с другой- закладывать лишний месяц на каждый проект- слишком расточительно. К тому же начальство тоже знакомо со статистикой, поэтому выделять
Тасовать задачи между людьми- это, к сожалению, приводит к снижению производительности по очевидным причинам. Да и как тасовать, если людей мало, и все загружены по самое «нехочу». Экстра-ресурсы хороши в начале и середине проекта, а ближе к концу их эффективность сильно под вопросом.
Может, все дело в том, что сейчас большая часть задач у нас- новые в той или иной степени для всей команды, а оценки делаются, исходя из статистики старых задач.
Поэтому мне очень интересно, как с этим справляетесь вы, похоже, у вас диапазон задач гораздо шире, чем у нас.
Я правильно понял, что у вас основное направление- это Web?
Да, ситуация знакома… Тяжело советовать без детального понимания ситуации… Может какие-то из следующих идей Вам помогут? Надеюсь…
Вы отстаете от плана итерации или общего оценочного плана? Если от оценочного то это не очень серьезная методическая проблема. Если заказчик пошел с вами Agile, то он должен был быть готов к такому повороту. Если отстаете от итерационного плана — то главное дожить до следующей итерации — там вы сможете подкорректировать оценочную скорость команды.
Если возникли проблемы с интеграцией из-за недостаточно детальной информации о протоколах от заказчика, то можно это просто попробовать обсудить с ним и сделать так называемый рескоуп — растянуть соответствующие части оценочного плана.
Также можно подумать об оптимизации архитектуры Вашей программной системы. Например вынести протоколы из хардкода в настройки или скрипты. Может быть Вам пора также сделать рефакторинг? Если система долго росла — код нужно «перетряхнуть». Мы заметили что после рефакторинга у нас был серьезный прирост производительности разработки.
Вы отстаете от плана итерации или общего оценочного плана? Если от оценочного то это не очень серьезная методическая проблема. Если заказчик пошел с вами Agile, то он должен был быть готов к такому повороту. Если отстаете от итерационного плана — то главное дожить до следующей итерации — там вы сможете подкорректировать оценочную скорость команды.
Если возникли проблемы с интеграцией из-за недостаточно детальной информации о протоколах от заказчика, то можно это просто попробовать обсудить с ним и сделать так называемый рескоуп — растянуть соответствующие части оценочного плана.
Также можно подумать об оптимизации архитектуры Вашей программной системы. Например вынести протоколы из хардкода в настройки или скрипты. Может быть Вам пора также сделать рефакторинг? Если система долго росла — код нужно «перетряхнуть». Мы заметили что после рефакторинга у нас был серьезный прирост производительности разработки.
Sign up to leave a comment.
Прагматический Процесс Разработки в «не-книжных» условиях