Как повысить качество разработки своих проектов под 1С?

11.03.13

Управление проектом

Здравствуйте уважаемые коллеги. Мы – небольшое франчайзи (4 человека), которое занимается разработкой под 1С вот уже более 2х лет. После первого года работы возникли некоторые проблемы с качеством кода, поскольку начался стремительный  рост сложности проектов и, соответственно, начало появляться большое количество неприятных ошибок. В статье я постараюсь рассказать о тех мерах, которые мы приняли для повышения производительности труда программиста и качества написанного им кода. Кому интересно прошу под кат.

Первое, с чем необходимо было разобраться – учет и планирование рабочего времени. Заказчики и начальство постоянно заявляли о затягивании сроков по разработке, часто подымались вопросы о том, что программисты ничем не занимаются вовсе. Одним словом, ситуация сложилась более чем критической.

Контроль времени программиста

Тем не менее, team leader принял решение о переводе разработки на Scrum/Agile, что, как выяснилось через некоторое время, принесло свои результаты. Вот список изменений, которые были внесены в процесс разработки:

  1. Спринты наше все. В буквальном смысле все. Все время разработки разделено на равномерные отрезки, которые в нашем случае длятся две недели – наиболее удобный для нас промежуток времени. Время спринта может коррелироваться в соответствии со сложностью и объемом исполняемого проекта. Но в последнее время длительность спринта так и не удавалось сократить на срок менее двух недель. От себя могу добавить, что методика разбиения времени разработчиков на спринты очень удобна и программистам и начальству, поскольку первые получают определенный список задач, ТЗ которых не изменяется на протяжении спринта, а вторые видят определенный результат после окончания итерации разработки.
  2. Среди разработчиков был назначен Scrum Master – один из разработчиков, на широкие плечи которого был возложен тяжелый груз общения из заказчиком, а также проведения ежедневных Daily Scrum Meeting. Теперь мы смогли более сконцентрироваться на разработке, а не на выяснении отношений со свирепыми пользователями, объясняя им, почему мы не будем решать ту или иную задачу здесь и сейчас.
  3. Daily Scrum Meeting – очень полезные штуки. Всего за 10 минут рабочего времени каждому нужно рассказать о том, что он сделал вчера, что получилось, а что не получилось и что он будет делать сегодня. В результате у сотрудников возросла мотивация, процесс разработки стал более интересный и качественный, поскольку можно оперативно получить помощь или критику (обоснованную) от более продвинутых коллег. Митинги проводим даже в том случае, когда один из разработчиков опоздал или в командировке (используем Skype в качестве скринкастера или звонилки). Буквально за первую неделю практики Daily Meeting наш коллектив стал более дружественный и сплоченный.
  4. Следующий пункт – разделение задач по категориям. В каждом проекте наши задачи делятся на категории.
    • Идеи. В эту категорию попадают задачи-хотелки пользователей, у которых нету ТЗ и которые мы возможно даже не будем делать(из-за абсурдности самой задачи, или присутствием в той или иной конфигурации стандартного функционала, решающего проблему).
    • Кандидаты на реализацию. Задачи, которые точно будут реализованы, но не имеют точно сформулированного ТЗ.
    • Необходимо обсудить. Задачи, которые возможно будут реализованы, но хотелка пользователя непонятна для разработчика.
    • Технические истории. В этот раздел попадают задачи программистов для программистов, задачи – результат выполнения которых не будет виден конечному пользователю (библиотека, оптимизация запроса).
    • Product Backlog. Собственно задачи с четким ТЗ, которые  точно нужно выполнить или коммерческие задачи, за которые хорошо платят.
  5. Каждая задача оценивается в story points (в количестве дней, которые разработчик потратит на выполнении задачи). Если задача занимает пять или больше дней – ее необходимо разбить на более мелкие задачи и желательно распараллелить мелкие задачи между несколькими разработчиками, для увеличения уровня совместного владения кодом. Количество времени, необходимое для решения задачи ставят сами разработчики, после завершения очередного спринта осуществляется переоценка задач в Product Backlog на следующий спринт, чтобы сориентировать заказчика на сроки выполнения проекта.
  6. Каждый спринт начинается из Planning meeting, на которым мы вместе с Product Owner (иными словами заказчиком) набираем задачи на 36 story points (4 разработчика на 9 дней разработки). Главная задача Planning meeting состоит в том, чтобы заказчик увидел объем работ, который будет выполняться в последующий отрезок времени и продукт, который он получит в результате выполнения намеченных работ.

Code review

Следующей проблемой, которую нам предстояло решить – побороть то количество ошибок, которое возникало в следствии увеличения сложности проектов и низкого уровня совместного владения кодом, проще говоря, одному разработчику было сложно разобраться с кодом, написанным другим разработчиком. В результате мы предприняли следующие меры:

  1. Переход на стандарты написания кода от самой 1С. Кому интересно почитать можно здесь – очень полезная методичка, в которой описано как и что правильно делать, а что делать нельзя. Также там поднимаются вопросы о производительности кода, оптимальности работы запросов, уменьшению количества клиент-серверных вызовов и многое другое, что будет полезно и начинающему программисту и человеку с большим опытом. Каждый наш разработчик потратил определенное количество времени на изучение материала, а сейчас, мы повсеместно применяем его на практике, как во внутренних проектах так и при разработке под заказ.
  2. Code review. Думаю, это просто необходимость в современных проектах. При написании обработок, где количество строк кода исчисляется тысячами без него не обойтись. Часто удавалось отловить злую ошибку влияющею на производительность работы всей системы еще до внедрения у клиента. В нашей команде это стало стандартом – проверять код написанный коллегой и по возможности проводить рефакторинг или оптимизацию. Да, возможно стоимость разработки возрастает, но взамен мы получаем более стабильный код, меньшее количество ошибок, быстрый тем роста новых сотрудников.

И еще несколько слов о инструментах, которые помогают нам справляться со всеми нововведениями.

http://realtimeboard.com/ - онлайн доска, которая заменяет нам обычную. На ней мы рисуем наш Burn down chart (очень важный элемент в процессе разработки, поскольку позволяет увидеть, успеваем мы с проектом или нет), разные алгоритмы, или просто комиксы, связанные с разработкой :).

