Comments 21
Хоть где-то понимают, что внесение ясности в задачу, в виде исполняемых спеков и тестов — единственный способ избежать хаоса при реализации.
Исполняемые спеки необходимы, но не достаточны для гарантии корректной работы. Они так же как и прочая документация могут не описывать всех мыслимых и не мыслимых нюансов.
Да, гарантировать это невозможно. Пробелы в спецификации будут сколько документации, даже разнотипной, ты не напиши. Но по другую сторону находятся проекты, где вообще нет вменяемой спецификации или она настолько поверхностная, что ее доделывают на ходу, по мере выявления в ней недостатков. А порой не доделывают, а согласовывают неясные места ad-hoc где-то, с кем-то, по почте, и/или телефону, а потом, это в виде тасков, состоящих только из заголовка, спускается разработчикам. Они идут к лиду, который им это спустил и он обьясняет им, что именно нужно сделать. Да, и такое бывает. У нас на проекте, видимо, считается зазорным писать лишний текст. Соответственно выглядит и документация кода, и тестирование, и архитектура. Архитектура есть, но она тебя в принципе никак не ограничивает. Получается, что одна команда пишет так, другая — эдак. Компилится, билд не ломает- нормально. Гайдлайны — там же где и документация лежат. Их просто нет. Так работа превращается в сплошной квест. Ты просто каждый день складываешь паззл. Без картинки. Часть коллег просто демотивированна и забивают на работу где только можно. Но ниче, как-то проект двигается вперед, что удивительно. Медленно, плохо, но двигается.
Поэтому когда видишь проект, где твоя работа рапланирована и ясна, где ты просто можешь, что я называю «работать вперед» — т.е выполнять рутинную работу по определенным заранее направлению и схеме — это кажется счастьем. Пусть для этого приходится ставить себя в определенные жесткие рамки.
Поэтому когда видишь проект, где твоя работа рапланирована и ясна, где ты просто можешь, что я называю «работать вперед» — т.е выполнять рутинную работу по определенным заранее направлению и схеме — это кажется счастьем. Пусть для этого приходится ставить себя в определенные жесткие рамки.
абсолютно, да.
я, персонально, еще впридачу отметил снятие с себя персонального груза рисков и ответственности за дальнейшую разработку. каждый может взять любую историю. каждый может ее завтра бросить. ничего не надо держать в голове, вышел — забыл — с утра снова прочитал. если забыл и не можешь найти где прочитать, то сам допишешь в спецификацию.
это другой мир, на самом деле.
я, персонально, еще впридачу отметил снятие с себя персонального груза рисков и ответственности за дальнейшую разработку. каждый может взять любую историю. каждый может ее завтра бросить. ничего не надо держать в голове, вышел — забыл — с утра снова прочитал. если забыл и не можешь найти где прочитать, то сам допишешь в спецификацию.
это другой мир, на самом деле.
Офигенная статья, и так мало комментариев. Я поражён.
Описанные условия — адов ад. Но я хотел бы в это на полгодика окунуться. Посмотреть и пощупать как выглядит TDD и парное программирование доведённые до крайности.
Осталось устранить стендапы, перевести всех на удаленку, платить не за жопочасы, а за закрытые тикеты и получится Zerocracy
Выглядит прикольно. Есть ли какие-то сравнения по качеству и скорости? Напишете статью на хабр?
нет, стендапы как были так и есть, хотя они становятся проще.
на удаленку нельзя, в этом весь пойнт парного программирования.
и платить за тикеты бессмысленно, программисты будут просто создавать больше тикетов.
оплата тут вообще ортогональна процессу — там есть отдельные recognition-метрики, которые у каждого коллаборанта могут быть свои, потому что, например, это могут быть разные компании-аутсорсеры.
на удаленку нельзя, в этом весь пойнт парного программирования.
и платить за тикеты бессмысленно, программисты будут просто создавать больше тикетов.
оплата тут вообще ортогональна процессу — там есть отдельные recognition-метрики, которые у каждого коллаборанта могут быть свои, потому что, например, это могут быть разные компании-аутсорсеры.
Отличная статья.
Сам имею возможность поработать с сабжем. Но как часто бывает в статьях — высвечиваются привлекательные стороны, а о плохом — вроде как не и сказано — значит и нету. А это очевидно не так. Список минусов не меньше чем список плюсов. И как любое лекарство его надо принимать с умом и под присмотром квалифицированого «доктора».
Кроме того в статье пропущена ключевая роль в этом процессе — TPM. Его квалификация и взаимодействие.
Ничего не сказано о роли Ankor — кто такой и где его взять.
Умалчивается а откуда беруться такие классные «десять-двадцать историй с покрытием» и что происходит когда они не классные или не беруться.
Ну и т.д…
В общем если представить, что проект состоит только из написания кода — то TDD\XP подход отлично решает проблему. Если же нет — то остаются пробелы и «пространство для улучшения».
Сам имею возможность поработать с сабжем. Но как часто бывает в статьях — высвечиваются привлекательные стороны, а о плохом — вроде как не и сказано — значит и нету. А это очевидно не так. Список минусов не меньше чем список плюсов. И как любое лекарство его надо принимать с умом и под присмотром квалифицированого «доктора».
Кроме того в статье пропущена ключевая роль в этом процессе — TPM. Его квалификация и взаимодействие.
Ничего не сказано о роли Ankor — кто такой и где его взять.
Умалчивается а откуда беруться такие классные «десять-двадцать историй с покрытием» и что происходит когда они не классные или не беруться.
Ну и т.д…
В общем если представить, что проект состоит только из написания кода — то TDD\XP подход отлично решает проблему. Если же нет — то остаются пробелы и «пространство для улучшения».
Писать десять-двадцать простых историй — это как раз очень просто. Поле нужно добавить на форму — раз. Поле нужно валидировать — два. Поле нужно скрывать в зависимости от других полей — три. Введенную информацию нужно послать на сервер — четыре. Валидировать на сервере — пять. Трансформировать в поле(поля) для базы — шесть. Сохранить в базу — семь. Добавить стили — восемь. (Это написать и принять одну историю для поля, включающую все вышесказанное, трудно, а так — нет.)
Все остальное — про ankor и TPM и прочее — это вопрос сюда не относящийся. Agile-методология бывает разная и я вообще не ее фанат, например. У нас есть стендапы и ретро, а TPMa нету совсем, ну и что.
Мы не говорим, что TDD решает все проблемы, мы указываем, какие именно проблемы оно решает: качество кода, наличие спеков и collaboration.
Все остальное — про ankor и TPM и прочее — это вопрос сюда не относящийся. Agile-методология бывает разная и я вообще не ее фанат, например. У нас есть стендапы и ретро, а TPMa нету совсем, ну и что.
Мы не говорим, что TDD решает все проблемы, мы указываем, какие именно проблемы оно решает: качество кода, наличие спеков и collaboration.
А что такое "история" и чем она отличается от задачи? Судя по тому, что результатом воплощения истории не являтся готовая фича, это не UserStory?
история — это просто user story, я не знал как перевести. просто они очень маленькие.
Оно соответствует определению тут: https://en.wikipedia.org/wiki/User_story
То есть написано с точки зрения ползователя, повествовательно и т.д.? Или просто "записать скидку в базу данных" — то ести технические подробности
написано в пользовательских терминах, в зависимости от предполагаемого пользователя. типично это: если в приложении А в одном поле записана дата заказа, то она должна отражаться в определенном поле приложения Б. Т.е. база данных или прочие особенности имплементации не фигурируют в самой истории. Как под это дело написать спеки — это обсуждаемый вопрос, иногда замораживают данные в базе и хардкодят ожидаемое значение в спецификации, иногда поднимают инстанс приложения и сравнивают с ним, например.
Если юзер сам программист и в состоянии посмотреть в базу, то в истории может фигурировать и база, впрочем.
Лишь бы тот, кто определяет юзер вэлью, не был отделен от acceptance по причине того, что у него нет прав\квалификации\ и тп
Если юзер сам программист и в состоянии посмотреть в базу, то в истории может фигурировать и база, впрочем.
Лишь бы тот, кто определяет юзер вэлью, не был отделен от acceptance по причине того, что у него нет прав\квалификации\ и тп
1. Кто пишет истории и кто их валидирует, что написаны/разбиты правильно? Видимо, сами разработчики?
2. На один тикет в джире несколько историй или один к одному?
2. На один тикет в джире несколько историй или один к одному?
у нас истории пишет продакт-оунер, но это, видимо, в зависимости от клиента-проекта по разному. разработчики просматривают на планнинге, если что-то выглядит сложнее чем нужно, разбивается на несколько. общий настрой на предельно атомарные истории, т.е. лучше переборщить с гранулярностью, чем принять историю с пропущенным требованием и после заводить баги или зависнуть в неопределенном состоянии.
один джира-тикет — одна история, она же юзер-стори.
единственное ограничение, может быть, что любая юзер-стори пишется в форме какую user value она предоставляет. т.е. «as an account manager i want to see the order id field on the form filled from the same place as in the Application», а не в технической форме — «добавить или починить real database adapter implementation», что ограничивает раж рефакторинга и заставляет фокусироваться на пользовательской ценности.
один джира-тикет — одна история, она же юзер-стори.
единственное ограничение, может быть, что любая юзер-стори пишется в форме какую user value она предоставляет. т.е. «as an account manager i want to see the order id field on the form filled from the same place as in the Application», а не в технической форме — «добавить или починить real database adapter implementation», что ограничивает раж рефакторинга и заставляет фокусироваться на пользовательской ценности.
А вы можете показать пример таких «10 простых историй»? — а то сложно представить что вы имеете ввиду.
Sign up to leave a comment.
True XP/TDD в Пивотал изнутри: как это выглядит и возможно ли это?