Comments 68
Как-то все очень идеально звучит.
Вы хотите сказать, что весь процесс проектирования происходит на доске и только? Этого достаточно что бы писать качественный код и не ловить на тестах кучу багов?
З.Ы. Ваша доска итераций и задач напоминает мне Jira+GreenHopper… ;)
Вы хотите сказать, что весь процесс проектирования происходит на доске и только? Этого достаточно что бы писать качественный код и не ловить на тестах кучу багов?
З.Ы. Ваша доска итераций и задач напоминает мне Jira+GreenHopper… ;)
В основном — да, на доске.
Если функциональность немного более серьёзная, аналитик продумает всё заранее, но в итоге, опять-таки, «задокументирует» это на доске. В случае если решение сложное или черезчур оригинальное, фото доски выкладывается на корпоративную вики…
Качественный код достигается благодаря способным программистам :) и постоянному спариванию. Каждый принимает ответственность за свой кусок, и старается его сделать как можно лучше. Временами оказывается, что не всё было учтено, и приходится делать рефакторинг в середине итерации. При спаривании такой рефакторинг сложнее смести под ковёр.
Jira+GreenHopper звучат знакомо. У нас все процессы планования малотехнологичны :)
Если функциональность немного более серьёзная, аналитик продумает всё заранее, но в итоге, опять-таки, «задокументирует» это на доске. В случае если решение сложное или черезчур оригинальное, фото доски выкладывается на корпоративную вики…
Качественный код достигается благодаря способным программистам :) и постоянному спариванию. Каждый принимает ответственность за свой кусок, и старается его сделать как можно лучше. Временами оказывается, что не всё было учтено, и приходится делать рефакторинг в середине итерации. При спаривании такой рефакторинг сложнее смести под ковёр.
Jira+GreenHopper звучат знакомо. У нас все процессы планования малотехнологичны :)
>>Качественный код достигается благодаря способным программистам :) и постоянному спариванию.
— также постоянное спаривание благоприятствует рождению новых пограммистов :)
— также постоянное спаривание благоприятствует рождению новых пограммистов :)
А что ещё есть в вашей вики? :)
Некоторые советы по программированию, инструкции установки используемых программ, объяснения как делать релис, немного инфе по системе…
Так же там хранилище финансовых процессов и требований регурирующей организации…
Так же там хранилище финансовых процессов и требований регурирующей организации…
В принципе, очень классно что экономится куча времени, которое иначе тратится на создание всяких описаний архитектуры и т.д., жаль что не во всех организациях применим такой подход (нарисовал — сфоткал). Насколько я понимаю, архитектура не описывается целиком и описание не обновляется, люди сами помнят или могут поднять забытое из тестов и вики. Я так понимаю что всё вами описанное работает где-то около 3 лет… Или больше?
Жестких правил по обновлению ресурсов нету. Если инженер чувствует, что изменение важно и\или сложно, он обновит вики.
Система работает чуть более года, а разработка длилась около 3х лет.
Система работает чуть более года, а разработка длилась около 3х лет.
Есть такой тренд: поддерживать up to date как можно более полное описание архитектуры, что вроде как должно дать меньшую зависимость от ключевых людей и большие возможности всех остальных иметь доступ к информации. Реально же почти всегда проекты делаются командой без особых описаний, на драйве и слаженной работе, но поддерживать этот продукт другим людям, когда все «отцы-основатели» ушли потому что у них появился новый вызов, почти невозможно. Так вот где компромис? Ваша версия, если не лень, конечно. :)
P.S. Спрашиваю потому что мне кажется, что даже используемый вами подход может дать сбой, если люди начнут остывать к общему делу и расходиться.
P.S. Спрашиваю потому что мне кажется, что даже используемый вами подход может дать сбой, если люди начнут остывать к общему делу и расходиться.
>вроде как должно дать меньшую зависимость от ключевых людей и большие возможности всех остальных иметь доступ к информации.
В том-то и дело, что «ключевых» людей не должно быть. Практически все решения производятся группой, а над сложными частями системы к концу реализации поработают практически все, прощупав и почувствовав каждый аспект — конечно, благодаря «спариванию» и ротации.
Офис организован так, что спонтанные сессии архитектурного дизайна всегда проходят в самом «гнезде» инженеров, на проходе, соединяющем все важные органы офиса (как митинг-румы, кухню, выход, туалет). У нас все инженеры — народ любопытный, и любит вставить свои три копейки — поэтому как только учуют интерес, присоединятся.
Такое «сования носа» у нас очень поощряется, и никто никогда не скажет, мол, иди работай, хватит подслушивать.
>когда все «отцы-основатели» ушли потому что у них появился новый вызов
Может прозвучать самоуверенно, но у нас мало народу уходит. Платят неплохо, процесс отличный, область — лучше не придумашь. Технологии передовые. Люди — приятейшие. Много пьют :) Большинство коллег пишут технические блоги, хорошо оцененные в сообществе. Одна девушка-программист ушла… и через 3 месяца вернулась!
В том-то и дело, что «ключевых» людей не должно быть. Практически все решения производятся группой, а над сложными частями системы к концу реализации поработают практически все, прощупав и почувствовав каждый аспект — конечно, благодаря «спариванию» и ротации.
Офис организован так, что спонтанные сессии архитектурного дизайна всегда проходят в самом «гнезде» инженеров, на проходе, соединяющем все важные органы офиса (как митинг-румы, кухню, выход, туалет). У нас все инженеры — народ любопытный, и любит вставить свои три копейки — поэтому как только учуют интерес, присоединятся.
Такое «сования носа» у нас очень поощряется, и никто никогда не скажет, мол, иди работай, хватит подслушивать.
>когда все «отцы-основатели» ушли потому что у них появился новый вызов
Может прозвучать самоуверенно, но у нас мало народу уходит. Платят неплохо, процесс отличный, область — лучше не придумашь. Технологии передовые. Люди — приятейшие. Много пьют :) Большинство коллег пишут технические блоги, хорошо оцененные в сообществе. Одна девушка-программист ушла… и через 3 месяца вернулась!
Можно к вам уборщиком?:)
Организация процесса правда впечатляет. На самом деле. Спасибо вам за рассказ и ответы на вопросы, они дали пищу для размышлений.
Я понимаю что у меня не получается точно спросить что хочу узнать. Потому что это вопрос из другой категории и напрямую к рабочему процессу, вроде как, отношения не имеющий. Я задал его как вопрос про новые вызовы, но то, о чём я на самом деле хотел спросить — шире.
Смотрите, трейдинг сейчас это совсем не то же самое, что трейдинг 10 лет назад. Даже совсем не то же самое что 5 лет назад. Это к тому что если сейчас ваш продукт это cutting edge всего что есть в трейдинге сейчас, то через 5 лет могут случиться две вещи сразу: спрос на те виды операций, которые ваш продукт может обрабатывать, не изменится, но появится 100500 новых инструментов, которые и будут новым cutting edge. Люди станут старше (кстати, интересно каков средний возраст сейчас) и их сфера интересов почти неизбежно сместится в сторону семьи. Заметьте, а продукт всё ещё востребован и не меньше чем раньше, а время идёт: 5, 10, 15 лет.
Я сейчас работаю с людьми, которые строили похожий cutting edge в 80-х, на коболе и мейнфреймах. В какой-то момент произошло насыщение рынка и стех пор нет большего спроса на их продукт, но нет и меньшего, но есть ворох новых требований, которые надо внедрять. Но к чему я веду, к тому что их знание более никому не передаётся и система будет жить пока они не уйдут на пенсию. При этом они — отличная команда, у них классно всё налажено, но они создали такую степень устойчивости процесса, что у них не было необходимости искать что-то на стороне. И ни смотря на то, что они постоянно развивались, они совершенно выпали из мейнстрима и сейчас они — последние из могикан. И насколько я могу судить, такая изоляция от мира присуща любой команде и чем лучше процессы в команде и чем глубже знание технологии, тем сложнее им развиваться и пробовать новое. Может не поначалу (первые 5-10 лет), но дальше.
Надеюсь, мне удалось донести мысль не слишком путано.
Я понимаю что у меня не получается точно спросить что хочу узнать. Потому что это вопрос из другой категории и напрямую к рабочему процессу, вроде как, отношения не имеющий. Я задал его как вопрос про новые вызовы, но то, о чём я на самом деле хотел спросить — шире.
Смотрите, трейдинг сейчас это совсем не то же самое, что трейдинг 10 лет назад. Даже совсем не то же самое что 5 лет назад. Это к тому что если сейчас ваш продукт это cutting edge всего что есть в трейдинге сейчас, то через 5 лет могут случиться две вещи сразу: спрос на те виды операций, которые ваш продукт может обрабатывать, не изменится, но появится 100500 новых инструментов, которые и будут новым cutting edge. Люди станут старше (кстати, интересно каков средний возраст сейчас) и их сфера интересов почти неизбежно сместится в сторону семьи. Заметьте, а продукт всё ещё востребован и не меньше чем раньше, а время идёт: 5, 10, 15 лет.
Я сейчас работаю с людьми, которые строили похожий cutting edge в 80-х, на коболе и мейнфреймах. В какой-то момент произошло насыщение рынка и стех пор нет большего спроса на их продукт, но нет и меньшего, но есть ворох новых требований, которые надо внедрять. Но к чему я веду, к тому что их знание более никому не передаётся и система будет жить пока они не уйдут на пенсию. При этом они — отличная команда, у них классно всё налажено, но они создали такую степень устойчивости процесса, что у них не было необходимости искать что-то на стороне. И ни смотря на то, что они постоянно развивались, они совершенно выпали из мейнстрима и сейчас они — последние из могикан. И насколько я могу судить, такая изоляция от мира присуща любой команде и чем лучше процессы в команде и чем глубже знание технологии, тем сложнее им развиваться и пробовать новое. Может не поначалу (первые 5-10 лет), но дальше.
Надеюсь, мне удалось донести мысль не слишком путано.
Наша система разработана на Java, с использованием других новых компонентов для интеграции (мы получили какую-то награду за интеграцию с системой Informatica). Недавно мы перешли на новую версию Java, и так как этот язык, вроде, умирать пока не собирается, судьба мейнфреймов нам пока не грозит. Вообще, когда выходит новая версия чего-либо, мы её внедряем и остаёмся cutting edge :)
Люди у нас приходят и уходят, команда растёт и меняется. В этом году ушло 2-3 человека, пришло 4-5 — процесс и знания распространяются.
Если появятся новые инструменты, или какие-то прочие требования — мы их добавим. На то мы и agile. В этом году, например, мы удвоили колличество тогровых пар форекса.
Возраст инженеров у нас разнообразный. Есть совсем молодые (лет 25), много 40-летних, несколько постарше. Дети почти у всех есть…
Да, система всё равно не вечна, как и всё остальное. Ничего, построим новую, где-то в другом месте.
Люди у нас приходят и уходят, команда растёт и меняется. В этом году ушло 2-3 человека, пришло 4-5 — процесс и знания распространяются.
Если появятся новые инструменты, или какие-то прочие требования — мы их добавим. На то мы и agile. В этом году, например, мы удвоили колличество тогровых пар форекса.
Возраст инженеров у нас разнообразный. Есть совсем молодые (лет 25), много 40-летних, несколько постарше. Дети почти у всех есть…
Да, система всё равно не вечна, как и всё остальное. Ничего, построим новую, где-то в другом месте.
А как у вас происходит процесс принятия решения при разделении мнений сторон?
Скопиирую с другого ответа:
Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.
Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.
Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.
Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.
а аудит систем вы как проходите без документации внесенных изменений?
«и начинают встречу с поедания торта» А заканчивают в тренажерке?
Всё настолько любопытно, что хочется задать кучу вопросов:
Правильно ли я понимаю, что аналитики полностью разбираются в предметной области?
Проходят ли какую-то предварительную фильтрацию требования от кастомеров, прежде чем появиться на доске планирования?
Каким образом производится включение новых сотрудников в команду?
Заранее спасибо :)
Правильно ли я понимаю, что аналитики полностью разбираются в предметной области?
Проходят ли какую-то предварительную фильтрацию требования от кастомеров, прежде чем появиться на доске планирования?
Каким образом производится включение новых сотрудников в команду?
Заранее спасибо :)
Да, аналитики отлично разбираются в предметной области, а так же неплохо — в коде.
Требования от клиентов фильтруются сначала просто продажами-маркетингом (если мы это сделаем, кто ещё извлечёт от этого выгоду? Стоит ли игра свеч? Совпадает ли это с нашим направлением?), а позже — всеми остальными. У нас нет барьеров — и если инженер, проходя мимо беклога, или, после встречи планирования, решает, что требование бессмысленно, или трудновыполнимо, его мнение обсуждается и учитывается.
Новых сотрудников сначала обучают системе — один из опытных программистов проводит с ним полдня, рисуя на доске архитектуру системы и поясняя решения. Потом он начинает «париться» наравне с остальными — начиная задачами попроще.
Ещё у нас серьёзный испытательный срок — бывает, человек не приживается.
Требования от клиентов фильтруются сначала просто продажами-маркетингом (если мы это сделаем, кто ещё извлечёт от этого выгоду? Стоит ли игра свеч? Совпадает ли это с нашим направлением?), а позже — всеми остальными. У нас нет барьеров — и если инженер, проходя мимо беклога, или, после встречи планирования, решает, что требование бессмысленно, или трудновыполнимо, его мнение обсуждается и учитывается.
Новых сотрудников сначала обучают системе — один из опытных программистов проводит с ним полдня, рисуя на доске архитектуру системы и поясняя решения. Потом он начинает «париться» наравне с остальными — начиная задачами попроще.
Ещё у нас серьёзный испытательный срок — бывает, человек не приживается.
Спасибо за рассказ, очень интересно!
И тоже хочется задать несколько вопросов.
1. Не бывает ли такого, что при внесении изменения возникает вопрос «Почему это было сделано именно так? Кто это просил? Кто и почему это так запрограммировал?». И никто из текущих людей этого не помнит (допустим, было написано давно, несколько лет назад). Как решаете такое?
2. Сколько в среднем разработчик и аналитик работает на этом проекте?
3. Как решаете архитектурные вопросы, если у людей в команде существенно разные мнения и нет формального архитектора? Есть неформальный? Или как-то все-таки быстро договариваетесь?
4. Сколько строк кода в итоге есть в системе и на каком языке? Сколько из них — тесты?
5. Сколько времени проходит от прихода в проект нового человека до его полноценного погружения? Ну, хоть примерно? Сколько времени длится испытательный срок?
6. Есть ли в системе СУБД и как от нее экранируетесь для тестирования? Как тестируется само взаимодействие с БД и ее структуры?
И тоже хочется задать несколько вопросов.
1. Не бывает ли такого, что при внесении изменения возникает вопрос «Почему это было сделано именно так? Кто это просил? Кто и почему это так запрограммировал?». И никто из текущих людей этого не помнит (допустим, было написано давно, несколько лет назад). Как решаете такое?
2. Сколько в среднем разработчик и аналитик работает на этом проекте?
3. Как решаете архитектурные вопросы, если у людей в команде существенно разные мнения и нет формального архитектора? Есть неформальный? Или как-то все-таки быстро договариваетесь?
4. Сколько строк кода в итоге есть в системе и на каком языке? Сколько из них — тесты?
5. Сколько времени проходит от прихода в проект нового человека до его полноценного погружения? Ну, хоть примерно? Сколько времени длится испытательный срок?
6. Есть ли в системе СУБД и как от нее экранируетесь для тестирования? Как тестируется само взаимодействие с БД и ее структуры?
1. Обычно такого не бывает, потому что 4-5 человек всегда участвовали в разработке, и ещё 3-4 слышали краем уха. Иногда случается, что забывается, как оно было сделано, но и тут есть решения — первое — почитать тесты, второе — покопать код. Так как эти действия тоже совершаются парно, скоро память восстанавливается :)
2. Не совсем поняла вопроса. Вместе мы обычно работаем вначале каждой истории, при написании тестов. Аналитики и программисты сидят рядом, а из-за того, что программеры парятся, даже если аналитик не в паре, он слышит все обсуждения и при надобности, вставляет свои 5 копеек, лезет в код или начитает что-то объяснять.
3. Архитектора нет, ни формального, ни неформального. Некоторые немного лучше разбираются в некоторых вопросах, чем другие. Нередко возникают горячие дискуссии, идём спрашивать у клиента, привлекаем кого-то их другой команды, но в итоге приходим к решению.
4. Ой… пишем на Java… (ушла строки считать)
5. До погружения, конечно, зависит от способностей. 3 недели назад присоединился новые инжинер, уже в полном порядке и с кучей отлчных идей. Испытательный срок длится 3 месяца.
6. База есть, но очень простая — в основном для аудита и прочих логов. Практически все операции происходят в памяти. Для тестирования у нас разработана спецальная библиотека, и при надобности она делает запросы в БД. Я тольком не знаю, как она работает — если когда разберусь, напишу отдельно.
ПС. Строк около 1 000 500, из них тестов около 133 000.
2. Не совсем поняла вопроса. Вместе мы обычно работаем вначале каждой истории, при написании тестов. Аналитики и программисты сидят рядом, а из-за того, что программеры парятся, даже если аналитик не в паре, он слышит все обсуждения и при надобности, вставляет свои 5 копеек, лезет в код или начитает что-то объяснять.
3. Архитектора нет, ни формального, ни неформального. Некоторые немного лучше разбираются в некоторых вопросах, чем другие. Нередко возникают горячие дискуссии, идём спрашивать у клиента, привлекаем кого-то их другой команды, но в итоге приходим к решению.
4. Ой… пишем на Java… (ушла строки считать)
5. До погружения, конечно, зависит от способностей. 3 недели назад присоединился новые инжинер, уже в полном порядке и с кучей отлчных идей. Испытательный срок длится 3 месяца.
6. База есть, но очень простая — в основном для аудита и прочих логов. Практически все операции происходят в памяти. Для тестирования у нас разработана спецальная библиотека, и при надобности она делает запросы в БД. Я тольком не знаю, как она работает — если когда разберусь, напишу отдельно.
ПС. Строк около 1 000 500, из них тестов около 133 000.
> 2. Сколько в среднем разработчик и аналитик работает на этом проекте?
Я имел в виду, есть ли уже какая-то статистика сколько времени человек работает до увольнения? Или пока только нанимаете?
Я имел в виду, есть ли уже какая-то статистика сколько времени человек работает до увольнения? Или пока только нанимаете?
Хм… Удивительно мало тестов, на мой взгляд. И это — при отсутствии другой документации.
На что похожи эти тесты? Или есть несколько категорий тестов? Модульные? Приемочные?
На что похожи эти тесты? Или есть несколько категорий тестов? Модульные? Приемочные?
Ой, еще вопросы созрели!
* А чем у вас занимаются тестеры, если разработка начинается с написания автотестов?
* А кто у вас занимается сопровождением эксплуатируемой системы? У нее же есть пользователи и есть проблемы и непонятки, которые нужно оперативно решать, в т.ч. с привлечением разработчиков? Как это происходит?
* В ситуации, когда есть несколько важных вещей, которые нужно сделать, но все сделать не успеваете — КТО решает, куда бросить ресурсы?
* Какие проблемы известны в проекте? :) Технические и организационные? Ведь без проблем не бывает.
* А чем у вас занимаются тестеры, если разработка начинается с написания автотестов?
* А кто у вас занимается сопровождением эксплуатируемой системы? У нее же есть пользователи и есть проблемы и непонятки, которые нужно оперативно решать, в т.ч. с привлечением разработчиков? Как это происходит?
* В ситуации, когда есть несколько важных вещей, которые нужно сделать, но все сделать не успеваете — КТО решает, куда бросить ресурсы?
* Какие проблемы известны в проекте? :) Технические и организационные? Ведь без проблем не бывает.
1) Пишут автотесты, придумывают, что ещё потестировать, проводят ручное тестирование — к сожалению, не всё можно автоматизировать. По-моему, у нас тестерам интересно работать — обычно это скучно и однообразно.
2) Одна из команд всегда «на дежурстве», и выполняет это сопровождение. Когда всё работает, они придумывают, как улучшить процесс — например, какие новые способы предотвращения неполадок, новые отчёты и пр.
3) Да, бывает. В зависимости от сложности — если мелочь, то программисты и аналитик решат, что хрен с ним. Бывает, доходит до ген. директора, но чаще всего бизнес решает (те, кто и запросили изменения)
4) Проблемы тоже случаются. Организационные реже — хотя вот в прошлой итерации моя команда что-то разучилась говорить «нет», в итоге потратили 2 дня на весьма бесполезный css. Технические — как у всех, думаю. То сервак заглючит, то лицензия не вовремя закончится, то просто окажется, что не совсем правильно спроектировано. Ничего особенного :)
2) Одна из команд всегда «на дежурстве», и выполняет это сопровождение. Когда всё работает, они придумывают, как улучшить процесс — например, какие новые способы предотвращения неполадок, новые отчёты и пр.
3) Да, бывает. В зависимости от сложности — если мелочь, то программисты и аналитик решат, что хрен с ним. Бывает, доходит до ген. директора, но чаще всего бизнес решает (те, кто и запросили изменения)
4) Проблемы тоже случаются. Организационные реже — хотя вот в прошлой итерации моя команда что-то разучилась говорить «нет», в итоге потратили 2 дня на весьма бесполезный css. Технические — как у всех, думаю. То сервак заглючит, то лицензия не вовремя закончится, то просто окажется, что не совсем правильно спроектировано. Ничего особенного :)
Орфографию поправьте, пожалуйста.
Не хватает расшифровки терминов:
«канбан»
«комит»
«SVN»
И не понятно, почему постоянная ротация обеспечивает хороший результат и так ли это на самом деле. Вообще не вижу в этом смысла. Свежий взгляд конечно хорош, но уходит время на разбор чужого кода и новой задачи. Зачем?
>«В проекте нету и не было ни одного руководителя проекта, координатора, планов проекта, диаграмм Гантта, >документов архитектуры, спецификаций требований, и планов тестирования.»
А разве все эти доски не являются планами проекта, тестировнаия и диаграммой Ганта?
Так же как и белая доска с маркером заменяет документы архитектуры и спецификации требований.
Разница в том, что документ согласовывается и утвреждается для определённости. А как здесь происходит отсев левых изменений — не ясно. Подошёл участник к доски, внёс рац предложение, а если оно не «рац», а как раз наоборот — кто решает принимать его или нет? А если сталкиваются два противоположных предложения — кто решает какое оставить?
«канбан»
«комит»
«SVN»
И не понятно, почему постоянная ротация обеспечивает хороший результат и так ли это на самом деле. Вообще не вижу в этом смысла. Свежий взгляд конечно хорош, но уходит время на разбор чужого кода и новой задачи. Зачем?
>«В проекте нету и не было ни одного руководителя проекта, координатора, планов проекта, диаграмм Гантта, >документов архитектуры, спецификаций требований, и планов тестирования.»
А разве все эти доски не являются планами проекта, тестировнаия и диаграммой Ганта?
Так же как и белая доска с маркером заменяет документы архитектуры и спецификации требований.
Разница в том, что документ согласовывается и утвреждается для определённости. А как здесь происходит отсев левых изменений — не ясно. Подошёл участник к доски, внёс рац предложение, а если оно не «рац», а как раз наоборот — кто решает принимать его или нет? А если сталкиваются два противоположных предложения — кто решает какое оставить?
Статья явно для людей, связанных с программированием, и интересующихся разработкой сложных проектов. Описывать работу с системами управления версиями, на мой взгляд, излишне для такой аудитории.
Ганта рассчитывают до исполнения на основе трудоёмкости операций, определяя последовательно выполнения операций и время работы. В Agile, насколько я понимаю, спланировать весь проект невозможно, разработка идет от итерации до итерации, а внутри итерации операции выполняются исходя из приоритетов разработчиков.
Ганта рассчитывают до исполнения на основе трудоёмкости операций, определяя последовательно выполнения операций и время работы. В Agile, насколько я понимаю, спланировать весь проект невозможно, разработка идет от итерации до итерации, а внутри итерации операции выполняются исходя из приоритетов разработчиков.
Канбан — японская система организации производства. Основное отличие — малое колличество параллельных задач. В данном случае имеется ввиду стена типо вот этой — technitai.files.wordpress.com/2011/04/simple-kanban-board.png
SVN (subversion) — система контроля версий, где каждая новая версия получает свой номер, и всегда можно вернуть любую из прошлых версий.
Комит (commit) — внесение новой версии в систему SVN.
Ротация полезна свежим взглядом, и это отличный инструмент для обучения. Кроме того, автоматом получается аудит кода, и вносятся изменения.
Про Ганта отличный ответ от Goder.
Документы архитектуры имеют смысл в основном до её реализации. На их написание уходит невероятное колличество времени, и куча ревизий. А в результате всё равно может получиться нечто, неудовлетворяющее требования.
Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.
Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.
SVN (subversion) — система контроля версий, где каждая новая версия получает свой номер, и всегда можно вернуть любую из прошлых версий.
Комит (commit) — внесение новой версии в систему SVN.
Ротация полезна свежим взглядом, и это отличный инструмент для обучения. Кроме того, автоматом получается аудит кода, и вносятся изменения.
Про Ганта отличный ответ от Goder.
Документы архитектуры имеют смысл в основном до её реализации. На их написание уходит невероятное колличество времени, и куча ревизий. А в результате всё равно может получиться нечто, неудовлетворяющее требования.
Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.
Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.
Про документы архитектуры можно 5 копеек? К тому же после воплощения системы в коде, в документах почти всегда найдётся что поправить, но бюджета на это уже, как правило, нет и документ остаётся таким как был до создания системы. Можно сказать, что это из-за кривых рук составителей документов, что в очень общем по своей сути документе были слишком конкретные детали, но это будет лишь половиной правды, потому что заказчик часто грешит детализацией там, где она не нужна ему самому.
Судя по тому, что народ на великах добирается — разработка не в Москве?
Блин, так вот, что такое agile и kanban :) Оказывается, мы этих два страшных слова тоже у себя применяем :)
> В разработке тоже происходит постоянная ротация – пары сходятся и расходятся, меняются заданиями. В результате все знают всё, и нужда в отдельных ревью кода исчезает.
Мне кажется, не могут люди знать все о такой крупной системе, как не делай ротацию. Но все познается в сравнении: был опыт работы без «насильственной» ротации разработчиков? Интересно сравнить фокус-фактор или другие количественные характеристики спринта в том и другом случае.
P.S. А требования+условия работы в вашей компании, как узнать?
Мне кажется, не могут люди знать все о такой крупной системе, как не делай ротацию. Но все познается в сравнении: был опыт работы без «насильственной» ротации разработчиков? Интересно сравнить фокус-фактор или другие количественные характеристики спринта в том и другом случае.
P.S. А требования+условия работы в вашей компании, как узнать?
Всё люди не будут знать, но будут знать, куда смотреть. А в паре — и то проще.
Ротация у нас не «насильственная» — если кто-то считает это плохой практикой, в Лондоне куча работ. Обычно инженеры очень рады работать с ротацией. Бывает, что конкретный программист хочет закончить задание в данной паре — это всегда пожалуйста.
Фокус-фактор и прочие характеристики мы не практикуем.
Требования — посмотрите на сайте LMAX.
Ротация у нас не «насильственная» — если кто-то считает это плохой практикой, в Лондоне куча работ. Обычно инженеры очень рады работать с ротацией. Бывает, что конкретный программист хочет закончить задание в данной паре — это всегда пожалуйста.
Фокус-фактор и прочие характеристики мы не практикуем.
Требования — посмотрите на сайте LMAX.
не прочел все комменты :) я прям переживаю за вашего проектного менеджера или так сказать за звено между разработчиками и инвесторами, то есть кто понимаю и те кто не понимают…
Не ужели не одна из стороне понимают что документация, как и библия, написано для того чтобы помнили, и боялись :)
Я рву на себе волосы просто!!!
Не ужели не одна из стороне понимают что документация, как и библия, написано для того чтобы помнили, и боялись :)
Я рву на себе волосы просто!!!
У нас нет тех, кто «не понимает». Бывает, не знаешь чего-то — идёшь и спрашиваешь. Всё просто.
«Чтобы боялись» — это не наш метод.
«Чтобы боялись» — это не наш метод.
хотите сказать от инвестора до самого программиста знает все от A до Z ?? ))
Инвесторы — это частные люди, их мы лично не знаем. Счёт открыть может кто угодно, это онлайн-сервис.
А так, бизнес очень неплохо понимает, что к чему. Конечно, кодить они не смогут, но знают ограничения.
А так, бизнес очень неплохо понимает, что к чему. Конечно, кодить они не смогут, но знают ограничения.
Хорошо что бизнес уже построен и имеются прибыли и это минимизируется риски, но мне было интересно, когда команда еще собиралось и не окупаемости, разве тогда не было контроля документации??
Ведь не было еще 100% уверенности во всей команде? на любом этапе могло произойти полная смена команды разве не так?
Ведь не было еще 100% уверенности во всей команде? на любом этапе могло произойти полная смена команды разве не так?
А у вас изначально с самого нуля разработка шла по agile или эту медодику вы уже внедрили на сопровождении?
Да, с нуля. У нас в офисе есть стена, на которой приклеены все законченные карточки. Впечатляет.
а как в таком случае «бизнес» (руководство) определял в самом начале (когда вообще ещё ничего не было), что продукт должен быть выпущен такого-то числа с таким-то стартовым функционалом?
а как в таком случае «бизнес» (руководство) определял в самом начале (когда вообще ещё ничего не было), что продукт должен быть выпущен такого-то числа с таким-то стартовым функционалом?
Это как раз самое нормальное программирование… Но пока не все понимают :)
Это как раз нормальное программирование… Но пока не все это понимают :)
можете написать про ваш технический парк серверов, сколько и какое там железо =)
Русских у вас много или Вы одна такая? :) Или как вообще распределение по народностям, все англичане кроме Вас или все разные?
Есть несколько русских, но в технологии я одна.
В основном в технологии у нас англоговорящие иммигранты — американцы, австралийцы, новозландцы. Англичан, думаю, четверть, или даже треть. По одному человеку есть из разных стран — Румыния, Турция, Испания, Израиль. Разношёрстно.
В технологии все белые, это необычно для ай-ти в Лондоне.
В основном в технологии у нас англоговорящие иммигранты — американцы, австралийцы, новозландцы. Англичан, думаю, четверть, или даже треть. По одному человеку есть из разных стран — Румыния, Турция, Испания, Израиль. Разношёрстно.
В технологии все белые, это необычно для ай-ти в Лондоне.
Тащемта, 20 толковых инженеров отлично будут работать в любом более-менее адекватном процессе. Цените своих людей, рад за вас.
Sign up to leave a comment.
Ненормальный Agile в финансах