http://www.redmine.org/ - опенсорсный дашбоард в котором мы и ведем все наши проекты. Удобно с точки зрения возможности подгона под наши потребности к процессу разработки с помощью разнообразных плагинов и настроек. Здесь есть и проекты, и статусы задач, и чек-листы, и многое другое.

http://www.kayako.com/ - для улучшения работы службы поддержки пользователей. С помощью программы регистрируется каждое обращение в службу поддержки (письмо по электронной почте, звонок или персональный визит).

Вот и все. Но в статье описана только вершина айсберга. А как вы, уважаемые читатели, работаете над повышением качества разработки и жизни самих разработчиков внутри своей команды?

Статья опубликована также на сайте avtomat.biz

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2770    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14298    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5852    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

Предыдущие мои статьи на тему управления проектами носили концептуальный характер – ради чего мы делаем проекты, почему мы не получаем поддержку от коллектива пользователей, где найти помощь и мотивацию, как победить сложного заказчика. Теперь от концепций перейдем к технологии. Первая часть будет посвящена вопросам декомпозиции проектных задач на подзадачи для выявления узких мест нашего проекта.

10.02.2023    4699    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2746    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4184    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10664    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13088    0    Evil Beaver    17    

117
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. pumbaE 11.03.13 09:22 Сейчас в теме
Code review - и как, вы делаете coderewiew? Можно подробней описать инструментарий?
5. akomar 454 11.03.13 12:32 Сейчас в теме
(1) Проблема в том, что инструментария подходящего не нашли. Код проверяем «вручную» на соответствие стандартам.
7. pumbaE 11.03.13 12:38 Сейчас в теме
(5) к redmine есть плагин coderewiew, ну и 8.3 выгрузка конфигурации в файлы + git.
8. akomar 454 11.03.13 12:41 Сейчас в теме
(7) Да, 8.3 ждемс с нетерпением, очень не хватает контроля версий.
9. pumbaE 11.03.13 12:59 Сейчас в теме
(8) я вас разочарую пока еще в 8.3 альтернативного контроля версий нет, судя по последним беткам. Ну а что с учетом зазеркальных обещаний, то вряд ли там что-то для альтернативных систем будет сделанно. Не верю, я в 1С в этом плане.
2. Belomor 110 11.03.13 09:57 Сейчас в теме
Экстремальное программирование (точнее - его элементы) действует ;). Спасибо за публикацию, ибо реальный опыт всегда интересен
3. fomix 33 11.03.13 11:41 Сейчас в теме
В свое время мне очень помогла давно прочитанная книга 1982 года издания "Искусство тестирования программ" автор Майерс Г. - просто и понятно. Кому интересно - вот ссылка http://mirknig.com/2009/06/20/iskusstvo-testirovaniya-programm.html.
VallyD; ftm; vabue; akomar; +4 Ответить
6. akomar 454 11.03.13 12:33 Сейчас в теме
46. VallyD 13.03.13 14:11 Сейчас в теме
(3) fomix, действительно интересная и полезная книга
4. prog1c8 11.03.13 12:27 Сейчас в теме
автор - ты русский?
copybases; surikateg; ElenkaLisenka; fomix; +4 1 Ответить
10. pbazeliuk 1955 11.03.13 13:22 Сейчас в теме
(4) prog1c8, Ваш вопрос имеет отношение к статье?
12. prog1c8 11.03.13 13:40 Сейчас в теме
11. romansun 193 11.03.13 13:40 Сейчас в теме
оооочень интересно, спасибо

пара вопросов:

- какого рода проекты у вас? можно воспользоваться вот это классификацией http://habrahabr.ru/post/172083/ :)

я почему спрашиваю, agile не заведется под "неподготовленного" заказчика, нежелающего ничего слышать..

(4) коллеги, методики западные. Устоявшего перевода нет и, видимо, не будет. Это не более, чем унификация терминологии. Если бы автор перевел все это по своему усмотрению, то получился бы рассинхрон со всей остальной инфой в инете.
13. prog1c8 11.03.13 13:59 Сейчас в теме
(11) romansun, согласен.
но вот такие фразы (например)
------------
.... Тем не менее, team leader принял решение о переводе разработки....
------------
говорят что слова из разных языков перемешанные в одном тексте - это не изза их непереводимости, причина в чем то другом...

конечно мы не на уроке русского языка и культуры общения, но все же автор написал статью для общего обозрения, и надо читателей как то уважать - используешь понятие из другого языка, ну возьми ты его в кавычки и дай расшифровку, чтобы читателю ясно было о чем речь.
silverbuger@yandex.ru; so-quest; fomaOp; zelevova; Oleg_nsk; Lubocka; +6 Ответить
15. orefkov 1152 11.03.13 14:43 Сейчас в теме
(13)
А по мне имхо, написание "team leader", а не "тимлид" - гораздо большее уважение к читателям.
(5)
Рефакторинг, надо больше рефакторинга!
Может отдельной статьей поделитесь опытом рефакторинга именно в 1С.
Какие приемы в-основном используются, как они выполняются, учитывая специфику 1С-языка и ее программной модели.
Какие технические средства хотелось бы иметь для его облегчения.
А то кроме "extract method" дело дальше не двигается.
zzz14; Gilev.Vyacheslav; +2 Ответить
14. akomar 454 11.03.13 14:02 Сейчас в теме
(11) прочитаю статью на хабрахабр и тогда отвечу точно по классификации (вечером :)).
16. ivanov660 4330 11.03.13 15:39 Сейчас в теме
Интересный опыт. Странно как вы до этого работали без таких тривиальных вещей?
17. orefkov 1152 11.03.13 15:42 Сейчас в теме
(16)
Вам действительно странно, как 99% одинэсников работают или так, потроллить ?
silverbuger@yandex.ru; _also; JohnyDeath; Redokov; zba; адуырщдв; Legin; EliasShy; zqzq; Makushimo; Yakud3a; ftm; yku; +13 Ответить
35. ivanov660 4330 11.03.13 21:28 Сейчас в теме
(17) orefkov,
Причем тут троллинг?
Возможно мне повезло больше остальных и мы работаем в более или менее нормальных условиях. Но работать без инструментов управления проектами или баг-трекинга это ужасно особенно для больших команд.
18. gr0ck 11.03.13 16:14 Сейчас в теме
Давно хотел почитать про agile, думаю, пора. Странно, что такой небольшой франь, 4 человека, и все так серьезно) Какого рода проекты у вас? Насколько крупные?
19. akomar 454 11.03.13 16:16 Сейчас в теме
(18) О проектах напишу отдельный комментарий, только вечером :)
21. pbazeliuk 1955 11.03.13 17:32 Сейчас в теме
(18) gr0ck, коллега наверное ошибся. У нас такая структура:
1 - ген. директор
1 - ведущий программист
1 - старший программист
1 - программист
3 - внедренца/поддержка
2 - системных администратора
2 - веб-разработчика

