Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Зачем вести отдельный документ с добавленными фичами, если есть отчеты в JIRA?
Мы файл с фичами периодически показываем заказчику. Также файл ведется в Excel и на дополнительных страницах я еще виду разбиение фич на подзадачи, + там же и импакт анализ делается на каждую фичу в спринте, а его в JIRA нормально не нарисуешь. Если б не импакт анализ, то в общем-то можно было все делать и в JIRA или поставить, например VersionOne — как раз для работы по Scrum предназначен. Но JIRA и VersionOne — вещи платные, а заказчику просто удобно смотреть все в Excel, а на треккер он вообще не заходит, ему это не интересно.
Отчеты в JIRA ситуационные.
Если нужно видеть историю работы, то есть смысл складировать подобные данные в wiki.
Если нужно видеть историю работы, то есть смысл складировать подобные данные в wiki.
Иными словами, у вас все как у людей — про методологии слышали, внедряли, что-то прижилось, что-то нет. Одним словом это называется Agile. Хотя найдутся умники, кричащие, будто это lean. И другие умники, отвечающие, что lean — одно из течений agile
Судя по тому, что хватает одной такой страницы, вам везет — проект небольшой, такой, что в голове удержать можно и на одну страничку помещается. Далеко не всегда так бывает.
Больше всего добивают те горе-специалисты, которые вцепляются в одну методологию, а потом начинают орать на команду всякий раз, когда кто-то хоть чуть-чуть отклоняется от заданного процесса. Насмотрелся я на таких скрам-храм-трам-барам-мастеров! Обычно такие вырастают из неинженерных направлений (BA, QA, HR), а вчерашние инженеры наоборот часто тяготеют к таким вот lean-подходам, т.к. часто воспринимают задачи, связанные с управлением, как оверхед — необходимое зло, которое нужно свести к минимому. Истина, как всегда, где-то посередине и зависит от конкретного случая.
А еще я автора знаю, поэтому обижать не хочется, но если притвориться, что мы не знакомы (ага?), то я бы добавил:
Уважаемый, во-первых одно капитанство. Львиная доля написанного очевидна даже для тех, кто не то, чтобы проектами не управлял, а вообще не тимлидил ни разу. Много воды и статья ни о чем.
А во-вторых, схема методологий у вас совершенно нечитаемая. Какие-то круги-круги-круги. Ворох умных и не очень слов. Вот и создается впечатление, что и в голове у вас тоже ворох слов и понятий. Похожее впечатление возникает, когда резюме начитанного джуниора без опыта читаешь.
Попробуйте наоборот поступить — не показывайте «источники вдохновения», а покажите сами практики, которые вы переняли. Например, канбан славен тем, что ограничивает объем задач, находящихся в процессе. Если много задач находятся в стадии work-in-progress, то новую задачу начинать запрещено. У вас такой лимит есть? Если да — отображайте. Нет — выбрасывайте. Или, например, стендапы из скрама: есть они у вас — пишите, нет — не пишите. И в результате будут не круги, а список практик, соответствующий разным аспектам ведения проекта.
По списку практик уже можно сравнивать подходы в управлении. А то выходит такое, что один говорит:
— У нас скрам, поэтому мы делаем A!
А другой ему отвечает:
— И у нас скрам, именно поэтому мы A не делаем!
А вы сидите и думаете: «кому из них верить?»
Судя по тому, что хватает одной такой страницы, вам везет — проект небольшой, такой, что в голове удержать можно и на одну страничку помещается. Далеко не всегда так бывает.
Больше всего добивают те горе-специалисты, которые вцепляются в одну методологию, а потом начинают орать на команду всякий раз, когда кто-то хоть чуть-чуть отклоняется от заданного процесса. Насмотрелся я на таких скрам-храм-трам-барам-мастеров! Обычно такие вырастают из неинженерных направлений (BA, QA, HR), а вчерашние инженеры наоборот часто тяготеют к таким вот lean-подходам, т.к. часто воспринимают задачи, связанные с управлением, как оверхед — необходимое зло, которое нужно свести к минимому. Истина, как всегда, где-то посередине и зависит от конкретного случая.
А еще я автора знаю, поэтому обижать не хочется, но если притвориться, что мы не знакомы (ага?), то я бы добавил:
Уважаемый, во-первых одно капитанство. Львиная доля написанного очевидна даже для тех, кто не то, чтобы проектами не управлял, а вообще не тимлидил ни разу. Много воды и статья ни о чем.
А во-вторых, схема методологий у вас совершенно нечитаемая. Какие-то круги-круги-круги. Ворох умных и не очень слов. Вот и создается впечатление, что и в голове у вас тоже ворох слов и понятий. Похожее впечатление возникает, когда резюме начитанного джуниора без опыта читаешь.
Попробуйте наоборот поступить — не показывайте «источники вдохновения», а покажите сами практики, которые вы переняли. Например, канбан славен тем, что ограничивает объем задач, находящихся в процессе. Если много задач находятся в стадии work-in-progress, то новую задачу начинать запрещено. У вас такой лимит есть? Если да — отображайте. Нет — выбрасывайте. Или, например, стендапы из скрама: есть они у вас — пишите, нет — не пишите. И в результате будут не круги, а список практик, соответствующий разным аспектам ведения проекта.
По списку практик уже можно сравнивать подходы в управлении. А то выходит такое, что один говорит:
— У нас скрам, поэтому мы делаем A!
А другой ему отвечает:
— И у нас скрам, именно поэтому мы A не делаем!
А вы сидите и думаете: «кому из них верить?»
Спасибо за столь длинный комментарий, статью написал, чтобы отзывы послушать. так что какие уж тут обиды? а вот по поводу знакомства… что-то не припоминаю я…
Согласен, что не надо цепляться за одну методологию. Когда команда работать начинала, вообще методологии небыло, так что-то кто-то слышал — применили… Очень помогли конференции, на которых можно пообщаться со знающими людьми, позадавать вопросы. Стараюсь приветствовать любые полезные нововведения от всех членов команды, ведь один я не могу охватить все новое, что всплывает в мире разработки ПО.
Может быть очевидна для тех, кто уже читал хоть что-то про методологии, согласен.
Извините, вспомнил универ, графики. Был вариант со списком под каждой из методологий, но он показался мне не красивым.
Согласен, что не надо цепляться за одну методологию. Когда команда работать начинала, вообще методологии небыло, так что-то кто-то слышал — применили… Очень помогли конференции, на которых можно пообщаться со знающими людьми, позадавать вопросы. Стараюсь приветствовать любые полезные нововведения от всех членов команды, ведь один я не могу охватить все новое, что всплывает в мире разработки ПО.
Львиная доля написанного очевидна даже для тех, кто не то, чтобы проектами не управлял, а вообще не тимлидил ни разу. Много воды и статья ни о чем
Может быть очевидна для тех, кто уже читал хоть что-то про методологии, согласен.
Какие-то круги-круги-круги
Извините, вспомнил универ, графики. Был вариант со списком под каждой из методологий, но он показался мне не красивым.
Порекомендуйте, какую литературу стоит почитать, чтобы ознакомиться с понятиями, используемыми в статье.
Это все потому что пиши-код-блять.рф/
Или как мне еще скидывали programming-motherfucker.com/
Да, это оно и есть
Вот кстати русское описание этой методологии factorized.tumblr.com/post/4180288873/programming-motherfucker
Вот кстати русское описание этой методологии factorized.tumblr.com/post/4180288873/programming-motherfucker
почитал — обзавидовался. У нас типа скрама и даже пытаемся выдержать побольше его практик, НО при этом тестировщиков нет, архитектора нет, тим и тех-лидов у бэкенда тоже нет. И вроде бы заказчик понимает, что архитектор и тестировщик нужны и даже менеджера тестировщиков наняли (сидеть рядом? Ха, да они вообще в другой стране будут), но уже много месяцев всё делают девелоперы. А в знак признательности (видимо) нас заставляют переписывать систему на Друпал, несмотря на негативное отношение всех разработчиков к этой идее.
есть примеры команд, их не много, но есть, в которых нет тестировщиков. В таких командах все покрывается TDD, BDD, ATDD, DDD и всякими другими ...DD (и придумали же)
Не стоит выдерживать все практики в скраме, если не получается, значит откажитесь от какой-то из практик. Есть еще понятие ScrumBat(или СкармНо по нашему). Это когда вы говорите, мы используем скрам, но не используем…, потому что… Можно почитать здесь scrumbat
Покажите заказчику Тест Джоэла: 12 шагов к лучшему коду может он проникнется и попытается создать вам все условия. Если заказчик заинтересован в улучшении процесса разработки, то шагов 10 (а может и 11) он вам постарается сделать, это не дорого и не очень сложно.
Не стоит выдерживать все практики в скраме, если не получается, значит откажитесь от какой-то из практик. Есть еще понятие ScrumBat(или СкармНо по нашему). Это когда вы говорите, мы используем скрам, но не используем…, потому что… Можно почитать здесь scrumbat
Покажите заказчику Тест Джоэла: 12 шагов к лучшему коду может он проникнется и попытается создать вам все условия. Если заказчик заинтересован в улучшении процесса разработки, то шагов 10 (а может и 11) он вам постарается сделать, это не дорого и не очень сложно.
спасибо за интересные ссылки. По тесту Джоэла у нас 5, но будет 4, т.к. нас переселят в другую комнату, к другому проекту. Однако над некоторыми пунктами мы работаем (2 и 3), но 10 — это нереально в нашем проекте, на мой взгляд.
Надо взять на вооружение идею про БД ошибок. Что-то такое витало в моих мыслях, но тут неплохо описано.
Надо взять на вооружение идею про БД ошибок. Что-то такое витало в моих мыслях, но тут неплохо описано.
Какую методологию посоветуете, если разработчик — «человек-оркестр»?
Так не от разработчика зависит, а от заказчика. Разработчик может быть и «человек-оркестр», а играть должен все равно по правилам заказчика. Заказчику в основном нужны релизы и как можно чаще, и чтоб по-больше новой функциональности было. Выбирая методологию разработки нужно смотреть на то, как вы работаете с заказчиком, если он любит, чтоб все сначала было спланированно, взвешенно, диаграмма нарисована, дизайн продуман, а потом только к коду приступать, то тут лучше водопадную модель использовать. Если заказчику все равно, то я бы за основу взял Scrum, т.к. здесь вы себя страхуете практически со всех сторон. Вы часто выпускаете релизы, заказчик может посмотреть на функциональность и внести изменения, когда еще не так много спроектированно и есть возможность легко что-то поменять. Плюс вы можете, на основании нескольких релизов, просчитать среднюю производительность команды и более точно спланировать следующий релиз. Еще у вас в Product backlog будет куча заданий с приоритетами и со Story Points, так что сможете распланировать на несколько релизов вперед.
Например, в нашем проекте, я не могу сказать, что использую Scrum, т.к. половина из него не прижилась, но за основу мы взяли Product BackLog, и внутренние релизы мы планируем сроком на 1-4 недели, заказчик же получает релиз раз в 2-3 месяца. Т.е. у нас получается такое понятие как спринт в спринте. Пробуйте из разных методологий выбрать то, что подходит для вашего проекта. Ведь все еще зависит от количества человек в команде, соотношения тестеров и программистов, сложности задач и др. факторов.
Например, в нашем проекте, я не могу сказать, что использую Scrum, т.к. половина из него не прижилась, но за основу мы взяли Product BackLog, и внутренние релизы мы планируем сроком на 1-4 недели, заказчик же получает релиз раз в 2-3 месяца. Т.е. у нас получается такое понятие как спринт в спринте. Пробуйте из разных методологий выбрать то, что подходит для вашего проекта. Ведь все еще зависит от количества человек в команде, соотношения тестеров и программистов, сложности задач и др. факторов.
Спасибо.
Так же советую вам сделать следующие вещи (тут наверняка накапитаню). Если у вас нет времени сделать их самому, попросите кого-то другого (закажите и заплатите, если никто просто так не берется). Вам нужно следующее:
1. Система контроля версий, разрешающая создание быстрых бранчей. Операции «создать бранч» и «слить бранч» должны быть мгновенными — это самое главное. Git или Hg вполне подойдут. Это важно, т.к. вам как человеку-оркестру очень важно в любой момент, не теряя времени, иметь возможность переключиться с задачи на задачу. Клиет позвонил, что-то попросил, вы тем временем работали над чем-то. Быстро создали бранч, стали работать над более приоритетной задачей. Сделали, показали мклиенту, он доволен, переключились в старый бранч, продолжили работать над предыдущей задачей. Без ожиданий, проволочек и проблем с мерджем. SVN, CVS, TFS так не умеют.
2. Настройте Continuous Integration. Каждый раз, когда коммитите изменения, должен прогоняться билд с тестами: что-то сломалось — вы об этом уже знаете. CI-сервер должен деплоить приложение. Например, заказчик попросил, что-то сделать, вы сделали и закоммитили, билд тут же прошел — вы можете показать сделанную работу заказчику.
3. Имейте кроме системы управления проектатми отдельный to-do-лист. Например, есть у вас с заказчиком в Гуглодоксах таблица с беклогом, таблица с багами, отдельные таблицы на каждую итерацию, мб бактреккер какой-то использовать будете — не важно! Все равно сделайте отдельный тудулист на день. С утра прежде чем начать работу, решите, что вы будете делать, в каком порядке и т.п. Для вас это будет заменой традиционного ежедневного стендапа. Да и в течение дня поможет вам оставаться сфокусированным. Обязательно ставьте отметки, когда вы завершили ту или иную задачу — будет чувствовать себя классным парнем, а в работе это очень важно. Вечером оставляйте список открытым, чтобы утром первым, что вы видели на экране, был ваш список. Он должен стать для вас основным рабочим инструментом наравне со средой разработки.
Вообще выше Андрей написал правильно — бейте итерацию на подитерации, задачи на подзадачи, этапы на подэтапы и т.п. Так легче оставаться в курсе того, с какой скоростью движется ваше дело, да и движется ли. Это — самое главное.
1. Система контроля версий, разрешающая создание быстрых бранчей. Операции «создать бранч» и «слить бранч» должны быть мгновенными — это самое главное. Git или Hg вполне подойдут. Это важно, т.к. вам как человеку-оркестру очень важно в любой момент, не теряя времени, иметь возможность переключиться с задачи на задачу. Клиет позвонил, что-то попросил, вы тем временем работали над чем-то. Быстро создали бранч, стали работать над более приоритетной задачей. Сделали, показали мклиенту, он доволен, переключились в старый бранч, продолжили работать над предыдущей задачей. Без ожиданий, проволочек и проблем с мерджем. SVN, CVS, TFS так не умеют.
2. Настройте Continuous Integration. Каждый раз, когда коммитите изменения, должен прогоняться билд с тестами: что-то сломалось — вы об этом уже знаете. CI-сервер должен деплоить приложение. Например, заказчик попросил, что-то сделать, вы сделали и закоммитили, билд тут же прошел — вы можете показать сделанную работу заказчику.
3. Имейте кроме системы управления проектатми отдельный to-do-лист. Например, есть у вас с заказчиком в Гуглодоксах таблица с беклогом, таблица с багами, отдельные таблицы на каждую итерацию, мб бактреккер какой-то использовать будете — не важно! Все равно сделайте отдельный тудулист на день. С утра прежде чем начать работу, решите, что вы будете делать, в каком порядке и т.п. Для вас это будет заменой традиционного ежедневного стендапа. Да и в течение дня поможет вам оставаться сфокусированным. Обязательно ставьте отметки, когда вы завершили ту или иную задачу — будет чувствовать себя классным парнем, а в работе это очень важно. Вечером оставляйте список открытым, чтобы утром первым, что вы видели на экране, был ваш список. Он должен стать для вас основным рабочим инструментом наравне со средой разработки.
Вообще выше Андрей написал правильно — бейте итерацию на подитерации, задачи на подзадачи, этапы на подэтапы и т.п. Так легче оставаться в курсе того, с какой скоростью движется ваше дело, да и движется ли. Это — самое главное.
если уж вы задумались о методологии, то можете посмотреть на Тест Джоэла: 12 шагов к лучшему коду и оценить каких шагов вам еще не хватает
Я не о методологии, я о процессе. Наплевать, скрам-не-скрам, аджайл-не-аджайл — есть базовые вещи, которые стоит делать, не зависимо от методологии. Я рассказал о том, что нужно по минимому человеку-оркестру — фрилансеру, например, — для организации собственной работы с удаленным заказчиком. Когда человек, с одной стороны, хочет организовать процесс, а с другой — не может позволить вкладывать в процесс слишком много времени.
Когда человек работает в одиночку, то какой ему прок от Joel-теста? Тестеров у него нет, спека при каждодневном и итеративном общении с заказчиком не очень-то и нужна, средства разработки у него тоже свои, а не «самы лучшие, какие только можно купить», ну и т.д.
Joel Test — это не панацея. Почитайте вопросы на сайтах StackExchange по соответствующему тегу, например. Большинство людей принимают его, но с оговорками.
Когда человек работает в одиночку, то какой ему прок от Joel-теста? Тестеров у него нет, спека при каждодневном и итеративном общении с заказчиком не очень-то и нужна, средства разработки у него тоже свои, а не «самы лучшие, какие только можно купить», ну и т.д.
Joel Test — это не панацея. Почитайте вопросы на сайтах StackExchange по соответствующему тегу, например. Большинство людей принимают его, но с оговорками.
вот про спеку не соглашусь. сколько уже было ситуаций типа "… а помните год назад я заказывал..." или "… я не то совсем имел ввиду, вы сделали не правильно.." И докажи потом, что ты прав. Иногда спасают письма в таких ситуациях, если, конечно, их никто не поудалял. Но лучше всего после обсуждения какой-то функциональности нарисовать пару скринов, хотябы в том же Paint, оформить в презентацию с комментариями и еще раз зааппрувить, а потом выложить на треккер, чтоб не потерялось. Спека — идеальный вариант вообще будет.
И то что не панацея, соглашусь, наверное, но все зависит от специфики проектов. Могу сказать только, что год назад без пары пунктов из теста Джоэла было все таки сложновато. И сидели в разных местах, например, и работали в openspace, где шумно было, и спек небыло и тестеров, и т.д… Пока пришел к выводу, что чем больше пунктов из этого теста есть, тем лучше. Хотя вот есть команды которые работают, например без тестеров вообще, можно послушать Николая Алименкова, например, он рассказывает про один такой случай, и вроде все у них в порядке.
человек спросил о методологии, думаю, чем больше он почитает о скраме, хр, 12-и шагах, тем проще ему будет к чему-то прийти.
И то что не панацея, соглашусь, наверное, но все зависит от специфики проектов. Могу сказать только, что год назад без пары пунктов из теста Джоэла было все таки сложновато. И сидели в разных местах, например, и работали в openspace, где шумно было, и спек небыло и тестеров, и т.д… Пока пришел к выводу, что чем больше пунктов из этого теста есть, тем лучше. Хотя вот есть команды которые работают, например без тестеров вообще, можно послушать Николая Алименкова, например, он рассказывает про один такой случай, и вроде все у них в порядке.
человек спросил о методологии, думаю, чем больше он почитает о скраме, хр, 12-и шагах, тем проще ему будет к чему-то прийти.
Как думаете, в какие сроки можно комфортно перевести группу разработчиков из 5 человек на Agile?
Сейчас в работе не используется ничего, кроме mercurial. Задачи формулируются устно каждому разработчику отдельно от 3-ёх человек, иногда задачи пересекаются.
Сейчас в работе не используется ничего, кроме mercurial. Задачи формулируются устно каждому разработчику отдельно от 3-ёх человек, иногда задачи пересекаются.
Наш переход происходил в несколько этапов. Сначала мы добавили ведение спецификаций. Спецификации приживались у нас месяца 2, потом это вошло в норму. Далее мы начали играться с длиной релизов, выпускали сначала два раза в неделю, раз в неделю, раз в две недели, раз в месяц, раз в два месяца, раз в три месяца… Определили, что раз в 3-4 недели таки оптимальный вариант, где все довольны: клиент с релизом без ошибок, команда в конце релиза бодрячком. Ввели standup митинги два раза в неделю. Потом ввели Product Backlog поигрались с важностью и Story Points… и… убрали их через два релиза. Потом добавили ретроспективу, которая стала проводиться раза два в неделю с фразами «А давайте ка сделаем/улучшим/поменяем/добавим… ». В общем можно сказать, что уложились мы где-то в пол года, когда уже наигрались с длинами спринта. И это был наш первый опыт перехода на Agile. Для перехода мне хватило прочитать эту книгу
Хенрик Книберг. Scum и XP: заметки с передовой как мы делаем Scrum.
и сходить на парочку конференций, чтобы задать вопросы.
Хенрик Книберг. Scum и XP: заметки с передовой как мы делаем Scrum.
и сходить на парочку конференций, чтобы задать вопросы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методология Разработки ПО