Проекты разные. Тот что является основным - пиковая нагрузка 150 пользователей онлайн, 30-40 тыс. документов в месяц.
aharechko; +1 Ответить
22. akomar 454 11.03.13 17:44 Сейчас в теме
(21) Статья именно об организации труда людей, которые занимались активной разработкой под 1С (не админы и не консультанты).
20. snic 125 11.03.13 16:40 Сейчас в теме
Спасибо за статью. Почерпнул полезные вещи.
23. DitriX 2091 11.03.13 18:31 Сейчас в теме
Вот уж чего точно на инфостарте не хватает :)
Этого хлама навалом на хабре и прочих ресурсах, можно только направление изменить на 1С, а не пхп, ява и т.д.
В вашей статье не обнаружил ничего полезного и интересного.
Выложили бы хоть пару скринов, а то говорите о каких то вещах, которые понятны только вам.
Привели бы пару примеров из жизни, например вы пишете:

Среди разработчиков был назначен Scrum Master – один из разработчиков, на широкие плечи которого был возложен тяжелый груз общения из заказчиком, а также проведения ежедневных Daily Scrum Meeting. Теперь мы смогли более сконцентрироваться на разработке, а не на выяснении отношений со свирепыми пользователями, объясняя им, почему мы не будем решать ту или иную задачу здесь и сейчас


Но объяснять то все равно надо. Тем более таким путем - команда теряет навыки общения с людьми. Люди считают что их игнорируют.Этот ваш Scrum Master - не может знать 100% проектов, так что он я так понимаю в любом случае перенаправляет все консультационные звонки программистам. В итоге время уходит на это точно так же.
А не боитесь ли вы все завязывать на одном человеке? А если он заболеет? Уволится?

Как вы ставите приоритеты задачам? На основании каких данных? Что вы делаете в случае не предвиденных авралов?

В целом - статья ни о чем. Очередной обзор софта :) Извините, но этого хлама везде полно.

Расскажите хоть как вы оцениваете время и на сколько в среднем проградываете? Я например беру время, за которое я могу теоретически сделать обработку, умножаю на четыре и говорю клиенту это число дней, с приставкой "от".

От себя могу добавить, что методика разбиения времени разработчиков на спринты очень удобна и программистам и начальству, поскольку первые получают определенный список задач, ТЗ которых не изменяется на протяжении спринта, а вторые видят определенный результат после окончания итерации разработки.


У вас нету по ходу бухгалтерии на поддержки, при чем измененной, мы так раз, совсем недавно только тем и занимались, что обновляли бухгатерию всем клиентам, на остальное тупо времени не хватало и ресурсов. Мы уже просто сидели и смеялись. Вот это сюрприз от 1С, после которого, две недели указанные вами - не понятно откуда взяты. А акции вы никогда ночью не делали? Ну просто потому что клиенту захотелось :)

Я это все к чему - мы работаем в той сфере бизнеса, где порядок, это роскошь. Тут не реально строить планы и какие то перспективы. Ты не можешь крупному клиенту просто так сказать - "друг иди лесом, у меня план расписан на две недели", ибо он пойдет лесом и найдет другого, который сделает это тут и сейчас.


Поэтому хотелось бы почитать статью о том, как это происходит РЕАЛЬНО, а не эту выдержку из любой книги по тайм мэнэджмэнту или статьи на хабре.

Ух я наваял :) Просто этого "добра" в последнее время - немерянно.
Сори, если что. Ничего личного.
FSerg; silverbuger@yandex.ru; МимохожийОднако; spy-83; NCCSOFT; Никс; tarasenkov; адуырщдв; Oleg_nsk; Yakud3a; ftm; +11 Ответить
25. romansun 193 11.03.13 18:52 Сейчас в теме
(23)

Единственное, с чем соглашусь - побольше жизни. В принципе про скрам и всё такое прочитать можно везде. А вот про скам и 1С на реальных примерах - нигде.

В остальном - не согласен :). Подразделения it-бухгалтеров не относятся к проектной разработке никаким боком. Это техподдержка, саппорт... Разные направления работ, разные подходы.

В 1С мире есть софтварные фирмы и их заказчики, у которых с порядком более менее вменяемо. Они вполне используют разные вумные методики.
26. pbazeliuk 1955 11.03.13 19:07 Сейчас в теме
(23) DitriX, для консультационных вопросов есть первая линия поддержки в kayako. Если так случилось, что поддержка не справилась, тогда переводят обращение на программистов.
27. DitriX 2091 11.03.13 19:21 Сейчас в теме
(26) а как они объясняют не типичные вопросы. Вот напимер у нас есть клиент, который любит акции, но его персонал вечно забывает как их делать. Инструкции не помогают. Они страхуются и звонят программисту (мы тоже аутсорсингом занимаемся). Вот вопрос, как ваша линия консультаций может ответить на такие специфические вопросы? Или их "гоняют" по всем доработкам всех клиентов? :)

(25) вот когда вы сможете людям объяснить, что задним числом ничего делать нельзя, тогда можем говорить про порядок в найшей сфере. До того момента, пока делаются костыли в ральных бизнесс процессах (ч/б бухгалтерия, вначале отдам товар, потом сделаю накладную, вначле продам, потом приход), то они отражаются и в нашей работе.

1С решили не плыть против течения и замутили РАУЗ. Почему? Если все было бы отлично и красиво, то обычный партионный вполне себя оправдывал (по большей части).

Я это все к тому, что мы себя тоже так вначале "обманывали", типо у нас все по плану, а этих 10% (потом 20, потом 90%) ситуаций которые не вписываются в график, запланированный ранее, то это всего лишь "ньюансы".

(26) Не возникает ли у вас такого? В общем поделитесь опытом. Нас интересует кухня, а не готовое блюдо.
28. romansun 193 11.03.13 19:42 Сейчас в теме
(27)
Я так понимаю, у вас в основном поддержка? В таком случае, да, эта статья не про вас :) Мы вообще от темы публикции ушли в разговоры за жизнь 1С-ную... Моё мнение - я бы уходил из таких контор. Вот реально. В таких местах вы *всегда* априори it-бухгалтер.

У меня несколько коллег ушли вообще из 1С именно по причине желания работать программистами (архитекторами, РП и пр.), а не бесконечно работать за пользователей бухгалтерами и расчетчиками зп.

В проекте, где работаю я, заднего числа, к счастью, почти нет. Ибо происходит ежедневное "закрытие дня" и править в прошлом просто так нельзя в принципе :)

Вот напимер у нас есть клиент, который любит акции, но его персонал вечно забывает как их делать. Инструкции не помогают. Они страхуются и звонят программисту (мы тоже аутсорсингом занимаемся). Вот вопрос, как ваша линия консультаций может ответить на такие специфические вопросы?


Счетчик, как в такси, включается. 20 минут в месяц (? или в неделю... не помню) бесплатно, остальное - по расценкам разработки. Счета по итогам месяца помогают справляться с неспособностью читать инструкции. Это реальный пример из жизни в работе одной отраслевой "1С:Бла-бла-бла". Но для такой жесткой манеры работы у вас должны быть железные яй.. эээ... очень крутая софтина, на которую клиенты молятся и крутые спецы.
antonov_i; vabue; +2 Ответить
31. DitriX 2091 11.03.13 20:16 Сейчас в теме
(28) та нет, в основном у нас именно разработка, и с бухгалтерией мы вообще практически не работаем. Только тогда, когда выходит пачка обновлений и все фирмы только этим и занимаются.

В основе нашей работы лежит все то, что касается управленческого учета, а не бухгалтерского. Бухгалтер у нас толковый только один. Я же до сих пор путаю дебит и кредит :) Так что не обязательно быть it-бухгалтером, с таким же успехом можно быть it-аналитиком, it-"он знает все, давайте спросим у него, зачем читать инструкции и экономику в 8 классе я прогулял".При этом за это очень не мало платят.

Счетчик, как в такси, включается. 20 минут в месяц (? или в неделю... не помню) бесплатно, остальное - по расценкам разработки. Счета по итогам месяца помогают справляться с неспособностью читать инструкции.

Не поверите - платят, и даже не парятся (хотя мы берем в среднем на 30 - 50% больше чем франчи по городу). Просто люди знают - к нам когда не обратись, мы всегда готовы сделать. Даже в час ночи. И даже не абы как, а вполне нормально.
Так что дело не в оплате, а в подходе и в решении таких случаев, про что мне и интересно узнать.
Т.е. есть план на две недели, и вот такой аврал, надо срочно сделать.
Как в этом случае двигаются сроки, как потом сводятся концы с концами? Или в эту неделю заложено 4 дня резерва?

(30) та что вы с этими ценами заладили. Та пусть хоть х10 будет множитель. Вопрос в том - как это сказывается на вашей структуре? Т.е. понятно что поработав ночью, я уже днем буду спать. А теперь я выспался днем - ночью спать не буду хотеть. Короче, что бы прийти в адекватное состояние, после одной рабочей ночи, надо минимум 3 - 4 дня.

Вот как вы с такой ситуацией разбираетесь?
32. pbazeliuk 1955 11.03.13 20:49 Сейчас в теме
(31) DitriX, для таких ситуаций закладывается 15-20% рабочего времени, хотя это время еще используется, если задачу оценили не правильно. В том случае, если ничего не случилось и осталось время, выполняются технические или другие приоритетные задачи.

Есть еще дополнительные руки - поддержка, она может обновить конфигурацию и что-то дописать не шибко сложное, если уж все так плохо.
33. pbazeliuk 1955 11.03.13 21:15 Сейчас в теме
(31) DitriX, на практике, такое случалось 3 раза.
Первый раз, при внедрении УТ в 2010г., месяц работали без сна;
Второй раз, начало лета 2011г., при неудачном обновлении УТ;
Третий раз, начало лета 2012г., так же неудачное обновление УТ.

После этих неудач, мы внедрили методику поэтапной разработки. Начали всегда прорабатывать чек-листы, добавились обязательное совместное владение кодом. Для очень сильно измененных конфигураций использовали статьи: http://infostart.ru/public/169131/ и http://infostart.ru/public/16980/. Например, чек-лист для УТ11 у нас составляет около 1000 позиций. При обновлении УТ11 в конце лета 2012г., было выявлено всего 3 ошибки, которые не попали в чек-листы, одна из них была зарегистрирована на партнерском форуме, так как являлась ошибкой конфигурации.
адуырщдв; +1 Ответить
36. pumbaE 11.03.13 23:22 Сейчас в теме
(33) pbazelyuk, покажите реальные примеры чек-листов хотя бы десятую часть.
(0) Скринов не хватает, примеры реальные спринтов, как в redmine происходит распределение, какие фильтры стоят, какие настройки/плагины и т.д. Пользуетесь ли таким понятием в redmine как резолюция для задачи, какой у вас workflow настроен для "фичи"/"задачи"/"ошибки".

добавились обязательное совместное владение кодом
можно расшифровать, инструементы, как на практике вы владете кодом и т.д. и т.п.
Как у вас чек-лист обновляется, есть ли связь между закрытой задачей и автоматическим добавлением в чек-лист? Как фильтруете чек-листы по подсистемам, какими средствами формируется справка, где видна история разработки/доработки например для документа/справочника/подсистемы , зависимость доработки на подсистему или документ ... ?
37. akomar 454 12.03.13 00:03 Сейчас в теме
(36)Вот например скриншот нашего текущего спринта http://piccy.info/view3/4256958/eb951a621f5a98b643ff99412c94f893/

Статусы в задачах http://piccy.info/view3/4256997/9f2ca935c4ae4f6942f990a7fad98cdc/
Версии - http://piccy.info/view3/4257023/cda650c42375e8cfb2cca041a87350b1/


Чек листы ведутся в google docs (предоставить на всеобщее рассмотрение не могу). Чек лист для каждой задачи подкрепляется через wiki-страницу.

Совместное владение кодом в нас подразумевает следующее, каждый из членов команды должен в любой момент продолжать писать код после своего коллеги. Сначала пробовали достигнуть эффекта парным программированием, но код-ревью + внедрение стандартов написания кода (http://its.1c.ru/db/v8std#browse:13:-1) намного эффективней. Спец инструментов (которые удобно использовать в 1С так и не нашли).
42. romansun 193 12.03.13 13:52 Сейчас в теме
(31)

Не поверите - платят, и даже не парятся (хотя мы берем в среднем на 30 - 50% больше чем франчи по городу). Просто люди знают - к нам когда не обратись, мы всегда готовы сделать. Даже в час ночи. И даже не абы как, а вполне нормально.
Так что дело не в оплате, а в подходе и в решении таких случаев, про что мне и интересно узнать.
Т.е. есть план на две недели, и вот такой аврал, надо срочно сделать.
Как в этом случае двигаются сроки, как потом сводятся концы с концами? Или в эту неделю заложено 4 дня резерва?

Т.е. понятно что поработав ночью, я уже днем буду спать. А теперь я выспался днем - ночью спать не буду хотеть. Короче, что бы прийти в адекватное состояние, после одной рабочей ночи, надо минимум 3 - 4 дня.

Вот как вы с такой ситуацией разбираетесь?


Очень, очень круто, что у вас такой авторитет и кредит доверия!

В целом, считается хорошей практикой, когда разработчик задействован максимум на двух задачах. Причем, одна - основная, вторая - вторым номером.
Понятно, что в этот период разработчик не должен заниматься еще тем, этим, вот тут, вот там, и еще чуть чуть у тети Вали в зарплате.

Разработчик вообще не должен заниматься саппортом. Это работа других подразделений. И да, я прекрасно понимаю, что далеко не везде есть эти подразделения.

И конечно, никой ночной работы быть не должно :D. 8 часов рабочий день, если только он у вас официально НЕ ненормированный. )))

Возможно, имеет смысл расширить чуть штат, особенно учитывая, что вас, как фирму, ценят.
43. DitriX 2091 12.03.13 14:43 Сейчас в теме
(42) Проблема в том, и наше спасение, что мы закрепляем за фирмой одного человека (минимум) и он работает с этой фирмой. Т.е. мы делим не по проэктам, а именно по фирмам. Таким образом - на все вопросы одной фирмы - способен ответить только этот человек. И эта фирма знает, что при любой проблеме - она звонит ему и он все объяснит (я повторяюсь, что бухгалтерией мы вообще не занимаемся, только редкие обновления, когда уэ очень просят).

И каждый наш программист-аналитик - является чуть ли не советником директора, так как с помощью знания программной логики - он может сказать еще на этапе зачатка идеи о том, как ее можно и нужно реализовать.

Это очень важно, так как вам могут сказать - сделай нам отчет по остаткам с ценами. Не зная ситуации в этой фирме - вы сделаете. Но если бы вы были там и понимали суть проблемы, то вы бы поняли, что этот отчет их никак не спасет. В реалии у них сверка взаиморасчетов с поставщиками, у них партионный учет и расчет, почему-то, они делали не по партиям закупки, а брали какой то левый отчет, который выводил им количество проданых пар и цену по типу цен и расчитывались с поставщиком. В итоге - бешеный перекос себестоимости и как следствие - валовой прибыли.
И они думали что построив отчет по остатками с ценами они смогут понять, где у них перекосы. Ясное дело что они бы не поняли.

Это я к чему:
Разработчик вообще не должен заниматься саппортом. Это работа других подразделений. И да, я прекрасно понимаю, что далеко не везде есть эти подразделения.

Если вы говорите про 1С-кодеров, то я согласен с вами, это по сути студенты, начинающие или ежи с ними. Тут да, они могут только кодить под надзором.

Но если вы говорите Разработчик , то тут я с вами не согласен. В этом и принципиальное отличие 1С программистов от программистов других областей, ибо 90% времени мы тратим на понимание и изыски - как лучше, и только потом пишем код (я ни в коем случае не говорю что в других языках на понимание времени не тратится, однако 1С тем и уникален, что разработчик является и дизайнером, и программистом, и аналитиком, и козлом отпущения для тупых тёть). И разработчикам как воздуху необходимо общаться с людьми, иначе они никогда не научатся ничему, кроме кодинга в 1С. В других фирмах (не 1С) есть отделы дизайна и GUI, а вы когда то обращались к дизайнерам, что бы они вам сказали где лучше кнопку разместить и как обозвать вот это поле? Я сомневаюсь.

Я просто столько видел крутых обработок, но мертвых. Идея хорошая, но то как она реализованна - это жесть. Т.е. программист писал для программиста. Почему? Так он других людей в глаза не видел :)

ИМХО...
МимохожийОднако; +1 Ответить
44. romansun 193 12.03.13 17:50 Сейчас в теме
(43)
ну чо, я согласен полностью. Наша 1С-ное подразделение тоже на 75% такое. Человек закреплен за парой фирм. Да так все работают, по сути.

только это называется саппорт

Он не имеет к разработке никакого отношения. Терминология, что 1С-ник на поддержке - это разработчик, а собственно сам разработчик - это просто студент-кодер некорректна.

1С-ник на поддержке это именно саппортный работник. К разработке конфигураций с нуля или подсистем с нуля такая деятельность отношения не имеет. Это другие знания, другие навыки, другой опыт. Общая только платформа 1С.

Просто так вышло, что 80% 1С-ников - это именно саппортеры. Ибо возможность создавать конфы с нуля имеют весьма немногие коллективы.

Те же, кто создает 1С-ные продукты на продажу - очень часто имеют классическую структуру обычной софтварной фиры. Все эти джуниоры, сеньоры, ПМ-ы, аналитики, тестеры и прочие и прочие.
51. АлексейН 2 18.03.13 10:33 Сейчас в теме
Интересная и достаточно познавательная статья.
(43)
Проблема в том, и наше спасение, что мы закрепляем за фирмой одного человека (минимум) и он работает с этой фирмой. Т.е. мы делим не по проэктам, а именно по фирмам. Таким образом - на все вопросы одной фирмы - способен ответить только этот человек. И эта фирма знает, что при любой проблеме - она звонит ему и он все объяснит (я повторяюсь, что бухгалтерией мы вообще не занимаемся, только редкие обновления, когда уэ очень просят).

И каждый наш программист-аналитик - является чуть ли не советником директора, так как с помощью знания программной логики - он может сказать еще на этапе зачатка идеи о том, как ее можно и нужно реализовать.

Это очень важно, так как вам могут сказать - сделай нам отчет по остаткам с ценами. Не зная ситуации в этой фирме - вы сделаете. Но если бы вы были там и понимали суть проблемы, то вы бы поняли, что этот отчет их никак не спасет. В реалии у них сверка взаиморасчетов с поставщиками, у них партионный учет и расчет, почему-то, они делали не по партиям закупки, а брали какой то левый отчет, который выводил им количество проданых пар и цену по типу цен и расчитывались с поставщиком. В итоге - бешеный перекос себестоимости и как следствие - валовой прибыли.
И они думали что построив отчет по остатками с ценами они смогут понять, где у них перекосы. Ясное дело что они бы не поняли.

Это тоже верно не зная специфики учета в организации, и очень тонких ньюансов - не возможно не только правильно написать отчет, но доказать бухгалтеру что она не права.
30. pbazeliuk 1955 11.03.13 20:03 Сейчас в теме
(27) DitriX, поддержка в состоянии решить такие вопросы.
Если у клиента аврал или надо на "вчера", тогда такие задачи оплачиваются с множителем х2-х3 от нормальной стоимости.
53. stagov 11 20.03.13 03:13 Сейчас в теме
(23) DitriX,
Статейка типа "не для средних умов".
54. DitriX 2091 20.03.13 13:32 Сейчас в теме
(53) это был камень в чей огород? :)
55. stagov 11 20.03.13 17:27 Сейчас в теме
(53) DitriX
автора сего произведения.
есть такое определение СУРЖИК. Надо уважать родной язык. А не писать всякую .....
Надо думать, что автор очень спешил это написать...
24. DoctorRoza 11.03.13 18:47 Сейчас в теме
Ну что, ничего нового, все давно известно! Никакой революции в статье нет!
29. romansun 193 11.03.13 19:48 Сейчас в теме
Я это все к тому, что мы себя тоже так вначале "обманывали", типо у нас все по плану, а этих 10% (потом 20, потом 90%) ситуаций которые не вписываются в график, запланированный ранее, то это всего лишь "ньюансы".



Не поверите, но это тоже планируется. В мире разработки софта такое везде и во всех странах. И давно. Ничего нового. Просто мы в 1С (да и в целом, по стране) реально отстали в методиках управления. Как бы пафосно и приторно по-западному это не звучало. Управление программными проектами, управление эффективностью, управление рисками, управление прочей лабудой - это всё описано и сформулировано. Причем именно для разработки софта.
34. ILM 240 11.03.13 21:27 Сейчас в теме
Ждите, если найду время, то разрожусь статьей с применением ТОС, почему все должны на проектах работать так же как и автор публикации.
38. pumbaE 12.03.13 01:13 Сейчас в теме
Версии внешних обработок/отчетов как ведете?
39. akomar 454 12.03.13 01:29 Сейчас в теме
(38)Все обработки хранятся на центральном хранилище (сервер разработки).

Вот пример версии Версия = "2.01.42";

Первая цифра - количество изменений в ядре обработки (изменение принципа работы или логики обработки).
Вторая цифра - значительные, но не масштабные изменения (например перерисовали форму, или макет отчета).
Третья цифра - количество мелки изменений (вплоть до опечатки в заголовке обработки).

После прохождения всего цикла (планирование, разработка, код-ревью, тестирование) разработчик изменяет версию обработки, а в справку (она обязательна к каждой обработке) вносит информацию о изменениях, которые он внес, например:
2.01.43 - изменил заголовок с "супер обработка" на "супер мего обработка".

После внесения изменений нужно посмотреть изменил ли ты самую свежую версию (обычно Сравнение/Объединение). Если все ок - подключить обработку на продакшен и поместить в файловое хранилище и сказать коллегам что вот, я внес мего изменения.

П.С. Если честно очень не хватает контроля версий. Очень много надежд на 8.3.
40. Gilev.Vyacheslav 1910 12.03.13 02:39 Сейчас в теме
(39) спасибо за статью!
на счет троллей сочувствую, их расплодилось много...
41. pumbaE 12.03.13 12:04 Сейчас в теме
(39) попробуйте svn/git/bzr использовать для хранилища внешних обработок очень удобно, для мажорных версий можно использовать тэги , а минорные видны сразу по истории разработки.

Питаете прям нездоровую веру в светлое будущее альтернативного контроля версий и 8.3 :). 1. Вряд ли будет пакетная выгрузка/загрузка для обработок/отчетов.
2. В 8.2 модуль формы выгружался, теперь форма во внутреннем представлении выгружается вся вместе только без напильника от этого никакого толку, считай то же самое что и v8unpack.
3. У вас есть хранилище, попробуйте выгрузите cf в xml, потом обратно из xml в cf и сравните с хранилищем, роли вас удивят...
45. lextor 5 13.03.13 07:31 Сейчас в теме
Статья понравилась. Организация процессов разработки конечно не нова, но реальный опыт всегда интересен!
47. пользователь 13.03.13 17:47
Сообщение было скрыто модератором.
...
48. Varp 14.03.13 00:35 Сейчас в теме
В большинстве случаев именно выделение специального сотрудника спасает положение если вдруг что-то пошло не так. Конечных пользователей выводит из себя когда каждую неделю меняется человек, который настраивает им 1с-ку или пишет для них отчет. Еще больше их бесит когда пришедший "новый" программист постоянно звонит в офис и спрашивает: а это куда? а почему здесь сделано так? кто и зачем сделал данную х..ню. В большинстве случаев при разработке средних или сложных систем приходится делать одно ,а получается ,как ни банально, другое "Видите ли бухгалтер представляла себе конечный результат по другому :(((" И неважно что подчас приходится по несколько часов сидеть на их собраниях и доказывать, объяснять, что так будет лучше проще, что нельзя все на свете автоматизировать (до чего же много людей любящих нажать одну кнопку и программа все сама за Них сделает :)))). Поэтому основным критерием при разработке и продвижению программного продукта на самом деле является правильно построенное общение, а его как раз таки проще и нужно налаживать только с постоянным сотрудником, выделенным для этой фирмы.
49. pumbaE 14.03.13 00:52 Сейчас в теме
(((" И неважно что подчас приходится по несколько часов сидеть на их собраниях и доказывать, объяснять, что так будет лучше проще, что нельзя все на свете автоматизировать (до чего же много людей любящих нажать одну кнопку и программа все сама за Них сделает :))))
И не важно, что мы обратились к вам таким уверенным со своей проблемой, да мы знаем, что это трудно, да мы платим деньги за решение этой проблемы, да мы хотим нажать одну кнопку, пускай 2 но не десять и увидеть результат, а в результате высиживаем на дурацких совещаниях, где нам пытаются доказать, что это невозможно и сидишь на этом совещании, тратишь время и все заканчиваеться фразой "а кому сейчас легко", а потом еще берет наш консультант по 10 раз на дню заворачивает ваш код написанный на коленке (о как я ненавижу хранилище), без всяких правил форматирования, с запросами в циклах (при возможности решения задачи одним запросом) и т.д. Результат: горло охрипшее, спать хочеться, но вроде работает все.

p.s.: простите крик души, недавно побывал со стороны консультанта, и теперь на фразы "совещания, так будет проще (для кого главнй вопрос), одну кнопку сделать нельзя" у меня аллергия.
50. ranger 123 15.03.13 10:34 Сейчас в теме
Согласен с prog1c8 по поводу стиля изложения.
Оперировать жаргонами,известными узкому кругу лиц,наверное не айс.
Как говорится-тема сисек не раскрыта
52. RG84 18.03.13 12:44 Сейчас в теме
спасибо... новый реальный опыт всегда интересен и полезен
56. 1cNike 209 20.03.13 22:37 Сейчас в теме
Статья понравилась. Недовольные сленгом могут не читать, верно? Либо вникать и разбираться. Каждому свое.
57. shandre 69 21.03.13 01:07 Сейчас в теме
58. itmind 308 21.03.13 08:23 Сейчас в теме
Почему выбрали именно SCRUM, а не Канбан ?
Были ли какие либо доводы за и против данной методологии?
62. akomar 454 21.03.13 12:03 Сейчас в теме
(58)Спасибо за вопрос.

В большинстве своём заказчики хотят результат, быстро и дёшево, поэтому мы выбрали SCRUM, поскольку в конце каждого спринта у нас есть релиз продукта готовый к внедрению. Перед внедрением SCRUM, проекты затягивались, часто бывало, что заказчик изменял требования во время разработки.

По своему опыту скажу, что если делаешь небольшими порциями но результат виден заказчику - он будет доволен и будет продолжать сотрудничать.

По системе, очень похожей на комбан у нас работает служба поддержки (с помощью kayako).

На счет второго вопроса, вначале никто не хотел ни SCRUMа, ни Канбана :)
59. Senator_I 166 21.03.13 08:32 Сейчас в теме
Да уж, как организовать правильно работу - действительно вопрос хороший, спасибо за статью.
60. KroVladS 34 21.03.13 11:54 Сейчас в теме
(0)
Почему в качестве ХелпДеска выбрали именно kayako, на сколько я понимаю это платное решение.
И если выбирали не из фри софта, почему не воспользовались решениями от 1с, что было бы логично для 1с программистов.
63. akomar 454 21.03.13 12:04 Сейчас в теме
(60)К нам попала демка kayako всем понравилась, потом решили купить. Понравился клиент под софтфон
61. fr.myha 21.03.13 11:55 Сейчас в теме
Мне очень нравиться использовать интеллект карты. Создаю их через MindManager.
Есть еще книга классная на эту тему: Бехтерев С. - Майнд-менеджмент. Решение бизнес-задач с помощью интеллект-карт - 2009.
Советую прочитать.
64. aharechko 47 21.03.13 21:46 Сейчас в теме
Интересная статья. Автор, спасибо.
65. OVladius 32 22.03.13 13:32 Сейчас в теме
"часто подымались вопросы о том, что программисты ничем не занимаются вовсе" - у меня это постоянное явление, хотя я и обрадовался что на предприятии не ведется учет рабочего времени но мне пришлось самому записывать что и когда я делал, потому что претензии были всегда, тип я сижу ничего не делаю, но когда я начал вести свой учет рабочего времени у начальства сразу все вопросы отпали и сразу все было понятно, чем и когда я занимался и что я сделал.

А как повысить качество работы если я один программист в конторе?
После разработки происходит тестирование 1 раз, в бухгалтерии девчонки проверили если работает то сразу же внедряем, потом лезут косяки и приходится быстро исправлять ошибки в работе.
66. akomar 454 22.03.13 16:14 Сейчас в теме
(65) Уделяйте больше внимания тестированию. Если Вы создаете новую обработку - составьте список пунктов, которые нужно протестировать (так называемый чек-лист) и сохраните этот документ. Составляйте список очень подробно, стараясь учесть каждый нюанс. Внедряйте свою наработку только тогда, когда пройдетесь по всему списку и ошибок не обнаружите.
После внесения изменений нужно опять таки проходить весь список (чек-лист) с самого начала. Конечно, время на разработку возрастет, но при тщательном составлении чек-листа сократится время на последующие исправления багов (постарайтесь донести это начальству и вносите больше времени на тестирование при оценке задачи).

Конечно, здесь еще нужно не ленится и заставлять себе заниматься тестированием такого рода, по себе знаю как хочется иногда забить и закончить задачу.

И еще один нюанс. Тестируйте под правами всех пользователей, которые будут пользоваться Вашей разработкой, даже если вы программируете отчет.

Удачи в новых начинаниях!
67. OVladius 32 22.03.13 19:42 Сейчас в теме
(66) У нас так бывает по дурацкому что приходит шеф говорит нам надо срочно сделать выгрузку продаж на андроид(есть свое приложение) пишешь сам пару раз проверяешь и сразу же внедряешь потому что торопят всем все срочно надо, но это уже проблема начальства, может составить какой то регламент по тестированию и показать начальству?

"И еще один нюанс. Тестируйте под правами всех пользователей, которые будут пользоваться Вашей разработкой, даже если вы программируете отчет." - на днях напоролся на этот нюанс, недели две не могли найти ошибку оказалось что проблема была в правах пользователя, а все тестили под полными.
68. akomar 454 22.03.13 19:52 Сейчас в теме
(67) Поговорите с начальством, расскажите в чем бывают проблемы, хотя к не технарям бывает трудно достучатся :)
69. _LEV_ 26.03.13 12:01 Сейчас в теме
(67) Этой проблемой страдают практически все - нехваткой времени на тестирование, и непониманием руководства, что работу можно внедрять только после тестирования.. в том числе и под правами пользователя(ей). Сами несколько раз на этом ловили баги..
70. mzelensky 53 28.03.13 10:35 Сейчас в теме
Взбесило меня пожалуй одно - вы что, русским языком не владеете? Или автор считает, что в русском лексиконе НЕТ ничего того, чем можно было бы заменить англоязычные понятия? Причем это даже не понятия, а просто фразы.
71. pumbaE 28.03.13 11:06 Сейчас в теме
OFF: (70) mzelensky, а вы какой русский язык имеете ввиду? Литературный, сленговый, разговорный ? 20 века или 19 или 21 ?
72. mzelensky 53 28.03.13 11:17 Сейчас в теме
(71) Русский язык в целом. Если владеете дворянским русским языком 19 века, то можете писать и на нем.
73. Evgeniy.Pecheykin 31 31.03.13 19:49 Сейчас в теме
Спасибо автору за статью! Сейчас сложилась такая же ситуация. Вроде работа делается, а её не видно. Вспомнить, что кто делал месяц назад - невозможно. Для слежения за выполнением задач использовали самописную конфигурацию на 1С. До спринтов пока не дощли, но задачи расписываются по мере поступления.

На счет русского языка. 10 минут в интернете:

Team Leader - Руководитель группы.
Некоторые должностные обязанности:
  • назначение задач членам команды
  • обзор работы членов команды
  • тренировка членов команды
  • поддержание контакта с представителем заказчика

Спринт (Sprint) – сфокусированные усилия группы на небольшой участок времени (неделя, 2 недели, но обычно не более месяца)

Скрам-мастер (ScrumMaster) - проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

Резерв проекта (Product Backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации.

Планирование спринта (Sprint Planning Meeting) - Происходит в начале новой итерации Спринта.
Evgen.Ponomarenko; +1 Ответить
74. s_uu 22 10.04.13 11:43 Сейчас в теме
Столько много иностранных терминов!!
75. Evgeniy.Pecheykin 31 14.04.13 21:45 Сейчас в теме
Ну я вроде все перевел=)
77. Wooster 01.01.14 21:30 Сейчас в теме
Андрей, спасибо за хорошую и полезную практическую методику работы.

Негативные комментарии вызвали недоумение.
78. Evgen.Ponomarenko 567 02.01.14 02:24 Сейчас в теме
Присоединяюсь к плюсующим тремя плюсами (+++)!
79. IgorXml 724 29.01.14 17:50 Сейчас в теме
Проекты веду единолично здесь kanbanflow.com . Но обязательно надо попробовать ваши методы-инструменты.
80. JesteR 151 22.02.14 21:11 Сейчас в теме
Спасибо за статью, начали использовать реалтаймбоард.
81. LexSeIch 210 01.07.14 12:18 Сейчас в теме
Мир этому дому!
Прошу прощения, что комментарий запоздалый, но не могу упомянуть про прекрасный перевод книги по практике использования Scrum и XP:

"Scrum и XP: заметки с передовой. Как мы делаем SCRUM". Книга имеет практическую направленость ( содержит менее 100 страниц). Ее чтение не отнимет много времени, и в то же время будет полезна тем, кто использует (или собирается использовать) технологии SCRUM и экстримального программирования (XP) в своей практике. Эта книга отображает субъективное мнение и практический опыт автора.

"Эта книга не претендует на звание «единственно правильного» учебного пособия по Scrum'у! Она всего
лишь предлагает вам пример удачного опыта, полученного на протяжении года в результате постоянной
оптимизации процесса. Кстати, у вас запросто может возникнуть ощущение, что мы всё поняли не так."
Майк Кон."

Спасибо ребятам за перевод.

82. dtybr 16 21.05.18 09:34 Сейчас в теме
Доброе утро.
Сколько времени прошло, а вопрос актуален и по сей день.
Коллеги, сможете вы еще пользуетесь http://realtimeboard.com/ ?
Есть ли в нем возможность указывать плановое время затрат и анализировать итоги спринта в разрезе планового времени/фактического времени/ количества выполненых и не выполненых.
Это важно для подведения итогов. Мы это на "физической" доске считаем и маркером пишем сейчас. Не очень удобно.
Оставьте свое сообщение